View a markdown version of this page

Terraform を使用して AWS Organizations の IAM アクセスキー管理を一元化する - AWS 規範ガイダンス
概要前提条件と制限事項アーキテクチャツールベストプラクティスエピックトラブルシューティング関連リソース

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

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

Aarti Rajput、Chintamani Aphale、T.V.R.L.Phani Kumar Dadi、Pratap Kumar Nanda、Pradip kumar Pandey、Mayuri Shinde (Amazon Web Services)

概要

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

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

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

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

  • ユーザー認証情報が侵害された場合に更新を適用できます。

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

前提条件と制限事項

アーキテクチャ

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 ポリシー

アーキテクチャ

AWS Organizations で IAM アクセスキー管理を一元化するためのアーキテクチャ

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

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

  2. account-inventory Lambda 関数は、すべての AWS アカウント ID、アカウント名、アカウントメールのリストを AWS Organizations に問い合わせます。 

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

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

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

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

  7. IAM アクセスキーの経過時間が定義されたローテーション期間を超えている場合、IAM-access-key-auto-rotation Lambda 関数は新しいキーを作成し、既存のキーをローテーションします。

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

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

  10. Notification Lambda 関数は S3 バケットにメールテンプレートを問い合わせ、関連するアクティビティメタデータを使用して 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 access key rotation リポジトリで入手できます。AWS Control Tower の中央デプロイアカウントにコードをデプロイして、中央の場所からキーローテーションを一元管理できます。

ベストプラクティス

エピック

タスク説明必要なスキル

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

  1. GitHub リポジトリの IAM access key rotation のクローンを作成します。

    $ git clone https://github.com/aws-samples/centralized-iam-key-management-aws-organizations-terraform.git

  2. リポジトリのローカルコピーに、次の 3 つのフォルダが含まれていることを確認します。

    $ cd Iam-Access-keys-Rotation
$ ls
org-account-customization
global-account-customization
account-customization
DevOps エンジニア
タスク説明必要なスキル

ブートストラップアカウントの設定

AFT ブートストラッププロセスの一環として、ローカルマシンに aft-bootstrap というフォルダが必要となります。

  1. すべての Terraform ファイルを、ローカル GitHub の org-account-customization フォルダから aft-bootstrap フォルダに手動でコピーします。

  2. Terraform コマンドを実行して、AWS Control Tower 管理アカウントでグローバルクロスアカウントロールを設定します。

    $ cd aft-bootstrap
$ terraform init
$ terraform apply —auto-approve
DevOps エンジニア

グローバルカスタマイズの設定

AFT フォルダの設定の一環として、ローカルマシンに aft-global-customizations というフォルダが必要となります。

  1. すべての Terraform ファイルを、ローカル GitHub の global-account-customization フォルダから aft-global-customizations/terraform フォルダに手動でコピーします。

  2. コードを AWS CodeCommit にプッシュします。

    $ git add *
$ git commit -m "message"
$ git push
DevOps エンジニア

アカウントのカスタマイズを設定

AFT フォルダの設定の一環として、ローカルマシンに aft-account-customizations というフォルダが必要となります。

  1. 発行されたアカウント番号でフォルダを作成します。

  2. すべての Terraform ファイルを、ローカル GitHub の account-customization フォルダから aft-account-customizations/<vended account>/terraform フォルダに手動でコピーします。

  3. コードを 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 - デプロイアカウントのサブネット ID。

  • create_smtp_endpoint - E メールエンドポイントを有効にする場合は true に設定します。

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

ソリューションの検証

  1. AWS マネジメントコンソールからデプロイアカウントにサインインします。

  2. IAM コンソールを開き、ユーザー認証情報 (アクセスキー ID とシークレットキー) が指定されたとおりにローテーションされているかどうかを確認します。

  3. IAM キーがローテーションされたら、以下を確認します。

    • 古い値が AWS Secrets Manager に保存されている。

    • シークレット名の形式が Account_<account ID>_User_<username>_AccessKey である。

    • admin_email_address パラメータで指定したユーザーが、キーローテーションに関する E メール通知を受け取っている。

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

E メール通知日のカスタマイズ

アクセスキーを無効にする前に、特定の日に E メール通知を送信する場合は、以下の変更で IAM-access-key-auto-rotation Lambda 関数を更新できます。

  1. notify-period という変数を定義します。

  2. キーを非アクティブ化する前に、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 エンジニア

トラブルシューティング

問題ソリューション

アカウントの一覧表示中に account-inventory Lambda ジョブが AccessDenied で失敗する。

この問題が発生した場合は、アクセス許可を検証する必要があります。

  1. 新しく発行されたアカウントにログインし、Amazon CloudWatch コンソールを開き、CloudWatch ロググループ /aws/lambda/account-inventory-lambda を表示します。

  2. 最新の CloudWatch ログで、アクセス拒否の問題の原因となっているアカウント番号を特定します。

  3. AWS Control Tower 管理アカウントにログインし、ロール allow-list-account が作成されていることを確認します。

  4. このロールが存在しない場合は、terraform apply コマンドを使用して Terraform コードを再実行します。

  5. [信頼できるアカウント] タブを選択し、同じアカウントが信頼されていることを確認します。

関連リソース