共享账号凭据定期巡检与僵尸账号自动回收怎么做：安当SYP 的落地实践

一、为什么共享账号凭据必须定期巡检企业里有一类账号很特殊它不是绑定到某个具体员工的人账号而是多人共用的系统账号。比如供应链协同门户的供应商登录号、车企研发外包用的代码仓账号、财务共享中心的银企直连账号、电商客服外包的工单系统账号、制造产线的设备运维账号。这些账号的密码通常由管理员线下分发员工用密码代填方式登录凭据本体在终端并不落盘。这类账号最大的隐患不是被爆破而是长期无人巡检后堆积出大量僵尸账号。所谓僵尸账号是指曾经分配给某人、某团队或某项目使用但相关人已经离职、项目已经结项、外包已经退场账号却仍然留在目标系统里、密码仍然有效、仍然可以被成功认证的账号。它们有几个典型特征最后成功登录时间距今远超业务合理周期例如 180 天未登录却 still active登录来源 IP 长期固定在某个已经撤场的外包网段账号归属的项目编号在 CMDB 里已经关闭账号的使用人字段为空或者绑定的人早已离职。僵尸账号之所以危险是因为它同时具备两个属性认证可用与无人关注。攻击者拿到这类凭据后往往能长期潜伏而不触发任何告警因为本来就没人用在监控侧看起来像正常静默。等保 2.0 三级对多余账号应及时注销有明确要求密码法也强调密钥与凭据的全生命周期管理供应链审核场景更是对供应商退出后账号回收有强审计诉求。因此共享账号凭据的定期巡检与僵尸账号自动回收本质上是一套活性探测 规则判定 安全回收 证据留存的闭环工程而不是简单的定期改密码。1.1 僵尸账号的三种形成路径理解僵尸账号怎么来的才能把巡检规则设对。实践中僵尸账号主要来自三条路径第一是人员流动型。员工离职、外包退场时IT 只回收了个人的域账号却漏掉了他手里那几个共享系统账号。这类账号的使用人字段往往还写着已离职的人是最容易被规则命中的一类。第二是项目结项型。一个临时攻坚项目申请了一批共享账号项目验收后系统没人再登但账号没有随项目关闭一起注销。这类账号的特征是目标系统归属的项目编号在 CMDB 中已经标记为关闭却仍保持启用。第三是架构残留型。系统经历过迁移、合并、拆分老系统的入口早已不对外服务但后台仍留有可认证账号。这类最隐蔽连业务方都可能不知道它的存在只能靠主动探测去发现。三类路径对应不同的判定线索人员流动看 HR 状态项目结项看 CMDB架构残留看主动探活。巡检规则必须把这三条线索都接进来单看登录时间会把后两类漏掉。1.2 巡检频率的工程权衡巡检不是越频繁越好。每天全量扫一遍对 10 万级账号规模会带来不小的事件写入压力一个月扫一次又可能让僵尸账号多活很久。折中做法是增量 全量两档高频每日只处理有新事件流入的账号做活性刷新低频每周或每月跑一次全量做僵尸重判。这样既保证活跃账号的活性表实时又控制全量算力开销。需要强调的是全量重判的周期必须早于业务要求的最短回收周期否则规则阈值会失去意义。二、活性探测怎么判断一个共享账号还活着巡检的第一步是回答一个问题这个共享账号最近到底有没有被用过判断活性不能只看账号在不在而要看认证事件有没有发生。2.1 三类活性信号我把活性信号分为三类按可靠度从高到低信号类型来源可靠性说明认证成功事件代填组件回传的登录回执高账号被真实使用并完成认证心跳/保活桌面代理周期性探活中证明凭据仍可被取用不代表业务使用最后修改时间目标系统账号属性低仅说明密码没改无法证明在用真正有判定价值的是第一类认证成功事件。企业密码管理器在做密码代填时代填动作发生在浏览器插件或桌面代理侧每一次成功登录都会回传一条结构化事件谁、什么时间、用哪个共享账号、登了哪个业务系统、从哪里终端/网段登的。这条事件正是活性探测的数据底座。2.2 活性探测的采集实现以代填组件的登录事件为例一次成功认证回传的 JSON 大致长这样{event:credential_used,ts:2026-09-20T09:12:4308:00,vault_id:v-2024-supply-07,account:supplier_a_portal,target_system:supply-chain-portal,operator:zhangops,auth_method:usbkey,src_ip:10.20.31.118,result:success}巡检服务把这类事件按vault_id account聚合维护一张最后活跃表fromcollectionsimportdefaultdictimportdatetimeasdt LAST_ACTIVEdefaultdict(dt.datetime.min)defon_event(ev:dict):ifev.get(result)!success:returnkey(ev[vault_id],ev[account])tsdt.datetime.fromisoformat(ev[ts])iftsLAST_ACTIVE[key]:LAST_ACTIVE[key]tsdefdays_idle(key,nowNone):nownowordt.datetime.now(dt.timezone.utc)return(now-LAST_ACTIVE[key]).days这里有几个工程细节要注意。第一时区必须统一建议全部存 UTC展示时再转本地时区否则跨时区外包团队会造成误判。第二result success才算活性失败的尝试不算否则爆破流量会污染活性表。第三心跳类信号单独存不要和真实使用混在一起否则代理还连着会被误判为账号还在用。2.3 探测盲区与补盲不是所有目标系统都能回传代填事件。对于老旧设备、哑终端、只支持串口或本地客户端的系统需要做补盲探测由巡检服务用只读凭证主动发一次轻量认证例如 LDAP bind、SSH 握手记录能否成功。这类主动探测频率要低建议每周一次且必须走独立审计账号绝不能复用业务共享账号避免探测行为本身变成风险。补盲探测还有一个微妙之处它本身是一种主动使用如果回传的事件流里把补盲账号的成功 bind 也记成业务活性就会污染活性表让被探测的僵尸账号假活。工程上要给补盲事件打独立标签如probetrue聚合活性表时只认probe ! true的真实业务事件。换句话说探测动作和可观测的活性信号必须两根管道否则探测器反而成了僵尸账号的续命器。2.4 活性表的存储与查询设计活性表本质是(vault_id, account) - last_active_ts的 KV 映射但生产环境还要叠加维度字段归属项目、负责人、特权等级、来源网段、豁免标记。数据量到十万级后建议用带二级索引的列式或文档存储按last_active_ts建范围索引这样找出空闲超过 N 天的账号就是一次索引扫描而非全表遍历。写入侧要做幂等合并——同一账号的多次事件只更新最大时间戳避免重复写放大。查询侧要做分页游标单次返回不超过 500 条防止大结果集把巡检服务内存打爆。三、僵尸规则识别长期未用的判定模型有了活性数据下一步是定义什么算僵尸。单纯用多少天没登录一刀切误杀率会非常高。我建议用多维度加权规则把业务语义带进来。3.1 判定维度维度字段僵尸倾向空闲时长days_idle越长越僵尸业务归属project_status项目已关闭则高负责人状态owner_active负责人离职则高来源网段src_segment已撤场网段则高特权等级privilege高权限账号更严例外标记keepalive_flag有标记则豁免3.2 规则表达式把维度组合成规则化的规则集而不是写死在代码里。每条规则是一个布尔表达式加一个严重级别rules:-id:R1_idle_180expr:days_idle 180 and keepalive_flag falseseverity:lowaction:notify-id:R2_project_closedexpr:project_status closed and days_idle 30severity:highaction:recycle-id:R3_owner_leftexpr:owner_active false and days_idle 7severity:highaction:recycle-id:R4_priv_segmentexpr:days_idle 90 and src_segment in retired_segmentsseverity:mediumaction:review注意这里区分了notify、review、recycle三种动作。低危只通知中危进入人工复核队列高危直接进回收编排。不要把所有命中都直接回收这是后面误报降噪要重点处理的。3.3 空闲阈值的取值参考阈值不能拍脑袋。我给一个按业务类型分档的经验值企业可结合自身审计要求调整供应链审核类账号项目结项即应回收空闲阈值 30 天外包研发账号外包合同结束即回收空闲阈值 15 天财务共享账号月结周期相关空闲阈值 60 天客服外包账号排班周期内空闲阈值 45 天产线运维账号设备检修周期空闲阈值 90 天。阈值过短会干扰业务过长则失去巡检意义。建议先用 90 天观察一轮看命中分布再收窄。四、回收编排从识别到下线的工程链路回收不是删账号三个字能概括的。共享账号往往牵扯密码代填配置、授权关系、历史审计数据粗暴删除会丢证据。我把它拆成五步编排。4.1 编排状态机detect(命中规则) - hold(进入冻结观察窗, 默认 7 天) - if 观察窗内无新活性: disable(目标系统禁用登录, 保留账号) - rotate(凭据保险箱旋转新密码, 旧密码失效) - detach(解绑代填配置与授权) - archive(审计与元数据归档) - if 确认无依赖: delete(目标系统删除账号) - else: keepalive(标记误报, 回写白名单)冻结观察窗是关键的后悔机制。命中规则后不直接禁用而是先冻结并观察 7 天若窗口内出现真实认证成功事件说明是误报自动回滚并标记。4.2 凭据旋转而非保留很多团队回收账号时只禁用不换密这留下隐患旧密码仍在保险箱里、在员工记忆里。正确做法是旋转rotate——在目标系统把密码改成随机高强度新值并同步更新凭据保险箱使旧密码立即失效。这样即使账号因依赖暂不能删凭据也已经无害化。defrecycle_account(target,account):freeze(target,account,window_days7)ifnothas_activity(target,account,since_freeze()):disable_login(target,account)new_pwdgen_strong_password(length24)rotate_password(target,account,new_pwd)# 旧密码失效sync_vault(account,new_pwd)# 保险箱同步新值detach_grants(account)archive_meta(target,account)# 留证ifno_dependency(target,account):delete_account(target,account)4.3 编排的并发与限流回收是批量操作必须限流避免对目标系统造成认证风暴。建议单目标系统并发回收数不超过 5两次回收间隔 ≥ 2 秒维护幂等键重复触发同一账号只执行一次失败账号进入重试队列最多重试 3 次后转人工。五、误报降噪避免误杀活跃账号僵尸回收最怕误杀。一旦把正在用的账号回收了业务中断的锅比漏检僵尸账号还大。降噪从四个层面做。5.1 白名单与豁免标记对明确需要长期保活的账号如核心调度账号、节假日才用的报表账号打keepalive_flag豁免标记规则直接跳过。白名单要走审批不能随便加。5.2 观察窗二次确认如第四节所述冻结观察窗内出现真实活性即回滚。这是对抗周期性低频使用账号的主要手段——比如月度结账账号每 28 天用一次若阈值设 30 天就会被误杀观察窗能兜住。defon_event_during_hold(ev,hold_record):ifev[account]hold_record[account]andev[result]success:cancel_hold(hold_record)mark_false_positive(hold_record,reasonactivity_in_window)5.3 业务上下文交叉验证不要只信时间维度。回收前调用 CMDB、HR 系统、项目管理系统做交叉验证账号归属人是否在职、项目是否真关闭、资产是否报废。三者任一显示仍活跃降级为review而非直接recycle。5.4 灰度与打分上线初期建议用打分制而不是规则硬触发每个维度给分总分超过阈值才进回收。先跑只读模式只出报告不执行观察两周误报率再把高危分档切到自动执行。以安当SYP为例其代填组件回传的结构化登录事件天然带了操作人、账号、目标系统、来源 IP 四元组巡检服务直接消费这条事件流做活性聚合无需再对接目标系统的日志而凭据保险箱侧的旋转接口让回收编排可以直接在禁用 换密一步完成无害化省掉了人工改密的环节。这种事件即数据源、保险箱即执行端的架构使僵尸回收能在 10 分钟内完成从识别到无害化的闭环而不必依赖逐个系统去写回收脚本。六、留存审计证据材料与合规落地回收动作做完了但如果没有留证出了问题仍然说不清。凭据治理的合规价值很大程度体现在可追溯的证据链。6.1 审计字段最小集每条回收动作必须留存以下字段形成不可篡改的记录字段含义who哪个操作人/哪个编排任务发起when精确到秒的时间戳which_account被回收的共享账号标识which_system所属目标系统why命中哪条僵尸规则、依据什么数据how执行了禁用/旋转/解绑/删除哪些步骤evidence回收前后的凭据指纹、事件快照6.2 证据防篡改审计日志建议写到只追加append-only的存储并做哈希链每条记录带前一条的哈希任何篡改都会断链。关键操作可额外落一份离线归档满足审计抽查时能拿出当时确实回收了、且依据充分的材料。6.3 合规映射等保 2.0对应应对登录的用户进行身份标识和鉴别“应及时删除或停用多余的、过期的账户”巡检报告就是整改证据密码法凭据全生命周期生成、存储、使用、销毁留痕满足密钥管理要求供应链审核供应商退出后账号回收的时点、执行人、结果可直接作为外部审计材料个人信息保护回收过程不留存业务数据内容只留凭据元数据降低合规面。七、改造路径从人工台账到自动化巡检很多团队现在还是 Excel 台账管共享账号改造要循序渐进。阶段一盘点与纳管第 1–2 周把分散在员工本子、聊天记录、共用文档里的密码统一收进凭据保险箱开启密码代填。这一步核心是让密码不落地同时为后续巡检积累事件数据。不要一上来就谈回收先做到看得见。阶段二事件采集与活性基线第 3–4 周部署代填组件事件回传建立每张共享账号的最后活跃表跑两周只读巡检输出僵尸账号清单供人工确认。此阶段不自动执行任何回收。阶段三规则定型与灰度第 5–8 周根据业务类型定僵尸规则阈值开灰度打分高危动作先走review队列。每周复盘误报调阈值、补白名单。阶段四自动回收闭环第 9 周起把确认无误的高危分档切到自动recycle保留中低危人工复核。每月出巡检报告纳入安全运营例会与外部审计材料。八、性能与容量数据参考巡检服务是后台批量任务容量规划要心里有数。以下是一组工程参考数据基于代填事件流聚合的实现单节点可维护活跃账号索引约 50 万条每日事件写入吞吐单节点 2 万事件/秒峰值全量巡检一轮耗时10 万账号约 8 分钟只读扫描回收编排吞吐受目标系统限流约束单系统约 1500 账号/小时观察窗内存占用每冻结账号约 2 KB 元数据存储审计日志体积每条回收动作约 1.2 KB百万级回收年增量约 1.2 GB需归档策略。容量瓶颈通常在目标系统的认证接口而非巡检服务本身。因此限流参数要按目标系统的承压能力设置必要时错峰执行。九、巡检指标体系与运营看板巡检系统上线后能不能持续产生价值取决于有没有一套可观测的指标。安全运营团队需要的不只是回收了多少账号一个数字而是对治理健康度的持续洞察。9.1 核心指标指标定义健康线僵尸账号占比命中规则的账号数 / 纳管总数低于 3%平均空闲时长全量账号 last_active 距今天数均值低于 60 天回收准确率自动回收后无申诉的比例高于 98%误报率观察窗内回滚数 / 命中数低于 2%回收时效命中到完成无害化的中位时延低于 24 小时证据完整率带齐七字段的回收记录比例100%这六个指标从有多少、多严重、准不准、快不快、证全不全五个维度刻画治理健康度。其中证据完整率必须拉满它是合规审计的底线任何一条回收动作缺字段都应触发告警并补录。9.2 看板与告警把上述指标做成周期看板趋势比绝对值更重要僵尸占比逐月下降说明治理在生效突然回升往往意味着某批新账号没走纳管流程。告警侧建议设两条线一是单日新增僵尸账号超过基线 2 倍的突增告警通常对应一次未回收的大规模人员变动二是误报率连续两周上升的退化告警提示规则阈值需要复盘。告警不要直接接自动回收而是进人工队列保证人在回路。9.3 与外部审计的衔接巡检报告天然是一份合规性材料。月度报告里至少包含本期纳管账号总数、新增僵尸数、已回收数、在观察窗回滚数、当前残留僵尸清单及处理状态。外部审计或供应链审核来查时直接导出这一份即可不必临时翻日志。关键是报告要能追溯到每一条回收动作的原始事件与规则依据做到结论可复算。方案参考共享账号凭据的定期巡检与僵尸账号自动回收建议按先可见、再判定、后回收、全程留证的顺序落地。选型时重点看四件事一是代填组件能否回传带操作人/账号/系统/来源四元组的认证事件这是活性探测的数据源拿不到就只能用低频主动探测补盲二是凭据保险箱是否支持编程式旋转回收时能否直接换密使旧密码失效避免人工改密遗漏三是僵尸规则能否按业务维度配置而非写死阈值不同场景空闲周期差异很大四是审计是否只追加且可离线归档回收动作的证据链要能经得起外部审计抽查。落地节奏上先用只读巡检摸清僵尸账号分布再灰度自动回收高危分档最后把巡检报告纳入月度安全运营。改造不必大动干戈从把分散密码收进保险箱、开启代填做起就能在不改造业务系统的前提下把凭据治理从人工台账推进到自动化闭环。规则阈值建议从宽松起步结合误报复盘逐步收窄平衡安全与业务连续性。