翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
AWS Control Tower の仕組み
このセクションでは、AWS Control Tower がどのように動作するかを大まかに説明します。ランディングゾーンは、すべての AWS リソース用に適切に設計されたマルチアカウント環境です。この環境を使用して、すべての AWS アカウントにコンプライアンス規制を適用できます。
AWS Control Tower のランディングゾーンの構造
AWS Control Tower のランディングゾーンの構造は次のとおりです。
-
ルート - ランディングゾーン内の他のすべての OU を含む親。
-
セキュリティ OU - この OU には、ログアーカイブアカウントと監査アカウントが含まれています。これらのアカウントは、共有アカウントとも呼ばれます。ランディングゾーンを起動するときに、これらの共有アカウント用にカスタマイズされた名前を選択できます。また、セキュリティとログ記録のために既存の AWS アカウントを AWS Control Tower に持ち込むオプションもあります。ただし、これらの名前を後で変更することはできません。また、初回起動後にセキュリティとログ記録のために既存のアカウントを追加することはできません。
-
サンドボックス OU - サンドボックス OU は、ランディングゾーンを有効にしている場合にランディングゾーンを起動すると作成されます。このメンバー OU と他のメンバー OU には、ユーザーが AWS ワークロードを実行するために使用する登録済みアカウントが含まれています。
-
IAM Identity Center ディレクトリ - このディレクトリには、IAM Identity Center ユーザーが格納されます。これは、各 IAM Identity Center ユーザーの許可の範囲を定義します。
-
IAM Identity Center ユーザー – これらは、ユーザーがランディングゾーンで AWS ワークロードを実行するために引き受けることができる ID です。
ランディングゾーンをセットアップした場合に起きること
ランディングゾーンをセットアップすると、ユーザーに代わって AWS Control Tower が管理アカウントで次のアクションを実行します。
-
2 つの AWS Organizations 組織単位 (OUs) を作成します。セキュリティとサンドボックス (オプション) は、組織のルート構造に含まれます。
-
セキュリティ OU 内に共有アカウントを 2 つ作成または追加する (ログアーカイブアカウントと監査アカウント)。
-
デフォルトの AWS Control Tower 設定を選択した場合や、ID プロバイダーを自己管理できる場合は、事前設定されたグループとシングルサインオンアクセスを使用して、IAM Identity Center にクラウドネイティブディレクトリを作成します。
-
必須の予防コントロールをすべて適用してポリシーを実施する。
-
必須の検出コントロールをすべて適用して設定違反を検出する。
-
予防コントロールは管理アカウントには適用されません。
-
管理コントロールを除き、ガードレールを組織全体に適用する。
AWS Control Tower ランディングゾーンおよびアカウント内のリソースの安全な管理
-
ランディングゾーンを作成すると、多数の AWS リソースが作成されます。AWS Control Tower を使用するには、このガイドで説明されたサポートされている方法以外で、これらの AWS Control Tower マネージドリソースを変更または削除することはできません。これらのリソースを変更または削除すると、ランディングゾーンの状態が不明になります。詳細については、「AWS Control Tower リソースの作成と変更に関するガイダンス」を参照してください。
-
オプションのコントロール (強く推奨されるガイダンスまたは選択的ガイダンスを持つコントロール) を有効にすると、AWS Control Tower はアカウントで管理する AWS リソースを作成します。AWS Control Tower によって作成されたリソースを変更または削除しないでください。これにより、コントロールの状態が不明になる可能性があります。
共有アカウントとは
AWS Control Tower では、ランディングゾーンの共有アカウント (管理アカウント、ログアーカイブアカウント、および監査アカウント) がセットアップ時にプロビジョニングされます。
管理アカウントとは
これは、ランディングゾーン専用に作成したアカウントです。このアカウントは、ランディングゾーンでのすべての請求に使用されます。また、このアカウントは、OU とコントロールの管理だけでなく、アカウントの Account Factory プロビジョニングに使用することもできます。
注記
AWS Control Tower 管理アカウントから運用ワークロードを実行することはお勧めしません。ワークロードを実行する別の AWS Control Tower アカウントを作成します。
詳細については、「管理アカウント」を参照してください。
ログアーカイブアカウントとは
このアカウントは、ランディングゾーン内のすべてのアカウントからの API アクティビティとリソース設定に関するログのリポジトリとして使用されます。
詳細については、「ログアーカイブアカウント」を参照してください。
監査アカウントとは
監査アカウントは、セキュリティチームとコンプライアンスチームに対してランディングゾーンのすべてのアカウントへの読み書きアクセスを許可するように設計された制限付きのアカウントです。監査アカウントからは、Lambda 関数にのみ付与されるロールを使用して、アカウントをレビューするためにプログラムによってアクセスできます。監査アカウントでは、他のアカウントに手動でログインすることはできません。Lambda 関数とロールの詳細については、「別の AWS アカウント からロールを引き受けるように Lambda 関数を設定する
詳細については、「監査アカウント」を参照してください。
コントロールの仕組み
コントロールは、 AWS 環境全体に継続的なガバナンスを提供する高レベルのルールです。各コントロールは 1 つのルールを適用します。これは、わかりやすい言語で示されます。有効になっている選択的コントロールまたは強く推奨されるコントロールを AWS Control Tower コンソールまたは AWS Control Tower API からいつでも変更できます。必須コントロールは常に適用され、変更することはできません。
予防コントロールにより、アクションの発生が防止されます。例えば、[Disallow Changes to Bucket Policy for Amazon S3 Buckets] (Amazon S3 バケットのバケットポリシーへの変更を不許可にする) という選択的コントロール (以前の名称は [Disallow Policy Changes to Log Archive] (ログアーカイブへのポリシーへの変更を不許可にする)) により、ログアーカイブ共有アカウント内で IAM ポリシーを変更できなくなります。禁止されたアクションを実行しようとすると、拒否され、CloudTrail に記録されます。リソースもログインします AWS Config。
検出コントロールにより、特定のイベントが発生したときにそのイベントが検出され、アクションが CloudTrail に記録されます。例えば、[Detect Whether Encryption is Enabled for Amazon EBS Volumes Attached to Amazon EC2 Instances] (Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームに対して暗号化が有効になっているかどうかを検出する) という強く推奨されるコントロールにより、暗号化されていない Amazon EBS ボリュームがランディングゾーンの EC2 インスタンスにアタッチされているかどうかが検出されます。
プロアクティブコントロールは、リソースがアカウントにプロビジョニングされる前に、リソースが会社のポリシーと目標に準拠しているかどうかを確認します。リソースがポリシーと目標に準拠していない場合、リソースはプロビジョニングされません。プロアクティブコントロールは、 AWS CloudFormation テンプレートを使用してアカウントにデプロイされるリソースをモニタリングします。
に慣れているユーザーの場合 AWS: AWS Control Tower では、予防コントロールはサービスコントロールポリシー (SCPs。検出コントロールは AWS Config ルールで実装されます。プロアクティブコントロールは AWS CloudFormation フックで実装されます。
関連トピック
AWS Control Tower と StackSets が動作する仕組み
AWS Control Tower は AWS CloudFormation StackSets を使用してアカウント内のリソースを設定します。各スタックセットには、アカウントおよびアカウント AWS リージョン ごとの に対応する StackInstances があります。AWS Control Tower は、アカウントとリージョンごとに 1 つのスタックセットインスタンスをデプロイします。
AWS Control Tower は、 AWS CloudFormation パラメータに基づいて、特定のアカウントと AWS リージョン に更新プログラムを適用します。更新が一部のスタックインスタンスに適用されると、他のスタックインスタンスが OUTDATED ステータスのままになることがあります。これは想定内の正常な動作です。
スタックインスタンスが OUTDATED 状態になった場合は通常、そのスタックインスタンスに対応するスタックがスタックセットの最新のテンプレートと合致していないことになります。スタックは古いテンプレートに残っているため、最新のリソースやパラメータが含まれていない可能性があります。スタックはまだ完全に使用可能です。
更新時に指定された AWS CloudFormation パラメータに基づいて、想定される動作を簡単にまとめます。
スタックセットの更新にテンプレートへの変更が含まれている場合 (つまり、 TemplateBodyまたは TemplateURLプロパティが指定されている場合）、または Parametersプロパティが指定されている場合、 は、指定されたアカウントおよび のスタックインスタンスを更新する前に、すべてのスタックインスタンスのステータスを「期限切れ」として AWS CloudFormation マークします AWS リージョン。スタックセットの更新にテンプレートまたはパラメータへの変更が含まれていない場合、 は指定されたアカウントとリージョンのスタックインスタンス AWS CloudFormation を更新し、他のすべてのスタックインスタンスは既存のスタックインスタンスのステータスのままにします。スタックセットに関連付けられたすべてのスタックインスタンスを更新するには、Accounts プロパティまたは Regions プロパティを指定しないでください。
詳細については、「 AWS CloudFormation ユーザーガイド」の「スタックセットの更新」を参照してください。
