11 种微服务和容器安全最佳实践(下)
导语:在本文中,我们观察了在开发应用程序时可能出现的基于容器和微服务的架构中的安全挑战。我们还提供 11 种微服务和容器安全最佳实践。
保护微服务和容器的 11 个最佳实践
我们在下面提到的实践可能有助于保护您当前使用容器和微服务开发应用程序的方式。但是,如果您才刚刚开始创建应用程序或即将将您的产品从单体架构迁移到基于微服务的架构,请确保准备好全面的安全策略。
NIST 建议概述两种类型的策略:
我们的容器和微服务最佳实践列表基于 Apriorit 团队的专业知识、领先的微服务从业者提供的安全建议以及以下文档中反映的行业标准:
· NIST 特别出版物 800-180(草案)NIST 对微服务、应用程序容器和系统虚拟机的定义
· NIST 特别出版物 800-190应用容器安全指南
· NIST 内部报告 8176 Linux 应用程序容器部署的安全保证要求
· NIST 特别出版物 800-204基于微服务的应用系统的安全策略
· 工作和养老金安全标准 - 微服务架构 (SS-028) [PDF]
现在让我们仔细看看如何在使用微服务和容器时开发安全的应用程序。
11个最佳实践容器微服务安全
1. 创建不可变容器
开发人员倾向于让 shell 访问图像,以便他们可以在生产中修复它们。但是,攻击者经常利用这种访问权限来注入恶意代码。为避免这种情况,请创建不可变容器。
根据Google Cloud Architecture Center的说法,不能修改不可变容器。如果您需要更新应用程序代码、应用补丁或更改配置,您可以重建映像并重新部署容器。如果需要回滚更改,只需重新部署旧镜像即可。您可以在每个环境中部署相同的容器映像,使它们完全相同。
请注意,远程管理是通过运行时 API 或通过创建与运行微服务的主机的远程 shell 会话来完成的。容器的不可变特性也会影响数据持久性。开发人员应将数据存储在容器之外,以便在替换某些容器时,所有数据仍可用于其新版本。
2.每台主机部署一个微服务
根据microservices.io,部署微服务有六种模式:
· 每个主机多个服务实例
· 每个主机的服务实例
· 每个 VM 的服务实例
· 每个容器的服务实例
· 无服务器部署
· 服务部署平台
两个最有益的部署选项是每个容器的服务实例和每个主机的服务实例,因为它们允许您:
· 将服务实例彼此隔离
· 消除资源需求或依赖版本冲突的可能性
· 允许服务实例最多消耗单个主机的资源
· 轻松监控、管理和重新部署每个服务实例
虽然在同一主机上部署多个微服务可以比每个主机模式的服务实例更有效地利用资源,但它也有很多缺点:
· 资源需求冲突和依赖版本冲突的风险
· 限制服务实例消耗的资源的困难
· 如果多个服务实例部署在同一进程中,则难以监控每个服务实例的资源消耗
3. 将自动化安全测试集成到您的构建或 CI/CD 流程中
有多种工具可以在构建或 CI/CD 过程中自动测试容器。例如,HP Fortify 和 IBM AppScan 提供动态和静态应用程序安全测试。
您还可以使用JFrog Xray和Black Duck等扫描仪实时检查容器中的已知漏洞。一旦这些工具发现漏洞,它们就会标记带有检测到问题的构建,让您可以检查和修复它们。
4.避免使用特权容器
如果容器以特权模式运行,则它可以访问主机上的所有组件。因此,这样的容器充当主机操作系统的一部分,并影响在其上运行的所有其他容器。如果这样的容器受到威胁,攻击者将拥有对服务器的完全访问权限。
因此,请考虑避免使用特权容器。例如,在 Kubernetes 中,您可以使用Policy Controller 禁止特权容器。
如果出于某种原因您需要使用特权容器,Google Cloud Architecture Center提供了一些替代方案:
· 通过 Kubernetes 的securityContext 选项或Docker中的 --cap-addflag 选项为容器提供特定的能力
· 在 sidecar 容器或init 容器中修改应用程序设置
· 使用专用注解修改 Kubernetes 中的 sysctls 接口
5. 仅从受信任的来源运行图像
对于具有现成容器的开发人员,有许多开源包。但是,出于安全目的,您需要知道容器的来源、更新时间以及它们是否没有任何已知漏洞和恶意代码。最好建立一个受信任的映像存储库并仅从该受信任的来源运行映像。
此外,开发人员应在将容器投入生产之前检查其脚本中的应用程序签名。如果您在多个云环境中运行容器,那么拥有多个映像存储库是可以接受的。如果您想使用其他来源的图像,建议使用扫描工具扫描图像。
6. 使用注册表安全地管理图像
Docker Hub、Amazon EC2 Container Registry 和 Quay Container Registry 等注册表可帮助开发人员存储和管理他们创建的映像。您可以使用这些注册表:
· 提供基于角色的访问控制
· 指定容器的可信来源
· 创建和更新已知漏洞列表
· 标记易受攻击的图像
请注意,基于角色的访问控制也很重要,因为您需要控制谁可以对您的容器进行更改。最好限制对特定管理帐户的访问:一个负责系统管理,一个负责操作和编排容器。
要记住的另一件事是确保您的注册表验证每个容器的签名并仅接受来自可信来源的那些。此外,利用可帮助您不断检查图像内容是否存在已知漏洞并通知安全问题的功能。例如,一旦您将镜像推送到 Docker Hub 并启用漏洞扫描, Docker Hub 漏洞扫描会自动扫描镜像以识别容器镜像中的漏洞。
7.强化主机操作系统
虽然大多数建议都涉及微服务和容器的安全性,但也有必要确保主机操作系统的安全性。
首先,NIST 建议使用特定于容器的主机操作系统(明确设计为仅运行容器的极简主机操作系统),因为它们没有不必要的功能,因此攻击面比通用主机小得多。最好使用允许通过路由器或防火墙控制出口流量的平台。
其次,CIS Docker Benchmark提供了强化系统的检查表。这些建议因操作系统、服务器软件、云提供商、移动设备、网络设备和桌面软件而异。
主要建议是:
· 建立用户认证
· 设置访问角色
· 指定二进制文件访问权限
· 收集详细的审计日志
为了避免数据泄露,限制容器对底层操作系统资源的访问,并将容器相互隔离。一个好的做法是在内核模式下运行容器引擎,同时在用户模式下运行容器。
例如,Linux 提供了 Linux 命名空间、seccomp、cgroups 和 SELinux 等技术,用于安全地构建和运行容器。
8. 使用纵深防御方法保护微服务
纵深防御是一种信息安全方法,它依赖于安全机制和控制(如防病毒软件、防火墙和补丁管理)的组合。其目标是在整个 IT 系统中提供多层安全性,以保护网络和数据的机密性、完整性和可用性。
纵深防御方法的三个关键层是:
· 物理控制——物理限制访问 IT 系统的任何东西,例如警卫和闭路电视系统
· 技术控制——旨在保护系统和资源的硬件和软件(下文讨论)
· 管理控制——各种政策和程序,以确保组织关键基础设施的适当网络安全
深度防御方法是微服务安全最重要的原则之一,因为它创建了多层安全性来防止攻击。它包括以下安全措施:
· 过滤通信流
· 对微服务进行身份验证和授权访问
· 使用加密技术
确保保护您的内部环境免受任何外部连接的影响,因为它是第一层防御。例如,检查您没有使用公共存储库中的图像,因为它们可能会给您的应用程序带来安全风险。通过已知的专用网络管理主机,这样就不会有公共攻击面。
9. 使用 API 访问控制安全访问微服务
API 是微服务应用程序的关键。基于该技术的软件有多个独立的 API 服务,需要额外的工具。
因此,确保安全认证和授权的 API 访问控制对于微服务安全至关重要。访问可以处理敏感数据的 API 应该需要经过数字签名或权威来源验证的身份验证令牌。
开发人员和管理员通常使用 OAuth/OAuth2 服务器来获取令牌以通过 API 访问应用程序。出于安全原因,您还应该应用传输层安全 (TLS) 加密来保护所有客户端-服务器通信。
10.使用容器原生监控工具
监控容器是必不可少的,因为它可以帮助您:
· 深入了解容器指标和日志
· 了解集群和主机级别以及容器内发生的情况
· 做出更明智的决策,例如何时扩展或扩展实例、更改实例类型和购买选项等。
但是,要建立有效的监控,最好使用容器原生监控工具。例如,在使用Docker时,开发人员通常使用 Docker Security Scanner 或其他专门设计的工具来检测对应用程序的任何潜在威胁。
监控工具首先收集事件,然后根据安全策略检查它们。确定性策略可以定义可以运行哪些服务以及允许哪些容器发出外部 HTTP 请求。动态策略可以创建正常通信活动的基线,并通知流量峰值或异常流量。
11. 使用编排管理器
编排是一个复杂的过程,可以自动化微服务和容器的部署、管理、扩展和网络。通常,它可以通过两种方式实现:
· 通过使用 API 网关作为编排层
· 通过将编排编码为单独的微服务
编排器从注册表中提取图像,将这些图像部署到容器中,并管理它们的运行。编排器提供的抽象允许您指定运行给定映像需要多少个容器以及需要为它们分配哪些主机资源。
通过使用编排管理器,您不仅可以自动化微服务的部署,还可以确保一定程度的安全性。例如,编排器允许您管理容器集群、隔离工作负载、限制对元数据的访问以及收集日志。
许多编排管理器还具有内置的机密管理工具,允许开发人员安全地存储和共享机密数据,例如 API 和 SSL 证书、加密密钥、身份令牌和密码。有许多编排管理器,例如Kubernetes、Swarm 和 Mesos,以及作为 Azure、谷歌云计算和 AWS 的一部分提供的云原生管理系统。
结论
基于微服务的软件的综合安全计划应涵盖整个应用程序生命周期。使用所描述的最佳实践,您可以确保容器和微服务的安全开发和部署。
发表评论