AWS Control Tower の仕組み - AWS Control Tower

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS Control Tower の仕組み

このセクションでは、AWSControl Tower の仕組みを大まかに説明します。ランディングゾーンは、すべての AWS リソース用に適切に設計されたマルチアカウント環境です。この環境を使用して、すべての AWS アカウントにコンプライアンス規制を適用できます。

AWS Control Tower ランディングゾーンの構造

AWS Control Tower のランディングゾーンの構造は次のとおりです。

  • ルート – ランディングゾーンOUsに他のすべての を含む親。

  • セキュリティ OU - この OU には、ログアーカイブアカウントと監査アカウントが含まれています。これらのアカウントは、共有アカウントとも呼ばれます。ランディングゾーンを起動するときに、これらの共有アカウント用にカスタマイズされた名前を選択できます。また、セキュリティとログ記録のために既存の AWS アカウントを AWS Control Tower に持ち込むオプションもあります。ただし、これらの名前を後で変更することはできません。また、初回起動後にセキュリティとログ記録のために既存のアカウントを追加することはできません。

  • サンドボックス OU - サンドボックス OU は、ランディングゾーンを有効にしている場合にランディングゾーンを起動すると作成されます。この およびその他の登録済み には、ユーザーがAWSワークロードを実行するために使用する登録済みアカウントOUsが含まれています。

  • IAM Identity Center ディレクトリ – このディレクトリには、IAMIdentity Center ユーザーが格納されます。各 IAM Identity Center ユーザーのアクセス許可の範囲を定義します。

  • IAM Identity Center ユーザー – これらは、ユーザーがランディングゾーンで AWS ワークロードを実行するために引き受けることができる ID です。

ランディングゾーンをセットアップした場合に起きること

ランディングゾーンを設定すると、AWSControl Tower はユーザーに代わって管理アカウントで次のアクションを実行します。

  • AWS Organizations 組織ルート構造に含まれるOUsセキュリティとサンドボックス (オプション) の 2 つの組織単位 () を作成します。

  • セキュリティ OU 内に共有アカウントを 2 つ作成または追加する (ログアーカイブアカウントと監査アカウント)。

  • デフォルトの AWS Control Tower 設定を選択した場合、または ID プロバイダーを自己管理できる場合、事前設定されたグループとシングルサインオンアクセスを使用して、IAMIdentity Center にクラウドネイティブディレクトリを作成します。

  • 必須の予防コントロールをすべて適用してポリシーを実施する。

  • 必須の検出コントロールをすべて適用して設定違反を検出する。

  • 予防コントロールは管理アカウントには適用されません。

  • 管理コントロールを除き、ガードレールを組織全体に適用する。

AWS Control Tower ランディングゾーンとアカウント内のリソースを安全に管理する
  • ランディングゾーンを作成すると、多数の AWS リソースが作成されます。AWS Control Tower を使用するには、このガイドで説明されているサポートされている方法以外で、これらの AWS Control Tower マネージドリソースを変更または削除しないでください。これらのリソースを変更または削除すると、ランディングゾーンの状態が不明になります。詳細については、「AWS Control Tower リソースの作成と変更に関するガイダンス」を参照してください。

  • オプションのコントロール (強く推奨されるガイダンスまたは選択的ガイダンスを持つコントロール) を有効にすると、AWSControl Tower はアカウントで管理する AWS リソースを作成します。AWS Control Tower によって作成されたリソースを変更または削除しないでください。これにより、コントロールの状態が不明になる可能性があります。

共有アカウントとは

AWS Control Tower では、ランディングゾーンの共有アカウントがセットアップ時にプロビジョニングされます。管理アカウント、ログアーカイブアカウント、監査アカウントです。

管理アカウントとは

これは、ランディングゾーン専用に作成したアカウントです。このアカウントは、ランディングゾーンでのすべての請求に使用されます。また、アカウントの Account Factory プロビジョニングや、 OUsと の管理にも使用されます。

注記

AWS Control Tower 管理アカウントからどのようなタイプの本番ワークロードも実行することはお勧めしません。ワークロードを実行するには、別の AWS Control Tower アカウントを作成します。

詳細については、「管理アカウント」を参照してください。

ログアーカイブアカウントとは

このアカウントは、ランディングゾーン内のすべてのアカウントからのAPIアクティビティとリソース設定のログのリポジトリとして機能します。

詳細については、「ログアーカイブアカウント」を参照してください。

監査アカウントとは

監査アカウントは、セキュリティチームとコンプライアンスチームに対してランディングゾーンのすべてのアカウントへの読み書きアクセスを許可するように設計された制限付きのアカウントです。監査アカウントからは、Lambda 関数にのみ付与されるロールを使用して、アカウントをレビューするためにプログラムによってアクセスできます。監査アカウントでは、他のアカウントに手動でログインすることはできません。Lambda 関数とロールの詳細については、「別の  AWS アカウント からロールを引き受けるように Lambda 関数を設定する」を参照してください。

詳細については、「監査アカウント」を参照してください。

コントロールの仕組み

コントロールは、 AWS 環境全体に継続的なガバナンスを提供する高レベルのルールです。各コントロールは 1 つのルールを適用します。これは、わかりやすい言語で示されます。有効な選択的コントロールまたは強く推奨されるコントロールは、Control Tower コンソールまたは AWS Control AWS Tower からいつでも変更できますAPIs。必須コントロールは常に適用され、変更することはできません。

予防コントロールにより、アクションの発生が防止されます。例えば、Amazon S3 バケットのバケットポリシーへの変更を許可しない (以前はログアーカイブへのポリシー変更を許可しない) という選択コントロールは、ログアーカイブ共有アカウント内のIAMポリシー変更をすべて禁止します。禁止されたアクションを実行しようとすると、拒否され、 CloudTrail に記録されます。リソースもログインします AWS Config。

検出コントロールは、特定のイベントが発生したときに検出し、 でアクションをログに記録しますCloudTrail。例えば、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 を使用して、 アカウントのリソースをセットアップします。各スタックセットには、アカウント StackInstances に対応する と、アカウント AWS リージョン ごとに に対応する があります。 AWSControl Tower は、アカウントとリージョンごとに 1 つのスタックセットインスタンスをデプロイします。

AWS Control Tower は、 AWS CloudFormation パラメータに基づいて、特定のアカウントと AWS リージョン に更新を適用します。更新が一部のスタックインスタンスに適用されると、他のスタックインスタンスが OUTDATED ステータスのままになることがあります。これは想定内の正常な動作です。

スタックインスタンスが OUTDATED 状態になった場合は通常、そのスタックインスタンスに対応するスタックがスタックセットの最新のテンプレートと合致していないことになります。スタックは古いテンプレートに残っているため、最新のリソースやパラメータが含まれていない可能性があります。スタックはまだ完全に使用可能です。

更新時に指定された AWS CloudFormation パラメータに基づいて、想定される動作を簡単にまとめます。

スタックセットの更新にテンプレートへの変更が含まれている場合 (つまり、 TemplateBodyまたは TemplateURLプロパティが指定されている場合)、または Parametersプロパティが指定されている場合、 は、指定されたアカウントおよび のスタックインスタンスを更新する前に、すべてのスタックインスタンスのステータスを「期限切れ」として AWS CloudFormation マークします AWS リージョン。スタックセットの更新にテンプレートまたはパラメータの変更が含まれていない場合、 は、他のすべてのスタックインスタンスを既存のスタックインスタンスのステータスのままにしながら、指定されたアカウントとリージョンのスタックインスタンス AWS CloudFormation を更新します。スタックセットに関連付けられたすべてのスタックインスタンスを更新するには、Accounts プロパティまたは Regions プロパティを指定しないでください。

詳細については、「 AWS CloudFormation ユーザーガイド」の「スタックセットの更新」を参照してください。