英文:
AWS KMS service principal account isolation
问题
我有一个类似下面的KMS策略声明。
{
"Sid": "允许SNS使用密钥",
"Effect": "允许",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": [
"kms:DescribeKey",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
这个策略是否允许来自任何AWS帐户的SNS（或者我在Principal中提到的任何服务）访问我的KMS密钥？我找不到任何明确的文档。
英文:
I have a KMS policy statement like given below.
{
"Sid": "Allow use of the key by SNS",
"Effect": "Allow",
"Principal": {
"Service": "sns.amazonaws.com"
},
"Action": [
"kms:DescribeKey",
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*"
],
"Resource": "*"
}
Will this make SNS (Or, any service I mention as Principal) from any AWS account to access my KMS key? I couldn't find any clear documentation around it.
答案1
得分: 2
通过允许服务主体对KMS密钥执行一些操作，您并非直接允许访问AWS账户，而是允许访问内部AWS服务主体（不属于特定的AWS账户）。
例如，如果您有一个CloudWatch警报发布到加密的SNS主题，您需要在KMS资源策略中包含类似以下的语句：
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}]
}
然而，通过这样做，从技术上讲，您正在为另一个账户可能访问您的KMS密钥，假设该其他账户配置了一个CloudWatch警报以发布到您的SNS主题（假设SNS主题还允许从cloudwatch.amazonaws.com服务主体发布消息）。
这就是为什么强烈建议在定义密钥策略时添加条件键，以仅允许特定调用者账户或特定的AWS资源ARN访问，并避免潜在的混淆代理场景：
当密钥策略中的主体是AWS服务主体时，强烈建议您使用aws:SourceArn或aws:SourceAccount全局条件键，以及kms:EncryptionContext:context-key条件键。
引用自AWS密钥策略中的AWS服务权限。
英文:
By allowing a service principal to perform some actions over a KMS key, you are not allowing directly access to AWS accounts, but to the internal AWS service principal (which does not belong to an specific AWS account).
For instance, if you have a CloudWatch alarm publishing to an SNS encrypted topic, you will need to include into the KMS resource policy, an statement like:
{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Principal": {
"Service": "cloudwatch.amazonaws.com"
},
"Action": [
"kms:GenerateDataKey",
"kms:Decrypt"
],
"Resource": "*"
}]
}
However, by doing this you are technically giving potential access to your KMS key from another accounts, if that other accounts, for instance, configure a CloudWatch alarm to publish into your SNS topic (assuming the SNS topic also allows publishing messages from cloudwatch.amazonaws.com service principal).
Thats why it is strongly recommended to add conditions keys when defining a key policy, in order to allow access only from specific caller accounts or even specific AWS resource ARN's, and to avoid a potential confused deputy scenario:
> When the principal in a key policy statement is an AWS service principal, we strongly recommend that you use the aws:SourceArn or aws:SourceAccount global condition keys, in addition to the kms:EncryptionContext:context-key condition key.
Quote from Permissions for AWS services in key policies.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论