こんにちは。クラウドコンサルティング課の田原です。
先日、Control Towerのセットアップ及びユーザー管理のブログを記載しましたが、前回扱えなかった「コントロール管理」・「Control Towerの廃止」についてご紹介いたします。
※前回のブログの続きとなります。以下の前回ブログを先にご参照ください。
※本ブログは、ワークショップの内容をベースに、図や追加調査の内容を補足しております。実際に手順実施の場合は、以下のオリジナルのワークショップの資料と合わせてご参照ください。
※2024/11時点の構築手順となります。アップデート等で変更になっている箇所は適宜読み替えて実施してください。
- 前提と構築ステップ
- ステップ⑦：コントロール管理：検出(Detective)
- ステップ⑧：コントロール管理：プロアクティブ(Proactive)
- ステップ⑨：コントロール管理：予防(Preventive)
- ステップ⑩：.Control Tower環境の削除
- まとめ
前提と構築ステップ
※ 前提として以下、前回ブログのステップ①ー⑥の「Control Towerの初期セットアップ」から「AWSアカウントの取り込み」までが完了した状態でのスタートを想定しております。
【やってみた】AWS Control Towerワークショップ その①（Control Towerセットアップ・ユーザー管理） - サーバーワークスエンジニアブログ
・本ブログで取り上げる「構成」と「構築ステップ」について以下に記載を行います
・Control Towerの「コントロール管理」機能と、検証利用した「Control Towerの廃止」方法について記載します
構成
構築ステップ
| ステップ | 概要 | 対応内容 |
|---|---|---|
| 7 | コントロール管理：検出(Detective) | ・検出コントロールによる「 S3 バケットのバージョニング有効確認」の実施と検証（※AWS Configの利用） |
| 8 | コントロール管理：プロアクティブ(Proactive) | ・プロアクティブコントロールによる「S3 バケットがセキュアソケットレイヤーの使用要求」の実施と検証（※AWS CloudFormation Hooksの利用） |
| 9 | コントロール管理：予防(Preventive) | ・予防コントロールによる「S3 バケットの暗号化設定の変更を許可しない」の実施と検証（※SCPの利用） |
| 10 | Control Tower環境の削除 | ・ランディングゾーンの廃止 ・ログアーカイブ用のS3バケットログ削除 ・AWS IAM Identity Center の削除 ・AWS Organizationsの廃止 ・管理AWSアカウントでのその他リソースの削除 |
※構築ステップ①－⑥は、前回ブログをご参照ください。
ステップ⑦：コントロール管理：検出(Detective)
・関連ワークショップページ：https://catalog.workshops.aws/control-tower/ja-JP/controls/detective
・「検出コントロール(Detective)」の動作検証として、「 S3 バケットのバージョニング有効確認」の適用をおこないます。
※ 検出コントロールの動作は、「AWS Config ルール」を使用してコンプライアンス違反を検出しています。
・AWS access portalにログイン後の、管理AWSアカウントの「AWSAdministratorAccess」にログインします ・「Control Tower」にアクセスし、→「すべてのコントロール」をクリックします ・コントロールを検索ボックスにて、「 [AWS-GR_S3_VERSIONING_ENABLED] Amazon S3 バケットのバージョニングが有効になっているかどうかを検出する」を検索し、選択します。 ・選択したコントロールが「動作：検出」、「実装：AWS Config rule」になっていることを確認し、以下をおこないます ・「コントロールアクション」→「有効化にする」を選択します ・検出コントロールの適用をおこなう「Sandbox」OUを選択して、「コントロールを有効化」をクリックします ・選択したコントロール画面に戻るため、「OUは有効です」タブをクリックし、「Sandbox」OUの制御が有効になっていることを確認します ・「Control Tower」→「ダッシュボード」をクリックし、「非準拠リソース」、「コンプライアンス」、「コンプライアンスステータス」に異常が無いことを確認します。
・「 S3 バケットのバージョニング有効確認」を動作させるため、S3バケットの作成をおこないます
・別のブラウザで、AWS access portalを開きます。 ・SandboxOU所属のAWSアカウント (Lab-User1)のメールアドレスでログインをおこない、「AWSAdministratorAccess」でログインします。 ※管理AWSアカウントのメールアドレスでログインしたユーザーに表示されているSandboxOU所属のAWSアカウント (Lab-User1)は「AWSOrganizationsFullAccess」の為、S3作成の権限がありません ・「S3」へアクセスし、「バケットを作成」をクリックします。 ・バケット名を「[AWSアカウントID]-testbuket-1」とし、その他の項目をデフォルトのままとして作成をおこないます ※デフォルト設定を使用して S3 バケットを作成すると、バージョニングは有効になりません。
・Control Tower側で検出が表示されるのかを確認します
・AWS access portalにログイン後の、管理AWSアカウントの「AWSAdministratorAccess」にログインします ・「Control Tower」→「ダッシュボード」をクリックし、「非準拠リソース」、「コンプライアンス」、「コンプライアンスステータス」を確認します ・「Amazon S3 バケットのバージョニングが有効になっているかどうかを検出する」の非準拠リソースとして表示されていることが確認できました。
ステップ⑧：コントロール管理：プロアクティブ(Proactive)
・関連ワークショップページ：https://catalog.workshops.aws/control-tower/ja-JP/controls/proactive
・「プロアクティブコントロール(Proactive)」の動作検証として、「 S3 バケットがセキュアソケットレイヤーの使用要求」の適用をおこないます
※ プロアクティブコントロールの動作は、「AWS CloudFormation Hooks」を使用して、プロビジョニングされる前にリソースのコンプライアンスチェックをしてリソース作成を未然に防ぎます
※プロアクティブコントロールは、動作前提で「[CT.CLOUDFORMATION.PR.1] AWS CloudFormation レジストリ内のリソースタイプ、モジュール、フックの管理を禁止する」のコントロールを実行しておく必要があります
・AWS access portalにログイン後の、管理AWSアカウントの「AWSAdministratorAccess」にログインします ・「Control Tower」にアクセスし、→「すべてのコントロール」をクリックします ・まず、コントロールを検索ボックスにて、「[CT.CLOUDFORMATION.PR.1] AWS CloudFormation レジストリ内のリソースタイプ、モジュール、フックの管理を禁止する」を検索し、選択します。 ・「コントロールアクション」→「有効化にする」を選択します ・検出コントロールの適用をおこなう「Sandbox」OUを選択して、「コントロールを有効化」をクリックします ・次に、コントロールを検索ボックスにて、「[CT.S3.PR.8] Amazon S3 バケットがセキュアソケットレイヤーの使用をリクエストすることを要求する」を検索し、選択します。 ・選択したコントロールが「動作：プロアクティブ」、「実装：AWS CloudFormation hook」になっていることを確認します ・「コントロールアクション」→「有効化にする」を選択します ・検出コントロールの適用をおこなう「Sandbox」OUを選択して、「コントロールを有効化」をクリックします ・選択したコントロール画面に戻るため、「OUは有効です」タブをクリックし、「Sandbox」OUの制御が有効になっていることを確認します
・「HTTP」の接続を許可したS3バケットを作成するCloudFormationでリソースをデプロイする場合、「 S3 バケットがセキュアソケットレイヤーの使用要求」のコントロールにて拒否される動作を確認します。
※CloudFormationはワークショップの中で提供されている、以下の「HTTP」の接続を許可したS3バケットを作成するCloudFormation「cfn-non-compliant.yml 」を利用します。
・ローカルPCへ「cfn-non-compliant.yml 」をダウンロードしておきます ・AWS access portalにログイン後の、・SandboxOU所属のAWSアカウント (Lab-User1)のメールアドレスでログインをおこない、「AWSAdministratorAccess」でログインします。 ・「CloudFormation」→「スタック」→「スタックの作成」→「新しいリソースを使用 (標準) 」をクリックし以下を入力します。 ・テンプレートの準備 ： 既存のテンプレートを選択 ・テンプレートソース ： テンプレートファイルのアップロード ・テンプレートファイルのアップロード ： cfn-non-compliant.yml ・スタック名に「myLogBucketStack」と入力し、その他項目はデフォルトにて「送信」をクリックします。 ・スタックのステータスが「ROLLBACK_COMPLETE」となり失敗したことを確認します。 ・「イベント」タブを開き、フック呼び出し列の「ControlTower::Guard::Hook」を開くと、プロアクティブコントロールにてデプロイを拒否されたことを確認できました。
ステップ⑨：コントロール管理：予防(Preventive)
・関連ワークショップページ：https://catalog.workshops.aws/control-tower/ja-JP/controls/preventive
・「予防コントロール(Preventive)」の動作検証として、「 S3 バケットの暗号化設定の変更を許可しない制御」の適用をおこないます
※ 予防コントロールの動作は、「サービスコントロールポリシー (SCP) 」をOUにアタッチして、対象アクションを禁止します
・AWS access portalにログイン後の、管理AWSアカウントの「AWSAdministratorAccess」にログインします ・「Control Tower」にアクセスし、→「すべてのコントロール」をクリックします ・コントロールを検索ボックスにて、「[AWS-GR_AUDIT_BUCKET_ENCRYPTION_ENABLED] Amazon S3 バケットの暗号化設定の変更を許可しない」を検索し、選択します。 ・選択したコントロールが「動作：予防」、「実装：Service control policy (SCP)」になっていることを確認します ・「コントロールアクション」→「有効化にする」を選択します ・検出コントロールの適用をおこなう「Sandbox」OUを選択し、その他項目はデフォルト値で、「コントロールを有効化」をクリックします ・選択したコントロール画面に戻るため、「OUは有効です」タブをクリックし、「Sandbox」OUの制御が有効になっていることを確認します
・検出コントロールの際に作成したデフォルト設定のS3バケットに「暗号化設定を無効化」する操作をおこない、「S3 バケットの暗号化設定の変更を許可しない制御」のコントロール適用が行われたか動作の確認おこないます
・AWS access portalにログイン後の、・SandboxOU所属のAWSアカウント (Lab-User1)のメールアドレスでログインをおこない、「AWSAdministratorAccess」でログインします。 ・「S3」→「バケット」→「検出コントロールの際に作成したデフォルト設定のS3バケット」→「プロパティ」を選択します ・「デフォルトの暗号化」項目の「編集」をクリックします ・「バケットキー」項目を「無効化する」を選択して、「変更の保存」をクリックします ・サービスコントロールポリシー (SCP)にて拒否されて、設定が実行できないことを確認できました。
ステップ⑩：.Control Tower環境の削除
・関連ワークショップページ：https://catalog.workshops.aws/control-tower/ja-JP/cleanup
・ワークショップの中では、環境の廃止方法の詳細が取り上げられていませんでしたので以下にControl Tower環境削除の流れをまとめています。
・今回は、「管理AWSアカウントのみを残す」形で、Control Tower検証で作成したAWSアカウント及びリソースを削除・廃止する方法をで対応していきます。
10-1.ランディングゾーンの廃止
・まず最初にControl Towerの「ランディングゾーンの廃止」をおこないます。
※参照手順：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/how-to-decommission.html
・ただし、ランディングゾーンの廃止では、以下のリソースの削除は自動でおこなわれない為、次項で手動での削除をおこなっていきます。
* AWS Organizations
* AWS IAM Identity Center (SSO)
* IAMロール
* Amazon S3 バケット
* 共有アカウント
* プロビジョニングされたアカウント
* CloudWatch ログロググループ
※参照ドキュメント：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/resources-not-removed.html
・「管理AWSアカウント」にログインします。 ・「AWS Control Tower」へアクセスし、「ランディングゾーン設定 」を選択します。 ・「廃止」タブへ移動し、「ランディングゾーンの廃止」をクリックします。 ・ランディングゾーン廃止の最終確認の画面が表示されます。 ※この操作は元には戻せないため、ランディングゾーンを廃止して問題無い無いか確認後に実施下さい ※ランディングゾーンの廃止処理は「最大2時間程度」かかります ・ランディングゾーンの廃止が完了したことを確認します。
10-2.ログアーカイブ用のS3バケットログ削除
・ログアーカイブ用のS3バケットは自動削除されていないため、手動で削除をおこないます。
※ログアーカイブ用のAWSアカウント廃止依頼から90日間はリソースが残り続けるため、コスト観点からの削除となります。
・AWS access portalにアクセス後、ログアーカイブ用のAWSアカウントの「AWSAdministratorAccess」にログインします ・「S3」→「バケット」へアクセスします。 ・「aws-controltower」から始まるバケットが2つあるため、こちらを削除します。 ・各バケットにて「空にする」を実施 ・各バケットにて「削除」を実施
10-3.AWS IAM Identity Center の削除
・IAM Identity Centerは自動削除されていないため、手動で削除をおこないます。
※これまで、IAM Identity Center経由でログインを行ってきましたが、本手順でIAM Identity Centerの削除をおこないIAM Identity Center経由でのログインが不可となります。 ※以降の手順については、IAM Identity Center経由では無く、「管理AWSアカウント」に管理権限を持ったIAMユーザまたはロール等でログインをして作業を行ってください。 ・「管理AWSアカウント」にログインします。 ・「IAM Identity Center」にアクセスし、「Settings」をクリックします。 ・「管理」タブをクリックし、「IAM Identity Center インスタンスを削除」の項目の「Delete」をクリックします ・最終確認画面が表示されるため、チェックを入れて「確認」をクリックします。 ※この操作は元には戻せないため、各AWSアカウントへログインが不要になった後に実施下さい
10-4.AWS Organizationsの廃止
・AWS Organizationsや各AWSアカウントは自動で廃止されていないため、手動で廃止をおこないます。
・まず、各AWSアカウントの廃止リクエストをしていきます。
※参照手順：https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_accounts_close.html
※本リクエストから、実際のAWSアカウント閉鎖には「最大90日」かかる点に注意が必要です
・「管理AWSアカウント」にログインします。 ・「AWS Organizations」にアクセスし、「AWS アカウント」をクリックします。 ・廃止対象の各AWSアカウントを選択して、「アクション」→「AWSアカウント/閉鎖」をクリックします。 ・最終確認をおこない「アカウントを閉鎖する」をクリックします ※各閉鎖対象のAWSアカウントで実行します ・閉鎖したアカウントは「中止済み」に変わります（90日後削除されます）
・次に、OUの削除をおこないます。各AWSアカウントをRoot OUへ移動後に、OUの削除が可能となります。
※参照手順：https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_org_delete.html
・「AWS Organizations」にアクセスし、「AWS アカウント」をクリックします。 ・削除対象のOUの配下にメンバーアカウントある場合はOU削除が不可の為、Root OUへ移動をおこないます。 ・各中止済みAWSアカウントを選択し、「アクション」→「AWSアカウント/移動」をクリックします。 ・「Root OU」を選択し、「AWSアカウントを移動」をクリックします。 ・各メンバーアカウントがOU配下からRoot OUに移動したことを確認します ・削除対象のOUを選択し、「アクション」→「組織単位/削除」をクリックします。 ・確認をおこない「削除」をクリックします。 ・Root OU配下のアクティブなアカウントが管理アカウントのみになっていることを確認します。
・最後に、Organizations(組織）自体の削除を行います。
※参照手順：https://docs.aws.amazon.com/ja_jp/organizations/latest/userguide/orgs_manage_org_delete.html
※「すべてのメンバーアカウントが削除された後」のみOrganizations(組織）が削除可能となるため、メンバーアカウント削除後の「最大90日以降」に実施できる点に注意が必要です。
10-5.管理AWSアカウントのその他リソース削除
・管理AWSアカウントにControl Towerの残リソースとして「CloudWatch Logs ロググループ」、「IAMロール・ポリシー」が残っている為、こちらを削除します。
・まず、Control Towerの「CloudWatch Logs ロググループ（aws-controltower/CloudTrailLogs）」を削除します。
※参照手順：https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/resources-not-removed.html
・「管理AWSアカウント」にログインします。 ・「CloudWatch」へアクセスし、「ロググループ」をクリックします。 ・「aws-controltower/CloudTrailLogs」のロググループが存在してるため、「ロググループの削除」をおこないます。
・最後に、Control Towerの「IAMロール・ポリシー」を削除します。
・「管理AWSアカウント」にログインします。 ・「Identity and Access Management (IAM)」へアクセスします。 ・以下の削除対象ロールを削除します。 - AWSControlTowerAdmin - AWSControlTowerCloudTrailRole - AWSControlTowerStackSetRole - AWSControlTowerConfigAggregatorRoleForOrganizations ・以下の削除対象ポリシーを削除します。 - AWSControlTowerAdminPolicy - AWSControlTowerCloudTrailRolePolicy - AWSControlTowerStackSetRolePolicy
お疲れさまでした。Control Towerのコントロール管理からControl Towerの廃止までの一連の対応はこれで以上です。
まとめ
いかがでしたでしょうか？
前回のブログと合わせるととても長い記事となってしまいましたが、Control Towerの基本の使い方から廃止までを一貫して学べたように思います。
Control Tower自体はまだまだ機能がたくさんあるため、引き続き理解を深めていっていきたいと思います。
本ブログが誰かの学びになれば幸いです。
田原宏樹(執筆記事の一覧)
子供とのお出かけとPodcastを聞くことが趣味です。
