既存のAWSアカウントをControlTowerに登録する

既存のAWSアカウントをControlTowerの管理下に移管する

AWS Control Tower

組織の中でクラウド利用が活発になると、組織内にアカウントが増えてきますよね。様々な部署がある企業の中でガバナンスを効かせながら複数のアカウントを運用していくためには、一元的な管理が不可欠です。

AWSには以下に挙げた例のような、複数のアカウントの管理を行うための様々なサービスが用意されています。

  • OU単位で管理し、SCP(サービスコントロールポリシー)を適用したり利用料金の一括請求ができるAWS Organizations
  • AWS リソースの設定を評価、監査、審査できるサービスであるAWS Config
  • AWS アカウントの運用とリスクの監査、ガバナンス、コンプライアンスを行えるように支援するAWS CloudTrail
  • ユーザーのID を安全に作成・接続し、AWS アカウントとアプリケーション全体のアクセスを一元的に管理するのに役立つIAM Identity Center

一方で新しくアカウントを作るたびに、アカウントを跨ぎながらこれらの設定を入れていくのは煩雑で、設定ミスがセキュリティホールに繋がるリスクもあります。
AWS Control Towerを用いることで、新規アカウント作成から上記のような設定をワンストップで行うことができ、組織内のアカウント管理を簡単で強固なものとすることができます。

既存のアカウントの移管

複数アカウント管理のためのサービスは非常に便利なものですが、最近AWSをやっと使い始めた企業にとっては、スモールスタートしたアカウントがあるかもしれません。
最近になってようやくCCoE(Cloud Center of Excellence)が発足した、というのも事業会社には多いパターンかもしれません。弊社も多分に漏れずそうです。

このような場合、組織のクラウド管理者を中心にControl Towerの運用が始まりクラウドの利用は加速していくことが見込まれますが、運用開始前にすでに稼働していたアカウントをControl Towerの管理下に入れるという必要性に駆られることがあると思います。
私も今回そのような状況に直面し、実際にやってみたところ少し設定が必要だったので今回はその方法についてご紹介します。

なお今回はすでに既存アカウントは組織のOrganizationsの中にある状態とします。
Organizations外のアカウントを招待する方法は組織への AWS アカウント の招待 - AWS Organizations
ユーザーガイド
をご参照ください。

AWS Control Towerへのアカウントの登録

AWSコンソールにてAWS Control Tower→組織へ移動します。ここでOrganizations内のアカウントが一覧で見られます。

  • AWS Control Towerへ登録済みのアカウントは登録済み
  • 登録されていないアカウントは未登録
  • 削除して90日以内のアカウントは停止

という状態となります。
今回はtechnexus-blogというアカウントをControl Towerに登録します。

一覧から当該アカウントを選択し詳細画面に進むと、アカウントの登録ボタンがありますのでそれをクリックします。
組織単位が登録したいOUになっているかを確認し登録します。

この時点で「アカウントを登録する前に、手動でアカウントを承認する必要があります。」という警告が出ます。今回は登録されるアカウントでこの設定を行う必要があるのですが、ここは一旦そのまま登録してみます。
図の下の方に書いてあるように、この登録のタイミングでAWS Control Tower は IAM Identity Center ログインを作成したり、親OUの設定に合わせるようですね。

ですが、登録されるアカウントにAWSControlTowerExecutionロールがないため、この登録は失敗します。

AWSControlTowerExecutionロールを追加する

そこでコンソールにもあるように、登録されるアカウントでAWSControlTowerExecutionロールを追加してやります。
以下のドキュメントを参考にしています。
(Manually add the required IAM role to an existing AWS account and enroll it - AWS Control Tower User Guide)

IAM→ロール→ロールを作成と進みます。
信頼されたエンティティタイプは カスタム信頼ポリシーを選択します。
その下にあるカスタム信頼ポリシーは以下のようなポリシーで作成します。Management Account IDはControl TowerのアカウントIDに変更します。

{
   "Version":"2012-10-17",
   "Statement":[
      {
      "Effect":"Allow",
      "Principal":{
         "AWS": "arn:aws:iam::Management Account ID:root"
         },
         "Action": "sts:AssumeRole",
         "Condition": {} 
      }
   ]
  }

そのまま次へ進み、AdministratorAccessのポリシーをアタッチし、ロール名をAWSControlTowerExecution、説明に適当な説明文を入力しロールを作成します。
ここでロールが作成できれば良いのですが、私はここで作成できず面食らってしまいました。

原因は、私が登録しようとしたアカウントはすでにAWS Control Towerで管理されたOrganizationsのOUの下に入れていたことでした。この時点で、AWS Control Towerで設定されたコントロール(昔はガードレールと呼ばれていたのでガードレールで説明されているドキュメントもある)が有効になっていました。
このコントロールは複数の項目によって構成されており、それによってOUにSCPがアタッチされます。
その中の [AWS-GR_IAM_ROLE_CHANGE_PROHIBITED]AWS Control Tower と AWS CloudFormation によって設定された AWS IAM ロールの変更を許可しない によって、 以下のSCPが有効になってしまいます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GRIAMROLEPOLICY",
      "Effect": "Deny",
      "Action": [
        "iam:AttachRolePolicy",
        "iam:CreateRole",
        "iam:DeleteRole",
        "iam:DeleteRolePermissionsBoundary",
        "iam:DeleteRolePolicy",
        "iam:DetachRolePolicy",
        "iam:PutRolePermissionsBoundary",
        "iam:PutRolePolicy",
        "iam:UpdateAssumeRolePolicy",
        "iam:UpdateRole",
        "iam:UpdateRoleDescription"
      ],
      "Resource": [
        "arn:aws:iam::*:role/aws-controltower-*",
        "arn:aws:iam::*:role/*AWSControlTower*",
        "arn:aws:iam::*:role/stacksets-exec-*"
      ],
      "Condition": {
        "ArnNotLike": {
          "aws:PrincipalArn": [
            "arn:aws:iam::*:role/AWSControlTowerExecution",
            "arn:aws:iam::*:role/stacksets-exec-*"
          ]
        }
      }
    }
  ]
}

これによってAWSControlTowerExecutionロールが作れなかったようです。
対処法としてはOUの下に入れる前(Root直下などにある段階)にロールを作成してしまうのが良いかと思います

再度AWS Control Towerで登録

これでAWS Control Towerから登録ができるようになったので、先程の手順と同様に登録してみます。
無事登録済みとなりました!

一部戸惑う点もありましたが、このようにして既存アカウントをAWS Control Towerに登録できました。

余談ですが、re: InventではCCoEなど管理者向けにアカウント管理やセキュリティのベストプラクティスをテーマとしたBreakout sessionやWorkshopもたくさんありました。
そのようなセッションは我々のような事業会社からの参加者が多かった印象があり、世界中で同じような悩みがあるんだろうなと実感しました。

Next Post Previous Post