随着云计算的不断发展,尤其是应用微服务化改造之后,保持微服务之间通信流量的安全要比保护单体应用的安全要困难的多,而在云原生环境下,动态的容器或Severless无服务器计算作为基础设施,识别用户操作的异常行为也变得更加困难。
目前大多数组织的安全策略和工具并没有跟上微服务应用设计和部署方式的快速变化,传统的安全工具是为具有明确边界的IT环境设计的,为外挂和旁路的方式部署,而对于在原生云中可快速扩展的工作负载,这些安全工具几乎不能有效的实现安全防护和协作等。
大多数组织并未因云原生架构的引入,快速调整他们的IT安全策略,更缺少成功实施安全策略的实践。组织的安全策略也应跟随着新的云服务类型而持续不断的适应。
下文主要描述适用云原生安全策略的挑战及以及说明IT团队必须采用哪些工具、流程和理念,以及对通用的容器编排平台Kubernets的加固介绍了优秀实践。
-基于边界的安全,使用以应用程序和服务定义明确的边界,然后使用防护墙执行保护
-采用静态的扫描和分析,在部署应用之前,通过静态扫描识别漏洞和弱点
-安全策略、安全工具和流程的设计并没考虑到服务器的可伸缩性,由于基础设施的增长和应用程序更新相对较慢,这种方式是可以接受也是有效的;
-孤立的团队,IT安全团队和软件开发团队及运维之间互相独立,也会存在一些推诿的现象发生
-合规需求,法规合规需求是最基本的,满足合规的安全要求是安全的主要建设驱动,企业的个性化的需求还不存在。
以上安全策略在云原生时代仍然可以发挥作用,但是这些安全方法本身不足以保障基于云的工作负载的安全性和兼容性。
以上传统安全的部署方式不能满足云原生环境对安全的需求,主要有几个关键原因,这也反映了云原生新技术发展的趋势。
原生云基础设施自身的一些特征使传统的安全工具和流程无法适应。首先,采用云优先战略的组织并不一定拥有或直接控制云基础设施,采用公有云时,还依赖第三方来确保云的物理安全。因此,基于安全考虑去调整硬件和软件环境的能力是有限的。其次,云中的访问控制模型可能不适合混合云的环境,虽然云平台大多提供了配置访问控制的工具,但这些工具通常限定于特定云平台,且功能有限,无法支撑组织可能存在的多云和复杂的应用场景。最后,混合和多云架构的使用,进一步增加了保护工作负载的复杂性。当使用多个云时,可能涉及到多个访问控制和管理工具,同时还要监视跨多云环境分布的工作负载的安全漏洞和可能的入侵。
容器的环境是高度动态的,容器会不间断的生成和退出,很难按照管理虚机的安全基线的方式来确定运行环境的安全状态,并且容器是以进程隔离为基础的,这也增加了可能导致入侵的安全风险。应用微服务化的部署,导致容器严重依赖网络进行通信,若没有适当的保护网络端点或将流量暴露到外部,可能会造成重大的安全风险。
容器生态系统产生了很多管理工具,除了流行的Kubernetes社区开放的工具外,许多公有云厂商也提供自己的编排工具,这也导致很难有统一的安全最佳实践。
无服务器计算功能,依然是一种新的技术,但很难入手开发无服务器相关的安全策略。此外,从IT操作角度看,对部署的代码管理工作量是最小的,但从安全角度看,意味着用户有更少的控制权,更多依赖云提供商保障工作负载的安全。因此需要在不损害灵活性的情况下,制定安全策略以保持无服务器工作负载的安全性。
软件定义基础设施带来更的灵活性和伸缩性,但由于不能一致的映射到物理系统,使得跟踪和安全的隔离变得困难,除非在基础架构中添加额外的控制层,但也增加了管理的复杂性。另外,由于引入了更多的软件工具,导致潜在的攻击载体也会变得更大。
云原生时代最大的安全挑战可能来自于云基础设施和服务的不断发展和变化。在云原生时代的初期,云服务局限于基本的云存储和虚拟服务器。近年来,由多种云存储类型、各种虚机实例,扩展到托管Docker容器环境、无服务器计算、基于云的大数据服务、监控服务等等。这些各类云服务额外增加了组织应对保护云工作负载的的安全挑战。可以肯定未来云服务会更加复杂和多样化,组织需要去适应云计算的变化,及时调整安全工具和安全策略。
依靠传统的安全工具和流程虽然无法满足云原生的安全需求,但仍然可以通过围绕云工作负载的安全需求调整安全策略,并从安全能力的延伸、多云架构下的保护、流水线集成、考虑多种部署模型等多个方面将安全能力集成入云原生环境中。
基于边界的安全策略和工具在云中依然扮演重要的角色,静态防火墙规则和网络监视工具可以保护网络端点并拦截外部恶意的流量攻击,然而仅仅依靠数据中心外围的安全防护,对云原生来说是远远不够的,Runtime的安全工具监控应用程序本身,而不是发送和接收流量是云原生安全的关键。并且要确保动态的防火墙控制规则能自动化的适应云内环境的动态伸缩和改变。
云原生的安全策略不应该专门针对任何特定云的设计,安全工具和流程的设计也必须考虑在多个云之间移动工作负载或将负载运行在多个云时,不必每次都需配置和更新安全策略。应该在更高的层次上实现一种云无关的安全策略,并与组织选择采用的私有云服务或其他公有云服务和工具之间进行安全的协同管理。
在要维持快速的软件交付的组织中,不可能将安全从软件开发生命周期中剥离出来。DevOps团队必须接受DevSecOps的概念,并加强安全人员与开发人员、运维人员之间的密切协作,确保在保证应用快速交付的同时,可以快速识别和解决安全问题。
此外,在生产环境中,漏洞的修复对于保障用户数据的安全尤为重要,在DevSecOps环境优化了修复生产环境中方法,遵循安全前移的原则,尽早发现、尽早修复,使得DevSecOps安全策略是在不损害安全性并且能维护快速、高效软件交付过程的唯一方法。
在云原生时代,应用程序的工作负载能够以多种方式部署。支持本地运行、在基于云的虚拟机中运行,使用容器、无服务器功能或未来可能其他下一代技术方式部署。一个有效的云原生安全策略,不应专用于某种部署类型的方案,必须能够支持任何类型的工作负载和架构,以适应组织合规、个性化的安全需求。
除非您的组织完全采用公有云托管的容器平台,您都首先要考虑原生云的核心引擎容器编排平台自身的安全,下面以较为流行的Kubernetes平台为例简要介绍。
结合Kubernetes的安全加固的实践,从管理员视角可以从如下几个方面的加固:
1、集群的安全,在Kubernetes的早期,默认设置使控制平面在许多重要方面不安全。不同的安装工具可能以不同的方式配置您的部署,这使得情况更加复杂。配置的设置对于Kubernetes控制平面安全非常重要,需要在部署在生产环境之前,对配置进行检查和加固。
首先,API Server作为管理节点的入口,需要确保关闭匿名访问、通过TLS加密通道、限定匿名访问API Server的权限,并进行健康检查等,也可对API Server增加防火墙等额外防护;对于kubelet的证书,要实现轮换机制;
其次,保障作为存储集群配置和状态信息的etcd的安全,需要考虑加密存储。因为只能有Kubernetes控制平面组件能与etcd有业务通信,所以还可以使用网络防火墙来阻止来自其他来源的流量到达etcd集群。
再次,集群配置设置的安全验证,可以考虑与建议的测试对照验证,也可以考虑渗透测试的方法检查有无弱点。最后,CIS提供了Kubernets安全设置基线的最佳实践。虽然所有的建议配置并不完全适合您的环境,您可根据基线检查发现您没有意识到的不安全的设置。
2、身份验证,集群所有的组件,例如运行在节点上的kubelet,以及发出kubectl命令的用户,都需要与API Server交互。为了处理请求,API Server首先验证是谁发出请求,服务器首选需要建立调用者的身份。用户账户和服务账号常用于集群中用户的访问和服务的调用。
首先应针对性的设置不同的服务账号,而不是启用默认的Service账户,防止被滥用和无法跟踪的风险。其次,根据集群部署的规模和用户组织的策略,可使用不同的验证策略:如静态密码、令牌、X.509证书、OADC(JWT),也可以与其他的验证协议LDAP、SAML、Kerberos集成。根据业界优秀实践,在验证中引入上下文的验证。如果不能使用第三方Idp,首选X.509证书方式,需要确保组织人员的凭据是唯一的,并执行生命周期的管理。
3、授权策略,Kubernetes通过使用API Server授权API请求,根据策略评估请求的属性,默认情况下,权限被拒绝,除非策略明确允许。Kubernetes提供多种授权模型用于权限的控制,节点的授权,根据计划运行的pod向kubelets授予权限;基于ABAC,通过用户属性、资源属性等授权;Webhook,该模式允许与kubernetes—外部授权器集成;RBAC,RBAC是Kubernetes中对开发人员和管理员最重要的授权方法,关于角色,主要区分集群和Namespace两种范围。
基于优秀实践,应使用RBAC模式,可升级kubernets版本到1.8及以上,确保该模式在API Server中启用。禁用默认Service Account的令牌自动挂载功能。
正如云彻底改变了数据和应用程序的部署方式一样,它也从根本上改变了IT的安全需求,以往外挂式的、基于边界设计的安全工具很难有效的保护动态的云工作负载,当前需要重点考虑容器模式下工作负载的运行态安全。我们需要重新调整和重新设计安全策略,以适应组织多云的架构,确保安全策略在异构环境下的统一执行。DevSecOps概念和框架提供了安全集成到CI/CD的最佳方法。不同于传统的云,容器编排平台是云原生的核心引擎,因此平台的安全加固是保障平台可用的基础,我们首要做的是结合官方实践和业务优秀实践对平台进行安全加固。
部分内容参考:https://www.aquion.com.au/wp-content/uploads/2018/12/Cloud-Native-Security-Whitepaper.pdf