创建授权 - AWS Key Management Service

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

创建授权

在创建授权之前,请了解用于自定义授权的选项。您可以使用授权约束来限制授权中的权限。此外,了解授予 CreateGrant 权限的相关信息。获得从授权创建授权的权限的委托人在其可以创建的授权中受到限制。

创建授予

要创建授权,请调用该CreateGrant操作。指定KMS密钥、被授权者委托人和允许的授权操作列表。您还可以指定一个可选的停用委托人。要自定义授权,请使用可选 Constraints 参数来定义授予约束

当您创建、停用或撤销授权时,可能会出现短暂的延迟(通常不到五分钟),才能使更改在整个 AWS KMS中可用。有关更多信息,请参阅最终一致性(用于授权)

例如,以下CreateGrant命令创建一个授权,允许有权担任该keyUserRole角色的用户对指定的对称KMS密钥调用 Decrypt 操作。授权使用 RetiringPrincipal 参数,指定可以停用授权的委托人。其中还包含一个授权约束,仅当请求中的加密上下文包含 "Department": "IT" 时才允许该权限。

$ aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextSubset={Department=IT}

如果您的代码重试该CreateGrant操作,或者使用自动重试请求的AWS SDK,请使用可选的 Nam e 参数来防止创建重复的授权。如果 AWS KMS 收到的授权CreateGrant请求具有与现有授权相同的属性(包括名称),则它会将该请求识别为重试,并且不会创建新的授权。您无法使用 Name 值来标识任何 AWS KMS 操作中的授权。

重要

不要在授权名称中包含机密或敏感信息。它可能以纯文本形式出现在 CloudTrail 日志和其他输出中。

$ aws kms create-grant \ --name IT-1234abcd-keyUserRole-decrypt \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextSubset={Department=IT}

有关演示如何通过多种编程语言创建授权的代码示例,请参阅 与 AWS SDK或CreateGrant一起使用 CLI

使用授权约束

授权约束设置授权给予被授权者委托人的权限的条件。在密钥策略或IAM策略中,授权约束取代条件密。每个授权约束值最多可以包含 8 个加密上下文对。每个授权约束中的加密上下文值不能超过 384 个字符。

重要

不要在此字段中包含机密或敏感信息。此字段可能会以纯文本形式显示在 CloudTrail 日志和其他输出中。

AWS KMS 支持两个授予限制,EncryptionContextEqualsEncryptionContextSubset,这两个约束都规定了加密操作请求中的加密上下文的要求。

加密上下文授权约束旨在与具有加密上下文参数的授权操作结合使用。

  • 加密上下文限制仅在授予对称加密KMS密钥时有效。使用其他KMS密钥进行的加密操作不支持加密上下文。

  • 对于 DescribeKeyRetireGrant 操作,加密上下文约束将被忽略。DescribeKeyRetireGrant 不包括加密上下文参数,但您可以将这些操作包含在具有加密上下文约束的授权中。

  • 您可以将授权中的加密上下文约束用于 CreateGrant 操作。加密上下文约束要求使用 CreateGrant 权限创建的任何授权具有同样严格或更严格的加密上下文约束。

AWS KMS 支持以下加密上下文授予限制。

EncryptionContextEquals

使用 EncryptionContextEquals 为允许的请求指定精确的加密上下文。

EncryptionContextEquals 要求请求中的加密上下文对与授权约束中加密上下文对区分大小写的完全匹配。上下文对可以按任意顺序显示,不过每一对中的键和值不能有改变。

例如,如果 EncryptionContextEquals 授权约束需要 "Department": "IT" 加密上下文对,则授权仅在请求中的加密上下文完全是 "Department": "IT" 时,允许指定类型的请求。

EncryptionContextSubset

使用 EncryptionContextSubset 来要求请求包含特定的加密上下文对。

EncryptionContextSubset 要求请求中包含授权约束中的所有加密上下文对(区分大小写的完全匹配),但请求也可以包含其他的加密上下文对。上下文对可以按任意顺序显示,不过每一对中的键和值不能有改变。

例如,如果 EncryptionContextSubset 授权约束需要 Department=IT 加密上下文对,则授权在请求中的加密上下文为 "Department": "IT" 或者包含 "Department": "IT" 以及其他加密上下文对(例如 "Department": "IT","Purpose": "Test")时,允许指定类型的请求。

要在对称加密密KMS钥的授权中指定加密上下文约束,请在CreateGrant操作中使用Constraints参数。此命令创建的授权将向被授权代入 keyUserRole 角色的用户调用 解密 操作的权限。不过,该权限仅在 Decrypt 请求中的加密上下文是 "Department": "IT" 加密上下文对时有效。

$ aws kms create-grant \ --key-id 1234abcd-12ab-34cd-56ef-1234567890ab \ --grantee-principal arn:aws:iam::111122223333:role/keyUserRole \ --operations Decrypt \ --retiring-principal arn:aws:iam::111122223333:role/adminRole \ --constraints EncryptionContextEquals={Department=IT}

生成的授权与以下项目类似。请注意,向 keyUserRole 角色授予的权限仅在 Decrypt 请求使用授权约束中指定的相同加密上下文对时有效。要查找KMS密钥上的授权,请使用ListGrants操作。

$ aws kms list-grants --key-id 1234abcd-12ab-34cd-56ef-1234567890ab { "Grants": [ { "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GrantId": "abcde1237f76e4ba7987489ac329fbfba6ad343d6f7075dbd1ef191f0120514a", "Operations": [ "Decrypt" ], "GranteePrincipal": "arn:aws:iam::111122223333:role/keyUserRole", "Constraints": { "EncryptionContextEquals": { "Department": "IT" } }, "CreationDate": 1568565290.0, "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "RetiringPrincipal": "arn:aws:iam::111122223333:role/adminRole" } ] }

为了满足 EncryptionContextEquals 授权约束,Decrypt 操作的请求中的加密上下文必须是 "Department": "IT" 对。来自被授予者委托人的以下请求将满足 EncryptionContextEquals 授权约束。

$ aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab\ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT

当授权约束为 EncryptionContextSubset 时,请求中的加密上下文对必须在授权约束中包含加密上下文对,不过请求也可以包括其他加密上下文对。以下授权约束要求请求中的一个加密上下文对是 "Deparment": "IT"

"Constraints": { "EncryptionContextSubset": { "Department": "IT" } }

来自被授权者委托人的以下请求将满足本示例中 EncryptionContextEqualEncryptionContextSubset 授权约束的要求。

$ aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT

但是,来自被授权者委托人的以下请求将满足 EncryptionContextSubset 授权约束,但不满足 EncryptionContextEquals 授权约束。

$ aws kms decrypt \ --key-id arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab \ --ciphertext-blob fileb://encrypted_msg \ --encryption-context Department=IT,Purpose=Test

AWS 服务通常在授予权限中使用加密上下文限制,从而允许它们使用您的KMS密钥 AWS 账户。例如,Amazon DynamoDB 使用类似下面的授权来获得为账户中的 DynamoDB 使用 AWS 托管式密钥 的权限。此授权中的 EncryptionContextSubset 授权约束使授权中的权限仅在请求中的加密上下文包含 "subscriberID": "111122223333""tableName": "Services" 对时有效。此授权限制意味着,该授权仅允许 DynamoDB 将KMS指定的密钥用于您的中的特定表。 AWS 账户

要获得此输出,请在您的账户中ListGrants对 Dynam AWS 托管式密钥 oDB 运行该操作。

$ aws kms list-grants --key-id 0987dcba-09fe-87dc-65ba-ab0987654321 { "Grants": [ { "Operations": [ "Decrypt", "Encrypt", "GenerateDataKey", "ReEncryptFrom", "ReEncryptTo", "RetireGrant", "DescribeKey" ], "IssuingAccount": "arn:aws:iam::111122223333:root", "Constraints": { "EncryptionContextSubset": { "aws:dynamodb:tableName": "Services", "aws:dynamodb:subscriberId": "111122223333" } }, "CreationDate": 1518567315.0, "KeyId": "arn:aws:kms:us-west-2:111122223333:key/0987dcba-09fe-87dc-65ba-ab0987654321", "GranteePrincipal": "dynamodb.us-west-2.amazonaws.com", "RetiringPrincipal": "dynamodb.us-west-2.amazonaws.com", "Name": "8276b9a6-6cf0-46f1-b2f0-7993a7f8c89a", "GrantId": "1667b97d27cf748cf05b487217dd4179526c949d14fb3903858e25193253fe59" } ] }

授予 CreateGrant 权限

授权可以包括调用 CreateGrant 操作的权限。但是,当被授权者委托人获取从授权中,而不是从策略中调用 CreateGrant 的权限时,该权限将收到限制。

  • 被授权者委托人只能创建允许父授权中部分或全部操作的授权。

  • 他们创建的授权中的授权约束必须至少与父授权中的约束一样严格。

这些限制不适用于从策略中获取 CreateGrant 权限的委托人,尽管它们的权限可以由策略条件限制。

例如,考虑一个授权,该授权允许被授权委托人调用 GenerateDataKeyDecryptCreateGrant 操作。我们将允许 CreateGrant 权限的授权称为父授权

# The original grant in a ListGrants response. { "Grants": [ { "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1572216195.0, "GrantId": "abcde1237f76e4ba7987489ac329fbfba6ad343d6f7075dbd1ef191f0120514a", "Operations": [ "GenerateDataKey", "Decrypt", "CreateGrant ] "RetiringPrincipal": "arn:aws:iam::111122223333:role/adminRole", "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GranteePrincipal": "arn:aws:iam::111122223333:role/keyUserRole", "Constraints": { "EncryptionContextSubset": { "Department": "IT" } }, } ] }

被授予者委托人可以使用此权限创建授权,其中包括原始授权中指定的任何操作子集,例如CreateGrantDecrypt。exampleUser子级授权不能包含其他操作,如 ScheduleKeyDeletion 或者 ReEncrypt

此外,子授权中的授权约束必须与父授权具有相同的限制或更严格的限制。例如,子授权可以添加对到父授权中的 EncryptionContextSubset 约束,但不能从中删除对。子授权可以将 EncryptionContextSubset 约束更改为 EncryptionContextEquals 约束,但不能反之。

IAM最佳做法不鼓励使用具有长期凭证的IAM用户。只要有可能,就使用提供临时证书的IAM角色。有关详细信息,请参阅《IAM用户指南》IAM中的安全最佳实践

例如,被授权者委托人可以使用从父级授权那里获得的 CreateGrant 权限以创建以下子级授权。子级授权中的操作是父级授权中操作的子集,并且授权约束更严格。

# The child grant in a ListGrants response. { "Grants": [ { "KeyId": "arn:aws:kms:us-west-2:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab", "CreationDate": 1572249600.0, "GrantId": "fedcba9999c1e2e9876abcde6e9d6c9b6a1987650000abcee009abcdef40183f", "Operations": [ "CreateGrant" "Decrypt" ] "RetiringPrincipal": "arn:aws:iam::111122223333:user/exampleUser", "Name": "", "IssuingAccount": "arn:aws:iam::111122223333:root", "GranteePrincipal": "arn:aws:iam::111122223333:user/anotherUser", "Constraints": { "EncryptionContextEquals": { "Department": "IT" } }, } ] }

子级授权中的被授权者委托人 anotherUser 可以使用它们的 CreateGrant 权限来创建授权。然而,anotherUser 创建的授权必须将操作包含在其父授权或子集中,并且授权约束必须相同或更严格。