第一次世界大战后，为了防止德军突袭，法国花了十几年的时间，在德法边境修建了长达390公里的防御工事，大炮，战壕，堡垒，甚至厨房，医院和工厂，深深的战壕和高高的基地四通八达mdash这就是著名的马奇诺线可是，我们知道，这条原本认为牢不可破的防线并没有让法国将德军拒之门外相反，由于盲目自信，过度依赖马奇诺防线，法国对战争的准备有所松懈二战中，德军绕过比利时，越过天然屏障阿登高地，从防线后直接抵达巴黎城下

军事家认为马奇诺防线的失败在于完全防御军事思想的失败与第一次世界大战不同，第二次世界大战强调灵活作战，但法国并没有利用马奇诺防线主动组织进攻，而是选择自卫当德军从缺口直逼巴黎时，排队的士兵还在等着别人从正面进攻，城里的人甚至沉迷于这场盛宴

实际上，像马奇诺线这样，外面看起来又粗又高，但里面实际上很宽松，就像计算机概念中的防火墙过去，大多数企业相信内部网安全只要数据在墙内你可以安全了mdash但显然，这样的安全战略就像二战中失败的现状马奇诺线已经过时了

集装箱安全的新挑战。内部网安全不再存在

类似于二战时期的情况，企业现在所处的外部经济环境波动较大，这就要求大家在业务发展过程中灵活高效地做出反应，这也是最近几年来容器应用流行的重要原因容器能够满足快速响应和敏捷开发的需求，已经成为企业应用交付的主流形式

可是，与传统应用相比，容器在隔离性和安全性方面自然有不足缺陷，这些缺陷当容器在所谓的内部网中一起运行时，如果它们不能被很好地识别和修复，分钟将变成马奇诺线上的差距，给企业带来不可估量的损失

面对这种情况，靠建一堵墙没有安全感，换句话说，企业必须重新审视和调整自己的安全政策

首先，我们来看看容器给企业带来的安全挑战。

我们知道，Kubernetes已经成为应用创新的标准平台，DevOps已经成为支持云原生应用开发和运维的主流实践方法论在这样的发展理念下，企业应用往往需要在本地数据中心和云端同步部署和交互，这意味着物理安全边界将消失，安全风险将变得无处不在在传统的安全策略中安全边界在中阻止不受信任域中的东西，墙外面的做法自然是不合适的

因此，企业想要推广和使用容器，有几个问题必须考虑:

第一，软件供应链的安全性。由于容器应用中的很多代码和组件都来自开源社区或第三方外包开发，如果高风险漏洞不能被别有用心的人有效识别或利用，就相当于把有问题的代码提供给用户，使安全体系处于全链条折叠，

第二，基础设施的安全性现在很多企业还是倾向于用DIYKubernetes平台，加上一些安全扫描工具，实际上很难满足和评估企业在安全合规性方面的要求，这将使整个平台或业务面临风险

第三，应用负载的安全性容器改变了传统的应用部署模式，不仅应用生命周期大大缩短，而且部署密度越来越高，传统的安全策略难以满足需求此外，应用程序封装在容器中后，其行为是否正常，能否达到安全标准，用以往的安全系统很难全面监控，如果出现问题，将直接影响业务

换句话说，企业需要改变的不仅仅是某种安全技术，而是整个安全策略。

安全意识向前看从被动防御到主动防护

如果你向法国学习，马奇诺线安于防御的教训，这意味着企业首先要做的是改变现状，被动是活动，优先主动出击，而不是等待攻击后才做出反应关于集装箱安全问题，也就是说，企业必须把安全意识和手段放在第一位，向前看

据相关调查，在应用开发，构建，部署和运行的不同阶段产生的安全成本正在逐步增加比如R&D阶段发现漏洞，只能由开发商直接修复，成本低，效率高如果只是在发布后才检测到漏洞，则需要安全人员给出方案，与R&D人员沟通，再由测试人员进行验证，不仅成本相对较高，而且存在一定的在线风险如果应用程序在运行一段时间后才被发现，这不仅仅是一个补救问题一方面，企业需要支付额外的资金，通讯费用和维修时间，另一方面也需要运维，发布，业务等大量人员的介入，给企业带来了数百倍的风险和成本压力

为此，将安全理念融入到DevOps，的全过程，结合开发，安全和运营理念创建解决方案的新途径。已日益成为业界的共识mdashmdash这是DevSecOps，它的基本思想是开发安全的shift left)rd quo，

可以理解，所谓的ldq。

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

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

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

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

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

显然，作为企业级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)等等这意味着，企业用户将能够真正地在开放的混合云环境中，构建，部署，运行各种应用，并且享用到更高级别，更全方位的安全保障

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