mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-01 21:50:13 +08:00
geekpi
GitHub
commit
782b2dff24
@ -1,84 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
How containers and microservices change security
|
||||
============================================================
|
||||
|
||||
### Cloud-native applications and infrastructure require a radically different approach to security. Keep these best practices in mind
|
||||
|
||||
|
||||
>thinkstock
|
||||
|
||||
|
||||
|
||||
Today organizations large and small are exploring the adoption of cloud-native software technologies. “Cloud-native” refers to an approach that packages software within standardized units called containers, arranges those units into microservices that interface with each other to form applications, and ensures that running applications are fully automated for greater speed, agility, and scalability.
|
||||
|
||||
Because this approach fundamentally changes how software is built, deployed, and run, it also fundamentally changes how software needs to be protected. Cloud-native applications and infrastructure create several new challenges for security professionals, who will need to establish new security programs that support their organization’s use of cloud-native technologies.
|
||||
|
||||
Let’s take a look at those challenges, and then we’ll discuss a number of best practices security teams should adopt to address them. First the challenges:
|
||||
|
||||
* **Traditional security infrastructure lacks container visibility. **Most existing host-based and network security tools do not have the ability to monitor or capture container activity. These tools were built to secure single operating systems or the traffic between host machines rather than the applications running above, resulting in a loss of visibility into container events, system interactions, and inter-container traffic.
|
||||
|
||||
* **Attack surfaces can change rapidly.** Cloud-native applications are made up of many smaller components called microservices that are highly distributed, each of which must be individually audited and secured. Because these applications are designed to be provisioned and scaled by orchestration systems, their attack surfaces change constantly—and far faster than traditional monolithic applications.
|
||||
|
||||
* **Distributed data flows require continuous monitoring.**Containers and microservices are designed to be lightweight and to interconnect programmatically with each other or external cloud services. This generates large volumes of fast-moving data across the environment to be continuously monitored for indicators of attack and compromise as well as unauthorized data access or exfiltration.
|
||||
|
||||
* **Detection, prevention, and response must be automated. **The speed and volume of events generated by containers overwhelms current security operations workflows. The ephemeral life spans of containers also make it difficult to capture, analyze, and determine the root cause of incidents. Effective threat protection means automating data collection, filtering, correlation, and analysis to be able to react fast enough to new incidents.
|
||||
|
||||
Faced with these new challenges, security professionals will need to establish new security programs that support their organization’s use of cloud-native technologies. Naturally, your security program should address the entire lifecycle of cloud-native applications, which can be split into two distinct phases: the build and deploy phase, and the runtime phase. Each of these phases has a different set of security considerations that must be addressed to form a comprehensive security program.
|
||||
|
||||
|
||||
### Securing container builds and deployment
|
||||
|
||||
Security for the build and deploy phase focuses on applying controls to developer workflows and continuous integration and deployment pipelines to mitigate the risk of security issues that may arise after containers have been launched. These controls can incorporate the following guidelines and best practices:
|
||||
|
||||
* **Keep images as small as possible. **A container image is a lightweight executable that packages application code and its dependencies. Restricting each image to only what is essential for software to run minimizes the attack surface for every container launched from the image. Starting with minimal operating system base images such as Alpine Linux can reduce image sizes and make images easier to manage.
|
||||
|
||||
* **Scan images for known issues. **As images get built, they should be checked for known vulnerabilities and exposures. Each file system layer that makes up an image can be scanned and the results compared to a Common Vulnerabilities and Exposures (CVE) database that is regularly updated. Development and security teams can then address discovered vulnerabilities before the images are used to launch containers.
|
||||
|
||||
* **Digitally sign images. **Once images have been built, their integrity should be verified prior to deployment. Some image formats utilize unique identifiers called digests that can be used to detect when image contents have changed. Signing images with private keys provides cryptographic assurances that each image used to launch containers was created by a trusted party.
|
||||
|
||||
* **Harden and restrict access to the host OS. **Since containers running on a host share the same OS, it is important to ensure that they start with an appropriately restricted set of capabilities. This can be achieved using kernel security features and modules such as Seccomp, AppArmor, and SELinux.
|
||||
|
||||
* **Specify application-level segmentation policies. **Network traffic between microservices can be segmented to limit how they connect to each other. However, this needs to be configured based on application-level attributes such as labels and selectors, abstracting away the complexity of dealing with traditional network details such as IP addresses. The challenge with segmentation is having to define policies upfront that restrict communications without impacting the ability of containers to communicate within and across environments as part of their normal activity.
|
||||
|
||||
* **Protect secrets to be used by containers. **Microservices interfacing with each other frequently exchange sensitive data such as passwords, tokens, and keys, referred to as secrets. These secrets can be accidentally exposed if they are stored in images or environment variables. As a result, several orchestration platforms such as Docker and Kubernetes have integrated secrets management, ensuring that secrets are only distributed to the containers that use them, when they need them.
|
||||
|
||||
Several leading container platforms and tools from companies such as Docker, Red Hat, and CoreOS provide some or all of these capabilities. Getting started with one of these options is the easiest way to ensure robust security during the build and deploy phase.
|
||||
|
||||
However, build and deployment phase controls are still insufficient to ensuring a comprehensive security program. Preempting all security incidents before containers start running is not possible for the following reasons. First, vulnerabilities will never be fully eliminated and new ones are exploited all the time. Second, declarative container metadata and network segmentation policies cannot fully anticipate all legitimate application activity in a highly distributed environment. And third, runtime controls are complex to use and often misconfigured, leaving applications susceptible to threats.
|
||||
|
||||
### Securing containers at runtime
|
||||
|
||||
Runtime phase security encompasses all the functions—visibility, detection, response, and prevention—required to discover and stop attacks and policy violations that occur once containers are running. Security teams need to triage, investigate, and identify the root causes of security incidents in order to fully remediate them. Here are the key aspects of successful runtime phase security:
|
||||
|
||||
|
||||
* **Instrument the entire environment for continuous visibility. **Being able to detect attacks and policy violations starts with being able to capture all activity from running containers in real time to provide an actionable “source of truth.” Various instrumentation frameworks exist to capture different types of container-relevant data. Selecting one that can handle the volume and speed of containers is critical.
|
||||
|
||||
* **Correlate distributed threat indicators. **Containers are designed to be distributed across compute infrastructure based on resource availability. Given that an application may be comprised of hundreds or thousands of containers, indicators of compromise may be spread out across large numbers of hosts, making it harder to pinpoint those that are related as part of an active threat. Large-scale, fast correlation is needed to determine which indicators form the basis for particular attacks.
|
||||
|
||||
* **Analyze container and microservices behavior. **Microservices and containers enable applications to be broken down into minimal components that perform specific functions and are designed to be immutable. This makes it easier to understand normal patterns of expected behavior than in traditional application environments. Deviations from these behavioral baselines may reflect malicious activity and can be used to detect threats with greater accuracy.
|
||||
|
||||
* **Augment threat detection with machine learning.** The volume and speed of data generated in container environments overwhelms conventional detection techniques. Automation and machine learning can enable far more effective behavioral modeling, pattern recognition, and classification to detect threats with increased fidelity and fewer false positives. Beware solutions that use machine learning simply to generate static whitelists used to alert on anomalies, which can result in substantial alert noise and fatigue.
|
||||
|
||||
* **Intercept and block unauthorized container engine commands. **Commands issued to the container engine, e.g., Docker, are used to create, launch, and kill containers as well as run commands inside of running containers. These commands can reflect attempts to compromise containers, meaning it is essential to disallow any unauthorized ones.
|
||||
|
||||
* **Automate actions for response and forensics. **The ephemeral life spans of containers mean that they often leave very little information available for incident response and forensics. Further, cloud-native architectures typically treat infrastructure as immutable, automatically replacing impacted systems with new ones, meaning containers may be gone by the time of investigation. Automation can ensure information is captured, analyzed, and escalated quickly enough to mitigate the impact of attacks and violations.
|
||||
|
||||
Cloud-native software built on container technologies and microservices architectures is rapidly modernizing applications and infrastructure. This paradigm shift forces security professionals to rethink the programs required to effectively protect their organizations. A comprehensive security program for cloud-native software addresses the entire application lifecycle as containers are built, deployed, and run. By implementing a program using the guidelines above, organizations can build a secure foundation for container infrastructures and the applications and services that run on them.
|
||||
|
||||
_Wei Lien Dang is VP of product at StackRox, a security company that provides adaptive threat protection for containers. Previously, he was head of product at CoreOS and held senior product management roles for security and cloud infrastructure at Amazon Web Services, Splunk, and Bracket Computing._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://www.infoworld.com/article/3233139/cloud-computing/how-cloud-native-applications-change-security.html
|
||||
|
||||
作者：[ Wei Lien Dang][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
@ -0,0 +1,81 @@
|
||||
容器和微服务如何改变安全性
|
||||
============================================================
|
||||
|
||||
### 云原生程序和基础架构需要完全不同的安全方式。牢记这些最佳实践
|
||||
|
||||
|
||||
>thinkstock
|
||||
|
||||
|
||||
|
||||
如今，大大小小的组织正在探索云原生技术的采用。“云原生”是指将软件打包到称为容器的标准化单元中的方法，将这些单元安排到互相交互以形成程序的微服务中，并确保正在运行的应用程序完全自动化以实现更高的速度、灵活性和可伸缩性。
|
||||
|
||||
由于这种方法从根本上改变了软件的构建、部署和运行方式，它也从根本上改变了软件需要保护的方式。云原生程序和基础架构为安全专业人员带来了若干新的挑战，他们需要建立新的安全程序来支持其组织使用云原生技术。
|
||||
|
||||
让我们来看看这些挑战，然后我们将讨论安全团队应该采取的哪些最佳实践来解决这些挑战。首先是挑战：
|
||||
|
||||
* **传统的安全基础设施缺乏容器可视性。** 大多数现有的基于主机和网络的安全工具不具备监视或捕获容器活动的能力。这些工具是为了保护单个操作系统或主机之间的流量，而不是上面运行的应用程序，从而导致容器事件、系统交互和容器间流量的可视性受损。
|
||||
|
||||
* **攻击面可以快速更改**云原生应用程序由许多较小的组件组成，这些组件称为微服务，它们是高度分布式的，每个应该分别进行审计和保护。因为这些应用程序的设计是通过编排系统进行配置和调整的，所以它们的攻击面不断变化，而且比传统的单体应用程序要快得多。
|
||||
|
||||
* **分布式数据流需要持续监控。**容器和微服务被设计为轻量级的，并且以编程方式与对方或外部云服务进行互连。这会在环境中产生大量的快速移动数据，以便对攻击和危害指标以及未经授权的数据访问或撤退进行连续监视。
|
||||
|
||||
* **检测、预防和响应必须自动化。** 容器生成的事件的速度和容量压倒了当前的安全操作流程。容器的短暂寿命也使得难以捕获、分析和确定事故的根本原因。有效的威胁保护意味着自动化数据收集、过滤、关联和分析，以便能够对新事件作出足够快速的反应。
|
||||
|
||||
面对这些新的挑战，安全专业人员将需要建立新的安全计划以支持其组织使用云原生技术。自然地，你的安全计划应该解决云原生程序的整个生命周期，这些应用程序可以分为两个不同的阶段：构建和部署阶段以及运行时阶段。每个阶段都有不同的安全考虑因素，必须加以解决才能形成一个全面的安全计划。
|
||||
|
||||
|
||||
### 确保容器的构建和部署
|
||||
|
||||
构建和部署阶段的安全性侧重于将控制应用于开发人员工作流程和持续集成和部署管道，以降低容器启动后可能出现的安全问题的风险。这些控制可以包含以下准则和最佳实践：
|
||||
|
||||
* **保持镜像尽可能小。**容器镜像是一个轻量级的可执行文件，用于打包应用程序代码及其依赖项。将每个镜像限制为软件运行所必需的内容, 从而最小化从镜像启动的每个容器的攻击面。从最小的操作系统基础镜像（如 Alpine Linux）开始，可以减少镜像大小，并使镜像更易于管理。
|
||||
|
||||
* **扫描镜像的已知问题。**当镜像构建后，应该检查已知的漏洞披露。可以扫描构成镜像的每个文件系统层，并将结果与定期更新的常见漏洞披露（CVE）数据库进行比较。然后开发和安全团队可以在镜像被用来启动容器之前解决发现的漏洞。
|
||||
|
||||
* **数字签名的图像。**一旦建立镜像，应在部署之前验证它们的完整性。某些镜像格式使用称为摘要的唯一标识符，可用于检测镜像内容何时发生变化。使用私钥签名镜像提供了加密保证，每个用于启动容器的镜像都是由可信方创建的。
|
||||
|
||||
* **强化并限制对主机操作系统的访问。**由于在主机上运行的容器共享相同的操作系统，因此必须确保它们以适当限制的功能集启动。这可以通过使用内核安全功能和 Seccomp、AppArmor 和 SELinux 等模块来实现。
|
||||
|
||||
* **指定应用程序级别的分割策略。**微服务之间的网络流量可以被分割，以限制它们彼此之间的连接。但是，这需要根据应用级属性（如标签和选择器）进行配置，从而消除了处理传统网络详细信息（如 IP 地址）的复杂性。分割带来的挑战是必须事先定义策略来限制通信，而不会影响容器在环境内部和环境之间进行通信的能力，这是正常活动的一部分。
|
||||
|
||||
* **保护容器使用的秘密。**微服务彼此交互频繁交换敏感数据，如密码、令牌和密钥，称为秘密。如果将这些秘密存储在镜像或环境变量中，则可能会意外暴露这些秘密。因此，像 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)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [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
|
||||
Loading…
Reference in New Issue
Block a user