tfsec 规则解析：用 azurerm_monitor_log_profile 的 categories 确保 Azure 日志配置文件捕获全部活动

应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载本篇技术指南以 tfsec 静态分析扫描器中的azure-monitor-capture-all-activities规则为主线讲解 Azure 活动日志配置文件azurerm_monitor_log_profile为何必须通过categories捕获全部三类活动事件并给出可复制的不安全/安全 Terraform 示例、参数取值说明以及 CLI 运行验证方法。读完本文后你将能够在自己的 Azure Terraform 代码中识别并修复日志配置文件未捕获全部活动的隐患并了解该规则在 tfsec 仓库中的文档组织与配套规则。规则概览azure-monitor-capture-all-activities是 tfsec 内置的 Azure Monitor 安全检查之一其官方检查文档位于 docs/checks/azure/monitor/capture-all-activities/index.md核心信息如下项目内容规则 IDazure-monitor-capture-all-activities默认严重级别medium中等适用资源azurerm_monitor_log_profile所属分类azure → monitor见 mkdocs.yml 与 docs/checks/azure/monitor/index.md核心检查点日志配置文件的categories列表必须完整覆盖所有活动类别在 tfsec 的文档导航中Azure monitor 分类下共包含三项配套规则它们共同构成活动日志完整审计的基线本规则正是其中之一capture-all-activities — 确保日志配置文件捕获全部活动capture-all-regions — 确保活动日志覆盖全部区域activity-log-retention-set — 确保活动日志保留期至少为一年。为什么捕获全部活动如此重要Azure 活动日志Activity Log记录订阅层面发生的控制平面事件是安全调查、合规审计和故障排查的首要数据来源。tfsec 对该规则的说明原文为Log profiles should capture all categories to ensure that all events are logged即日志配置文件Log Profile应当捕获所有类别以确保所有事件都被记录。规则给出的潜在影响Possible Impact则进一步强调Log profile must capture all activity to be able to ensure that all relevant information possible is available for an investigation如果日志配置文件只捕获部分类别意味着某些操作事件例如资源删除、配置写入或管理操作根本不会进入日志体系。当安全事件发生后进行溯源调查时缺失的事件记录将直接导致无法还原完整的攻击路径或操作轨迹——这正是一个 medium 级别问题的本质并非立刻造成破坏但会系统性削弱可观测性与事后取证能力。不安全的配置示例categories 为空列表以下配置会被azure-monitor-capture-all-activities规则判定为失败failresource azurerm_monitor_log_profile bad_example { name bad_example categories [] retention_policy { enabled true days 7 } }该示例的关键缺陷在于categories []categories是一个列表用于声明日志配置文件将要收集的活动类别空列表意味着不捕获任何类别的事件即使retention_policy已启用、也设置了保留天数日志体系仍然是空转状态从规则视角看凡是未能完整列出全部活动类别或列表为空的azurerm_monitor_log_profile资源都会被该规则标记为违规。这也是该规则与同组其他规则的显著区别activity-log-retention-set关注日志保留多久capture-all-regions关注覆盖哪些区域而本规则关注收集哪些类别的活动——三者分别对应日志审计的完整性、覆盖度与留存时长三个维度。安全的配置示例完整列出三类活动事件以下配置会通过passazure-monitor-capture-all-activities检查resource azurerm_monitor_log_profile good_example { name good_example categories [ Action, Delete, Write, ] retention_policy { enabled true days 365 } }与不安全示例对比安全配置的差异点集中在categories列表它完整列出了 Azure 活动日志的三类事件类别取值含义Action管理操作类事件如控制平面上的创建、更新等管理行为Delete删除操作事件记录资源的删除行为Write写入操作事件记录配置或状态发生变更的操作同时示例将retention_policy.days设为365保证事件至少保留一年便于应对延迟启动的调查这一点与同组的 activity-log-retention-set 规则建议一致。需要说明的是示例中categories的缩进使用 tab 不影响 Terraform 解析真正决定通过与否的是列表内容是否完整覆盖上述三类活动。categories 参数说明与取值建议categories是azurerm_monitor_log_profile资源的必填核心参数用于指定日志配置文件收集的活动类别集合。从 tfsec 的安全示例可以确认判定规则要求该列表完整包含 Action、Delete、Write 三个取值三个取值缺一不可只填[Action]或只填[Delete]均视为未捕获全部活动列表为空categories []属于最严重的缺失等同于关闭活动日志采集建议在编写 Azure 日志配置文件时将三个类别显式写出而不是依赖默认值或动态拼接——显式声明既能让 IaC 代码自文档化也能被 tfsec 这类静态扫描工具直接验证。若希望在代码层面同时满足完整审计目标应结合同组规则一并检查区域完整性locations需覆盖全部区域与global参考 capture-all-regions 文档中的安全示例该示例完整罗列了 eastus、westus、global 等全部可用区域保留时长retention_policy.days建议设为365及以上参考 activity-log-retention-set审计目的地日志配置文件通常配合诊断设置diagnostic settings将活动日志路由到存储账户、事件中心或 Log Analytics 工作区形成可检索的审计归档。在项目中运行并验证该规则tfsec 是一个面向 Terraform 代码的静态分析安全扫描器仓库站点描述见 mkdocs.yml无需云凭证即可对本地 HCL 代码执行扫描。针对本规则的典型使用方式如下# 无参数运行扫描当前目录下的 Terraform 代码输出默认 lovely 格式 tfsec # 只报告 MEDIUM 及以上严重级别的问题本规则默认级别为 medium tfsec --minimum-severity MEDIUM # 通过规则 ID 精确排除该规则例如临时豁免评估 tfsec -e azure-monitor-capture-all-activities # 将结果导出为 SARIF便于接入 CI 安全门禁 tfsec --format sarif --out tfsec.sarif # 同时展示通过检查的配置确认修复效果 tfsec --include-passed以上参数均来自仓库内的官方使用文档 docs/guides/usage.md 中的 CLI 参数表完整参数列表可通过tfsec --help查看。此外若希望将exclude、minimum_severity等规则固化到项目配置可参考配置文档 docs/guides/configuration/config.md若希望针对特定资源临时豁免本规则可参照忽略规则指南 docs/guides/configuration/ignores.md按规则 IDazure-monitor-capture-all-activities添加忽略标注需要注意tfsec 现已并入 Trivy 生态迁移路径可参考 tfsec-to-trivy-migration-guide.md 与 docs/guides/trivy.md。规则背后的仓库实现与文档结构从仓库源码与文档结构可以进一步理解该规则的来龙去脉文档导航mkdocs.yml的 Checks → azure → monitor 节点将本规则映射到checks/azure/monitor/capture-all-activities/index.md见 mkdocs.yml目录索引 docs/checks/azure/monitor/index.md 中给出了该规则的摘要描述 Ensure log profile captures all activities检查文档模板每个内置规则遵循统一的文档结构Explanation / Possible Impact / Suggested Resolution / Insecure Example / Secure Example / Links便于扫描结果与文档相互对照规则 ID 体系tfsec 的检查 ID 采用provider-service-checkname三段式命名如本规则的azure-monitor-capture-all-activities。仓库内的 internal/pkg/legacy/map.go 维护了旧版编号如AZU001、AZU002等到新规则 ID 的映射表用于--migrate-ignores迁移场景从该映射表的检索结果看monitor 系列规则未分配旧版 AZU 编号属于较新加入的规则因此在忽略标注、排除参数中应直接使用完整规则 ID检查实现载体本仓库基于github.com/aquasecurity/defsec规则引擎实现检查逻辑见 go.mod各云厂商规则与示例代码的对应关系可在文档目录docs/checks/下按 provider 分层查阅。小结azure-monitor-capture-all-activities规则解决的是一个看似简单、实则影响深远的问题Azure 日志配置文件必须完整列出Action、Delete、Write三类活动事件才能保证订阅层操作的全量可审计性。修复方式也极为直接——将空列表或残缺列表补齐为完整三类categories [ Action, Delete, Write, ]在落地实践时建议将本规则与同组的 capture-all-regions区域覆盖、activity-log-retention-set保留时长一起纳入 CI 扫描并用tfsec --include-passed验证修复效果从而构建一套完整的 Azure 活动日志审计基线。赞分享应用安全SASTIaC【免费下载链接】tfsecTfsec is now part of Trivy项目地址https://gitcode.com/gh_mirrors/tf/tfsec点击查看免费下载相关推荐tfsec 安全规则详解确保 Azure AKS 集群已配置向 Azure Monitor 发送容器日志azure-container-loggingtfsec 安全规则详解确保 Azure AKS 集群已配置向 Azure Monitor 发送容器日志azure container logging t应用安全SASTIaCtfsec 检查规则详解确保 Azure PostgreSQL 开启 connection_throttling 连接节流日志tfsec 检查规则详解确保 Azure PostgreSQL 开启 connection_throttling 连接节流日志 本文围绕 tfsec 内置的应用安全SASTIaCtfsec 检查项详解确保 Azure Monitor 活动日志保留期至少一年azure-monitor-activity-log-retention-settfsec 检查项详解确保 Azure Monitor 活动日志保留期至少一年azure monitor activity log retention se应用安全SASTIaC上一篇当AI学会组合技能如何用技能目录重塑你的工作方式下一篇300x300图像输入的奥秘tf_efficientnet_b3.ns_jft_in1k预处理流程全解析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考