必须加强建设DevSecOps的Ops阶段

What 将安全性和可靠性结合
Why 错把“DevSec”当成“DevSecOps”
How Secure Your Ops
安全混沌工程-Security Chaos Engineering
韧性-Resilience
无接触-No Touch
When 对待安全的观念需要立刻改变
参考资料

What 将安全性和可靠性结合

业界不少关于DevSecOps实践的文章，大都是一些静态代码检查、被动扫描器、安全框架和SDK、域名上线卡点之类的介绍，这些文章不约而同地避开了软件的维护、运维阶段。实践DevSecOps的第一个误区就是错把“DevSec”当成“DevSecOps”，缺少持续运营的运维\交付阶段，仅将安全向开发人员左移是选择做一件简单的事，而不是正确的事。

开发人员通常不是安全工程师，安全团队通常没有开发人员。两个团队都没有资源或技能来满足对方的需求，安全不仅仅是安全和研发两个团队的责任，需要每个工程师参与，笔者认为安全工作不应该仅仅从保障不出事的角度，而是要站在为业务带来发展的正向价值的高度去思考，DevSecOps以关注代码开始，以部署和运维开始循环，Deploy、Operation阶段的安全性也很重要。

是时候谈谈安全和可靠的融合了，可靠性和安全性不可分割，没有安全性，就不可能获得安全性；而没有可靠性，安全性就是不完全，不巩固的。运维、交付阶段的安全运营领域将是未来5到10年DevSecOps行业的主战场，而国内阿里、腾讯早已经布局这方面的人员和技术积累。

Why 错把“DevSec”当成“DevSecOps”

实践DevSecOps，很多人第一步就做错了--错把“DevSec”当成“DevSecOps”，忽视Ops阶段的安全性，定义持续安全性区分两个团队：一个是开发和工程团队，另一个是运维/发布团队，折腾开发人员是安全团队的一项传统技能，安全的偏见认为SRE就是做申请机器，打补丁的事情，其实现在SRE的角色已经完全不同，虽然没人愿意去折腾SRE，但是我们不能妥协，工作哪能不严格呢？和和气气怎么能把工作搞好，实现变革是需要付出代价的。

某公司介绍所谓DevSecOps工具链，到了上线阶段就截止了

只关注dev的sec，不关注ops阶段的sec，主要体现在四个方面：

建设的思路受限于过去的经验。对于云原生项目、微服务、大数据、SaaS的项目，仅通过安全团队的web、移动应用安全审查，并说“安全审核通过，可以上线发布了”是不够的，谈到应用安全其实是指狭义的研发安全，好像以为主机系统安全、部署安全、运维安全、基础设施安全领域和自己没有什么关系，安全的手不能伸得太长，可是现在未来是“基础设施即服务”（IaaS）、”配置即服务“的趋势，不能仅仅关注代码维度了，要关注产品的全部生命周期。以供应链攻击威力，并不仅仅是code。数据显示开发人员使用39% 的时间用于管理 DevOps 基础设施。

以供应链攻击为例共有以下8个攻击环节，但是如果关注研发安全，只能覆盖其中4个代码技术层面，忽略下图中的A、B、G、H场景。

重新审视供应链攻击的大盘

选择做当前的事，不着眼于长远。当前的问题是仅在需求、设计和开发实施的阶段考虑安全性，对于业务视角来说，企业安全本身就是一个正在进行的项目，要注意整个安全能力的交付过程，而这项工作随着企业软硬件的发展永远不会完成。我们总是可以做些事情来减少未来漏洞带来的风险和影响。

安全工程化要求不高。我们总是以为公司的安全隐患是研发人员写的代码引入的，实际对于一次全链路攻击，利用代码安全漏洞仅仅是入口边界，提权、抓hash、未授权等横向渗透后果其实和开发人员没什么关系。现在能力大都集中在主要是防入侵而已，防范删库跑路不少公司是做不到的。花了很大精力去做长尾工作的扫描、修漏洞、告警能力，安全投资的回报已经不足，为什么不真实关注建设的短板呢？当然有些黑、白盒安全运营的能力是“看上去”比较成熟，挑战不大，本质上我们没有提出更高的要求，我们不仅要鼓励devsec的从10到100，也要鼓励secops的从0到1，1到10。

忽略人的因素。是人就会犯错误，我们只能缩减问题发生的影响，永远不能完全解决问题。除了关注技术和流程，人的Operation因素是影响DevOps效果的最大变量。

ESG对北美对私营和公共部门的IT和网络安全专业人员进行的调研显示，48%的组织故意将易受攻击的代码推送到产品中，说明工具流程虽然能检出，但是人去主动忽略放行。

还有个最近的例子，我们能否真正解决”删库跑路“问题？字节最近通过”传字节跳动实习生删库，公司通报为重要事故“事件回答：不能。

How Secure Your Ops

DataOps、MLOps 和AIOps，可以统称为Operations（Ops\运维）阶段。SRE 可以帮助团队在发布新功能和确保用户可靠性之间找到平衡。SRE(或者是DevOps工程师)关注的稳定性和安全所关注的安全性问题，在解决思路策略、技术实现、对人的要求都是一致的，但现状是安全和SRE的沟通协作还远远不够，在下图中显然大家做的更多事情是偏左，右侧的技术栈的安全熟练度不高。

DevOps工具链，你是否关注左边大于右边

我们永远无法理解我们自己的系统，但安全还没跟上这个道理，总是喜欢规范统一，现在构建的分布式系统如此复杂，以至于没有谁能够说明其整个运行本质，系统不安全是常态，应急响应流程存在不足是常态，防微杜渐、严防死守的观念已经不适应现在行业发展。新的挑战面前，怎么去把事情继续做好？需要不断开阔自己的思路，往前看的同时也往后看，关注Ops领域。业界已经有一些实践作用于安全和可靠性领域：

安全混沌工程-Security Chaos Engineering

红蓝对抗方式是一种偏向传统的思维，显而易见其不足之处在于：一、攻击者总是能发现缺陷，蓝队总是能收到告警，说不清到底有多少工作要做；二、虽然少数优秀的执行团队可以做到以周、月度为周期演练，频度仍然严重不足；三、不透明、不可重复实验、过程不可控，缺少持续的反馈。如果说红蓝的定位是”发现建设存在哪些问题“，安全混沌工程则关注”建设这些问题的优先级“。

当我们面临一个复杂规模的业务系统时，出现安全漏洞几乎是必然事件，没有安全问题是偶然现象。不管你花多少精力进行漏洞修复，出现0day几乎是必然事件；不管你组织多少安全培训，员工点击钓鱼系统几乎是必然事件；不管你做多少风险感知能力，入侵行为发生快于阻断是必然事件。

根据《IBM Security 2020 Cost of a Data Breach Report 》52%的数据泄露是因为恶意代码攻击，23%的原因是人的犯错，25%的原因是系统故障。安全混沌工程通过观测应急响应、安全控制措施验、基线监控、风险发现等技术手段解决后两类问题，占比共达到48%！

将安全视为故障需要运维和安全共同进行改善，安全混沌工程通过快速检测服务是否健壮、安全、有足够的韧性、能否容忍意外的安全事件来提高企业安全架构的实用性。

韧性-Resilience

发生安全事件的第一步应该做什么？恢复业务正常运行进行止损。组织需要建立面对性能和安全威胁时，有效保持系统弹性和恢复的能力。今年RSAC大会探讨的韧性其实已经超越了安全的范畴，是踏踏实实的软件工程。韧性要求安全工作不仅仅重视拿结果，也重视过程阶段的成熟，引入了控制降级、冗余、弹性设计、隔离、自动缓解和恢复的概念。

无接触-No Touch

恶意用户（或者攻击者）尝试破坏系统、中断系统来影响服务可用性，我们必须将”人的因素“装在”笼子“里。想象一下，一位研发人员通过配置管理下发了一个错误的配置引起了软件变更，但是这个时候是不是绕过了code review和代码扫描流程，是不是应用安全应该关注的事？SDL亦或是DevSecOps的职责是产品安全或者应用安全整体，不应该是止步于研发安全。

举个例子，怎么阻止高权限的运维人员私自开放公网ip到线上？No Touch通过审核每一次变更必须通过自动化、软件校验风险因子、可审计的备用措施来实现”提高生产安全性、避免中断“，被背后代表着需要落地大量安全原则，比如最小权限、前置安全检查策略、安全代理、审核、关注人和机器之间、机器和机器之间的交互。

参考AWS的“Humans and Data Don’t Mix”，这方面需要建设工具链很多，出成绩的前景很大。