值得推荐的十大安全加固容器方法

译文
安全 应用安全
在本文中,我们将讨论各种可遵循和实施的容器安全优秀实践与工具,以降低容器化工作负载的各项安全风险。

众所周知,网络安全事件会对一个组织的声誉、以及市场竞争力造成严重的影响,甚至可能导致由最终用户发起的诉讼、以及各种不必要的法律纠纷。根据IBM的一份​​调查报告​​,全球范围内的各个组织平均每次由数据泄露所带来的总体成本约为392万美元。通常,一个组织会因为如下方面的疏漏,而拉低整体的安全态势:

  • 缺乏安全管理工具和实践的技能和培训
  • 缺乏风险的可见性和漏洞的发现机制
  • 未能持续监控当前系统与服务的安全状态

而根据PaloAlto Networks最近的一份《​​云安全状况调查报告​​》表明,有94%的组织正在使用着一个或多个云平台,并且其中有大约45%的计算会发生在他们容器或CaaS(容器即服务)上。随着应用容器的主导地位的逐步攀升,由此引发的安全威胁也在不断增加。同时,该报告也罗列出了如下八大主要安全威胁:

  • 由恶意软件引发的数据泄露
  • 应用程序的代码级漏洞
  • 系统身份验证组件的薄弱或被破坏
  • 应用的配置错误
  • 不正确的访问或权限过高
  • 源自内部的威胁
  • 身份认证凭据的泄漏
  • 不安全的端点

针对上述威胁,我们将在下面和您讨论一些有关容器安全性的优秀实践。您可以通过遵循并实施,来降低容器化工作负载中的各种安全风险,进而实现对于应用程序的保护。

1. 来自受信存储库的基于源代码的镜像

当我们创建容器镜像时,通常会依赖那些来自流行的、私有的或公共注册表的种子镜像。不过请注意,在镜像制作的供应链中,有人可能会渗透进去,并植入能够为攻击者打开“大门”的恶意代码。例如,在2018年,一些黑客曾攻击了英国航空公司的软件供应链。他们将恶意的JavaScript代码插入英国航空公司的Web应用程序之中。具体请参见链接--https://www.wired.com/story/british-airways-hack-details/。同样,就在几年前,Docker在其Docker Hub上也发现了一些被安装了Cryptominers(加密货币挖矿软件)的​​镜像​​。

因此,您需要在如下方面引起足够的重视:

  • 在创建容器镜像时,请使用来自知名可信发布者的、经过安全加固的基础性镜像源。
  • 请选择那些经常被更新的、带有最新安全修复和补丁的镜像。
  • 请使用那些经过签名和标记的镜像,并在拉取的过程中验证镜像的真实性,以阻断中间人攻击。

2. 安装经过验证的包

出于同样的原因,我们也需要保障被安装在基础镜像上的软件包,也源自经过验证和受信任的来源。

3. 最小化镜像中的攻击面

我们常说应用的受攻击面与镜像中已安装的软件包和库的数量有关。通常,如果此类对象的数量较少,那么出现漏洞的机率也就越低。可见,我们应当在满足应用程序运行时的基本要求的前提下,尽可能地保持镜像的体积最小。理想状况下,我们最好在一个应用程序容器中,仅保留一个应用程序。同时,您可以从如下方面入手:

  • 删除不必要的工具和软件,包括:包管理器(如,yum和apt)、网络工具、客户端、以及镜像中的shell和netcat(可用于创建反向的shell)等。
  • 使用多阶段(multi-stage)的Dockerfile,并从生产环境的镜像中删除各个用于软件构建的组件。
  • 为了减少威胁,请不要在容器中暴露不必要的网络端口、套接字、以及运行不需要的服务(如SSH的守护程序等)。
  • 与其选用带有完整操作系统的镜像,不如选择alpine镜像、临时镜像或专为容器优化了的操作系统。

4.不要在镜像中留存信任凭据

所有的信任凭据都应该“远离”镜像和Dockerfile。包括SSL证书、密码、令牌、以及API密钥在内的各种机密信息,都应当被保存在外部,并通过容器编排引擎、或外部密钥管理器,进行安全地挂载。目前,Hashicorp Vault工具,由AWS Secrets Manager、Kubernetes Secrets、Docker Secrets Management、以及CyberArk等提供的云端密钥管理服务,都可以改善您在此方面的安全态势。

5. 使用安全的私有或公共注册表

企业通常拥有自己的基础镜像,其中包含了各种他们不想公开分发的专有软件库。为了确保镜像能够被托管在安全且受信的注册表处,以防止未经授权的访问,请使用具有可信根CA的TLS证书,并实施强身份验证,以防范MITM(中间人)攻击。

6.不要使用特权或root用户,在容器中运行应用程序

这是容器化工作负载中最常见的配置错误。请牢记最低权限原则,创建一个应用程序的专用用户,并使用它在容器内运行应用程序的对应进程。您也许会问为何不能用root用户呢?其原因是:除了通过其带有的额外元数据,来识别是否为容器的一部分,在容器中运行的进程,与在主机操作系统上运行的进程十分相似。而一旦容器中的root用户有了UID和GID,那么它可以访问、甚至修改其在宿主机上的文件。

注意,如果您没有在Dockerfile中定义任何USER的话,那么容器就会以root用户运行。

7. 在CI/CD中实施镜像漏洞扫描

在为容器的构建和交付设计CI/CD时,请包含一个镜像扫描方法,以识别那些由CVE公布到的知名漏洞。同时,请不要在没有修复的情况下,部署任何可用的镜像。常见的漏洞扫描工具包括:Clair、Synk、Anchore、AquaSec、Twistlock等。同时,AWS ECR和Quay.io等容器注册表也需要配备各种相应的扫描方案。

8. 启用AppArmor等内核安全配置文件

AppArmor是一个Linux安全模块,可被用于保护操作系统、及其应用程序免受各种安全威胁。Docker通过提供默认配置文件的方式,允许程序访问诸如:网络访问、内核功能、文件权限等有限的资源。该方法不但减少了潜在的攻击面,而且提供了很好的深度防御。

9. 安全集中式的远程日志记录

通常,容器将所有内容记录到标准输出--STDOUT上。显然,这些日志会因为中断而丢失。因此,我们需要将日志安全地、以传输流的方式集中到一处,以供未来的审计和按需取证。当然,我们需要确保此类日志系统的安全性,以免敏感数据信息从日志中泄漏出去。

10. 部署运行时(Runtime)的安全监控

前面给出的九项安全建议,只是最大限度地减少了安全威胁,并不能完全阻止攻击的发生。对此,我们仍然需要通过持续监控和记录应用程序的行为,来及时检测并发现任何可疑或恶意的活动。同时,我们还可以实施分层防御,对不同的监控范围,部署不同的审计与容器保护工具。

可用于安全控制的开源工具

常言道:“工欲善其事,必先利其器”。为了简化上述针对容器的安全加固,我在此为您罗列了如下六大开源和商业工具,以方便您按需采用:

  • ​Docker-bench-security​​– 属于Docker的官方工具。作为由​​CIS Benchmark​​针对Docker提出的行业标准,它可以被用于审计容器的各种工作负载。
  • ​Hadolint Linter for Dockerfile​​ – 可以使用linter对Dockerfile进行静态代码分析。作为一种优秀实践,linter可与各种流行的代码编辑器和集成管道相整合。
  • ​Clair​​ – 是一种流行的应用容器静态漏洞扫描工具。它会定期从各种漏洞数据库中获取元数据。其同类工具包括:​​Anchore​​、​​Synk​​、以及​​Trivy​​。
  • ​OWASP Cheatsheet​​– 该漏洞备忘录来自备受安全专家欢迎的开放社区--OWASP。
  • ​OpenSCAP for Container​​– SCAP(Security Content Automation Protocol,安全内容自动化协议)是一个多用途的规范框架,可以支持自动化配置、漏洞和补丁检查、技术控制的合规活动与安全测量等。它执行的是NIST各项标准。
  • ​Sysdig Falco​​​– 随着黑客的持续进步和新漏洞的不断涌现,静态扫描工具已显得力不从心。我们需要能够持续进行行为监控、以及基于AI/ML的高级引擎。而作为一种可用于实现运行时安全性的工具,Falco使用高效的eBPF去拦截各种调用与流量,并能实时进行监控和取证。

此外,您还可以选用AquaSec、Twistlock、Sysdig、Synk、以及Qualys等企业级安全工具和商业产品。

希望上述各种解决方案能够真正为您抵御黑客攻击,协助您及时发现当前系统中的异常状态,以及为您的容器负载提供合理化的改进建议。

译者介绍

陈峻 (Julian Chen),51CTO社区编辑,具有十多年的IT项目实施经验,善于对内外部资源与风险实施管控,专注传播网络与信息安全知识与经验;持续以博文、专题和译文等形式,分享前沿技术与新知;经常以线上、线下等方式,开展信息安全类培训与授课。

原文标题:Top 10 Ways To Secure Containers,作者:Anjul Sahu

责任编辑:华轩 来源: 51CTO
相关推荐

2022-01-14 14:33:20

安全挑战勒索软件供应链

2009-06-16 14:48:06

2014-01-02 09:26:04

2013-07-26 13:23:28

2020-07-30 07:00:00

API安全威胁零日漏洞

2014-03-11 16:52:20

2013-07-05 10:18:14

2022-12-29 07:40:58

2014-05-15 09:44:52

2020-10-28 09:37:08

React代码数据

2016-12-26 16:23:24

2016-02-15 14:32:38

2011-12-23 10:09:20

2021-12-29 06:15:01

安全误区网络安全安全公司

2014-01-03 11:22:53

2018-08-31 08:11:29

2024-03-12 08:57:39

2011-03-25 09:40:57

2016-01-20 12:40:09

2010-10-25 17:22:52

点赞
收藏

51CTO技术栈公众号