[レポート] SCPの自動デプロイワークフローのCode Talk – 全社的なクラウド・ガバナンスのためのスケーラブルなSCP戦略の設計 #IAM343 #AWSreInforce

あしざわです。

米国フィラデルフィアで開催されている AWS re:Inforce 2024 に参加しています。

本記事は AWS re:Inforce 2024 のCode Talk 「Design a scalable SCP strategy for enterprise-wide cloud governance」のレポートです。

セッション概要

Do you want to optimize your organization’s security and operational efficiency on AWS? Join this code talk to learn about a reference architecture for managing and tracking service control policies (SCPs) across an organization’s multi-account environment. The talk features a live demo showcasing the design, implementation, and effective management of SCPs aligned with recommended AWS best practices. Gain insights about essential SCPs that can help you protect AI/ML workloads and your overall AWS environment. The talk also covers implementation best practices and guidance for deploying and managing the architecture using infrastructure as code (AWS CloudFormation and Terraform) through a CI/CD pipeline.

前提

今回紹介するアーキテクチャがCDKを利用してデプロイされるサンプルコードが、以下のGitHubリポジトリのaws-sampleから公開されています。

ここから紹介するセッションの概要もサンプルのリンクを参照しながら進めます。

構成図

今回のセッションで紹介されていたアーキテクチャの構成図はこちらです(aws-sampleリポジトリより引用)

構成図の解説

前提として、事前にすべてのSCPのステートメントがソースリポジトリに格納してあり、そのSCPはTerraformテンプレートからデプロイされています。

CodePipelineを利用した以下の流れのデプロイフローが定義されています。

1. ソースリポジトリ上のSCPステートメントの変更
2. デプロイされるTerraformテンプレートのチェック
3. IAM Access AnalyzerによるSCPポリシーステートメントのチェック
4. 人間によるレビュープロセス
5. デプロイ & 構成変更

ここからそれぞれのパイプライン内の処理について説明します。全体の流れの詳細はSCP_Management_Pipeline/pipeline.pyファイルも合わせて参考にご覧ください。

1. ソースリポジトリ上のSCPステートメントの変更

ソースコードリポジトリにあるSCPファイルが変更されると、CodeCommitで定義されたCICDパイプラインが実行されます。

サンプルでは、SCPはInfrastructureOU/MultiOU/RootOUの3パターンが定義されており、以下図のようにSCPが設定されているようです。

また、構成図上はソースリポジトリとしてGitHubと書かれていますが、CDKでデプロイされるアーキテクチャではCodeCommitが利用されていました。GitHubを利用したい場合はサンプルから少し手を加える必要がありそうです。

• 参考: SCP_Management_Pipeline/devtools.py

2. デプロイされるTerraformテンプレートのチェック

CodeBuild上でTerraform実行環境が構築され、デプロイされるSCPのテンプレートが正しいかどうかがチェックされます。

ここでは、terraform validateとterraform planのコマンドがチェックで利用されています。

• 参考: SCP_Management_Pipeline/terraformbuild_buildspec.yaml

3. IAM Access AnalyzerによるSCPポリシーステートメントのチェック

このフェーズでは、設定したSCPを検証するためのアクセス解析が行われます。アクセス解析はIAM Access Analyzerを使って行われています。

IAM Access Analyzerによるチェックをサポートするツールとして、terraform-iam-policy-validatorが利用されています。

このツールを使うと、TerraformテンプレートからIAMアイデンティティポリシー・リソースベースポリシーを解析し、IAM Access Analyzerを使ったポリシーチェックが実行されます。

• 参考: SCP_Management_Pipeline/access_analyzer_checks_buildspec.yaml

検証の結果はブロック・非ブロックのステータスで確認でき、重大なエラーにつながるブロック検知した際はパイプラインが中断されます。

このチェックにより、SCPに記載したポリシーの構文チェック、ポリシーアクションの重複確認、その他ポリシーステートメントの詳細の構文チェックが実行できます。

チェック結果に問題がなければ、CodeCommitの

4. 人間による承認プロセス

CodeCommitのプルリクエストの承認のためのリンクが、SNS経由でメール通知されます。

デモではデプロイから承認まで1人でやっていましたが、もちろん本来は複数人によるレビューのための仕組みです。

5. デプロイ & 構成変更

プルリクエストが承認されると、それをトリガーにEventBridge経由でterraform applyを実行するLambda関数が実行され、SCPのデプロイが行われます。

• 参考: SCP_Management_Pipeline/terraform_apply_buildspec.yaml

注意点

このプロセスが実現するのはあくまでコードの実行時エラーの確認とSCPの自動設定であり、そのSCPが本当に設定すべきものなのかチェックするものではありません。

前提となるインプットとして、以下のようなSCPのベストプラクティスが紹介されていました。

1. SCPはセキュリティ影響が大きく優先度が高いもののみを設定する
2. SCPステートメントの文字数を節約する
   • 不要な記載、重複を避ける
   • ワイルドカード(*)を利用する
   • Actionを多用する際は、NotActionを使ってみる
3. カスタムSCPではなくAWSマネージドポリシーで代用する
4. SCPを論理的にカテゴライズする
   • 例） Security Baseline、Infrastructure Baseline、Data Baseline、Account Baseline
5. SCPデプロイ時の自動チェック
6. SCPのデプロイ時の既存SCPとのコンフリクトの検知

...etc

SCPベストプラクティスについては以下のAWS公式ブログがソースになっていそうです。

• マルチアカウント環境における AWS Organizations サービスコントロールポリシーのベストプラクティス | AWS for Industries
• マルチアカウント環境でサービス制御ポリシーを最大限に活用する | AWS セキュリティブログ

5,6はコードで作成されるデプロイ自動化のアーキテクチャで解決できそうですが、1-4はそもそもどんなSCPを書く必要があるのかという基本かつ重要なことで自動化できないところなので、こういった考えのインプットがとても大切ですね。

まとめ

以上、「Design a scalable SCP strategy for enterprise-wide cloud governance」のレポートでした。

本セッションでは、大規模なOrganizations組織におけるSCPを管理・拡張を自動化させるためのアーキテクチャの解説が行われました。

アーキテクチャをデプロイするコードの説明が中心のセッションでしたが、個人的には周辺知識として紹介されたSCPのベストプラクティスがかなりためになりました。SCPを設計する時にベストプラクティスの存在を知っておくだけでもためになりそうです。

セッション内容が気になった方は、ぜひこちらのaws-sampleをご自身の環境でお試しください。

以上です。