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

2022-10-06    分类: 网站建设

第一次世界大战之后,为了防止德军突袭,法国花重金用了十几年时间在德法边境建造了一座延绵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)等等。这意味着,企业用户将能够真正地在开放的混合云环境中,构建、部署、运行各种应用,并且享用到更高级别、更全方位的安全保障。

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

新闻名称:“马其诺防线”失效,如何做好容器云安全?
文章出自:https://www.cdcxhl.com/news15/202365.html

成都网站建设公司_创新互联,为您提供做网站移动网站建设网站排名响应式网站建站公司网站收录

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联

成都网站建设公司