前几天数世咨询的一篇文章中介绍了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.

声明：本文来自数世咨询，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。