AI 威胁瞬息万变，防御措施应紧跟步伐。

近日，红帽的 Vincent Danen 指出，在 Mozilla 与 Anthropic 的合作中，AI 模型仅通过一次扫描就在 Firefox 中发现了 271 个真实存在的安全缺陷。既然 AI 能为防御者做到这一点，它同样也能为攻击者所用。正如 Danen 所言：“如果您的安全防护策略完全建立在‘软件不存在漏洞’这一假设之上，那么您的输局已定。” 

代码中的漏洞仅仅是入侵的切入点。真正的破坏发生在入侵之后：攻击者借助配置不当的网络、权限过高的凭据、长期未轮换的密钥，以及彼此盲目互信的服务进行横向渗透。任何补丁周期都无法跟上这种攻击节奏。这也凸显了企业全面实施“深度防御”的必要性：这是一种文化的转变，即默认假设入侵必然会发生，并将防护重心放在降低风险本身带来的影响上。 

这正是零信任的定义。首轮安全漏洞浪潮过后，后续还会有第二波、第三波漏洞冲击接踵而至。企业组织需要采用零信任原则，从单纯的预防转向对安全事件的遏制，在身份、密钥、网络分段以及各层级的策略中强制执行最小特权原则。面对 AI 驱动型威胁的高速演进，企业组织需要能够以同等速度自动执行的防护机制。 红帽 Ansible 自动化平台正是实现这一目标的关键助力。

AI 带来的攻击面转变

传统的漏洞扫描程序会标记潜在问题，然后交由人工进行分类处理。而 AI 已经将网络攻击商品化。如今的 AI 工具，本质上相当于将整个攻击团队的能力整合为一体，而成本仅仅是消耗一些词元。以往要发起 SolarWinds 之类破坏性极强的入侵事件，需要投入大量时间、具备深厚的专业知识，还需要一定运气才能完成；而现在借助 AI，心怀歹意的攻击者可以毫不费力地将跨平台的复杂漏洞串联利用，发起攻击。

这些看似微不足道的弱点日积月累，只会百害而无一利。例如：

• 登录页面允许过于频繁地重试密码
• 设置页面不会二次核验用户身份
• API 在用户注销过程中短暂暴露会话令牌

这些漏洞单独来看都不算过于危险。每一条单独列出时，都可能被归为“低优先级”并搁置在待办清单中，但一旦串联起来，攻击者就能暴力破解密码，在会话过期前劫持会话，并以管理员身份进入设置页面。三个不起眼的小漏洞，足以构成一次实质性的入侵。

这些高级 AI 模型能够编写、编译和执行漏洞利用代码，还会根据执行失败的返回结果反复优化攻击手段、重新发起尝试。企业组织固然可以借助这类能力快速发现并修复此前未知的漏洞，但令人不安的事实是，攻击者同样握有这把“利器”。正如 Danen 所言：“能帮助防御者找到漏洞的工具，必然也会帮助攻击者找到它们。”攻击者的技能门槛已大幅拉低。加快修补速度只是应对手段之一，还必须辅以坚实的防御体系。 

防御体系需要搭建一个自动化运维层

搭载 SELinux 的红帽企业 Linux 与红帽 OpenShift 已提供平台级强化，但仅靠这类平台防御还远远不够。例如，SELinux 无法判定谁有权限部署应用。当安全信息和事件管理（SIEM）系统在凌晨 3 点检测到暴力攻击时，容器隔离机制不会撤销数据库凭据。而自动化技术正好可以弥补这些缺陷，助力制定良好防御策略。 

运维变更（部署、补丁、网络重新配置、凭据轮换）会经由人员、脚本、管道和自动化工具执行。如果这些路径未经策略管控，那么平台强化只能抵御一类攻击，却会让另一类攻击有机可乘。 

NIST SP 800-207 提出了零信任架构（ZTA）蓝图，其核心是策略执行点（PEP）。大多数人将 PEP 视为过滤网络流量的防火墙或网关。但是，当团队部署应用、修补服务器以及更改网络配置时，这些操作并不经过防火墙，而是通过自动化流程完成。归根结底，零信任是一种需要依托自动化技术才能大规模实施的运维规范。

以 Ansible 自动化平台为策略执行点

当 Ansible 自动化平台充当 PEP 时，每个运维操作都会经过该平台，以检查身份、评估策略、管理机密并记录结果。这些不是高级功能，而是零信任架构所要求的最低可行控制措施。运维人员永远不会直接触及目标系统，相关操作由 Ansible Playbook 执行，而且 Playbook 仅会在平台确认运维人员具备对应操作权限后才会启动运行。

该架构的优势在于“集中管控，分布执行”。策略决策在单一控制平面完成，而策略执行则在自动化所覆盖的任何位置进行。运维人员无法直接连接服务器，也不能从笔记本电脑运行脚本，从而显著降低了“牛仔式工程”和不可追溯的配置偏移风险。这也有效解决了凭据泛滥、影子自动化以及无管控横向移动等反模式问题。

该架构还通过消除易受攻击的本地端点上的高特权生产凭据，有效缓解了关键安全漏洞。自动化平台作为单一控制点，每次变更都附带身份信息、策略审批以及审计记录。 

Ansible 自动化平台可以通过双环执行模型来实现这一点。外环在平台层级运行。在作业模板启动之前，Ansible 自动化平台会通过内置的策略执行功能，向开放策略代理（OPA）服务器发起校验，同时提交完整的作业上下文信息：操作者身份、所属团队以及待运行的模板。 

图 1 基于 Ansible 自动化平台的内外环策略执行架构

OPA 根据策略对请求进行评估，并返回允许或拒绝指令。如果外环判定为拒绝，则 Playbook 不会执行。OPA 策略会将团队成员身份映射到允许的模板类别。

package aap.gateway
import rego.v1
default decision := {"allowed": true, "violations": []}
patching_teams := {"Infrastructure", "Security"}
network_teams := {"Infrastructure"}
app_teams := {"Applications", "DevOps"}
user_teams := {name | name := input.created_by.teams[_].name}
decision := {
    "allowed": false,
    "violations": [sprintf(
        "user '%s' is not in an authorised team for patching templates (requires: %v, has: %v)",
        [input.created_by.username, patching_teams, user_teams],
    )],
} if {
    not input.created_by.is_superuser
    is_patching_template
    not team_match(patching_teams)
}

图 2 策略即代码检查的 Rego 策略示例

内环在模板/工作流内部运行。对于 VLAN 更改等潜在的高影响操作，Playbook 会获取 SPIFFE 身份（一种加密工作负载身份）并将其发送到 OPA。OPA 会评估三个条件： 

• 操作人员通过团队成员身份获得授权
• 工作负载通过 SPIFFE 可验证身份确认为合法
• 请求的更改在批准的范围内

三个条件必须全部通过。

图 3 Ansible 自动化平台的多策略执行示例

这对于防范 AI 驱动的攻击至关重要，因为攻击链会在策略执行点被切断，而不是等到漏洞层面才处置。即便 AI 代理串联多个漏洞成功侵入服务器，也会被困在数据平面；在该平面，网络微分段、短期凭据等零信任策略会彻底切断其外部访问路径与横向移动能力。它无法滥用您的部署环境来推送恶意应用，也无法在不经过 Ansible 自动化平台的情况下更改企业网络策略。一旦检测到本地系统遭到入侵，Ansible 自动化平台内置的事件驱动的 Ansible 可以自动隔离系统，并即时向安全防护团队提供相关上下文信息。

窃取的用户凭据无法通过 SPIFFE 检查，因为工作负载身份不匹配。遭入侵的自动化节点也无法通过团队成员身份检查，因为攻击者无法控制用户在 Ansible 自动化平台中的会话。内外两环相互独立，攻破其中一环并不足以突破整体防线。这就是深度防御的实际体现。

利用动态凭据和微分段缩小潜在影响范围

即使在自动化层实施了策略，凭据与网络路径依然是可被利用的攻击面。如果数据库密码每月轮换一次，那么攻击者一旦获取访问权限，就拥有长达一个月的攻击窗口期。如果应用层与数据库层之间的网络访问控制列表（ACL）始终处于开放状态，那么这条路径将始终可用。

当应用部署工作流运行时，Ansible 自动化平台能够从 HashiCorp Vault 请求动态数据库凭据，这是一个作用域仅限应用架构的 PostgresSQL 角色，其生存时间（TTL）为 5 分钟。该凭据仅在部署窗口期内有效。TTL 到期后，角色即被删除。由于不存在持久性的凭据，攻击者也就无密可窃。

在同一工作流中，Ansible 自动化平台还会配置网络，打开一个 ACL 条目，以允许从应用的 IP 地址到数据库端口的流量。

面对 AI 发起的攻击链，这一机制彻底改变了攻防局面。即便攻击工具串联多个漏洞并成功渗透到数据库层，也只会发现凭据早在 4 分钟前就已过期。可利用的攻击窗口期从“等到人工下次轮换密码”的数月时长，直接压缩到“直到自动化任务完成”的短短数分钟，而且在生产环境中运行应用时，vault 代理将负责后续的凭据生命周期管理。

以机器级速度响应事件

如果 AI 代理能够自动生成漏洞利用代码并将其串联成攻击链，那么仅依靠安全防护运维中心（SOC）分析师接收通知、登录系统、读取警报、开展调查，再手动撤销凭据，就相当于以人类的反应速度去对抗数字化威胁。

事件驱动的 Ansible 有助于弥合这一差距。当 Splunk 之类的 SIEM 系统检测到针对应用身份验证端点的暴力破解行为后，可通过事件流向事件驱动的 Ansible 触发警报；事件驱动的 Ansible 则会评估事件，并启动自动化作业以采取行动。此作业会调用 HashiCorp Vault 的 API，以撤销应用持有的每个有效动态数据库租约。应用随即便失去数据库连接。

—  
  name: Splunk Brute-Force credential revocation
  hosts: all
  sources:
    - ansible.eda.webhook:
        host: 0.0.0.0
        port: 5000
  rules:
    - name: Revoke credentials on SSH brute-force detection
      condition: event.payload.search_name is search("SSH Brute Force Detected")
      action:
        run_job_template:
          name: "Emergency: Revoke App Credentials"
          organization: Default

图 4 针对 Splunk 中暴力破解事件的事件驱动的 Ansible Rulebook 示例
 

从检测到遏制的闭环在数秒内即可完成，将解决问题的平均时间从几小时缩短到几秒。潜在影响也从“攻击者可能获得数据库访问权限”降为“攻击者可以访问应用，但该应用已无法连接到其数据”。

图 5 基于事件驱动的 Ansible 的零信任架构攻击事件响应示例
 

这是一种自动化遏制机制，后续可衔接手动恢复流程。事件驱动的 Ansible 无需人工审批即可撤销凭据，因为撤销是一种安全的默认操作，即应用停止提供数据，但不会造成任何破坏。而恢复则需要人工介入调查，确认威胁已解除，并启动恢复工作流以重新部署应用。之所以在恢复路径中设置检查点，是因为在系统遭到入侵后恢复访问权限，绝不应在未经人工调查的情况下自动执行。

多层防护，一体防御

随着 AI 辅助漏洞发现技术的普及，深度防御已势在必行。但如果没有自动化运维层的支撑，深度防御就会留下漏洞，从而成为机器级高速攻击的目标。

三层防护可填补这一漏洞，每一层会在 AI 攻击链的不同节点予以阻断：

• 平台强化（编译器标志、SELinux、容器隔离、地址空间布局随机化（ASLR））可提升初始漏洞的利用难度。即便 AI 模型发现了漏洞，经强化的平台也会迫使攻击者必须构建多步攻击链才能实现代码执行。
• 基于 Ansible 自动化平台的策略执行可阻止未经授权的运维路径。即便攻击链成功突破，攻击者也无法在不经过自动化控制平面的情况下部署、修补、重新配置或访问机密。仅凭窃取的凭据远远不够。
• 基于事件驱动的 Ansible 的自动响应有助于在攻击者开始横向移动前遏制入侵事件。从检测到遏制只需几秒，其速度与 AI 驱动的攻击相当，这是人工干预响应所无法企及的。

每一层防护都独立运行。平台强化不依赖于策略执行，策略执行也不依赖于自动响应。即便某一层失效，其余两层仍能限制破坏范围。这种独立性使安全防护团队能够将精力投入到战略性风险缓释工作，而不是疲于应对海量警报；同时，它也让企业组织能够放心采纳 AI 辅助运维，即便工具迭代速度超过了策略更新速度，安全护栏依然能稳定发挥作用。

大多数企业组织已完成平台强化，还有许多企业组织正在采用零信任原则。但是，鲜有企业组织能以应对当前威胁所需的速度，将策略执行与自动化真正结合起来。这一差距，正是下一次入侵事件的突破口。将上述三层防护体系相结合，就能大幅强化防御能力，有效抵御 AI 驱动攻击带来的冲击。  

资源

• 网络培训课堂： 利用红帽 Ansible 自动化平台实施零信任
• 网络培训课堂： 实现安全防护自动化，与 ITOps 协调一致
• 电子书： 实现安全防护自动化，以确保与企业 IT 保持一致
• 电子书： 红帽 Ansible 自动化平台：入门指南
• 互动讲解： IT 自动化（含安全防护自动化）
• 网页： 安全防护自动化