Terraform を使用して AWS Organizations の IAM アクセスキー管理を一元化する

PDF

作成者: Aarti Rajput (AWS)、Chintamani Aphale (AWS)、T.V.R.L.Phani Kumar Dadi (AWS)、Pradip kumar Pandey (AWS)、Mayurihinde (AWS)、Pratap Kumar Nanda (AWS)

概要

注意: AWS CodeCommit は新規顧客には利用できなくなりました。の既存のお客様は、通常どおりサービスを AWS CodeCommit 引き続き使用できます。詳細はこちら

キーとパスワードのセキュリティルールの適用は、すべての組織にとって 不可欠なタスクです。重要なルールの 1 つは、セキュリティを強化するために AWS Identity and Access Management (IAM) キーを定期的にローテーションすることです。通常、AWS アクセスキーは、チームが AWS コマンドラインインターフェイス (AWS CLI) または AWS 外のアプリケーションから AWS にアクセスするたびにローカルで作成および設定されます。組織全体で強力なセキュリティを維持するには、要件が満たされた後、または定期的に古いセキュリティキーを変更または削除する必要があります。組織内の複数のアカウント間でキーローテーションを管理するプロセスは、時間がかかり、面倒です。このパターンは、Account Factory for Terraform (AFT) と AWS のサービスを使用してローテーションプロセスを自動化するのに役立ちます。

このパターンには以下の利点があります。

• アクセスキー IDs とシークレットアクセスキーを、組織内のすべてのアカウントで一元管理します。

• AWS_ACCESS_KEY_ID および AWS_SECRET_ACCESS_KEY環境変数を自動的にローテーションします。

• ユーザー認証情報が侵害された場合は、更新を強制します。

このパターンでは、Terraform を使用して AWS Lambda 関数、Amazon EventBridge ルール、IAM ロールをデプロイします。EventBridge ルールは定期的に実行され、作成された日時に基づいてすべてのユーザーアクセスキーを一覧表示する Lambda 関数を呼び出します。前のキーが定義したローテーション期間 (45 日など) より古い場合、追加の Lambda 関数は新しいアクセスキー ID とシークレットアクセスキーを作成し、Amazon Simple Notification Service (Amazon SNS) と Amazon Simple Email Service (Amazon SES) を使用してセキュリティ管理者に通知します。シークレットはそのユーザーの AWS Secrets Manager で作成され、古いシークレットアクセスキーは Secrets Manager に保存され、古いキーにアクセスするためのアクセス許可が設定されます。古いアクセスキーが使用されないようにするには、非アクティブ期間 (例: 60 日、この例ではキーがローテーションされてから 15 日後) 後に無効になります。非アクティブなバッファ期間 (例: 90 日、またはこの例ではキーがローテーションされてから 45 日) 後、古いアクセスキーは AWS Secrets Manager から削除されます。詳細なアーキテクチャとワークフローについては、「アーキテクチャ」セクションを参照してください。

前提条件と制限

• AWS Control Tower （バージョン 3.1 以降) を使用して構築された組織のランディングゾーン

•  Account Factory for Terraform (AFT) は、次の 3 つのアカウントで設定されています。

  • 組織管理アカウントは、組織全体を一元管理します。

  • AFT 管理アカウントは Terraform パイプラインをホストし、インフラストラクチャをデプロイアカウントにデプロイします。

  • デプロイアカウントは、この完全なソリューションをデプロイし、IAM キーを一元管理します。

• デプロイアカウントにインフラストラクチャをプロビジョニングするための Terraform バージョン 0.15.0 以降。

• Amazon Simple Email Service (Amazon SES) で設定されている E メールアドレス。

• （推奨) セキュリティを強化するには、このソリューションを Virtual Private Cloud (VPC) 内のプライベートサブネット (デプロイアカウント) 内にデプロイします。変数をカスタマイズするときに VPC とサブネットの詳細を指定できます (エピックセクションのコードパイプラインのパラメータをカスタマイズするセクションを参照）。

アーキテクチャ

AFT リポジトリ

このパターンでは、Account Factory for Terraform (AFT) を使用して、必要なすべての AWS リソースを作成し、コードパイプラインを使用してデプロイアカウントにリソースをデプロイします。コードパイプラインは 2 つのリポジトリで実行されます。

• グローバルカスタマイズには、AFT に登録されているすべてのアカウントで実行される Terraform コードが含まれています。

• アカウントのカスタマイズには、デプロイアカウントで実行される Terraform コードが含まれます。

リソースの詳細

AWS CodePipeline ジョブは、デプロイアカウントに次のリソースを作成します。

• AWS EventBridge ルールと設定済みルール

• account-inventory Lambda 関数

• IAM-access-key-rotation Lambda 関数

• Notification Lambda 関数

• E メールテンプレートを含む Amazon Simple Storage Service (Amazon S3) バケット

• 必要な IAM ポリシー

アーキテクチャ

この図表は、以下を示すものです：

1. EventBridge ルールは、24 時間ごとに account-inventory Lambda 関数を呼び出します。

2. account-inventory Lambda 関数は、すべての AWS アカウント ID、アカウント名、およびアカウント E メールのリストを AWS Organizations にクエリします。 IDs 

3. account-inventoryLambda 関数は、AWS アカウントごとに IAM-access-key-auto-rotation Lambda 関数を開始し、メタデータを渡して追加の処理を行います。

4. IAM-access-key-auto-rotation Lambda 関数は、引き受けた IAM ロールを使用して AWS アカウントにアクセスします。Lambda スクリプトは、アカウント内のすべてのユーザーとそのユーザーの IAM アクセスキーに対して監査を実行します。

5. IAM キーローテーションしきい値 (ローテーション期間) は、IAM-access-key-auto-rotationLambda 関数がデプロイされるときに環境変数として設定されます。ローテーション期間が変更されると、IAM-access-key-auto-rotationLambda 関数は更新された環境変数で再デプロイされます。パラメータを設定して、ローテーション期間、古いキーの非アクティブ期間、および古いキーが削除された後の非アクティブバッファを設定できます (エピックセクションのコードパイプラインのパラメータをカスタマイズするを参照）。

6. IAM-access-key-auto-rotation Lambda 関数は、設定に基づいてアクセスキーの経過時間を検証します。IAM アクセスキーの有効期間が定義したローテーション期間を超えていない場合、Lambda 関数はそれ以上アクションを実行しません。

7. IAM アクセスキーの有効期間が定義したローテーション期間を超えた場合、IAM-access-key-auto-rotationLambda 関数は新しいキーを作成し、既存のキーをローテーションします。

8. Lambda 関数は、古いキーを Secrets Manager に保存し、アクセスキーがセキュリティ標準から逸脱したユーザーにアクセス許可を制限します。Lambda 関数は、指定された IAM プリンシパルのみがシークレットにアクセスして取得できるようにするリソースベースのポリシーも作成します。

9. IAM-access-key-rotation Lambda 関数は Lambda Notification 関数を呼び出します。

10. Notification Lambda 関数は S3 バケットに E メールテンプレートをクエリし、関連するアクティビティメタデータを含む E メールメッセージを動的に生成します。

11. Notification Lambda 関数は、Amazon SES を呼び出してさらにアクションを実行します。

12.  Amazon SES は、アカウント所有者の E メールアドレスに関連情報を含む E メールを送信します。

ツール

AWS サービス

• 「AWS Identity and Access Management (IAM)」は、AWS リソースへのアクセスを安全に管理し、誰が認証され、使用する権限があるかを制御するのに役立ちます。このパターンには IAM ロールとアクセス許可が必要です。

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

• AWS Secrets Manager は、コード内のハードコードされた認証情報 (パスワードを含む) を Secrets Manager への API コールに置き換えて、シークレットをプログラムで取得する上で役立ちます。

• 「Amazon Simple Email Service (Amazon SES)」はユーザー自身のメールアドレスとドメインを使用してメールを送受信する上で役立ちます。

その他のツール

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

コードリポジトリ

このパターンの手順とコードは、GitHub IAM アクセスキーローテーションリポジトリで入手できます。AWS Control Tower の中央デプロイアカウントにコードをデプロイして、キーローテーションを一元管理できます。

ベストプラクティス

• IAM については、IAM ドキュメントの「セキュリティのベストプラクティス」を参照してください。

• キーローテーションについては、IAM ドキュメントの「アクセスキーの更新に関するガイドライン」を参照してください。

エピック

ソースファイルのセットアップ

タスク	説明	必要なスキル
リポジトリをクローン作成します。	IAM アクセスキーローテーション GitHub リポジトリのクローンを作成します。 $ git clone https://github.com/aws-samples/centralized-iam-key-management-aws-organizations-terraform.git リポジトリのローカルコピーに 3 つのフォルダが含まれていることを確認します。 $ cd Iam-Access-keys-Rotation $ ls org-account-customization global-account-customization account-customization	DevOps エンジニア

ソースファイルのセットアップ

タスク	説明	必要なスキル
リポジトリをクローン作成します。	IAM アクセスキーローテーション GitHub リポジトリのクローンを作成します。 $ git clone https://github.com/aws-samples/centralized-iam-key-management-aws-organizations-terraform.git リポジトリのローカルコピーに 3 つのフォルダが含まれていることを確認します。 $ cd Iam-Access-keys-Rotation $ ls org-account-customization global-account-customization account-customization	DevOps エンジニア

アカウントの設定

タスク	説明	必要なスキル
ブートストラップアカウントを設定します。	AFT ブートストラッププロセスの一環として、ローカルマシンaft-bootstrapに というフォルダが必要です。 すべての Terraform ファイルをローカル GitHub org-account-customization フォルダから aft-bootstrap フォルダに手動でコピーします。 Terraform コマンドを実行して、AWS Control Tower 管理アカウントでグローバルクロスアカウントロールを設定します。 $ cd aft-bootstrap $ terraform init $ terraform apply —auto-approve	DevOps エンジニア
グローバルカスタマイズを設定します。	AFT フォルダの設定の一環として、ローカルマシンaft-global-customizationsに というフォルダが必要です。 すべての Terraform ファイルをローカル GitHub global-account-customization フォルダから aft-global-customizations/terraform フォルダに手動でコピーします。 コードを AWS CodeCommit にプッシュします。 $ git add * $ git commit -m "message" $ git push	DevOps エンジニア
アカウントのカスタマイズを設定します。	AFT フォルダの設定の一環として、ローカルマシンaft-account-customizationsに というフォルダがあります。 販売されたアカウント番号でフォルダを作成します。 すべての Terraform ファイルをローカル GitHub アカウントカスタマイズフォルダから aft-account-customizations/<vended account>/terraform フォルダに手動でコピーします。 コードを AWS CodeCommit にプッシュします。 $ git add * $ git commit -m "message" $ git push	DevOps エンジニア

アカウントの設定

タスク	説明	必要なスキル
ブートストラップアカウントを設定します。	AFT ブートストラッププロセスの一環として、ローカルマシンaft-bootstrapに というフォルダが必要です。 すべての Terraform ファイルをローカル GitHub org-account-customization フォルダから aft-bootstrap フォルダに手動でコピーします。 Terraform コマンドを実行して、AWS Control Tower 管理アカウントでグローバルクロスアカウントロールを設定します。 $ cd aft-bootstrap $ terraform init $ terraform apply —auto-approve	DevOps エンジニア
グローバルカスタマイズを設定します。	AFT フォルダの設定の一環として、ローカルマシンaft-global-customizationsに というフォルダが必要です。 すべての Terraform ファイルをローカル GitHub global-account-customization フォルダから aft-global-customizations/terraform フォルダに手動でコピーします。 コードを AWS CodeCommit にプッシュします。 $ git add * $ git commit -m "message" $ git push	DevOps エンジニア
アカウントのカスタマイズを設定します。	AFT フォルダの設定の一環として、ローカルマシンaft-account-customizationsに というフォルダがあります。 販売されたアカウント番号でフォルダを作成します。 すべての Terraform ファイルをローカル GitHub アカウントカスタマイズフォルダから aft-account-customizations/<vended account>/terraform フォルダに手動でコピーします。 コードを AWS CodeCommit にプッシュします。 $ git add * $ git commit -m "message" $ git push	DevOps エンジニア

コードパイプラインのパラメータをカスタマイズする

タスク	説明	必要なスキル
すべてのアカウントに対して非Terraform コードパイプラインパラメータをカスタマイズします。	aft-global-customizations/terraform/ フォルダinput.auto.tfvarsに という名前のファイルを作成し、必要な入力データを指定します。デフォルト値については、GitHub リポジトリの ファイルを参照してください。	DevOps エンジニア
デプロイアカウントのコードパイプラインパラメータをカスタマイズします。	aft-account-customizations/<AccountName>/terraform/ フォルダinput.auto.tfvarsに という名前のファイルを作成し、コードを AWS CodeCommit にプッシュします。AWS CodeCommit にコードをプッシュすると、コードパイプラインが自動的に開始されます。 以下を含む、組織の要件に基づいてパラメータの値を指定します (デフォルト値については、Github リポジトリの ファイルを参照してください）。 s3_bucket_name – E メールテンプレートの一意のバケット名。 s3_bucket_prefix – S3 バケット内のフォルダ名。 admin_email_address – 通知を受け取る管理者の E メールアドレス。 org_list_account – 管理アカウントのアカウント番号。 rotation_period – キーをアクティブから非アクティブにローテーションする日数。 inactive_period – ローテーションされたキーを非アクティブ化する日数。この値は、 の値より大きい必要がありますrotation_period。 inactive_buffer – ローテーションからキーの非アクティブ化までの猶予期間。 recovery_grace_period – 非アクティブ化からキーの削除までの猶予期間。 dry_run_flag – キーをローテーションせずにテスト目的で管理者に通知を送信する場合は、true に設定します。 store_secrets_in_central_account – シークレットをデプロイアカウントに保存する場合は true に設定します。変数が false (デフォルト) に設定されている場合、シークレットはメンバーアカウントに保存されます。 credential_replication_region – Lambda 関数と E メールテンプレートの S3 バケットをデプロイする AWS リージョン。 run_lambda_in_vpc – VPC 内で Lambda 関数を実行するには、true に設定します。 vpc_id – VPC 内で Lambda 関数を実行する場合の、デプロイアカウントの VPC ID。 vpc_cidr – デプロイアカウントの CIDR 範囲。 subnet_id – デプロイアカウントのサブネット IDs。 create_smtp_endpoint – E メールエンドポイントを有効にする場合は true に設定します。	DevOps エンジニア

コードパイプラインのパラメータをカスタマイズする

タスク	説明	必要なスキル
すべてのアカウントに対して非Terraform コードパイプラインパラメータをカスタマイズします。	aft-global-customizations/terraform/ フォルダinput.auto.tfvarsに という名前のファイルを作成し、必要な入力データを指定します。デフォルト値については、GitHub リポジトリの ファイルを参照してください。	DevOps エンジニア
デプロイアカウントのコードパイプラインパラメータをカスタマイズします。	aft-account-customizations/<AccountName>/terraform/ フォルダinput.auto.tfvarsに という名前のファイルを作成し、コードを AWS CodeCommit にプッシュします。AWS CodeCommit にコードをプッシュすると、コードパイプラインが自動的に開始されます。 以下を含む、組織の要件に基づいてパラメータの値を指定します (デフォルト値については、Github リポジトリの ファイルを参照してください）。 s3_bucket_name – E メールテンプレートの一意のバケット名。 s3_bucket_prefix – S3 バケット内のフォルダ名。 admin_email_address – 通知を受け取る管理者の E メールアドレス。 org_list_account – 管理アカウントのアカウント番号。 rotation_period – キーをアクティブから非アクティブにローテーションする日数。 inactive_period – ローテーションされたキーを非アクティブ化する日数。この値は、 の値より大きい必要がありますrotation_period。 inactive_buffer – ローテーションからキーの非アクティブ化までの猶予期間。 recovery_grace_period – 非アクティブ化からキーの削除までの猶予期間。 dry_run_flag – キーをローテーションせずにテスト目的で管理者に通知を送信する場合は、true に設定します。 store_secrets_in_central_account – シークレットをデプロイアカウントに保存する場合は true に設定します。変数が false (デフォルト) に設定されている場合、シークレットはメンバーアカウントに保存されます。 credential_replication_region – Lambda 関数と E メールテンプレートの S3 バケットをデプロイする AWS リージョン。 run_lambda_in_vpc – VPC 内で Lambda 関数を実行するには、true に設定します。 vpc_id – VPC 内で Lambda 関数を実行する場合の、デプロイアカウントの VPC ID。 vpc_cidr – デプロイアカウントの CIDR 範囲。 subnet_id – デプロイアカウントのサブネット IDs。 create_smtp_endpoint – E メールエンドポイントを有効にする場合は true に設定します。	DevOps エンジニア

キーローテーションを検証する

タスク	説明	必要なスキル
ソリューションを更新する	AWS マネジメントコンソールから、デプロイアカウントにサインインします。 IAM コンソールを開き、ユーザー認証情報 (アクセスキー IDsとシークレットキー) が指定されたとおりにローテーションされているかどうかを確認します。 IAM キーがローテーションされたら、以下を確認します。 古い値は AWS Secrets Manager に保存されます。 シークレット名は の形式ですAccount_<account ID>_User_<username>_AccessKey。 admin_email_address パラメータで指定したユーザーは、キーローテーションに関する E メール通知を受け取ります。	DevOps エンジニア

キーローテーションを検証する

タスク	説明	必要なスキル
ソリューションを更新する	AWS マネジメントコンソールから、デプロイアカウントにサインインします。 IAM コンソールを開き、ユーザー認証情報 (アクセスキー IDsとシークレットキー) が指定されたとおりにローテーションされているかどうかを確認します。 IAM キーがローテーションされたら、以下を確認します。 古い値は AWS Secrets Manager に保存されます。 シークレット名は の形式ですAccount_<account ID>_User_<username>_AccessKey。 admin_email_address パラメータで指定したユーザーは、キーローテーションに関する E メール通知を受け取ります。	DevOps エンジニア

ソリューションを拡張する

タスク	説明	必要なスキル
E メール通知の日付をカスタマイズします。	アクセスキーを無効にする前に特定の日に E メール通知を送信する場合は、これらの変更で IAM-access-key-auto-rotation Lambda 関数を更新できます。 という変数を定義しますnotify-period。 キーを非アクティブ化main.pyする前に、 に if条件を追加します。 If (keyage>rotation-period-notify-period){ send_to_notifier(context, aws_account_id, account_name, resource_owner, resource_actions[resource_owner], dryrun, config.emailTemplateAudit) }	DevOps エンジニア

ソリューションを拡張する

タスク	説明	必要なスキル
E メール通知の日付をカスタマイズします。	アクセスキーを無効にする前に特定の日に E メール通知を送信する場合は、これらの変更で IAM-access-key-auto-rotation Lambda 関数を更新できます。 という変数を定義しますnotify-period。 キーを非アクティブ化main.pyする前に、 に if条件を追加します。 If (keyage>rotation-period-notify-period){ send_to_notifier(context, aws_account_id, account_name, resource_owner, resource_actions[resource_owner], dryrun, config.emailTemplateAudit) }	DevOps エンジニア

トラブルシューティング

問題	ソリューション
アカウントの一覧表示AccessDenied中に account-inventory Lambda ジョブが で失敗します。	この問題が発生した場合は、アクセス許可を検証する必要があります。 新しく発行されたアカウントにログインし、Amazon CloudWatch コンソールを開き、CloudWatch ロググループ を表示します/aws/lambda/account-inventory-lambda。 最新の CloudWatch ログで、アクセス拒否の問題の原因となっているアカウント番号を特定します。 AWS Control Tower 管理アカウントにログインし、ロールallow-list-accountが作成されたことを確認します。 ロールが存在しない場合は、 terraform apply コマンドを使用して Terraform コードを再実行します。 Trusted Account タブを選択し、同じアカウントが信頼されていることを確認します。

関連リソース

• Terraform の推奨プラクティス (Terraform ドキュメント）

• IAM でのセキュリティのベストプラクティス (IAM ドキュメント)

• キーローテーションのベストプラクティス (IAM ドキュメント）