AWS KMS对称CMK加密的公开密文可跨账号解密，该场景下是否应改用非对称密钥？

先澄清你测试里的核心认知偏差 #

KMS对称CMK生成的密文Blob虽然内嵌了关联密钥的元数据，但不存在“谁拿到密文都能解密”的默认特性。你之前测到跨账号也能解密，本质是给这把对称CMK配了过度宽松的密钥策略（比如允许所有主体解密），不是密文本身的问题——KMS解密是强鉴权操作，哪怕你拿到密文，只要没有对应CMK的解密授权，不管用哪个账号的身份调用解密接口都会被拒。
另外你贴的示例代码还有语法问题：KeyId、Plaintext参数都没有加字符串引号，bytes()方法的入参也没有闭合括号，实际运行会直接报错。 #

非对称CMK的核心设计价值 #

• 权限天然解耦：对称CMK的加密、解密能力都绑定在同一把密钥上，一旦为了让第三方能加密放开了接口权限，很容易因为策略配置失误连带放开解密权限（就是你现在测试的这种踩坑场景）。而非对称CMK的公钥可以完全公开、自由导出，所有加密操作都可以离线完成，不需要调用AWS接口，也不需要任何AWS账号权限；私钥永远留在KMS内部不会导出，解密权限可以单独收紧管控，和加密权限完全隔离开。
• 支撑签名验签场景：非对称CMK可以做数据签名、身份验签，比如给发布的软件制品签名、验证API请求的合法性，这类能力是对称CMK完全不具备的。

非对称CMK不是只适用于账号内部闭环 #

恰恰相反，非对称CMK的设计初衷就是适配跨主体、公域的加密场景：
你可以把公钥放到公开仓库、官网、公开文档里，任何第三方拿到公钥都可以直接加密数据，哪怕把密文公开也不用担心泄露，只有持有对应私钥的授权主体才能解密。反过来如果用对称CMK做跨主体加密，必须给第三方开通KMS加密接口的调用权限，还要配置跨账号的密钥策略，不管是配置成本还是权限泄露风险都高很多。 #

把密文放公开GitHub的场景，换非对称CMK是更合理的选择 #

你的这个场景刚好踩中非对称CMK的最优适配区间：

• 你可以把非对称CMK的公钥直接放到公开仓库里，任何使用方都可以用公钥加密要上传的敏感数据，密文哪怕完全公开也没有泄露风险——因为只有你方持有私钥的授权主体能调用KMS解密，不会出现对称CMK那种策略配错导致密文裸奔的问题。
• 对比你当前用对称CMK的方案：如果要让第三方能加密数据，必须给第三方开通KMS加密接口的调用权限，还要配置跨账号/公网的密钥策略，一旦权限配错（比如像你测试那样放开了解密权限），公开的密文就等于没有任何防护。

注意：KMS非对称CMK单次加密最多只能处理4KB以内的明文，大体积数据的话还是要走信封加密逻辑：用非对称公钥加密一个临时数据密钥，再用临时密钥加密原始明文，和对称KMS的信封加密逻辑一致。 #

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