DevOps企业实践指南(8): 安全机制
DevOps落地实践中，安全机制应该如何保证，这篇文章从当前安全状况调查解读开始，同时介绍了DevOps落地实践时应该遵循的原则。
安全问题现状
Kaspersky Lab对26个国家超过5500公司进行了安全相关的调查，结果发现，安全风险无处不在，付出成本相当昂贵。
| 项番 | 调查结果 |
|---|---|
| 1 | 90%的业务曾发生过安全事故，而且，高达46%的业务由于内部或者外部的安全问题丢失过敏感的数据 |
| 2 | 大型企业平均每个安全漏洞要付出551,000$的直接成本，而对于中小型企业这个数字是38,000$ |
| 3 | 大型企业平均每个安全漏洞要付出额外的69,000$ 的间接成本, 而对于中小型企业这个数字是8,000$ |
安全漏洞影响
风险无处不在，漏洞影响巨大，主要的三种影响为：
| 项番 | 影响 |
|---|---|
| 1 | 对公司信用的影响 |
| 2 | 安全漏洞产生的额外的人员以及培训的费用 |
| 3 | 关键业务不能服务或者错误服务导致的额外保险等费用 |
安全漏洞类型
安全漏洞很多，在这其中，企业付出代价最大的三种类型分别是：
| 项番 | 漏洞类型 |
|---|---|
| 1 | 可以被木马等方式利用进行网络关键信息获取的漏洞 |
| 2 | 整合第三方业务服务引入的安全漏洞 |
| 3 | 网络设定相关或者容易被黑客进行攻击的安全漏洞 |
数据丢失的威胁来源
在一个数据变得越来越敏感和重要的年代，可能带来数据丢失的安全漏洞更加引起着广泛地关注。在这其中，以下三类严重威胁着企业的数据安全。
| 项番 | 数据丢失的安全威胁 |
|---|---|
| 1 | 恶意软件 |
| 2 | 钓鱼式攻击 |
| 3 | 内部员工导致的敏感数据泄露 |
DevOps实践中容易忽视的一环
安全，在DevOps实践中是非常容易被忽视的一环。所有人都认为安全非常重要，但是安全控制从那些角度着手，有哪些原则需要遵守，随着DevOps持续集成和持续部署的加快，安全机制如何才能保证跟上快速的节奏，这些都是我们在落地DevOps实践中需要考虑的问题。
安全实践原则
安全生产，重于泰山。落地实践，重在细节。如何落地，如下整理一些实际落地的实践原则：
原则一：以终为始，分析被攻击的价值所在
站在攻击者的角度，设身处地，将心比心，看看为什么会被攻击，然后便可以制定对应的应对措施了。
| 项番 | 价值分析自测问题 |
|---|---|
| 1 | 通过你的系统是否有可能接触到大量的用户私密数据，而这些数据在现在的时代具有重要的价值？ |
| 2 | 通过你的系统是否能够接触到很多用户名/密码，这些具有不同权限的用户名和密码是否能给攻击者带来很多价值，比如身份盗用？ |
| 3 | 通过你的系统是否能接触到用户的信用卡号码和账单地址等？ |
| 4 | 通过你的系统是否能接触到用户行为习惯这些隐私性的数据，而这些数据能够使得算法更加聪明？ |
| 5 | 通过你的系统是否能够接触到进行转账相关的关键性数据？ |
| 6 | … |
原则二：以客户为中心的安全策略
安全策略的创建，一般方式有如下两种：
| 项番 | 角度 | 安全策略 |
|---|---|---|
| 1 | 安全专家 | 保护企业资产的安全角度的防护策略 |
| 2 | 业务专家 | 满足客户的需求以增加收入的安全策略 |
由于安全专家与业务专家着眼点的不同，会导致在决策上产生很大分歧和摩擦。安全专家着重在防守，但是当安全方案在支持DevOps的快速响应客户需求，推动敏捷实践和持续创新落地方面则会显得步履蹒跚。而仅着眼于价值的业务专家往往对一些安全必须要注意的事项会选择性的无视。
而秉持以客户为中心的理念，使得安全和价值两者在实现时需要进行权衡和调整，安全专家采取一些不至于过于笨重的策略，保证安全的同时同时保障业务创新的敏捷性需求。
原则三：安全策略的左移
传统的方式下，开发团队/运维团队/安全团队各司其职，保证整个IT业务的整体实现：
| 部门 | 职责 |
|---|---|
| 开发团队 | 应用软件的开发和价值的交付 |
| 运维团队 | 保证服务的可用性和连续性 |
| 安全团队 | 负责安全保障 |
在这种构成之下，开发/运维/安全部门各有各自的KPI，职能相互独立，目标不同甚至产生对立和冲突，而且往往在交付到生产环境之前才会确认安全相关的确认，而安全事件的对应越晚付出的成本越高。根据研究，产品上线或者在运维阶段解决安全问题的成本往往远高于设计阶段：
| 阶段 | 修复安全问题的成本 |
|---|---|
| 产品发布以后 | 是设计阶段解决成本的4到5倍 |
| 运维阶段 | 达到甚至超出设计阶段解决成本的100倍 |
DevOps实践之中，尽早融入需要确认的安全性因素到各个阶段：
| 阶段 | 安全策略 |
|---|---|
| 需求阶段 | 客户合规性安全需求 |
| 开发阶段 | 代码静态分析，脆弱性检测 |
| 测试阶段 | 安全相关的测试内容 |
| 运维阶段 | 合规性和安全相关的监控 |
这样，尽可能早地引入了安全相关的机制，保证了安全保障的确认不会拖慢DevOps实践的节奏。
原则四：安全策略与工具的融合
在原则三中，我们意识到了安全策略要提前融入，工具在这其中也扮演着一个重要的角色。工具的自动化保障了安全在DevOps落地实践的顺畅执行。比如可以在如下阶段使用如下工具：
| 阶段 | 安全策略 | 工具融合 |
|---|---|---|
| 需求阶段 | 客户合规性安全需求 | Anchore |
| 开发阶段 | 代码静态分析，脆弱性检测 | Sonarqube/Findbugs/Fortify |
| 测试阶段 | 安全相关的测试内容 | Robot/Selenium/UFT |
| 运维阶段 | 合规性和安全相关的监控 | Clamvn/Anchore/Clair |
工欲善其事，必先利器。融合开发/运维/安全是一个非常繁重的工作，引入合适的工具能够做到事半功倍，使得开发/运维/安全的融合更加顺畅。
原则五：持续评估CI/CD的安全状况
持续集成和持续部署加快了交付的速度，但是自动化机制处理的不得当可能会带来很多安全上的隐患，所以评估CI/CD的安全状况以便持续改进非常重要。这里整理了一些常见的问题以便能够帮助进行自测和评估。
| 项番 | 安全评估自测问题 |
|---|---|
| 1 | 开发者能够看到其他项目的敏感信息么？ |
| 2 | 扩展问题1，各种用户的权限是否清晰，是否存在越权的风险？ |
| 3 | 密码的信息是否是用明文的形式进行存储？ |
| 4 | 匿名用户时候会取得过于宽松的权限比如可以执行所有项目的脚本？ |
| 5 | 构建的机制是否容易或者可能被攻击? |
| 6 | 开发者是否可能轻易地删除其他项目的一些信息？ |
| 7 | 是否使用了一些其他的不安全的服务或者机制进行CI/CD？ |
| 8 | 是否存在上传脚本等自定义机制引入不安全的因素？ |
| 9 | 安全相关的基线管理是否融入和CI/CD之中？ |
原则六：创建适合DevOps的安全标准
安全不是为了做出一个不明觉厉的复杂安全报表让人不知所措，安全报告是为了进行决策而产生的，而产生安全报告的安全标准更应该考虑到这样。我们在原则三中提出了安全应该融入软件生命期的各个阶段，所以针对不同的阶段和不同的角色，安全标准的侧重点应该有所不同。
| 阶段 | 安全策略 | 安全标准侧重点 |
|---|---|---|
| 需求阶段 | 客户合规性安全需求 | 侧重于整体性的业务资源相关以及企业资产安全相关的内容 |
| 开发阶段 | 代码静态分析，脆弱性检测 | 代码的漏洞或者缺陷 |
| 测试阶段 | 安全相关的测试内容 | 系统功能性的正确性和安全相关的测试内容 |
| 运维阶段 | 合规性和安全相关的监控 | 基础设施和配置方面存在的缺陷和漏洞 |
原则七：主动监控而不是被动应对
如果先于攻击者发现安全漏洞并将其修复，而不是在遭受到攻击之后被动的应对，损失则能免掉很多。主动监控安全问题，尽可能早地的发现可能会被攻击者或者对手利用的缺陷，则能带来极大的好处。
所以强化以上各个原则，达成融合安全和自动化于DevOps实践之中，在持续集成和持续部署中尽早地发现可能存在的隐患，主动监控，快速反馈，主动应对，对企业会很有帮助。
原则八：自我攻击和验证
依据DevOps环境一致性原则，Staging环境尽可能地与生产环境类似，可以在Staging环境中验证可能的各种攻击，先于可能的攻击者对自己的系统进行攻击和验证，以激进地发现可能的问题，降低了大部分潜在可能的简单外部攻击带来的影响。
原则九：安全的持续评估&安全规则固化
安全的对应是一个长期的过程，是企业在持续学习中应该不断保持的状态，同时更应该不断提升安全的等级以保证业务的连续性。通过不断的对安全进行评估，确定出需要强化的安全事项，不断将这些事项固化成最佳实践，然后标准化，最后自动化到整体的流程之中，以保证安全机制的整体不断增强和持续改进。
总结
安全是一个被所有人口头上非常重视，但是往往在实际的实践中选择性无视的一个话题。通过了解卡巴斯基实验室对于安全性相关的调查状况的解读，了解到了目前企业安全状况不容忽视的现状。同时阐述了随着DevOps持续集成和持续部署的加快，安全机制如何才能保证跟上快速的节奏，应该从那些角度着手，有哪些原则需要遵守，细节上如何落地的方式。