AWS KMS の ABAC - AWS Key Management Service

AWS KMS の ABAC

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

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

Notes

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

タグとエイリアスの変更が KMS キーの認可に影響を及ぼすまでに最長 5 分かかることがあります。最近の変更は、認可に影響を与える前に API オペレーションで表示される場合があります。

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

詳細情報

AWS KMS のABAC 条件キー

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

ABAC 条件キー 説明 ポリシータイプ AWS KMS オペレーション
aws:ResourceTag KMS キーのタグ (キーと値) が、ポリシーのタグ (キーと値) またはタグパターンと一致する IAM ポリシーのみ KMS キーリソースのオペレーション 2
aws:RequestTag/tag-key リクエスト内のタグ (キーと値) が、ポリシー内のタグ (キーと値) またはタグパターンと一致する キーポリシーと IAM ポリシー 1 TagResourceUntagResource
aws:TagKeys リクエスト内のタグキーが、ポリシーのタグキーと一致する キーポリシーと IAM ポリシー 1 TagResourceUntagResource
kms:ResourceAliases KMS キーに関連付けられたエイリアスが、ポリシーのエイリアスまたはエイリアスパターンと一致する IAM ポリシーのみ KMS キーリソースのオペレーション 2
kms:RequestAlias リクエスト内の KMS キーを表すエイリアスが、ポリシーのエイリアスまたはエイリアスパターンと一致する。 キーポリシーと IAM ポリシー 1 Cryptographic operationsDescribeKeyGetPublicKey

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

2 KMS キーのリソースオペレーションは、特定の KMS キーに対して認可されるオペレーションです。KMS キーリソースオペレーションを識別するには、AWS KMS アクセス許可の表で、オペレーションの Resources 列の KMS キー値を探します。

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

  • 特定のエイリアスまたはエイリアスパターンを持つ KMS キーを使用するアクセス許可を付与する aws:ResourceAliases を備えた IAM ポリシー。これは、タグに依存するポリシーとは少し異なります。ポリシーでエイリアスパターンを使用できますが、各エイリアスは AWS アカウント とリージョンで、一意である必要があります。これにより、KMS キーのキー ARN をポリシーステートメントに表示せずに、選択した KMS キーのセットにポリシーを適用できます。セットの KMS キーを追加または削除するには、KMS キーのエイリアスを変更します。

  • Encrypt リクエストがエイリアスを使用して KMS キーを識別する場合にのみ、Encrypt オペレーションでプリンシパルの KMS キー使用を許可する aws: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 キーから削除するには、タグを編集または削除します。

{ "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 キーへのアクセスを制御できます。このリスクを軽減するには、タグおよびエイリアスを管理する許可の制限を検討します。例えば、選択したプリンシパルのみが Purpose=Test タグを管理できるようにします。詳細については、「エイリアスを使用して KMS キーへのアクセスを制御する」および「タグを使用してKMS キーへのアクセスを制御する」を参照してください。

タグまたはエイリアス

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

タグを使用するか、特定の AWS 使用パターンに基づいてエイリアスを使用するかを決定します。例えば、すでにほとんどの管理者にタグ付け許可を付与している場合は、エイリアスに基づいて認可戦略を制御する方が簡単です。または、KMS キーごとのエイリアスのクォータに近づいている場合、タグに基づく認可戦略の方が得策かもしれません。

以下は、一般的な利点です。

タグベースのアクセスコントロールの利点

  • 異なるタイプの AWS リソースで同じ認可メカニズム。

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

  • KMS キーグループへのアクセスを認可します。

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

エイリアスベースのアクセス制御の利点

  • エイリアスに基づいて暗号化オペレーションへのアクセスを認可します。

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

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

    • リクエストで、KMS キーを識別するためにエイリアスを使用する必要があります。

    • kms:RequestAlias を条件として、プリンシパルが KMS キーを使用するアクセス許可が必要です。

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

  • きわめて限定されたアクセス許可を付与します。

    エイリアスは AWS アカウント とリージョン内で、一意である必要があります 結果として、プリンシパルに、エイリアスに基づいて KMS キーへのアクセスを許可することは、タグに基づいてプリンシパルにアクセスを許可するよりもはるかに制限が厳しくなります。エイリアスとは異なり、タグは同じアカウントとリージョン内の複数の KMS キーに割り当てることができます。選択すると、エイリアスパターン (alias/test* など) を使用して、プリンシパルに同じアカウントとリージョン内の KMS キーグループへのアクセスを許可します。ただし、特定のエイリアスへのアクセスを許可または拒否すると、KMS キーのきわめて厳密な制御が可能になります。

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

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

タグの変更によりアクセスが変更される

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

例えば、プリンシパルに、Project=Alpha タグに基づく KMS キーへのアクセス許可 (以下の例の、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" } } } ] }

タグがその KMS キーから削除されるか、タグの値が変更されると、プリンシパルには指定されたオペレーションで KMS キーを使用するアクセス許可がなくなります。これは、プリンシパルが、カスタマーマネージドキーを使用する AWS サービスのデータを読み取る、または書き込む際に明らかになります。タグの変更を追跡するには、TagResource または UntagResource entries の CloudTrail ログを確認します。

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

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

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

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

{ "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 ログで、CreateAliasUpdateAliasDeleteAlias エントリを確認します。

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

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

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

kms:ResourceAliases 条件によって KMS キーの使用を認可されているユーザーには、KMS キーがそのアカウントまたはリージョンの、デフォルトのKMS キーあたりのエイリアスクォータを超えた場合、AccessDenied の例外が適用されます。

アクセスを復元するには、KMS キーに関連付けられたエイリアスを削除して、クォータに適合させます。または、別のメカニズムを使用して、ユーザーに KMS キーへのアクセスを許可します。

認可変更の遅延

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

例えば、特定のプリンシパルに "Purpose"="Test" タグで KMS キーの使用を許可する IAM ポリシーなどです。次に、"Purpose"="Test"タグを KMS キーに追加します。TagResource オペレーションが完了し、ListResourceTags レスポンスによって、タグが KMS キーに割り当てられていることが確認されても、プリンシパルは KMS キーに最大 5 分間アクセスできない場合があります。

エラーを防ぐには、この予想される遅延をコードに組み込みます。

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

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

エイリアス名またはエイリアス ARN を指定する Decrypt および ReEncrypt リクエストは、エイリアスが暗号化テキストを暗号化していない KMS キーに関連付けられたため、失敗することがあります。この状況は通常、IncorrectKeyException または NotFoundException を返します。または、リクエストに KeyId または DestinationKeyId パラメータがない場合、発信者が暗号文を暗号化した KMS キーにアクセスできなくなったため、AccessDenied の例外により、オペレーションは失敗する可能性があります。

CloudTrail ログで CreateAliasUpdateAliasDeleteAlias ログエントリを探して、変更を追跡できます。ListAliases レスポンスの LastUpdatedDate フィールド値を使用して、変更を検出することもできます。

例えば、次の ListAliases レスポンスの例では、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 キーを取得します。エイリアス管理許可を、必要とするプリンシパルにのみ付与し、エイリアス管理許可の制限を、管理する必要があるエイリアスに設定します。