- 缺乏安全管理工具和实践的技能和培训
- 缺乏风险的可见性和漏洞的发现机制
- 未能持续监控当前系统与服务的安全状态
而根据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