配置IAM策略限制解密dev KMS密钥加密的SSM参数失败求助

我需要创建一条IAM策略，允许用户查看所有SSM Parameter Store的参数值，但禁止解密由dev KMS密钥加密的参数。我编写了如下策略，但测试后发现仍能解密dev密钥加密的参数，求解决方法。

原IAM策略 #

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyDecryptForDevKey",
        "Effect": "Deny",
        "Action": "kms:Decrypt",
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "kms:RequestAlias": "dev"
            }
        }
    },
    {
        "Sid": "AllowDecryptIfNotDevKey",
        "Effect": "Allow",
        "Action": "kms:Decrypt",
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "kms:RequestAlias": "dev"
            }
        }
    },
    {
        "Sid": "GetSSMParameters",
        "Effect": "Allow",
        "Action": [
            "ssm:GetParameter",
            "ssm:GetParameters",
            "ssm:GetParametersByPath"
        ],
        "Resource": "*"
    }
]
}

UI中显示的权限定义 #

显式拒绝 #

允许权限 #

测试步骤 #

1. 创建类型为SecureString、由dev密钥加密的参数；
2. 创建另一个类型为SecureString、由非dev密钥加密的参数；
3. 创建信任实体类型为AWS账户的角色testing-role；
4. 创建包含上述权限的IAM策略并附加到该角色；
5. 在UI中切换到testing-role角色；
6. 尝试通过切换Show decrypted value查看参数值。

解决方案 #

问题核心在于kms:RequestAlias条件的适用场景：当通过SSM Parameter Store解密参数时，SSM会自动将密钥别名解析为ARN并传递给KMS，请求中不会携带RequestAlias参数，因此原策略的条件无法触发拒绝规则。

方案一：使用kms:KeyAlias条件匹配密钥别名 #

替换原策略中的kms:RequestAlias为kms:KeyAlias，注意别名需要使用完整格式alias/dev：

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyDecryptForDevKey",
        "Effect": "Deny",
        "Action": "kms:Decrypt",
        "Resource": "*",
        "Condition": {
            "StringEquals": {
                "kms:KeyAlias": "alias/dev"
            }
        }
    },
    {
        "Sid": "AllowDecryptIfNotDevKey",
        "Effect": "Allow",
        "Action": "kms:Decrypt",
        "Resource": "*",
        "Condition": {
            "StringNotEquals": {
                "kms:KeyAlias": "alias/dev"
            }
        }
    },
    {
        "Sid": "GetSSMParameters",
        "Effect": "Allow",
        "Action": [
            "ssm:GetParameter",
            "ssm:GetParameters",
            "ssm:GetParametersByPath"
        ],
        "Resource": "*"
    }
]
}

方案二：直接指定禁止的KMS密钥ARN作为资源（更安全） #

将拒绝语句的Resource直接设置为dev密钥的ARN，跳过条件匹配，规则更精准：

{
"Version": "2012-10-17",
"Statement": [
    {
        "Sid": "DenyDecryptForDevKey",
        "Effect": "Deny",
        "Action": "kms:Decrypt",
        "Resource": "arn:aws:kms:你的区域:你的账户ID:key/你的dev密钥ID"
    },
    {
        "Sid": "AllowDecryptIfNotDevKey",
        "Effect": "Allow",
        "Action": "kms:Decrypt",
        "Resource": "*"
    },
    {
        "Sid": "GetSSMParameters",
        "Effect": "Allow",
        "Action": [
            "ssm:GetParameter",
            "ssm:GetParameters",
            "ssm:GetParametersByPath"
        ],
        "Resource": "*"
    }
]
}

补充说明 #

• kms:RequestAlias仅在直接调用KMS API并传入别名作为参数时生效，SSM调用KMS的场景不适用；
• 使用密钥ARN作为资源的方案优先级更高，IAM资源匹配比条件匹配更直接，能有效避免逻辑漏洞。

内容的提问来源于stack exchange，提问作者Somethingwhatever