ある企業はAWS Organizationsで30のAWSアカウントを管理しています。中央セキュリティアカウントにAWS KMSのカスタマーマネージドキー（CMK）を保持しており、各メンバーアカウントのEC2インスタンス

Question

ある企業はAWS Organizationsで30のAWSアカウントを管理しています。中央セキュリティアカウントにAWS KMSのカスタマーマネージドキー（CMK）を保持しており、各メンバーアカウントのEC2インスタンスがこのCMKでEBSボリュームを暗号化しています。セキュリティチームの要件は以下の通りです。

・CMKへのアクセスをOrganizations配下のアカウントのみに限定する
・新規アカウントがOrganizationsに参加した際、KMSキーポリシーを変更せずに自動的にアクセスを許可したい
・30個のアカウントIDを個別にリストアップするメンテナンス作業を避けたい

KMSキーポリシーのStatementに追加すべき条件として最も適切なものはどれですか？

Accepted Answer

正解: aws:PrincipalOrgID条件キーに自社のOrganizations IDを指定し、Organizations配下のプリンシパルからのリクエストのみにkms:Decryptやkms:GenerateDataKeyを許可する。aws:PrincipalOrgIDグローバル条件キーは、リクエストを送信したIAMプリンシパル（ユーザー・ロール）が所属するAWS OrganizationsのIDを検証します。KMSキーポリシーでこの条件を使用することで、「指定したOrganizations IDに属する全プリンシパル」のみにアクセスを許可できます。

この方法の最大の利点は、新規アカウントがOrganizationsに追加されても自動的に条件を満たすため、キーポリシーの更新が不要な点です。30アカウントのIDを個別にリストする必要もなく、メンテナンスコストを大幅に削減できます。

選択肢Bのワイルドカードarn:aws:iam::*:rootを使用するアプローチは、Organizations外の任意のAWSアカウントにもアクセスを許可してしまうため、「Organization配下のみ」という要件を満たさない。
選択肢Cのaws:SourceAccountはAWSサービスプリンシパル（Lambda・S3等）からのリクエストのアカウントを検証するために使用される条件キーであり、Organizations IDを値として受け付けない。IAMユーザー・ロールのOrganizations所属の検証にはaws:PrincipalOrgIDを使用する。
選択肢DのSCPはメンバーアカウントのIAMプリンシパルに対して最大権限の上限を設定するもので、クロスアカウントのKMSキーへのアクセスを「許可」する機能はない。許可はKMSキーポリシーで明示的に設定する必要がある。

Answer

KMSキーポリシーのPrincipalにarn:aws:iam::*:rootをワイルドカードで指定してすべてのAWSアカウントからのアクセスを許可し、SCPで組織外への鍵使用を制限する — arn:aws:iam::*:rootのワイルドカード指定はOrganizations外の任意のAWSアカウントにもアクセスを許可してしまう。SCPはメンバーアカウントの最大権限の上限を設定するものであり、クロスアカウントのKMSキーへのアクセスを許可する機能はないため要件を満たさない。

Answer

aws:SourceAccount条件キーにOrganizations ID（o-xxxxxxxxxx）を値として指定し、Organizations配下のアカウントからのアクセスのみを許可する — aws:SourceAccountはAWSサービスプリンシパルからのリクエストの発生元アカウントを検証する条件キーであり、Organizations IDを値として受け付けない。OrganizationsメンバーのIAMプリンシパルを対象にするにはaws:PrincipalOrgIDを使用する必要がある。

Answer

KMSキーポリシーではなくAWS Organizations SCPを使用してメンバーアカウントにkms:Decryptを許可し、中央セキュリティアカウントのCMKへのアクセスを制御する — SCPはメンバーアカウントのIAMプリンシパルに対して最大権限の境界を設定するものであり、中央セキュリティアカウントのCMKへのクロスアカウントアクセスを許可する機能はない。アクセス許可はKMSキーポリシー側で明示的に定義する必要がある。

解説

解説