网络安全动态 ·

再谈云配置飘移形成的新威胁趋势

前几天数世咨询的一篇文章中介绍了DevSecOps的一份调查报告,报告显示90%的云资源配置在部署后都会被特权用户修改。当然,许多情况下这些修改都是合法的业务需求,但也有一些则是攻击者在入侵之后的横向移动所造成的。

不安全的配置已经成为云上数据泄露最为主要的因素,如果不能及时的发现并解决,就会为攻击者敞开大门,成为一个来去自如的入口。

架构即代码以及安全错觉

根据Accurics的研究发现,在云环境中,近1/4的配置变化是通过代码进行的。这在DevOps流程中被称为架构即代码(infrastructure as code, IaC)或者连续配置自动化(continuous configuration automation, CCA)。大部分云供应商允许他们的顾客通过机器可读的定义文档或者模板,提供新的资源或者云实例。另外,还有许多第三方工具适用于多种云环境。

Accurics的报告数据来自于客户调查、CISO、与其他合作伙伴的开源调查,外加Accurics自身对成百上千个真实环境的云资源的分析。

如果配置得当,由于IaC模板可以减少人为配置带来的错误,从而加强安全性;尤其在涉及设置较多的时候,效果更为显著。IaC可以作为安全左移的一部分,并集成在DevOps的早期流水线上。

但是,做到这些的前提条件,是云环境中的IaC模板必须遵照最佳实践,并能满足多种标准。然而事实上,这只存在于理想状况之中。派拓网络从GitHub等资源处中收集了大量IaC模板并进行分析,发现了近20万的文件中包含不安全配置选项。一些普遍被发现的问题包括:

  • 对数据存储缺少加密和记录

  • SSH和RDP等服务直接暴露于互联网

  • 凭证无法满足行业最低标准

  • 容器缺乏对CPU或者记忆空间的资源限制

  • 云存储缺乏安全存储选项

Accurics发现,67%被发现的设置错误都属于高危风险,问题包括公开的安全组、权限过高的IAM角色、暴露的云存储服务;超过40%的资源并未满足所有的CIS关键安全控制要求,18%的资源没有满足PCI-DSS要求,19%违反SOC2标准,并有10%没有满足HIPAA要求。

Accurics的联合创始人兼CEO,Sachin Aggarwal认为:“我觉得24%通过代码进行的是设置是没问题的。一个很大的问题在于,绝大部分的IaC代码,在被使用到真实运行的环境前,是没有进行任何安全评估的。结果而言,虽然说企业确实在早期就启用了IaC,并且创建了自己的DevOps流水线;但是,在企业明明有机会将安全完全嵌入代码的时候,却没有做任何的安全评估。”

云配置飘移问题

确保IaC模板包含安全配置选项只是保障云环境安全的第一步。持续对云资源,以及之后可能影响安全的配置改变进行监控,也同样重要。根据Accurics的发现,在通过代码部署的云环境中,有超过90%存在配置飘移问题。

“现实是,特权用户确实会在业务系统的云架构中直接修改代码。”Accurics在报告中提到,“在某些情况中,这些改变是被授权、合规的;但其他情况中,改变会带来风险。无论结果如何,云配置都会通过代码从基线产生飘移,而代码应该是修改的唯一来源。”

Accurics发现有77%的云资源产生了配置飘移的功能有云实例(37%)、应用负载均衡(19%)、安全组(15%)以及云存储服务(5.5%)。

这些配置飘移的一部分原因是工作环境文化,以及管理员和架构工程师的工作习惯导致的。正如DevOps自身有文化变化一样,不经记录手动改变配置的习惯,也会随着时间的推移和新策略的实施而减少。但是,也有一些其他人为操作的原因,包括攻击者试图提升自身的权限,因此监测任何运行中的云实例和资源的配置变化依然很重要。

越晚发现这些不安全、未记录的配置变更,之后修复就越难——因为之后可能还有更多基于这些变更的进一步变更,而最初修改配置的意图可能也已经被遗忘。根据Accurics的报告,只有4%在生产系统发现的问题被真正关注。

最后,Accurics发现超过80%的组织使用不止一种IaC技术,比如与Terraform、Kubernetes YAML、Dockerfile、以及OpenFaaS YAML.

声明:本文来自数世咨询,版权归作者所有。文章内容仅代表作者独立观点,不代表安全内参立场,转载目的在于传递更多信息。如有侵权,请联系 [email protected]

参与评论