Terraform を使用して AWS アクセス許可セットを動的に管理する

Vinicius Elias and Marcos Vinicius Pinto Jordao、Amazon Web Services

概要

AWS IAM Identity Center は、 AWS アカウント およびクラウドアプリケーションへのシングルサインオンアクセスを管理するための一元化されたハブを提供することで AWS Identity and Access Management (IAM) を強化します。ただし、IAM Identity Center アクセス許可セットの手動管理は、組織の成長に伴ってますます複雑になり、エラーが発生しやすくなります。この複雑さにより、セキュリティギャップや管理オーバーヘッドが発生する可能性があります。

このソリューションを使用すると、ネイティブで構築された継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインを使用して、Infrastructure as Code (IaC) を通じてアクセス許可セットを管理できます AWS のサービス。これにより、アクセス許可セットの割り当てメカニズムを AWS Control Tower ライフサイクルイベントまたは Account Factory for Terraform (AFT) 環境とシームレスに統合できます。このアプローチでは、新規と既存の ID の両方に動的な ID 設定を提供します AWS アカウント。

Amazon EventBridge ルールは AWS アカウント 作成と更新をモニタリングし、ID 設定を組織構造と同期させるのに役立ちます。 AWS Control Tower または AFT でアカウントを作成または更新すると、パイプラインがトリガーされます。アクセス許可セット定義と割り当てルールを含む一連の JSON ファイルを評価します。次に、パイプラインが適用され、すべてのアカウントで設定が同期されます。

このアプローチには、次の利点があります。

• 整合性 — AWS 組織全体の手動設定ドリフトを排除

• 監査可能性 – すべての ID 管理変更の完全な履歴を維持します。

• スケーラビリティ – AWS 環境の拡大に応じて設定を自動的に適用する

• セキュリティ – アクセス許可の割り当てにおけるヒューマンエラーを削減

• コンプライアンス — 文書化された変更と割り当てルールを通じて、規制要件への準拠を促進します

前提条件と制限

• AWS Control Tower と AWS Organizations がセットアップされたマルチアカウント環境。必要に応じて、 で AFT を使用できます AWS Control Tower。

• ソリューションを受け取る AWS アカウント IAM アイデンティティセンターの委任管理者。詳細については、IAM Identity Center ドキュメントの「委任された管理」を参照してください。

• メインコードを処理するバージョン管理システム (VCS) リポジトリ。サンプルについては、ソリューションの GitHub リポジトリを参照してください。

• Amazon Simple Storage Service (Amazon S3) バケットや Amazon DynamoDB テーブルなど、Terraform バックエンド管理に必要な AWS リソース。

制約事項

• パイプラインは AWS ネイティブリソースとオープンソースの Terraform を使用します。パイプラインは、サードパーティーのエコシステムを呼び出す準備ができていません。

• 一部の AWS のサービス は では使用できません AWS リージョン。リージョンの可用性については、AWS 「リージョン別のサービス」を参照してください。特定のエンドポイントについては、「サービスエンドポイントとクォータ」を参照して、サービスのリンクを選択します。

アーキテクチャ

次の図は、このパターンのコンポーネントとワークフローを示しています。

AWS Control Tower イベントフロー

このソリューションは、 AWS Control Tower または AFT からのイベントの統合から始まります。一方のサービスまたは他のサービスの選択は、変数定義を通じて実装時に行われます。使用する方法に関係なく、アカウントが作成または更新されるたびにパイプラインがトリガーされます。パイプラインは、アクセス許可セット管理リポジトリに保存されているポリシーを調整します。

AWS Control Tower ライフサイクルイベントは次のとおりです。

• CreateManagedAccount – 新しいアカウントが作成されたとき

• UpdateManagedAccount – 既存のアカウントが更新された場合

イベントルーティング

EventBridge は中央イベント処理サービスとして機能し、 AWS Control Tower アカウントで生成されたイベントをキャプチャします。イベントが発生すると、EventBridge はそれらをソリューションアカウントの一元化されたイベントバスにインテリジェントにルーティングします。 AWS Control Tower ライフサイクルイベントは、個別のルーティングパターンに従います。AFT がイベントソースとして定義されている場合、AFT 管理アカウントは AWS Control Tower アカウントではなくイベントを処理します。このイベント駆動型アーキテクチャにより、手動で介入することなく、組織の変更に自動的に対応できます。

AFT 統合プロセス

AWS Control Tower ライフサイクルイベントが AFT 管理アカウントに到達すると、AFT に組み込まれている複数のダウンストリームプロセスが自動的にトリガーされます。AFT アカウントのカスタマイズワークフローが完了すると、専用の aft-notifications Amazon Simple Notification Service (Amazon SNS) トピックにメッセージを発行します。このトピックでは、このソリューションで実装されている aft-new-account-forward-event AWS Lambda 関数をトリガーします。Lambda 関数は、パイプラインの開始に使用されるソリューションアカウントイベントバスにイベントを送信します。

コードパイプラインとしてのインフラストラクチャ

ソリューションパイプラインは、完全に自動化されたデプロイメカニズムとして機能します。 AWS CodePipeline サービスはリポジトリの変更を継続的にモニタリングします。新しいコミットを検出すると、デプロイワークフローが自動的に開始され、検証フェーズと実行フェーズを含むシーケンシャルプロセスが開始されます。システムは Terraform planオペレーションを実行して提案された変更を特定し、次に Terraform apply コマンドを実行してそれらの変更を AWS 環境に実装します。特に、パイプラインは手動の承認ゲートなしで実行されます。このアプローチにより、パイプラインログと Terraform 状態ファイルを通じて監査可能性を維持しながら、インフラストラクチャの変更を迅速にデプロイできます。

パイプラインは を活用して AWS CodeBuild 、適切なアクセス許可を持つ制御された環境で Terraform オペレーションを実行します。この IaC アプローチにより、パイプラインは次のような包括的なアクセス許可管理オペレーションを実行できます。

• 新しいアクセス許可セットを作成します。

• 既存のアクセス許可セットを更新します。

• 不要なアクセス許可セットを削除します。

• AWS 組織内のアカウントとグループ間でこれらのアクセス許可の割り当てを管理します。

インフラストラクチャの一貫性を維持し、競合する変更を防ぐために、このソリューションは Amazon S3 バケットと専用の Amazon DynamoDB テーブルを使用して Terraform バックエンド状態管理システムを実装します。このアプローチは、Terraform ステートファイルとステートロックメカニズムの永続的なストレージロケーションを提供し、同じリソースへの同時変更を防ぎます。

メインの Terraform コードは、公式 AWS permission-setsの Terraform モジュールを使用します。このモジュールは、アクセス許可セットテンプレートに基づいて、IAM Identity Center でアクセス許可セットを動的に管理できます。

ソースコントロール管理

アクセス許可セットテンプレート (JSON ファイル) は、ID 管理設定用の一元化されたリポジトリを提供する GitHub などの外部バージョン管理システムにあります。このアプローチは、標準のコードレビュープラクティスを通じて共同開発を可能にしながら、アクセス許可セット定義の信頼できる単一のソースを確立します。承認されたユーザーは、組織の変更管理プロセスに従って、これらのテンプレートに変更をコミットできます。これらのコミットは、自動デプロイパイプラインのプライマリトリガーとして機能し、インフラストラクチャの更新プロセスを開始します。

リポジトリの JSON ファイルを使用してアクセス許可セットを設定する方法の例については、「追加情報」を参照してください。

ツール

AWS のサービス

• AWS CodeBuild は、ソースコードのコンパイル、ユニットテストの実行、デプロイ可能なアーティファクトの生成に役立つフルマネージド型のビルドサービスです。

• AWS CodeConnections では、CodePipeline などの AWS リソースとサービスが GitHub などの外部コードリポジトリに接続できます。

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

• AWS Command Line Interface （AWS CLI） は、コマンドラインシェルのコマンド AWS のサービス を使用して を操作するのに役立つオープンソースツールです。

• AWS Control Tower は、規範的なベストプラクティスに従って、 AWS マルチアカウント環境のセットアップと管理に役立ちます。

• Amazon DynamoDB は、フルマネージド NoSQL データベースサービスです。高速かつ予測可能でスケーラブルなパフォーマンスを提供します。

• 「Amazon EventBridge」 は、アプリケーションをさまざまなソースのデータに接続するために支援するサーバーレスイベントバスサービスです。例えば、 AWS Lambda 関数、API 送信先を使用する HTTP 呼び出しエンドポイント、その他のイベントバスなどです AWS アカウント。

• AWS Identity and Access Management (IAM) は、誰を認証し、誰に使用を認可するかを制御することで、 AWS リソースへのアクセスを安全に管理するのに役立ちます。

• AWS IAM Identity Center を使用すると、すべての AWS アカウント およびクラウドアプリケーションへのシングルサインオン (SSO) アクセスを一元管理できます。

• AWS Lambda は、サーバーのプロビジョニングや管理を行うことなくコードを実行できるコンピューティングサービスです。必要に応じてコードを実行し、自動的にスケーリングするため、課金は実際に使用したコンピューティング時間に対してのみ発生します。

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

• 「Amazon Simple Notification Service (Amazon SNS)」は、ウェブサーバーやメールアドレスなど、パブリッシャーとクライアント間のメッセージの交換を調整および管理するのに役立ちます。これにより、アカウント管理イベントのプッシュ通知が可能になり、システム内の重要な変更やアクションが関係者に通知されます。

• Amazon Simple Storage Service (Amazon S3) は、どのようなデータ量であっても、データを保存、保護、取得することを支援するクラウドベースのオブジェクトストレージサービスです。

その他のツール

• 「Terraform」は、HashiCorpのinfrastructure as code (IaC) ツールで、クラウドとオンプレミスのリソースの作成と管理を支援します。

コードリポジトリ

このパターンのコードは、 AWS sample-terraform-aws-permission-sets-pipeline リポジトリの GitHub の Samples 組織で入手できます。 sample-terraform-aws-permission-sets-pipeline

ベストプラクティス

• 本番環境でコードを実行するために使用される Terraform モジュールとプロバイダーのバージョンを常にピン留めします。

• Checkov などの静的コード分析ツールを使用してコードをスキャンし、セキュリティの問題を解決します。

• 最小特権の原則に従い、タスクの実行に必要な最小限のアクセス許可を付与します。詳細については、IAM ドキュメントの「最小特権の付与」と「セキュリティのベストプラクティス」を参照してください。

エピック

前提条件を作成する (オプション）

タスク	説明	必要なスキル
Terraform バックエンドリソースを作成します。	Terraform バックエンド AWS リソースをまだ作成していない場合は、次の手順を使用して Amazon S3 バケット (s3-tf-backend-{ACCOUNT_ID}) と DynamoDB テーブル () を作成しますddb-tf-backend。 ソリューションをデプロイ AWS アカウント する にサインインし、 AWS Control Tower ホームAWS CloudShellで を開きます AWS リージョン。 次のコマンドを実行し、プレースホルダーを AWS アカウント ID {ACCOUNT_ID} に置き換えます。 aws s3api create-bucket --bucket s3-tf-backend-{ACCOUNT_ID} aws s3api put-bucket-versioning --bucket s3-tf-backend-{ACCOUNT_ID} --versioning-configuration Status=Enabled aws dynamodb create-table --table-name ddb-tf-backend --attribute-definitions AttributeName=LockID,AttributeType=S --key-schema AttributeName=LockID,KeyType=HASH --provisioned-throughput ReadCapacityUnits=1,WriteCapacityUnits=1	AWS 管理者
クロスアカウントロールを作成します。	Terraform AWS プロバイダー設定でクロスアカウント IAM event-source-account ロールを指定する必要があります。このロールをまだ作成していない場合は、次のステップを使用して作成します。 イベントソース (AWS Control Tower 管理アカウントまたは AFT アカウント) AWS アカウント となる にサインインし、開きます AWS CloudShell。 次のコマンドを実行し、プレースホルダーを現在の {ACCOUNT_ID} AWS アカウント ID ではなく、このソリューションに使用している AWS アカウント ID に置き換えます。 aws iam create-role \ --role-name CrossAccountRole \ --assume-role-policy-document '{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{ACCOUNT_ID}:root" }, "Action": "sts:AssumeRole" } ] }' コマンド出力を確認し、ロール Amazon リソースネーム (ARN) をコピーします (例: )arn:aws:iam::111122223333:role/CrossAccountRole。 IAM ポリシーをロールにアタッチするには、次のコマンドを実行します。 aws iam attach-role-policy \ --role-name CrossAccountRole \ --policy-arn arn:aws:iam::aws:policy/AdministratorAccess この例では、 AWS マネージド IAM ポリシー AdministratorAccess を使用します。必要に応じて、より具体的なポリシーを使用できます。	AWS 管理者

アクセス許可セットリポジトリを準備する

タスク	説明	必要なスキル
専用リポジトリを作成します。	このタスクは、GitHub を使用していることを前提としています。メインの Terraform コードとアクセス許可セットテンプレート JSON ファイルを保存する専用リポジトリを作成します。	DevOps エンジニア
アクセス許可セットコードを準備します。	次のファイルを構築する方法については、ソリューションリポジトリのサンプルコードを参照してください。 ├── main.tf ├── outputs.tf ├── providers.jinja └── テンプレート コンテンツをコピーし、providers.jinja値を保持して、他のファイルに必要な調整を行います。たとえば、アクセス許可セットテンプレートファイルを に追加するtemplatesか、 main.tf ファイルのaws-ia/permission-sets/awsモジュールバージョンを固定します。	DevOps エンジニア
変更をコミットします。	前に作成したリポジトリに変更をコミットしてプッシュします。リポジトリ名とその GitHub 組織を保存します。例: myorg/aws-ps-pipeline。	DevOps エンジニア

デプロイコードを準備する

タスク	説明	必要なスキル
コンテンツをダウンロードします。	ソリューションリポジトリからコンテンツをダウンロード (クローン) します。	DevOps エンジニア
変数を実行します。	terraform.tfvars ファイルを作成し、次の必要な変数を追加します。 repository_name – 前に作成したアクセス許可セットリポジトリの名前 branch_name – アクセス許可セットリポジトリブランチの名前 vcs_provider – VCS プロバイダー account_lifecycle_events_source – パイプライン (AWS Control Tower または AFT) をトリガーするイベントのソース repository_name = "myorg/aws-ps-pipeline" branch_name = "main" vcs_provider = "github" account_lifecycle_events_source = "CT" 追加の変数オプションの詳細については、このパターンの GitHub リポジトリにある variables.tf ファイルを参照してください。	DevOps エンジニア
Terraform バックエンド設定を調整します。	backend.tf ファイルで、プレースホルダーを独自の値に置き換えます。 AWS Control Tower ホームを使用し AWS リージョン、以前に作成した Amazon S3 バケットと DynamoDB テーブルの名前を指定します。 terraform { required_version = ">=1.6" backend "s3" { region = "{region}" bucket = "{bucket_name}" key = "terraform.tfstate" dynamodb_table = "{table_name}" encrypt = "true" } } 必要に応じて、独自の Terraform バックエンド設定を使用できます。	DevOps エンジニア
Terraform プロバイダーの設定を調整します。	providers.tf ファイルで、プレースホルダーを独自の情報に置き換えます。 AWS Control Tower ホームリージョンを使用して、以前に作成したevent-source-accountプロバイダーのクロスアカウント IAM ロールの ARN を指定します。 provider "aws" { region = "{region}" } provider "aws" { alias = "event-source-account" region = "{region}" assume_role { role_arn = "{role_arn}" } }	DevOps エンジニア

ソリューションを手動でデプロイする

タスク	説明	必要なスキル
を選択します AWS アカウント。	IAM Identity Center の委任管理者アカウントにソリューションをデプロイすることをお勧めします。ただし、 AWS Organizations 管理アカウントにデプロイすることもできます。 IAM Identity Center インスタンスと同じリージョンで選択したアカウントにサインインするには、 を使用します AWS CLI。使用している IAM ロールに、前のステップでevent-source-accountプロバイダーに指定されたロールを引き受けるアクセス許可があることを確認します。また、このロールは Terraform バックエンド設定で使用される AWS リソースにアクセスできる必要があります。	AWS 管理者
Terraform を手動で実行します。	設定を初期化、計画、適用するには、次の Terraform コマンドを次の順序で実行します。 terraform init terraform plan terraform apply	DevOps エンジニア
デプロイの結果を確認します。	IAM Identity Center の委任管理者アカウントで、aws-ps-pipelineパイプラインが作成されていることを確認します。また、保留中のステータス AWS CodeConnections の接続があることを確認します。	AWS DevOps
CodeConnections 設定を完了します。	CodeConnections 設定を完了するには、次の手順を実行します。 CodeConnections に移動し、作成された接続を選択し、保留中の接続の更新を選択します。 GitHub 認証情報を指定し、新しい GitHub アプリをインストールするか、アクセス許可セットリポジトリにアクセスできる既存のアプリを選択して、接続を選択します。 これで、パイプラインはアクセス許可セットリポジトリにアクセスできるはずです。 詳細な手順については、「 デベロッパーツールコンソールドキュメント」の「保留中の接続の更新」を参照してください。	AWS DevOps

パイプライン実行フローを選択してソリューションをテストする

タスク	説明	必要なスキル
パイプラインを AWS Control Tower または AFT 更新で実行します。	AWS Control Tower または AFT を使用してアカウントを作成または変更すると (選択したライフサイクルイベントのタイプに応じて）、パイプラインが開始されます。	AWS 管理者
コードを変更してパイプラインを実行します。	コードを変更してmainブランチにコミットすると、パイプラインが開始されます。	AWS DevOps
パイプラインを手動で実行します。	パイプラインを手動で開始するには、 のリリース変更機能を使用します AWS CodePipeline。	AWS DevOps

トラブルシューティング

問題	ソリューション
アクセスが拒否されました	ソリューションをデプロイするために必要なアクセス許可があることを確認します。
CodeConnections の問題	接続ステータスが保留中ではなく利用可能であることを確認します。 CodeConnections 設定が GitHub 認証情報で適切に完了していることを確認します。詳細については、「 デベロッパーツールコンソールドキュメント」の「保留中の接続の更新」を参照してください。 GitHub アプリに、アクセス許可セットリポジトリへの適切なアクセス許可があることを確認します。
パイプライン実行の問題	Amazon CloudWatch logsでパイプライン実行エラーを確認します。 IAM アイデンティティセンターの委任が正しく設定されていることを確認します。そうしないと、 AWS アカウント メタデータの読み取り時にパイプラインが失敗する可能性があります。
アクセス許可セットのデプロイの問題	アクセス許可セットテンプレートファイルの JSON 構文が正しいことを確認します。 テンプレートで参照されている IAM 管理ポリシーが存在することを確認します。 指定されたグループと割り当て内のユーザーが IAM Identity Center に存在するかどうかを確認します。

関連リソース

AWS のサービス ドキュメント

• AWS IAM Identity Center ユーザーガイド

• アクセス許可セット AWS アカウント を使用して を管理する (IAM Identity Center ドキュメント）

その他のリソース

• アクセスAWS 許可セットモジュール (Terraform)

追加情報

サンプルアクセス許可セットを含む JSON ファイル

次の例は、リポジトリ内の JSON ファイルを使用してアクセス許可セットを設定する方法を示しています。

{
  "Name": "ps-billing", // Permission set identifier
  "Comment": "Sample permission set for billing access", // Comment to document the purpose of the permission set
  "Description": "Billing access in AWS", // Detailed description
  "SessionDuration": "PT4H", // Session duration = 4 hours (ISO 8601 format)
  "ManagedPolicies": [ // List of AWS IAM managed policies
    "arn:aws:iam::aws:policy/job-function/Billing",
    "arn:aws:iam::aws:policy/job-function/SupportUser",
    "arn:aws:iam::aws:policy/AWSSupportAccess",
    "arn:aws:iam::aws:policy/job-function/ViewOnlyAccess"
  ],
  "CustomerPolicies": [], // References to IAM policies previously created
  "CustomPolicy": {}, // Inline IAM policy defined directly in the permission set
  "PermissionBoundary": {  // AWS or customer managed IAM policy to be used as boundary
    "ManagedPolicy": "",
    "CustomerPolicy": ""
  },
  "Assignments": [ // Define the assignment rules
    {
      "all_accounts": true, // Apply to ALL active AWS accounts in organization
      "principal": "G_BILLING_USERS", // Group/user name in Identity Center
      "type": "GROUP", // Can be "GROUP" or "USER"
      "account_id": [], // List of AWS account ID (empty since all_accounts=true)
      "account_ou": [], // List of AWS Organizational Unit IDs with target AWS accounts
      "account_tag": [] // List of tags (key:value) to match AWS Organization accounts tags
    }
  ]
}

詳細については、Terraform ウェブサイトの AWS Permission Sets モジュールのドキュメントの JSON スキーマを参照してください。

ヒント

• Terraform インポートブロックを使用して、既存のアクセス許可セットをソリューションにインポートできます。

• AFT を使用して、委任アカウントに AWS 権限セットパイプラインを実装できます。詳細については、「AFT 設計図」を参照してください。