mcpField
I
iac-security

iac-security

github.com/vinayaklatthe安全17842 次安装19 周前更新
代码仓库

关于 iac-security

面向 Azure 基础设施即代码流水线安全规划与加固的技能，适用于使用 Bicep、ARM 或 Terraform 的团队。它将扫描、策略门禁、流水线身份和供应链控制纳入部署前流程。

主要功能

  1. 01配置 OIDC 流水线身份
  2. 02规划 IaC 与密钥扫描
  3. 03设置 Azure Policy 部署门禁
  4. 04强化 Bicep 与 Terraform 流程
  5. 05检测基础设施漂移

适用场景

  1. 01将流水线机密迁移到 OIDC 联合身份
  2. 02在 PR 阶段检查 IaC 配置
  3. 03部署前评估 Azure Policy 拒绝规则
  4. 04定期检测 Terraform 状态漂移

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/vinayaklatthe/microsoft-security-skills --skill iac-security

安装后在 Claude Code 中输入/iac-security确认已加载。

详细介绍

Azure 上的基础设施即代码安全

如今，大多数云安全漏洞都源于通过代码配置的基础设施存在错误配置。加固 IaC 流水线——包括 Bicep、ARM、Terraform 以及运行它们的 CI/CD——可以将安全防护前移到部署之前：在 PR 审查时发现错误配置，而不是等到三周后才在 Defender for Cloud 中发现问题。

适用场景

为 Azure 设计或加固 IaC 流水线（GitHub Actions / Azure DevOps / GitLab），包括扫描、策略即代码、流水线身份和供应链控制。

请勿将此技能用于单独的 K8s 准入控制（defender-for-containers）、通用 CI/CD 架构或应用层安全。

能力栈

层能力
流水线身份OIDC 联合（无需客户端密钥）、Workload Identities Premium
提交前 / PR 时扫描Microsoft Security DevOps (MSDO) Action / Extension；Bicep linter；tflint；checkov；trivy；密钥扫描
策略即代码门禁部署时以 Audit 和 Deny 模式使用 Azure Policy；通过 az policy what-if 进行 CI 评估，使用 Terraform azapi 进行策略预览
态势回连Defender for Cloud DevOps Security 连接器，连接到 GitHub / Azure DevOps
漂移检测Defender for Cloud；在定时 CI 中运行 Terraform plan；在 AKS 上使用 GitOps 控制器（Flux/ArgoCD）
供应链签名提交、依赖项审查、制品签名（Notation/cosign）、允许使用的模块注册表

方法

  1. 用 OIDC 联合身份替换流水线密钥。 每种现代 Azure CI 集成都支持联合工作负载身份：

    • GitHub Actions → Azure：在用户分配的 MI 上配置联合凭据；无需使用 AZURE_CREDENTIALS JSON 密钥。
    • Azure DevOps → Azure：使用 Workload Identity 联合身份服务连接。 将联合凭据固定到特定环境 / 分支 （environment:prod，而不是 repo:org/repo:*）。参见 entra-workload-identity。

  2. 限制流水线身份的权限范围。 为每条流水线配置服务主体 / MI，并在 RG / 资源范围内分配角色，而不是授予订阅 Owner 权限。使用部署堆栈（Bicep）控制影响范围。

  3. 采用 Microsoft Security DevOps (MSDO) Action / Extension。 集成多种开源扫描器（template-analyzer、checkov、terrascan、trivy、bandit、ESLint security），以及密钥扫描（CredScan）。只需一个集成点；发现严重问题时阻止 PR。

  4. Bicep 具体做法。

    • 在 CI 中使用 bicep build + bicep lint。
    • 使用模板规格共享模式，并对其进行版本管理。
    • 使用部署堆栈和 denySettings，防止人员在流水线之外修改堆栈资源。
    • 使用带签名模块的模块注册表（私有 ACR 或 Bicep 注册表）。

  5. Terraform 具体做法。

    • 加固后端：将状态存储在 Azure Storage 中，并配置专用终结点、Customer Lockbox + RBAC 范围限定、软删除 + 版本控制 + 锁定。
    • 固定提供程序版本（次要版本使用 ~>，安全关键的依赖项使用精确版本）。
    • 在 CI 中使用 tflint + checkov；tfsec 已弃用 — 已由 trivy 取代。
    • 将 terraform plan 产物发布到 PR，供审核者查看；Apply 需经批准后才能执行。
    • 通过定期运行 terraform plan 并与当前状态比对来检测漂移。

  6. 策略即代码门禁。 对不可妥协的控制项，将 Azure Policy 设为拒绝模式：

    • VM 不得配置公共 IP。
    • Storage / SQL / Key Vault 必须配置专用终结点。
    • 必须配置加密 + 诊断设置 + 标记。 在 CI 中运行 az deployment what-if（Bicep/ARM），或通过 Get-AzPolicyComplianceForResource 根据策略进行评估，以便在应用之前发现拒绝模式导致的失败。

  7. 密钥卫生。

    • 每次推送都运行 CredScan / GitHub Advanced Security 密钥扫描。
    • 不得在 .tfvars 或 parameters.json 中存放密钥 — 使用 Key Vault 引用 / GitHub Environments / 标记为机密的流水线变量组。
    • 阻止引入密钥的 PR（启用推送保护）。
    • 轮换任何历史泄露的密钥；清理 Git 历史很困难，应直接更换密钥。

  8. 供应链。

    • 尽可能按摘要固定模块版本（Bicep 注册表摘要、固定 GitHub Action 的 SHA）。
    • 允许的注册表：在订阅上使用 Azure Policy，将容器 / Bicep 模块限制在私有注册表中。
    • 签名产物：使用 Notation / cosign 为容器映像签名；在 AKS 的准入控制中验证（defender-for-containers）。

  9. Defender for Cloud DevOps Security。 将 GitHub / Azure DevOps 连接到 Defender for Cloud：

    • 将 IaC 发现、密钥扫描结果、代码扫描结果和依赖项漏洞汇总到 Defender for Cloud 的统一视图中。
    • 标记、所有权和优先级管理方式与云发现项相同。
    • 按仓库 / 流水线跟踪安全态势趋势。

  10. 漂移检测。 即便采用策略 + IaC，仍会发生漂移（人员操作、ClickOps）。 检测方式：

    • 使用 Defender for Cloud 检查非流水线创建的资源所产生的安全态势发现项。
    • 定期运行 Terraform plan 作业，并对非空差异发出警报。
    • 使用 GitOps（Flux/ArgoCD）对 AKS 集群进行协调，并针对协调情况发出警报。

防护措施

  • 不要将云凭据存储为长期有效的流水线密钥。 始终使用 OIDC 联合。
  • 不要以订阅所有者身份运行流水线。 严格限制范围；使用部署堆栈进行隔离。
  • 成熟后，只有 critical 级别问题才会导致 PR 失败，标准过于宽松。 基线噪声调整完成后，将阈值提高到中危及以上。
  • Bicep what-if 不是安全审查。 它会显示变更；安全审查则需要解读这些变更。
  • Terraform 状态文件以明文形式包含密钥。 必须加固后端存储。
  • 不要让 provider "azurerm" { ... features {} } 在各流水线中漂移，且不固定版本。 可复现性就是安全性。
  • 仅使用 Audit 模式的 Azure Policy 有必要，但还不够。 关键控制措施需要 Deny。
  • 没有必需审阅者的分支保护，无法管控 IaC 合并。 必须落实人工审查。
  • MSDO 不能取代各语言的代码检查工具。 应分层使用。
  • Defender DevOps Security 需要连接器，而且每个仓库都需要一位负责人。 否则发现的问题会被搁置。

常见反模式

  • “在 GitHub Actions 中使用服务主体客户端密钥” — 这是大多数流水线泄露事件的根源。
  • “为流水线 SP 授予订阅范围的 Contributor 权限” — 一个失误就可能导致整个订阅中断。
  • “跳过 what-if；先部署 Bicep，看看会出什么问题” — 未经预览就变更生产环境。
  • “Terraform 状态存放在默认存储帐户，且使用公共终结点” — 密钥暴露。
  • “因为‘我们有 CI 扫描’，所以禁用了推送保护” — 在 CI 发现之前，密钥仍会泄露到历史记录中。
  • “将操作固定到 @ main” — 供应链攻击会借此渗透。应固定到经验证的 SHA 或标签。
  • “Terraform 使用随机的提供程序版本” — 相同代码，不同结果。
  • “没有人负责处理 Defender DevOps Security 发现的问题” — 这与无人负责处理 Defender for Cloud 发现的问题如出一辙。
  • “为保持稳定，在生产环境中禁用 GitOps 协调” — 配置漂移会变得不可见。

示例提示词

  • 将我们所有 GitHub Actions Azure 部署中的客户端密钥服务主体迁移到 OIDC 联合，并固定环境主体。
  • 在 80 个仓库中推出 Microsoft Security DevOps，并在发现中危及以上级别的问题时阻止 PR。
  • 将 Azure DevOps 和 GitHub 组织连接到 Defender for Cloud DevOps Security，并建立逐仓库的负责人机制。
  • 加固 Terraform 后端存储：专用终结点、Customer Lockbox、RBAC、软删除。
  • 为 Landing Zone 的不可妥协要求编写 Azure Policy 拒绝模式策略，并在部署前的 PR 阶段进行评估。
  • 实施 Bicep 部署堆栈，并使用 denySettings 隔离生产环境的爆炸半径。
  • 配置漂移检测流水线：定期运行 Terraform plan、检查 Defender for Cloud 差异，并路由警报。
  • 加固供应链：将 GitHub Actions 固定到 SHA、在专用注册表中签署 Bicep 模块，并使用 cosign 对容器映像进行签名。

Microsoft Learn

评论

支持 Markdown