作者 | Dotan Nahum
译者 | 盖磊
策划 | 丁晓昀
审校 | 冬雨
通常，安全属于信息安全团队的工作范畴。这样的网络安全实现方式曾一度运作良好，直至最近几年才发生变化。
向云计算基础设施的转变，造就了分散化的软件开发环境，进而推动了软件开发在速度和规模上的增长。DevOps 为软件开发全生命周期提供了更丰富的服务，有助于开发团队更快速地实现敏捷的软件创建、测试和实施。但 DevOps 同时引入了新的网络安全漏洞，这是传统的信息安全孤岛所无法管理的。为保护 DevOps 环境，以敏感信息（Secret）管理为主责的 DevSecOps 部门应运而生。
1 网络安全是必须的
毫无疑问，云安全已成为 DevOps 团队不可分割的职责。团队必须在云安全管理（Cloud Security Management，CSM）上积极作为。
2 云安全：敏感信息及防泄露方法
现代开发人员在创建软件之外，还必须保护组织的敏感信息免受未经授权或身份验证的访问，并将其落实在开发过程中。那什么是“敏感信息”？敏感信息指支持访问权限的数字凭证，其中访问包括用户访问应用，以及应用间的相互访问。对于后一种访问，“敏感信息”包括密码、加密密钥、证书和 API 密钥等。
为避免代码出现泄露敏感信息而导致数据泄露，DevOps 团队必须首先了解在 DevOps 环境中存在的多种敏感信息扩散方式。导致敏感信息滚雪球般扩散的因素，可概况为如下七种方式：基于云原生的开发、多云基础设施、微服务架构、从用户到机器的身份转变、主动学习 / 机器学习 / 数据分析、物联网 / 嵌入式设备，当然还包括 DevOps 本身。这些致因引发了更多的出错机会，因此会产生漏洞。其中包括：为加速测试而对敏感信息做了硬编码、使用了不安全的开源库，以及未考虑云上安全和云本身安全等。
当前存在着多种商业的和开源的敏感信息管理技术，用户需要考虑的因素包括：所在组织的预算和要求、当前部署的技术、DevOps 团队在敏感信息管理上的经验，以及目前实施这些技术并维持最新的可能性。
3 支持云架构安全，DevOps 团队的 8 项做法
1. 识别必要需求：前期应做好预警的准备，越早越好。大部分公司已至少部分上云，有时很难后退一步看到整体局面。
谨记，云服务并不仅仅是 AWS、Azure 和 Google 这些厂商，而是技术栈涵盖了从记账到 Zoom 的所有 SaaS 应用。需特别提出一点，团队是否正在使用 Slack 等基于 SaaS 的文档管理系统（DM）？
如果开发团队或 DevOps 团队正使用自己的 Slack Channel 分享企业的敏感信息，那么攻击一旦通过暴力获取了 Slack 的访问权限，就能置整个组织于危险境地。
CI/CD 访问的界定和管理，需明确落实为管制措施。
鉴于数据泄露主要由人为错误引发，表现为配置不正确、敏感信息泄露和数字卫生堪忧等问题，因此鉴权的责任需由 DevOps 和 DevSecOps 团队承担，这是每个联网的安全系统的基本要求。
有别于开发团队，DBA 团队需要完全不同的数据访问权限。为降低风险，应在正确配置的技术栈上遵循“最小访问权限策略”（least access privilege policy）。
事实上，任何一种“某某即服务”，无论是 IaaS、PaaS 或是其它，都需要做到在凭证这一最基本的级别上的保护。Solarwinds 数据泄露案例就始于凭证的泄露。Google 会定期向其商业用户发送警报，告知用户潜在的凭据泄露。
无论如何，都不要遗漏"影子 IT"（ShadowIT）。确保组织中每位人员都知道，自身凭据的泄露可能是皇冠明珠中最薄弱的环节。影子 IT 增大了凭证泄露的风险，因为 IT 团队并未意识到一些外部平台能突然连接到受控的内部系统。
最后一点，举一反三，博采众长。推荐英特尔提供的速查安全清单，可作为确定云安全要求的一个基础。
2. 定义架构：一旦识别了组织的云安全要求，就会更加全面地掌握组织在用的云服务类型，以及需添加的其它服务。
始终将云上安全和云自身安全置于首位。谨记，用户需对自己应用、数据、操作系统、用户访问和虚拟网络流量的安全负责。此外，还需提升用户对配置的基础认知。有超过 5% 的 AWS S3 Bucket 被错误地配置为公开可读。近期 Kafdrop 的一个低级错误配置，就泄露了一些世界上最大型企业的 Apache Kafka 技术栈。
尽管三大云厂商在自身技术栈安全加固上的投资数以百万计，但 PaaS 公司并没有此类预算。所以重要的事情说三遍，检查、检查，仔细检查。称其为“零信任”是有原因的。
对于 SaaS 和 Web 安全，凭证保护同样关键。
每种类型的架构，都需要有各自的安全类型，在这点上不能偷懒。例如，混合云基础架构需要达到一种“三重击”类型的安全。一是本地部署需实现高度安全，包括关闭所有的端口、追踪表面区域，以及具备一个高度活跃的安全运营中心 (SOC)；二是在公有云的安全防护上，需使用其技术栈中可用的最新和最强大的安全技术；三是二者间的连接也需加以保护，以免受攻击。
3. 分析现有管控措施，找出存在的漏洞：零敲碎打的安全技术栈，效果是不会好的。显然，更彻底、更合理的做法是从零开始构建。下面列出了一些可行的技术措施：
- 云访问安全代理 (Cloud access security broker，CASB)
- 云工作负载保护平台 (Cloud workload protection platforms，CWPP)
- 云安全态势管理 (Cloud security posture management，CSPM)
- 静态应用安全测试 (Static application security testing，SAST)
- 数据丢失防护 (Data loss prevention，DLP)
CASB 担当了组织和云厂商间的中介，提供配置审计、DLP、治理和监控等服务。主要的 CASB 产品厂商包括 Broadcom、Palo Alto 和 Forcepoint 等企业。
CWPP 用于防止系统过载，比如 DDoS 和潜在导致内存溢出的错误代码。CWPP 监控云基础设施上部署的云计算资源。CheckPoint、Trend Micro 和 Carbon Black 等企业都提供 CWPP 产品。
CSPM 通过持续审计方式检测错误的配置，帮助发现人为错误，这是导致出现安全漏洞的主要原因之一。CSPM 厂商包括 Spectral 等。
SAST 扫描源代码中的潜在漏洞，防止由于人为错误和遗漏而导致敏感信息泄露。例如，测试后遗忘了数据库访问凭证的硬编码。
DLP 可以是 CASB 产品的组成部分，也可以是单独的产品。DLP 提供保护敏感数据的工具和策略，降低或消除由不良行为者或内部资源导致的数据泄露风险。
上述工具可以单独使用，也可以作为更广泛的安全技术栈的组成部分；可用于整个组织，也可用于特定的领域内，例如在开发中使用 SAST。
4. 聚焦于云上敏感信息保护：在理想情况下，只要相关教育、以安全为中心的文化和各项工具到位，敏感信息是永远不会泄露的。但人为错误是难免会出现的。老话常说“更快、更好、更便宜”。但在新说法中，会再添加上一条，“更安全”。当然，最初的收益是从“更快”和“更便宜”中获得的，但忽视“更安全”的后果是对会业务产生更持久的影响。
开发人员面对着发布代码的巨大压力。为简化跨工具的访问，他们有时会走捷径，试图使用更易于记忆的密码，或是使用易于猜出模式的轮转密码。
鉴于此，我们应聚焦于凭证保护。密钥和密码应尽可能在无需人工交互的情况下自动轮转，也必须强大到足以承受蛮力攻击。
不要忘记培训人员了解一些“典型”威胁，例如钓鱼式攻击、短信息钓鱼（smishing）、链接投毒等。
然而，无论团队如何审慎而为，人总是会犯错误的。
5. 搜索错误配置：如前所述，在更快、更高效、更好的过程中，开发人员一直专注于如何将代码发布出来。一种加速做法就是在配置中硬编码数据库访问等敏感信息。偶尔还会为了省事，在 QA 和测试中直接将“读取访问权限”设置为“公共”。
问题在于，开发人员面对太多需要关注的事情，以至于有时会忘记删除这些访问权限，从而导致整个系统易受攻击。自动配置扫描是发现此类错误的关键，因为没有人会真正有时间特地去逐行地检查配置代码。
6. 聚焦于最少访问原则：理想情况下，每个人都是百分百适岗和诚实的，从不会犯错误，或是故意做错事。
现实中，为实现更好的访问控制，需执行将访问权限严控于必需人员的“最少访问权限”原则，由此降低发生错误的风险、限制损害的范围，并加强安全性。例如，在 Sage 公司数据泄露案例中，即便某位会计岗员工图谋不轨，该策略也能大大地降低企业的损失。当然，最小访问权限需要辅以持续的监控，它并非一种完备的解决方案，但可通过以下方式得到强化：
- 去除终端用户计算机上的管理员权限；
- 更好地保护帐户凭据；
- 监控特权会话，确保正确的使用；
- 除非开发人员有特定的要求，否则应限制访问权限；
- 限制对生产系统的访问。
这一原则同样具有技术解决方案。权限访问管理技术提供监控、审计和强制合规性。好的权限访问解决方案，可支持权限的动态分配和拒绝，确保基于实际需要访问。
7. 对 CI/CD 管道的全面持续安全防护：关键在于“测试关口前移”（Shifting Left）。安全性应始于首行代码，而不是遗留到 QA 或测试阶段。主动安全涵盖了从防止不合规的和错误的配置，到限制敏感信息泄露和凭证漏洞，从而降低了整个软件生命周期出现问题的可能性。
在开发中的每一步，都需要主动安全和被动安全齐头并进。在加快响应速度的同时，保持一切过程的敏捷性。安全性是每位开发人员都需要考虑的问题，并检查新旧代码是否存在潜在的漏洞。简而言之，从一开始就要在新代码编写中落实安全，在旧代码审查中寻找问题。
8. 一切从简：为确保整个软件生命周期的安全，实现自动化是最快捷、最简单的方式。重要的解决方案包括配置检查、敏感信息扫描、身份访问管理、治理、合规性、掩码和人工数据等。解决问题的关键在于找出一种组合，能最大限度地提高云安全性、减少误报，并快速且低代价地发布高质量的代码。
最好的解决方案，应是最简单的。即使用尽可能少的工具构建安全技术栈，却能提供最高等级的安全性和最低等级的误报。不幸的是，事情总是相当复杂的。虽然一些企业提供了多合一工具或兼容套件，用于简化流程。但作为用户，并不能完全依赖于此。和所有的大型项目一样，最好的做法是择机去迈出这一步。
永远不要忽视云上安全与云本身安全，云厂商很少会去分担用户的责任。对照企业自身的 SLA，去发现云厂商提供服务中所有遗留下的坑，并逐项加以弥补。
作者简介：
Dotan Nahum 是 Spectral 公司的 CEO 和联合创始人。作为一名技术大拿和代码忍者，Nahum 具有数十年的动手编码经验，力图通过深思熟虑的设计实现快速构建，融合性能、正确性和开发人员经验。作为一名重要的开源贡献者、作家、演讲者和播客，Nahum 在 React、Node.js、Go、React Native、分布式系统和基础设施（包括 Hadoop、Spark、Docker、AWS 等）方面体现出专业高水平。可访问他的 Github 和博客。
原文链接：
https://www.infoq.com/articles/devops-cloud-security/
