mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-29 21:41:00 +08:00
67 lines
10 KiB
Markdown
67 lines
10 KiB
Markdown
容器和微服务是如何改变了安全性
|
||
============================================================
|
||
|
||
> 云原生程序和基础架构需要完全不同的安全方式。牢记这些最佳实践
|
||
|
||
|
||
|
||
>thinkstock
|
||
|
||
如今，大大小小的组织正在探索云原生技术的采用。“<ruby>云原生<rt>Cloud-native</rt></ruby>”是指将软件打包到被称为容器的标准化单元中的方法，这些单元组织成微服务，它们必须对接以形成程序，并确保正在运行的应用程序完全自动化以实现更高的速度、灵活性和可伸缩性。
|
||
|
||
由于这种方法从根本上改变了软件的构建、部署和运行方式，它也从根本上改变了软件需要保护的方式。云原生程序和基础架构为安全专业人员带来了若干新的挑战，他们需要建立新的安全计划来支持其组织对云原生技术的使用。
|
||
|
||
让我们来看看这些挑战，然后我们将讨论安全团队应该采取的哪些最佳实践来解决这些挑战。首先挑战是：
|
||
|
||
* **传统的安全基础设施缺乏容器可视性。** 大多数现有的基于主机和网络的安全工具不具备监视或捕获容器活动的能力。这些工具是为了保护单个操作系统或主机之间的流量，而不是其上运行的应用程序，从而导致容器事件、系统交互和容器间流量的可视性缺乏。
|
||
* **攻击面可以快速更改。**云原生应用程序由许多较小的组件组成，这些组件称为微服务，它们是高度分布式的，每个都应该分别进行审计和保护。因为这些应用程序的设计是通过编排系统进行配置和调整的，所以其攻击面也在不断变化，而且比传统的独石应用程序要快得多。
|
||
* **分布式数据流需要持续监控。**容器和微服务被设计为轻量级的，并且以可编程方式与对方或外部云服务进行互连。这会在整个环境中产生大量的快速移动数据，需要进行持续监控，以便应对攻击和危害指标以及未经授权的数据访问或渗透。
|
||
* **检测、预防和响应必须自动化。** 容器生成的事件的速度和容量压倒了当前的安全操作流程。容器的短暂寿命也成为难以捕获、分析和确定事故的根本原因。有效的威胁保护意味着自动化数据收集、过滤、关联和分析，以便能够对新事件作出足够快速的反应。
|
||
|
||
面对这些新的挑战，安全专业人员将需要建立新的安全计划以支持其组织对云原生技术的使用。自然地，你的安全计划应该解决云原生程序的整个生命周期的问题，这些应用程序可以分为两个不同的阶段：构建和部署阶段以及运行时阶段。每个阶段都有不同的安全考虑因素，必须全部加以解决才能形成一个全面的安全计划。
|
||
|
||
### 确保容器的构建和部署
|
||
|
||
构建和部署阶段的安全性侧重于将控制应用于开发人员工作流程和持续集成和部署管道，以降低容器启动后可能出现的安全问题的风险。这些控制可以包含以下准则和最佳实践：
|
||
|
||
* **保持镜像尽可能小。**容器镜像是一个轻量级的可执行文件，用于打包应用程序代码及其依赖项。将每个镜像限制为软件运行所必需的内容, 从而最小化从镜像启动的每个容器的攻击面。从最小的操作系统基础镜像（如 Alpine Linux）开始，可以减少镜像大小，并使镜像更易于管理。
|
||
* **扫描镜像的已知问题。**当镜像构建后，应该检查已知的漏洞披露。可以扫描构成镜像的每个文件系统层，并将结果与定期更新的常见漏洞披露数据库（CVE）进行比较。然后开发和安全团队可以在镜像被用来启动容器之前解决发现的漏洞。
|
||
* **数字签名的镜像。**一旦建立镜像，应在部署之前验证它们的完整性。某些镜像格式使用被称为摘要的唯一标识符，可用于检测镜像内容何时发生变化。使用私钥签名镜像提供了加密的保证，以确保每个用于启动容器的镜像都是由可信方创建的。
|
||
* **强化并限制对主机操作系统的访问。**由于在主机上运行的容器共享相同的操作系统，因此必须确保它们以适当限制的功能集启动。这可以通过使用内核安全功能和 Seccomp、AppArmor 和 SELinux 等模块来实现。
|
||
* **指定应用程序级别的分割策略。**微服务之间的网络流量可以被分割，以限制它们彼此之间的连接。但是，这需要根据应用级属性（如标签和选择器）进行配置，从而消除了处理传统网络详细信息（如 IP 地址）的复杂性。分割带来的挑战是，必须事先定义策略来限制通信，而不会影响容器在环境内部和环境之间进行通信的能力，这是正常活动的一部分。
|
||
* **保护容器所使用的秘密信息。**微服务彼此相互之间频繁交换敏感数据，如密码、令牌和密钥，这称之为<ruby>秘密信息<rt>secret</rt></ruby>。如果将这些秘密信息存储在镜像或环境变量中，则可能会意外暴露这些。因此，像 Docker 和 Kubernetes 这样的多个编排平台都集成了秘密信息管理，确保只有在需要的时候才将秘密信息分发给使用它们的容器。
|
||
|
||
来自诸如 Docker、Red Hat 和 CoreOS 等公司的几个领先的容器平台和工具提供了部分或全部这些功能。开始使用这些方法之一是在构建和部署阶段确保强大安全性的最简单方法。
|
||
|
||
但是，构建和部署阶段控制仍然不足以确保全面的安全计划。提前解决容器开始运行之前的所有安全事件是不可能的，原因如下：首先，漏洞永远不会被完全消除，新的漏洞会一直出现。其次，声明式的容器元数据和网络分段策略不能完全预见高度分布式环境中的所有合法应用程序活动。第三，运行时控制使用起来很复杂，而且往往配置错误，就会使应用程序容易受到威胁。
|
||
|
||
### 在运行时保护容器
|
||
|
||
运行时阶段的安全性包括所有功能（可见性、检测、响应和预防），这些功能是发现和阻止容器运行后发生的攻击和策略违规所必需的。安全团队需要对安全事件的根源进行分类、调查和确定，以便对其进行全面补救。以下是成功的运行时阶段安全性的关键方面：
|
||
|
||
* **检测整个环境以得到持续可见性。**能够检测攻击和违规行为始于能够实时捕获正在运行的容器中的所有活动，以提供可操作的“真相源”。捕获不同类型的容器相关数据有各种检测框架。选择一个能够处理容器的容量和速度的方案至关重要。
|
||
* **关联分布式威胁指标。** 容器设计为基于资源可用性以跨计算基础架构而分布。由于应用程序可能由数百或数千个容器组成，因此危害指标可能分布在大量主机上，使得难以确定那些与主动威胁相关的相关指标。需要大规模，快速的相关性来确定哪些指标构成特定攻击的基础。
|
||
* **分析容器和微服务行为。**微服务和容器使得应用程序可以分解为执行特定功能的最小组件，并被设计为不可变的。这使得比传统的应用环境更容易理解预期行为的正常模式。偏离这些行为基准可能反映恶意行为，可用于更准确地检测威胁。
|
||
* **通过机器学习增强威胁检测。**容器环境中生成的数据量和速度超过了传统的检测技术。自动化和机器学习可以实现更有效的行为建模、模式识别和分类，从而以更高的保真度和更少的误报来检测威胁。注意使用机器学习的解决方案只是为了生成静态白名单，用于警报异常，这可能会导致严重的警报噪音和疲劳。
|
||
* **拦截并阻止未经授权的容器引擎命令。**发送到容器引擎（例如 Docker）的命令用于创建、启动和终止容器以及在正在运行的容器中运行命令。这些命令可以反映危害容器的意图，这意味着可以禁止任何未经授权的命令。
|
||
* **自动响应和取证。**容器的短暂寿命意味着它们往往只能提供很少的事件信息，以用于事件响应和取证。此外，云原生架构通常将基础设施视为不可变的，自动将受影响的系统替换为新系统，这意味着在调查时的容器可能会消失。自动化可以确保足够快地捕获、分析和升级信息，以减轻攻击和违规的影响。
|
||
|
||
基于容器技术和微服务架构的云原生软件正在迅速实现应用程序和基础架构的现代化。这种模式转变迫使安全专业人员重新考虑有效保护其组织所需的计划。随着容器的构建、部署和运行，云原生软件的全面安全计划将解决整个应用程序生命周期问题。通过使用上述指导方针实施计划，组织可以为容器基础设施以及运行在上面的应用程序和服务构建安全的基础。
|
||
|
||
_WeLien Dang 是 StackRox 的产品副总裁，StackRox 是一家为容器提供自适应威胁保护的安全公司。此前，他曾担任 CoreOS 产品负责人，并在亚马逊、Splunk 和 Bracket Computing 担任安全和云基础架构的高级产品管理职位。_
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: https://www.infoworld.com/article/3233139/cloud-computing/how-cloud-native-applications-change-security.html
|
||
|
||
作者：[Wei Lien Dang][a]
|
||
译者：[geekpi](https://github.com/geekpi)
|
||
校对：[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://www.infoworld.com/blog/new-tech-forum/
|
||
[1]:https://www.stackrox.com/
|
||
[2]:https://www.infoworld.com/article/3204171/what-is-docker-linux-containers-explained.html#tk.ifw-infsb
|
||
[3]:https://www.infoworld.com/resources/16373/application-virtualization/the-beginners-guide-to-docker.html#tk.ifw-infsb
|