如何用Claude自动化阿里云安全组规则治理

简而言之： 把安全组规则导出来，连同你想要的策略一起交给Claude，拿回一份按严重程度排序的清单：过度放行、无人需要、重复遮蔽、以及环境之间漂移的规则，并以可复核的差异形式呈现。这覆盖了这件事的前百分之八十。而"应用变更"这一步仍然要走人工审批和变更记录——一个对生产环境安全组有写权限的AI代理，不是该建的形状。

没人会计划让一个安全组最后攒到四十条规则。它是一个又一个紧急的周五攒出来的：一个供应商需要访问、一个外包在排查什么、一个监控工具够不到某个端口。每一条规则在被加上的那天都合情合理。两年之后，没人说得清哪些还需要，而那条叫"test-rule-3"的规则，已经比三位可能知道它是干什么的人待得更久。

这件事持续存在的原因不是疏忽。手工复核规则是一项真正枯燥、又没有可见回报的工作，它要求你一次性把整个资产装进脑子里，而在每一个具体的决策点上，感觉最安全的动作都是"别动这条"。于是规则越攒越多，攻击面在悄悄变大。

这恰恰是语言模型真正擅长的那类问题：读一份庞大的结构化导出、把它对照一份你用大白话写下来的策略、然后产出一份具体而有序的"看起来不对"的清单。它不擅长的是判断"关掉这个端口会不会弄坏生产"，而这正是"应用"那一半仍然属于人的原因。

安全组为什么会腐化

到处都是同样的模式，而把它们叫出名字就完成了一半的工作。

临时规则变成永久规则。 为一次迁移、一次厂商演示或一次排障开的访问权，从来没被关掉，因为关掉它没有期限、也没有人负责。

全世界都能到达一个管理端口。 SSH或RDP上出现0.0.0.0/0这样的来源范围，是最常见的严重发现，而它通常是某人为了快点把自己放行、并打算"回头再收紧"的结果。

规则没有主人、也没有到期。 那个本可以解释这条规则的字段是可选的，所以它是空的。而且没有任何机制会在某一天问一句"这条还需要吗？"

环境之间会漂移。 预发布环境是十八个月前从生产克隆出来的，此后两边各自演化，而没人比对过——常见的情况是预发布带着更松的规则和同样的数据。

重复和被遮蔽的规则会堆积。 两条覆盖范围重叠的规则，其中一条永远不会生效，而两条都没人敢删，因为删掉的后果并不清楚。

把当前状态从阿里云里取出来

该导出什么，怎么导？

阿里云通过ECS的API、以及基于它的命令行工具暴露安全组清单——"列出安全组"和"查询单个安全组的规则"这两个动作就是你需要的，而具体的动作名和参数值得去查当前的API文档，而不是相信某段代码片段，因为这些是会演进的。

导出的东西要比规则本身更多。一条规则只有放在上下文里才可判断，所以请把安全组列表连同它们各自所属的VPC和地域、每个组的完整规则集，以及每个组上实际挂载了哪些实例，一起拉出来。最后这一项比听上去更重要：一个什么都没挂的宽松安全组，和一个正在保护数据库的同样宽松的安全组，是两个不同的问题。

在你运营的每一个地域上都做一遍。自然生长出来的资产里，几乎总有一个被遗忘的地域，里面还跑着东西；而一份只覆盖了"你会想到的那个地域"的复核，恰恰会漏掉那个有意思的发现。

分析这一趟需要哪些RAM权限？

只读，而这不是走形式。分析这一趟只需要查询安全组和实例，别无其他，所以它应该在一个改不了任何东西的RAM身份下运行。阿里云为ECS提供了符合这个需求的只读策略；请在RAM控制台里核对当前的策略名称和它们的确切范围，而不是凭记忆用一个名字。

除了良好卫生之外，这件事要紧还有两个理由。第一，一个只读凭据消除了整整一类事故——那种"本来只想生成报告的自动化最后改了东西"的事故；你最害怕的那件事变成了结构上不可能，而不只是"本意不是那样"。第二，它改变了你和审批这项工作的人之间的对话："一份只读导出、由人复核、由人应用"是一个容易批的方案，而"一个对防火墙有写权限的代理"不是，也不该是。

把这个凭据像对待任何其他生产密钥那样存放，并给它一个有效期。一个长期有效的AccessKey躺在某个脚本目录里，比这次复核会翻出来的大多数问题都更严重。

该让Claude找什么

四个能产出发现的问题

先说明你想要的策略——哪些端口可以对公网开放、管理访问可以接受哪些来源、你的各个环境本来应该长什么样——然后对照它去问。没有一份说明白的策略，模型就会套用泛泛的最佳实践，产出一堆你会跟它争的发现。

过度放行的来源。 任何放行了宽泛公网范围的规则，按"它后面是什么"排序。先是管理端口，然后是其余的，并且把每个组上挂载的实例名列出来，好让读的人判断严重程度。

看起来没有东西需要的规则。 对应不上任何你在跑的服务的端口、没有挂载任何实例的安全组、指向一个你早已停止合作的供应商的来源。模型提出，你来确认——它看不到你的流量。

重复和被遮蔽的规则。 范围重叠、其中一条让另一条变得无关紧要的情况。在四十条规则里靠手工找出来很枯燥，而对一个一次性读完全部的模型来说不值一提。

环境之间的漂移。 给它两份导出，问它有什么不同。这是那种没人会手工去做的检查，而令人意外的发现常常就在那里。

要一份差异，而不是一篇散文

输出格式决定了这件事会不会变成常规。一段描述你安全态势的散文是不可操作的，也没人会读第二遍。

请改为要求：每一条提议的变更占一行——哪个组、哪条规则、改成什么、为什么、以及一个严重程度。要求给出实现它的确切API调用或控制台操作，让复核的人是在检查一个具体动作，而不是在解读一条建议。并且明确要求每一项都附一句"影响半径"——如果这条改错了，什么会停止工作——因为那正是复核者真正需要的字段，也是模型不被要求就会跳过的那个。

把提议和分析分开放。一个正在审批变更的人，应该读到的是一份变更清单，而不是在一段解释里翻找它们。

一个周期性的治理闭环

五步，按这个顺序，每次都一样。

导出当前状态，按计划执行，而不是等谁想起来。分析，对照你说明白的策略。复核那份提议的差异，由人来做，凡是影响半径不清楚的一律打回。应用，走你正常的变更流程——和任何其他防火墙变更走同一条、同样的审批。记录改了什么、为什么、谁批的。

对一个经常变动的资产来说，每月做一次导出和分析是合理的节奏；对一个稳定的资产，每季度也说得过去。而比间隔更要紧的是这个闭环真的闭上：一份没人复核的分析比没有分析更糟，因为它制造出一条"工作已经做过"的书面痕迹。

AI辅助规则复核 vs 云原生配置工具 vs 托管安全服务

• 起步成本 — AI辅助复核胜出。一份导出、一段提示、一个下午。
• 理解你的意图 — AI辅助复核明显胜出。原生工具对照的是泛泛的最佳实践；一个模型可以对照你自己写下的策略，包括你刻意留下的那些例外。
• 持续、自动的评估 — 云原生配置工具胜出。它们不需要谁记得就会运行，而"需要谁记得"正是每一个手工流程的失败模式。
• 安全组之外的覆盖面 — 原生工具和托管服务都胜过一次性复核，后者只看得见你导出的那部分。
• 有人为结果负责 — 托管安全服务完胜。无论你的工程师忙不忙，复核都会发生，而且结果由别人负责。
• 能拿去审计的证据 — 托管服务胜出。一份带日期和审批链的报告是审计方接受的东西；一段聊天记录不是。

它们是叠加关系而不是竞争关系。对一个从没被复核过的资产来说，AI辅助的一趟是最快的清理方式；一个原生配置工具让它不再重新腐化；而当这套纪律需要在"大家都很忙"的情况下依然活着时，你买的就是托管服务。

哪些规则绝不能自动化掉

三条，而它们正是"治理"和"事故"之间的差别。

每一次变更都由人审批。 模型提出，一个有上下文的人来定。即使提议明显是对的，这条也成立，因为"明显是对的"恰恰是自动化做不了、而人做得了的那种判断。

每一次变更都留下记录。 改了什么、什么时候、谁批的、理由是什么。这是让下一次复核成为可能的东西，也是审计方会要的东西。

每一次变更都有回滚路径。 在应用之前，先知道原先的状态和怎么恢复它。把变更之前那份导出留着——它就是回滚方案。

以及贯穿这三条的那个立场：不要针对生产环境的安全组去搭一个自动应用的闭环。 一个能在没有人在路径上的情况下打开端口的代理，是你一开始那个问题的一个更新、也更糟的版本。"读取并提议"是形状；"应用"是一个决定。

把这件事做对：RAM凭据、变更控制，以及何时该让IT介入

有三件事值得刻意定下来。

第一，凭据。一个只读的RAM身份，范围收敛到分析所需，有明确的有效期，并且像任何其他生产密钥那样存放。如果同一套自动化以后需要应用变更，那是另一个身份、另一次审批、另一场对话——而不是把第一个的权限扩一扩。

第二，什么离开了你的环境。一份安全组导出就是一张你攻击面的地图：哪些端口开着、从哪里能进、保护着什么。这确实敏感，而它去了哪里值得一个决定，而不是一个习惯。请读一读你所用那个具体产品层级的数据处理与训练条款，而不是靠假设，因为商业版和企业版通常与消费级不同，条款也会变。出于同样的原因，我们在内部AI助手的中国数据驻留问题里讨论过的那些考量，在这里同样适用。

第三，当所有人都忙起来时，谁来负责这个闭环。这才是会衰减的那部分。防火墙规则的变更与调优、每月的差距分析、每季度的配置备份，恰恰是托管IT安全服务作为一项持续运转的纪律（而不是一个意愿）所覆盖的内容。我们的AI+支持服务帮你把这类自动化建在受治理的凭据和公司账号上；我们的托管IT支持则覆盖围绕它的权限生命周期。Brocent自2007年在北京创立以来，一直在亚洲提供托管IT与安全服务，总部位于新加坡，并自2016年起设有香港办公室。

常见问题

AI代理应该自动应用安全组变更吗？

不应该，至少不能对生产环境。失败模式不是"模型偶尔会错"——而是当它错的时候没人会注意到，因为记录上写着"变更已由一套流程而不是一个人批准并执行"。请把模型留在分析和提议上，并在任何会修改规则的动作前面，放一个人和一条变更记录。

分析这一趟到底需要哪些RAM权限？

读取权限，用于查询安全组、它们的规则，以及挂载在上面的实例，别无其他。阿里云发布了覆盖这一点的ECS只读策略；请在RAM控制台里核对当前的名称和范围，而不是从一篇文章里抄一个策略名。如果一份被提议的权限集里包含任何能修改的东西，那它就是这件事的错误权限集。

把规则集导出给AI工具会不会造成暴露？

这是一个真实的考量，因为那份导出描述的就是你的攻击面。请刻意地决定它：核对你所用层级的数据处理条款、优先选择商业版或企业版，并考虑在不破坏分析的前提下脱敏实例标识。对那些无法接受这一点的资产，同样的方法用一个自托管模型、或者一套脚本化的规则检查，也一样成立。

这应该多久跑一次？

对经常变动的资产每月一次，对稳定的资产每季度一次，以及在任何重大迁移或新环境上线之后立刻做一次。间隔本身没有"闭环是否闭上"重要——一份没人复核的导出提供不了任何保护，还制造出一条误导性的记录。

这和等保等审计要求怎么衔接？

"对网络访问控制做周期性复核并留存证据"，是包括中国等级保护制度在内的多种安全框架里常见的期待。这个闭环产出的那些东西——一份带日期的导出、一份成文的策略、一份被复核过的提议、一次审批和一条变更记录——正是审计方会要的证据形状。至于适用于你所定级别的具体要求，请与有资质的测评机构确认，而不要假设这样就满足了。

模型能告诉我们哪些规则实际在用吗？

仅凭规则集不能——它只能根据你描述的服务，告诉你哪些规则看起来不必要。真实的使用情况需要流量数据，那是另一个你得自己提供的来源。请把每一条"看起来没在用"的发现当作一个要去问懂这个系统的人的问题，而不是一个结论。

从哪里开始

挑一个地域和一个生产VPC。把安全组、它们的规则和挂载的实例导出来，用五句大白话写下你想要的策略，然后要求按"后面是什么"排序的过度放行规则清单。你会拿到一份不长的清单，其中大部分你认得，还有一些你不认得。先修那些对全世界开放的管理端口，走你正常的变更流程，并把那份导出留作回滚。然后决定下个月由谁再跑一次——因为一次性的清理，价值远低于一个不需要谁记得的闭环。如果你更希望这个闭环被妥善地负责起来，并带着审计会要的那条证据链，欢迎联系我们。