OU 設計: フェーズ 2

この例に登場する製薬企業は、認証済みの本稼働ワークロードを既存の OU にデプロイすることで、新たなクラウド成熟フェーズへの移行を加速させました。これにより初期設計のレビューが開始され、規制された AWS ランディングゾーンに移行するワークロードが増えるにつれて、フェーズ 1 の構造に問題が生じることとなりました。

以下の新しい要件とインサイトが重要になりました。

• 同社ではデータ共有モデルのワークロードを実装していたため、臨床や製造といった個別の OU に割り当てることができないようアプリケーションに多目的性を持たせました。

• 認定 (特に継続的な認定) が、多くのワークロードの重要な側面となりました。セキュリティのベストプラクティスをより簡単に遵守できるよう、これらのワークロードを運用プロセスに統合する必要がありました。認定を受けたワークロードには、フェーズ 1 の OU レベルで設定された、より厳格な AWS による制御が必要でした。

• ネストされた OU 機能が AWS Control Tower で利用可能になりました。

• スキルの向上と経験により、ワークロードに関連する特定のポリシーについて、よりよく理解できるようになりました。

• 会社は、責任のアラインメントに基づく運用モデルを定義し、これに合意しました。

• ワークロードのセグメンテーションと構造のブループリントが成熟し、ワークロードの移行に導入されました。

その結果、フェーズ 2 およびその新しい構造へと移行された AWS アカウントでは新しい設計が実装されました。この新しい構造には、以下のセクションに記載された OU が含まれます。

アーキテクチャの設計

次の図は、フェーズ 2 の OU アーキテクチャを示しています。

セキュリティ OU

セキュリティ OU には、セキュリティ機能に広く関連する AWS アカウントが含まれ、2 つのアカウント (監査とログアーカイブ) を使用して一元的なログ記録と環境への監査アクセスのためにセキュリティ運用データを保存します。Amazon GuardDuty や AWS Security Hub CSPM などの AWS コアセキュリティサービスは、監査アカウントにあります。この OU は元の設計から変更されません。

インフラストラクチャプラットフォーム OU

インフラストラクチャプラットフォーム OU には、AWS Landing Zone 全体のネットワークや共有オートメーションなど、基盤となるインフラストラクチャアカウントが含まれています。この OU は元の設計から変更されません。

認定 OU

認定 OU には、厳格な変更管理、認定、検証などの認定インフラストラクチャを必要とするワークロードが含まれています。

非認定 OU

非認定 OU には、GxP 要件がないか、ビジネスクリティカルではないワークロードが含まれています。

オートメーション OU

オートメーション OU には、インフラストラクチャ管理のための継続的インテグレーションや継続的デリバリー (CI/CD) パイプラインなど、ワークロードの自動化に対応する共有リソースが含まれています。要件に応じて、オートメーションは環境間で分割することも、単一の AWS アカウントでホストすることもできます。

例外 OU

例外 OU には、特別な処理を必要とするワークロードが含まれており、それ以外のワークロードはポリシーによって阻止されます。例えば、広くアクセス可能で読み取り可能な Amazon Simple Storage Service (Amazon S3) バケットは例外 OU に該当します。

グレイブヤード OU

グレイブヤード OU には、削除されるワークロードの AWS アカウントが含まれます。これらのアカウントのポリシーは、アカウントの有効期限が切れるか削除されるまで、効果的でシンプルな管理アクセスのために削除する必要があります。