| 编辑推荐: |
| 本文来自于网络，文章主要介绍主要介绍了如何把security整合到DevOps这个模式中以及如何保护部署流水线等相关知识。 |
|
导言
今天由为大家拆书《DevOps Handbook》第六部分，信息安全集成到DevOps的技术实践。
大概有三块内容：
第一块是总体介绍一下DevSecOps。
第二块主要是原书的第22章，安全成为每个人工作的一部分。
第三块主要介绍原书的第3章，保护部署流水线。
一、DevSecops概述
DevSecOps概述，DevOps不仅仅需要达到开发和运维的目标，同时也需要实现信息安全的总体目标。包括服务和数据的可性用、机密性、完整性。
通常来说我们一个产品的上线或者一个产品的立项或者一个产品功能的定义需要满足，比如在一定的开发周期内，在一定的人员投入内，实现一定并发的用户的同时在线或者并发的请求数，等等这些基本的开发和运维目标。
其实很少有产品或者需求能够覆盖到相关安全的指标，比如我整个产品防篡改的能力，整个产品抗攻击的能力，整个产品用户数据如何防止被泄露等。这就是安全整个DevOps中的价值，保证服务和数据的可用性、机密性、完整性。
在《DevOps Handbook》里主要介绍了两块内容，第一块是让安全成为每个人工作的一部分，这里面不仅仅是安全团队专业的安全工程师，同时也包括产品经理、开发工程师、测试工程师、运维工程师，都需要成为他们工作的一部分。
这里面如果细分就涉及到包括对代码库或者共享库或者第三方引入文件，还有对开发周期产品迭代的安全控制项，还有静态代码分析，以及线上运营环境安全监控、部署环境安全基线、安全扫描，以及在运营环境中的权责分离等。
Garnter：how to integrate security into DevOps
这个是Gartner曾经提出的，信息安全整合到的工作流程中，主要的目标是信息安全对开发和运维工程师来说，即使不能做到百分之百，至少大多数的扫描也好、评估也好，应该是透明无感知的，因为DevOps主要有交付效率还有敏捷开发的一些要求，如果加入了security很多评审或者审批、扫描，很可能会使整个交付周期被delay，所以如果你能做到尽可能的自动化，把大部分安全的要求和策略都能自动化实现，这样对开发和运维来说也基本做到了无感知。
这里面可能有几个挑战，其中一个挑战，信息安全会使整个敏捷开发效率受到一定影响。信息安全整体框架需要自动化的集成到DevOps的交付平台中是有一些困难的。
现在很多应用其实是应用了大量的开源组件，组装整个应用，而不是完全由自主开发，这样给透明的自动化的安全分析、安全扫描带来非常大的挑战，主要挑战是这三块。
二、Making secutiry a part of everyone’s job
如何让安全成为每个人工作的一部分，安全在每个工程师或者产品经理的角度出发，目标也是不一样的，我这里举了一些例子，比如产品经理，在关注用户体验的同时，是否关注用户的安全体验？
比如产品经理通常会关注我这个按钮是不是可以点，这个搜索是不是可以执行，这个界面应该长成什么样子，但是产品经理很少关注用户资产被盗刷或者个人信息泄露，相关的安全事件带来用户不好的体验。
开发工程师在交付产品需求和功能的同时，主要考虑目标都是能够按照项目规定的时间，能够满足项目需求的质量和性能，通常对于应用或者业务的安全性考虑得不多。
比如交付的代码，输入参数合法性，比如很多界面菜单提交可能要求输入手机号，很多工程师不一定考虑如果输入字符串会怎样，如果输入元字符，比如单引号，能够造成特殊截断的这种字符会怎样。
另外权限控制，比如管理员应该具有权限，是不是能够完全横向覆盖到所有的权限项，如果不具备权限会怎样，如果在异常网络健全失败的情况下会怎样，可能这个工程师考虑的并不多。
还有像抗攻击能力、数据加密存储/加密传输等等这些安全的开发商的要求，可能关注的不一定多。
安全工程师通常会从安全体系建设整体来进行关注，包括一些安全事件应急响应，还有对运维工程师、开发工程师去指导，以及对产品需求、功能、安全评审。
架构工程师往往会考虑业务正常的技术架构，比如如何做到高可用，如何做到就近路由，如何做到每个用户体验更好，比如在一些网络异常的情况下，如何进行容灾的架构，这可能是架构师通常需要考虑的或者考虑比较多的。
对于架构的抗攻击能力，比如攻击来了，我这个架构应该怎么办，是否能够具备抵抗攻击的架构，或者能够对攻击进行自动化防御、自动化伸缩的架构。还有一些不可抗导致的灾难弹性容灾能力，可能架构师考虑的并不多。
为什么说让安全成为每个成员职责的一部分，让一个组织的整体所有人都能对这个安全目标负责和实施，这种产品才能使自己最初设计的安全目标最终达到。在《DevOps
Handbook》里最先强调的就是让安全成为每个人工作的一部分，接下来怎么实现，后面会有细分。
这里有一个案例，也是我个人在实际工作中的案例。为什么说我们要开发、运维、测试、产品统一对安全目标负责，看看这个案例。2016年著名的勒索事件，把你的数据直接加密之后，比如给2000比特币还是多少比特币才能换这个数据的解密，著名的mongodb勒索事件。
如果出现这类事件，漏洞升级，需要修复这个漏洞，通常来说安全工程师非常关注这个漏洞，因为这个漏洞对整个组织的风险巨大，可能对整个组织整个应用的所有数据都会带来不可恢复的灾难。
一般的互联网公司可能有几十台甚至几百台、几千台的mongodb的服务器的升级和修复，其实非常复杂。首先这个事件对于产品的功能和用户体验并不大，因为用户该有的功能还得有，可能产品经理并不一定意识到这个风险发生概率是多少，或者是即使发生之后，对用户的影响是什么，可能没那么直观。
开发上要想修复这个漏洞，因为mongodb默认的是不需要用户的密码，匿名直接就可以登录，开发为了简单，通常这种是比较常见的。如果要加一些认证机制，可能对于他的代码就要进行修改，增加认证方案。
如果是一个几百台mongodb服务器，前端的中间件的调用可能会更多，甚至上千台服务器，至少几百台，这样的灰度升级其实需要时间。另外还需要测试，从运维的角度，同一时间升级这么多台服务器，修复漏洞，其实也带来全网操作的风险，也带来事故的风险。
无论从产品开发和运维，并不一定着急要修复这个漏洞，开发工程师、运维工程师或产品经理天然会认为这是安全团队或安全公司应该负责的，我不升级或者我不去增加认证机制，但是你还得把这个风险解决掉。很显然这是不现实的，其实安全从产品也好、运维也好、开发也好、安全也好，目标是一致的，大家一起来把安全问题解决，而不是单独的依靠安全团队或者安全工程师来解决安全问题。
《DevOps Handbook》这本书提得非常好，第一点提的就是让安全成为每个人工作的一部分。在我这么多年的工作中我也觉得这句话非常有道理，也非常深刻，安全不是单独安全团队的责任，是整个组织所有人的一致的目标和责任。
2.1、Integrate security into development iteration
demonstrations(将安全整合到开发迭代的论证评审中)
接下来介绍将安全整合到开发迭代的论证评审中。先看一下，一般来说产品需求的定义首先要产品经理提出一些产品的想法或者业务的功能，做一些产品原型，由美术设计来进行设计，由技术来进行评审，需要多长时间，比如一个月还是两个月能开发上线，还是搞定测试，需要怎么去测，通常是这样的一个流程。但这里面其实很少有项目或者有产品能够把这里面存在的安全问题提前同大家一起去评审。
举个例子，这是我在自己的实际工作中随便举的例子，为了让大家能够理解为什么需要把安全专家的想法能够提前介入到产品需求或者项目需求定义和需求评审中，很多产品都有注册功能，通常产品经理提出输入用户名、密码、注册信息、生日等，点击注册，发送注册邮件，激活，就成功了。
但是很少有人提出非可见功能以外的安全功能，比如注册功能的暴力注册对抗怎么办，怎么去人机挑战，怎么去限流限速，当你遇到暴力注册时应该怎么办。
很多登录环节就考虑输入用户名密码，点击登录就可以了，但是如何防范用户的账号被盗号登录或者恶意登录这些风险，比如用户的cookie被监听或者被劫持，在他不常用的登录设备上去登录，这种情况该怎么办，还有支付环节，是不是只需要用户名密码就可以，是不是需要更严格的认证机制，比如双因素认证，静态密码+动态口令。
比如在设计架构的时候，架构的高可用、高并发是ok了，但是你的抗攻击能力怎么办，运营活动说我有些礼物要送给新用户，如果黑产去刷你这个礼物，如何对抗，如何降低风险和损失。
还有账号的登录冻结机制，多数功能都是非可见功能，通常需要安全的专业人员介入才能提出很多非可见功能以外的需求，能够在设计开发中一起实现。这个就是把安全整合到整个开发迭代需求论证过程中的价值，能够尽早去发现这里面可能存在的问题，提早去制定一些相关的设计。
我这里举了一个比较典型的案例，互联网中比较常见的一个功能就是登录，我想通过这个案例来说明安全团队专家的视角和开发人员、产品经理、测试人员的视角是不一样的。
通常这个功能是产品经理提出一个功能，登录，输入用户名密码就可以登录了，开发的视角通常想，我怎么样通过你输入的用户名和密码，我查询一下数据库，如果命中成功就登录成功，如果密码不对，匹配错误，我就提示输入失败，如果考虑到性能，我可能不直接访问数据库，我可能要通过缓存，速度比较快，快速响应，另外通过集群调度，可以保证就近的用户在就近的节点得到响应，这样用户体验比较好。
测试通常会这样想，我的用户名密码肯定是正常功能的测试，预期是正常的，输入正确的用户名密码，正常登录成功。我输入错误用户名或者错误密码，预期登录失败。另外看你登录的延迟，是2秒钟才登录成功还是1秒钟还是300毫秒。另外要后登录服务，我要并发1万，并发10万，看一下你的性能会怎样。
安全团队的视角，跟开发和测试完全不同，安全团队视角是说你这个密码保存在数据库中，是加密的还是明文保存的。知道之前有个很出名的论坛，叫DN，就是因为数据库保存的用户密码系明文保存的，导致整个账号数据的泄露。
如果你是密文保存，风险进一步降低，只能通过撞库，安全团队关注的视角是你账号密码在数据库中保存是明文还是密文，绝对不允许明文，密文是可逆加密还是不可逆加密，通常来讲需要做到不可逆加密。
另外密码的传输功能是不是能被监听，比如http协议，还有一些TCP协议及，字符串也能够被监听。另外你的登录有没有抗暴力破解的登录机制，比如连续输入三次失败就要输入验证码、滑动验证码，等等人机挑战的机制，如果连续输入多少次失败冻结账户。
另外登录票据，比如cookie这种，有效期是多长，是永久有效还是一次性有效？另外你登录的票据cookie如果绑定的登录设备换了或者绑定的IP换了，还可以登录吗，其实这些都是跟登录场景有关的安全问题，我们通过这个可以看出，安全专家在整个登录功能的需求评审过程中会提出很多不一样角度的需求或者技术的要求，这样可以保证在整个项目上线过程中是以相对完善或者安全风险比较低的。
2.2、Integrate security into defect tracking and post-mortem(将安全整合到问题跟踪和验证中)
将安全整合到问题跟踪和验证中，很多公司都有自己的需求管理或者问题跟踪的平台，通常来说都是一些功能性的需求或者一些严重的bug，这里必须一个要求，安全的风险和漏洞也要一起纳入到问题跟踪的平台中，让安全的风险、安全的bug或者安全的威胁，也让所有的开发工程师、运维工程师或者安全工程师一起可视化，让所有人都了解这里面存在的风险和问题以及整体跟踪的进度。
比如刚才说的登录环节里的安全机制可能不健全，需要改，还有一些可能已经的漏洞，可能导致用户不安全的已经存在已经发生的事件还有潜在的没有发生的威胁和风险，可能都需要进行跟踪和管理。将安全整合到问题跟踪和验证中，并能够做持续的状态跟进。
2.3、Integrate preventive security controls into shared
source code prepositories and shared services(将安全预防控制策略融入到共享代码库和共享服务中)
将安全预防控制策略融入到共享代码库和共享服务中，前面章节提到要创建整个公司通用的共享代码库，比如一些加密模块、日志收集模块、鉴权模块、认证服务等，尽可能让代码能够在整个组织复用，提高整体开发效率和开发质量。
这个时候我们只需要把安全的策略、安全的扫描或者安全的机制能够在共享代码库共享服务里去实施，这样可以极大的提高整个通用代码或者通用服务的质量，安全风险会降低。尽可能通过自动化的平台来保证，比如安全扫描或者配置检查。
开发层面，可以考虑建立统一的跟安全相关的通用的服务，比如认证服务，统一的登录认证，统一认证里就可以考虑了，比如登录的暴力破解、限流限速、常登录设备、常登录IP等，这样不至于说每一个服务自己去开发一块认证服务，这样导致存在各种各样安全的问题。统一的登录认证服务进行统一的安全策略的控制，这样可能风险会降低。
另外可以开发统一鉴权服务模块，将鉴权的机制统一去完善改进。比如加密模块、日志模块审计服务等，可以尽可能做成通用安全策略和通用控制措施，整合到共享库和共享服务中。
运维层面，可以提供统一的OS镜像或者统一的开源组件以及开源组件的配置。比如很多工程师去安装操作系统或者重装操作系统或者安装Nginx、MySQL，如果每个人都自己安装，他获取的这些渠道可能不一致，有的可能在国外的某些网站下载，其实也不排除那些下载下来的配置本身就不安全或者是本身代码里就有后门。如果统一的能够去提供这些基础设施或者基础组件、基础配置，就可以把安全风险降到最低。
安全团队可以持续去评估和改进共享库和共享服务，比如全公司提供的所有通用组件和通用服务都可以进行一些安全的分析、安全的评估，并持续的去跟进和指导一些工程师的开发或者运维工程师的配置，把相关风险点可以降到最低。
这里面提了一些具体的实践，比如可以建立公司级的统一的通用技术组件，比如加密库和加密算法，加密的动态库，加密的jar包，或者一个支持http协议或者Swift加密服务，可以实现哪些功能，比如各种加密算法，可以根据参数实现各种加密算法，可以实现不同位数的加密，不同的加密强度，也可以实现支撑公司不同业务的加密技术，统一来实现加密库脆弱性的评估。
统一的账号认证服务，把用户的一些登录认证，还有疑似机器人登录的限流限速的机制，还有疑似机器人的人机挑战，比如不同挑战级别的验证码，疑似可疑的非常登录地的设备和非常登录地的风控，还有双因素认证，比如遇到非常常登录设备或者疑似被盗的，可以增加多一个因素的认证，还有一些改密的服务，密码手机等，一切跟账号认证相关的模块都可以统一化。
这样后续公司的每个服务都可以直接调用这个统一认证服务就可以实现安全级别比较高的认证服务。至于说每一个应用、每一个业务自己都去开发一套账号认证，那每个工程师的水平也不一样，每个安全的风险也不同。
另外像运维层面，比如统一的Nginx安装包，每个开发工程师、每个运维工程师部署Nginx，不要在网上自己去下载，而是通过公司统一的组件包，比如统一的Linux，统一的镜像，MySQL的统一安装包，把它统一起来，包括配置。可能不熟悉的工程师会直接在网上down，装完之后很多默认的配置他不太了解，有很多默认配置会导致很多安全风险，提供统一的组件包和统一的默认配置会把风险降至最低。
2.4、Intergrate security into devpoyment pipline(安全整合到部署流程中)
怎么能够把安全整合到部署流水线中，传统的方式，产品开发完之后，需要启动安全评估，比如做各种业务逻辑的安全评估，比如注册功能、登录功能、搜索功能、视频上传功能，各种功能的安全评估，代码静态安全检查、动态安全分析等，输出一个几十页甚至上百页的风险评估报告，通常传统是这样的方式。
但对DevOps来说，这种安全介入的环节明显是有点晚了，如果出现了相关的安全问题或者有一些安全威胁1修，这时候需要重新讨论设计，重新讨论产品功能需求，势必会影响整个产品或者整个需求的上线周期。
在DevSecOps的理念中，我们希望安全尽可能早的介入到整个产品的研发生命周期内，我们的目标是以最快的速度反馈代码存在的风险项。这里面一个主要目标是自动化，尽可能自动化做相关的安全测试和相关的代码检查。
比如很多公司已经实现了像静态代码的检查，比如输入参数的校验，能够跟代码构建做整合，代码构建过程中自动的集成了这个代码分析，能够实现一些扫描报告实时的异步输出，这样就可以保证DevOps交付效率的同时，还能把现有整个的安全能力整合到现有的部署的流水线中，在提升安全能力的同时还不影响DevOps交付的时间和效率。
2.5、Ensure security of the application(确保上线应用没有安全风险)
确保上线应用没有安全风险，这句话覆盖的场景太多了，做出来相当复杂，涉及面非常广。大家可以想象你通常的应用包含哪些场景，可能这里面会涉及到登录、注册、搜索、添加好友、上传视频、发消息、下载等，另外很多服务器可能涉及到进程运行的服务器差不多有几百台，代码有JAVA代码、PHP代码、C++代码、GO代码，引用的外部的开源组件和jar包还有动态库可能也很多，Elasticsearch、Hadoop，各种，所以要想保障这一点，要保证相关的方面都能够尽可能的覆盖全。
比如静态分析，所有应用涉及的代码都应该能够通过静态代码分析，确保是安全的没有问题的才能上线，包括所有的代码，前端代码、后端代码。另外动态代码分析，代码能够在虚拟机也好或者是真实的运行环境也好，能够实际运行，把里面产生的安全风险也能提前暴露出来。
另外还能分析应用所依赖的外部的库文件，比如有的应用依赖第三方的库，比如OpenSSL心脏流血那个漏洞，都能够进行分析。另外还有代码完整性校验和代码签名机制，所有的一切尽可能都要通过自动化的平台或者自动化的安全测试来实现，或者自动化的分析。纯手工搞的话，基本没有效率，而且不可能完成任务。
这个章节主要是介绍要能够通过各种静态分析、动态分析还有第三方依赖库的分析，能够确保整个应用是安全的。
介绍一个书中的例子，推特的一个例子，2009年的，推特之前曾经发生过两次事件，那里没有仔细介绍，大概说这两个事件看起来都跟账号被破解有关系，没说破解的，但实际上业内来说，被hack的通常的思路，要么你的口令比较简单，比较容易破解，弱口令，还有一种是撞库，比如你这个账号曾经出现在互联网的某个被拖库的应用中，比如A论坛是个小论坛，你使用的密码跟淘宝或者微信账号使用的密码相同，都用手机来捆绑，这样很容易被撞库。另外一个推特的事件，管理员账号被破解，这个明确说了是通过暴力拆解。
通过这两个事件后，推特开始推进安全的自动化测试，原文案例中介绍的几块：
第一块是明确老板和员工都需要对Sprint的安全计划负责，大家目标一致。
第二是能够预见的潜在的导致入侵的内部和外部风险统一的进行风险改进计划并能够落地。
第三个是代码的自动化安全测试分析。原书做了一些数据的介绍，推特也做了很多自动化的安全测试的平台，通过自动化安全测试确实能够把整个的风险降得很低，也发现很多问题，避免了很多潜在的安全事件发生。
2.6、Ensure security of our software supply chain(确保引用外部软件包或者库文件是安全的)
确保引用外部软件包括库文件是最安全的，这个很重要，最出名的就是struts 2，最近几年爆发了三四次，每一次都是致命的。曾经有一个很出名的电商，大量的账号写好，其实就由于struts
2导致的，密码泄露的不是明文，是密文，只是被撞库而已，用户名可能是明文。
我们说一个比较常见的例子，很多工程师写代码习惯从他之前的工程中拷代码，直接拿过来用，比如写的数据库的中间件，很多字符串的校验的逻辑，直接把代码拷过来了，把以前用的第三方库也拷过来了，其实并不是你们公司现在允许的标准的第三方库，但是他也拷过来了，这种情况非常容易把老版本的一些漏洞引入到当前的应用中。
之前发生过很多类似的情况，其实整个公司已经升级了某一个第三方库的漏洞，升级到最新版本了，但还是有个别工程师引用他之前的旧版本，旧工程下的第三方库或者开源组件有漏洞配置引入进来，比如struts
2很著名，像Elasticsearch、心脏流血OpenSSL，所有的都是外部软件包的安全问题导致整个组织的安全风险。
现在还有很多SDK比较盛行，很多移动应用里引入了大量的SDK，其实你怎么知道你引用的SDK里没有后门没有木马没有收集用户数据呢，所以你在使用第三方SDK时一定要经过你自动化的评估，能够通过你的安全分析、安全评估才能引用到你的SDK中。这里强调的是在引用外部软件包或者开源软件的同时一定要确保它是安全的。
下面举这个例子就是来说明这个事的，像OpenSSL、struts 2、Hadoop、Spring等，包括第三方商业开发软件包，比如视频编解码SDK、用户统计SDK或者智能调度SDK，都是花钱去买的，也要确保这个买过来的SDK是一个安全可靠的。这里面提到实践，在你组织要想做到既不影响整个项目的开发周期和交付效率，又能够达到安全的目标，基本上要实现自动化检查、自动化分析和自动化扫描，在整个组织中才能实现既安全又快速的目标。
2.7、Ensure secuity of the envionment(确保运行环境安全)
确保运行环境安全，业务进程的运行环境包括整个网络环境、服务器环境、操作系统环境、数据库环境，说起来跟运维的关系是最强相关的。为了让大家能够比较容易的理解这块，举几个比较常见的例子。
很多业务上的安全和业务上的代码逻辑，比如像每个业务场景、业务功能的登录、认证，今天我们讲的主要还是运营环境上基础服务的安全，如果人家业务已经做到了或者应用已经做到了比较安全，但是部署在你的服务器上，你的服务器已经被入侵了，或者服务器已经被植入木马了，它的安全是没有意义的，它已经将进程注入一个风险之中了。
运行环境的安全，举几个案例，比如像操作系统bash破壳漏洞，能够把操作系统的一些敏感信息内存块泄露，还有一些Linux的dirtycow提权，几乎可以秒杀很多Linux内核及还有数据库的环境，mongodb、MySQL都曾经出现过远程执行命令漏洞。
还有网络，有的时候你的网络是一个已经被arp欺骗的网络，很多传输数据都已经在被监听之内，这种环境本身都已经是风险非常高了，里面承载的进程也好、数据也好，都是风险极大的。
如何确保运行环境安全，涉及到的领域也非常多，包括服务器层、主机层的入侵检测或者安全基线检查，比如Linux那些操作系统的命令，有没有被篡改，是不是原生的密码文件，其实在我的经历中这种都有被密码篡改过。
比如曾经有一些密码篡改你的PS命令，作为一个守护进程，当你再叫PS的时候，运维也好，开发也好，自动就把他木马拉起，这样他的木马就神不知鬼不觉的被守护了末。
另外是你的Linux整个的操作系统版本是不是安全的，比如是不是具备提权漏洞，这种漏洞是不是已经修复了，能够导致提到root的这些补丁是不是已经打了。
比如你MySQL的这些版本是否具有相关的漏洞，你的网络是不是有被arp欺骗，你的网关地址是不是正常的网关地址，还是被arp欺骗的一个网关地址。
所有这一切，包括主机层的网络层的开源组件的基础配置的，所有的这些都应该能有一些自动化的分析，比如你操作系统的一些参数，比如像是否合规，这里面涉及到合规性，比如像history的，很多用户在退出整个操作系统时并没有清那个history，很多黑客入侵之后看看你的history就ok了，就知道你可能签了很多MySQL的user和password，还有敲了一些敏感的东西在history里，所以history安全基线是不是应该都直接清理掉，用户退出的时候自动清history。安全基线的方面涉及到很多方面，才能确保整个环境是安全的。
这里面同样有一个案例，在确保运营安全这块，刚才有一个案例是推特的案例，推特有员工被账号被账号撞库了或者破解，触发了两个安全事件，做了一些安全的优化和改进，做了一些安全自动化测试。
再通过一个案例介绍，整个运行环境的安全涉及的面还是很广的，包括运维体系的发布系统，管理机、跳板机、工具系统，面临的风险和挑战更大，一旦被入侵，对全网造成的风险或者安全挑战其实是灾难性的。
为大家介绍一个案例，可以想一想是不是在你的组织或公司也存在同样的问题。很多员工账号用户名和密码，他们用的密码是在互联网上其他的网站都存在过，比如淘宝、猫扑、知乎等各种网站，可能都有用过，用的就是这个密码，还有用的密码很弱，为了简单记，还有很多人把密码写在服务器的某一个文件中，还起个名叫password.txt，一看就是跟password相关。
我说的也是真实的案例，员工账号密码被撞库了，邮箱也被撞库了，有人可能还把跳板机证书或者有一些跟认证相关的key上可能会保存在办公机或者保存在邮箱里，或者保存在一个地方为了方便下载。
一旦邮箱或者是办公机被入侵，整个就泄露了。另外工具系统、发布系统，在发布的权限控制中，一旦入侵了这个人的账号或者跳板机，你这个人名下的服务器或者名下的服务都存在很大危险，假如说这个人是个特权账号，对整个运维体系来说，风险很大。
前面介绍推特的Administrators账号，这个也是一样，任何组织的Administrators账号，尤其是发布系统、管理系统、运维系统的Administrators账号也是特权账号，风险非常大，一旦被入侵，也是同样对整个组织都是灾难性的。
所以要保证整个运行的安全，要做起来涉及的面非常广，包括网络层、主机层，还有安全意识、安全管理，可能还涉及到IT上，办公网，还有外部网络怎么访问办公网等，是一个关联很广的体系，才能保证整个运行环境的安全。
2.8、Integrate information security into production
telementry(整合信息安全到产品监控中)
如何把信息安全整合到产品监控中，通常来讲产品上线有各种正常指标的监控，比如用户并发数，用户延时，用户的浏览器，用户的手机型号。我们今天提出来把安全的功能或者是跟安全相关的事件，也能够做到实时的监控或者实时的预警。
这里面举了一些例子，比如登录功能，像登录成功这些数据和登录失败这些数据和密码重置的这些数据，还有一些失败次数过多的登录IP或者失败次数过多的设备。
这里面要记录的东西还挺多，登录成功和登录失败记录为什么，是为了后续能够做一些大数据安全事件的分析或者能够做一些大数据挖掘，比如登录IP，失败次数过多，可以分析一下这个IP在的黑产或者恶意IP的情报库中是否存在，比如这个设备IP是否存在，这个IP是否登录、支付、充值等，其他的业务场景是否存在，这样可以做很多关联分析，比如失败达多少次，这个IP下聚合了多少账号，另外协议栈，还有很多像Linux，明明是在Linux的协议栈，非要伪装成Windows，伪装成正常的用户，实际上是服务器，这种可疑的场景和可疑的数据都可以做一个监控。这是和业务场合、应用场合相关的跟安全有关的。
另外是运行环境监控，像操作系统变更，操作系统版本变更，操作系统补丁等变更或者操作系统的参数，可能都会影响系统稳定或者抗攻击能力。
还有开源组件配置变更，像Redis这种，比如业务在使用的时候可能没有配置成匿名登录或者空口令，但是变更之后变成了匿名登录或者空口令，对整个配置系统监控会及时的预警风险。
另外服务器被入侵的时间，这涉及到整个入侵检测的体系，比如可以通过哪些维度去判断服务器是否被入侵，可能涉及到服务器行为模式的一些分析，比如你的PS命令被替换，除了系统管理员，普通人很少操作会替换掉PS命令，还有清一些系统日志，会输出一些清理系统日志或者替换系统命令或者重新编译系统内核或者SSH做一个反弹，等等这些可以的行为里可以进行一个监控，其实也是整个入侵检测体系的一部分。
另外是网络被攻击的这些监控，比如你当前的整个网络，如果没有网络监控的数据，表象来说，交换机数据已经满了，开始丢包了，带宽已经超过了整个网络可用带宽了，很多新链接建立不起来，比如Nginx的服务器大量的链接被重置，这里面如果没有攻击数据，这些东西看不出来。
比如看到很多链接被重置，很有可能也是攻击导致的被重置，比如导致大量的报文打到服务器，导致会话状态跟踪秒满，新的链接进不来等等，如果没有安全和攻击上的监控，这些问题你是不容易第一时间做成正确判断的。还有像数据库运行环境的监控，比如MySQL查询等这些敏感的操作，可以实时监控下来。
这里也有一些实践，像入侵检测体系还有入侵行为分析平台，防DDoS或防CC攻击平台，包括可视化、数据化、实时预警，还有跟业务相关的业务防刷平台，还有自动化攻击或弹性伸缩平台，还有各种安全基线、安全配置的检查，这里面都涉及到信息安全整合到产品和应用或者运行环境的监控中，这一小点主要介绍如何把安全产品的监控也能整合到产品和运营的监控。
三、保护部署流水线
3.1、Intergrate security and compliance into change
approval precesses(整合安全合规到变更过程中)
接下来是原书的第23章，原文叫保护部署流水线，这里有三小点。
第一点，整合安全合规到变更过程中。其实很多的安全事件、安全事故很多都由于变更导致的，人工的变更也好，或者全网的运维系统发布的自动化变更也好，会导致很多事故。
在这个阶段我们要确保把安全规范整合到当前的管理过程中，合理的变更管理策略可以把风险降低，同时如果要部署流程能够引入一些自动化基线检查或者自动化测试验证，能够确保整个部署变更是按照预期进行的，这样可以把风险降到最低，基本上不再需要人工的变更操作。
变更有这么几块，比如标准变更，低风险变更，所谓低风险变更，在变更是比较标准化的，在变更之前已经充分了解了变更的风险是比较低的，通常也是常规的定期的变更操作，这类变更通常是不需要审批的，可以自动化实行此类变更。
另外一类是高风险变更，需要review宾更内容，对变更操作、变更时间、变更内容需要审批，也需要评估整个变更的风险以及恢复的预案，比如变更出问题了应该怎么搞，这变更内容是不是该变更，变更的操作是否合理，变更的时间和影响是否能够控制，这类变更通常是高风险变更，需要审批。
还有一类是紧急变更，比如高危漏洞的安全事件，还有业务上一些紧急的bug，需要第一时间响应修复。
3.2、What to do when changes are categorized as normal
changes(被归类为“正常变更”应该做什么？)
第二点，刚才提到了，把一些低风险变更归类为标准变更，毕竟还有一类是高风险的变更，被列为正常变更之后应该怎么办，这类变更通常是风险比较大的，最主要的是需要去审批。
为了能够保证审批的效率或者效果，需要提供审批的完整材料，比如变更的目的是什么，为什么需要变更，变更哪些内容，变更会影响什么，变更怎么操作，操作时间是什么，等等所有变更所需要的材料都能够完整的提供。
另外能够把整个变更的操作关联到需求管理或者是版本控制管理，同时变更之后能够验证整个变更的效果，是否达到了预期的变更，是不是还有其他潜在的风险，以便于出现问题去回溯或者恢复到之前的版本
实践，归类为正常变更，可以通过运维平台或研发的自动化平台来实现自动化变更，以及同缺陷的需求管理、版本控制的自动化。
如果不能实现自动化，其实很多操作效率就会比较低，比如说审批通过了，操作一个全网可能几百台几千台服务器的变更，这个时候肯定需要通过自动化平台来实现，而不可能手工的一台台去改。这一点主要介绍如何把正常的变更提供完整的审批材料，保证变更能够正常有序的进行。
降低对于职权分离的依赖。在过往很多标准体系中，包括ISO20007等，经常提到的是“三权分立”、职权分离，过往的实践主要通过职权分离可以尽可能降低风险和犯错的概率，在很多国际标准都曾经引用过，比如服务器的系统管理员可以查询系统的日志，但是这个系统管理员不能删除和修改这些日志，这样可以避免某些特权的管理员删除某些证据。
比如这个人既是系统管理员，同说又可以删除很多日志，又可以导出很多数据，又可以修改很多变更，这样他岂不是可以神不知鬼不觉的可以操作很多东西，最主要是无法审计。控制全网操作的一些重要变更，执行人、审批人、复核人要分，职权分离，能够多层保证降低风险。这是在过往的一些实践中或者过往的标准中，但是在DevOps里，我们应该尽可能降低对职权分离的依赖，主要目标还是效率。
我们实现信息安全，但是绝对不能因为有了信息安全而阻碍整个组织的开发和交付效率。但是我们不实施职权分离或者是降低对职权分离的依赖，不代表说我们就不考虑信息安全、不考虑风险了，不是，而是我们通过其他方式，比如这里介绍的配对开发，一个人写代码，可能由于这个人的理解水平，有一些犯错，导致写了一些不安全的函数或者对输入的校验不严格等，导致一些安全问题，但是如果进行配对开发，可能就把风险降低，同时不影响整个交付效率，带来的肯定是人员的投入会增加。
比如自动化代码检查，比如职权分离也好，或者操作变更的权限分开也好，目的就是为了能够避免某一个单一特权的操作带来组织风险及这里可以做到一些，比如自动化的日志预警，只要有人删了系统日志，我就自动发一个告警出来，这样是不是就可以避免特权账号删除某些敏感的数据。
还有一些自动化代码检查，能够自动化的把一些代码的风险提前发现出来，这样也可以在DevOps过程中比较有效率。不同发展阶段的公司，包括自动化运维程度、自动化安全体系程度还有规范程度，其实对于职权分离的依赖程度，我个人觉得区别很大，降低依赖绝不是不依赖，而是我们尽可能通过其他方式来降低对职权分离的依赖，这样提高整个DevOps交付的效率。
3.3、Ensure documention and proof for auditors and
compliance officers(确保文档和证明供审计和合规检查使用)
要确保文档和证明材料能够提供给审计和合规检查使用，组织在适应DevOps模式的同时，对传统的IT和审计挑战也是很大的，实施了哪些的控制措施，使用了哪些工具，具有哪些审批人员等，都提出了新的要求。
因为很多都是便捷，都是为了各种快速各种高效，各种周期的敏捷，绝对不是说为了快就不需要文档了，文档也不写，很多过程也不去控制，那肯定不是。我们还需要把整个的文档给合规检查也好或者给审计也好，还是要把它文档化，整理充分。
一个案例，ATM机合规审计案例，非常典型，在很多互联网公司也都出现过，互联网公司很多页面或者很多APP的请求量比较大，有很多传统的分发流量或者点击页面，作为跳转，能够带来很多广告费，所以很多员工在这这里面，在大流量的userview的页面中加一个木马，做一个自动跳转转发，可能广告费或者流量分发能赚不少，这个例子也差不多，是一个ATM机的公司做合规审计的案例。
几年前某个员工通过在代码中植入后门木马，使得那些ATM机可以被他控制进入维护模式，他们可以从ATM机中直接取钞票了，但这个ATM机公司做合规审计时就把这个问题审计出来了，你进入维护模式的设计还有取钱的时间等，通过这些文档或者一些日志、数据，能够避免整个组织的风险，这小点主要介绍的是务必要把文档清晰化，给后续的合规、审计检查使用。
我今天的拆书主要介绍了把security整合到DevOps这个模式中，我可以再总结一下，主要有两块，一个是原书的第22、23章，22章是每个人都要对安全工作负责，另外一个是保护好我们部署的流水线。如何让安全成为每个人工作的一部分又展开了一些，比如产品迭代的管理，共享库的管理，运行环境的监控或者运行环境的安全、应用的安全等，来说明让每个人都能对安全负责。第二个重要的地方，23章主要说保护部署流水线，里面提到了一些变更，主要是变更，有正常变更、紧急变更等，应该怎么做。
我今天的整个拆书就到这里，谢谢大家！ |
