OU 設計: フェーズ 1

この例では、多国間医薬品会社の場合、 における組織と OUs の初期設計は、セットアップに関する AWS 推奨事項に AWS Organizations 厳密に従っていました AWS Control Tower。例については、ブログ記事「Best Practices for Organizational Units with AWS Organizations, including the Security OU, the Platform Infrastructure OU, and company-specific OUs」で説明されているように、「Landing Zone Accelerator on AWS for healthcare. AWS Control Tower initially provisioned a simple OU structure with common foundational OUs」を参照してください。

アーキテクチャの設計

次の図は、最初の OU アーキテクチャを示しています。

セキュリティ OU

セキュリティ OU は、セキュリティ機能 AWS アカウント に関連する広範なグループをまとめ、2 つのアカウント (監査とログアーカイブ) を使用して、環境への中央ログ記録と監査アクセスのためのセキュリティ運用データを保存します。Amazon GuardDuty や などの AWS コアセキュリティサービスは、監査アカウント AWS Security Hub にあります。

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

インフラストラクチャプラットフォーム OU は、インフラストラクチャ基盤 AWS アカウント を提供する OU をグループ化します。この OU 内に最初にデプロイされたのは、中央ネットワークコンポーネント (ゲートウェイ、ファイアウォール、中央ネットワークハブ、および同様のサービス) AWS アカウント の です。 

追加の OUs

その他の企業固有の OUs (臨床 OU など) は、低レベル階層内の基本的な OUs を強化します。ワークロードは、マルチアカウント構造と、それらの OUs。

この初期設計は、いくつかの考慮事項によって推進されました。

• ネストされた OUs でその時点で使用できず AWS Control Tower 、広範なカスタマイズが必要でした。

• クラウド用に指定された初期ワークロードは、臨床トライアルや製造機器分析 (機能面) など、会社の特定の側面に焦点を当てています。

• 同社は、5 つのワークロード環境 (開発、検証、統合、トレーニング、本番稼働) を区別しています。同社は、本番環境のワークロードに必要な AWS コントロールによる厳格なガバナンスなしでアプリケーションを開発するためのプレイグラウンドを必要としていました。この目的のために、Manufacturing-Dev OUs などの開発 OU が割り当てられました。

• ワークロードの自動化は各アプリケーションのエコシステムの一部であり、分離を必要としませんでした。

• インフラストラクチャ認定 (IQ) と GxP コンプライアンスプロセスでは、OU レベルで AWS コントロールを区別する必要がありませんでした。