在对于私有云安全落地的实践中,如果我们已经有了一定的安全基础,对于后期架构策略的设计,需要花更多的精力在纵深防御和整体联动之上。
下面笔者会从多个维度,分析下能在私有云进行建设的纵深防御工作。
安全产品矩阵
在私有云的纵深防御中,有些同学可能觉得安全产品堆叠实际不会产生很好的效果,更大的价值上只是为了把每年采购的预算给花出去。
但其实,如果我们合理安排对于各项领域安全产品的组合,在一定程度上也能为我们的系统迁移上云,提供更加可靠的保障。
下面笔者会简单聊下各个领域的产品,为私有云安全架构的建设工作提供参考。
通信安全
在通信流量的安全控制上,通常我们会对边界进行阻断,再通过节点部署安全产品,逐步进行流量监控的补充。
对于堡垒机,我们可以通过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依赖都是比较固定,而且能在每个阶段做到安全审计,降低被攻破的风险,是我们对于容器研究里程碑的较大的突破。