很多企业涉及在线业务的时候，发现业务发展迭代太快，刚刚熟悉和实施DevOps（中文社区翻译成：研发运营一体化），在落地过程中发现很难过安全这一关，尤其是上云之后，一下子涌入的云服务眼花缭乱，上线的安全基线和要求是什么？既然我们的团队转型到研发运营一体化，那安全团队如何适应和与时俱进，这确实是个难题。
时间回到2009年：Netflix从IDC走向公有云
Netflix 在2009年发表了一篇 100多页的 PPT 讲述他们企业的文化观《自由与责任》该 PPT 被 Facebook 公司的 COO 桑德伯格称为“硅谷最重要的文件”；任何团队的转型都离不开思考转型的初心，什么事情要做，什么事情要避免；Netflix 文化中最重要的7个方面是：
- 我们所珍视之物成就我们的价值观
- 高效能
- 情境管理而非掌控管理
- 紧密一致又松耦合的团队
- 支付市场最高工资
- 提升和发展
当时 Netflix 正在从美国本土的一家 DVD 租赁公司要立志成为一个全球的在线流媒体服务商，业务的高速增长的挑战是每月的API请求数的快速指数级增长，远远超过数据中心的容量，2011 年一个报道称Netflix当时用户高峰吃掉了全美 32%的带宽，数据中心频繁发生大规模不可用的事故，因此 Netflix走向全面的 AWS 云优化之旅，从而追求更好的可用性，支持公司业务全球化快速增长，匹配公司文化的技术敏捷微服务转型；
如何定位 Netflix 和 AWS 的关系？Netflix 定义了未来要实现的 “PaaS” 几个基本原则：
- 尽可能利用 AWS 服务（因为 AWS 在云服务上持续有巨大的投资，没有必要重复造轮子）
- 最大化开发人员的生产率和敏捷度
- 接口化隔离应用和 AWS，避免和 AWS API 细节锁定
- 云是由开发者掌控的，Netflix的 IT 是 AWS API
- 传统的很多 IT角色都转型成开发者，谁开发谁运维
- 长期目标：当市场其他的云计算玩家赶上AWS的时候满足可移植性
基于这样的原则，Netflix 目标构建一个全球的基于公有云 AWS 的 PaaS平台，支持 AWS 全部区域和可用区，支持多 AWS 账号体系，一键部署跨多可用区高可用，跨区域状态数据复制和备份，动态细粒度的安全管理，自动化扩展到上千的计算实例，监控百万级的各种指标；那新的面向云 API 的工程师团队有着怎样的角色构成呢？
自下而上，我们可以看到，Netflix 定义了云架构师，质量工程师，数据持久化工程团队，安全团队，核心平台开发，SRE 团队，云创新方案团队（监控，猴子军团等等），工程师工具团队负责比如编排，构建和部署等；为了内部团队熟悉云服务，Netflix定期举行一天的云服务训练营，一半时间讲解，一半时间做实验，让团队快速基于Netflix 的 PaaS 构建 “HelloWorld” 云应用，并且了解如何和安全、监控集成，如何使用 Cassandra 读写数据。
时间发展到2012年：安全团队的思考-云和安全合规
安全团队接触到公有云，第一个挑战是，原来数据中心的安全流程和策略完全不能适应云的大环境，云服务给到用户的印象是自由、敏捷、自服务、可扩展、自动化，而安全给到大家的第一印象是折磨、守门员、标准、控制以及集中化；因此，对于安全团队而言，首先要定义一个“云友好”的安全模型。
那数据中心和云服务的主要差别在什么地方呢？相比传统数据中心，云服务计算节点生命周期短，可动态弹性扩展，硬件、网络存储等都虚拟化成了服务，可编程的基础设施并且原生支持常见的部署模式；一般的数据中心的网络虚拟化程度低，硬件设备的维护更新，应用环境难以保持一致和快速重建；那公有云的安全有哪些挑战呢？
- AWS共享责任模型，事件响应如何做？根因分析？合规？
- 能否直接利用熟悉的现有的数据中心安全工具？授权问题，不同的假设前提，弹性伸缩高可用挑战，
- 秘钥管理，基础设施是否可信？自动化引导程序？硬件加密机？
Netflix 安全团队思考这些差异和挑战的基础之上，定义出了几个云优化安全模型的基本原则：
（1）区别对待，识别不同的风险等级；不是所有的环境、应用或数据都是同等重要，理解哪些是重要的并定义恰当的优先顺序，理解不同业务组织的风险偏好；
（2）利用并集成工具；持续集成和持续部署的管道是集成安全实践的非常重要的一个环节，跟开发人员使用一样的工具，思考哪些适合集成和什么情况适合隔离；在Netflix 团队实现自动化持续集成和发布管道之后，所有的变更都是一次新的发布，应用上线之后利用 AWS 弹性工作组结合自定义业务监控指标实现了自动的在线扩容和缩容，这样的自动化对于运维的影响重大，没有 CMDB，没有专门管理基础设施的系统，极少的登录生成系统的需求，开发运维的界限消失了；对安全方面的影响是，自动集成文件的完整性检查和监控，用户行为监控，漏洞和补丁管理内置在黄金镜像自动化制作环节。
（3）正确的事情一定要开发者友好简化；开发人员“很懒”很难为业务之外的任务花费太多时间，合乎情理的默认安全设定，为通用但难以推广的安全措施开发公共库，发布和推广可重用的安全模式
（4）拥抱自服务，但允许例外发生；自服务是公有云的一个突破性优势，将安全配置放置在最终用户随手可取的地方，比如SSL证书管理，某些防火墙规则，用户和权限管理等等。
对于合规性，Netflix面临多样化的合规性挑战比如PCI，数据隐私，SOX等等，传统的一些合规做法对云环境而言不是那么有利，需要采取更保守的策略；在应对方面，Netflix团队采取了隔离合规性敏感的业务系统，限制边界访问权限和增强日志审计，并利用多种工具集成实现合规性检查和管控。
实施可编程基础设施的安全有哪些优势？
AWS 完全 API 覆盖和支撑的“可编程基础设施”对于客户的优势就是非常方便实现自动化和可量化衡量，Netflix首创了混沌工程团队，使用各种工具（如 Netflix 的 Simian Army、故障注入测试、ChAP 和 Gremlin），以游戏日的方式让大家参与演习，演练如何应对灾难故障；同样的理念被 Netflix 安全团队采纳，他们使用 Safestack AVA、Metasploit、AttackIQ和 SafeBreach等工具，尝试主动攻击系统，强制工程师们在可控范围内做一些破坏性的行为。这种“建设性破坏”思路让安全团队对于各种安全事件及时测试和改进，进而将说不清道不明的“安全”原则和策略变得类似应用一样可迭代发展，可验证。
对于安全工程师而言，随着业务发展，云服务的大量使用以及微服务架构的流行，会遇到不少常见的技术挑战。大量的用户的访问和内部服务交互；从各种数据源会产生大量不同格式的数据；太多的需要管理的边界接口和“竖井”分离系统，相对的，可供选择的自动化可扩展的安全方案却很少。
实际日常项目中，想想你如何响应业务团队的需求？比如增加一个用户，查询某个业务系统所占用的资源，更新一个防火墙配置，帮一个业务系统打一个快照，禁用多因素认证等等；很多客户哪怕上了云，很多还是手工在操作响应业务方需求；最自然的开发者友好的方式当然是抽象、定义和实现这些操作接口如CreateUser(),DescribeInstances(), AuthSecurityGroup(), CreateSnapshot(), DeactiveMFADevice(),etc
Netflix猴子军团：安全猴子
Netflix 在2011年的一篇博客中《TheNetflix Simian Army》中谈到为了提升可靠性和可用性，他们发明了“混沌猴子”在上班时间，随机下架生产系统的计算实例，以便测试他们的系统可以在这样的故障中保持良好的健壮性而不影响最终用户；由于混沌猴子的成功，Netflix团队将类似的理念延伸到了安全等领域，用来确保系统的安全合规。
“安全猴子“被设计来支撑公司的自由和责任的文化，集成 AWS 的 API 和安全服务，提供一个统一云环境安全合规监控和分析的框架，Web 应用的漏洞扫描，自动化监控SSL证书和秘钥有效不过期，检查防火墙、用户、用户组和权限策略等安全配置发现违规和漏洞，并终止有问题实例。
举个例子来理解如何将“自由和责任”文化贯彻到安全设计中去，最小权限原则是 AWS 倡导的云安全原则的很重要的一条准则，但实际客户反馈，很难在实际项目中落地，业务最大，最后各种妥协和“无底线”；
在 AWS 上分配恰当的权限非常困难，因为到 2018年 AWS 上有3200种细粒度的权限条目，有100多种的云服务，如何破？从需求出发，Netflix 安全团队将服务的权限整个生命周期建模成创建、访问行为分析、自动适应新功能新权限策略和清理四个阶段；在创建阶段，安全团队提供了一个AWSIAM顾问工具Aardvark（https://github.com/Netflix-Skunkworks/aardvark）协助用户自助设定恰当的权限，定期访问AWSIAM的Access API更新并保存用户的访问行为；同时又开发了Repokid（https://github.com/Netflix/repokid）工具，利用Aardvark里面记录的访问行为记录，提醒并删除不需要的服务授权；
AWS是否能提供云安全咨询实施服务？
答案是肯定的；根据企业风险管理分类（GSRC）指导，企业需要关注治理、安全、风险和合规四大块，而信息安全领域最相关的是安全相关：数据安全，网络安全、应用安全和安全响应；风险相关：技术和运营；合规对于所有的线上服务而言都要遵守国家和地区的法律法规，如《网络安全法》，欧盟的《个人隐私保护条例》，其他根据客户的行业属性，有不同的合规要求，比如PCI-DSS等。
AWS 云安全专业服务提供三步走路径，分别为基础与规划，设计和构建，以及验证和响应三步，每个步骤涉及的大概内容如下图所示，仅供大家参考：
星星之火可以燎原：云安全卓越小组
DevOps和DevSecOps都涉及到企业文化相关的发展变化，从AWS的经验来看，成立一个2个披萨小团队，领导整个公司的云安全战略，帮助业务及开发运维团队落地和积累几个成功的应用上线经验，对企业的转型之路非常有帮助；这个云安全卓越小组有什么特征和职责呢？首先人数控制到10个人以下，包含不同的部门成员，有产品经理，架构师，基础架构工程师，安全工程师，运维和开发工程师等；其次，该虚拟团队以降低和消除DevSecOps转型的风险为己任，全职投入；最后，该团队要负责制定安全合规相关的原则，流程，可动手实现安全相关自动化工具，培训和影响其他团队采用最佳的安全实践，制定和指导安全基线。
DevSecOps：安全是每个人的责任
安全是建立客户信任的基础，保护您的客户应该是您的首要任务；没有这个，你就没有生意机会；在DevOps时代，每天都在发布新版本，过去的时候审查方式已经无法保证系统的安全，对代码改动和可能安全风险最清楚的应该是开发者，而不是旁部门的安全工程师；开发人员要有安全意识，应用的安全架构，安全编码，安全工具等等，在持续集成和持续部署流程中嵌入自动化的安全检查比如静态代码扫描，安全测试用例等等。
閱讀更多 假行家聊安全 的文章
