翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# の ABAC AWS KMS
属性ベースのアクセスコントロール (ABAC) は、属性に基づいてアクセス許可を定義する認可戦略です。 は、KMS キーに関連付けられたタグとエイリアスに基づいてカスタマーマネージドキーへのアクセスを制御できるようにすることで、ABAC AWS KMS をサポートします。で ABAC を有効にするタグとエイリアスの条件キーは、ポリシーを編集したり許可を管理したりすることなく、プリンシパルに KMS キーの使用を許可する強力で柔軟な方法 AWS KMS を提供します。ただし、プリンシパルが誤ってアクセスを許可されたり拒否されないように、注意してこれらの機能を使用する必要があります。
ABAC を使用する場合は、タグとエイリアスを管理する許可が、アクセス制御許可になることに注意してください。タグまたはエイリアスに依存するポリシーをデプロイする前に、すべての KMS キーの既存のタグとエイリアスを把握していることを確認してください。エイリアスの追加、削除、更新時、およびキーのタグ付けおよびタグ解除時には、妥当な予防措置を講じます。タグとエイリアスを必要とするプリンシパルにのみ管理する許可を付与し、管理できるタグとエイリアスを制限します。
**注意事項**
ABAC を使用するときは AWS KMS、タグとエイリアスを管理するアクセス許可をプリンシパルに付与することに注意してください。タグまたはエイリアスを変更すると、KMS キーに対するアクセス許可を、許可または拒否する可能性があります。キーポリシーを変更したり、グラントを作成したりする許可を持たないキー管理者も、タグやエイリアスを管理する許可があれば、KMS キーへのアクセスを制御できます。
タグとエイリアスの変更が KMS キーの認可に影響を及ぼすまでに最長 5 分かかることがあります。最近の変更は、認可に影響を与える前に API オペレーションで表示される場合があります。
エイリアスに基づいて KMS キーへのアクセスを制御するには、条件キーを使用する必要があります。ポリシーステートメントの `Resource` 要素のエイリアスを使用して KMS キーを表すことはできません。エイリアスが `Resource` 要素で表示される場合、ポリシーステートメントは、関連付けられた KMS キーではなく、エイリアスに適用されます。
**詳細はこちら**
+ 例を含む ABAC AWS KMS のサポートの詳細については、[エイリアスを使用して KMS キーへのアクセスを制御する](alias-authorization.md)「」および「」を参照してください[タグを使用して KMS キーへのアクセスを制御する](tag-authorization.md)。
+ タグを使用してリソースへのアクセス AWS を制御する方法の詳細については、*IAM ユーザーガイド*の[「ABAC for AWSとは](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html)」および[「リソースタグを使用した AWS リソースへのアクセスの制御](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_tags.html)」を参照してください。
## の ABAC 条件キー AWS KMS
タグとエイリアスに基づいて KMS キーへのアクセスを認可するには、キーポリシーまたは IAM ポリシーで次の条件キーを使用します。
| ABAC 条件キー | 説明 | ポリシータイプ | AWS KMS オペレーション |
| --- | --- | --- | --- |
| [aws:ResourceTag](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-resourcetag) | KMS キーのタグ (キーと値) が、ポリシーのタグ (キーと値) またはタグパターンと一致する | IAM ポリシーのみ | KMS キーリソースのオペレーション 2 |
| [aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) | リクエスト内のタグ (キーと値) が、ポリシー内のタグ (キーと値) またはタグパターンと一致する | キーポリシーと IAM ポリシー 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)、[UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) |
| [aws:TagKeys](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-tagkeys) | リクエスト内のタグキーが、ポリシーのタグキーと一致する | キーポリシーと IAM ポリシー 1 | [TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html)、[UntagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_UntagResource.html) |
| [kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) | KMS キーに関連付けられたエイリアスが、ポリシーのエイリアスまたはエイリアスパターンと一致する | IAM ポリシーのみ | KMS キーリソースのオペレーション 2 |
| [kms:RequestAlias](conditions-kms.md#conditions-kms-request-alias) | リクエスト内の KMS キーを表すエイリアスが、ポリシーのエイリアスまたはエイリアスパターンと一致する。 | キーポリシーと IAM ポリシー 1 | [Cryptographic operations](kms-cryptography.md#cryptographic-operations)、[DescribeKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_DescribeKey.html)、[GetPublicKey](https://docs.aws.amazon.com/kms/latest/APIReference/API_GetPublicKey.html) |
1 キーポリシーで使用できる条件キーは、IAM ポリシーでも使用できます。ただし、[キーポリシーによって許可される場合](key-policy-default.md#key-policy-default-allow-root-enable-iam)に限ります。
2 *KMS キーのリソースオペレーション*は、特定の KMS キーに対して認可されるオペレーションです。KMS キーリソースオペレーションを識別するには、[AWS KMS アクセス許可の表](kms-api-permissions-reference.md#kms-api-permissions-reference-table)で、オペレーションの `Resources` 列の KMS キー値を探します。
例えば、これらの条件キーを使用して、次のポリシーを作成できます。
+ 特定のエイリアスまたはエイリアスパターンを持つ KMS キーを使用するアクセス許可を付与する `kms:ResourceAliases` を備えた IAM ポリシー。これは、タグに依存するポリシーとは少し異なります。ポリシーでエイリアスパターンを使用できますが、各エイリアスは AWS アカウント および リージョンで一意である必要があります。これにより、KMS キーのキー ARN をポリシーステートメントに表示せずに、選択した KMS キーのセットにポリシーを適用できます。セットの KMS キーを追加または削除するには、KMS キーのエイリアスを変更します。
+ `Encrypt` リクエストがエイリアスを使用して KMS キーを識別する場合にのみ、`Encrypt` オペレーションでプリンシパルの KMS キー使用を許可する `kms:RequestAlias` を備えたキーポリシー。
+ 特定のタグキーとタグ値を持つ KMS キーを使用するアクセス許可を拒否する `aws:ResourceTag/tag-key` を備えた IAMポリシー。これにより、KMS キーのキー ARN をポリシーステートメントに表示せずに、選択した KMS キーのセットにポリシーを適用できます。セットの KMS キーを追加または削除するには、KMS キーをタグ付けまたはタグ解除します。
+ プリンシパルが `"Purpose"="Test"` KMS キータグのみを削除することを許可する `aws:RequestTag/tag-key` を備えた IAMポリシー。
+ `Restricted` タグキーで KMS キーをタグ付けまたはタグ解除する許可を拒否する `aws:TagKeys` を備えた IAMポリシー。
ABAC は、アクセス管理を柔軟かつスケーラブルにします。例えば、`aws:ResourceTag/tag-key` 条件キーを使用して、KMS キーが `Purpose=Test` タグを持つ場合にのみ、プリンシパルが指定されたオペレーションに KMS キーを使用することを許可する IAM ポリシーを作成します。このポリシーは、 AWS アカウントのすべてのリージョンの KMS キーに適用されます。
ユーザーまたはロールにアタッチされると、以下の IAM ポリシーにより、プリンシパルは指定されたオペレーションの `Purpose=Test` タグで既存のKMS キーを使用できるようになります。新規または既存の KMS キーにこのアクセスを提供するためにポリシーを変更する必要はありません。単に、KMS キーに `Purpose=Test` タグをアタッチします。同様に、`Purpose=Test` タグでこのアクセスを KMS キーから削除するには、タグを編集または削除します。
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
ただし、この機能を使用する場合は、タグとエイリアスを管理する際に注意が必要です。タグまたはエイリアスを追加、変更、削除する際に、KMS キーへのアクセスを誤って許可または拒否する可能性があります。キーポリシーを変更したり、グラントを作成したりする許可を持たないキー管理者も、タグとエイリアスを管理する許可があれば、KMS キーへのアクセスを制御できます。このリスクを軽減するには、[タグおよび[エイリアス](alias-access.md#alias-access-limiting)を管理する許可の制限](tag-permissions.md#tag-permissions-conditions)を検討します。例えば、選択したプリンシパルのみが `Purpose=Test` タグを管理できるようにします。詳細については、「[エイリアスを使用して KMS キーへのアクセスを制御する](alias-authorization.md)」および「[タグを使用して KMS キーへのアクセスを制御する](tag-authorization.md)」を参照してください。
## タグまたはエイリアス
AWS KMS は、タグとエイリアスの ABAC をサポートしています。どちらのオプションも、柔軟でスケーラブルなアクセス制御方法を提供しますが、互いに若干異なります。
タグを使用するか、特定の使用パターンに基づいてエイリアス AWS を使用するかを選択できます。例えば、すでにほとんどの管理者にタグ付け許可を付与している場合は、エイリアスに基づいて認可の方法を制御する方が簡単です。または、[KMS キーごとのエイリアス](resource-limits.md#aliases-per-key)のクォータに近づいている場合、タグに基づく認可の方法の方が得策かもしれません。
以下は、一般的な利点です。
**タグベースのアクセスコントロールの利点**
+ 異なるタイプの AWS リソースに対して同じ認可メカニズム。
同じタグまたはタグキーを使用して、Amazon Relational Database Service (Amazon RDS) クラスター、Amazon Elastic Block Store (Amazon EBS) ボリューム、KMS キーなど、複数のリソースタイプへのアクセスを制御できます。この機能により、従来のロールベースのアクセス制御よりも柔軟性が高い、複数の異なる認可モデルが可能になります。
+ KMS キーグループへのアクセスを認可します。
タグを使用すると、同じ AWS アカウント およびリージョンの KMS キーグループへのアクセスを管理できます。選択した KMS キーに同じタグまたはタグキーを割り当てます。次に、タグまたはタグキーに基づいて、シンプルで保守が容易なポリシーステートメントを作成します。認可グループの KMS キーを追加または削除するには、タグを追加または削除します。ポリシーを編集する必要はありません。
**エイリアスベースのアクセス制御の利点**
+ エイリアスに基づいて暗号化オペレーションへのアクセスを認可します。
属性に対するほとんどのリクエストベースのポリシー条件 ([aws:RequestTag/*tag-key*](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html#condition-keys-requesttag) など) は、属性を追加、編集、削除するオペレーションにのみ影響します。ただし、[kms:RequestAlias](conditions-kms.md#conditions-kms-request-alias) 条件キーは、リクエストの KMS キーの識別に使用されるエイリアスに基づき、暗号化オペレーションへのアクセスを制御します。例えば、`Encrypt` オペレーションで KMS キーを使用するプリンシパルに、`KeyId` パラメータ値が `alias/restricted-key-1` の場合にのみ、アクセス許可を付与できます。この条件を満たすには、次のすべてが必要です。
+ KMS キーがそのエイリアスに関連付けられている必要があります。
+ リクエストで、KMS キーを識別するためにエイリアスを使用する必要があります。
+ `kms:RequestAlias` を条件として、プリンシパルが KMS キーを使用するアクセス許可が必要です。
これは、アプリケーションが一般的にエイリアス名またはエイリアス ARN を使用して KMS キーを参照する場合に特に便利です。
+ きわめて限定されたアクセス許可を付与します。
エイリアスは、 AWS アカウント および リージョンで一意である必要があります。結果として、プリンシパルに、エイリアスに基づいて KMS キーへのアクセスを許可することは、タグに基づいてプリンシパルにアクセスを許可するよりもはるかに制限が厳しくなります。エイリアスとは異なり、タグは同じアカウントとリージョン内の複数の KMS キーに割り当てることができます。選択すると、エイリアスパターン (`alias/test*` など) を使用して、プリンシパルに同じアカウントとリージョン内の KMS キーグループへのアクセスを許可します。ただし、特定のエイリアスへのアクセスを許可または拒否すると、KMS キーのきわめて厳密な制御が可能になります。
# の ABAC のトラブルシューティング AWS KMS
タグとエイリアスに基づいて KMS キーへのアクセスを制御することは、便利で強力です。ただし、いくつかの予測可能なエラーが発生しやすいため、予防する必要があります。
## タグの変更によりアクセスが変更される
タグが削除されるかその値が変更されると、そのタグのみに基づいて KMS キーにアクセスするプリンシパルは、KMS キーへのアクセスを拒否されます。これは、拒否ポリシーステートメントに含まれるタグが KMS キーに追加された場合にも発生します。ポリシー関連のタグを KMS キーに追加すると、KMS キーへのアクセスを拒否されるプリンシパルにアクセスを許可できます。
例えば、プリンシパルに、`Project=Alpha` タグに基づく KMS キーへのアクセス許可 (以下の例の、IAM ポリシーステートメントによって付与されるアクセス許可など) があるとします。
------
#### [ JSON ]
****
```
{
"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"
}
}
}
]
}
```
------
タグがその KMS キーから削除されるか、タグの値が変更されると、プリンシパルには指定されたオペレーションで KMS キーを使用するアクセス許可がなくなります。これは、プリンシパルがカスタマーマネージドキーを使用する AWS サービスでデータの読み取りまたは書き込みを試みると明らかになる場合があります。タグの変更を追跡するには、CloudTrail ログで [TagResource](ct-tagresource.md) または [UntagResource エントリ](ct-untagresource.md)を確認します。
ポリシーを更新せずにアクセスを復元するには、KMS キーのタグを変更します。このアクションは、 AWS KMS全体で有効な期間中、短い期間を除いて影響は最小限です。このようなエラーを防ぐには、タグ付けとタグ解除の許可を必要なプリンシパルのみに付与し、[タグ付け許可を、管理する必要があるタグに制限します](tag-permissions.md#tag-permissions-conditions)。タグを変更する前にポリシーを検索して、タグに依存するアクセスを検出し、タグを持つすべてのリージョンで KMS キーを取得します。特定のタグが変更されるときは、Amazon CloudWatch アラームの作成を検討してください。
## エイリアスの変更によるアクセス変更
エイリアスが削除されたり、別の KMS キーに関連付けられている場合、そのエイリアスのみに基づいて KMS キーにアクセスするプリンシパルは、KMS キーへのアクセスを拒否されます。これは、KMS キー に関連付けられたエイリアスが拒否ポリシーステートメントに含まれる場合にも発生します。ポリシー関連のエイリアスを KMS キーに追加すると、KMS キーへのアクセスを拒否されるプリンシパルへのアクセスを許可できます。
例えば、次の IAM ポリシーステートメントは、[kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 条件キーを使用して、指定されたエイリアスを持つアカウントの異なるリージョンの KMS キーへのアクセスを許可します。
------
#### [ JSON ]
****
```
{
"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](ct-createalias.md)、[UpdateAlias](ct-updatealias.md)、[DeleteAlias](ct-deletealias.md) エントリを確認します。
ポリシーを更新せずにアクセスを復元するには、KMS キーに関連付けられたエイリアスを変更します。各エイリアスは、アカウントおよびリージョン内の 1 つの KMS キーのみにしか関連付けできないため、エイリアスの管理は、タグの管理よりも若干難しくなります。ある KMS キーの一部のプリンシパルへのアクセスを復元すると、異なる KMS キーの同じプリンシパルまたは他のプリンシパルへのアクセスが拒否されることがあります。
このエラーを防ぐには、エイリアス管理許可を必要なプリンシパルのみに付与し、[エイリアス管理許可の制限](alias-access.md#alias-access-limiting)を管理する必要があるエイリアスに制限します。エイリアスを更新または削除する前に、ポリシーを検索してエイリアスに依存するアクセスを検出し、エイリアスに関連付けられているすべてのリージョンで KMS キーを検索します。
## エイリアスクォータによりアクセスが拒否された
[kms:ResourceAliases](conditions-kms.md#conditions-kms-resource-aliases) 条件によって KMS キーの使用を認可されているユーザーには、KMS キーがそのアカウントまたはリージョンの、デフォルトの[KMS キーあたりのエイリアス](resource-limits.md#aliases-per-key)クォータを超えた場合、`AccessDenied` の例外が適用されます。
アクセスを復元するには、KMS キーに関連付けられたエイリアスを削除して、クォータに適合させます。または、別のメカニズムを使用して、ユーザーに KMS キーへのアクセスを許可します。
## 認可変更の遅延
タグとエイリアスを変更すると、KMS キーの認可に影響を及ぼすまでに最大 5 分かかる場合があります。結果として、タグやエイリアスの変更が認可に影響を与える前に、API オペレーションからのレスポンスに反映される可能性があります。この遅延は、ほとんどの AWS KMS オペレーションに影響する短い結果整合性遅延よりも長くなる可能性があります。
例えば、特定のプリンシパルに `"Purpose"="Test"` タグで KMS キーの使用を許可する IAM ポリシーなどです。次に、`"Purpose"="Test"`タグを KMS キーに追加します。[TagResource](https://docs.aws.amazon.com/kms/latest/APIReference/API_TagResource.html) オペレーションが完了し、[ListResourceTags](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListResourceTags.html) レスポンスによって、タグが KMS キーに割り当てられていることが確認されても、プリンシパルは KMS キーに最大 5 分間アクセスできない場合があります。
エラーを防ぐには、この予想される遅延をコードに組み込みます。
## エイリアスの更新によるリクエストの失敗
エイリアスを更新するときは、既存のエイリアスを別の KMS キーに関連付けます。
[エイリアス名](concepts.md#key-id-alias-name)または[エイリアス ARN](concepts.md#key-id-alias-ARN) を指定する [Decrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_Decrypt.html) および [ReEncrypt](https://docs.aws.amazon.com/kms/latest/APIReference/API_ReEncrypt.html) リクエストは、エイリアスが暗号文を暗号化していない KMS キーに関連付けられたため、失敗することがあります。この状況は通常、`IncorrectKeyException` または `NotFoundException` を返します。または、リクエストに `KeyId` または `DestinationKeyId` パラメータがない場合、発信者が暗号文を暗号化した KMS キーにアクセスできなくなったため、`AccessDenied` の例外により、オペレーションは失敗する可能性があります。
CloudTrail ログで [CreateAlias](ct-createalias.md)、[UpdateAlias](ct-updatealias.md)、[DeleteAlias](ct-deletealias.md) ログエントリを探して、変更を追跡できます。[ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html) レスポンスの `LastUpdatedDate` フィールド値を使用して、変更を検出することもできます。
例えば、次の [ListAliases](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListAliases.html) レスポンスの例では、`kms:ResourceAliases` 条件の `ProjectAlpha_Test` エイリアスが更新されたことを確認できます。この結果、エイリアスに基づくアクセス許可を持つプリンシパルは、以前に関連付けられた KMS キーにアクセスできなくなります。代わりに、新しく関連付けられた KMS キーにアクセスできます。
```
$ 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
}
]
}
```
この変更を回避するのは簡単ではありません。エイリアスを再度更新して、元の KMS キーに関連付けることができます。ただし、オペレーションを行う前に、その変更が現在関連付けられている KMS キーに及ぼす影響を考慮する必要があります。プリンシパルが暗号化オペレーションで後者の KMS キーを使用した場合は、引き続きそのキーにアクセスする必要がある可能性もあります。この場合はポリシーを更新し、プリンシパルに両方の KMS キーを使用するアクセス許可があることを確認します。
エイリアスを更新する前にポリシーを検索して、エイリアスに依存するアクセスを検出することで、このようなエラーを防ぐことができます。次に、エイリアスに関連付けられているすべてのリージョンで KMS キーを取得します。エイリアス管理許可を、必要とするプリンシパルにのみ付与し、[エイリアス管理許可の制限](alias-access.md#alias-access-limiting)を、管理する必要があるエイリアスに設定します。