私有云安全-纵深防御设计实践

在对于私有云安全落地的实践中,如果我们已经有了一定的安全基础,对于后期架构策略的设计,需要花更多的精力在纵深防御和整体联动之上。

下面笔者会从多个维度,分析下能在私有云进行建设的纵深防御工作。

纵深防御

安全产品矩阵

在私有云的纵深防御中,有些同学可能觉得安全产品堆叠实际不会产生很好的效果,更大的价值上只是为了把每年采购的预算给花出去。

但其实,如果我们合理安排对于各项领域安全产品的组合,在一定程度上也能为我们的系统迁移上云,提供更加可靠的保障。

下面笔者会简单聊下各个领域的产品,为私有云安全架构的建设工作提供参考。

产品纵深

通信安全

在通信流量的安全控制上,通常我们会对边界进行阻断,再通过节点部署安全产品,逐步进行流量监控的补充。

对于堡垒机,我们可以通过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依赖都是比较固定,而且能在每个阶段做到安全审计,降低被攻破的风险,是我们对于容器研究里程碑的较大的突破。

参考文档

微服务认证鉴权的四种方案

CDN 如何实现鉴权配置

关于网络安全域隔离问题的研究与思考

安全容器:开启云原生沙箱技术的未来

云原生之容器安全实践

全景解析5种云安全技术方案