1Password、Bitwarden 与 KeePass：从团队共享到离职回收
一名外包工程师离场后，管理员立即从密码库移除了他的账号，审计页也不再显示任何 vault 或 collection 权限。两周后，旧的数据库管理密码仍被使用。调查没有发现平台越权：工程师曾在浏览器里复制过密码，笔记本离线缓存里还有共享项，项目群里还留着一次导出文件。管理员撤掉的是“以后从权威库读取”的能力，不是已经到达设备、剪贴板和人脑的秘密，更不是目标数据库接受旧密码的能力。
密码库解决的是保存、组织、授权和取用问题；凭据真正失效，必须由目标系统完成轮换或撤销。1Password、Bitwarden 和 KeePass 都能让个人不再把密码写进表格，但它们的控制面完全不同：前两者有账号、组织和服务端授权，KeePass 的权威对象则是一份由主密钥保护的 KDBX 文件。把三者只排成“功能对比”会漏掉最重要的工程事实：谁拥有数据、权限在哪一层生效、设备拿到副本后还能做什么、机器任务如何取用，以及团队怎样证明旧凭据已经不能工作。
先把一个密码拆成四层对象
团队口中的“密码”通常同时存在于四层。第一层是密码库中的权威记录，例如 1Password item、Bitwarden organization item 或 KeePass entry；第二层是授权关系，例如 vault、collection、group 或文件系统 ACL；第三层是客户端副本，包括加密缓存、解锁后的内存、剪贴板、浏览器表单、导出和备份；第四层是目标系统真正校验的凭据，例如数据库账号密码、SaaS 恢复码或 SSH 公钥。
这四层决定了事故处置顺序。先冻结或移除密码库访问可以阻止继续同步；随后盘点这个人或设备能够读取的全部项；再到目标系统轮换密码、吊销 token、删除公钥或使恢复码失效；最后用旧值做一次受控失败验证。若只看到“成员已删除”就结案，离线副本仍然有效。若只改目标密码却不更新权威项，团队会继续复制旧值并制造第二轮故障。
密码库中的历史版本也不是目标系统的回滚能力。恢复旧 item 只会恢复旧字符串；数据库、云账号或 SSH 服务是否仍接受它，要由目标端验证。团队台账至少要把 record_id、目标账号、访问组、凭据 owner、轮换方式、最后验证证据和旁路副本位置关联起来。记录标题可以让人阅读，稳定 ID 才适合自动化和审计。
1Password：vault 是授权边界，item 是使用对象
1Password 的人员链从 account 进入，一个 account 可以访问多个 vault，vault 内保存 item，item 再按 Login、Password、SSH Key 等类别组织字段。团队通常把人加入 group，再把 group 授权给 vault；不要用标签模拟权限，因为标签只是组织方式。管理 vault 不天然包含读取 item 的能力，查看、编辑、导出、复制分享和管理 vault 也是不同权限。官方的 团队 vault 权限说明还指出，允许导出意味着能把内容保存为其他应用可读的未加密文件，因此“可查看”和“可带走全部数据”不应默认绑定。
研发团队可以按环境与职责拆 vault，例如 catalog-dev、catalog-release、shared-emergency，但不能为每条密码建立一个 vault。vault 太粗会让无关人员一起获得高敏项，太碎则使授权关系难以复核。一个实用判断是：同一 vault 中的 item 是否拥有相同的数据 owner、人员集合、客户端访问策略、导出约束和离职轮换批次；任一答案不同，就应考虑拆分。
item 的 title 用于检索，字段才是程序读取的接口。自动化不要依赖易改名的显示标题，优先使用稳定 ID 或受控的 secret reference。op://vault/item/field 引用表达的是定位关系，不含字段明文，可以进入模板仓库；它仍会泄露 vault、item 与字段命名，命名中不要放客户名、事故代号或其他敏感拓扑。字段改名会使引用失效，移动 item、复制 item 和新建同名 item 也可能改变身份，变更时必须同时跑消费端验证。
安装 1Password 桌面端与 CLI，并确认身份链
交互开发机可同时安装官方桌面应用与 op CLI。桌面应用负责本地解锁、系统认证和浏览器集成，CLI 负责脚本化读取；启用桌面集成时，CLI 可以复用已解锁的桌面会话。CLI 也可以使用独立的交互式登录或 Service Account，服务器与 CI 不应为了得到 CLI 而安装桌面会话。官方 1Password CLI 入门列出了各平台入口，Windows 可使用：
winget install --id AgileBits.1Password.CLI --exact
Get-Command op | Format-List Source,Version
op --version使用桌面集成时，按应用的 Developer 设置启用 CLI 集成并保持应用解锁，然后运行：
op vault list
op whoami成功证据不是终端出现一长串 JSON，而是 op whoami 返回预期 account，op vault list 只列出当前人员应访问的 vault。若命令提示未登录，先区分桌面集成未启用、应用已锁定、多个 account 选错和企业策略禁止集成；不要把 account password 或 Secret Key 写进脚本绕过交互认证。
代理网络还要分别验证登录服务、item API 和软件更新入口。能下载 CLI 不代表能访问团队 account；企业 TLS 检查可能让客户端报证书链错误。正确修复是向受控系统信任库分发企业根证书，并确认代理不记录请求体，而不是关闭证书校验。桌面应用、浏览器扩展和 CLI 的版本基线应由软件分发系统记录，安装包与扩展只从官方发布入口取得。
用 1Password 跑通一条合成共享链
在管理页创建实验 vault catalog-demo，只给实验 group 查看权限；在桌面应用中创建 Login item demo-api，用户名填 demo-user，密码使用客户端现场生成的随机值，不把值粘贴进命令、文档或聊天。然后创建只含引用的模板 .env.op：
DEMO_USER=op://catalog-demo/demo-api/username
DEMO_PASSWORD=op://catalog-demo/demo-api/password用一个只判断“值是否存在且用户名是否匹配”的临时脚本消费它，避免把密码打印出来：
// verify-credential.mjs
import { createHash } from "node:crypto";
const user = process.env.DEMO_USER;
const password = process.env.DEMO_PASSWORD;
if (user !== "demo-user" || !password || password.length < 16) {
console.error("credential_contract_failed");
process.exit(2);
}
const fingerprint = createHash("sha256").update(password).digest("hex").slice(0, 12);
console.log(JSON.stringify({ user, loaded: true, fingerprint }));op run --env-file .env.op -- node .\verify-credential.mjs
Remove-Item .\verify-credential.mjs,.\.env.op预期输出只有 loaded: true、合成用户名和不可逆短指纹，没有 secret 明文。op run 把解析后的值放进子进程环境；这比永久 .env 少一个磁盘副本，但环境变量仍可能被子进程、崩溃转储、调试器或错误日志读取。处理高敏凭据时，应优先让目标程序从受限文件描述符或专用 SDK 读取，并关闭 shell trace。
反向实验把实验人员移出 group，锁定并重新解锁客户端，再运行相同命令。可信失败是 op 无法解析该引用或返回无权访问，而不是脚本还能读到旧环境变量。必须启动新终端和新子进程，因为一个已经得到 DEMO_PASSWORD 的进程不会因服务端撤权而自动擦除内存。最后在目标测试服务轮换合成密码，用旧值请求一次并得到确定的认证失败，才能证明离职回收闭环。
这个实验还要分别观察在线撤权与离线副本。暂停或删除成员后，联网且已解锁的 1Password 应移除其团队数据；官方的 成员移除说明同时明确，离线设备上的项目可能一直可读，直到设备联网并再次尝试解锁。因而管理员要把该成员曾有权查看的 vault 作为轮换集合，不能只按审计中出现过的 item 处理。清理实验时先删除合成 item，再移除实验 group 对 vault 的权限；确认留任账号仍能访问需要保留的对象后删除实验 vault，并清除 .env.op、临时脚本、终端子进程和任何共享链接。
1Password 的机器接入不能复用员工会话
交互式 CLI 可以借助桌面应用和系统认证；CI、容器与无头服务器需要非人身份。1Password Service Account 是独立于员工的机器身份，可限制可访问的 vault；其可见操作与报告能力取决于团队方案和管理员权限。官方 Service Account 说明把它用于共享环境、自动访问和无头认证。它的 token 是高敏长期材料：只在 CI secret store 中保存，限制环境与分支，轮换时创建新 token、切换消费者、验证新 token、撤销旧 token，不能把 token 放进镜像层或 Compose 文件。
# CI 平台中 OP_SERVICE_ACCOUNT_TOKEN 来自受保护的 secret，不写入仓库。
steps:
- name: verify synthetic credential
shell: bash
env:
OP_SERVICE_ACCOUNT_TOKEN: ${{ secrets.OP_SERVICE_ACCOUNT_TOKEN }}
run: |
set +x
op read 'op://catalog-demo/demo-api/username' >/dev/null
op run --env-file .env.op -- node verify-credential.mjsService Account 适合 CLI 或 SDK 直接访问托管服务。1Password Connect 则是在团队基础设施中部署 API 服务，让应用通过 Connect token 读取被授权 vault；它需要 Connect 凭据文件和访问 token，并引入镜像升级、TLS、网络分区、容量、备份和自身可用性。官方 Connect 部署入口给出 Docker 与 Kubernetes 形态。Connect 不是“把个人密码库复制到容器”：凭据文件、token、服务日志和缓存都进入新的信任边界，出口网络应只到必要的 1Password 服务，访问 token 只给调用应用，平台团队还要监控同步失败与陈旧数据。
自动化需要大量短期数据库凭据、按工作负载动态签发、租约到期自动撤销时，密码库 item 不是理想的颁发引擎。Service Account 解决“谁可以读取静态记录”，不会让目标数据库里的密码自动变成短期凭据。此时应由 Vault、云 secret manager 或目标系统身份联合签发，1Password 只保留恢复材料、人工审批入口或 bootstrap 凭据。
1Password 的退出链从受控导出开始。1Password 导出说明明确，1PUX 与 CSV 都是未加密文件；CSV 只覆盖标题、网站、用户名、密码、一次性密码等有限字段，不能拿“文件已生成”代替恢复验证。桌面端的文件导出不包含 passkey；当前只有 iOS 与 Android 可以通过 FIDO Credential Exchange Protocol 把 passkey 直接导出到兼容应用，这条移动端迁移链与 1PUX/CSV 是两种不同机制。使用 SSO 解锁的账号不能直接导出，需要团队管理员先关闭该账号的 Unlock with SSO。管理员应先在隔离设备导出一组合成 item，记录文件 hash 与保管人，在候选工具中导入并核对自定义字段、附件、TOTP、SSH key 与 passkey 的迁移限制，再销毁下载目录、回收站和同步盘副本。真实迁移中，凡经过明文导出的凭据都进入轮换队列；关闭账号、Service Account 或 Connect 之前，还要导出所需审计证据并验证新平台的人员权限和机器任务已经接管。
1Password SSH agent 代理签名，不替你撤销服务器公钥
SSH Key item 可以保存密钥，1Password SSH agent 通过 agent 协议向 ssh 提供签名，私钥不必导出为普通文件。安装桌面应用、添加或生成 SSH Key item、在 Developer 设置中启用 SSH agent，再按平台把 SSH_AUTH_SOCK 指向 1Password agent。官方 SSH agent 文档是平台配置的权威入口。
ssh-add -L
ssh -v demo-user@host.examplessh-add -L 只应列出获准使用的公钥；ssh -v 的证据是客户端选择了预期指纹并由 agent 完成签名，不是把私钥打印出来。若出现 Too many authentication failures，要限制 agent 暴露的 key 或在 SSH config 中绑定 IdentityFile 对应公钥；若本机 app 已锁，签名请求应被阻断或要求重新批准。
删除 vault 权限会阻断以后从 1Password 使用 key，但目标服务器的 authorized_keys、Git 平台 deploy key 和代码签名信任不会自动删除。离职时必须从目标端移除公钥并验证旧 key 认证失败。若公钥已复制到多台主机，CMDB 或 IaC 应能按指纹反查全部落点；否则密码库的审计只能证明谁可能拿到 key，不能证明 key 在哪里仍被信任。
Bitwarden：个人 vault、organization 与 collection 不能混用
Bitwarden 客户端把个人项和组织项显示在一个 Vaults 视图中，但所有权不同。My vault 中的 item 属于个人；移动到 organization 后，item 归组织所有，并至少属于一个 collection。collection 将组织项分组并赋予成员或 group 权限。官方 Collections 说明特别强调：嵌套 collection 只改变显示层级，不继承父 collection 的 item、访问或权限。把 Production 放在 Engineering 下面，不会自动把工程组权限传给生产项，也不会自动隔离它。
folder 是个人整理工具，collection 才是组织共享边界；group 用来批量关联人员与 collection。把同一凭据复制到多人个人 vault 会失去组织所有权与统一更新能力。共享动作应把 item 移入 organization 并选择 collection，而不是通过聊天发送值。移入前确认目标 collection 的人员和权限，因为归属改变后，原创建者可能不再拥有管理权。
Password Manager 和 Secrets Manager 也是不同对象面。Password Manager 的 bw CLI操作 login、secure note、organization item 与 collection；Secrets Manager 的 bws CLI围绕 project、secret、machine account 和 access token。官方已将 Secrets Manager 的 service account 称为 machine account，它代表应用或流水线，并按 project 配置 Can read 或 Can read, write。当前 Secrets Manager CLI 已提供 secret create、secret edit、secret delete 以及 project 写命令，实际读写能力由 access token 对应 machine account 的 project 权限约束；生产读取任务仍应只授予 Can read，把写入与删除交给独立发布身份，并用 bws secret --help、允许写入和只读拒绝两组实验确认安装版本与服务端权限一致。不能给 CI 一个员工的 BW_SESSION，也不能把 organization collection 当成 Secrets Manager project 的别名。
安装 Bitwarden 客户端与两套 CLI
人员设备从官方客户端入口安装桌面应用和浏览器扩展，企业分发要固定服务器区域或自托管 URL、扩展来源、锁定策略和更新通道。Password Manager CLI 可以使用官方原生包；已经受控使用 Node.js 的开发机可按 Bitwarden CLI 文档安装：
npm install -g @bitwarden/cli
Get-Command bw | Format-List Source,Version
bw --version
bw statusbw login 建立登录状态，bw unlock 才生成可解密 vault 的 session key。BW_SESSION 是解密会话材料，不应写进 profile、日志或 CI 变量库；使用结束执行 bw lock 或 bw logout。bw sync 只从服务器拉取加密 vault，客户端创建、编辑或删除则会自动推送。故障时先看 bw status 的服务器 URL、同步时间与 locked/unlocked 状态，避免在错误的自托管实例上反复重置密码。
bw login
$env:BW_SESSION = bw unlock --raw
bw sync
bw status
# 完成实验后：
bw lock
Remove-Item Env:BW_SESSION -ErrorAction SilentlyContinueSecrets Manager CLI 使用 bws，从官方 SDK releases 取得二进制并校验来源，或使用官方容器入口。它用 machine account access token 认证；token 决定能访问哪些 project 与 secret。官方 Secrets Manager CLI提醒 token 可以通过环境变量或参数传入，但命令行参数容易进入进程列表和 shell 历史，团队应使用受保护的环境注入并关闭 trace。
bws --version
bws project list
bws run --help这三个命令只有在 BWS_ACCESS_TOKEN 来自受控临时环境时才构成最小验证。bws secret list 或 bws secret get 可能把值写到标准输出，不能把它们当作探活命令；读取验证应改用受控子进程，只输出成功状态和不敏感版本标签。机器账号的 token 轮换与 Password Manager 主密码变更是两条不同链路，不能互相替代。
bws 可在本机配置目录保存加密状态文件以减少重复认证和速率限制，但状态目录仍是需要盘点、限制权限和离职清理的副本；一次性 runner 可选择不保留状态。机器账号 access token、bws 状态文件与 Password Manager 主密码是三条不同生命周期，不能互相替代。
用 Bitwarden 验证组织所有权与 collection 权限
先在实验 organization 创建 catalog-demo collection，建立只读 group 并加入测试成员。用桌面或 Web 创建一个合成 Login item，选择 organization 与该 collection，用户名填 demo-user，密码由客户端生成。同步 CLI 后，只读取元数据和密码指纹：
$env:BW_SESSION = bw unlock --raw
bw sync
$item = bw list items --search "catalog-demo-api" | ConvertFrom-Json |
Where-Object { $_.organizationId } | Select-Object -First 1
if (-not $item -or -not $item.collectionIds) { throw "organization_item_missing" }
$secret = bw get password $item.id
$hash = [Convert]::ToHexString(
[Security.Cryptography.SHA256]::HashData([Text.Encoding]::UTF8.GetBytes($secret))
).Substring(0,12)
[pscustomobject]@{
itemId = $item.id
organizationOwned = [bool]$item.organizationId
collectionCount = $item.collectionIds.Count
fingerprint = $hash
}
Remove-Variable secret成功输出应显示 organizationOwned: True、至少一个 collection 和短指纹。脚本故意不打印密码。若搜索命中多个同名项，必须改用稳定 item ID；bw get 对非唯一字符串会失败，这恰好能阻止自动化悄悄选择错误凭据。
反向实验从 collection 移除测试成员或 group，在线同步后重新解锁并查询 item。预期是 item 不再出现在组织视图，按旧 ID 读取失败。然后把设备断网再观察：官方 永久移除成员说明指出，离线设备会缓存包含组织项的只读副本，部分客户端在移除后短时间仍可能访问它。这个事实决定了离职动作必须同时轮换成员曾访问的目标凭据；“服务端列表里看不到他”不是旧值失效证据。
清理实验时，在组织端删除合成 item 或移入回收站，确认其他授权成员同步后不再使用；从 group 移除测试账号；执行 bw lock、清除 BW_SESSION，并删除任何导出。删除 collection 前先确认没有仍需保留的 item 和唯一管理者，避免把权限对象当普通文件夹清理。
Bitwarden 的离职链要区分撤销、移除和删除账号。先撤销组织访问可切断服务器端同步，保留调查窗口；确认组织所有的 item、collection 与机器账号已由留任 owner 接管后，再移除成员。成员的个人 Bitwarden 账号不会因移出 organization 而被删除，个人 vault 中的工作凭据也不会自动转为组织所有。离线设备缓存的组织项按已经披露处理，目标端必须轮换。退出平台前分别导出个人 vault 与 organization 数据：明文 CSV/JSON 是敏感副本；加密 JSON 还要区分密码保护型与绑定账号加密密钥的类型，并用独立测试账号实际导入。Password Manager 导出说明指出，只有 JSON 导出包含 passkey、SSH key、card 和 identity；带附件的 ZIP 当前只适用于个人 vault；任何格式都不包含回收站和 Send。Secrets Manager 导出还要单独执行，其 JSON 只包含 project 与 secret，不包含 machine account 和 access token，因此退出前必须另建机器身份、权限与 token 清单。随后清除导出、BW_SESSION、bw 缓存与 bws 状态目录，最后才停用自托管服务或合同账号。
Bitwarden Secrets Manager 承担机器 secret，而不是个人 vault
流水线应使用 machine account 访问 project 中的 secret。创建 catalog-demo project、合成 secret 和只读 machine account，给它仅该 project 的 Can read 权限，再签发 access token。人可以管理 project，作业只读取需要的 secret。官方 Machine Accounts说明，机器账号可按 project 授权，删除机器账号不会删除关联 secret；这让身份撤销和数据删除成为两个独立动作。
steps:
- name: run with project secrets
shell: bash
env:
BWS_ACCESS_TOKEN: ${{ secrets.BWS_ACCESS_TOKEN }}
BWS_PROJECT_ID: ${{ vars.BWS_PROJECT_ID }}
run: |
set +x
bws run --project-id "$BWS_PROJECT_ID" -- node verify-credential.mjs正向证据是作业身份只能列出授权 project，验证脚本得到合成值且日志无明文。反向实验应创建另一个 project，确认同一 token 无法读取；撤销 token 后，新作业认证失败；已经注入到旧进程内存的值不会自动消失，因此还要终止旧作业并轮换目标凭据。删除 machine account 前导出必要的事件证据，盘点所有 token 注入位置，再验证没有消费者仍依赖它。
Secrets Manager 能为机器提供受控静态 secret，但 access token 本身仍是 bootstrap 凭据。Access token 说明显示，创建 token 时默认到期时间是 Never，生产任务必须显式选择有限到期时间，并把到期告警、双 token 切换和旧 token 撤销纳入发布流程；token 值只在创建时显示，Bitwarden 不保存可供再次取回的副本。支持工作负载身份联合的环境应优先使用短期身份换取访问；若只能使用 token，还要限制 runner、环境、分支和网络。个人 Password Manager CLI 的 API key 或 session key 不应成为无人值守服务的长期身份。
KeePass：KDBX 文件就是权威边界
KeePass 2.x 把数据保存在 KDBX database 中。database 内有 group，group 内有 entry；entry 包含 title、username、password、URL、notes、自定义字段、附件、历史版本和自动输入设置。database 由 master key 加密，master key 可以由 master password、key file 以及特定平台组件组合而成。官方 Master Key 文档明确：只要组合中的任一组件丢失，数据库就无法恢复，没有后门。
这套模型没有 SaaS organization、服务端 group、按 entry 的在线撤权或集中 item 审计。文件服务器 ACL 能阻止以后下载 KDBX，却不能收回员工已经复制的 KDBX。知道 master password 且拥有 key file 的人，可以离线打开旧副本。团队共享 KeePass 的安全性因此取决于三件事：KDBX 副本分布是否可盘点，master key 组件是否分离保存，目标凭据是否能在人员变化时批量轮换。
group 是数据库内的组织结构，不是强访问控制。把生产条目放进 Production group 不会让只应访问开发条目的成员看不到它；能解锁同一 database 的人原则上能读取其中全部 entry。需要不同人员集合时，应拆成不同 database，并为每份 database 使用独立 master key、存储 ACL、备份与 owner。拆库会增加同步和恢复成本，但这是 KeePass 模型下真实的权限边界。
安装 KeePass 并创建可恢复的临时库
Windows 从 KeePass 官方下载页选择 2.x installer 或 portable ZIP。installer 写入程序目录并使用用户配置目录，portable 版可以解压即用并把配置放在应用目录。官方 安装与便携说明给出了更新和静默安装参数。企业分发应校验发布包来源，明确插件白名单，并记录 portable 副本位置；“便携”不等于“不留痕”，数据库、配置、最近文件、操作系统缓存和备份仍会留下副本。
$keepass = Get-Command KeePass.exe -ErrorAction Stop
$keepass | Format-List Source,Version
(Get-Item $keepass.Source).VersionInfo |
Select-Object FileName,FileVersion,ProductVersion桌面正向实验在临时目录创建 catalog-demo.kdbx：选择 File -> New，使用现场生成的长合成主密码；新增 Catalog/Demo group；在其中创建 demo-api entry，用户名为 demo-user，密码由 KeePass 生成器产生；保存后锁定 workspace，再用同一 master key 解锁。可信证据是锁定时 entry 不可读，重新解锁后 title、group 与密码指纹一致，KDBX 文件修改时间随保存更新。
如果加入 key file，要让数据库与 key file 位于不同控制域。KDBX 放在受控文件存储，key file 可放在单独的硬件介质或受限 secret store；不要把两者放进同一个同步文件夹。更换 key file 必须通过 File -> Change Master Key 正式重写数据库，直接编辑或替换 key file 会失去访问。恢复演练要在隔离机器上用备份 KDBX、主密码和 key file 全部打开一次，而不是只检查三个文件“都存在”。
KDF、锁定与剪贴板决定 KeePass 的离线攻击面
KDBX 4.1 文件包含经过认证的加密结构、KDF 参数和加密后的 XML 数据。KDF 把 master key 组件转换成数据库加密密钥，增加每次猜测成本。KeePass 2.x 可配置 AES-KDF 与 Argon2 变体；官方 数据库设置建议通过本机基准选择转换成本。团队不应抄一个固定迭代数，而要在最慢的受支持设备上测量解锁时间，在可接受交互延迟内提高内存与计算成本，并把 KDF 参数随数据库备份。参数过低会降低离线猜测成本，参数过高则可能让老设备无法在应急窗口解锁。
锁定 workspace 时，KeePass 关闭 database，只保留路径和少量视图参数；再次解锁等同重新打开数据库。配置应在系统锁屏、用户切换、睡眠和空闲后自动锁定。官方还提供 enforced configuration，可由管理员强制剪贴板自动清除、会话切换锁定和休眠锁定。它只能约束受管 KeePass 实例，无法阻止恶意进程在明文已进入剪贴板时立即读取。
Auto-Type 通过模拟按键把字段送到匹配窗口，减少剪贴板暴露，但目标窗口匹配错误仍会把密码输入到聊天框或钓鱼窗口。KeePass 本体的 Auto-Type 不要求浏览器插件；额外浏览器集成插件会增加代码执行和供应链边界。官方 Auto-Type 文档说明 entry 与 group 可配置窗口关联和序列。高敏 entry 应精确匹配窗口与 URL，不使用宽泛通配；执行前观察焦点和窗口标题，不把 KeePass 以管理员身份常驻来解决普通窗口权限问题。
KeePass 的命令行可以打开指定 database、触发 Auto-Type 或锁定现有 workspace，但它不是带租约、工作负载身份和逐次审计的 headless secret API。KPScript 能扩展单次操作，仍需要安全交付 master key；把主密码放进 -pw: 参数会暴露到命令历史和进程参数。-pw-stdin 不把值放进命令行，却仍要求调用方和管道可信，也不会补上机器身份或逐项授权。需要 CI 动态取值、短期凭据或自动撤销时，应使用专用机器 secret 平台；KeePass 更适合作为离线恢复库或受控人工入口。
桌面端安装后可以用命令行验证程序入口和锁定动作，但不要把 master password 拼进参数：
& (Get-Command KeePass.exe).Source --help
& (Get-Command KeePass.exe).Source --lock-all第一条应打开或显示当前发行版支持的命令行帮助，第二条只作用于正在运行的 KeePass workspace。若无人值守脚本必须读取 entry，问题已经从“是否有 CLI”变成“谁向脚本交付完整 master key、脚本能否导出整个数据库、失败后怎样撤销”；KeePass 本身没有适合 CI 的逐任务机器身份，因此不能用 -pw: 或共享 key file 假装补齐这条控制面。
用 KeePass 做正反实验，并看见文件共享的极限
完成临时库后，复制 catalog-demo.kdbx 为 offline-copy.kdbx，模拟成员设备已经同步一份加密副本。随后在主库删除测试 entry、保存并清空回收站，再打开离线副本。只要旧 master key 仍可用，旧 entry 仍能读取。这不是 KeePass 漏洞，而是离线加密文件的必然语义：新文件无法远程擦除旧文件。
$lab = Join-Path $env:TEMP ("keepass-lab-" + [guid]::NewGuid().ToString("N"))
New-Item -ItemType Directory -Path $lab | Out-Null
# 在 KeePass 中把临时数据库保存为 $lab\catalog-demo.kdbx 后执行：
Copy-Item "$lab\catalog-demo.kdbx" "$lab\offline-copy.kdbx"
Get-FileHash "$lab\catalog-demo.kdbx" -Algorithm SHA256
Get-FileHash "$lab\offline-copy.kdbx" -Algorithm SHA256删除主库 entry 后，两份文件 hash 会分叉；旧副本仍能解锁就是反向证据。真正的回收动作是到目标测试服务轮换合成密码或删除公钥，再用离线副本中的旧值验证认证失败。若整个 database 的成员集合变化，还应更换 master key 并将新 KDBX 分发给留任人员；这只能保护新版本，旧数据库里的旧凭据仍必须逐项在目标端失效。
多成员编辑同一 KDBX 时，不要依赖云盘“最后写入获胜”。KeePass 2.x 有内建同步，会合并两份数据库并把合并结果写回；直接覆盖则可能丢失并发变更。官方 Synchronization说明保存时会检测磁盘文件变化并提示覆盖或同步。团队要保留版本化备份，规定谁可以同步，冲突后核对 entry 历史，并把一次恢复演练纳入升级门禁。
实验清理顺序是先关闭 KeePass、确认主库不再需要、删除临时 KDBX 与离线副本、清空操作系统回收站，再检查同步客户端版本历史和备份策略是否自动留存。SSD、云盘和企业备份通常无法保证“安全覆写”，因此敏感实验只能使用合成值；真实凭据一旦进入不受控 KDBX，就按已复制处理并轮换，不能依赖文件删除消除风险。
& (Get-Command KeePass.exe).Source --lock-all
Remove-Item -LiteralPath $lab -Recurse -Force
Test-Path -LiteralPath $lab # 预期 FalseKeePass 的共享、离职和导出实际上是一条文件治理链。共享时只把 KDBX 放入受控文件存储，按 database 拆分人员集合，并通过另一控制域交付 key file；离职时先撤销文件存储 ACL、收回受管设备，再更换留任库的 master key，但仍假定离职者持有旧 KDBX。随后逐项轮换旧库中可读的目标凭据，用旧值失败作为结案证据。KDBX 可作为加密离线副本，CSV、HTML、XML 等导出则是明文或降级格式；导出前要确认接收格式会丢失哪些字段、附件和历史，导入候选库后做字段级核对，最后清除中间文件。因为 KeePass 没有服务端逐人审计，文件服务器下载日志、终端管理记录、备份目录和轮换台账共同承担证据链。
三套工具共用的本地合成撤权实验
没有 1Password 或 Bitwarden 测试组织，也未安装 KeePass 时，可以先运行下面的教学模型。它不调用加密算法或厂商 API，不能证明任何产品的撤权时序；它只演示一个必须由三套工具各自实验验证的状态不变量：在线读取被阻断后，已下发的离线副本仍可能保留旧值；只有目标端轮换后，旧副本才失去业务效力。脚本只生成随机合成值，只输出 hash 指纹，并在退出前清空临时目录。
// password-vault-lifecycle-lab.mjs
import { createHash, randomBytes } from "node:crypto";
import { mkdtemp, rm, writeFile, readFile } from "node:fs/promises";
import { tmpdir } from "node:os";
import { join } from "node:path";
const dir = await mkdtemp(join(tmpdir(), "password-vault-lab-"));
const fp = (value) => createHash("sha256").update(value).digest("hex").slice(0, 12);
const randomSecret = () => `synthetic-${randomBytes(24).toString("base64url")}`;
const authority = {
itemId: "catalog-demo-api",
version: 1,
readers: ["developer", "leaver"],
value: randomSecret(),
};
const target = { acceptedFingerprint: fp(authority.value) };
const readOnline = (actor) => {
if (!authority.readers.includes(actor)) throw new Error("ACCESS_DENIED");
return authority.value;
};
const authenticate = (value) => fp(value) === target.acceptedFingerprint;
try {
const oldValue = readOnline("leaver");
await writeFile(join(dir, "offline-cache.json"), JSON.stringify({ value: oldValue }));
console.log(JSON.stringify({ phase: "positive", online: authenticate(oldValue), fp: fp(oldValue) }));
authority.readers = authority.readers.filter((name) => name !== "leaver");
try {
readOnline("leaver");
throw new Error("revocation_test_did_not_fail");
} catch (error) {
if (error.message !== "ACCESS_DENIED") throw error;
console.log(JSON.stringify({ phase: "revoked", onlineRead: "ACCESS_DENIED" }));
}
const cached = JSON.parse(await readFile(join(dir, "offline-cache.json"), "utf8")).value;
console.log(JSON.stringify({ phase: "offline-copy", oldValueStillWorks: authenticate(cached), fp: fp(cached) }));
authority.value = randomSecret();
authority.version += 1;
target.acceptedFingerprint = fp(authority.value);
console.log(JSON.stringify({
phase: "rotated",
version: authority.version,
oldValueStillWorks: authenticate(cached),
newValueWorks: authenticate(readOnline("developer")),
}));
} finally {
await rm(dir, { recursive: true, force: true });
console.log(JSON.stringify({ phase: "cleanup", removed: true }));
}node .\password-vault-lifecycle-lab.mjs
Remove-Item .\password-vault-lifecycle-lab.mjs预期顺序为：正向读取成功；撤权后在线读取返回 ACCESS_DENIED；离线旧值在轮换前仍可认证；轮换后 oldValueStillWorks 变为 false、newValueWorks 为 true；临时目录清理成功。任何产品的离职流程如果无法给出同等证据，就还没有关闭旧凭据风险。
浏览器、剪贴板和共享链接是高频旁路
浏览器扩展运行在浏览器攻击面中，负责 URL 匹配、填充、保存和解锁协同。只安装官方扩展，关闭浏览器自带密码管理器避免双写，禁止在不受管 profile 中使用工作 vault。自动填充不能只看页面标题，要核对 scheme、完整域名、端口和 iframe；HTTP、相似域名和不受信 iframe 应触发拒绝或人工确认。1Password 可按 vault 限制应用与浏览器访问，Bitwarden 可配置 URI match 与 blocked domains；KeePass 原生 Auto-Type 则依赖窗口关联，额外插件由团队单独做供应链准入。
复制密码后，系统剪贴板管理器、远程桌面、跨设备剪贴板和会议软件都可能获得副本。设置短清除时间有帮助，但不是瞬时撤销。自动化优先使用 op run、bws run 或进程级注入；交互登录优先使用受控自动填充或 Auto-Type；必须复制时关闭跨设备剪贴板，并避免在录屏、日志采集或 AI 助手读取剪贴板的环境操作高敏项。
共享链接传递的是 item 的一个副本或可访问视图，不等于把接收者加入长期 vault。发送前设置接收者限制、最短过期时间和一次性用途，发送后记录 owner；任务结束主动删除链接。1Password 提供共享历史和删除链接入口，官方 安全共享 item说明管理员还可从审计入口定位共享活动。Bitwarden Send 与 organization collection 也不是同一授权模型：Send 到期或删除不代表接收者没有复制内容，链接 secret 仍应按已披露处理。
导出、恢复和紧急访问要按可读副本治理
三套工具各自章节中的导出链最终遵守同一条规则：1Password 1PUX/CSV、Bitwarden 明文 CSV/JSON、KeePass CSV/XML 都按明文处理；Bitwarden 加密 JSON 与 KeePass KDBX 虽可作为加密副本，也必须同时保管解密材料并验证兼容客户端。恢复演练必须验证“需要的数据实际在备份里”，不能只检查文件生成成功。
每次导出都要创建临时工单：导出人、理由、数据集合、文件 hash、存储位置、加密方式、接收者、删除时点和复核人。迁移时先在隔离测试库导入，核对 item 数、附件、历史、TOTP、SSH key 和自定义字段，再切换客户端；切换成功后销毁明文中间文件，并检查下载目录、回收站、云同步、终端历史和 DLP 告警。导入通常不会自动去重，重复执行前要有幂等策略和回滚快照。
紧急恢复不是共享一个永不过期的管理员密码。1Password 团队应至少有两个能执行 account recovery 的责任人，恢复会生成新的登录材料并要求设备重新登录；Emergency Kit 是账号恢复材料，不应和已解锁工作设备放在一起。Bitwarden 的 Emergency Access 面向个人 vault，可授予查看或接管，并经过等待与批准；官方 Emergency Access明确接管会替换主密码并移除原有两步登录方式，它不等于组织离职接管。组织账号恢复、人员继任与个人紧急访问要分别演练。KeePass 没有服务端恢复，恢复能力完全取决于 KDBX、master password、key file 和兼容客户端的可用副本。
离职与失窃设备必须做两阶段回收
第一阶段是立即阻断同步和交互：在身份提供方禁用账号，暂停或移除密码库成员，撤销活跃共享链接和机器 token，隔离失窃设备，并保留审计证据。第二阶段是按“曾经可读”而不是“最近使用”盘点凭据，逐一在目标系统轮换或撤销。审计日志可能只记录实际访问，也可能受客户端版本、离线状态和保留窗口限制；没有访问事件不能证明没有看过。
1Password 官方的 成员移除说明指出，设备需要联网且应用解锁才会移除数据，离线设备可能在下一次联网解锁前继续访问。Bitwarden 也明确警告离线设备会缓存组织项的只读副本。KeePass 更直接：旧 KDBX 副本永远不会收到撤权事件。因此三者都要采用同一结案标准：旧账号不能同步，旧设备被隔离，旧共享链接失效，所有可读目标凭据已轮换，旧值受控验证失败，新值由留任身份验证成功。
offboarding_evidence:
principal: synthetic-leaver
access_revoked:
identity_provider: verified
password_vault: verified
shared_links: reviewed
machine_tokens: revoked_or_not_applicable
replicas:
managed_devices: quarantined_or_wiped
offline_cache: assumed_exposed
exports: located_and_destroyed
keepass_copies: inventoried
target_credentials:
- record_id: catalog-demo-api
target_owner: platform-demo
rotated: true
old_value_rejected: true
new_value_verified: true
approvers: [security-owner, system-owner]若离职账号曾能管理 vault 或 collection，要按其最大可见范围处理，而不是只看当前成员列表。若员工在个人 vault 保存了工作凭据，组织可能无法查看或回收；入职时就要规定工作项的组织所有权，并用报告或抽查纠偏。离职当天才要求员工“把密码交出来”，已经太晚。
选型时看控制面，不看密码数量
1Password 适合需要托管团队 vault、细分客户端权限、Service Account、Connect、SSH agent 和集中报告的组织；代价是账号与服务依赖、能力边界随团队方案变化，以及机器 token、Connect 服务和导出形成的新治理面。Bitwarden 适合需要组织 collection、可选自托管、Password Manager 与 Secrets Manager 分离控制面的团队；必须理解个人与组织所有权、离线缓存、两套 CLI 和自托管升级责任。KeePass 适合个人、极小团队、离线应急库、隔离网络或需要单文件可携性的场景；代价是缺少服务端逐人撤权、按 entry ACL、集中审计和原生机器 secret 颁发。
不要按“只有几十条密码所以 KeePass 足够”做决定。真正决定选型的是人员变动频率、设备可管理程度、离线需求、机器访问比例、审计保留、恢复时间目标、出口网络、可接受的 SaaS 依赖和运维 owner。一个五人团队如果频繁外包且必须逐人撤权，可能比百人固定团队更需要组织控制面；一个大团队的离线应急库则可能仍适合独立 KeePass，但其中只能保存少量恢复材料，并用严格双人保管和定期演练约束。
成本也不只看订阅。托管平台的总成本包含座席、机器身份、日志导出、SIEM 存储、客户端分发、支持与退出演练；自托管 Bitwarden增加数据库、备份、邮件、TLS、升级、监控和值班；KeePass 的软件成本低，却把权限拆库、同步冲突、离职轮换、插件审查和恢复验证转移给团队。价格与套餐会变化，采购时只根据官方当前能力、合同和试验租户核定，不在架构基线中写死数字。
长期治理要让每个副本都有责任人
团队每个 vault、organization collection、Secrets Manager project 和 KeePass database 都需要业务 owner 与技术 owner。业务 owner 确认谁应该访问、哪些 item 仍有效；技术 owner 负责客户端版本、自动化、备份、轮换、审计导出和恢复。高敏容器还要有独立复核人，避免同一人既能读取全部密码、又能修改审计与恢复材料。
持续治理不靠年末盘点。人员和 group 变化触发访问复核；目标系统权限变化触发凭据范围复核；客户端或插件升级触发兼容与供应链检查；导出和共享链接触发限时清理；机器 token 到期前触发双凭据轮换；每个恢复周期用隔离环境实际打开备份。指标应观察“无 owner 容器数”“超期共享链接数”“未轮换的离职暴露项数”“旧值拒绝证据缺失数”“机器身份使用个人会话数”和“恢复演练失败数”，而不是只统计保存了多少密码。
最终退出还要能离开产品。导出一份合成数据，迁移到候选工具，核对结构和附件，重建 group/collection/vault 权限，再轮换所有因迁移而进入明文或新信任边界的凭据。旧平台在验证完成前只读冻结，验证完成后撤销 token、关闭 Connect 或自托管服务、删除客户端配置和备份副本，最后保留脱敏审计与销毁证据。一个无法安全导出、无法重建权限、无法证明旧副本失效的密码库，不是团队的安全底座，只是更整齐的秘密堆放点。
把关闭条件写进变更记录
人员共享项归组织或受控数据库所有，没有把工作凭据散落在个人 vault。1Password vault、Bitwarden collection 和 KeePass database 按真实访问集合拆分，没有用标签、嵌套名称或 group 目录冒充权限。桌面、CLI、浏览器扩展和插件来自批准来源，版本、更新通道、代理和企业证书链可验证。
每套工具在进入团队准入前，都应跑通合成凭据的创建、读取、拒绝、轮换、旧值失败和清理链路，并保存不含明文的证据。CI 使用 Service Account、machine account 或专用机器身份，不复用员工桌面会话、主密码或长期 BW_SESSION。共享链接有接收者、到期、owner 和主动删除记录，接收者拿到的内容按已复制处理。
剪贴板、跨设备同步、浏览器自动填充、终端 trace、日志、截图和 AI 上下文不会长期保留 secret。导出文件按明文或可解密副本管理，恢复演练验证字段、附件、历史和目标凭据，而不只是验证文件存在。离职与失窃设备按离线副本最坏情况处理，密码库撤权后继续完成目标系统轮换与旧值失败验证。
KeePass 的 KDBX 与 key file 分离保存，KDF 在最慢受支持设备上基准化，旧副本和同步冲突有处置方案。机器 token、Connect 凭据、自托管组件、插件和浏览器扩展进入供应链清单，具备升级、回滚与退出 owner。审计数据明确事件种类、客户端覆盖、保留时间和导出位置，不用“没有日志”证明“没有访问”。