容器和微服务安全难以保障。机器学习可能是解决问题的办法。

利用云原生 (Cloud-Native) 架构，公司企业能以较低的成本减少应用开发时间，提升敏捷性。尽管灵活性和可移植性驱动了云原生架构的广泛采纳，但也带来了新的挑战：怎样规模化管理安全及性能?

容器和微服务安全难以保障主要是以下几个原因：

边界分散：一旦传统边界被突破，恶意软件或勒索软件常会在数据中心和云环境中四处游走，难以检测。
DevOps 思维模式下，开发人员不断构建、推送和拉取各种镜像，直面无数暴露，比如操作系统漏洞、软件包漏洞、错误配置、秘密信息暴露……
容器生存周期短，内容不透明，很容易在用过后遗留下大量数据，极难看清容器化环境的风险及安全态势。面对几百万台转瞬即逝的容器，想要梳理其上成千上万服务中的互联数据，以便及时了解具体安全状况或违规情况，好比大海捞针一样。
随着开发速度的加快，安全被挤到了开发周期末端。开发人员不再从早期开始即植入安全，而宁可在末期补上，最终也就增加了基础设施中潜在暴露的概率。

预算紧张，加上不断创新的压力，让机器学习和人工智能 IT 运营 (AIOps) 逐渐融入安全提供商路线图中，因为这是减轻现代架构中安全人员负担最为现实的解决方案了，至少目前看来是。

容器按需使用，上下线转换频繁，安全人员没有犯错的余地。攻击者却只需成功一次即可收获满满，而不断发展变化的云原生环境中，入侵来得更加容易，因为安全难以跟进。也就是说，运行时环境如今可因内部人黑客行为、策略错误配置、零日威胁和外部攻击而千疮百孔。

这种动态环境中，人手短缺的安全团队是无法人工大规模抵御这些威胁的。安全配置可能需要几个小时乃至数天才能调整好，如此充裕的时间完全够黑客充分利用该机会窗口了。

过去几十年来，我们已经见证了机器学习算法和技术的长足进步。如今，即使是没有统计学背景的人，也可以获取机器学习模型并将之应用来解决各种问题。

容器很适合用监督学习模型，原因如下：

因为容器基本为模块化任务设计，构造简单，比较容易定义其内部行为基线，区分正常与不正常的行为。虚拟机则不同，动辄几百个程序和进程运行，比容器难判断得多。

2. 容器是声明性的

不用挨个儿查配置，DevOps 团队查看守护进程和容器环境就可以了解特定容器运行时可以做些什么了。

这种不变性就是防止运行时修改的保护围栏。比如说，如果某容器突然开始运行 netcat，那就说明可能有人入侵了。

鉴于以上特性，机器学习模型可以从行为中学习，在创建运行时配置时更加准确，精准评估哪些行为应被允许而哪些应加以禁止。通过让机器来定义准确的配置，自动发现潜在威胁指标，检测的效率和精度都能得到大幅提升。同时，这还能缓解安全运营中心团队成员的过劳情况，让他们不用为不同容器环境挨个儿手动创建特定规则，从而将精力放在响应和修复上，而不是单调机械地人工检测上。

云原生时代，安全必须跟上不断变化的技术态势。团队应配备云原生安全工具以摒除噪音与干扰，找出所需的准确情报。若不用机器学习，安全团队会被大量无关紧要的琐碎细节绊住，错失真正应该关注的东西。

原文来自：

本文地址：//lrxjmw.cn/machine-learning-anquan.html编辑：王华超，审核员：逄增宝

Linux大全：

Linux系统大全：

红帽认证RHCE考试心得：