什么是基础设施即代码 (IaC) 安全？

• 基础设施即代码 (IaC) 是一种通过代码而非手动配置来预配和管理云基础设施的方法。
• IaC 安全有助于在应用程序进入生产环境之前，帮助企业发现并修复云错误配置。
• 如果实时云基础设施与企业的模板不符，配置漂移可能会造成漏洞。
• 使用策略即代码 (PaC) 将能够在整个 SDLC 期间自动执行安全与合规检查。
• 通过采用左移安全实践，企业可以在 CI/CD 管道中应用 IaC 扫描，从而降低修复成本。
• 现代暴露风险管理解决方案将 IaC 安全洞察与风险、攻击路径、身份及云资产相关联。

基础设施模板中的单个配置错误，可能在几秒钟内就波及数千项云资源。这正是基础设施即代码 (IaC) 安全旨在解决的核心风险。

IaC 允许通过机器可读的配置文件来定义和部署服务器、存储、网络以及安全设置，而无需手动配置。 Terraform、CloudFormation、Kubernetes 和 Ansible 等工具让云基础设施的预配更加快速且一致。

这能为您带来一致性、扩展性、可重复性和速度。 基础设施的部署只需几分钟，而不是几天。

然而，这种速度虽然赋予了 IaC 价值，但同样带来了风险。IaC 配置中的一个错误，可能会在几秒钟内迅速波及数百甚至数千个云实例。 

过于宽松的 IAM 策略、暴露在外的存储桶，或是缺失的加密设置，都可能在无人察觉的情况下，从开发环境悄然进入生产环境。

IaC 安全是指通过扫描模板、强制执行策略以及在整个云环境中保持可见性，在配置错误尚未被漏洞利用之前就发现这些错误。

如今，许多严重的云安全事件，其根源其实都只是一个简单的配置错误。

最常见的风险之一是，云存储、网络权限和 IAM 策略配置错误，且这些错误会被直接嵌入到基础设施模板中。 一旦这些模板进入生产环境，每次部署都会继承相同的缺陷。

默认权限过于宽松是另一个常见问题。开发团队在测试阶段通常更注重速度，因此在将代码部署到生产环境时，可能会忽略收紧权限设置。测试阶段授予的过多权限可能会在整个部署生命周期持续存在。

将凭据和密钥直接硬编码到配置文件中，是另一个长期存在的问题。 当攻击者能够查看代码库或部署管道时，硬编码的凭据、API 密钥和访问令牌会使其获得未经授权的访问权限。

在软件开发过程中，第三方模块和可重用代码库被广泛使用。 虽然这些工具能加快开发进程，但其往往伴随着一些固有风险，例如不安全的依赖项和过时的配置。

加密方面的缺口也会导致云配置错误的风险。 如果缺少加密设置（无论是静态数据、传输中的数据还是备份数据），关键数据就会暴露在外，从而引发 PCI-DSS、GDPR、HIPAA、PSD2、SOC 2、CIS Benchmarks 和 NIST 等框架的合规问题。

最后，日志记录和监控方面的配置不当可能会导致在部署后无法获得所需的可见性，从而无法识别可疑活动或无法妥善调查事件。

当实时环境的基础设施开始偏离其最初经批准的 IaC 模板时，就会发生配置漂移。

虽然基础设施最初可能处于合规状态，但随着时间的推移，变更会不断累积。 工程师在云控制台中实施紧急修复，管理员则创建临时策略例外清单。 

团队会临时修改权限，但后来却忘记撤销这些权限。

这些手动更改导致了已批准的模板与实际生产环境之间的差异。

后果则是，您的基准越来越不可靠。IaC 模板中的配置可能与生产基础设施上的实际配置有所不同。 

可能存在开放的端口、宽松的访问控制、已禁用的日志记录，或者在没有任何文档或授权的情况下运行的服务。

配置漂移很少会以一次灾难性的事件形式出现。 相反，它会随着时间的推移而逐渐积累。 每项变化单独来看似乎都无足轻重，但累积的暴露风险会在数月或数年间稳步增加。

这一挑战与 AI 系统中的模型漂移颇为相似。性能会逐步渐进式下降，没有明显的单点故障。等到问题显而易见时，可能已经存在重大风险了。

传统的时间点安全评估无法发现漂移，因为它们仅捕获某个时间点的快照。实时监控的效果要好得多，因为它能立即检测到偏差，并在基础设施偏离既定基准时发出警报。

如果打算实施暴露风险评估和暴露风险管理，配置漂移是一项关键因素，因为它会对现有安全控制措施造成影响。

策略即代码 (PaC) 将手动安全治理转变为一种自动化的可扩展功能。

PaC 依靠无需例行检查或人工审批，而是将安全和合规要求定义为机器可读的策略，由系统自动执行。

这些策略贯穿整个基础设施生命周期。

在任何代码进入源代码控制系统之前，开发人员会通过 IDE 中的提交前检查获取反馈。 CI/CD 管道中的配置检查会在合并和部署之前验证配置。 持续监控系统会在部署后对配置进行验证。

这种做法可以将策略执行前移至代码编写阶段。企业可以在开发人员构建云基础设施时就发现问题，而不是等到团队预配好云资源之后才有所察觉。

策略即代码还能确保跨多云环境的一致性。 无论环境是在 AWS、Azure 还是 Google Cloud 上运行，都无需进行额外的手动审核即可实施安全策略。

这点同样适用于合规领域。 每次执行策略时，系统都会生成审计追踪，记录应用了哪些控制措施、团队中的哪位成员执行了这些控制措施，以及基础设施是否成功通过了自检。 PaC 支持的合规要求包括 SOC 2、CIS Benchmarks、NIST、PCI-DSS、GDPR、PSD2 和 HIPAA。

更重要的是，PaC 能够规模化识别和控制配置漂移。 如果没有自动化，要在动态的云环境中维持治理将困难得多。

越早发现基础设施的安全问题，解决起来就越容易，成本也就越低。

当配置错误进入生产环境时，修复工作往往涉及额外的测试、执行变更管理流程，还会导致服务中断，且需要在多个团队之间进行协调。 随着问题在软件开发生命周期 (SDLC) 中不断深入，成本也会大幅增加。

左移安全策略通过将 IaC 扫描直接集成到 CI/CD 管道，解决了这一挑战。

无需在部署后等待安全团队进行审查，开发人员可以在开发过程中即时收到反馈。 他们可以在代码合并到生产分支之前修复安全问题。

这种方法可以让安全性从一种下游的审计功能，转变为完全集成到开发流程的一个组成部分。

现代 DevSecOps 安全框架必须整合基础设施即代码扫描，以及静态应用程序安全测试 (SAST) 和动态应用程序安全测试 (DAST)，从而在软件、基础设施和部署管道之间构建持续的安全视图。

随着企业加快云技术的采用，应用程序安全与基础设施安全之间的界限正日益模糊。 基础设施为应用程序提供支持，而基础设施大多以代码的形式呈现。为了实现有效的暴露风险管理，企业需要对两者都了如指掌。

AI 编码助手和代理式 AI 正在转变开发团队构建基础设施的方式。

越来越多的软件工程师开始借助 AI 驱动的自动化技术来编写 Terraform 模板、Kubernetes 配置、云部署脚本以及其他基础设施组件。 

这些工具虽然可以提高效率，但也会带来新的漏洞。

AI 可以在几秒钟内生成基础设施代码，但其安全性无法得到保证。 模板虽然可以正常运行，但可能会暴露存储资源、授予过多的权限、跳过加密步骤，或者将服务直接暴露在互联网上。 

如果在未经审查的情况下就盲目相信输出的结果，这些问题就会迅速进入生产环境。

安全团队也开始频繁遭遇“影子 IaC”问题。在未经批准的工作流之外使用 AI 工具来生成和部署基础设施，会出现一些难以察觉的环境。

AI 的独特之处在于速度。 错误的配置不再需要数月的手动更改才能覆盖整个环境。一个存在缺陷的 AI 生成的模板，在察觉到其存在问题之前，可能已被复制到数百项资源中，并被反复使用。

同样的原则也适用于执行安全措施。 Tenable 由 AI 提供支持的漏洞优先级评级 (VPR) 将 CVSS 标记为“严重”或“高危”的 CVE 比例从 60% 缩小至 1.6%，且这些漏洞会对企业造成真正的业务风险。

在 IaC 环境中应用这种优先级排序方式，意味着团队无需再对无用信息进行分类，而是专注于可能会被实际利用的错误配置。

安全专业人士正在利用基于 AI 的云安全态势管理、策略即代码实践以及自动化验证工具来应对这些威胁。

上下文感知型 AI 防护机制可以直接在开发人员的工作流中强制执行最小特权原则、允许的资源类型、命名规范、加密策略以及企业策略。因此，安全的默认设置是阻力最小的路径。

代理式 AI 令这些控制措施变得更加重要。 

自主系统无需人工逐一审批，即可预配基础设施、修改云环境并执行工作流。 这意味着，团队必须从一开始就将治理机制嵌入开发和部署流程中，而不是亡羊补牢。

随着前沿 AI 模型逐渐具备自主部署基础设施和执行云运维的能力，企业的治理政策可能会落后于发展步伐，而任何手动流程都难以及时弥补这一差距。

治理政策必须与无需等待人工批准即可运行的系统保持同步。

AI 可以令风险规模化，同样也能使安全防护规模化。区别在于，安全策略是从一开始就融入开发流程，还是一种事后补救。

要以机器的速度治理云基础设施，需要从一开始就将安全策略融入到整个流程中。 Tenable 将 IaC 安全视为更广泛的暴露风险管理策略的一部分。

Tenable One Cloud Exposure 会在部署前对 IaC 模板进行扫描，识别 Terraform、CloudFormation、Kubernetes、Ansible 及其他常见格式中的配置错误。

Tenable One Cloud Exposure 会根据已批准的基准，持续监控实时云环境，并立即检测配置漂移。 随后，Tenable 由 AI 提供支持的漏洞优先级评级 (VPR) 会进一步缩小需关注项目的范围，将 CVSS 标记为“严重”或“高危”的 CVE 比例从 60% 缩小至 1.6%，且这些漏洞会对企业造成真正的业务风险。

策略即代码的执行机制会覆盖 AWS、Azure 和 Google Cloud，无需人工审核周期即可确保始终合规。

Tenable One 平台会将每个 IaC 配置错误与相关的攻击路径、身份和资产进行关联。 团队可以了解哪些暴露风险需要立即采取行动，哪些可以暂缓处理。

该平台涵盖的内容远不止于个别发现结果。 Tenable 不仅会标记云配置错误，还会分析该暴露风险如何与更广泛的攻击路径、身份、权限以及关键资产相关联。

随着企业采用 AI 提供支持的开发工作流并管理日益扩大的云环境，此类上下文信息比以往任何时候都更为重要。 企业需要了解哪些暴露风险代表真正的业务风险，哪些暴露风险需要立即响应并进行修复。

Tenable One 暴露风险安全管理平台可以将 IaC 发现结果与漏洞数据、云资产信息、身份暴露风险洞察以及攻击路径分析进行关联，从而全面掌握风险状况。 

当安全团队需要进行暴露风险评估，并将发现结果与实际业务影响关联起来时，Tenable One 可提供统一的视图，帮助团队采取相应行动。

Tenable 还通过 API 和 CI/CD 管道集成支持 DevSecOps 集成，这样安全验证便自然而然地融入了现代化开发工作流。

大多数 IaC 配置错误并非表示复杂的攻击。 这些错误因疏忽而致。 测试时遗留的宽松配置、没人删除的硬编码凭据、在未经任何人检查前就被复制的模板。 单独来看，这些错误无足轻重。 在数百次部署中，这些错误累积成了攻击面。

在模板中发现这些错误，而不要等到它们呈现在数据外泄报告中。这正是 Tenable One 的设计初衷。

对于新入行和资深的安全专业人士而言，视企业的安全策略、技术堆栈和能力不同，基础设施即代码可能会带来大量问题。 让我们回顾一些最常见的问题，帮助您理解某些基础知识，无论您目前处于安全运营的哪个阶段。

什么是基础设施即代码 (IaC)？

基础设施即代码 (IaC) 是一种通过机器可读的配置文件来管理和预配计算基础设施（服务器、网络、数据库、负载均衡器等）的实践，而非通过手动点击控制台或运行一次性命令来完成。常见示例包括 Terraform、CloudFormation、Kubernetes 清单和 Ansible。

IaC 中最常见的安全风险有哪些？

大多数 IaC 安全问题都源于配置错误。如果无人及早发现，权限设置过宽、存储资源暴露、凭据硬编码、缺乏加密以及不安全的第三方模块等风险都可能潜入生产环境。

什么是云基础设施中的配置漂移？

当云环境随时间推移发生变化，且不再与构建该环境的 IaC 模板相符时，就会发生配置漂移。通常是手动更新、快速修复和一次性更改所致。

配置漂移如何造成安全漏洞？

漂移之所以成为问题，是因为已批准的配置不再能够体现实际情况。您可能以为系统是按某种方式配置的，但实际生产环境却大相径庭，从而产生了您从未预料且毫不知情的暴露风险。

什么是策略即代码 (PaC)？

策略即代码是指以机器可读形式实施的安全和合规策略，系统会在基础设施内自动执行这些策略。

策略即代码与传统的合规审查有何不同？ 

审计工作定期执行，且通常需要人工检查。 另一方面，策略即代码会持续对基础设施进行验证。

Tenable 支持哪些 IaC 格式和工具？

Tenable One Cloud Exposure 支持 Terraform、CloudFormation、Kubernetes 文件、Ansible 以及其他常见 IaC 工具。

左移安全如何应用于 IaC？

左移安全将 IaC 扫描整合到软件开发生命周期的最早阶段，从而让团队能够在配置错误进入生产环境之前及时发现并解决这些错误。

IaC 的配置错误是否会导致数据外泄？

是的，存储设置配置错误、权限过高的帐户、缺少安全控制措施以及开放的端口，都可能导致未经授权的访问和潜在的数据外泄。

Tenable 如何在实时环境中检测配置漂移？

Tenable 会持续扫描在线云资产，识别这些资产与已批准的基线配置之间的差异，并针对潜在的安全漏洞发出警报。