私有云安全:容器安全设计实践 – 作者:dawner

私有云安全由于其合规性和独立性,不同于公有云和混合云,需要单独定制落地的流程和规划,这里跟大家简单聊聊关于容器安全设计的相关问题。

1604894586_5fa8bf7ac0319522b05a8.jpg!small

容器安全综述

容器安全架构设计,可以在其三大关键生命周期阶段进行实施,其中包括镜像安全、配置安全、运行安全。

镜像安全:

在初始阶段对镜像本身做把控,从供应链进行核查,在日常会对镜像做验证和校验,最后会在构建时进行阻断或者检测。

配置安全:

对于构建好的初始镜像,需要遵从行CIS、NIST最佳安全实践。在构建好系统后,需要检查相应的Docker配置、Kubernetes配置、以及操作系统本身。

运行安全:

在容器运行的时候,我们会对里面的系统运行状态进行监控,还会对CMDB资产图谱状态进行对比核查。

镜像安全

嵌入流程检测

这部分工作可以结合CICD流水线进行,一般有两种建议。

CI构建阻断:

日常构建新镜像时,接入配置扫描和白盒扫描流程,如果核查出错会直接阻断,这种做法稍显粗暴,而且会影响业务,但这样可以减少镜像出现风险的可能性,后续重构建的工作也会相应减少。

旁路分析:

复制需要检测的镜像,进行模拟构建,出问题直接阻断。这样的好处是不会影响业务进程,但脆弱的镜像可能会被构建到生产环境,存在潜在风险。

出现问题后,研发运维人员需要根据镜像标签去做追踪,剔除脆弱镜像或者排期重新构建。

这种一般是在构建时,不会直接阻断流程,而是旁路提供鉴定报告,后续再供给安全运维人员进行分析。

当然如果需要得到即时结果,则构建扫描可以提供API攻击给Docker CI平台,作为结果自动化处理的参考。

镜像初始安全

镜像库内控

首先,对于镜像本身,由于企业自用的镜像大部分是规范定制化的,纯私有云落地的话不建议使用公网镜像库,可以看看harbor之类的,这也是为保障供应链风险可控。

由于私有云合规性的特殊要求,一般是要求不能接入专线(与混合云不同),这样能在减少诸如水坑攻击,或者防止被黑客大规模挂马之类攻击误伤。

镜像仓库核查

对于初始镜像,需要定期核查软件镜像库,查看镜像是否被植入木马。如果私有镜像仓库由于配置不当而开启了2357端口,将会导致私有仓库暴露在公网中。

这样的话,攻击者可以直接访问私有仓库并篡改镜像内容,存在仓库镜像被污染的隐患。

镜像扫描核查

镜像核查,主要会做两方面的工作:

第一,是进行常规漏洞检测,根据CVE漏洞库进行清单核查式扫描。

第二,是对系统进行基线检查,把潜在的风险扼杀在摇篮里。

这部分核查结果,需要分布走进行治理,首先更新初始镜像,把相关镜像的缺陷统一修复。 然后,会根据线上业务和系统本身的稳定性和适配度,在测试环境调试回归并灰度完毕,再统一进行替换。

镜像数字签名

Docker的内容信任(Content Trust)机制,可保护镜像在镜像仓库与用户之间传输过程中的完整性。目前。目前Docker的内容信任机制是默认关闭的,需要手动开启。

内容信任机制启用后,镜像发布者可对镜像进行签名,而镜像使用者可以对镜像签名进行验证。

镜像构建者在通过docker build命令运行Dockerfile文件前,需要通过手动或脚本方式将DOCKER_CONTENT_TRUST环境变量置为1进行启用。

在内容信任机制开启后,push、build、create、pull、run等命令均与内容信任机制绑定,只有通过内容信任验证的镜像才可成功运行这些操作。例如,Dockerfile中如果包含未签名的基础镜像,将无法成功通过docker build进行镜像构建。

(命令示例:export DOCKER_CONTENT_TRUST = 1)
供应链核查

对于代码中使用的公共组件包,需要对来源进行核查。在私有云的落地实践中,最好是建立私有包的仓库,这样即使镜像被进行植入性攻击,也在可溯源和可控制的范围内。

顺便提一下,企业日常使用的代码编译器,也需要在企业核准控制范围内。最好通过统一采购源,在内网提供正版的下载,以及提供内网激活API等方式。

但是,在目前大环境下,由于版权和虚拟资产购置价格过高的问题,不少互联网大厂也很难统一解决这一点。

配置安全

内部核查

Dockerfile核查

如果Dockerfile存在漏洞或被插入恶意脚本,那么生成的容器也可能产生漏洞或被恶意利用。例如,攻击者可构造特殊的Dockerfile压缩文件,在编译时触发漏洞获取执行任意代码的权限。

如果在Dockerfile中没有指定USER,Docker将默认以root用户的身份运行该Dockerfile创建的容器,如果该容器遭到攻击,那么宿主机的root访问权限也可能会被获取。

如果在Dockerfile文件中存储了固定密码等敏感信息,并对外进行发布,则可能导致数据泄露的风险。

如果在Dockerfile的编写中添加了不必要的应用,如SSH、Telnet等,则会产生攻击面扩大的风险。

Metadata安全监控

本身私有云环境是相对隔离的,但如果其中的数据访问鉴权方式不当,或者意外造成了安全密钥泄露的话,黑客可以比较容易的获取到敏感元数据。

所以在安全配置和访问控制上,我们仍旧需要在日常做好监控工作。

攻击面核查

强制访问控制

强制访问控制(Mandatory Access Control, MAC)是指每一个主体(包括用户和程序)和客体都拥有固定的安全标记,主体能否对客体进行相关操作,取决于主体和客体所拥有安全标记的关系。

在Docker容器应用环境下,可通过强制访问控制机制限制容器的访问资源。Linux内核的强制访问控制机制包括SELinux、AppArmor等。

内容信任机制

Linux内核能力表示进程所拥有的系统调用权限,决定了程序的系统调用能力。

因此,不当的容器能力配置可能会扩大攻击面,增加容器与宿主机面临的安全风险。

在执行docker run命令运行Docker容器时可根据实际需求通过–cap-add或–cap-drop配置接口对容器的能力进行增删,或者尝试通过配置文件进行统一调整。

构建资管图谱

枚举初始镜像内的软件包、端口、服务,构建初始清单列表。

如果私有云安全架构体系中,本身可以考虑构建类似于CMDB资产管理的系统,也可以考虑搭配像Dependency-track等工具,核查对于第三方的依赖。

否则的话,可以通过灰盒扫描和流量agent方式,对资产数据库进行补充检查。

同时,一旦出现异常,通过自动化对比初始状态数据,我们也能较快地发现风险。

运行安全

敏感信息检查

核查运行的镜像系统的代码中,是否存在敏感信息泄露:密码、秘钥、token等。

这个问题比较微妙,可能更偏向普适性的安全问题,但作为系统运行时安全,还是要提一下的。

黑盒扫描

在容器中系统的运行时,可能会无意中暴露一些攻击面,因此我们需要选择适当的扫描器进行定期核查。

这里简单例举几个黑盒扫描引擎:

nessus(网络主机漏洞扫描器)

awvs(web爬虫扫描器)

appscan(IBM重量级web扫描器)

dirscan(web路径扫描器)

docker-bench-security(官方基线核查脚本)

anchore(针对容器Docker的CVE扫描

来源:freebuf.com 2020-11-09 12:04:08 by: dawner

© 版权声明
THE END
喜欢就支持一下吧
点赞0
分享
评论 抢沙发

请登录后发表评论