服务商进来干活，账号该怎么给

结论先行：把服务商请进来干活，绕不开一件事：给他什么账号。给一个共用管理员账号最省事，也最容易在事后说不清。可行的做法是把这件事拆成五项，逐项定下来——用实名账号而不是共用账号、权限划到具体的设备组而不是全域、每次授权带明确到期日、所有操作进可查的记录、结束时有明确的回收动作。五项里缺哪一项，出问题时那一项就会成为解释不清的地方。

本文只谈服务商进场干活时用什么样的账号、权限该给到哪一层、授权怎么到期，不谈服务商离场时的清单核对与移交凭据，也不谈内部员工离岗时的权限与数据归属。

为什么账号问题总在事后才被看见

三个原因，都很现实。

其一是赶工期。服务商到场当天就要动设备，开账号这件事排在后面。为了不耽误，先把现有的管理员账号给出去，反正干完活就还回来。而「还回来」这件事，通常没有人盯。

其二是账户与人脱钩。很多环境里，一台设备只配一个管理员账号，谁维护都用它。这个账号在台账上属于「系统内置」，不属于任何一个人。于是所有操作在记录里都是同一个名字，出了事只能问「那几天谁去过机房」。

其三是没有结束动作。加人是主动的，有人提需求、有人批、有人开；删人却是被动的，服务商撤场、项目结项、对接人换岗，这些时点没有任何人负责触发回收。存量账号就这么一个项目一个项目地堆下来。

三件事叠加的结果是：账号一直在，人一直在变，而记录只记到一个谁都不是的名字上。

四类账号，管理方式不一样

四类里，问题最多的是实名个人账号与系统内置账号这两类。前者数量多、生命周期短，最容易漏销；后者最隐蔽，因为它看起来是「系统的一部分」，不像一个人。

可行的做法是把系统内置账号明确列为禁止用于人工操作的对象：它的口令由专人保管、只在特定场景下启用、启用过程留记录。日常运维一律走实名账号。这一条在很多合规要求里是明文，但真正落到配置上的环境并不多。

开立时要把五件事写下来

其一，身份。账号挂在具体的人名下，而不是「某服务商」。做到人这一层，才有可能在事后回答「那次改动是谁做的」。人员更换时，旧账号停用、新账号新开，不做账号交接。

其二，范围。权限划到具体的设备组或系统，不划到全域。这里有个常见误区：为了省事给一个「管理员」角色，而这个角色在多数平台上意味着全域全权。可行的做法是先列这份活要碰哪些设备，再按清单授权，清单之外的一律不给。

其三，时效。每次授权带一个明确的到期日，而不是「项目结束为止」。到期日的好处是可以被系统提醒，而「项目结束」是一个需要人来判断的状态，通常没人判断。故障处置类的临时权限，时效应当按小时算。

其四，留痕。操作记录要覆盖到人。这里要区分两件事：设备自己有日志，和平台把操作记录到具体账号上。前者很多设备都有，后者常常缺——尤其是通过堡垒类通道统一接入的场景，如果通道本身不做身份绑定，设备上看到的还是通道账号。

其五，回收。回收不是「取消账号」一个动作，它至少包含三步：停用账号、撤销授权、确认会话已断。第三步最容易被忘——账号停用了，但已建立的会话可能还活着。

权限给到哪一层，比给多大更重要

同样是「能改配置」，不同的给法风险完全不同。

给到界面还是给到命令。有些工作只需要在管理界面上看状态、点几个开关，不需要命令行。把范围限制在界面层，能挡掉很大一部分误操作。

给到设备还是给到设备组。一次变更通常只涉及几台设备。按设备组授权，能把影响范围限制在组内；全给，一次误操作就可能波及全域。

给到操作还是给到审批。高危动作（改隔离策略、删审计记录、调权限、改路由）可以由服务商发起、由甲方审批执行，而不是直接给执行权。这个分工在多品牌环境里尤其有效：服务商最懂设备，甲方最懂业务边界。

给到人还是给到时段。临时开放的时间窗口，结束后自动收回，比人工去关更可靠。这类窗口应当与工单绑定：有工单才有窗口，工单关闭窗口即失效。

授权到期，比事后清理可靠

「记得去清理」这句话在多数团队里等于不会发生。可行的办法是把清理变成到期——不是等人想起来去关，而是它自己到点失效。

落到配置上，就是每次授权带一个明确到期日，临时权限按小时计。到期失效的好处是它不依赖任何人记得，也不会因为对接人换了而中断。与工单绑定的临时窗口同理：工单关闭，窗口自动失效。

到期机制解决的是「忘了关」，但它解决不了「该不该续」。所以还要配一项定期复核：按季度导出一次外部账号清单，按最近一次登录时间排序，长期未登录的逐个确认——这个人还在不在这个项目上、还需不需要这个权限。确认结果要留档，因为下一次复核会拿它做对照。

还有一类容易漏的：服务商那边换了工程师，甲方的账号台账却没有变。这类情况在复核时能看出来——登录记录里出现了新的操作习惯（时间、设备、路径），但账号没变。看到这类信号，就该主动确认一次。

事后自证的三条线

外部账号这件事，真正要能回答的是三个问题。

谁能进来。当前有哪些外部账号、分别属于谁、有效期到什么时候。这一条要靠台账，台账不及时，这条线就断了。

进来做了什么。每一次操作要能对到具体的人和具体的工单。这一条要靠记录，而且是不可被有权限的人删除的记录。

什么时候失效的。授权的到期日是哪天、到期有没有真的失效、有没有续期记录。这一条最常缺，因为到期是一个自动发生的动作，没人会主动去确认它到底发生了没有。

三条线里，第三条是判断一个单位管理水平的分水岭。前两条只要上了系统就大体能做到，第三条必须有制度配合。

多因素与来源限制，是这类账号的前提

账号和权限设计得再细，如果登录只靠一个口令，冒用一个人的账号就绕过了全部设计。

行业里较完整的做法是把两件事配上：一是多因素认证，口令加动态令牌、或口令加生物特征；二是来源限制，对陌生来源地址的登录做拦截或二次确认。这两条对外部账号尤其重要，因为外部账号往往从固定办公地点之外的地方登录。

还有一层是行为记录。登录行为、文件传输、外设使用这类动作要进记录，而且要和账号对上。它的意义不在于「防住」，而在于事后能把一段行为的全貌还原出来。

落地清单

• 外部账号一律实名到人，不用「某服务商」这类共名账号。
• 系统内置账号明确禁止用于人工操作，口令专人保管、启用留记录。
• 权限按设备组或系统授予，先列清单再授权，清单之外不给。
• 每次授权写明确到期日，应急权限按小时计。
• 高危动作由服务商发起、甲方审批执行，不直接给执行权。
• 临时开放窗口与工单绑定，工单关闭窗口失效。
• 操作记录必须能落到具体账号，统一通道也要做身份绑定。
• 停用账号要三步一起做：停账号、撤授权、确认已建立的会话已断。
• 授权一律带到期日，临时窗口与工单绑定，工单关闭窗口失效。
• 每季度按最近登录时间复核外部账号，确认结果留档备下次对照。
• 外部账号配多因素认证与来源限制，登录与文件传输进记录。

深圳市奇摩计算机有限公司在做运维服务类项目时，会与客户先把外部账号的开立、审批、回收三张清单对齐，再进入现场。这样安排的原因很实际：服务商进场这件事本身是双方的共同风险，把边界写在前面，比事后解释要省力得多。若您正在梳理外部账号的管理口径，欢迎 预约咨询。