谈谈云计算数据中心DevSecOps运维模式中的安全性

（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”（安全）的理解，以及自己工作中的一些探索。其目的在于抛砖引玉，带动大家一起讨论如何提高云服务数据中心的安全性，确保业务连续性。其中有些观点不一定正确，，欢迎批评指正。

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

【编辑推荐】

1. 微软：开源软件和云计算是推动人工智能和机器学习的主要方式
2. 开源模式下的云计算和大数据现状
3. 云计算技术的出现或导致IT运维体系产生重大变革
4. IBM 340亿美元收购红帽，云计算时代的开源软件有哪些收入模式？
5. 为什么说云计算运维是新“贵”？

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!