本文想从技术的角度谈谈我对云计算数据中心 DevSecOps 运维模式中的安全性的理解，和过去几年我在云服务业务连续性管理方面的探索。

现在公有云服务商都不约而同地转向 DevSecOps 模式。DevSecOps 是 DevOps 的另一种实践，它将信息技术安全性作为软件开发所有阶段的一个基本点。安全性，不仅涉及各种层次的隔离和合规性检查，而且涉及从技术层面确保业务连续性。在 ISO/IEC 27001 信息安全管理体系中，“业务连续性管理”是安全管理中非常重要的一环，目的是为减少业务活动的中断，使关键业务过程免受主要故障或天灾的影响，并确保及时恢复。“业务连续性管理”是安全治理中的术语，把它转化到计算机产品中的术语，就是“可靠性，可用性和可维护性（RAS）”。

一、去中心化 

每个云计算数据中心都有一些中心化的共享服务，比如防火墙、DNS、核心路由、负载均衡器、分布式存储等等。虽然IT基础架构在设计和代码执行充分考虑到了高可用和高通量，可是实际上，总是有一些例外。比如，我们在一次防火墙升级时，因为一个偶发的 Bug，Peer 并没有接管所有的流量，结果导致了很多服务的非计划中断。

在这之后，将 IT 基础架构从中心化结构分解成众多的较小的故障域结构，成了我们在设计和改进云计算数据中心的关键考虑因素之一。我们云基础架构分布于几十个地区Regions。每个地区的数据中心又从物理上分隔为 3 个可用性域Availability Domains，这些可用性域所有的基础设施都独立的。可用域彼此隔离，容错，并且几乎不可能同时失败。由于可用性域不共享基础设施（例如电源或冷却）或内部可用性域网络，因此区域内一个可用性域的故障不太可能影响同一区域内其他可用性域的客户。在每个可用性域里，我们又进一步去中心化，分组为多个故障域Fault Domains。故障域是一组硬件和基础架构。通过适当地利用故障域，我们的客户可以提高在 Oracle Cloud Infrastructure 上运行的应用程序的可用性。例如，客户如有两个 Web 服务器和一个集群数据库，我们会建议他们将一个 Web 服务器和一个数据库节点组合在一个故障域中，将另一半组分配到另一个故障域中。这可以确保任何一个故障的失败都不会导致应用程序中断。

除了上面这个故障域，我们还针对 Oracle SaaS 服务（Oracle 的 ERP、CRM、HCM 等行业解决方案，目前有超过 2.5 万的企业客户）提出了具体的指标：任何组件的灾难事件都应无法导致该数据中心 10% 的客户，或 100 个客户的服务中断。为此，我们团队几年前设计并实施一个去中心化的改进方案以实现这一目标。这是个以零停机时间为目标的基础架构优化方案，涉及了防火墙、DNS、负载均衡器、Web 前端、存储、IMAP 等等。

二、备份与容灾

备份与容灾是保证服务安全性和可用性绕不开的话题。虽然备份与容灾的成本很高，我们还是提供了针对各种场景的备份与容灾方案供客户自己选择。

备份数据使用率很低。在生产环境中，我接到的数据恢复请求平均每个季度不到千分之二，主要是顾客测试环境中的数据恢复。而真实的生产环境的 SaaS 服务数据恢复请求平均每个季度不到万分之二。为了这万分之二的使用概率，运维部门每周都会抽取一定比例的备份按照特定的安全的流程进行数据恢复测试和验证，以确保备份是有效的。

我还和我的同事们还开发了 Oracle SaaS DR 的执行方案。客户如购买了这一服务，则可通过 Oracle Site Guard 的 Web GUI 界面的简单几步操作，即可快速将生产环境从一个数据中心切换到另一个数据中心。蘑菇街技术服务总监赵成先生在他的文章《做容灾，冷备是不是个好方案》中提到了冷备的难点。我们的 DR 方案在技术上重点就是解决了非计划中断之后，数据同步、清除异常锁文件、负载均衡器更新、应用配置更新、使用 Data Guard 切换数据库等方面的问题，以及主节点恢复后如何进行反向同步并自动切换到非计划中断之前的配置。关于我们 DR 方案的 RTO（Recovery Time Objective）和 RPO（Recovery Point Objective），你可以 Google 查询“Disaster Recovery for Oracle SaaS Public Cloud Services ”，从官方正式的文档中得到。实际上，我们生产环境中验证的数据比对外公布的数据要好得多。

三、持续改进访问控制，在效率和安全中找到平衡点 

我把访问控制的范围概括为：客户授权的特定的人、在指定的时间内、以验证过的安全方式、访问脱敏的内容，并尽可能地加密客户数据路过的所有通道和节点。

（1)、客户授权。我们根据客户的行业属性不同和数据安全性需求不同，定制了多个客户安全审计部门参的访问控制批准工作流。这个授权的程序涉及 SRE 工程师的国籍、第三方背景调查、客户数据保护相关的安全培训、笔记本电脑的硬盘加密状态等。访问授权的时效可能是一次性、可能是几天、也可能是 1 个月，根据行业特点和客户需求而定。

（2)、访问控制的细粒度。在技术的执行上，除了 VPN 和 Bastion (又称 Jumpbox) 外，我们还引入了 Oracle Break Glass 方案来让外部客户自己来批准和授权Oracle 的 SRE 工程师对系统和服务的管理访问，提供应用层的额外的安全性。Break Glass 访问是有时间限制的，它通过仅提供对 Oracle 支持人员的临时访问来保护客户的数据。我们还引入 HSM 来加强云服务环境中的数字密钥的管理。在新一代的 Oracle SaaS 服务中，任何工程师对数据库的 SQL 操作，会自动挂起并自动产生一个要求批准执行的SR，直到相关人员审查 SQL 语句安全性并批准后才会执行。

（3)、数据加密。除了这种受控访问之外，我们还使用 Oracle 的 Transparent Data Encryption（TDE）和 Database Vault 对静态数据行保护和审计。客户可以控制 TDE 主加密密钥并管理其生命周期。

（4)、渗透测试、安全评估、修复和强化。另外，我们还周期性从技术的角度审查各个组件的认证和授权协议的安全性、传输层加密和网络隔离的安全性、数据访问控制的细粒度，并引用漏洞扫描、渗透测试和评估，对发现的潜在性弱点及时自动化的修复和强化方案。

四、从运维的角度持续验证和改进每个组件的可靠性、可用性和可维护性

在谈到可靠性时，大家常提到混沌工程Chaos Engineering。我个人觉得混沌工程是对于云服务商的服务消费者而言。云服务消费者往往由于缺少对低层技术的了解，所以需要引入混沌工程触发服务器实例失效、网络故障、应用故障来使自己研发工程师递交的运行于公有云服务能够容忍故障同时仍然确保足够的服务质量。

对于公有云服务商而言，我们还得走专家模式，引入破坏性测试，从运维的角度，持续验证和改进每个组件的可靠性、可用性和可维护性，特别是可能性的故障的恢复的解决方案，从而提高系统在故障后可以花较少的时间将服务恢复到运行状态的能力。

我们通常是将整个服务的 IT 基础架构，分解为若干组件，再从以下七个维度来分析和改进每个组件恢复的解决方案。

（1)、单点故障，例如，硬件的各个组件、软件的各个进程、硬盘热拔插、坏盘是否会导致零 I/O、Chatty Disk 是否会导致零I/O、DISK Resilvering、系统启动盘、硬盘架Enclosure。

（2)、集群框架，例如，单个储存节点的 CRASH、HANG、PANIC、手动切换集群、手动集群 Failback、集群的 Split Brain、集群的 heartbeat 故障、高负荷下的集群接管操作、分布式锁失效测试、数据一致性验证失效测试。

（3)、共享服务，例如，如果有多条配置，则在 DNS、NTP、AD、LDAP、NIS 中添加或删除一个条目不应影响数据访问和管理接口的访问。

（4)、数据损坏，例如，包括触发 Split Brain 并观察是否存在数据损坏问题并找出数据服务恢复的解决方案，触发 RAID 损坏并观察是否存在数据损坏问题并找出数据服务恢复的方案。

（5)、基础架构服务故障。

（6)、管理和监控接口的可靠性。

（7)、Overlay 技术带来的性能和诊断的问题，以及服务恢复的解决方案。

正因为对每个组件相应的技术领域有了深入研究和充分的准备，对于升级的云服务性能和可用性问题（P1 Escalation），我所在的 SRE 团队基本上实现了“15 分钟内响应并完成数据收集与分析、15 分钟内给出解决方案”。

总之，云计算数据中心 DevSecOps 运维模式中的安全性是一个持续改进的过程，我们要充分考虑去中心化、备份与容灾、持续改进访问控制，并引入破坏性测试，提高系统在故障后快速恢复到运行状态的能力。

本文旨在简单阐述一下作为一个 IT 系统架构师，我对当下云计算数据中心 DevSecOps 运维模式中的“Sec”（安全）的理解，以及自己工作中的一些探索。其目的在于抛砖引玉，带动大家一起讨论如何提高云服务数据中心的安全性，确保业务连续性。其中有些观点不一定正确，欢迎批评指正。

欢迎大家发表留言，列出你的企业从安全的角度改进”业务连续性“方面的经验。