建议投诉 | 联系我们 | 关注微信 安全虎 - 专注于互联网信息安全的科技新媒体!
你的位置:首页 > 行业虎评 » 正文

为什么保护容器和微服务很难

来源:2018-05-21 | 人围观 | 评论:暂无评论

 容器环境的粒度、部署速度和数据流量规模都要求采用新安全方法。

容器是一种简单方便快速的跨计算环境软件部署及运行方式。通过将应用的整个运行时环境(库、可执行程序和配置文件)容纳进来,平台和基础设施被抽象了出来,让应用或多或少地可以在任何地点运行。所有主流云提供商和现场数据中心以及混合云环境都提供容器,而且,容器还能节省下很多开支。

开发人员可用容器创建微服务,也就是应用的可重用组件。因为可重用,微服务能帮开发人员免掉重新开发的时间。另外,微服务可跨不同平台部署。

因此,容器的采纳率高毫不令人意外。但不幸的是,安全界仍在摸索容器的运行机制和最佳锁定方法。迈克菲最近针对全球1500位IT人员的调查显示,雇员数超500人的公司企业中约有80%正在使用容器,但仅66%拥有容器安全策略。事实上,今年3月CyberEdge对1200名IT决策者的调查表明,容器如今与移动设备一起成为了公司企业最大的安全挑战。

有很多原因促成了安全成为容器世界中的一大挑战。原因之一,容器的部署速度。原因之二,容器通常要求应用被分割成微服务,造成数据流量和访问控制规则复杂度的增加。原因之三,容器通常运行在云环境中,比如AWS,适用新型的安全控制措施。

容器安全工具生态系统尚不成熟,类似虚拟机和云的早期时候。公司企业需构建专属工具和基础设施来让容器安全发挥作用,需要很多资源来实现容器安全。目前并没有太多已成型的解决方案可用,也没有足够的解决方案以覆盖所有用例。

容器的生命周期很短且缺乏良性管理

容器时代,构建-测试-部署的传统软件开发过程变得无关紧要。事实上,开发人员经常从公开代码库中直接拖来现成的镜像甩到云端。

但其中有些隐性的信任级是可能不被许可的。容器镜像是很便捷的现成代码包,但提供者可能没那个时间或兴趣监测安全问题或公开版本注释。

理想状况下公司企业应有版本检查的过程,但极少有企业真的这么做。公司应该持续检查自己所用容器是否是最新版本,所有的代码是否已打上补丁并做了更新。但目前,这些责任都落到了开发人员个体身上,而且大多是人工检查。这就出现了检查上的漏洞,往往落入拖来容器运行起来就再也不管的境地。公司企业真的应该引入更加自动化的过程了。

然而,开发人员自己构建容器也没好到哪儿去。开发速度意味着根本没时间保证质量或进行安全测试。到有人注意到容器上线的时候,他们基本也就等同完事儿撤漂了。

到安全团队可以入驻的时候,容器开发生命周期可能就完结了。这是个问题,需要另一套完全不同的安全思路。

需要在开发过程早期就引入安全意识,并尽可能地自动化。比如说,如果开发人员从外部源下载镜像,在容器上线之前应对镜像进行扫描,找出所有漏洞、未修复代码和其他潜在问题。而一旦容器上线,怎样维护并监视其安全状况,监控那些与其他组件互操作的瞬时动作呢?

举个例子,云安全提供商 Skyhigh Networks。这家公司部署最新的架构栈,有各种微服务,事实上,他们一天之中可以多次部署进生产环境。一般来讲,公司企业可以进行安全测试或渗透测试,但这两种测试不适用于开发运维环境。

必须找到自动化很多功能的方法,也就是说,得能够发现所有被部署的容器,确保这些容器的所有成分都是安全的,容器所处环境也是安全的——有应用控制和应用白名单,且施以持续的监测。

迈克菲在4月RSA大会上发布的云工作负载安全平台就是干这个的。该平台保护AWS、Azure和VMWare等公共云和私有云中的Docker容器及其中的工作负载,是能够将容器与被感染工作负载隔离的第一款云工作负载解决方案。

该产品还可通过检查非必要管理员权限或未满足的加密要求,以及核查AWS存储桶是否被设为公开可读,来减小配置风险。从客户反馈来看,该平台修复速度也有了提升——加快了90%。

目前为止,几乎所有的容器安全问题都是不当配置所致,容器的最大风险就在配置上。

服务漩涡

配置管理和补丁管理很难操作,攻击者却很方便利用这些漏洞,但至少,二者都是可以解决的问题。容器问题上另一块不散的阴云,在于应用被切分成大量内部互联的微服务时所产生的复杂性。

传统整体式应用的模型下,一个应用也就一个服务和两个端口。安全人员知道黑客将会攻击的地方,防护起来也颇为方便。

但微服务模式下,服务和端口数量暴涨,需要看好的门瞬间翻了几十倍不止。而且,每道门口的实时情况也更不容易掌握了,很难分辨出来敲门的是好人还是坏人。

于是,安全重任落到了确保每一道门都关得够紧上,也就是对每个微服务应用诸如最小权限、严格访问控制、隔离和审计等等安全原则。这些东西上世纪70年代就出现了,没想到现在还需要这么做。

真是说起来容易做起来难。公司企业持续将其整体的服务分解成越来越细小的微服务,应用的数据流因而变得越来越复杂,以致难以分辨每个微服务的状态。

只要众多微服务中混进了一个硬编码的访问凭证,或者泄露了某个身份验证令牌,那整个系统顿时对黑客不设防。这是个大问题,然而人们往往没意识到该问题的严重性。

而且,随着越来越多的关键系统迁移到软件即服务的交付模式,这个问题持续发酵。公司企业将大量数据集中进自身应用中,让这些非常敏感重要的数据在微服务间流转,几乎没有人拥有对这些数据流的良好视野。Equifax就是个很好的例子,Uber也是。

容器漏洞

容器面临的安全挑战还有一个:漏洞。容器运行在共享环境中,客户不知道自己的邻居都是谁,这种情况在公共云环境下更为突出。事实上,过去几年里Docker和Kubernets容器管理系统中都发现了漏洞。

在公共云上运行容器的公司刚开始意识到这个问题,直接询问有没有什么工具能够抵御容器逃逸攻击,能够将容器相互隔离。

Portworx 2017容器采用调查中,超过70%的受访者在Linux上运行容器。管理员可用于确保容器隔离的方法包括利用Linux名字空间,以及用 Security Enhanced Linux 作为强制访问控制的补充。另外,还有名为 Linux Capabilities 的东西可以用来限制Linux系统中进程的不同访问权限。

Linux安全专家对这些概念相对熟悉,但部署容器的团队未必掌握,刚刚从Windows迁移到Linux的公司企业就更不知道这些东西了。运营自己的容器环境的公司,无论是在公共还是私有云上,至少都对自身安全设置有全权控制。但使用现成容器时,就只有信任云提供商能够搞对底层安全基础设施了。

目前为止,能让进程逃出容器的那些漏洞尚未造成重大数据泄露。但容器领域被少数几个大平台把持的事实,意味着一旦攻击者能够快速利用,仅仅1个漏洞都能造成大面积的伤害。所以,容器漏洞问题真的应认真面对,多加准备了。

标签:

相关内容推荐:

Top