客户端应用CloudWatch日志功能是否应硬编码IAM凭证？

一、密钥存储的选择 #

你纠结的硬编码和配置文件其实本质没有太大的安全差异，不管哪种存储方式，只要是静态存在客户端包体内的，有逆向经验的攻击者都可以在半小时以内提取到完整密钥。如果一定要选的话，建议选择「拆分+混淆后的硬编码」：不要把完整的AK/SK写成整段明文字符串，拆成4-6段分别存在不同的代码文件的常量里，运行时再动态拼接，同时做基础的字符串混淆，能过滤掉90%以上的脚本小子和自动化爬取密钥的工具，已经足够覆盖大多数场景。
你提到的换密钥必须发版本的问题确实存在，这也是客户端内置静态密钥的固有缺陷，接受这个方案就必须接受这个成本。

二、恶意刷量的防范方案 #

你担心的密钥被盗后恶意写入产生高额成本的问题，可以通过几个低成本的手段规避：

• 先精简你的IAM权限，当前策略里的logs:DescribeLogGroups权限是多余的，客户端如果已经写死了目标LogGroup的ARN，完全不需要调用这个接口，直接删掉这条Statement减少攻击面。
• 给AWS账户的CloudWatch Logs服务单独设置预算告警，用AWS Budgets配置月度/日度消费阈值，超过阈值第一时间给你发通知，还可以配置自动动作，达到阈值后直接禁用对应用户的访问密钥，从根源上止损，最多损失一个阈值内的成本。
• 给IAM策略加上条件约束，比如添加aws:UserAgent校验，要求所有请求的UA必须是你应用自定义的特定字符串，虽然UA可以伪造，但能大幅提高攻击者的攻击成本，普通恶意使用者不会特意去抓包分析你的上报UA。
• 给对应LogGroup配置写入量告警，比如你日常日均写入量是5GB，就配置超过8GB时触发告警，能比预算告警更快发现异常刷量行为。

三、更标准化的行业替代方案 #

如果后续业务规模增长，不想再受静态密钥的限制，可以改成更通用的客户端日志上报架构：
在前端和CloudWatch之间加一层轻量的API网关，客户端不需要持有任何AWS密钥，只需要把日志上报到你自己的网关接口，网关侧做简单的请求校验、频率限制，确认是合法的应用请求后，再由网关侧把日志写入CloudWatch。这种方案完全规避了客户端密钥泄露的风险，是现在绝大多数互联网公司的标准做法，改造工作量也不大，用AWS API网关+Lambda组合就能快速实现，不需要额外维护服务器。

你当前的方案其实不算脱离常规实践，很多团队在初期资源有限、业务量不大的时候都会这么做，只要做好成本兜底的告警策略，完全可以正常运行，和你提到的App Center的内置密钥逻辑本质是一样的，不用过于担心。

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