第一次世界大战以后，为了避免二战德军突击，法国的花重金用了十几年時间在德法边境线修建了一座绵延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)这些。这代表着，公司客户将可以真实地在开启的云计算平台自然环境中，搭建、布署、运作各种各样运用，而且享受到更皮内瘤、更全面的安全防范措施。
总得来说，“高筑城门以御外族”的时期早已以往，将来，公司的运用将越来越无所不在，安全风险也随着无所不在。于公司来讲，务必变化开发设计、经营和安全设置，通全局性、求积极;而于技术性服务提供商来讲，能不能造就公司碰触这一总体目标，完成跨自然环境的对外开放安全运营，将变成竞争能力所属。