云安全管理中的DevOps职责

摘要： 为增强云上安全和云本身安全，需核验云安全的各个方面，包括识别需求、定义架构、分析控制、识别漏洞等。安全必须既是主动的又是被动的，是开发中每一步都应考虑的问题。

作者： Dotan Nahum

正文：

本文要点

• 软件开发和集成中通常存在着大量的出错机会，因此会产生一些软件漏洞。其中的突出问题包括：使用了不安全的开源代码、为简化测试而对密钥做了硬编码等。
• 影子IT（ShadowIT）是引爆安全问题的潜在漏洞，因为安全团队并非完全掌控当前有哪些外部系统可以访问内部。
• 时刻牢记云上安全与云本身安全。云厂商只提供服务，剩下的取决于用户。用户应确保阅读了服务细则。
• 安全必须既是主动的又是被动的，是开发中每一步都应考虑的问题。DevSecOps无法做到兵来将挡水来土掩，因此相关政策和程序必须先于威胁发生而部署到位。
• 创建新代码时，需将安全性置于首位。旧代码可能并不安全，因此在构建新功能时，需审查旧代码。

通常，安全属于信息安全团队的工作范畴。这样的网络安全实现方式曾一度运作良好，直至最近几年才发生变化。

向云计算基础设施的转变，造就了分散化的软件开发环境，进而推动了软件开发在速度和规模上的增长。DevOps为软件开发全生命周期提供了更丰富的服务，有助于开发团队更快速地实现敏捷的软件创建、测试和实施。但DevOps同时引入了新的网络安全漏洞，这是传统的信息安全孤岛所无法管理的。为保护DevOps环境，以敏感信息（Secret）管理为主责的DevSecOps部门应运而生。

网络安全是必须的

毫无疑问，云安全已成为DevOps团队不可分割的职责。团队必须在云安全管理（Cloud Security Management，CSM）上积极作为。

云安全：敏感信息及防泄露方法

现代开发人员在创建软件之外，还必须保护组织的敏感信息免受未经授权或身份验证的访问，并将其落实在开发过程中。那什么是“敏感信息”？敏感信息指支持访问权限的数字凭证，其中访问包括用户访问应用，以及应用间的相互访问。对于后一种访问，“敏感信息”包括密码、加密密钥、证书和API密钥等。

为避免代码出现泄露敏感信息而导致数据泄露，DevOps团队必须首先了解在DevOps环境中存在的多种敏感信息扩散方式。导致敏感信息滚雪球般扩散的因素，可概况为如下七种方式：基于云原生的开发、多云基础设施、微服务架构、从用户到机器的身份转变、主动学习/机器学习/数据分析、物联网/嵌入式设备，当然还包括DevOps本身。这些致因引发了更多的出错机会，因此会产生漏洞。其中包括：为加速测试而对敏感信息做了硬编码、使用了不安全的开源库，以及未考虑云上安全和云本身安全等。

当前存在着多种商业的和开源的敏感信息管理技术，用户需要考虑的因素包括：所在组织的预算和要求、当前部署的技术、DevOps团队在敏感信息管理上的经验，以及目前实施这些技术并维持最新的可能性。

支持云架构安全，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和博客。

原文链接： The Role of DevOps in Cloud Security Management