第一次世界大战后，为了防止德国人的袭击，法国花了十多年时间在德法边境修建了长达390公里的防御工事，配备了大炮、战壕、炮台，甚至还有厨房、医院、工厂，深沟高垒，四通八达——这就是著名的“马其诺防线”。但正如我们所知，这条本应牢不可破的防线最终并没有让法国挡住德军。相反，由于盲目自信和过度依赖马奇诺防线，法国在备战方面松懈了。二战中，德军绕过了比利时，越过危险的阿登高地，直接从防线后逼近巴黎城。军事家认为，马其诺防线之所以失败，在于“全面防御”军事思想的失败。与第一次世界大战不同，第二次世界大战侧重于机动和灵活的战斗。不过法国并没有主动通过马其诺防线组织进攻，而是选择了严防死守。当德军从缺口长驱直入巴黎时，防线上的士兵还在原地等候。人们从正面进攻，城中的人更是大吃大喝。其实就像“马其诺防线”一样，外面看起来是一堵厚厚的墙，其实里面很松，很像电脑概念中的“防火墙”。过去，大多数企业信奉“内网式安全”，认为只要把数据放在“墙内”就万无一失——但显然，这样的安全策略就像“马奇诺”在第二次世界大战中失败了。“防线”也落伍了。容器安全的新挑战，“内网式安全”不复存在，类似于二战时的情形。如今，企业生存的外部经济环境多变多变，要求大家在业务发展的过程中能够灵活高效的做出响应，这也是为什么最近几年，容器应用成为其流行的一个重要原因。因为它可以满足企业快速响应和敏捷开发的需求，容器已经成为企业应用交付的主流形式，但是相对于传统应用，容器在隔离性和安全性上天然存在“缺陷”，这些“缺陷”伴随着容器在所谓的企业内网中运行，每时每刻将成为“马奇诺防线”的缺口，给企业带来不可估量的损失。面对这种情况，安全感可以通过建造“墙”获得的安全消失了。也就是说，企业必须重新审视和调整自己的安全策略。首先我们来看看容器给企业带来的安全挑战。我们知道，Kubernetes已经成为应用创新的标准平台，DevOps已经成为支撑云原生应用开发运维的主流实践方法论。在这样的发展理念下，企业应用往往需要在本地数据中心和云端同时部署和交互，这意味着物理安全边界将消失，安全风险将无处不在。传统的安全策略构建“安全边界”，把非信任域的东西挡在“墙”之外的做法自然不合时宜。因此，企业要想推广使用容器，有几个问题是必须要考虑的：第一，软件供应链的安全。由于容器应用中的很多代码和组件来自于开源社区或第三方外包开发，如果不能有效识别高危漏洞，或者被别有用心的人利用，就相当于向用户提供了有问题的代码，使得整个链上的安全体系“崩溃”；第二，基础设施的安全。现在很多企业还是倾向于使用“DIY”的Kubernetes平台，再加上一些安全扫描工具，这样的基础设施实际上很难满足和评估企业在安全合规性方面的要求，这会让整个平台或者业务暴露于风险之中。另一方面，Kubernetes的安全职责相对分散，职责不明确也会导致管理松散，不利于安全策略的落实；第三，应用加载的安全性。容器改变了传统的应用程序部署模型。不仅应用生命周期大大缩短，部署密度也越来越高。传统安全策略难以适应需求。另外，应用（尤其是第三方应用）在容器封装后，其行为是否正常，是否符合安全标准，很难用以往的安全体系进行全面的监控。如果出现问题，将直接影响业务。影响。也就是说，企业需要改变的不仅仅是某种安全技术手段，而是整个安全策略。安全意识“前行”，从被动防御到主动防护。如果我们吸取法国“马奇诺防线”的教训，知足常乐，这意味着企业首先要做的是变“被动”为“主动”，优先采取主动，而不是坐以待毙。攻击发生在反应之前。在容器安全这件事情上，也就是说，企业要将安全意识和方法“前移”。据相关调查显示，从应用开发、建设、部署到运营的不同阶段，期间产生的安全成本逐年递增。例如：在研发阶段发现漏洞，可以由开发者直接修复，成本低，效率高；如果漏洞发布后被检测到，需要安全人员出方案，与研发人员沟通，然后由测试人员进行验证，不仅成本相对较高，而且存在一定的上线风险；如果直到应用程序运行一段时间后才发现漏洞，则不仅仅是修复问题。一方面，企业需要付出额外的资金、通信成本和修复时间，另一方面，也需要运维、发布、业务等大量人员的介入，这就带来了给企业带来数十倍至数百倍的风险和成本压力。正因如此，将安全的概念融入到DevOps的全过程中，“一种结合开发、安全和运营理念打造解决方案的新方法”——这就是DevSecOps，它已经成为业界越来越多的共识。基本思想是“开发安全左移（SHIFTLEFT）”。可以理解，所谓“左移”，其实就是将安全意识从运维阶段提前到容器构建、CI/CD阶段，避免运维后无法挽回的损失和高昂的补救成本。例如，在以往的应用开发过程中，通常是程序员编写代码并将其放入源代码库中，然后使用CI工具将代码打包成镜像，并调用静态扫描工具进行安全扫描。确认无误后，通过CD工具推送到测试云，最后交付到生产云上线。可见整个过程依赖于静态扫描。但是现在很多网络恶意行为都是动态的，静态扫描有明显的缺点。解决方案是在现有的CI/CDpipeline上增加一个安全合规测试云链路——即在完成功能测试后，先部署到一个安全合规测试云上进行动态和静态测试。安全合规测试，最终推送到生产云运行。尤其是对于第三方外包厂商提供的应用，这个思路特别有用，因为越来越多的厂商都在使用容器来封装应用，但是这些应用的开发过程对于企业来说是一个“黑匣子”。如果仍然使用传统的镜像文件静态扫描，很难保证容器平台的安全。不过，让我们换个角度来看这个问题。我们知道，大多数企业选择使用开源技术或容器应用，是为了避免“重复造车”，加快敏捷开发。如果这让企业担心处处存在安全漏洞，则需要企业配备非常复杂的安全监管机制。这是不现实的。对于企业来说，需要的是开箱即??用的安全策略，希望能够针对实际运行的容器环境定制多因素策略。通过可见性和一致性为开放混合环境中的安全运营保驾护航显然，作为企业级Kubernetes解决方案的“核心玩家”，红帽在这个问题上的考虑是具有前瞻性的。在OpenShift上，红帽为容器和云原生应用提供从构建、部署到运行的持续安全保障，能够满足企业在容器云平台自身和多集群管理方面的多维度安全需求。为了不错过任何一块“拼图”，红帽还在今年年初收购了Kubernetes原生安全领域的服务商StackRox。通过将自身能力输入到OpenShift，实现优势互补，据此打造了红帽容器安全管理平台RHACS。（红帽高级集群安全）。通过该平台，红帽可以帮助企业将安全设计提前到容器构建和CI/CD阶段，从而为整个IT堆栈和全生命周期提供统一的解决方案，实现更高的安全性。具体来说，RHACS可以在以下场景下保障容器应用的安全使用：第一，漏洞管理，通过对漏洞的识别、分类、报告、优先级排序和及时修复，保护系统免受潜在镜像和运行中已知漏洞的威胁在容器中；二是配置管理，确保应用程序部署和配置过程符合最佳安全实践；三是风险分析，确定最严重的问题优先处理；第四，网络细粒度安全管理，通过网络监控实现应用网络隔离和访问控制策略，实时监控应用的异常网络行为。第五，在合规性方面，RHACS可以帮助企业满足监管和企业自身的安全需求，轻松生成报告并按要求进行审计和整改；六是实时发现运行环境中的威胁，根据风险程度，提供相关人员主动及时应对。值得一提的是，这一系列的安全管理操作都可以通过可视化的方式实现。也就是说，相关人员可以通过平台直观地看到系统中存在多少高危漏洞，是否满足合规要求，高风险存在于何处，以及应用部署对安全合规的影响。这大大减少了实施安全所需的时间和精力，并简化了安全分析、调查和补救。当然，这些能力并不局限于红帽的OpenShift。收购后，StackRox将继续支持多个Kubernetes平台，包括AmazonElasticKubernetesService(EKS)、MicrosoftAzureKubernetesService(AKS)和GoogleKubernetesEngine(GKE)。等待。这意味着企业用户将能够真正在开放的混合云环境中构建、部署和运行各种应用，享受更高层次、更全面的安全保障。总而言之，“筑高墙御外敌”的时代已经过去了。未来，企业应用无处不在，安全隐患也无处不在。对企业而言，需要转变发展、运营、安全策略，顾全大局，谋求主动；对于技术服务商而言，能否实现这一目标，实现跨环境的开放安全运营，将成为他们的竞争力。
