[レポート] Accelerated hands-on recipes for building strong cloud foundations に参加してきました！ #SMB308 #AWSreInvent

AWS re:Invent 2024
#AWS Control Tower
#AWS Organizations
#AWS IAM Identity Center
ヒラネ
2024.12.06
こんにちは！ AWS 事業本部オペレーション部の平根です。

現在、re:Invent 2024 に現地参加しています。
https://reinvent.awsevents.com/
Control Tower によるランディングゾーンの設定と組織内の複数 AWS アカウントに対するアクセス管理について学習できそうな Builders' session がありましたので参加してみました。

本セッションは AWS の担当者 1 名と複数の参加者 (今回は 6 人程度) で構成されたテーブルで行われる 1 時間のハンズオンセッションでした。
 セッション概要セッションタイトル

SMB308 | Accelerated hands-on recipes for building strong cloud foundations
説明
アジリティ、セキュリティ、クラウド管理のための堅牢なクラウド基盤の構築は不可欠ですが、少人数の技術チームにとっては課題となっています。この実践的なビルダーズセッションに参加して、200社以上の中規模企業での成功事例を通じて洗練された実践的な経験と実証済みの戦略を学びましょう。組織のクラウドインフラを成長と持続的な成功のために確実にスケールさせるための重要な知識と自信を身につけることができます。このセッションでは、AWS Control Tower、AWS Organizations、AWS IAM Identity Center、および関連サービスについて探求します。参加にはノートパソコンの持参が必要です。
スピーカー
Sinisha Mikashinovich
Senior Solutions Architect, AWS

Pablo Redondo Sanchez
Principal Solutions Architect, AWS

Prashanth Ganapathy
Sr. Solutions Architect, Amazon

Lavanya Bandari
Sr. Solutions Architect, Amazon

Pawel Zawadzki
Sr. Solutions Architect, Amazon Web Services

 事前説明まず、セッションの冒頭で、マルチアカウント管理について以下の説明がありました。
マルチアカウント戦略
アカウントを分離することで、不正アクセスなどの発生時にアカウントが単一障害点となることを防止し、セキュリティ・運用上のリスクを軽減することができる

コンプライアンス維持のためのログ管理の重要性
ログを適切に記録・管理することで不正なアクセスや異常なアクティビティを迅速に検知できる

Control Tower の役割
マルチアカウント環境をデプロイし、管理する
ガードレールを利用して、安全でガバナンスの行き届いたクラウド基盤を提供する

 ハンズオンで実施した内容以下がハンズオンで実施した演習項目となります。

※タイトルは機械翻訳
 レシピ1: ランディングゾーンの基本設定今回のハンズオンでは、以下の OU 構成の環境を利用しました。
事前にデプロイされている Control Tower の環境に対して、新しい OU の作成や新規 AWS アカウントの登録などの組織の拡張を行いました。
1.1. Control Tower アカウント構造の拡張

Control Tower に対して新たな組織単位(組織名：Workload)を追加しました。
1.2. 既存のAWSアカウントを登録する

Control Tower に新たに登録する AWS アカウント(アカウント名：Workload A)に、Control Tower が管理を行うために必要な "AWSControlTowerExecution" ロールを作成しました。

新たに作成した組織に上記の AWS アカウントを追加しました。

以下の状態となり、Workload A アカウントを Control Tower の環境に追加することができました。
 レシピ2: ユーザーとアクセス管理AWS IAM Identity Center を利用して、権限セットとグループベースの割り当てを使用した権限制御を実施しました。

権限管理を集中させることで効率的に安全なユーザーアクセスを実現できます。
2.1. IAM アイデンティティ センターの紹介と MFA

セキュリティのベストプラクティスでは、すべてのユーザーに対して MFA をオンにすることが推奨されている点を学習しました。

※今回のハンズオンではデバイス等が用意できない都合上、 MFA の有効化は行いませんでした。
2.2. ユーザーにアカウントアクセスを割り当てる

事前に作成されている IAM Identity Center に IT Staff という新たなグループを作成し、ユーザー（ユーザー名：John Doe）を IT Staff グループに登録しました。

IT Staff グループ向けの権限セットを作成しました。

前の手順で Control Tower 環境に追加した Workload A アカウントに IT Staff グループと権限セットを割り当てました。
2.3. アカウントへのユーザーアクセスの検証

ユーザー John Doe で Workload A アカウントにログインを試行し、実際にログイン可能であることを確認しました。
 レシピ3: セキュリティとコンプライアンス管理Control Tower は、セキュリティとコンプライアンスの領域全体にわたる包括的なコントロールを提供しています。

これらのコントロールは AWS のベストプラクティスに準拠しているため、コンプライアンスを確保しながら AWS を利用することができます。
本項目では、リソースの管理やコンプライアンスの監視を行うための予防・検知を行うコントロールを実装しました。
3.1. コントロールライブラリの紹介

本項目では、Control Tower に存在するコントロールライブラリとは何かについて学習をしました。

コントロールライブラリとは、様々な目的に応じ予め用意されたコントロールの一覧です。

一覧から有効化を行うことで、Control Tower 環境に対して簡単にコントロールを適用できます。

コントロールライブラリは以下の画面から確認することができます。
3.2. 非準拠のS3バケットを検出する

"レシピ 2" にて Control Tower 環境に追加した Workload A アカウント内で、バージョン管理が無効となっている S3 バケットを作成しました。

また、組織の管理アカウントの Contorol Tower にて、S3 バケットのバージョン管理が有効になっているかどうかを検出する以下コントロールを有効化しました。
コントロール：[AWS-GR_S3_VERSIONING_ENABLED] Detect whether versioning for Amazon S3 buckets
後続の手順で、上記のコントロールにより実際にバージョン管理が無効となっている S3 バケットが検知されるかを確認します。
3.3. ルートアカウントを保護する

AWS Organizations の全アカウントにおいて、ルートユーザーによる操作をブロックすることは重要なセキュリティ対策です。

本項目では、ルートユーザーでの操作を禁止する以下のコントロールを有効化しました。
コントロール：[AWS-GR_RESTRICT_ROOT_USER] Disallow actions as a root user
Control Tower 環境のアカウントについて、ルートユーザーのみが実行可能な操作を行う必要がある場合には次のような対策を取る必要があります。
対策 1：本コントロールを一時的に無効化する

対策 2：Control Towerの管理外のOUを作成し、ルートユーザーのアクションが必要なアカウントを一時的に作成した管理外のOUに移動する
参考：ルートユーザーのみが実行可能な操作
3.4. コンプライアンスステータスの確認

前述の手順で有効化した以下コントロールのステータスを確認しました。

以下のように、バージョン管理が無効となっている S3 バケットが非準拠のリソースとして検知されていることを確認できました。
 レシピ4: 財務ガバナンス本項目では、組織に対して予算や閾値を設定し、閾値を超過した際に SCP によりアクションを制限するように設定をしました。
4.1. 組織でCost Explorerサービスを有効にする

Cost Explorer について、管理アカウントでは組織内のアカウント全てに対してフィルタリングができるのに対し、

メンバーアカウントでは他のメンバーアカウントのフィルタリングができないことを確認しました。
管理アカウントの画面



メンバーアカウントの画面

4.2. サンドボックスアカウントの予算制限

本項目では、サンドボックス アカウントの予算制限を設定してクラウド コストを効果的に管理する方法を学習しました。

まず、以下のような EC2 のアクションを禁止するポリシーを Organizaiion の SCP に作成し、"BudgetControl-DenyEC2-SCP" と名前をつけました。
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": [
                "ec2:Run*",
                "ec2:Start*",
                "ec2:Create*"
            ],
            "Resource": "*"
        }
    ]
}
次に、SCP の更新を許可するロール "AllowChangeSCPforAWSBudgets" を作成しました。

その後、Billing and Cost Management にて予算を 100$ に設定しました。

上記予算の 80%に達した際に、"BudgetControl-DenyEC2-SCP" が特定の組織に適用されるように設定をしました。
 ためになったことIAM Identity Center のユーザー追加方法について

IAM Identity Center のユーザー追加方法について、ドキュメント上で確認したことはあったものの具体的な設定イメージが湧いていない状態でした。

今回、実際にコンソール上でグループの作成、グループへのユーザー追加、権限セットの作成、ログイン対象のアカウント・グループ・権限セットの紐付けの操作を一連で実施することで、理解を深めることができました。
Billing and Cost Management の予算のアラート機能について

Billing and Cost Management の予算にて、予算超過時に SCP が自動適用されるように設定し、

過度な費用の発生を抑止できることを知らなかったのでとてもためになりました。

EventBridge や Lambda を利用することなくこのようなアクションを実行できるのはとても便利ですね！
 最後にControl Tower の機能は複数の AWS アカウントを管理する際に利用するものであり、個人での検証はなかなか手間がかかるものだと思います。

ハンズオンを通して実際にコントロールの適用や検知、または組織に対する予算の設定を行いながら理解を深めることができ、貴重な経験となりました。

個人での検証が難しい内容については、今回のような AWS イベントで参加できるハンスオンに積極的に参加していきたいとおもいました。
以上、平根でした！