“马其诺防线”失效,如何做好容器云安全?

第一次世界大战之后,为了防止德军突袭,法国花重金用了十几年时间在德法边境建造了一座延绵390公里的防御工事,内设大炮、壕沟、堡垒,甚至是厨房、医院、工厂,深沟高垒、四通八达——这就是大名鼎鼎的“马奇诺防线”。但如我们所知,这个原以为牢不可破的防御线最终并没有让法国把德军阻击在外,相反地,由于对马奇诺防线的盲目自信和过度依赖,导致法国备战懈怠,二战中,德军绕道比利时,翻越了天险阿登高地,从防线后方直接兵临巴黎城下。

军事家们认为,马奇诺防线失效的原因在于“完全防御”军事思想的失效。和一战不同,二战讲求的是机动灵活作战,但法国并没有借马其诺防线主动组织进攻,而是选择了严防死守,当德军从缺口直驱巴黎的时候,防线的士兵还在原地等着人家从正面进攻,而城内的人们甚至还沉迷在灯红酒绿之中。

其实,像“马奇诺防线”这样,外面看似厚墙高筑,里面实则十分松散的状态,就很像计算机概念中的“防火墙”。过去,大多数企业都信奉“内网式安全”,认为只要把数据放在“墙内”就能安全无虞——但是很显然,这样的安全策略就像是二战中失效的“马奇诺防线”一样已经过时。

“马其诺防线”失效,如何做好容器云安全?

容器安全新挑战,“内网式安全感”不复存在

和二战的情况类似,如今企业所处的外部经济环境震荡多变,要求大家在业务发展过程中必须灵活且高效应对,这就是为什么近几年来,容器应用开始大行其道的重要原因。由于能够满足企业快速响应、敏捷开发的需求,容器已经成为企业应用交付的主流形式。

但是,相较于传统应用而言,容器天然在隔离和安全性等方面存在着“缺陷”,这些“缺陷”随着容器一起跑在所谓的企业内网中,如果不能很好地识别并修复,分分钟就会成为“马奇诺防线”上的缺口,给企业带来不可估量的损失。

面对这种情况,靠砌“一道墙”就拥有的安全感就荡然无存,换句话说,企业必须重新审视并调整自己的安全策略。

首先,来看看容器给企业带来了哪些方面的安全挑战。

我们知道,目前Kubernetes已经成为应用创新的标准平台,而DevOps也已经成为支持云原生应用开发和运维的主流实践方法论。在这样的开发理念之下,企业应用往往需要同步在本地数据中心和云上部署和交互,这意味着,物理安全边界将会消失,安全隐患变得无处不在,传统安全策略中通过构建一个“安全边界”,把非信任域的东西阻挡在“墙”外的做法自然就不合时宜。

所以,企业想要推行和使用容器,有几个问题必须要考虑:

第一,软件供应链的安全性。由于容器应用中有很多代码、组件来自于开源社区或者第三方外包开发,如果不能对其中的高危漏洞有效识别,或者被别有用心者利用,就等于把有问题的代码提供给了使用者,使整个链条上的安全体系“崩塌”;

第二,基础设施的安全性。如今,很多企业仍然倾向于使用“DIY”的Kubernetes平台,再配上一些安全扫描的工具,这样的基础设施实际上很难满足和评估企业在安全合规方面的要求,会使得整个平台或业务暴露在风险之下。另一方面,Kubernetes的安全责任相对分散,全责不明确也会造成管理的松散,不利于安全策略落实;

第三,应用负载的安全性。容器改变了传统的应用部署模式,不仅应用生命周期被大幅缩短,部署密度也越来越高,传统安全策略很难适应需求。另外,在对应用(尤其是第三方应用)进行容器打包之后,它的行为是否正常、能否达到安全标准,用过去的安全系统也很难进行全面监控,如有问题就会直接对业务产生影响。

换言之,企业要改变的不仅仅是某一个安全技术手段,而是整个安全策略。

安全意识“前移”,从被动防御到主动防护

如果吸取法国“马奇诺防线”安于防守的教训,这意味着,企业首先要做的就是化“被动”为“主动”,优先占据主动权,而不是等着攻击发生后才做出反应。放在容器安全这件事上,也就是说,企业必须把安全意识和手段“前移”。

有相关调查显示,从应用研发、构建、部署到运行的不同阶段,期间产生的安全成本是逐级递增的。举例来说:如果在研发阶段发现漏洞,只要由开发人员直接修复即可,成本低而且效率高;如果等到发布后才检测出漏洞,那就需要安全人员给出方案,与研发人员沟通,再由测试人员验证,不仅相对成本高,而且还存在一定的线上风险;而如果等到应用运行了一段时间后漏洞才被发现,那就不只是补救的问题了,一方面企业需要付出额外的金钱、沟通成本和修复时间,另一方面还需要运维、发布、业务等大量人员的介入,给企业带来的风险和成本压力是数十上百倍的。

正因如此,把安全理念贯穿到DevOps 全流程中,“糅合开发、安全及运营理念以创建解决方案的全新方法”,越来越成为业界共识——这就是DevSecOps,它的基础思想,即是“开发安全左移(SHIFTLEFT)”。

可以这么理解,所谓“左移”实际上就是把安全意识从运行阶段,前置到容器构建和CI/CD阶段,从而避免造成运行后不可挽回的损失以及高昂的补救成本。

举个例子,比如在过去的应用开发过程中,一般是由编程人员写好代码放到源代码库,然后通过CI工具把代码打包成镜像,同时调用静态扫描工具进行安全扫描,确认无误后通过CD工具推向测试云,最后再交付到生产云进行上线。可以看到,这整个过程依赖的实际上还是静态扫描。但是,如今很多网络恶意行为都是动态的,静态扫描存在明显短板。而解决办法就是,在已有的CI/CD流水线中,增加一个安全合规测试云环节——也就是说,在完成功能测试之后,先部署到安全合规的测试云中进行动态和静态的安全合规测试,最后再推向生产云运行。

尤其是针对第三方外包厂家提供的应用,这样的思路尤为受用,因为越来越多的厂家都在用容器方式打包应用,但这些应用的开发流程对于企业来说就是一个“黑盒子”,如果还采用传统的镜像文件静态扫描,那就很难保障容器平台安全。

但是,换个角度再来看这个问题。我们知道,大多数企业选择使用开源技术或者容器应用,都是为了避免“重复造车”,加快敏捷开发,如果为此令企业处处担心安全漏洞,要求企业自己能够配备非常复杂的安全监管机制,这并不现实。对于企业而言,需要的是开箱即用的安全策略,并且,希望能够为实际运行的容器环境自定义多因素策略。

通过可视性和一致性,为开放混合环境下的安全运营护航

显然,作为企业级Kubernetes解决方案的“核心玩家”,红帽对这个问题的考虑是具有前瞻性的。在OpenShift上,红帽为容器和云原生应用提供了从构建、部署到运行的持续安全性,并且,能够从容器云平台自身以及多集群管理等多个方面,满足企业多维度的安全需求。

为了不错漏任何一块“拼图”,红帽还在今年年初收购了Kubernetes原生安全领域服务商StackRox,通过将其能力输入到OpenShift,实现了优势互补,并据此打造了红帽容器安全管理平台RHACS(Red Hat Advanced Cluster Security)。通过这一平台,红帽能够帮助企业做到把安全设计前移到容器构建和CI/CD阶段,从而为整个IT堆栈以及整个生命周期实现更高的安全性提供统一的解决方案。

具体来说,RHACS可以在以下几个场景保障容器应用的安全使用:首先,是漏洞管理,通过对漏洞的识别、分类、报告,确定优先级并进行及时修复,保护系统免遭潜在镜像和运行容器中的已知漏洞威胁;其二,是配置管理,确保应用部署和配置的过程符合最佳安全实践;其三,是风险分析,也就是通过对某个对象的综合安全指标分析,确认最严重的问题进行优先处理;其四,网络细粒度安全管理,通过网络监控实现应用的网络隔离和访问控制策略,实时监测应用的异常网络行为;其五,在合规方面,RHACS可以帮助企业满足监管和企业自身安全要求,轻松生成报表并按照要求进行审计和整改;其六,实时对运行环境中的威胁进行检测,并根据风险级别高低,提供给相关人员进行主动及时响应。

值得一提的是,这一系列安全管理操作都可以通过可视化的方式实现。也就是说,相关人员都能够通过平台直观地看到系统中有多少高危漏洞、合规要求是否满足、哪些位置存在高风险,以及应用部署后对安全合规的影响等等。如此一来,就能大大减少实施安全性所需的时间和精力,简化安全性分析、调查和补救工作。

当然,这些能力并不只局限于红帽的OpenShift,在收购之后,StackRox将继续支持多个Kubernetes平台,包括Amazon Elastic Kubernetes Service(EKS)、Microsoft Azure Kubernetes Service(AKS)以及Google Kubernetes Engine(GKE)等等。这意味着,企业用户将能够真正地在开放的混合云环境中,构建、部署、运行各种应用,并且享用到更高级别、更全方位的安全保障。

总而言之,“高筑城墙以御外敌”的时代已经过去,未来,企业的应用将变得无处不在,安全隐患也随之无处不在。于企业而言,必须转变开发、运营和安全策略,通全局、求主动;而于技术服务商而言,能否成就企业触及这一目标,实现跨环境的开放安全运营,将成为竞争力所在。

未经允许不得转载:VPS服务器 » “马其诺防线”失效,如何做好容器云安全?

分享到: 生成海报