AWS CodePipeline と Amazon Bedrock を使用して AWS Organizations ポリシーをコードとして管理する - AWS 規範ガイダンス

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

AWS CodePipeline と Amazon Bedrock を使用して AWS Organizations ポリシーをコードとして管理する

Amazon Web Services、Andre Cavalcante および Mariana Pessoa de Queiroz

概要

認可ポリシーを使用して AWS Organizations 、メンバーアカウントのプリンシパルとリソースのアクセスを一元的に設定および管理できます。サービスコントロールポリシー (SCPs、組織内の AWS Identity and Access Management (IAM) ロールとユーザーに使用可能なアクセス許可の最大数を定義します。リソースコントロールポリシー (RCP) は、組織内のリソースで利用できるアクセス許可の上限を定義します。

このパターンは、継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを通じてデプロイする Infrastructure as Code (IaC) として SCP と RCP を管理するのに役立ちます。 AWS CloudFormation または Hashicorp Terraform を使用してこれらのポリシーを管理することで、複数の認可ポリシーの構築と維持に関連する負担を軽減できます。

このパターンには、次の機能が含まれます。

  • マニフェストファイル (scp-management.json および rcp-management.json) を使用して、認可ポリシーを作成、削除、更新します。

  • ポリシーの代わりにガードレールを使用します。ガードレールとそれらのターゲットはマニフェストファイルで定義します。

  • AWS CodeBuild と を使用するパイプラインは AWS CodePipeline、マニフェストファイルのガードレールをマージして最適化します。マニフェストファイル内の各ステートメントについて、パイプラインはガードレールを単一の SCP または RCP にマージし、定義されたターゲットに適用します。

  • AWS Organizations はターゲットにポリシーを適用します。ターゲットは AWS アカウント、、組織単位 (OU)、環境 ( environments.json ファイルで定義したアカウントのグループまたは OUs)、またはAWS タグを共有するアカウントのグループです。

  • Amazon Bedrock はパイプラインログを読み取り、すべてのポリシーの変更を要約します。

  • パイプラインには、手動承認が必要です。承認者は、Amazon Bedrock が作成したエグゼクティブサマリーを確認でき、エグゼクティブサマリーは変更内容を理解するのに役立ちます。

前提条件と制限

前提条件

制限事項

  • このパターンを使用して、この CI/CD パイプラインの外部で作成された SCP または RCP を管理することはできません。ただし、パイプラインを通じて既存のポリシーを再作成することはできます。詳細については、このパターンの「追加情報」セクションの「既存のポリシーをパイプラインに移行する」を参照してください。

  • 各アカウントのアカウント、OU、ポリシーの数には、 AWS Organizationsのクォータとサービス制限が適用されます。

  • このパターンは、バックアップポリシー AWS Organizations、タグポリシー、チャットアプリケーションポリシー、宣言ポリシーなど、 の管理ポリシーの設定には使用できません。

アーキテクチャ

以下の図は、ポリシー管理パイプラインとその関連リソースのワークフローを示しています。

ポリシー管理パイプラインを通じた SCP と RCP のリリース。

この図表は、次のワークフローを示しています:

  1. ユーザーは、リモートリポジトリのメインブランチにある scp-management.json または rcp-management.json マニフェストファイルに変更をコミットします。

  2. main ブランチの変更により、パイプラインが開始されます AWS CodePipeline。

  3. CodePipeline は Validate-Plan CodeBuild プロジェクトを開始します。このプロジェクトでは、リモートリポジトリ内の Python スクリプトを使用して、ポリシーとポリシーマニフェストファイルを検証します。この CodeBuild プロジェクトでは、以下を行います。

    1. SCP と RCP のマニフェストファイルに一意のステートメント ID (Sid) が含まれていることを確認します。

    2. scp-policy-processor/main.pyrcp-policy-processor/main.py の Python スクリプトを使用して、ガードレールフォルダ内のガードレールを単一の RCP または SCP ポリシーに連結します。同じ ResourceAction、および Condition を持つガードレールを組み合わせます。

    3. AWS Identity and Access Management Access Analyzer を使用して、最終的な最適化されたポリシーを検証します。検出結果がある場合、パイプラインは停止します。

    4. Terraform がリソースの作成に使用する scps.json ファイルと rcps.json ファイルを作成します。

    5. Terraform 実行プランを作成する、terraform plan コマンドを実行します。

  4. (オプション) Validate-Plan CodeBuild プロジェクトは、bedrock-prompt/prompt.py スクリプトを使用して Amazon Bedrock にプロンプトを送信します。bedrock-prompt/prompt.txt ファイルでプロンプトを定義します。Amazon Bedrock は、Terraform ログと Python ログを分析することで、Anthropic Claude Sonnet 3.5 を使用して、提案された変更の概要を生成します。

  5. CodePipeline は、変更を確認する必要があることを承認者に通知するために、Amazon Simple Notification Service (Amazon SNS) トピックを使用します。Amazon Bedrock によって変更の概要が生成された場合、通知にはこの概要が含まれます。

  6. ポリシー承認者は、CodePipeline でアクションを承認します。Amazon Bedrock によって変更の概要が生成された場合、承認者は承認する前に CodePipeline で概要を確認できます。

  7. CodePipeline は Apply CodeBuild プロジェクトを開始します。このプロジェクトでは、Terraform を使用して RCP と SCP の変更を適用します AWS Organizations。

このアーキテクチャに関連付けられた IaC テンプレートは、ポリシー管理パイプラインをサポートする次のリソースもデプロイします。

  • scp-policy-processor/main.pybedrock-prompt/prompt.py などの CodePipeline アーティファクトとスクリプトを保存するための Amazon S3 バケット

  • このソリューションによって作成されたリソースを暗号化する AWS Key Management Service (AWS KMS) キー

ツール

AWS のサービス

  • Amazon Bedrock は、多くの高パフォーマンスな基盤モデルを、統合 API を通じて利用できるようにする完全マネージド型 AI サービスです。

  • AWS CodeBuild は完全マネージド型の構築サービスです。ソースコードのコンパイル、ユニットテストの実行、すぐにデプロイできるアーティファクトの生成を行います。 

  • AWS CodePipeline は、ソフトウェアリリースのさまざまな段階を迅速にモデル化および設定し、ソフトウェアの変更を継続的にリリースするために必要なステップを自動化するのに役立ちます。

  • AWS Organizations は、作成して一元管理する AWS アカウント 組織に複数の を統合するのに役立つアカウント管理サービスです。

  • AWS SDK for Python (Boto3) は、Python アプリケーション、ライブラリ、またはスクリプトを と統合するのに役立つソフトウェア開発キットです AWS のサービス。

  • Amazon Simple Storage Service (Amazon S3) は、あらゆる量のデータを保存、保護、取得できるクラウドベースのオブジェクトストレージサービスです。

その他のツール

  • HashiCorp Terraform は、コードを使用してクラウドインフラストラクチャとリソースをプロビジョニングして管理するのに役立つ IaC ツールです。

コードリポジトリ

このパターンのコードは organizations-policy-pipeline GitHub リポジトリで利用できます。sample-repository フォルダに含まれるキーファイルは次のとおりです。

  • environments フォルダ内の environments.json には環境のリストが含まれます。環境はターゲットのグループであり、 AWS アカウント IDsまたは組織単位 (OUsを含めることができます。

  • rcp-management フォルダ内:

    • guardrails フォルダには、RCP の個々のガードレールが含まれます。

    • policies フォルダには、個々の RCP が含まれます。

    • rcp-management.json マニフェストファイルは、RCP ガードレール、完全な RCP、およびそれらの関連ターゲットを管理するのに役立ちます。

  • scp-management フォルダ内:

    • guardrails フォルダには、SCP の個々のガードレールが含まれます。

    • policies フォルダには、個々の SCP が含まれます。

    • scp-management.json マニフェストファイルは、SCP ガードレール、完全な SCP、およびそれらの関連ターゲットを管理するのに役立ちます。

  • utils フォルダには、現在の SCP と RCP の移行に役立つスクリプトが含まれ、これにより、パイプラインを通じて SCP と RCP を管理できるようになります。詳細については、このパターンの「追加情報」セクションを参照してください。

ベストプラクティス

  • パイプラインを設定する前に、 AWS Organizations クォータの制限に達していないことを確認することをお勧めします。

  • AWS Organizations 管理アカウントは、そのアカウントで実行する必要があるタスクにのみ使用することをお勧めします。詳細については、「管理アカウントのベストプラクティス」を参照してください。

エピック

タスク説明必要なスキル

リポジトリを作成します。

セキュリティ運用チームがポリシーを管理するためのリポジトリを作成します。 AWS CodeConnections がサポートするサードパーティーのリポジトリプロバイダーのいずれかを使用します。

DevOps エンジニア

ポリシー管理を委任します。

パイプラインをデプロイするメンバーアカウントに AWS Organizations ポリシーの管理を委任します。手順については、「 を使用してリソースベースの委任ポリシーを作成する AWS Organizations」を参照してください。サンプルポリシーについては、このパターンの「追加情報」セクションの「リソースベースの委任ポリシーのサンプル」を参照してください。

AWS 管理者

(オプション) 基盤モデルを有効にします。

ポリシーの変更の概要を生成する場合は、パイプラインをデプロイ AWS アカウント する の Amazon Bedrock で Anthropic Claude 3.5 Sonnet 基盤モデルへのアクセスを有効にします。手順については、「Add or remove access to Amazon Bedrock foundation models」を参照してください。

AWS 全般
タスク説明必要なスキル

リポジトリのクローン作成

GitHub から organizations-policy-pipeline リポジトリをクローンするには、次のコマンドを入力します。

git clone https://github.com/aws-samples/organizations-policy-pipeline.git

DevOps エンジニア

デプロイ方法を定義します。

  1. クローンしたリポジトリで variables.tf ファイルを開きます。

  2. project_name には、デプロイされたリソースの名前に適用するプレフィックスを入力します。

  3. provider_type には、リモートリポジトリのプロバイダーを入力します。有効な値がファイルで指定されます。

  4. full_repository_name には、リモートリポジトリの名前を入力します。

  5. branch_name には、ポリシーをデプロイするために使用する Git ブランチの名前を入力します。このブランチでのプッシュまたはマージによりパイプラインが開始されます。通常、これはメインブランチとなります。

  6. terraform_version には、使用している Terraform のバージョンを入力します。

  7. Amazon Bedrock で変更を要約する場合、enable_bedrock には、true を入力します。変更の概要を生成しない場合は、false を入力します。

  8. tags には、デプロイされたリソースにタグとして割り当てるキーと値のペアを入力します。

  9. variables.tf ファイルを保存して閉じます。

DevOps エンジニア

パイプラインをデプロイします。

  1. プランを作成して、変更を確認するには、次のコマンドを入力します。

    terraform plan
  2. プランを適用して、パイプラインインフラストラクチャを作成するには、次のコマンドを入力します。

    terraform apply
DevOps エンジニア、Terraform

リモートリポジトリを接続します。

前の手順では、Terraform によってサードパーティーリポジトリへの CodeConnections 接続が作成されました。AWS デベロッパーツールコンソールで、接続のステータスを PENDING から AVAILABLE に変更します。手順については、「保留中の接続の更新」を参照してください。

AWS DevOps

Amazon SNS トピックを購読します。

Terraform によって Amazon SNS トピックが作成されました。トピックにエンドポイントをサブスクライブし、サブスクリプションを確認して、承認者がパイプライン内の保留中の承認アクションに関する通知を受け取るようにします。手順については、「Amazon SNS トピックのサブスクリプションの作成」を参照してください。

AWS 全般
タスク説明必要なスキル

リモートリポジトリに入力します。

クローンされたリポジトリから、sample-repository フォルダの内容をリモートリポジトリにコピーします。これには environmentsrcp-managementscp-managementutils フォルダが含まれます。

DevOps エンジニア

環境を定義します。

  1. environments フォルダで、environments.json ファイルを開きます。これは、RCPs AWS アカウント と SCP のターゲットと OUs を定義するファイルです。 SCPs

  2. 環境の例を削除します。

  3. 次の形式でターゲット環境を追加します。

    [ { "ID": "<environment-name>", "Target": [ "<ou-name>:<ou-id>", "<account-name>:<account-id>" ] } ]

    コードの説明は以下のとおりです。

    • <environment-name> は、OU と AWS アカウントのグループに割り当てる名前です。マニフェストファイルでこの名前を使用すると、ポリシーを適用する場所を定義できます。

    • <ou-name> はターゲット OU の名前です。

    • <ou-id> はターゲット OU の ID です。

    • <account-name> はターゲットの名前です AWS アカウント。

    • <account-id> はターゲットの ID です AWS アカウント。

    例については、「ソースコードリポジトリ」を参照してください。

  4. environments.json ファイルを保存して閉じます。

DevOps エンジニア

ガードレールを定義します。

  1. リモートリポジトリの rcp-management/guardrails フォルダに移動します。これは、RCP マニフェストファイルのガードレールを定義するフォルダです。各ガードレールは個別のファイルに含まれている必要があります。ガードレールファイルには、1 つ以上のステートメントを含めることができます。

    注記

    SCP と RCP のマニフェストファイル内で複数のステートメントに同じガードレールを使用できます。ガードレールを変更すると、このガードレールを含むすべてのポリシーが影響を受けます。

  2. ソースコードリポジトリからコピーされたガードレールの例をすべて削除します。

  3. 新しい .json ファイルを作成し、わかりやすい名前を付けます。

  4. 作成した .json ファイルを開きます。

  5. 次の形式でガードレールを定義します。

    [ { "Sid": "<guardrail-name>", "Effect": "<effect-value>", "Action": [ "<action-name>" ], "Resource": "<resource-arn>", "Condition": { "<condition-operator>": { "<condition-key>": [ "<condition-value>" ] } } } ]

    コードの説明は以下のとおりです。

    • <guardrail-name> はガードレールの一意の名前です。この名前は他のガードレールには使用できません。

    • <effect-value> には、Allow または Deny を指定する必要があります。詳細については、「影響」を参照してください。

    • <action-name> は、サービスがサポートするアクションの有効な名前である必要があります。詳細については、「アクション」を参照してください。

    • <resource-arn> は、ガードレールが適用されるリソースの Amazon リソースネーム (ARN) です。*? などのワイルドカード文字を使用することもできます。詳細については、「リソース」を参照してください。

    • <condition-operator> は、有効な条件演算子です。詳細については、「条件演算子」を参照してください。

    • <condition-key> は、有効なグローバル条件コンテキストキーまたはサービス固有のコンテキストキーです。詳細については、「条件」を参照してください。

    • <condition-value> は、ガードレールが適用されるかどうかを評価するための条件で使用される特定の値です。詳細については、「条件」を参照してください。

    RCP ガードレールの例については、「ソースコードリポジトリ」を参照してください。

  6. .json ファイルを保存して閉じます。

  7. これらのステップを繰り返して、必要な数の RCP ガードレールを作成します。

  8. scp-management/guardrails フォルダ内でこれらのステップを繰り返して、SCP に必要な数のガードレールを作成します。SCP ガードレールの例については、「ソースコードリポジトリ」を参照してください。

DevOps エンジニア

ポリシーを定義します。

  1. リモートリポジトリの rcp-management/policies フォルダに移動します。これは、RCP マニフェストファイルの完全なポリシーを定義するフォルダです。各ポリシーは、個別のファイルである必要があります。

    注記

    このフォルダ内のポリシーを変更すると、マニフェストファイルで定義されているように、このポリシーが適用されているすべてのアカウントまたは OU にポリシーの変更が影響します。

  2. ソースコードリポジトリからコピーされたポリシーの例をすべて削除します。

  3. 新しい .json ファイルを作成し、わかりやすい名前を付けます。

  4. 作成した .json ファイルを開きます。

  5. RCP を定義します。RCPs「リソースコントロールポリシーの例」を参照してください。 https://github.com/aws-samples/organizations-policy-pipeline/tree/main/sample-repository/rcp-management/policies AWS Organizations

  6. .json ファイルを保存して閉じます。

  7. これらのステップを繰り返して、必要な数の RCP を作成します。

  8. scp-management/policies フォルダ内でこれらのステップを繰り返して、必要な数の SCP を作成します。SCPs「サービスコントロールポリシーの例」を参照してください。 https://github.com/aws-samples/organizations-policy-pipeline/tree/main/sample-repository/scp-management/policies AWS Organizations

DevOps エンジニア
タスク説明必要なスキル

マニフェストファイルを設定します。

  1. rcp-management フォルダで、rcp-management.json ファイルを開きます。これは、ターゲット環境に適用する RCP ガードレールと完全な RCP を定義するファイルです。このファイルの例については、「ソースコードリポジトリ」を参照してください。

  2. ステートメントの例を削除します。

  3. 次の形式で新しいステートメントを追加します。

    [ { "SID": "<statement-name>", "Target": { "Type": "<target-type>", "ID": "<target-name>" }, "Guardrails": [ "<guardrail-name>" ], "Policy": "<policy-name>", "Comments": "<comment-text>" } ]

    コードの説明は以下のとおりです。

    • <statement-name> は、ステートメントの一意の名前です。

    • <target-type> は、ポリシーを適用するターゲットのタイプです。有効な値は AccountOUEnvironment、または Tag です。

    • <target-name> は、ポリシーを適用するターゲットの識別子です。次のいずれかを入力します。

      • には AWS アカウント、識別子を として入力します<account-name>:<account-id>

      • OU の場合、<OU-name>:<ou-id> として識別子を入力します。

      • 環境の場合、environments.json ファイルで定義した一意の名前を入力します。

      • タグの場合、<tag-key>:<tag-value> としてキーと値のペアを入力します。

    • <guardrail-name> は、rcp-management/guardrails フォルダで定義した RCP ガードレールの一意の名前です。この要素には、複数のガードレールを追加できます。ガードレールを適用しない場合は、このフィールドを空のままにしておくことができます。

    • <policy-name> は、rcp-management/policies フォルダで定義した RCP の一意の名前です。この要素にはポリシーを 1 つだけ追加できます。ポリシーを適用しない場合は、このフィールドを空のままにしておくことができます。

    • <comment-text> は、文書化の目的で入力できる説明です。このフィールドはパイプライン処理中には使用されません。コメントを追加しない場合は、このフィールドを空のままにしておくことができます。

  4. これらのステップを繰り返して、組織の RCP を設定するために必要な数のステートメントを追加します。

  5. rcp-management.json ファイルを保存して閉じます。

  6. scp-management フォルダ内の scp-management.json ファイルで、これらのステップを繰り返します。これは、ターゲット環境に適用する SCP ガードレールと完全な SCP を定義するファイルです。このファイルの例については、「ソースコードリポジトリ」を参照してください。

DevOps エンジニア

パイプラインを開始します。

variables.tf ファイルで定義したリモートリポジトリのブランチに変更をコミットしてプッシュします。通常、これは main ブランチとなります。CI/CD パイプラインが自動的に開始されます。パイプラインエラーがある場合は、このパターンの「トラブルシューティング」セクションを参照してください。

DevOps エンジニア

変更を承認します。

Validate-Plan CodeBuild プロジェクトが完了すると、ポリシー承認者は、以前に設定した Amazon SNS トピックを通じて通知を受け取ります。以下の操作を実行します。

  1. 通知メッセージを開きます。

  2. 可能な場合は、ポリシー変更の概要を確認します。

  3. CodePipeline で承認アクションを承認または拒否する」の手順に従います。

AWS 全般、ポリシー承認者

デプロイを検証する。

  1. AWS Organizationsの委任管理者アカウントで AWS Organizations コンソールにサインインします。

  2. [サービスコントロールポリシー] ページで、作成した SCP が一覧表示されていることを確認します。

  3. パイプラインを通じて管理される SCP を選択し、それが目的のターゲットに適用されることを確認します。

  4. [リソースコントロールポリシー] ページで、作成した RCP が一覧表示されていることを確認します。

  5. パイプラインを通じて管理される RCP を選択し、それが目的のターゲットに適用されることを確認します。

AWS 全般

トラブルシューティング

問題ソリューション

パイプラインの Validate-Plan フェーズでのマニフェストファイルエラー

scp-management.json または rcp-management.json ファイルにエラーがある場合、パイプライン出力に「Pipeline errors in the Validation & Plan phase for manifest files」というメッセージが表示されます。起こり得るエラーには、正しくない環境名、重複した SID、無効なフィールドや値などがあります。以下の操作を実行します。

  1. View build details in AWS CodeBuild」の手順に従います。

  2. ビルドログで、検証エラーを見つけます。エラーから、ビルドが失敗した原因に関する詳細情報を得られます。

  3. 対応する .json ファイルを更新します。

  4. リモートリポジトリに、更新されたファイルをコミットしてプッシュします。パイプラインが再起動します。

  5. ステータスをモニタリングして、検証エラーが解決されたことを確認します。

パイプラインの Validate-Plan フェーズでの IAM Access Analyzer の検出結果

ガードレールまたはポリシーの定義にエラーがある場合、パイプライン出力に「Findings in IAM Access Analyzer during Validation & Plan phase」というメッセージが表示されます。このパターンでは、IAM Access Analyzer を使用して最終的なポリシーを検証します。以下の操作を実行します。

  1. View build details in AWS CodeBuild」の手順に従います。

  2. ビルドログで、IAM Access Analyzer 検証エラーを見つけます。エラーから、ビルドが失敗した原因に関する詳細情報を得られます。検出結果タイプの詳細については、「IAM ポリシー検証チェックリファレンス」を参照してください。

  3. ガードレールまたはポリシーに対応する .json ファイルを更新します。

  4. リモートリポジトリに、更新されたファイルをコミットしてプッシュします。パイプラインが再起動します。

  5. ステータスをモニタリングして、検証エラーが解決されたことを確認します。

関連リソース

追加情報

リソースベースの委任ポリシーのサンプル

以下は、 のリソースベースの委任ポリシーの例です AWS Organizations。これにより、委任された管理者アカウントが組織の SSP と RCP を管理できるようになります。次のサンプルポリシーでは、ポリシー管理パイプラインをデプロイするアカウントの ID に <MEMBER_ACCOUNT_ID> を置き換えます。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DelegationToAudit", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::<MEMBER_ACCOUNT_ID>:root" }, "Action": [ "organizations:ListTargetsForPolicy", "organizations:CreatePolicy", "organizations:DeletePolicy", "organizations:AttachPolicy", "organizations:DetachPolicy", "organizations:DisablePolicyType", "organizations:EnablePolicyType", "organizations:UpdatePolicy", "organizations:DescribeEffectivePolicy", "organizations:DescribePolicy", "organizations:DescribeResourcePolicy" ], "Resource": "*" } ] }

既存のポリシーをパイプラインに移行する

このパイプラインを通じて移行および管理する既存の SCP または RCP がある場合は、コードリポジトリの sample-repository/utils フォルダにある Python スクリプトを使用できます。これらのスクリプトには、以下が含まれます。

  • check-if-scp-exists-in-env.py – このスクリプトは、environments.json ファイルで定義した特定の環境内の任意のターゲットに、指定されたポリシーが適用されるかどうかをチェックします。次のコマンドを入力して、このスクリプトを実行します。

    python3 check-if-scp-exists-in-env.py \ --policy-type <POLICY_TYPE> \ --policy-name <POLICY_NAME> \ --env-id <ENV_ID>

    このコマンドの次の部分を置き換えます。

    • <POLICY_TYPE>scp または rcp

    • <POLICY_NAME> は、SCP または RCP の名前です

    • <ENV_ID> は、environments.json ファイルで定義した環境の ID です

  • create-environments.py – このスクリプトは、環境内の現在の SCP と RCP に基づいて environment.json ファイルを作成します。を通じてデプロイされたポリシーは除外されます AWS Control Tower。次のコマンドを入力して、このスクリプトを実行します。ここで、<POLICY_TYPE>scp または rcp になります。

    python create-environments.py --policy-type <POLICY_TYPE>
  • verify-policies-capacity.py – このスクリプトは、定義した各環境をチェックして、各 AWS Organizations ポリシー関連のクォータに残っている容量を決定します。environments.json ファイルでチェックする環境を定義します。次のコマンドを入力して、このスクリプトを実行します。ここで、<POLICY_TYPE>scp または rcp になります。

    python verify-policies-capacity.py --policy-type <POLICY_TYPE>