如何全自动完成云平台工单提交从用户中心凭证到短信验证码闭环云平台工单看起来是一个网页表单问题真实做成全自动后它其实是一个跨系统的授权编排问题要能安全登录控制台要能读取用户中心里的凭证要能处理 MFA、短信验证码和滑块验证还要能在提交前把敏感信息放到正确边界里最后拿到工单号并回写证据。本文用一次真实的腾讯云安全事件工单提交为例拆解一个可复用的自动化方案。重点不是“怎么点网页”而是如何把凭证、验证码、浏览器状态、审计日志和人工确认边界组合成一个稳定流程。自动化目标一次完整的全自动工单提交至少要完成这些动作1从用户中心读取云平台账号凭证、MFA 秘钥和必要的联系人信息。2打开云平台控制台并完成登录包括密码、TOTP 和必要的账号安全设置。3进入工单系统选择产品分类和问题分类。4生成问题描述并按平台规则拆分公开描述、机密信息和附件。5如果平台要求验证联系方式发送短信验证码并从用户中心读取最新验证码。6如果出现滑块或拼图验证在获得用户授权后处理验证。7提交工单读取工单号、提交时间、提单账号、状态和详情页 URL。8把结果回写到运维日志或事故记录便于后续跟进。这套流程的价值在于把一次临时操作固化成“可重复执行的事故响应能力”。当服务器异常、供应商封禁、账号被拦截或云安全告警出现时系统可以快速把现场证据提交给云厂商而不是让人临时翻密码、等验证码、手动复制日志。系统边界建议把自动化拆成四层流程图 1每一层只负责自己的边界事件检测层负责收集事实不负责登录云平台。内容生成器负责把事实转成可提交的问题描述不读取密码或验证码。浏览器执行器负责页面操作但不持久保存凭证。用户中心负责保存凭证、MFA 秘钥和短信验证码并提供受控查询。结果回写层只保存工单号、状态和已提交摘要不保存一次性验证码。用户中心里需要保存什么用户中心不只是账号密码本。为了让工单提交闭环它需要支持几类数据数据用途保存建议控制台账号登录云平台控制台按平台、账号、所属人建档控制台密码自动登录加密保存禁止明文展示MFA TOTP 秘钥生成动态口令加密保存只在执行期解密云 API Secret查询实例、重启机器、读取云资源单独授权按最小权限发放手机号工单联系方式与账号所属人绑定短信验证码处理联系方式验证短期保存按来源和时间查询关键原则是凭证可以被自动化流程使用但不能被自动化流程随意输出。日志里最多记录“已读取凭证”“已生成 TOTP”“已匹配短信验证码”不要打印密码、SecretKey、MFA 秘钥或验证码原文。登录与 MFA云平台登录通常不是一次表单提交。更稳的做法是复用带登录态的浏览器同时保留完整登录能力1先打开目标控制台页面检查是否已登录。2如果跳转登录页从用户中心读取账号和密码。3如果要求 TOTP从用户中心读取 MFA 秘钥在本地执行器内生成当前 30 秒窗口验证码。4如果平台要求绑定 MFA必须先取得用户明确授权再把新 MFA 秘钥存入用户中心。5登录完成后不读取浏览器 cookie 或密码库只使用当前浏览器会话继续操作。这里的重点是“状态复用”和“凭证集中”。自动化不应该把云平台密码散落在脚本、环境变量或临时文件里也不应该为了方便直接导出浏览器会话。短信验证码闭环很多工单系统会要求补充或验证手机号。要做到自动化需要让短信进入用户中心例如通过短信同步服务、手机转发、运营商短信接收或已有的消息接入能力。执行流程可以这样设计1浏览器执行器在页面上点击“发送验证码”。2如果出现滑块验证先完成滑块再确认按钮进入倒计时。3等待用户中心出现同一手机号、同一平台、最近时间窗口内的新短信。4提取验证码只在内存中使用。5填入验证码并确认联系方式。6验证主表单里的手机号已经显示为已确认状态。验证码查询必须带时间窗口。不要简单取“最近一条腾讯短信”否则容易用到旧码。更稳的匹配条件包括短信发送方包含云平台名称。接收手机号匹配当前账号联系人。接收时间晚于本次点击发送验证码的时间。短信正文符合验证码格式。验证码只使用一次不写入工单正文和最终报告。滑块验证怎么处理滑块验证属于反自动化机制不能默认绕过。合规的做法是把它当成高风险交互1页面检测到滑块或拼图验证。2自动化暂停并请求用户授权处理该验证码。3获得授权后读取验证码截图和滑块轨道位置。4估算缺口位置模拟拖动。5只有页面显示“验证成功”或按钮进入倒计时时才继续下一步。如果验证失败不要盲目高速重试。应刷新验证码、重新估算距离并限制尝试次数。多次失败后交给用户手动处理。工单正文要分层云平台工单通常会提醒“问题描述包含机密信息请放入机密信息区域”。这不是装饰提示很多平台会直接阻止提交或让按钮无响应。建议把内容拆成三层公开问题描述事件类型。影响范围概述。已完成的临时处置。需要云厂商协助确认的问题。机密信息实例 ID。公网和内网 IP。告警 ID。具体日志片段。文件路径、哈希、密钥指纹等 IOC。附件脱敏后的日志。恶意文件哈希清单。处置命令记录。监控截图。这样做有两个好处一是更容易通过平台前端校验二是权限边界更清楚。客服、工程师、自动推荐系统看到的信息范围不一定相同敏感信息应走平台提供的加密字段或附件机制。提交流程状态机实际执行时建议把工单提交做成状态机而不是一段线性脚本流程图 2状态机的好处是可恢复。比如浏览器会话断开后只要页面还在就能从 DOM 状态判断当前处于“联系方式已确认”还是“等待服务角色授权”而不是从头再来。权限弹窗也要纳入流程云平台工单可能会触发服务角色授权例如创建一个服务相关角色让云平台安灯或工单系统可以访问 CVM、COS 等资源。这属于权限变更不应静默点击。自动化系统要识别这类弹窗并记录角色名称。角色类型。授权策略。访问范围。用户授权时间。点击同意后的结果。如果用户已经对该次任务明确授权可以继续执行否则必须暂停确认。权限弹窗不是普通确认框它可能改变云账号的访问边界。审计与回写工单提交成功后系统应保存这些结果工单号。详情页 URL。提交账号。提交时间。工单分类。已提交摘要。是否创建服务角色。是否使用短信验证码。是否处理滑块验证。不要保存一次性验证码。不要把完整密码、SecretKey、MFA 秘钥写进运维日志。若工单里临时包含了敏感凭证应在结单后轮换对应凭证。最小实现清单一个可落地的实现可以从下面这些模块开始1CredentialResolver按平台和账号从用户中心读取登录凭证、MFA 秘钥和联系人。2SmsCodeResolver按平台、手机号、发送时间查询最新验证码。3TicketDraftBuilder把事件事实转成公开描述、机密字段和附件清单。4BrowserTicketRunner负责控制台登录、填表、验证码和提交。5TicketStateDetector从页面识别当前状态支持失败恢复。6AuditWriter写入工单号、状态、证据和后续跟进事项。先把这六个模块跑通再考虑多云平台抽象。不同云厂商的页面差异很大但凭证、验证码、状态机和审计边界是通用的。关键风险全自动工单提交最容易出问题的地方不是页面点击而是边界失控把 SecretKey、密码或验证码写进日志。使用旧短信验证码。将敏感实例信息放入普通问题描述触发平台校验或扩大可见范围。自动同意云账号权限变更却没有审计记录。浏览器临时标签页被清理后没有状态恢复能力。提交后没有读取工单号误以为成功。这些风险都可以通过状态机、短期凭证使用、敏感字段分层和提交后读回来控制。结论全自动工单提交不是“模拟人点网页”而是把用户中心、短信验证码、浏览器会话、云平台权限和事故证据串成一个闭环。真正可靠的实现要做到三件事第一凭证集中管理执行期使用日志不泄露。 第二页面状态可检测验证码和权限弹窗可恢复。 第三提交成功必须回读工单号和详情页形成可审计证据。当这三点成立工单提交就可以从临时人工操作变成运维和安全响应的一部分发现问题、收集证据、提交厂商、回写台账整条链路都能自动化。