作者 | 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/
点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!
今日好文推荐
点个在看少个 bug👇
继续阅读
阅读原文