の ABAC の使用AWS KMS - AWS Key Management Service

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

の ABAC の使用AWS KMS

属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認証戦略です。AWS KMSCMK に関連付けられたタグとエイリアスを基に、カスタマーマスターキー (CMK) へのアクセスをコントロールできるため、ABAC がサポートされています。ABAC を有効にするタグおよびエイリアスの条件キー。AWS KMSは、ポリシーを編集したり許可を管理したりすることなく、プリンシパルに CMK の使用を許可する強力で柔軟な方法を提供します。ただし、プリンシパルが誤ってアクセスを許可または拒否されないように注意してこれらの機能を使用する必要があります。

ABAC を使用する場合は、タグとエイリアスを管理する権限がアクセス制御権限になることに注意してください。タグまたはエイリアスに依存するポリシーを展開する前に、すべての CMK の既存のタグとエイリアスがわかっていることを確認してください。エイリアスの追加、削除、更新時、およびキーのタグ付けおよびタグ付け解除時には、妥当な予防措置を講じます。タグとエイリアスを必要とするプリンシパルにのみ管理する権限を付与し、管理できるタグとエイリアスを制限します。

Notes

ABAC をAWS KMSプリンシパルにタグとエイリアスを管理する権限をプリンシパルに与えることに注意する必要があります。タグまたはエイリアスを変更すると、CMK に対するアクセス許可が許可または拒否される場合があります。キーポリシーを変更したり、許可を作成したりする権限を持たないキー管理者は、タグやエイリアスを管理する権限があれば、CMK へのアクセスを制御できます。

タグおよびエイリアスの変更が CMK 承認に影響するまでに、最大 5 分かかることがあります。最近の変更は、承認に影響を与える前に API 操作で表示される場合があります。

エイリアスに基づいて CMK へのアクセスを制御するには、条件キーを使用する必要があります。エイリアスを使用して、CMK を表すことはできませんResourceポリシーステートメントの要素。エイリアスがResource要素の場合、ポリシーステートメントは関連付けられた CMK ではなく、エイリアスに適用されます。

詳細はこちら

の ABAC 条件キーAWS KMS

タグとエイリアスに基づいて CMK へのアクセスを許可するには、キーポリシーまたは IAM ポリシーで次の条件キーを使用します。

ABAC 条件キー 説明 ポリシータイプ AWS KMSオペレーション
aws:ResourceTag/tag-key CMK のタグ(キーと値)が、ポリシーのタグ(キーと値)またはタグパターンと一致する IAM ポリシーのみ CMK リソースオペレーション2
aws:RequestTag/tag-key リクエスト内のタグ(キーと値)がポリシー内のタグ(キーと値)またはタグパターンと一致する キーポリシーと IAM ポリシー1 TagResource,UntagResource
aws:TagKeys リクエスト内のタグキーが、ポリシーのタグキーと一致します キーポリシーと IAM ポリシー1 TagResource,UntagResource
KMS: リソースエイリアス CMK に関連付けられたエイリアスは、ポリシーのエイリアスまたはエイリアスパターンに一致します。 IAM ポリシーのみ CMK リソースオペレーション2
KMS: 要求エイリアス リクエスト内の CMK を表すエイリアスは、ポリシーのエイリアスまたはエイリアスパターンと一致します。 キーポリシーと IAM ポリシー1 暗号化オペレーション,DescribeKey,GetPublicKey

1キーポリシーで使用できる条件キーは、IAM ポリシーでも使用できます。ただし、キーポリシーによって許可される

2ACMK リソースオペレーション特定の CMK に許可されるオペレーションです。CMK リソース操作を識別するには、AWS KMSパーミッションテーブルで CMK の値を探しますResources列で操作します。

たとえば、これらの条件キーを使用して、次のポリシーを作成できます。

  • の IAM ポリシーkms:ResourceAliasesで、特定のエイリアスまたはエイリアスパターンを持つ CMK を使用する許可を許可します。これは、タグに依存するポリシーとは少し異なります。ポリシーでエイリアスパターンを使用できますが、各エイリアスは AWS アカウント およびリージョン。これにより、ポリシーステートメントに CMK のキー ARN をリストせずに、選択した CMK セットにポリシーを適用できます。セットから CMK を追加または削除するには、CMK のエイリアスを変更します。

  • キーポリシーaws:RequestAliasこのコードでは、プリンシパルが CMK を使用できるようにしますEncryptオペレーションと同じですが、Encryptリクエストは、そのエイリアスを使用して CMK を識別します。

  • の IAM ポリシーaws:ResourceTag/tag-key特定のタグキーとタグ値を持つ CMK を使用するためのアクセス許可を拒否します。これにより、ポリシーステートメントに CMK のキー ARN をリストせずに、選択した CMK セットにポリシーを適用できます。CMK をセットに追加または削除するには、CMK にタグ付けするか、タグ付け解除します。

  • の IAM ポリシーaws:RequestTag/tag-keyプリンシパルの削除のみを許可する"Purpose"="Test"CMK タグ。

  • の IAM ポリシーaws:TagKeysを使用して CMK にタグ付けまたはタグ付け解除する権限を拒否するRestrictedタグキー。

ABAC は、アクセス管理を柔軟かつスケーラブルにします。たとえば、を使用することもできますaws:ResourceTag/tag-key条件キーを使用して、プリンシパルが特定の操作に CMK を使用できるようにする IAM ポリシーを作成します。このポリシーでは、CMK にPurpose=Testタグ。このポリシーは、のすべてのリージョンですべての CMK に適用されます AWS アカウント 。

ユーザーまたはロールにアタッチされると、以下の IAM ポリシーにより、プリンシパルはPurpose=Test指定された操作のタグ。新規または既存の CMK へのアクセスを提供するには、ポリシーを変更する必要はありません。単にアタッチしますPurpose=Testタグを CMK にアタッチします。同様に、このアクセスを CMK から削除するには、Purpose=Testタグで、タグを編集または削除します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Purpose": "Test" } } } ] }

ただし、この機能を使用する場合は、タグとエイリアスを管理するときに注意してください。タグまたはエイリアスを追加、変更、または削除すると、CMK へのアクセスを誤って許可または拒否する可能性があります。キーポリシーを変更したり、許可を作成したりする権限を持たないキー管理者は、タグやエイリアスを管理する権限があれば、CMK へのアクセスを制御できます。このリスクを軽減するには、タグを管理する権限の制限およびエイリアス。たとえば、選択したプリンシパルのみを管理できるようにすることができます。Purpose=Testタグ。詳細については、「エイリアスを使用した CMK へのアクセスを制御する」および「タグを使用した CMK へのアクセスのコントロール」を参照してください。

タグまたはエイリアス?

AWS KMSは、タグとエイリアスで ABAC をサポートします。どちらのオプションも、柔軟でスケーラブルなアクセス制御戦略を提供しますが、これらは互いに若干異なります。

タグを使用するか、特定のAWSパターンを使用します。たとえば、すでにほとんどの管理者にタグ付け権限を付与している場合は、エイリアスに基づいて承認戦略を制御する方が簡単です。または、あなたがのためのクォータに近い場合CMK あたりのエイリアスでは、タグに基づく認証戦略を好むかもしれません。

以下の利点が一般的である。

タグベースのアクセスコントロールのメリット

  • 異なるタイプの同じ認証メカニズムAWSリソースの使用料金を見積もることができます。

    同じタグキーまたはタグキーを使用して、Amazon Relational Database Service(Amazon RDS)クラスター、Amazon Elastic Block Store (Amazon EBS) ボリューム、AWS KMSCMK。この機能により、従来のロールベースのアクセス制御よりも柔軟性が高い、いくつかの異なる認可モデルが可能になります。

  • CMK のグループへのアクセスを許可します。

    タグを使用すると、同じ CMK グループへのアクセスを管理できます。 AWS アカウント およびリージョン。選択した CMK に同じタグまたはタグキーを割り当てます。次に、タグまたはタグキーに基づいて、シンプルで保守が容易なポリシーステートメントを作成します。認証グループに CMK を追加または削除するには、タグを追加または削除します。ポリシーを編集する必要はありません。

エイリアスベースのアクセスコントロールのメリット

  • エイリアスに基づいて暗号化操作へのアクセスを許可します。

    属性に対するほとんどの要求ベースのポリシー条件(aws: RequestTag/tag-key属性の追加、編集、または削除を実行するオペレーションにのみ影響します。しかし、KMS: 要求エイリアス条件キーは、リクエストの CMK を識別するために使用されるエイリアスを基に、暗号化オペレーションへのアクセスを制御します。たとえば、CMK を使用するプリンシパルアクセス許可をEncryptオペレーションをリクエストしますが、KeyIdパラメータがalias/restricted-key-1。この条件を満たすには、次のすべてが必要です。

    • CMK は、そのエイリアスに関連付けられている必要があります。

    • リクエストでは、エイリアスを使用して CMK を識別する必要があります。

    • プリンシパルは、CMK サブジェクトを使用するためのアクセス許可が必要です。kms:RequestAlias条件。

    これは、アプリケーションが一般的にエイリアス名またはエイリアス ARN を使用して CMK を参照する場合に特に便利です。

  • 非常に限られた権限を提供します。

    エイリアスは、 AWS アカウント およびリージョン。その結果、プリンシパルにエイリアスに基づいて CMK へのアクセス権を付与することは、タグに基づいてアクセス権を付与するよりもはるかに制限が厳しくなります。エイリアスとは異なり、タグは同じアカウントとリージョン内の複数の CMK に割り当てることができます。を選択した場合は、エイリアスパターン (alias/test*プリンシパルは同じアカウントとリージョンの CMK グループへのアクセスを許可します。ただし、特定のエイリアスへのアクセスを許可または拒否すると、CMK に対する非常に厳密な制御が可能になります。

の ABAC のトラブルシューティングAWS KMS

タグとエイリアスに基づいて CMK へのアクセスを制御することは、便利で強力です。ただし、いくつかの予測可能なエラーが発生しやすいため、予防する必要があります。

タグの変更によりアクセスが変更されました

タグが削除されるか、その値が変更されると、そのタグのみに基づく CMK へのアクセス権を持つプリンシパルは、CMK へのアクセスが拒否されます。これは、拒否ポリシーステートメントに含まれるタグが CMK に追加された場合にも発生します。CMK にポリシー関連タグを追加すると、CMK へのアクセスを拒否する必要のあるプリンシパルへのアクセスを許可できます。

たとえば、プリンシパルが CMK へのアクセス権を、Project=Alphaタグ (以下の IAM ポリシーステートメントの例によって提供されるアクセス許可など)。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "IAMPolicyWithResourceTag", "Effect": "Allow", "Action": [ "kms:GenerateDataKeyWithoutPlaintext", "kms:Decrypt" ], "Resource": "arn:aws:kms:ap-southeast-1:111122223333:key/*", "Condition": { "StringEquals": { "aws:ResourceTag/Project": "Alpha" } } } ] }

タグがその CMK から削除されるか、タグの値が変更されると、プリンシパルには、指定された操作で CMK を使用する権限がなくなります。これは、プリンシパルがAWSカスタマー管理の CMK を使用するサービス。タグの変更をトレースするには、CloudTrail ログでTagResourceまたはUntagResource エントリ

ポリシーを更新せずにアクセスを復元するには、CMK のタグを変更します。このアクションは、それが全体を通して有効である間、短い期間以外への影響は最小限ですAWS KMS。このようなエラーを防ぐには、タグ付けとタグ付け解除の権限を必要なプリンシパルにのみ与え、タグ付け権限を制限するを、管理する必要があるタグに追加します。タグを変更する前に、検索ポリシーでタグに依存するアクセスを検出し、タグを持つすべてのリージョンで CMK を取得します。特定のタグが変更されたときに、Amazon CloudWatch アラームを作成することを検討してください。

エイリアスの変更によるアクセス変更

エイリアスが削除されるか、別の CMK に関連付けられている場合、そのエイリアスだけに基づく CMK へのアクセス権を持つプリンシパルは、CMK へのアクセスが拒否されます。これは、CMK に関連付けられているエイリアスが拒否ポリシーステートメントに含まれている場合にも発生します。ポリシー関連のエイリアスを CMK に追加すると、CMK へのアクセスを拒否する必要のあるプリンシパルへのアクセスを許可することもできます。

たとえば、次の IAM ポリシーステートメントは、KMS: リソースエイリアス条件キーを使用して、指定したエイリアスを持つアカウントの異なるリージョンの CMK へのアクセスを許可します。

{ "Version": "2012-10-17", "Statement": [ { "Sid": "AliasBasedIAMPolicy", "Effect": "Allow", "Action": [ "kms:List*", "kms:Describe*", "kms:Decrypt" ], "Resource": "arn:aws:kms:*:111122223333:key/*", "Condition": { "ForAnyValue:StringEquals": { "kms:ResourceAliases": [ "alias/ProjectAlpha", "alias/ProjectAlpha_Test", "alias/ProjectAlpha_Dev" ] } } } ] }

エイリアスの変更をトレースするには、CloudTrail ログでCreateAlias,UpdateAlias, およびDeleteAliasエントリ。

ポリシーを更新せずにアクセスを復元するには、CMK に関連付けられたエイリアスを変更します。各エイリアスは、アカウントおよびリージョン内の 1 つの CMK にのみ関連付けることができるため、エイリアスの管理は、タグの管理よりも少し難しくなります。1 つの CMK の一部のプリンシパルへのアクセスを復元すると、異なる CMK への同じプリンシパルまたは他のプリンシパルアクセスを拒否できます。

このエラーを防ぐには、エイリアス管理権限が必要なプリンシパルにのみ付与し、エイリアス管理権限を制限するを、管理する必要があるエイリアスに設定します。エイリアスを更新または削除する前に、ポリシーを検索して、エイリアスに依存するアクセスを検出し、エイリアスに関連付けられているすべてのリージョンで CMK を検索します。

エイリアスクォータによりアクセスが拒否されました

によって CMK の使用が許可されているユーザーKMS: リソースエイリアス条件は、AccessDeniedCMK がデフォルトのCMK あたりのエイリアスこのアカウントとリージョンのクォータです。

アクセスを復元するには、CMK に関連付けられているエイリアスを削除して、クォータに準拠させます。または、別のメカニズムを使用して、CMK へのアクセス権をユーザーに付与します。

承認変更の遅延

タグとエイリアスに加えた変更は、CMK の承認に影響するまでに最大 5 分かかる場合があります。その結果、タグやエイリアスの変更は、承認に影響を与える前に API オペレーションからのレスポンスに反映される可能性があります。この遅延は、ほとんどの場合、最終的な整合性の短い遅延よりも長くなる可能性があります。AWS KMSオペレーション。

たとえば、特定のプリンシパルに CMK を使用することを許可する IAM ポリシーがある場合、"Purpose"="Test"タグ。次に、"Purpose"="Test"タグを CMK に追加します。ただし、TagResource操作が完了し、ListResourceTagsレスポンスがタグが CMK に割り当てられていることを確認した場合、プリンシパルは最大 5 分間CMK にアクセスできない可能性があります。

エラーを防ぐには、この予想される遅延をコードに組み込んでください。

エイリアスの更新によるリクエストの失敗

エイリアスを更新するときは、既存のエイリアスを別の CMK に関連付けます。

DecryptおよびReEncrypt要求を指定するエイリアス名またはエイリアス ARNエイリアスが暗号文を暗号化していない CMK に関連付けられているため、失敗する可能性があります。この状況は通常、IncorrectKeyExceptionまたはNotFoundException。または、リクエストに何もない場合KeyIdまたはDestinationKeyIdパラメーターを使用すると、操作が失敗することがあります。AccessDenied例外が発生します。これは、呼び出し元が暗号文を暗号化した CMK にアクセスできなくなったためです。

変更を追跡するには、CloudTrail ログでCreateAlias,UpdateAlias, およびDeleteAliasのログエントリ。また、の値を使用することもできますLastUpdatedDateフィールド内のListAliases応答を使用して変更を検出します。

たとえば、次のListAliasesレスポンスの例では、ProjectAlpha_Testエイリアスをkms:ResourceAliases条件が更新されました。その結果、エイリアスに基づくアクセス権を持つプリンシパルは、以前に関連付けられた CMK にアクセスできなくなります。代わりに、新しく関連付けられた CMK にアクセスできます。

$ aws kms list-aliases --query 'Aliases[?starts_with(AliasName, `alias/ProjectAlpha`)]' { "Aliases": [ { "AliasName": "alias/ProjectAlpha_Test", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Test", "TargetKeyId": "0987dcba-09fe-87dc-65ba-ab0987654321", "CreationDate": 1566518783.394, "LastUpdatedDate": 1605308931.903 }, { "AliasName": "alias/ProjectAlpha_Restricted", "AliasArn": "arn:aws:kms:us-west-2:111122223333:alias/ProjectAlpha_Restricted", "TargetKeyId": "1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1553410800.010, "LastUpdatedDate": 1553410800.010 } ] }

この変更に対する救済策は単純ではありません。エイリアスを再度更新して、元の CMK に関連付けることができます。ただし、操作を行う前に、その変更が現在関連付けられている CMK に与える影響を考慮する必要があります。プリンシパルが暗号化操作で後者 CMK を使用した場合、プリンシパルは引き続きそのプリンシパルにアクセスする必要があります。この場合、ポリシーを更新して、プリンシパルに両方の CMK を使用する権限があることを確認できます。

このようなエラーを防ぐことができます:エイリアスを更新する前に、ポリシーを検索して、エイリアスに依存するアクセスを検出します。次に、エイリアスに関連付けられているすべてのリージョンの CMK を取得します。エイリアス管理権限を必要とするプリンシパルにのみ付与し、エイリアス管理権限を制限するを、管理する必要があるエイリアスに設定します。