产品和基础设施工程团队并不总是与安全工程团队的利益保持一致。当产品和基础设施专注于驱动业务价值和交付实用的解决方案时，安全性专注于检测、预防和补救，这些似乎没有立即的价值。就像保险单一样，在还没有发生事故的情况下，为什么它值得花钱或付出努力，这并不是很明显。
与传统的识别漏洞、应用补救和通过案例管理跟踪的循环不同，我发现倡导同时提供业务价值的安全解决方案要有效得多。例如，使用基于OAuth和Iam的访问而不是静态密钥和加密，而不是更细粒度的访问控制，可以显著简化基础设施，降低复杂性，减轻操作负担，使它们对产品和平台工程团队都非常有吸引力。
示例:将静态密钥替换为基于Iam的OAuth
传统上，系统之间的访问是通过静态密钥对实现的。虽然很常见，但由于管理密钥生成、轮换和应用程序生命周期的复杂性，这种方法经常导致可靠性问题。平台团队还必须投入大量精力来监控和检测异常情况，以防止意外的密钥泄露，例如通过Slack或GitHub意外暴露。即使开发人员报告并修复泄漏，轮换过程也会很费力。更糟糕的是，开发人员可能会认为这是一个低风险的泄漏，并且泄漏可能不会被报告。
根据ISO/IEC27001:2022,A.9.1：
组织必须实施政策和程序来控制对信息的访问，确保只有那些有合法需求的人才能访问信息。
平台团队有两种选择：
（1）添加更复杂的访问控制和审批流程。
（2）用基于Iam的OAuth替换静态密钥-秘密对。
第一种选择可能很诱人，因为它只需要添加一个像ServiceNow这样的供应商，而不需要额外的工作。然而，第二种选择虽然需要更多的实现更改，但更安全，并且减少了应用程序团队更新秘密、重新启动pod和确保秘密被提取的操作负担。事实上，最近出现了几家专注于非人类身份认证的公司，如P0和Clutch，突显了更安全和高效的认证方法的发展趋势。
这个示例演示了一种不同的安全实现方法如何改进安全标准、简化基础设施体系结构并提高开发人员的总体速度。
数据加密的案例
数据加密是另一个例子，尽管安全团队不能简单地添加一个供应商，但从安全性和体系结构设计的角度来看，它显著降低了所有平台的复杂性和实现工作。
典型的数据流包括:
- 源应用发布数据
- 数据被发送到传输层(例如，Kafka,Kinesis)
- 数据存储在数据库(MySQL,Postgres)，数据仓库(Redshift,Snowflake)或数据湖(S3,Databricks)中。
不同的解决方案对“访问控制”有不同的解释和实现，导致平台团队实现他们自己的版本。这通常会导致整个公司出现碎片化的实现。对于安全工程师来说，实现越分散，实现标准化的治理、控制和监视就越困难，最终使系统不那么安全。
结论
使用数据加密，只需使用加密密钥配置一次访问权限，然后就可以在数据流的不同阶段将其分配给各个工作负载。这大大降低了跨不同平台实现和调整权限策略所涉及的复杂性。加密确保数据在所有平台上得到一致的保护，简化了治理和控制，同时增强了整体安全性。
