浅谈云计算数据中心DevSecOps运维模式中安全业务连续性管理的探索。现在，公共云服务提供商正在一致转向DevSecOps模型。DevSecOps是另一种DevOps实践，它将信息技术安全视为软件开发所有阶段的一个基本点。安全不仅涉及各个层面的隔离和合规检查，还涉及技术层面的业务连续性保障。在ISO/IEC27001信息安全管理体系中，“业务连续性管理”是安全管理中非常重要的一环。目的是减少业务活动的中断，保护关键业务流程免受重大故障或自然灾害的影响，并确保及时恢复。“业务连续性管理”是安全治理中的一个术语，翻译成计算机产品中的一个术语，就是“可靠性、可用性和可维护性（RAS）”。1.去中心化每个云计算数据中心都有一些集中共享的服务，如防火墙、DNS、核心路由、负载均衡器、分布式存储等。虽然IT基础设施的设计和代码执行充分考虑了高可用性和高吞吐量，但实际上，总有一些例外。比如我们升级防火墙的时候，Peer因为偶尔的bug没有接管所有的流量，导致很多服务非计划中断。之后，将IT基础设施从一个集中式结构分解为无数更小的故障域结构，成为我们设计和改进云计算数据中心的重点考虑之一。我们的云基础设施分布在几十个地区（Regions）。每个区域的数据中心在物理上分为三个可用性域（AvailabilityDomains），这些可用性域的所有基础设施都是独立的。可用性域彼此隔离，具有容错性，并且几乎不可能同时出现故障。由于可用性域不共享基础设施（例如电源或冷却）或内部可用性域网络，因此一个区域内的一个可用性域发生故障不太可能影响同一区域中其他可用性域的客户。在每个可用性域中，我们进一步分散并分组为多个故障域（FaultDomains）。故障域是一组硬件和基础设施。通过正确利用故障域，我们的客户可以提高在Oracle云基础设施上运行的应用程序的可用性。例如，如果客户有两个Web服务器和一个集群数据库，我们建议他们将一个Web服务器和一个数据库节点组合在一个故障域中，并将该组的另一半分配给另一个故障域。这确保任一故障的失败都不会导致应用程序中断。除了上述故障域，我们还针对OracleSaaS服务（Oracle的ERP、CRM、HCM等行业解决方案，目前拥有超过25000家企业客户）提出具体指标：任何组件灾难不应该造成这10%的客户在数据中心，或100个客户，停止服务。为此，我们的团队在几年前设计并实施了去中心化的改进来实现这一目标。这是一项以零停机为目标的基础设施优化，涉及防火墙、DNS、负载平衡器、Web前端、存储、IMAP等。2.备份与容灾备份与容灾是保障业务安全性和可用性绕不开的话题。虽然备份容灾的成本较高，但我们依然提供各种场景的备份容灾解决方案，供客户选择。备份数据使用率低。在生产环境中，我平均每个季度收到的数据恢复请求不到千分之二，主要是客户测试环境的数据恢复。而实际生产环境中SaaS服务数据恢复请求平均每季度不到万分之二。针对这2/10,000的使用概率，运维部门每周都会抽取一定比例的备份，按照特定的安全流程进行数据恢复测试和验证，确保备份有效。我和我的同事还开发了OracleSaaSDR的实施。如果客户购买了这项服务，他们可以通过OracleSiteGuard的WebGUI界面通过几个简单的步骤快速将生产环境从一个数据中心切换到另一个数据中心。蘑菇街技术服务总监赵成先生在他的文章《做容灾，冷备是不是个好方案》中提到了冷备份的难点。我们的容灾解决方案的技术重点是解决数据同步问题，异常锁文件清除问题，负载均衡器更新问题，应用配置更新问题，计划外宕机后使用DataGuard切换数据库，主节点恢复后如何进行Reversesync和Reversesync和自动切换到计划外停机前的配置。关于我们容灾方案的RTO（RecoveryTimeObjective）和RPO（RecoveryPointObjective），大家可以谷歌“OracleSaaS公有云服务的灾难恢复”，从官方文档中获取。事实上，在我们的生产环境中验证的数据比发布的数据要好得多。3、不断完善门禁控制，在效率与安全之间找到平衡点。我将访问控制的范围概括为：客户授权的特定人员在规定的时间内以经过验证的安全方式访问脱敏内容。并尽可能对客户数据经过的所有通道和节点进行加密。(1)客户授权。根据客户不同的行业属性和数据安全需求，定制了多个客户安全审计部门参与的门禁审批流程。这个授权过程涉及到SRE工程师的国籍、第三方背景调查、客户数据保护相关的安全培训、笔记本电脑硬盘加密状态等，访问授权的时限可能是一次性的、几天的、一个月的，取决于行业特点和客户需求。(2)细粒度的访问控制。在技??术实现方面，除了虚拟专用网和Bastion（又名Jumpbox），我们还引入了OracleBreakGlass解决方案，让外部客户批准授权Oracle的SRE工程师管理系统和服务的访问，以及提供额外安全的应用层。BreakGlass访问是有时间限制的，并且通过仅向Oracle支持人员提供临时访问来保护客户数据。我们还引入了HSM来加强对云服务环境中数字密钥的管理。在新一代OracleSaaS服务中，任何工程师对数据库的SQL操作都会自动暂停，并自动生成请求批准执行的SR，相关人员审核SQL语句安全并批准后才会执行它。(3)、数据加密。除了这种受控访问之外，我们还使用Oracle的透明数据加密(TDE)和DatabaseVault对静态数据进行行保护和审计。客户可以控制TDE主加密密钥并管理其生命周期。(4)、渗透测试、安全评估、修复加固。此外，我们还定期从技术角度审核各组件的认证授权协议的安全性、传输层加密和网络隔离的安全性、数据访问控制的细粒度等。发现的潜在弱点自动修复并及时加固。4、从运维角度不断验证和提升各组件的可靠性、可用性和可维护性。说到可靠性，人们往往会提到混沌工程。我个人认为混沌工程是针对云服务商的服务消费者的。云服务消费者往往缺乏对底层技术的理解，因此需要引入混沌工程来触发服务器实例故障、网络故障和应用程序故障，使自己研发工程师提交的运行在公有云上的服务能够容错，同时仍然保证足够的服务质量。对于公有云服务商，我们还是要走专家模式，引入破坏性测试，从运维的角度不断验证和提升各个组件的可靠性、可用性、可维护性，尤其是可能出现的故障。恢复解决方案，从而提高系统在发生故障后在更短时间内将服务恢复到运行状态的能力。我们通常将整个业务的IT基础设施分解成若干个组件，然后从以下七个维度分析和改进每个组件的恢复方案。(1)单点故障，例如硬件的各个组成部分，软件的各个进程，硬盘热插拔，坏盘是否会造成零I/O，ChattyDisk是否会造成零I/O，DISKResilvering，系统启动盘，硬盘架（Enclosure）。(2)集群框架，例如单存储节点的CRASH、HANG、PANIC、手动集群切换、手动集群故障恢复、集群SplitBrain、集群心跳故障、高负载下的集群接管操作、分布式锁故障测试、数据一致性验证失败测试。(3)共享服务，比如有多个配置，在DNS、NTP、AD、LDAP、NIS中增加或删除一个条目，不应该影响数据访问和管理界面访问。(4)数据损坏，例如触发SplitBrain并观察是否存在数据损坏问题并找出数据服务恢复的解决方案，触发RAID损坏并观察是否存在数据损坏问题并找出解决方案数据服务恢复。(5)基础设施服务故障。(6)管理和监控接口的可靠性。(7)Overlay技术带来的性能和诊断问题，以及服务恢复的解决方案。由于对每个组件相应技术领域的深入研究和充分准备，对于升级后的云服务性能和可用性问题（P1Escalation），我的SRE团队基本做到了“15分钟内响应并完成数据收集和分析，并在15分钟内给出解决方案。”总之，云计算数据中心DevSecOps运维模式下的安全是一个不断提升的过程。必须充分考虑去中心化、备份容灾、持续改进访问控制、引入破坏性测试，提高系统发生故障后的安全性。快速恢复到运行状态的能力。本文旨在简要说明作为一名IT系统架构师，我对当前云计算数据中心DevSecOps运维模式中“Sec”（安全）的理解，以及工作中的一些探索。其宗旨是抛砖引玉，带动大家共同探讨如何提高云服务数据中心的安全性，保障业务连续性。其中部分观点不一定正确，欢迎批评指正。欢迎大家留言，列出贵公司从安全角度提升“业务连续性”的经验。
