想象你要盖一栋三十层的写字楼。设计图上藏着一个致命错误：消防疏散通道被承重柱堵死了。如果没人发现，等楼体封顶、装修完工才暴露，返工成本将是天文数字；可如果在动工之前，有位经验丰富的审查工程师拿着放大镜，把图纸的每一根线条都核对一遍，就能用一杯咖啡的代价换来一栋安全的大楼。 云上世界的“盖楼”也是同样的道理。用 Terraform 写下的每一行代码，都是云基础设施的设计蓝图——它定义了虚拟机、存储桶、数据库、安全组。而 terraform apply 就是那个“动工”按钮，一按下去，几百台机器瞬间拉起。云上盖楼比现实快一万倍，出事的速度也快一万倍：安全组对公网全开、数据库没有加密、管理密码硬编码在代码里——这些隐患一旦上线，就像把金库大门的钥匙挂在门口。 本文要讲的，就是替你看住这张蓝图的“智能安检机”：用 tfsec、Checkov 等工具给代码做静态体检，用 Sentinel 和 OPA 把合规规范写成可执行的条文，把安检机搬进 CI/CD 流水线当门禁，再给状态文件上锁、给密钥换保险箱，最后用漂移检测和定期巡检守住长期安全。一句话：在“动工”之前发现问题，在“入住”之后持续巡查。

岗位关联

掌握 Terraform 安全扫描与合规检查，是 DevOps 与云安全工程师的必备技能。它能把“出事后救火”变成“上线前拦截”，是你简历上最有说服力的“安全左移”实战经验。

目录
  1. 可视化演示
  2. 安全扫描工具：图纸审查师的放大镜
  3. 合规策略编写：把建筑规范写成可执行的条文
  4. CI/CD 集成门禁：施工流水线上的质检站
  5. 密钥安全管理：保险箱与钥匙管理
  6. 风险修复闭环：从整改通知单到复查销号
  7. 持续合规审计：定期巡检与长期台账
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

\u5c55\u793a\u5bb9\u5668\u7f16\u6392\u7cfb\u7edf\u5c06Pod\u8c03\u5ea6\u5230\u5408\u9002\u8282\u70b9\u7684\u8fc7\u7a0b\uff0c\u6839\u636e\u8d44\u6e90\u5229\u7528\u7387\u548c\u8d1f\u8f7d\u5747\u8861\u7b56\u7565\u5206\u914d\u4efb\u52a1\u3002

本节配有交互动效（进入视口后自动加载，约 3KB）。

\u5bb9\u5668\u8c03\u5ea6 \u8fd0\u884c\u4e2dPod \u5f85\u8c03\u5ea6Pod LeastLoaded \u8d1f\u8f7d\u5747\u8861\u8c03\u5ea6\u7b56\u7565

安全扫描工具：图纸审查师的放大镜

工地开工前，最有经验的图纸审查师会把蓝图摊在桌上，拿放大镜逐条核对：承重墙厚度达标没有？消防通道有没有被堵死？这些问题在二维纸面上就能发现，根本不用等大楼封顶。Terraform 的静态安全扫描工具做的正是这件事——把 .tf 代码当成图纸，在云资源真正创建之前，逐行搜索危险配置。

市面上最常用的三把“放大镜”是 tfsec、Checkov 和 Terrascan。tfsec 专注 Terraform，规则贴近三大云厂商的常见配置陷阱，跑得最快；Checkov 覆盖面最广，除了 Terraform 还能扫 CloudFormation、Kubernetes YAML，社区规则库超过一千条；Terrascan 则强调与 CIS 等安全基准确立的一一映射，适合手里握着合规尺子的团队。

三把放大镜共享同一个“眼睛”——规则库。规则库是一份不断更新的危险模式清单，例如安全组放行 0.0.0.0/0、S3 桶开启 public-read、管理员密码硬编码。扫描器把代码解析成资源树，再拿每个节点与规则库比对，命中即生成一条 finding，附上严重度、位置和修复建议。

放大镜再精巧，也只能发现规范手册上写过的坑。所以老审查师的桌角总放着最新版规范——工具规则库要勤更新，否则新出现的攻击手法又会夹在图纸缝隙里溜过去。

RiskScore=S×E×A\text{RiskScore} = S \times E \times A
风险评分公式：扫描出的每条问题按“严重度 × 暴露面 × 资产价值”加权，得到优先级排序，分数最高的先修。
  1. 严重度 S（Severity）规则库为每类风险定一个 0 到 10 的基础分，公网全开这类高危问题通常打 9 分以上。
    S∈[0,10]S \in [0, 10]
  2. 暴露系数 E（Exposure）考虑资源是否暴露在公网，暴露面越大系数越高，公网可达取 1.0，仅内网取 0.3。
    E={1.0,公网可达0.3,仅内网E = \begin{cases} 1.0, & \text{公网可达} \\ 0.3, & \text{仅内网} \end{cases}
  3. 资产价值 A（Asset）被攻破后损失越大，权重越高，数据库、IAM 这类核心资产的 A 值更高。
    A=资产重要性权重A = \text{资产重要性权重}
  4. 综合评分三项相乘得到该条风险的综合分，扫描器按分值从高到低排序，指导团队先处理最危险的问题。
    RiskScore=S×E×A\text{RiskScore} = S \times E \times A

合规策略编写：把建筑规范写成可执行的条文

建筑行业有厚厚的规范书：消防通道宽度、承重墙厚度、电缆防火等级……但规范写得再全，如果只靠人脑记忆，不同审查员的判断就会五花八门。聪明的做法是把规范条文直接变成程序能读的代码，谁也别想打折扣。

在 Terraform 生态里，“可执行的条文”有两种主流写法。一种是 Terraform Cloud 内置的 Sentinel，用接近 HCL 的语法描述“这个资源必须满足某条件”，并提供 advisory（仅建议）、soft-mandatory（强制但可豁免）、hard-mandatory（不可豁免）三档执行模式。另一种是开源界的 OPA（Open Policy Agent），配套的 Rego 语言更通用，能横跨 Terraform、Kubernetes、微服务统一执行策略。

把合规写成代码（Policy as Code）后，规范就有了生命力：进版本仓库可评审、可回滚；每次改动都有记录；还能写单元测试验证策略本身。企业里常见的做法是维护一条“策略覆盖率”指标，防止扫描工具部署了，规范条款却长期没有跟进。

施工规范每隔几年要升版，合规策略库也需要有人持续维护。把规范变成代码只是第一步，让代码跟得上威胁的变化，才是长期功课。

Coverage=NcoveredNtotal×100%\text{Coverage} = \frac{N_{\text{covered}}}{N_{\text{total}}} \times 100\%
覆盖率公式：衡量“应该检查的点”有多少真正被写成了策略。覆盖率低，说明合规条文还没写全。
  1. 合规基线 \(N_{\text{total}}\)依据等保、ISO 或企业内规整理出的全部检查点数量，是分母。
    Ntotal=基线要求的检查点总数N_{\text{total}} = \text{基线要求的检查点总数}
  2. 已覆盖数 \(N_{\text{covered}}\)已经写进 Sentinel 或 OPA 策略的检查点数量，是分子。
    Ncovered=已策略化的检查点数N_{\text{covered}} = \text{已策略化的检查点数}
  3. 比例计算用已覆盖数除以基线总数，得到尚未落地的规范缺口。
    NcoveredNtotal\frac{N_{\text{covered}}}{N_{\text{total}}}
  4. 百分比化乘以 100% 得到覆盖率，管理层用这个数字判断合规建设进度。
    ×100%\times 100\%

CI/CD 集成门禁：施工流水线上的质检站

汽车工厂的流水线上，每个工位都有一道质检门：零件装歪了，机械臂直接把它拨下生产线，绝不让瑕疵车流到下一站。软件交付的 CI/CD 流水线也需要同样的门禁——扫描发现问题，构建直接失败，合并请求被毫不留情地拒绝。

具体做法是在 GitLab CI 或 GitHub Actions 里增加一个 job：拉取代码 → 运行 tfsec / Checkov → 把扫描结果映射为退出码。exit code 非 0 时 job 失败，流水线中断，merge request 无法合并，这就是“自动阻断”。关键点在于扫描必须放在 plan 甚至 apply 之前，让门禁成为部署的前置条件。

流水线还会把扫描报告上传到制品库或安全平台，自动关联工单系统，形成“发现问题—自动建单—追踪修复”的审计留痕。每一次扫描的结论都能追溯，这也是等保审计时最有力的证据链。

质检站不需要人站岗，但规则要设计得聪明：不是所有问题都一票否决，按严重度分级处理，才能既守住安全又不拖垮交付节奏。

Gate={阻断,Ccrit≥1审查,Chigh≥k放行,其他\text{Gate} = \begin{cases} \text{阻断}, & C_{\text{crit}} \ge 1 \\ \text{审查}, & C_{\text{high}} \ge k \\ \text{放行}, & \text{其他} \end{cases}
门禁判定公式：Critical 级别问题一票否决；High 级别达到阈值转人工审批；其余放行并留痕。分级处理比“一刀切”更贴近真实工程。
  1. 计数 Critical 问题统计本次扫描结果中严重度为 Critical 的数量，记为 \(C_{\text{crit}}\)。
    Ccrit=∑i=1n[severityi=Critical]C_{\text{crit}} = \sum_{i=1}^{n} [\text{severity}_i = \text{Critical}]
  2. 阻断分支只要存在 1 条及以上 Critical，门禁直接判定阻断，构建失败。
    Critical≥1⇒阻断\text{Critical} \ge 1 \Rightarrow \text{阻断}
  3. 审查分支没有 Critical 但 High 达到阈值 \(k\) 时，转人工审批而非直接失败。
    High≥k⇒审查\text{High} \ge k \Rightarrow \text{审查}
  4. 放行分支其余情况放行，同时把扫描报告归档留痕。
    其他⇒放行\text{其他} \Rightarrow \text{放行}

密钥安全管理：保险箱与钥匙管理

图纸审得再仔细，如果施工队把保险柜钥匙直接挂在工地围栏上，一切都白搭。Terraform 世界中最容易被忽略的“保险柜”是状态文件 terraform.tfstate——它会把所有资源的真实属性明文记录下来，包括数据库密码、访问密钥。

密钥管理的第一条军规：状态文件绝不放在本地磁盘裸奔。用 S3 或 GCS 作为远程后端并开启加密，配合版本控制和锁机制；第二，变量文件（*.tfvars）里的敏感值要改用环境变量或密钥管理工具（Vault、AWS Secrets Manager）注入；第三，在代码里用 sensitive = true 标记敏感变量，让 plan 的输出自动脱敏。

至于密钥本身的强度，可以借用信息论中的熵值来衡量。一个由随机大小写字母、数字、符号组成的密钥，字符种类越多、长度越长，熵越高，被暴力猜中的概率越低。

保险箱的价值不只是锁好，还包括“别让钥匙出现在不该出现的地方”。定期轮换密钥、扫描仓库历史提交中的泄露痕迹，才能让保险箱长期可靠。

H=−∑i=1npilog⁡2piH = -\sum_{i=1}^{n} p_i \log_2 p_i
熵公式：衡量密钥的“混乱程度”。熵越高，密钥越难被猜中；全数字短密码熵低，一碰就碎。
  1. 统计概率 \(p_i\)把密钥看作由若干字符类别（小写、大写、数字、符号）组成的字符串，先统计每类字符出现的概率。
    pi=niNp_i = \frac{n_i}{N}
  2. 计算信息量 \(\log_2 p_i\)概率越低的事件发生，携带的信息量越大；取以 2 为底的对数，正好把信息量量化为比特。
    log⁡2pi\log_2 p_i
  3. 加权求和取负把每个类别的概率与信息量相乘后全部加总，前面加负号让熵值为正。
    H=−∑i=1npilog⁡2piH = -\sum_{i=1}^{n} p_i \log_2 p_i
  4. 解读熵值纯数字 8 位密码熵约 26.6 比特，大小写数字符号混合的 16 位密码熵可超 100 比特，暴力破解难度是天壤之别。
    H≈26.6 vs H>100H \approx 26.6 \text{ vs } H > 100

风险修复闭环：从整改通知单到复查销号

安检机响了，接下来怎么办？工地上有一套成熟流程：审查员开出“整改通知单”，施工队限期整改，复查合格后销号归档。云上安全也一样，扫描出漏洞只是开始，把漏洞一个个修掉、确认不再复发，才算真正闭环。

常见的修复流程分三步：第一步确认分级——这条 finding 是真漏洞还是误报；第二步修复——改代码、调配置，或者对确实可接受的残余风险做豁免（suppress）并备注原因；第三步复扫——合并改动后重新跑一遍扫描，确认同一条规则不再命中。

团队还会维护一份“安全基线”：哪些规则必须零告警、哪些允许带豁免清单，全部写进基线文档并纳入版本库。每次调整都有记录，防止有人悄悄把高危规则豁免掉。用平均修复时长（MTTR）衡量团队响应速度。

整改通知单最怕“烂尾”。把修复率和 MTTR 挂上 dashboard 每周过一遍，闭环才不会变成墙上的口号。

MTTR=TfixedNfixed\text{MTTR} = \frac{T_{\text{fixed}}}{N_{\text{fixed}}}
平均修复时长：统计周期内修复所有漏洞消耗的总时间除以漏洞数量。MTTR 越短，说明响应越敏捷。
  1. 累计修复时长 \(T_{\text{fixed}}\)统计周期内从漏洞发现到修复完成的总时长，单位通常为小时。
    Tfixed=∑j=1m(tresolve,j−tfound,j)T_{\text{fixed}} = \sum_{j=1}^{m} (t_{\text{resolve},j} - t_{\text{found},j})
  2. 修复数量 \(N_{\text{fixed}}\)同一周期内确认销号的漏洞总数。
    Nfixed=已关闭的 finding 数量N_{\text{fixed}} = \text{已关闭的 finding 数量}
  3. 平均修复时长总时长除以数量，得到每个漏洞的平均修复耗时。
    MTTR=TfixedNfixed\text{MTTR} = \frac{T_{\text{fixed}}}{N_{\text{fixed}}}
  4. 趋势解读MTTR 持续下降，说明团队的安全响应机制在变好，门禁的价值才真正体现出来。

持续合规审计：定期巡检与长期台账

大楼交付入住后，消防员并不会就此离开——他们每隔半年上门巡检，检查灭火器压力、安全通道是否被杂物堵住。云上世界也一样，代码部署之后，真实环境会悄悄“漂移”：有人在控制台手动改了安全组，或者某次操作给存储桶加了公共权限。

漂移检测就是把“期望状态”（Terraform 代码描述的）和“实际状态”（云上真实存在的）做对比，发现不一致就告警。Terraform 的 plan 命令天然是一台漂移探测器，配合定时任务的自动执行，就能实现无人值守的定期巡检。

每次巡检的结论会汇总成合规报告：总资源数、通过项、漂移项、风险项，以及本轮新增修复的漏洞。数据沉淀成月度台账，管理层一眼看清安全趋势，审计机构来了也能直接提供证据链。

长期台账的意义在于“趋势比快照更有价值”。单看某一天全绿说明不了问题，连续三个月漂移率下降、MTTR 缩短，才说明这套安全机制真正在起作用——工地巡检员终于可以放心地把记录本合上了。

ComplianceRate=Npass−NdriftNtotal×100%\text{ComplianceRate} = \frac{N_{\text{pass}} - N_{\text{drift}}}{N_{\text{total}}} \times 100\%
合规率公式：通过项扣除漂移项后除以资源总数。漂移越多，合规率越低，安全水位一目了然。
  1. 通过项 \(N_{\text{pass}}\)巡检中满足全部策略的资源数量。
    Npass=合规资源数N_{\text{pass}} = \text{合规资源数}
  2. 漂移项 \(N_{\text{drift}}\)实际配置与代码期望不一致的资源数，漂移往往意味着未登记的风险变更。
    Ndrift=漂移资源数N_{\text{drift}} = \text{漂移资源数}
  3. 差值比总量通过项扣除漂移项后除以资源总数，漂移越多合规率越低。
    Npass−NdriftNtotal\frac{N_{\text{pass}} - N_{\text{drift}}}{N_{\text{total}}}
  4. 百分比化乘以 100% 得到管理层习惯阅读的百分比指标，作为月度复盘的核心数字。
    ×100%\times 100\%

AI 应用场景

存量云资产大体检（迁移前扫描）

阶段：安全左移、存量代码评估

解决的问题：团队接手维护多年的 Terraform 仓库，几百个 .tf 文件散落各分支。人工逐行审计要数周且极易遗漏，堪称“在成堆旧图纸里找隐患”。用 Checkov 对全仓库批量扫描，几分钟就能生成按严重度排序的发现清单。

具体案例：某互联网金融公司迁移容器平台前，用 tfsec + Checkov 对 47 个仓库做存量扫描，发现 132 条高危配置和 8 处硬编码密钥，按风险分排序后一周内清空 90% 的 Critical 问题，迁移进度未被拖后腿。

DevSecOps 流水线自动门禁

阶段：CI/CD 持续集成

解决的问题：发布前依赖人工安全检查不可持续，往往流于形式。把扫描工具嵌进 GitLab CI 或 GitHub Actions，让每次 merge request 自动触发安检，Critical 级问题直接让流水线失败，把“上线后追责”变成“上线前拦截”。

具体案例：某电商平台大促预热期每天发版 20 次，安全门禁全自动运行，高危配置在合并阶段即被拦截，整个大促周期零新增高危资源上线，安全团队从“救火队长”变成“规则制定者”。

等保合规报告自动生成

阶段：合规审计与证据留存

解决的问题：等保 2.0 与 ISO 27001 审计需要制度、配置、证据三件套，手动截图拼报告费时费力还容易漏项。用 Sentinel 策略对全量资源执行合规检查，输出结构化报告，审计时直接导出证据链。

具体案例：某政务云项目按等保三级要求，用 OPA 策略统一检查所有 Terraform 配置，每月自动生成合规报告并归档到对象存储，配合漂移检测补充运行时证据，审计准备时间从两周压缩到一天。

Python 演示

python64 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""sim_tfsec.py - 简易 Terraform 安全检查模拟器""" import reimport sysfrom pathlib import Path RULES = [    {        "id": "AWS-SG-001",        "severity": 9,        "pattern": r"cidr_blocks\s*=\s*\[\"0\.0\.0\.0/0\"\]",        "message": "安全组对公网全量开放",    },    {        "id": "SECRET-001",        "severity": 10,        "pattern": r"(password|access_key|secret_key)\s*=\s*\"[^\"]+\"",        "message": "疑似硬编码密钥",    },    {        "id": "AWS-S3-002",        "severity": 7,        "pattern": r"acl\s*=\s*\"public-read\"",        "message": "存储桶公共读权限",    },]  def collect_tf_files(root):    return sorted(Path(root).rglob("*.tf"))  def scan_file(path):    findings = []    for rule in RULES:        for lineno, line in enumerate(path.read_text(encoding="utf-8").splitlines(), 1):            if re.search(rule["pattern"], line, re.IGNORECASE):                findings.append((rule["id"], rule["severity"], rule["message"], lineno))    return findings  def calculate_score(findings):    return sum(item[1] for item in findings)  def main():    root = sys.argv[1] if len(sys.argv) > 1 else "."    findings = []    for tf_file in collect_tf_files(root):        findings.extend(scan_file(tf_file))    findings.sort(key=lambda item: item[1], reverse=True)    for rule_id, sev, message, lineno in findings:        print("[%s] line=%d severity=%d %s" % (rule_id, lineno, sev, message))    score = calculate_score(findings)    passed = score < 20    print("-" * 48)    print("findings=%d risk_score=%d gate=%s" % (len(findings), score, "PASS" if passed else "BLOCK"))    return 0 if passed else 1  if __name__ == "__main__":    sys.exit(main())
目的：模拟 tfsec 的静态扫描原理——用规则库对 .tf 文件逐行正则匹配，输出风险清单并给出门禁判定（PASS / BLOCK）。在 CI 中运行该脚本，退出码即可驱动流水线阻断。
  1. RULES = [定义模拟规则库，相当于安检机的“违规清单”，每条含严重度与匹配模式。
  2. Path(root).rglob("*.tf")递归收集仓库中所有 Terraform 文件，对应安检流水线的“待检图纸入口”。
  3. for rule in RULES:外层循环遍历规则，每条规则都是一次模式匹配。
  4. re.search(rule["pattern"], line, re.IGNORECASE)用正则表达式在代码行中寻找违规特征，忽略大小写。
  5. findings.append(...)命中规则就记录一条 finding，包含规则 ID、严重度和行号。
  6. findings.sort(key=lambda item: item[1], reverse=True)按严重度从高到低排序，先展示最危险的问题。
  7. passed = score < 20门禁判定：风险分低于阈值才放行，否则返回非零退出码。
  8. sys.exit(main())退出码驱动 CI 行为：非零即构建失败，实现自动阻断。

常见误区

误区tfsec 或 Checkov 跑一遍零告警，就觉得云上基建固若金汤，可以放心大胆地点下 apply。

正解静态扫描像图纸审查，只能发现“规则库里写过的坑”。组合攻击、权限边界逻辑错误、运行时配置篡改都不会在静态扫描中暴露。安全是持续过程，必须叠加状态文件加密、漂移检测和人工代码评审，才能覆盖全生命周期。

为何常见：工具输出醒目的"0 vulnerabilities"带来强烈的完成感，让人误以为安全是一次性检查而非持续运营。

误区把密码放进 `terraform.tfvars` 就安全了，因为它不在源代码里，Git 仓库里看不到。

正解tfvars 和 tfstate 都以明文存储，状态文件会把所有资源属性（含 password）原样记录。若不加密后端存储、不限制访问权限，等于把保险柜钥匙贴在门上。正确做法是远程后端加密 + Vault/Secrets Manager 注入 + sensitive 标记脱敏。

为何常见：人们直觉认为“不在代码里”就安全，忽视了状态文件与变量文件同样是明文存放点。

误区把 Sentinel 全部设为 hard-mandatory，发现任何中低危就阻断构建，认为这才是对安全负责。

正解过度阻断会拖垮交付节奏，开发者被逼急了会用尽办法绕过门禁，合规反而变成形式主义。合理做法是分级门禁：Critical 阻断、High 阻断但允许豁免并留审计、Low 仅记录归档，在安全与效率之间找平衡。

为何常见：安全团队对“出事”的恐惧远大于对“阻塞”的厌恶，容易滑向极端僵化。

误区在 pipeline 里加一行 `tfsec` 命令，看到日志里有扫描输出，就觉得 DevSecOps 落地了。

正解没有“失败即阻断”的门禁，扫描命令只是摆设；job 退出码非零导致 merge 失败才是关键。同时还要做结果归档、工单关联、修复率追踪，形成完整闭环，否则扫描报告只会沉没在日志海里。

为何常见：复制粘贴文档命令很容易，但理解退出码、审批流与安全指标的联动需要整体设计，初学者往往只抄了表面。

面试题

Q1. 以下哪项是 Terraform 代码的静态安全扫描工具？

单选题 · easy

  • A.tfsec 静态扫描工具← 正确答案
  • B.GitLab Runner 执行器
  • C.Terraform 云平台组件
  • D.Kubernetes 集群管理

答案：A。tfsec 是专为 Terraform 设计的静态扫描工具，相当于“图纸审查师的放大镜”；GitLab Runner 是流水线执行器，Terraform Cloud 是托管平台，Kubernetes 是容器编排系统，三者都不是安全扫描器。

Q2. Terraform 状态文件（terraform.tfstate）的主要安全隐患是什么？

单选题 · easy

  • A.只包含元数据没有风险
  • B.仅影响本地文件大小
  • C.保存明文敏感属性值← 正确答案
  • D.会自动加密上传云端

答案：C。状态文件会明文记录所有资源的真实属性，包括数据库密码和访问密钥，就像保险箱的钥匙被贴在门上。它不是纯元数据，也不会自动加密，必须主动配置后端加密存储。

Q3. Sentinel 策略在 Terraform Cloud 中的强制模式是哪一组？

单选题 · mid

  • A.allow/deny/ignore 三值模式
  • B.advisory 与 soft/hard 强制模式← 正确答案
  • C.pass/fail/skip 判定模式
  • D.audit/enforce/monitor 模式

答案：B。Sentinel 提供 advisory（仅建议）、soft-mandatory（强制但可豁免）、hard-mandatory（不可豁免）三档。类比建筑规范的“推荐条款、一般强制、绝对红线”。其余选项是其他策略引擎的术语，不是 Sentinel 的表达方式。

Q4. 以下哪些属于常见的 Terraform 安全扫描工具？

多选题 · mid

  • A.Checkov 扫描工具← 正确答案
  • B.tfsec 扫描工具← 正确答案
  • C.Ansible 配置工具
  • D.Terrascan 扫描工具← 正确答案

答案：ABD。Checkov、tfsec、Terrascan 都是主流 IaC 静态扫描器，对应不同品牌的“放大镜”。Ansible 是配置管理工具，负责“施工”而不是“审图”，不属于安全扫描工具。

Q5. 在 CI/CD 流水线中实现“合规门禁”的正确做法是？

单选题 · mid

  • A.仅输出日志供人工查看
  • B.每月末执行一次批量扫描
  • C.高危存在则阻断合并门禁← 正确答案
  • D.部署完成后再执行扫描

答案：C。门禁的精髓是“失败即阻断”：扫描 job 返回非零退出码，流水线中断、合并被拒，就像质检站把瑕疵车拨下生产线。仅输出日志、月末扫描或部署后再扫都错过了最关键的拦截时机。

Q6. 以下哪些措施能有效降低 Terraform 密钥泄露风险？

多选题 · mid

  • A.后端加密存储状态文件← 正确答案
  • B.密钥工具注入敏感变量← 正确答案
  • C.密钥明文写入 tfvars 文件
  • D.变量标记敏感自动脱敏← 正确答案

答案：ABD。后端加密、Vault/Secrets Manager 注入变量、用 sensitive 标记脱敏，都是把钥匙收进保险箱的做法。把密钥明文写进 tfvars 并提交仓库，恰恰是最常见的泄露途径，属于反面操作。

Q7. 关于 Sentinel 与 OPA 的对比，下列说法正确的是？

单选题 · hard

  • A.OPA 仅支持 AWS 一种云
  • B.二者均无法集成 Terraform
  • C.Sentinel 是开源免费的引擎
  • D.Sentinel 用 HCL 语法← 正确答案

答案：D。Sentinel 采用 HCL 风格语法，随 Terraform Cloud 提供，并非开源免费；OPA 用 Rego 语言，开源且支持多云与微服务。二者都能与 Terraform 集成，OPA 也不限于任何单一云厂商。

Q8. 某团队设计分级门禁策略时，以下哪几项是合理规则？

多选题 · extreme

  • A.Critical 级问题直接阻断← 正确答案
  • B.High 级问题豁免需审计← 正确答案
  • C.Low 级问题放行并记录← 正确答案
  • D.所有级别一律强制阻断

答案：ABC。分级门禁符合工程实际：Critical 一票否决，High 可带豁免但必须审计，Low 记录归档即可。全部阻断会拖垮交付节奏，迫使开发者绕过门禁，反而让合规流于形式，因此 D 不合理。

Q9. Terraform 中的“漂移检测”指的是什么？

单选题 · easy

  • A.状态文件意外丢失损坏
  • B.实际资源与期望状态不一致← 正确答案
  • C.云账单金额出现异常上涨
  • D.代码仓库发生合并冲突

答案：B。漂移是实际云资源状态与 Terraform 代码描述的期望状态不一致，例如有人在控制台手动改了安全组。plan 命令天然能发现漂移，就像巡检员发现消防通道被杂物堵住。

Q10. 把合规策略写成代码（Policy as Code）的核心好处是？

单选题 · easy

  • A.策略可版本化复用
  • B.可消除所有安全风险
  • C.无需再编写测试代码← 正确答案
  • D.无需任何人工评审

答案：C。策略代码化让规范进入版本仓库，可评审、可回滚、可复用，像建筑条文有了统一打印版本。但它不能消除所有风险，策略本身仍需测试，关键变更依然要人工评审，后三个选项都是过度承诺。