从技术的角度谈谈对云计算数据中心DevSecOps运维模式中的安全性的理解

从技术的角度谈谈对云计算数据中心DevSecOps运维模式中的安全性的理解

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

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

一、去中心化

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

二、备份与容灾

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

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

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

（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主加密密钥并管理其生命周期。

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

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

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

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

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

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

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

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

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

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

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

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

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