在对于私有云安全落地的实践中，如果我们已经有了一定的安全基础，对于后期架构策略的设计，需要花更多的精力在纵深防御和整体联动之上。
下面笔者会从多个维度，分析下能在私有云进行建设的纵深防御工作。
安全产品矩阵
在私有云的纵深防御中，有些同学可能觉得安全产品堆叠实际不会产生很好的效果，更大的价值上只是为了把每年采购的预算给花出去。
但其实，如果我们合理安排对于各项领域安全产品的组合，在一定程度上也能为我们的系统迁移上云，提供更加可靠的保障。
下面笔者会简单聊下各个领域的产品，为私有云安全架构的建设工作提供参考。
通信安全
在通信流量的安全控制上，通常我们会对边界进行阻断，再通过节点部署安全产品，逐步进行流量监控的补充。
对于堡垒机，我们可以通过4A认证，结合IAM和VPN对出入的流量进行细粒度管控。
边界防火墙，则可以对私有云出入口，以及不同安全域之间的流量进行拦截。
至于NIDS，则是部署在节点之后，利用高吞吐量和对内网流量协议的高切合度的分析规则，对防火墙没能拦截的内容做补充分析。
主机安全
在主机系统安全上，其实也存在很多竞品，功能有不少重合之处。
比较常用的就是HIDS，它会监控主机的事件和系统调用的监控，但对系统做适配和定制化。
而EDR作为终端安全产品概念，也被一些厂商概念混用，拿去做IDC（或者容器）安全监控了，这个不做过多的讨论。
此外，我们针对WebServer层面，是可以考虑嵌入RASP，做运行时安全监控的。 但是这个相对来讲，对业务性能影响也会更多，所以需要做审慎启用。
在私有云的容器群中，我们也可以考虑部署蜜罐。
业务方一般不会主动去访问蜜罐主机，所以当它们意外收到访问流量时，就可以在不动声色的情况下，被动监控黑客的横向拓展动作。
数据安全
我们的系统在上云时，除了要考虑数据库访问的稳定性和资源分配合理性，也需要对数据库访问的SQL进行行为分析。
或者，我们也可以直接针对单条恶意SQL进行阻断，或通过链式SQL分析进行告警，这就涉及到数据安全审计（数据库防火墙）了。
与此同时，我们在对外展示数据和存数据入库时，也可能涉及到加解密和脱敏问题，尤其是第三方人员账号介入，公共的云加解密（脱敏）平台能很好的缓释相关风险。
另外，对于我们通常讲的硬编码问题，云管平台也一般会配上KMS密钥管理功能，通过线上线下分离，也能缓释内部Git库对第三方开放的风险。
应用安全
在针对应用的保护上，从粗粒度来看，我们可以通过添WAF（主机层面和代理层面）、添加网页防窜改（植入文件监控）、添加反爬机制（做好验证和混淆策略，然后接入风控）。
同时，我们在考虑外部风险点时，防DDOS和CC也会是个重点治理方案，这个在前面的《私有云安全-边界安全设计实践》已经提到过。
最后，我们需要特别关注下，云管平台自带的（或者另行搭建）API安全网关，是否能完美支持我们私有云服务间接口的协议。
态势感知SA
安全态势感知产品的类别也很多，比如SIEM就是软件和服务的组合，通过对各类告警信息的整合，提升私有云整体审计溯源、应急响应的能。
而SOC其实跟前者有些类似，但更趋向于以资产为核心，以安全事件管理为关键流程，采用安全域划分的思想，建立一套实时的资产风险模型进行集中式管理。
至于Gartner之后力推的SOAR，个人觉得比较难去适配各家的产品。 上云的系统在针对各类标准不同的API进行自动化编排时，会对研发成本消耗加剧，应当有待观察后续的发展情况。
鉴权防护
在私有云的接口调用和角色操作行为方面，有很多地方涉及到细粒度鉴权。
我们可能不一定有机会，在代码层面去附加设计鉴权策略，但是可以借助云管平台和PaaS资源，根据现有的基础做一些配置优化。
中间件鉴权
在私有云架构里使用中间件时，由于采用的大规模集群管理，不可能单独做配置，所以一般会有两种基础鉴权方式：
-
第一，我们可以使用Security插件，这类是附带的中间件管理机制，但缺点是无法统一做管控溯源。
-
第二，我们可以在Nginx层面做反向代理，然后在此层面提高吞吐量，通过第三方接口回调或者代理配置进行认证。
API鉴权
至于API鉴权，在可信域范围之内，我们可以通过注册信息，直接进行通信交互。 否则的话，我们需要借助签名信息，与KMS密钥管理平台协作，完成交互认证闭环。
CDN鉴权
由于私有云上存储的文件，其访问和外发都是比较敏感的。
因此，除了要对文件本身做好加密，我们还需要在访问控制做好鉴权。
在访问URL时，我们可以通过带上私钥和时间戳的加密组合，结合身份来验证是否盗链访问，同时这样也能限制文件访问的过期时间。
此外，我们可以通过IP白名单的方式做辅助验证，系统发现更改来源IP（或者直接进行内网IP绑定）后，会直接拒绝访问。
微服务鉴权
这里讨论的其实不属于资源层面的，而是属于架构层面的认证鉴权。
微服务鉴权目前的做法，使用全局Token+API网关鉴权会多一些。
在这种形式下微服务是透明化的，通过网关时会把原始的用户令牌，转换为内部会话ID令牌，单方面注销相对来说也精准一些。
元素基准鉴权
元素基准鉴权的问题，在前面的系列文章《私有云安全-边界安全设计实践》也简单提到过。
我们通过对角色、资源、服务等多个维度，构建对应的复杂关系网络，其中再以某个元素为基准点，进行XABC类型的鉴权，实际应用可以参考IAM访问控制模型。
多因素鉴权
我们统一认证入口处，为了鉴别登入人的身份，通常会采用多因素认证。 比如短信+密码，或者令牌+密码，有时候还可能加上硬件KEY、指纹、虹膜识别等等技术手段。
在这里需要注意的是，由于私有云环境是相对固定的运维人员做操作，也希望减少对外的交互，最好采用在断网情况下也能进行认证的方式。
人为监督
在私有云复杂环境下，如果出现问题，我们需要对资产进行细分，建立相应资产责任人制度。
- 落地一级责任人自查，针对资源设置直接责任人，方便出问题时进行溯源和告警。
- 实行多人Backup机制，针对资源进行归类划分，一个资源群有2-3人递归负责。
- 推广支撑部门互相监督，在业务中如果出现了异常调用的流量，支撑部门需要对可能出现问题的一方进行监督提醒。
- 制定分级上报流程，在上报期间，如果出现延期响应和业务方推诿后，可以分期逐级再向上推送。
分级隔离
在针对私有云内的安全隔离上，主要分多个层面逐级进行隔离，建立纵深防御的隔离体系。
ACL隔离
ACL一般是在防火墙或者交换机上实现的，是基于IP地址的控制策略。
在此基础上，我们通过IP地址段和端口列表的形式进行控制，但其控制粒度相对较粗，这种适合对应用层访问控制进行补充。
VPC区域隔离
专有网络VPC属于第二层的隔离，可以为每个用户创建多个子网。
VPC代表了不同的租户，以它为限制区域隔离出了租户，每个租户的子网之间也是可以继续隔离的。
部分云厂商由于拓展偏好，借鉴了AWS的Vxlan协议，对每个VPC网络进行隔离。
但其实传统的Vlan隔离出来的数量，也是够用的。
另外，在每个云租户内部，如果隔离要求比较严格，其实也可以借用VPC进行安全隔离。
安全组隔离
在云租户内部的VPC内，如果还想尝试更细粒度的划分，可以尝试安全组形式的隔离。
安全组用于设置多台云服务器的网络访问控制，是重要的网络安全隔离手段，用于在云端划分安全域。
安全组是一个逻辑上的划分，这个分组由同一个地域内具有相同安全保护需求，并相互信任的实例组成。
它在不同的云厂商实现中，叫法和实现方式可能也有差异，比如将VPC内的隔离成为Subnet（子网），意思应该与安全组一样。
容器层隔离
这个概念是用虚拟化技术来作为容器（确切地说是 Kubernetes Pod）的沙箱，目前主流的开源安全容器项目是Kata、Gvisor，各大互联网厂商应用的也比较多。
虽然作为安全容器项目，Kata和Gvisor目前在业务稳定性和兼容性上，比起Docker还有待优化，但毕竟是未来替代发展的大趋势。
它们能提供虚拟机级别的隔离性，这个安全级别是在过去数年以来的云服务中，是被广泛接受的。
新型的安全容器不再共享内核，而是利用Hypervisor等技术进行加固和隔离。
它们对Linux依赖都是比较固定，而且能在每个阶段做到安全审计，降低被攻破的风险，是我们对于容器研究里程碑的较大的突破。