数据采集、数据融合、平台能力构建、AI算法支持等方面最新技术实践分享>> 了解详情
写点什么

云安全管理中的 DevOps 职责

作者:Dotan Nahum

  • 2022-05-20
  • 本文字数:4124 字

    阅读完需:约 14 分钟

云安全管理中的DevOps职责

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


向云计算基础设施的转变,造就了分散化的软件开发环境,进而推动了软件开发在速度和规模上的增长。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

2022-05-20 09:413920

评论

发布
暂无评论
发现更多内容

【ELT.ZIP】OpenHarmony啃论文俱乐部——浅析稀疏表示医学图像

ELT.ZIP

OpenHarmony 医学影像 稀疏矩阵 ELT.ZIP

【ELT.ZIP】OpenHarmony啃论文俱乐部——这些小风景你不应该错过

ELT.ZIP

神经网络 OpenHarmony ELT.ZIP

安全之花如何盛开在华为云空间的每个角落?

脑极体

企业管理理念之人本善还是本恶

秋去冬来春未远

企业管理 人性本善 人性本恶 一念之差

另一视角看元宇宙:元宇宙文化正悄然改变世界

CECBC

关于数字货币的几点问题及回应

CECBC

Java 操作 Office:POI word 之文档信息提取

程序员架构进阶

内容审核 4月日更 文档识别 4月月更

一个完整的渗透学习路线是怎样的?如何成为安全渗透工程师?

网络安全学海

网络安全 信息安全 渗透测试 WEB安全 漏洞挖掘

论利润中心内部核算和集团核算

秋去冬来春未远

阿米巴 利润中心 集团成本

Camtasia Studio2022汉化版

茶色酒

Camtasia2022

在线YAML转CSV工具

入门小站

工具

区块链如何助推著原创保护

CECBC

Apache Doris (incubating) 1.0 Release 版本正式发布!

ApacheDoris

数据库 大数据 开源 OLAP apache doris

linux之rpm命令

入门小站

Linux

在线CSV转Plaintext(txt)工具

入门小站

工具

利用 Dio 完成数据删除操作

岛上码农

ios 跨平台 移动端开发 flutter开发 安卓开发

Web3.0 时代,我们的生活将产生什么变化?

CECBC

[Day19]-[动态规划]分割等和子集

方勇(gopher)

LeetCode 动态规划 数据结构和算法

云安全管理中的DevOps职责_云原生_InfoQ精选文章