企业如何应对云原生时代的安全挑战?

Posted RancherLabs

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了企业如何应对云原生时代的安全挑战?相关的知识,希望对你有一定的参考价值。

本文整理自 SUSE 安全产品战略副总裁黄飞在 SUSECON 北京 2022 开源技术峰会上的主题演讲。

不断缩小的安全“边界”

应用软件发展平台发展线路很清晰,从最早的物理机发展到后来的虚拟机,可以运行多个操作系统在物理机上;2014 年开始,以 Docker 为首的容器厂商把容器技术推向大众,也带动了微服务的高速发展;到今天越来越多的企业客户甚至政府机关,开始在多云环境下部署分布式的集群服务。

从安全角度来看。在物理机时代我们保护一些安全的边界,这个边界可以是一个网关,可以是一个笔记本电脑,可以是个台式机,可以是个数据库,我们在入口位置部署相应的安全功能,基本上能满足安全的需求。

在虚拟机时代,原来基于物理机的安全方案已无法满足需求,虚拟机的安全技术方案应运而出,包括虚拟网络、负载均衡、数据中心的安全、虚拟存储的安全。

微服务的出现让安全系统再一次面临新的挑战。具有代表性的是容器网络的改变。容器网络是在传统的虚拟网络上又加了一层虚拟的容器网络,等于是网络多次虚拟化;同时所有原来基于进程之间的通信逐渐变成了所谓的服务,服务组件变成了网络上的一个节点。同时微服务节点之间的通信,甚至出现了 sidecar 这种比较高级的微服务应用,它的外部通信、内部通信,包括所有的数据服务都变成了一些被虚拟化了的数据服务。

一些新技术层出不穷,比如服务网格技术、多集群之间的通信、多云和混合云的技术、甚至 Serverless,这些都对安全边界提出了越来越多的要求。

我个人认为安全的边界其实是逐渐减小的,从原来保护一个巨大的物理机到保护一个虚拟机,到保护一个小小的容器,再到保护一个 serveless function,安全边界越来越小,甚至会逐渐消失掉。

云原生环境下的安全挑战

云原生环境下的安全挑战体现在 3 个方面:

容器环境的快速发展。 容器变化非常快,K8s、Docker 等很多容器的生命周期可能只有几十分钟甚至几分钟时间,这段时间之内它的版本 1 的容器要不要保护?怎么保护?如果仍然用传统方法保护,还没有来得及制定好策略,新版本就迭代上去了。这是一个很大的安全挑战:它太快了!

传统安全工具无法适应新的云环境。 例如,有的网络防火墙架在端口位置,它无法理解如果跨集群、跨云,所有的通讯已经加密,在底层网关节点上完全没有办法有效感知到任何的 contacts,没法有效地保护它。

另外传统的一些 agent based solution 会在所有节点上装 agent,但是我们曾经也看到有的厂商试图把 agent 装到所有的容器里,这似乎是可以实现一些安全功能,但是容器作为微服务,装 agent 就与主机没有差别了。这个完全跟容器发展、微服务的发展背道而驰,从技术角度来看,我认为这是一个错误的系统构架。

K8s 大量采用虚拟化技术,把数据、网络、计算全部虚拟化之后,对应用程序层来讲非常好用。基本上放一个容器上去,不需要关心底层的构架和平台网络,就全部可以自动跑起来。但是对于安全人员的挑战就是没有可见性,不知道这个容器到底是不是在做它应该做的事情,即虚拟化技术本身对安全管控形成了一定的屏障。

基于 CNCF 云原生系统构架分析安全功能的构建

CNCF 把云原生系统分为三大块:

  • 底层基础层,是整个云的基础构架,包括 compute resource、存储、网络、底层的操作系统和编排系统,底层系统现在已经有非常成熟的安全解决方案。

  • 应用程序生命周期。现在云原生应用程序基本上从开发到提交代码、到流程管道里会自动进行代码检查、测试、包装,包装成容器然后发布,到最后的安全策略形成,整个一套是全自动化的,这个应用程序的生命周期需要有很强的安全管控。例如所谓的 supply chain,很重要的一块就是管道安全,所有安全检查需要发生在生命周期里,每个环节都要有一定的功能。

  • 运行时的安全。我们把应用程序和数据生产化了以后,才是真正面对挑战的时候。此时,由于程序已经在公有云、私有云上跑了,端口已经打开,这就意味着已经公布于众。所有好的、坏的连接就会发生,首先是从网络层面会试图攻击你的端口扫描、网络端口,试着去获得非法授权,试着去攻击整个云环境,试着控制运行时的容器。一旦获得了某些提权之后,就可能有一些非法访问,比如挖矿。在云环境下,如果没有很好的运行时的监控和阻挡方法,会造成非常严重的损失,这样的例子数不胜数。

CNCF 把运行时的环境画的非常复杂,每一层都由非常复杂的模块组成,包括整个云的环境、整个云的配置。各个方面都需要做到安全检查,比如说一些 Access、存储系统的加密、密码权限要切分得非常清晰、云节点之间的安全策略、节点和节点之间的网络安全策略。

在这之上有 workload orchestration,比如 K8s 平台、Rancher 平台,这个平台使用大量的技术和功能。怎么保证你拉下来的镜像是安全的,是经过安全检查的?

再往上是应用层。云厂商没有办法管理,因为这些应用和服务是你自己开发的,或者是第三方开发的,需要你自己去管理、去运行,它是你整个企业业务最重要的服务工具,它的数据也是企业最重要的资产。云平台被攻克了还可以快速恢复,但是自己的数据被锁死、加密了,损失是非常大的。所以基本上分成这三层来构架。

安全模式的进化——零信任

公有云快速发展,大家一直在讨论安全的界限到底在哪里,谁应该负责哪一块的安全。一开始,很多客户认为公有云的安全应该交给供公有云厂商,但是真实情况并非如此。

这是 AWS 对外公布的 Security Responsibility Model,即公有云厂商只提供基础服务,只保证在它上面的数据全部加密,保证保存好所有平台的日志,以供分析,但是并不保证你的应用程序和数据安全。

这个应用程序和数据是指应用层的。公有云为你架构了一个销售系统,这个销售系统里会存储所有客户信息和数据库,但 AWS 是不会负责任何安全的,它也做不到,也不理解。这就是说应用程序级别的安全是必须由各个企业用户自己负责。

这就促生了过去五六年、七八年以来安全领域很重要的模式的进化。在传统安全方案里,我们基本上是基于所谓的信任、非信任的区域管控来做安全。举个例子,你新拿到一个笔记本电脑,这个笔记本电脑就是你的安全边界,我只要在笔记本电脑上装一个杀毒软件,做定期每天半夜的扫描,就认为是安全的了,这就是我信任它扫描过的我的硬盘和软件。

但是随着云技术的深入发展,终端逐渐变成显示装备,真正最重要的数据、流程、管道基本上都是在云那边作为服务的方式存在的,并不存在本地机器上。这就带动了整个安全模式的进化,我们传统的叫做被动式安全模式,新一代的叫主动式的零信任安全模式。 也就是说缺省情况下我并不信任任何内部外部的通信和内部外部的存取,我需要有一定的方法能够保证即使是内部过来的通信,也不是一个恶意存取,这就是所谓主动式的安全模式。

被动式安全模式策略往往基于黑名单。例如传统的防火墙,可以定义端口到端口,哪个 IP 地址可以通信,必须手动定义好,否则防火墙就不知道怎么处理了。主动式的环境下我们用白名单的方法。比如在容器环境下有一个数据库容器,缺省化就应该只跟内部的 web server 通信,他们之间使用了一个 certificate,可以互相认证,这就是主动安全模式,我就规定了只有拥有 SCR certificate 的服务器节点能够跟我通信。

从防火墙策略的角度来讲,怎么定义这件事?在新一代的安全模式下,我们用一种可以描述的语言,例如 K8s CRD ,可以把它描述成我这个容器可以跟谁通信,所有不能认证的节点,统统拒绝。 这很重要,因为黑客往往攻击到运行时的容器环境时,会以某一个节点作为桥头堡,试着攻击其他的节点,他们可能共享在同一个物理机、虚拟机、平台上,他们有机会看到其他在跑的容器,因为容器网络整个是平面化的。

即使你能够攻入到某个容器或节点,也不能有效地在内部进行刺探,这就是零信任安全的基本要素。

这里面还有很多,包括 CICD 管道安全也是其中的一部分,这就引申到欧美非常火的一个概念,即 supply chain security。因为在整个应用程序的发展周期里,在编译、制作软件的时候不可避免地需要使用到很多的开源软件包、第三方的包。怎么保证其中没有嵌入恶意程序?这就是管道 supply chain 的安全管控问题,它也是零信任的一部分。我不相信任何从第三方拉取的、甚至自己开发人员开发的软件,我都要在一定的安全检查之后才能认证是可用的,模块是可以被编译的,这也是一个零信任的安全概念。

所以有很多知名分析机构把零信任安全归纳为 7 个要素,基本上这 7 个要素涵盖了大中小企业甚至政府机关所需要保护的基本要素:用户、设备、网络和环境、应用程序和服务、可视化信息收集和分析、自动化管理和编排、数据。

如何更有效地保护这 7 个要素?简单来说有四个要点:

  • 最小化被攻击界面。被攻击界面越大,被攻陷的可能性越大,零信任安全是减小攻击界面非常有效的手段之一。

  • 实时检测和阻挡。很多安全软件可以检测到一些恶意事情的发生,检测到有人想偷取你的数据,但这些往往都是从日志里发现的,这已经晚了,数据已经被偷走了。需要强调的是,你要有一个安全方案能够在攻击发生的时候立刻检测到,并且阻断、报警,这才是最强的保护方法。

  • 不间断的可视化管理和合规检查。合规检查应该是全自动的,有一套系统在管道里不停地做合规检查,发生任何事情都能在第一时间通知和修复。

  • 安全应该具有一定的透明性和易用性。云原生的系统构架非常复杂,是基于一层一层各种各样的复杂的系统构建起来的,但这并不意味着安全需要很复杂。如果安全很复杂、易用性越来越差,就没法适应容器技术的发展。如果今天部署 K8s 只要几秒钟,那么安全就不能用几个小时甚至几天才部署起来、用起来,因为这个过程无法匹配,所以安全系统的本身要有透明性和易用性。

实现零信任安全的四个阶段

可以了解一下 SUSE NeuVector 和 SUSE Open Zero Trust。SUSE 把整个云原生零信任安全划分成四个阶段,并不一定要推翻你所有的安全投资和配置,其实可以从某一个单点开始介入和部署,逐渐深化,有了足够的信心和经验其实可以很快部署一套云原生环境的安全方案出来。

以上是关于企业如何应对云原生时代的安全挑战?的主要内容,如果未能解决你的问题,请参考以下文章

云原生时代,如何“玩转”容器安全?

云原生时代下,容器安全的“四个挑战”和“两个关键”

云原生时代下,容器安全的“四个挑战”和“两个关键”

网络分层架构灵活应对企业上云挑战

网络分层架构灵活应对企业上云挑战

网络分层架构灵活应对企业上云挑战