AWS Key Management Service
開発者ガイド

キーアクセスのトラブルシューティング

カスタマーマスターキー (CMK) へのアクセスを許可するとき、AWS KMS は以下を評価します。

  • CMK にアタッチされているキーポリシーキーポリシーは、常に、CMK を所有する AWS アカウントで定義されます。

  • そのリクエストを行っている IAM ユーザーまたはロールにアタッチされているすべての IAM ポリシー。プリンシパルの CMK の使用を規定する IAM ポリシーは常にプリンシパルの AWS アカウントで定義されています。

  • CMK に適用されるすべての許可。

AWS KMS は CMK の キーポリシーIAM ポリシー許可を一緒に評価して、CMK へのアクセスを許可するか拒否するかを決定します。そのために、AWS KMS は以下のフローチャートに示されているようなプロセスを使用します。以下のフローチャートは、ポリシーの評価プロセスを視覚的に表したものです。


      ポリシーの評価プロセスを示すフローチャート

このフローチャートは 2 つの部分に分かれています。これらの部分には順序があるように見えますが、一般的に同時に評価されます。

  • 承認の使用により、そのキーポリシー、IAM ポリシー、許可に基づいて、CMK の使用が許可されるかどうかが決まります。

  • キーの信頼により、使用が許可されている CMK を信頼すべきかどうかが決まります。通常、お客様は AWS アカウントのリソースを信頼します。ただし、お客様のアカウントの許可または IAM ポリシーで CMK の使用が許可される場合は、別の AWS アカウントでその CMK を信頼して使用できます。

このフローチャートを使用すると、呼び出し元がなぜ CMK の使用を許可または拒否されたかがわかります。また、ポリシーと許可を評価することもできます。たとえば、フローチャートでは、キーポリシー、IAM ポリシー、または許可で、明示的な DENY ステートメントがあることより、または明示的な ALLOW ステートメントがないことにより、呼び出し元がアクセスを拒否される可能性があることを示しています。

フローチャートでは、いくつかの一般的なアクセス許可のシナリオについて説明しています。

例 1: ユーザーが自分の AWS アカウントで CMK へのアクセスを拒否される

Alice は 111122223333 AWS アカウントの IAM ユーザーです。同じ AWS アカウントの CMK へのアクセスが拒否されました。Alice が CMK を使用できないのはなぜでしょうか。

この場合、Alice が CMK へのアクセスを拒否されたのは、必要なアクセス許可を付与するキーポリシー、IAM ポリシー、または許可がないためです。CMK のキーポリシーでは、AWS アカウントに CMK へのアクセスをコントロールする IAM ポリシーの使用を許可していますが、Alice に CMK を使用するためのアクセス許可を付与する IAM ポリシーはありません。


               ポリシーの評価プロセスを示すフローチャート

この例に関連するポリシーを考えてみます。

  • Alice が使用する CMK には、デフォルトキーポリシーがあります。このポリシーでは、IAM ポリシーを使用して CMK へのアクセスをコントロールすることを、その CMK を所有する AWS アカウントに許可しています。フローチャートでは、このキーポリシーによってキーポリシーが呼び出し元のアカウントに IAM ポリシーを使用してキーへのアクセスをコントロールすることを許可しているか? という条件が満たされます。

    { "Version" : "2012-10-17", "Id" : "key-test-1", "Statement" : [ { "Sid" : "Delegate to IAM policies", "Effect" : "Allow", "Principal" : { "AWS" : "arn:aws:iam::111122223333:root" }, "Action" : "kms:*", "Resource" : "*" } ] }
  • ただし、Alice に CMK を使用するためのアクセス許可を付与するキーポリシー、IAM ポリシー、または許可がありません。したがって、Alice は CMK の使用を拒否されます。

例 2: ユーザーが別の AWS アカウントの CMK を使用するためのアクセス許可のあるロールを引き受ける

Bob はアカウント 1 (111122223333) のユーザーです。アカウント 2 (444455556666) の CMK を暗号化オペレーションで使用することを許可されています。これはどのようにすれば可能になるのでしょうか。

ヒント

クロスアカウントのアクセス許可を評価するときは、キーポリシーが CMK のアカウントで指定されていることを忘れないでください。呼び出し元が別のアカウントを使用していても、IAM ポリシーは呼び出し元のアカウントで指定されています。

  • アカウント 2 の CMK のキーポリシーは、アカウント 2 が IAM ポリシーを使用して CMK へのアクセスをコントロールすることを許可します。

  • アカウント 2 の CMK のキーポリシーは、アカウント 1 が暗号化オペレーションで CMK を使用することを許可します。ただし、アカウント 1 は IAM ポリシーを使用してそのプリンシパルに CMK へのアクセス権限を付与する必要があります。

  • アカウント 1 の IAM ポリシーは、ExampleRole ロールに、アカウント 2 の CMK を暗号化オペレーションで使用することを許可します。

  • アカウント 1 のユーザーである Bob には、ExampleRole ロールを引き受けるアクセス権限があります。

  • Bob はこの CMK を信頼できます。この CMK は Bob のアカウントにはありませんが、アカウントの IAM ポリシーにより、この CMK を使用する明示的なアクセス許可が Bob に付与されるためです。


               ポリシーの評価プロセスを示すフローチャート

アカウント 1 のユーザーである Bob がアカウント 2 の CMK を使用することを許可するポリシーを考えてみます。

  • CMK のキーポリシーは、アカウント 2 (CMK を所有するアカウント、444455556666) に、IAM ポリシーを使用して CMK へのアクセスをコントロールすることを許可します。このキーポリシーはまた、アカウント 1 (111122223333) に暗号化オペレーションで CMK を使用することを許可します (ポリシーステートメントの Action 要素で指定)。ただし、アカウント 1 でプリンシパルに CMK へのアクセスを許可する IAM ポリシーが定義されるまでは、アカウント 1 のだれもアカウント 2 の CMK を使用できません。

    フローチャートでは、このアカウント 2 のキーポリシーによってキーポリシーが呼び出し元のアカウントに IAM ポリシーを使用してキーへのアクセスをコントロールすることを許可しているか? という条件が満たされます。

    { "Id": "key-policy-acct-2", "Version": "2012-10-17", "Statement": [ { "Sid": "Permission to use IAM policies", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::444455556666:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow account 1 to use this CMK", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::111122223333:root" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": "*" } ] }
  • 呼び出し元の AWS アカウント (アカウント 1、111122223333) の IAM ポリシーは、アカウント 1 の ExampleRole ロールに、アカウント 2 (444455556666) の CMK を使用して暗号化オペレーションを実行するためのアクセス許可を付与します。Action 要素は、アカウント 2 のキーポリシーがアカウント 1 に付与したのと同じアクセス権限をロールに付与します。

    このようなクロスアカウント IAM ポリシーは、アカウント 2 の CMK のキーポリシーがアカウント 1 に、CMK を使用するアクセス権限を付与している場合にのみ有効です。また、アカウント 1 がプリンシパルに付与できるのは、キーポリシーがそのアカウントに付与しているアクションの実行アクセス許可のみです。

    フローチャートでは、これによって IAM ポリシーが呼び出し元にこのアクションの実行を許可しているか? という条件が満たされます。

    { "Version": "2012-10-17", "Statement": [ { "Principal": { "arn:aws:iam::111122223333:role/ExampleRole" } "Effect": "Allow", "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncryptFrom", "kms:ReEncryptTo", "kms:GenerateDataKey", "kms:GenerateDataKeyWithoutPlaintext", "kms:DescribeKey" ], "Resource": [ "arn:aws:kms:us-west-2:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab" ] } ] }
  • 最後に必要な要素は、アカウント 1 での ExampleRole ロールの定義です。ロールの AssumeRolePolicyDocument により、Bob は ExampleRole ロールを引き受けることができます。

    { "Role": { "Arn": "arn:aws:iam::111122223333:role/ExampleRole", "CreateDate": "2019-05-16T00:09:25Z", "AssumeRolePolicyDocument": { "Version": "2012-10-17", "Statement": { "Principal": { "AWS": "arn:aws:iam::111122223333:user/bob" }, "Effect": "Allow", "Action": "sts:AssumeRole" } }, "Path": "/", "RoleName": "ExampleRole", "RoleId": "AROA4KJY2TU23Y7NK62MV" } }