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

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

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