2026 服务器租用团队密码库自建：Vaultwarden 备份与反代 干货大全 + 避雷全解

2026 服务器租用团队密码库自建：Vaultwarden 备份与反代 干货大全 + 避雷全解

团队密码库的诉求其实很朴素：把散落在聊天记录、共享表格、浏览器自动填充里的凭据收进一个地方，谁需要谁知道，走了的人不再知道。市面上现成的托管服务能做到这一点，但确实有一部分团队因为数据存放位置的要求、预算结构，或者单纯想把钥匙握在自己手里，选择在一台自己租用的服务器上跑一套服务端。这条路是可行的，前提是你清楚它把哪些责任从服务商转移到了你身上。本文只谈一种具体选择：用社区维护的第三方服务端实现 Vaultwarden，配合官方客户端，在自有的服务器租用环境里自建团队密码库，重点放在备份、反向代理和暴露面收敛这三件真正会出事的事情上。

需要先把期望值摆正。自建解决的是"数据放在谁的机器上"这个问题，它不解决"谁来保证它一直能用"这个问题。托管服务里那些你从未察觉的工作，比如多地冗余、异地副本、故障切换、值班响应、升级兼容性验证，在自建之后全部变成你的日程表上的条目。如果团队里没有人愿意认领这份日程，那么下面所有技术细节都只是把风险往后推。反过来讲，只要你愿意认领，这件事的技术门槛并不高，服务端本身的资源占用相当低，真正的成本在流程与演练上。

第三方服务端实现与官方服务端的责任边界

Vaultwarden 是社区维护的第三方服务端实现，早期名字叫 bitwarden_rs，用 Rust 写成，它的目标是替代 Bitwarden 官方的服务端，让官方出品的浏览器扩展、桌面端和移动端客户端能直接连上来使用。它不是 Bitwarden 官方出品，这一点必须先讲清楚，因为它决定了后面所有问题的归责方式。选型会上如果出现"这就是官方的开源版"这类理解，后面的责任划分一定会出偏差。

客户端是官方的，服务端是社区的，这条分界线带来一个很实际的结果：客户端更新之后，服务端需要跟上协议层面的变化，而社区跟进的速度不受任何服务等级承诺的约束。你在托管服务里遇到兼容性问题可以提工单、有响应时间；在自建环境里只能自己看更新日志、自己安排升级窗口、自己承担升级失败后的回滚成本。这不是缺陷，是选择自建时一并接受的条件。

这种实现有一个明确的工程取向：资源占用明显低于官方服务端，单进程加一个数据库就能跑起来，常见的后端是 SQLite，也可以接 MySQL 或者 PostgreSQL。对一台配置普通的租用服务器来说，这意味着密码库这个应用本身几乎不会成为资源瓶颈，你付出去的硬件成本主要花在冗余、备份和可达性上，而不是花在支撑服务端运行上。这也是很多中小团队愿意选它的现实原因。

所以选择它的典型理由是：你认可端对端加密模型，愿意自己维护一套轻量服务端，用低得多的资源占用换取对数据物理位置的控制。不选它的理由同样清楚：你需要一个可以追责的商业支持主体，或者你的可用性要求高于对数据位置的要求。这两类诉求没有对错，但要诚实地承认自己属于哪一类，别用"自己搭更可控"这种模糊说法掩盖真实的取舍。

端对端加密下管理员救不了主密码的后果

加密模型是端对端：客户端在设备本地用主密钥加密之后才上传，服务端保存的是密文。服务端从头到尾没有见过明文，也没有见过能解开这些密文的密钥。这一条不是配置选项，不是可以通过调整权限改变的设定，而是整个系统的地基。

它的直接后果是管理员无法替用户找回主密码。这不是权限不够，是数学上做不到。用户主密码丢失，服务端上属于他的那部分数据就永久解不开，管理员能做的只有删除这个账号、让用户重新注册、然后由用户自己重新录入内容。如果这位用户还往个人库里塞了公司独有的东西，那部分内容就是真的没了。

这条事实必须在全员上线之前讲清楚并让人签收，而不是等到第一次有人忘记密码时才解释。最常见的误解是"我们把备份做好了就没事"。备份解决的是服务端整机损毁或者数据目录被误删；主密码丢失解决的是用户本人丢了钥匙。两者是完全不同的故障，前者靠运维体系兜底，后者只能靠用户自己的保管习惯，运维在这件事上无能为力。

由此带来流程上的改动。入职培训里要加一条关于主密码保管的要求：写下来装进物理信封由本人和另一位负责人分持、或者存进公司另外管理的恢复体系，具体形式由团队自己定，但必须有。离职流程里也要写清楚：公司回收的是账号访问权，不是数据解密权，回收之后仍然要做凭据轮换，理由后面会展开。

另一个常被误解的点是管理员后台能做的事情相当有限。它更接近"用户与组织的生命周期管理"，而不是"数据内容的查看与管理"。如果团队期待的是管理员能随时导出明文、能在某人不在时替他打开某条凭据，那么自建这套东西会让人失望，托管服务在这一点上也同样做不到。这是加密模型的代价，不是某个实现的功能缺失。

数据分四处：库、附件、配置、图标缓存

自建之后，"备份"这个词必须拆成四个对象，因为它们落在不同位置，丢失后的后果也完全不同。只说"我们每天备份"而不说备份了哪几份，等于什么都没说。下面这张表是排查备份覆盖度时最实用的一张清单。

数据库是核心，但它不是全部。真正容易翻车的是附件目录：很多团队习惯把密钥文件、证书、恢复码截图作为附件塞进密码库，这些内容独立于数据库存放。只拷数据库、丢了附件，恢复出来的是一堆"有条目没内容"的空壳，从恢复日志看一切正常，用起来处处是洞，而且这种损坏往往在很久之后才被发现。

图标缓存目录在技术上属于可再生缓存，丢了不影响数据本身，只影响界面观感和加载速度。它值得备份的理由是恢复速度，不是数据安全，所以给它一个低频备份就够了，不必和核心数据同等对待。把它和数据库并列成"必须每小时备份"的对象，是资源配置上的浪费。

配置文件是最后一个，也是最容易被漏掉的一个。数据库和附件都在，配置丢了，你面对的是一台不知道自己该用哪个域名、管理员后台进不去的服务。更麻烦的是配置里的管理员令牌：如果它只存在于原机器的某个文件里，而那台机器已经不在了，你就连后台都进不去。恢复演练时最常卡住的往往就是这一步，而不是数据恢复本身。

SQLite 运行中复制库文件的不一致风险

默认后端是 SQLite，它让部署变得极其简单，也让备份带上了陷阱。SQLite 使用预写日志机制，运行中对库文件直接做文件复制，有可能拿到一个处于中间状态的不一致快照：在你复制的那一刻，还有尚未合并进主库的写入留在日志文件里。

这种快照的麻烦之处在于它多数时候能打开。你每次检查都看到"备份成功""文件能解开"，于是以为没问题，直到真正需要它的那天打不开，或者打开后发现少了最近一段时间的改动。这是最坏的一类故障：它在平时伪装成正常状态。

稳妥做法有两条。一是用数据库自带的备份命令导出一致性快照，这条路径不中断服务，适合作为常规方案；二是先停服务、确认没有写入、再拷文件、再启动，这条路径简单但需要安排窗口。选哪一条取决于你能接受多长的不一致窗口，以及你有没有现成的任务调度来跑前者。

什么时候该从 SQLite 换成独立数据库？判断标准不要看"多少人用"，要看"同时写"。密码库的读远多于写，几十人的团队在 SQLite 上通常也跑得动；真正的压力来自批量导入、组织结构大调整这类集中写入操作。除此之外，还有两个换的理由：你希望备份能独立于应用进程做一致性导出，或者你想把库交给更成熟的备份体系托管。MySQL 与 PostgreSQL 都是可选后端。

换成独立数据库之后，复杂度会上升：多一个进程要管、多一套凭据要托管、备份脚本要重写。这是一笔明确的交易，用运维复杂度换一致性与可扩容性。团队规模不大、成员稳定、没有集中写入场景的时候，SQLite 完全够用，不必为了"看起来更专业"提前迁移。真到了该迁移的时候，症状会很明确，不会需要你猜。

反代三件事：HTTPS、WebSocket 升级、请求体上限

把服务端暴露给公网时几乎总要经过一层反向代理，这层代理要做对三件事，做对两件等于没做——因为客户端的表现会是"能用，但哪里不对劲"，这种模糊症状最耗排查时间。

第一件是 HTTPS。客户端不接受明文环境，也不接受自签证书环境。这不是可选的加固项，是能不能连上的前提。证书签发与自动续期要纳入常规运维，不要用手工申请的一次性证书，否则某天证书过期，全团队同时掉线，而你正在休假。

第二件是 WebSocket 长连接，客户端靠它接收实时推送与同步通知。只配了普通 HTTP 反代、没放行 WebSocket 升级头，典型现象是"能用但要手动刷新才同步"：一个人在手机上改了密码，另一个人在浏览器扩展里看到的还是旧值，手动刷新才更新。这个现象极易被误判为客户端 bug 或者服务端性能问题，排查方向会完全跑偏。

第三件是请求体大小上限。反代有默认上限，服务端自身也有上限，附件传不上去的时候两头都要查。只放宽反代那一头，请求会卡在应用层；只放宽服务端那一头，请求根本到不了应用层。两边都放宽之后还要确认一遍实际生效值，改了配置没重载是常见疏漏。

一个实用的验收办法：上线后立刻做三项验证。证书链在移动端和浏览器扩展上都正常，没有告警；两台设备分别登录同一账号，改一条凭据，看另一台是否在无操作的情况下自动更新；传一个大附件，确认成功且能下载回来。这三项过了，反代才算配完，没过就别急着通知全员切换。

上线清单里最容易被跳过的开放注册开关

服务第一次跑起来的时候，默认状态未必是你想要的最终状态。开放注册这个开关如果不显式关掉，任何扫到这个域名的人都可以自助注册一个账号，占用你的存储，成为你数据目录里的陌生人。它是一个不报错、不告警、只会安静开着的选项。

这一条的隐蔽之处在于上线初期你往往需要自己注册第一个账号，所以会把它打开；等你把管理员账号建好、把组织建好，很容易忘记再关回来。等到某天在用户列表里看到陌生邮箱，才发现它一直开着。更糟的情况是没人去看用户列表，这个状态持续很久。

正确顺序应该是：临时开启注册、创建管理员账号、关闭注册、后续成员统一由管理员在组织内邀请。把"关闭注册"写进上线检查表，作为发布流程里一个可勾选的步骤，而不是存在某个人脑子里。人脑在上线当天要处理的事情太多，靠不住。

如果确实存在让外部人员自助注册的需求，那就要额外做邮箱验证、邀请码和配额限制，那是另一种产品形态，不是团队内部密码库该走的路线。内部密码库的正确形态始终是：封闭注册、邀请加入、管理员可随时移除。

还要区分一件事：管理员后台是通过管理员令牌启用的，注册开关和令牌开关是两件独立的事。关了注册不等于后台安全，开了后台不等于注册开放。这两项要在清单里分开确认，不要用一个勾选项盖过去。

管理员令牌的启用方式、存放位置与收起时机

管理员后台通过管理员令牌启用，这个令牌一旦泄露，等同于把后台钥匙交出去。攻击者拿到它可以管理用户与组织，虽然看不到明文凭据，但足以造成破坏：批量删账号、改组织关系、把所有人锁在外面。这在业务上的后果和泄露明文一样严重。

存放位置是第一个要收紧的地方。不要写进能被 Web 读到的目录，不要放在代码仓库里，不要贴在运维文档的正文里到处复制。它和数据库的管理员口令是同一级别的东西，应该用同一套机密管理机制托管，访问要留痕。很多团队在这一步是松的，因为"反正只是个内部服务"。

收起时机是第二个要收紧的地方。后台不是日常操作界面，做完用户与组织的调整就可以把它关掉，需要时再打开。长期开着一个平时不用的管理界面，等于长期暴露一个不必要的入口。这一条的实施方式通常是：需要进后台时临时配置令牌并启动，做完即撤。

如果必须长期启用，至少要加来源限制：只允许来自内网访问通道或者固定的几段来源地址访问后台路径，其他来源直接拒绝。这一层和后面提到的暴露面收敛思路是一致的——把入口收窄，而不是靠一个字符串口令硬扛全网的扫描。

令牌本身也要定期更换，流程和你换任何其他管理凭据一样：先在机密库里更新值，再让服务端加载新值，确认后台能进，最后销毁旧值。顺序不能反过来，否则会在中间态把自己锁在外面，而且在没有其他恢复手段的自建环境里，这个锁可能很难开。

登录限速与来源限制的攻击面收敛

密码库是团队的钥匙串，被撞库和被扫描的价值远高于一个普通站点。攻破它拿到的不是一条数据，而是通往其他系统的入口。因此它值得比普通站点更厚的防护，而不是同等防护。很多团队给对外业务站上了完整防护，却让密码库裸着，这是典型的权重倒挂。

至少要上两层，而且必须是性质不同的两层：登录限速、失败封禁、来源限制、隐藏在内网访问通道之后，这四层里选两层以上。限速挡的是自动化尝试的速率，来源限制挡的是可达范围，隐藏挡的是被发现的概率。三层叠起来的效果是乘数级的，只做一层则容易被绕过。

登录限速与失败封禁是成本最低、效果最直接的一层：连续失败的来源在一段时间内被拒绝，让大规模尝试变得不经济。配置时要注意误伤——同一个出口地址后面可能是一整个办公室，封禁粒度和时长要平衡，太粗会把正常用户一起挡住，太短则形同虚设。

第二层推荐来源限制或者内网访问通道。如果团队主要在固定办公地点活动，最省事的做法是根本不把服务暴露到公网，成员通过内网通道访问。公网完全不可见，被扫描到的概率大幅下降，这一层的收益通常高于再叠加几层应用层规则。代价是成员外出时多一步操作，对存着全公司钥匙的服务来说，多这一步是值得的。

还有一层容易被忽略的是基础运维卫生：系统与依赖的安全更新要及时跟上，服务端版本要跟随社区更新，备份目录的文件权限要对，日志要留够。这些事听起来老套，但对一个集中存放全部钥匙的服务来说，恰恰是最不能省的部分。真正的安全事故往往不是高级攻击造成的，是一个没人管的过期依赖或者一个权限开错的目录。

组织与集合的最小授权设计与离职流程

共享粒度由组织（Organization）与集合（Collection）决定。谁看得到哪一组凭据，要在这里收敛，而不是靠"大家都在一个账号里"这种省事做法。共用一个账号看起来简单，实际上放弃了全部授权控制，也放弃了审计能力——日志里全是同一个人的操作。

设计原则是按职能分组而不是按人分组：按"财务系统""生产环境""第三方服务"这类职能建集合，人员变动时改的是成员关系，不是凭据本身。按人分集合的后果是每次人员调整都要重新分发一批凭据，改一次乱一次，而且分发出去的副本收不回来。

最小授权的实操含义很朴素：默认不给，需要才给，定期复核。新人进来拿到的是他当前职能对应的集合，不是全部；项目结束后收回，不是留着。定期复核的周期建议跟着人事变动走，至少每季度过一遍集合成员名单，把已经不该在里面的人清出去。

离职流程要具体到步骤，并且写成文档：从所有集合中移除、从组织中移除、禁用账号、处理其个人库中属于公司的条目、最后轮换他接触过的全部凭据。中间那一步需要事先约定，因为管理员打不开他的个人库，唯一可行的办法是在职期间就禁止把公司独有凭据放进个人库。

最后一步轮换最常被跳过，也最关键。因为端对端加密意味着你无法确认离职者在权限有效期内是否导出过什么，服务端日志只能告诉你他访问过，不能告诉你他带走了什么。唯一能确定的是：轮换之后，他手里的那份副本失效。轮换清单可以直接从他所属的集合导出，这也是按职能分集合带来的另一个好处——它让轮换范围变得可枚举。

组织事件日志的保留窗口与导出责任

组织事件日志能看到谁在什么时候访问或改动了哪一条，这是事后追溯和合规举证的依据。当有人问"这条凭据在上周三之前被谁看过"的时候，能回答这个问题的只有这份日志。

但日志有保留与清理策略，不是永久留存。需要长期保存的团队必须提前规划导出：定期把日志拉出来，存进自己的归档系统，保留期限由你的合规要求决定，不由服务端的默认策略决定。把这件事做成定时任务，而不是想起来才做一次。

这里存在一个认知落差：很多人默认"系统里有日志，随时能查"。实际上默认策略可能是滚动清理，也可能被管理员手动清理过，或者因为一次数据目录迁移而丢失。等到要举证时发现只剩最近一小段，是非常被动的局面，而且无法补救。

导出频率取决于要求本身：按月导出对多数团队够用；有明确审计要求的可以按周甚至按天。导出的日志本身也要纳入备份范围——它和数据库是两类东西，别指望恢复数据库时日志会跟着一起回来。很多恢复演练只验证条目和附件，忘了验证日志，事后才发现追溯链条断了一段。

还有一个边界要讲清楚：日志记录的是访问与改动行为，不是明文内容。它能回答"谁动过"，不能回答"他看到了什么具体值"。在写内部合规说明或者对外承诺时，不要给出超出这个能力的表述，否则出事时会被追问得很尴尬。

导出的日志还要注意存放位置本身的安全性。它虽然不含明文，但包含了组织结构、成员名单、访问时间规律这类信息，对攻击者来说是有价值的侦察材料。因此日志归档应该和数据备份同等对待：加密存放、限制读取来源、纳入访问留痕。别把它图省事丢在一个谁都能列目录的地方，那等于把团队的权限地图公开出去。

最后一个实操建议是给日志导出加一个失败告警。定时任务最常见的失败方式是静默失败：脚本某天开始报错，没人看，几个月后才发现归档目录里空了一截。加一条简单的告警，比如导出后校验文件条数、异常时推送到运维频道，能避免这种"以为一直在存"的情况发生。

备份恢复演练怎么才算真的能恢复

"我们有备份"和"我们能恢复"是两件事，中间隔着一次演练。没有演练过的备份，本质上等同于没有备份，因为你对它的信任没有任何依据支撑。这句话在密码库这种低使用频率但高重要性的系统上尤其成立——它平时没人动，一出问题就是大事。

演练的最小形态：在一台独立的机器上，用最近一次备份完整重建一次服务，然后用客户端登录，检查条目数量、附件内容、组织与集合关系、以及管理后台是否可用。检查附件内容这一条最容易被略过，而它恰好是"空壳恢复"最容易暴露的地方。只验证能登录、能看到条目数量，是自我安慰。

演练频率建议和变更频率挂钩：大版本升级之后、存储路径调整之后、备份脚本改动之后，都要做一次。平时按季度做一次完整演练，按周做一次备份完整性检查，比如确认文件存在、大小合理、能解开、包含预期的表或者目录结构。完整演练耗时，完整性检查便宜，两者都要有。

演练要记录两个指标：恢复耗时与数据丢失窗口。前者告诉你能不能在可接受的时间内把服务还回去，后者告诉你会丢多久的数据。这两个数字才是你决定备份频率的依据，而不是拍脑袋定个"每天一次"。如果演练发现恢复要四个小时，那你的备份频率再高也解决不了可用性问题，该改的是恢复流程本身。

备份本身也要遵循多份原则：至少一份异地，至少一份离线。只放在同一台机器的另一个目录，机器故障时一起没了；只放在同一机房，机房级故障时一起没了。密码库的备份尤其值得加密之后再异地存放——条目本身是密文，但配置文件里的域名、令牌和结构信息同样敏感，不要因为"反正都是密文"就明文丢到对象存储里。

哪些团队不该自建密码库服务端

先说不建议的情况。团队里没有明确的运维责任人，或者这位责任人已经满负荷；没有能力做异地备份与恢复演练；对可用性的要求高于对数据位置的要求，比如成员分散在全国多地随时要用、中断十分钟都不可接受；需要有一个能追责的商业主体。这几条里命中任何一条，自建都会变成负担。

这些情况选托管服务更合适：托管方负责可用性与多地冗余，你只管人和策略；自建则反过来，恢复能力、演练、值班都要自己背。这不是技术能力的比较，是责任分配的取舍。很多失败的自建项目不是技术问题，是责任没有落到具体的人头上。

还有一种中间状态值得警惕：为了省钱而自建。密码库服务端本身资源占用极低，硬件成本确实不大，但把备份存储、监控告警、演练工时和故障时的值班成本一起算进去之后，总成本未必低于托管。省下来的钱很可能来自"还没出事"这个时间差，而不是真的效率更高。

适合自建的典型画像是：有专职运维或者明确的运维负责人，成员集中在少数几个办公地点或者已有内网访问通道，对数据存放位置有明确要求，愿意把恢复演练排进季度日程，并且接受管理员救不了主密码这个前提。符合这个画像的团队，自建的体验会相当好；不符合的，一开始就该看托管方案。

服务器租用上的起步配置与扩容顺序

如果决定自建，硬件上的门槛比想象中低。服务端本身单进程加一个数据库就能跑起来，资源占用明显低于官方服务端，对处理器和内存的压力主要来自并发连接数而不是计算量。起步阶段的瓶颈通常不在密码库应用本身，而在备份存储与网络可达性这两件事上。

存储要优先考虑：数据库文件、附件目录、图标缓存目录、以及备份的异地副本，这几份数据的总量会随时间增长，其中附件增长最快。给数据盘留出增长余量，并且把备份放在与应用不同的盘、最好不同的机器上。很多人按应用占用去估存储，一年后才发现是附件和备份把盘吃满了。

处理器与内存的起步配置按常规小型服务对待即可，不必为此上高配机型。扩容顺序建议是：先补齐备份与存储的冗余，再考虑计算资源。前者决定你能不能从故障里回来，后者决定你在高峰期能不能快一点。顺序搞反了，就是一台跑得飞快但备份没地方放的机器。

网络层面要提前想清楚暴露方式：公网直接暴露，还是放在内网访问通道之后。后者能显著降低被扫描和被撞库的概率，代价是成员在外网访问时多一步。对存着全公司钥匙的服务，多这一步是值得的，而且这一步还能和来源限制叠加，形成前面要求的那两层防护。

扩容的另一条路径是把后端数据库独立出来：从 SQLite 换成 MySQL 或者 PostgreSQL，可以单独部署、单独备份、单独扩容。什么时候换，前面已经给了判断依据——看并发写入强度和备份一致性需求，不看人数。独立数据库带来的运维复杂度是真实的，只有在症状出现时才值得付这个代价。

最后是监控。自建之后没有人替你盯服务状态，所以需要自己接一套最基础的检查：服务进程是否存活、端口是否可连、证书剩余天数、磁盘余量、备份任务最近一次成功时间。这几项覆盖了绝大多数会导致"突然用不了"的原因。证书剩余天数和备份最近成功时间尤其容易被忽略，而它们恰好对应两类最典型的突发故障。

把上面这些串起来看，自建团队密码库的工作量分布其实很清楚：搭起来只占很小一部分，备份与恢复占最大一块，反代配置、暴露面收敛、权限与流程各占一块。按这个比例分配精力，就不会出现"服务跑得很稳但一次都没演练过"的情况。

把容量账算清之后再谈机型

自建密码库这台机器上真正需要算的容量，不是应用能跑多大，而是数据能长多大、备份要放几份、异地副本放哪里。把这三笔账算清楚，配置自然就出来了，不需要在机型之间反复纠结。应用运行所需的资源在这个总量面前几乎可以忽略不计。

算法很简单：先估条目与附件的年增长量，乘以备份份数与保留周期得到备份容量，再乘以异地副本数得到总需求。算完之后拿这个总需求去选存储方案，剩下的处理器与内存按常规小型服务配置即可。机型、带宽与报价以实时信息为准，一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

如果算完发现备份容量需求远大于应用运行需求，这是正常的，也说明你的账算对了。那些"应用只用几个 G、备份却要几百 G"的方案并不浪费，多出来的部分正是你在故障时能够回来的全部依据。反之，如果备份容量和应用容量差不多大，通常意味着备份份数或者保留周期定得偏紧，值得重新过一遍。

上线前需要确认的几件事

一张可勾选的清单比任何说明都管用。上线前至少确认这几项：开放注册已经关闭；管理员令牌已生成并托管进机密库、后台在非必要时处于关闭状态；HTTPS 证书有效且自动续期已经验证过；WebSocket 升级头已放行且双设备同步验证通过；请求体上限在反代与服务端两头都已经放宽。

再确认备份这一组：备份任务覆盖数据库、附件目录、图标缓存目录、配置文件这四份；备份任务实际执行过至少一次且产物存在异地；恢复演练在一台独立机器上成功完成过一次，并且验证过附件内容；登录限速与来源限制至少上了两层。这几条里任何一条没打勾，都不算上线完成。

最后确认非技术项：全员已经被告知管理员无法找回主密码这件事；主密码的保管方式已经在团队内约定并写入文档；离职流程里的凭据轮换步骤已经存在且有负责人。这几条做完，团队密码库才算真的上线，而不只是"服务跑起来了"。跑起来只是第一步，能恢复、能追溯、能轮换，才是它真正开始发挥作用的时刻。