Passwordstate 的最佳替代方案：到底该用什么替代

最佳 Passwordstate 替代方案：实际上应该用什么来替代

Passwordstate 是 Click Studios 推出的一款自托管、基于 Web 的企业密码管理工具。在金融、政府和国防等限制或彻底禁止云访问的组织中，它非常常见。很多团队也把它当作一个临时的 secrets manager 来使用，将 API key、auth token 和服务凭证与人类密码一起存储。像 devblackops/PasswordState 这样的社区包也存在，用来让程序化访问不那么痛苦。

问题在于：Passwordstate 的安全记录已经侵蚀了人们对它的信任，而这种信任正是继续使用它的理由。

安全时间线

有三个主要的事件群，定义了这一模式：

• 2021：供应链攻陷。 攻击者攻陷了 Click Studios 的下载服务器，并通过应用内的 Global In-Place Upgrade 机制分发恶意的 moserware.secretsplitter.dll。任何拉取了该更新的实例，都会开始通过 Moserpass 恶意软件向攻击者的基础设施泄露已存储记录和主机系统元数据。Click Studios 花了 28 小时才作出响应。随后，攻击者还发起了一场冒充 Click Studios 的钓鱼活动，分发一个假的补丁，这意味着事件响应过程本身也变成了额外的攻击向量。
• 2022：关键 API 身份验证绕过（CVE-2022-3875，CVSS 9.1）。 该漏洞由 modzero AG 发现，它允许未经身份验证的远程攻击者仅凭目标用户名就能伪造 API token 并获取明文密码。它是当年披露的更广泛的七个漏洞中的一部分，其中还包括访问控制绕过（CVE-2022-3876）、存储型 XSS（CVE-2022-3877）以及硬编码凭证。所有漏洞都已在 build 9611 和 9653 中修复。
• 2024 和 2025：反复出现的身份验证绕过漏洞。 由 Bastion Security 发现的 CVE-2024-39337 允许攻击者仅使用受害者的 Active Directory 用户名，就能接管完整账户，并通过部分 session 漏洞绕过密码和 MFA 要求。Click Studios 于 2024 年 3 月在 build 9858 中修复了该问题。随后，在 2025 年 8 月，Emergency Access 页面中的另一个身份验证绕过漏洞被修复（build 9972，CVE 待定），可通过精心构造的 URL 进行利用。《The Register》指出，这是 Passwordstate 9 自发布以来遭遇的第四个身份验证绕过漏洞。

比任何单一 bug 更重要的是这种模式。该产品的核心价值主张是“我们让 secrets 不上云，所以它们更安全”，但其实现却一再未能保护这些 secrets。再加上事件期间缓慢且不透明的沟通，你面对的是一个仅靠打补丁无法修复的信任问题。

选择替代品：三个不同的问题

在选择工具之前，先确定你真正要解决的是哪个问题。Passwordstate 被用于几种不同的用途，而正确的替代方案取决于哪一种用途对你的团队最重要。

问题 1：为人类存储和共享密码

这是最初的使用场景：员工凭证、共享登录、WiFi 密码、供应商门户访问。核心需求包括：一个能生成高熵凭证的密码生成器、团队成员之间安全共享密码而不诉诸 Slack 私信或电子表格，以及用于合规的审计日志。

问题 2：管理机器 secrets

API key、数据库连接字符串、SSH key、CI/CD token、服务账户凭证。这些需要程序化访问、具备环境感知的作用域（dev/staging/prod），以及与部署流水线集成。传统密码管理器并不适合这项工作。

问题 3：管理特权访问

控制谁可以访问关键基础设施、在什么条件下访问、可以访问多久。这包括 session 录制、凭证 checkout/checkin，以及针对提升权限访问的审批工作流。这属于 Privileged Access Management（PAM）的领域——Passwordstate 的用户群经常需要这一类别，但传统密码管理器并不能很好地解决它。

选项 A：KeePass / KeePassXC —— 仅本地密码存储

适用场景：云不是一个选项，而且范围严格限定为个人或非常小型团队的人类密码。

KeePass 及其跨平台分支 KeePassXC 将凭证存储在一个加密的本地数据库文件中（.kdbx，AES-256 或 ChaCha20）。默认情况下，KeePass 在本地运行，不需要服务器或云组件；除非你额外增加同步或共享层，否则不会通过网络暴露凭证。

以下是这两个变体在实际中的表现：

• KeePass： Windows 原生（可通过 Mono 在 Mac/Linux 上运行，但体验较差）。
• KeePassXC： 为 Windows、macOS 和 Linux 提供原生构建，并具有现代化界面。
• 两者都是开源且免费的。
• 内置密码生成器，支持可配置的熵。
• 可通过扩展提供浏览器集成（KeePassXC-Browser）。
• KeePassXC 支持 YubiKey 和硬件密钥。

它的不足之处：

• 没有内置的多用户访问控制。共享意味着共享数据库文件和主密钥，或者在其上运行一个同步层（例如 Syncthing、网络共享）。这会带来额外的运维麻烦。
• 没有基于角色的权限控制。任何拥有主密钥的人都能看到一切。
• 没有中心化审计轨迹。
• 打补丁是手动且分散的。当 CVE-2023-32784 爆出时（允许从进程内存中提取主密码），组织内每一个 KeePass 实例都需要单独手动更新。没有推送机制，也没有中心化更新管理。
• 插件生态（尤其是 KeePass）会引入供应链风险——插件并不像核心应用程序那样经过同等严格的审查。

KeePassXC 是一个可靠的个人密码保险库。作为面向 50+ 团队的企业密码管理解决方案，它需要大量运维开销才能运转，而缺乏集中控制也使其难以成为需要审计轨迹或入职/离职工作流的组织的合格 Passwordstate 替代品。

类似工具：Enpass、RoboForm

选项 B：1Password —— 做得很好的云密码管理

适用场景：可以接受云，主要需求是人类凭证管理，并且团队重视 UX 和快速入职。

1Password 是一个云托管密码管理器，具有精致的 UI、细粒度的 vault 权限以及简洁的入职/离职工作流。当有人离开组织时，撤销访问权限只需要一次管理员操作，凭证仍然保留在公司内部。

为什么它与这一受众相关：

• 集成的 TOTP 支持： 当团队成员之间共享密码时，2FA token 会随凭证一起传递，从而消除了“你能把 MFA 验证码发给我吗”这个问题。
• Watchtower 会根据已知数据泄露数据库监控已存储凭证，并标记已泄露或重复使用的密码。
• Secrets Automation 和 SDK： 1Password 在面向开发者的功能上投入了很多。Service Accounts 提供对 vault 项目的作用域化、程序化访问。适用于 Python、JavaScript 和 Go 的开源 SDK 允许在运行时获取 secrets，而无需硬编码。1Password Connect 则通过私有 REST API 和本地缓存实现自托管的 secrets 访问，以提供高可用性。
• CI/CD 集成： 为 GitHub Actions、CircleCI、Jenkins 等提供预构建集成，允许将 secrets 注入部署流水线。
• Agentic AI 安全： 1Password 现在支持 AI agents 的凭证管理，包括用于自主工作流的基于 TOTP 的 MFA，以及针对凭证访问的人类参与审批——随着团队采用 agentic automation，这一特性正变得越来越相关。
• CLI（op）： 用于脚本和自动化，包括 SSH key 管理和 Git commit 签名。

它的不足之处：

• 它是云托管的。对于有严格数据驻留或 air-gapped 要求的组织来说，这是无法接受的。
• 虽然 secrets automation 能力已经显著成熟，但在环境作用域抽象（将 dev/staging/prod 作为一等概念）、动态 secrets 生成和自动化凭证轮换方面，它不如专门构建的 secrets management platforms 深入。1Password 仍然最强于作为一个人类凭证管理器，并具备可靠的开发者集成，而不是一个完整的 secrets 生命周期平台。

类似工具：Dashlane、LastPass（尽管 LastPass 自身也有显著的数据泄露历史，因此要谨慎评估）

选项 C：Bitwarden —— 开源、可自托管的密码管理

适用场景：团队需要企业密码管理，并且希望保留自托管选项，同时开源对于可审计性或策略合规很重要。

Bitwarden 是一个开源密码管理器，既提供云托管，也提供自托管部署选项。对于那些因为自托管需求而特意从 Passwordstate 迁移的团队来说，Bitwarden 可以说是最自然的替代品——它在不放弃本地部署的前提下，提供了真正的多用户访问控制。

关键技术属性：

• 开源并经过审计。 Bitwarden 的代码库公开托管在 GitHub 上，并定期接受第三方安全审计。该平台符合 SOC 2、GDPR、CCPA 和 HIPAA。
• 可自托管。 可使用 Docker 或 Kubernetes 的 Helm chart 部署在你自己的基础设施上。所有 vault 数据都保留在你的服务器上——这对于有严格数据驻留要求的组织很重要。
• 细粒度访问控制。 Organizations、collections 和 groups 提供基于角色的权限。你可以按部门、项目或敏感级别组织凭证，并控制谁能看到什么。
• SSO 集成。 企业计划支持 SAML 2.0 和 OIDC，并将 SSO 身份验证与 vault 解密解耦，以保持零知识加密。兼容 Okta、Microsoft Entra ID、Google Workspace、Ping Identity 以及其他符合标准的提供商。
• SCIM provisioning。 通过你的身份提供商自动进行用户和组 provisioning。当某人在你的目录中被停用时，他们对 Bitwarden 的访问将自动被撤销。
• Secrets Manager。 Bitwarden 提供一个专用的 Secrets Manager 产品，用于存储和将机器凭证（API key、token、证书）注入应用程序和 CI/CD 流水线。这在 Bitwarden 生态系统中提供了一种基础的 secrets management 能力。
• CLI 和 API 访问，用于脚本和自动化工作流。
• Send，用于与外部方进行安全、限时的凭证共享。

它的不足之处：

• 自托管部署会带来运维开销。你需要负责数据库维护、备份、SSL 证书和更新。搭建并不复杂，但要在企业规模下维护它需要专门投入。
• 零知识 SSO 配置（Key Connector）对于自托管部署来说并不简单，并且需要大量 IT 资源才能安全实施。
• Bitwarden 的 Secrets Manager 功能可用，但相对较新；在环境作用域 secrets、动态凭证生成或轮换自动化方面，不如专门构建的平台功能丰富。
• UX 虽然不错，但通常被认为不如 1Password 精致，尤其是在非技术用户的入职体验方面。

选项 D：云原生 Secrets Manager —— AWS、Azure、GCP

适用场景： 团队已经在主要云服务商上运行工作负载，并且需要具备深度平台集成的托管式 secrets management。

如果你的基础设施主要运行在某一家主流云上，那么原生 secrets management 服务通常是处理机器凭证最简单的路径。它们是完全托管的，与 IAM 深度集成，并且不需要额外基础设施来部署。

AWS Secrets Manager：

• 与 AWS IAM 原生集成，可实现细粒度访问控制，并自动将凭证注入 Lambda、ECS、EKS 和其他 AWS 服务。
• 通过 Lambda 轮换函数为 RDS、Redshift、DocumentDB 及其他 AWS 数据库凭证提供内置自动轮换。
• 支持跨账户和跨区域的 secret 复制，用于灾难恢复。
• 按 secret 计费（$0.40/secret/月）外加 API 调用费用——在大规模场景下成本会迅速增加。
• 局限于 AWS 生态。如果你运行的是多云或混合基础设施，则需要为非 AWS 工作负载单独管理 secrets。

Azure Key Vault：

• 在一个服务中统一管理 secrets、加密密钥和证书。
• 提供 HSM 支持的密钥存储选项（FIPS 140-2 Level 2 和 Level 3），适合具有严格密码学要求的组织。
• 与 Azure AD / Microsoft Entra ID 深度集成，用于访问策略和托管身份，使 Azure 资源无需存储凭证即可进行身份验证。
• 原生集成 Azure DevOps、App Service、AKS 及其他 Azure 服务。
• 支持 secret 版本管理和 soft-delete 以便恢复，但没有内置自动轮换——轮换需要借助 Azure Functions 或自定义自动化，这会增加运维复杂性。

GCP Secret Manager：

• 支持跨区域自动复制，并可配置复制策略（自动或用户管理）。
• 与 IAM 和 Workload Identity Federation 集成，在 GCP 服务之间实现细粒度访问控制。
• 内置版本管理、通过 Cloud Audit Logs 提供审计日志，以及与 Cloud Functions 集成以支持轮换工作流。
• 定价简单直接（$0.06/10,000 次访问操作，外加按版本计费的存储成本）。
• 和其他服务一样，它也与 GCP 生态紧密耦合。多云团队需要为非 GCP 工作负载准备单独方案。

三者的共同限制： 这些服务非常适合用于各自云生态内部消费的 secrets，但在多云或混合环境中会造成碎片化。它们也无法解决人类凭证管理问题。对于员工密码、共享账户和供应商门户访问，你仍然需要一个密码管理器。而且，它们都没有开发者导向 secrets management 平台原生提供的环境作用域模型（将 dev/staging/prod 作为一等构造）。

选项 E：Infisical —— 面向机器凭证和基础设施访问的 Secrets Management 与 PAM

适用场景： 真正的痛点在于跨环境和流水线管理 API key、token 和服务凭证——或者团队需要对数据库和服务器等基础设施进行特权访问控制。

Infisical 是一个用于 secrets management、证书和 privileged access management 的开源平台，专为开发者和基础设施工作流构建。如果团队一直在把机器凭证塞进 Passwordstate，然后再用自定义脚本取出来，那么这就是一个专门构建的替代品。它不是面向人类登录凭证的传统密码管理器——而是一个用于管理现代基础设施所需 secrets、证书和特权访问的企业级平台。

关键技术属性：

• 天然具备环境感知。 Secrets 原生按环境（dev、staging、production）划分作用域，而不是通过命名约定或文件夹技巧来实现。
• 原生 CI/CD 集成。 GitHub Actions、GitLab CI、Kubernetes operators、Docker、Terraform、Ansible 等。Secrets 在运行时注入，无需硬编码它们，也无需在代码仓库中存储 .env 文件。
• 动态 secrets。 按需为 PostgreSQL、MySQL、Redis 和 RabbitMQ 等服务生成临时、短生命周期凭证。这些凭证在过期后会被自动撤销，从而消除陈旧、长期凭证带来的风险。
• 自动化 secret 轮换。 以可配置的间隔为数据库（PostgreSQL、MySQL、MSSQL、OracleDB）、AWS IAM、Auth0、LDAP 和其他服务轮换凭证，并提供重叠有效期以防止轮换期间停机。
• CLI 和 SDK 访问。 通过客户端 SDK（Node、Python、Go、Ruby、Java、.NET）和 Infisical CLI 以程序方式获取 secrets。Infisical Agent 可在不修改应用代码的情况下将 secrets 注入应用程序。
• 证书管理（PKI）。 创建和管理内部证书颁发机构，签发和续订 X.509 证书，并与 Let's Encrypt 和 DigiCert 等外部 CA 集成。支持 ACME 和 EST 注册协议。
• 可自托管。 平台是开源的（核心部分采用 MIT license），可运行在你自己的基础设施上——这对于那些因为要避免第三方云依赖而离开 Passwordstate 的组织很重要。
• 访问控制和审批工作流。 RBAC、基于属性的访问控制、自动过期的临时访问、带多步审批链的访问请求，以及覆盖所有操作的全面审计日志。

Infisical PAM：特权访问管理

对于那些将 Passwordstate 作为事实上的 PAM 工具来使用的团队——例如管理谁可以访问关键数据库、服务器和基础设施——Infisical PAM 直接解决了这一问题。Passwordstate 历史中的许多安全失败（尤其是 Emergency Access 绕过漏洞）正是源于恰当的 PAM 解决方案旨在防止的那类特权访问问题。

Infisical PAM 为访问数据库和服务器等基础设施资源提供中心化、基于策略的控制。其架构采用基于 Gateway 的模型：一个轻量级的 Infisical Gateway 部署在你的网络内部，并作为通向私有资源的安全桥梁。用户永远不会获得直接网络访问权限，也看不到底层凭证。相反，连接会通过 Gateway 代理，并自动注入凭证。

访问生命周期如何运作：

1. 发现： 用户登录 Infisical，并看到一个他们被允许访问的资源（数据库、服务器）和账户目录。
2. 请求与审批： 用户请求访问某个特定资源和账户（例如，以 read_only 身份访问“Production PostgreSQL”）。如果配置了审批策略，请求会通过多步审批工作流进行路由——指定审批人会收到通知，并可批准或拒绝。在已配置的情况下，也可为紧急场景提供 break-glass 绕过。
3. 凭证注入： 一旦获得批准，Infisical 会通过 Gateway 建立安全隧道，并自动为目标账户注入凭证。用户永远不会看到底层密码或密钥。
4. Session 录制： 所有 session 活动都会被记录。对于数据库连接，Infisical 会捕获执行的每一条查询及其对应响应。录制内容会以加密形式静态存储，在 session 期间缓存在 Gateway 本地，并在 session 结束后上传到 Infisical 平台进行中心化长期存储。这种异步方式意味着即使与 Infisical 平台的连接暂时中断，session 仍可继续运行。
5. 自动化凭证轮换： PAM 资源的凭证可以自动轮换，从而确保即使某个凭证以某种方式暴露，其可利用生命周期也受到限制。

Infisical PAM 当前支持的资源包括 Active Directory、PostgreSQL、MySQL、MSSQL、Redis、Kubernetes、AWS IAM、SSH 和 Windows Servers，并且还会随着时间推移增加更多资源类型。对于 SSH 访问，Infisical 支持签名 SSH 证书，以实现临时、短生命周期的基础设施访问。

对于当前同时在 Passwordstate 中存储人类密码和机器凭证的团队，一个实用的迁移路径是：使用 1Password 或 Bitwarden 管理人类凭证 + 使用 Infisical 管理机器 secrets 和特权基础设施访问。 这能清晰地区分关注点，并为每个问题配上合适的工具。

类似工具： Doppler（不开源）、HashiCorp Vault（运维负担很重——把它运行好本身就是一份工作，不过 HCP Vault 提供了一个托管选项，可减轻负担），以及专门针对 PAM 的 CyberArk、Delinea 和 BeyondTrust。

运维陷阱

从 Passwordstate 迁移 secrets 是手动且混乱的。 Passwordstate 的导出工具能力有限。你很可能需要针对其 API 编写脚本来提取凭证，并仔细验证完整性。API 存在速率限制，可能会影响批量导出，因此要据此规划。如果 2021 年攻陷窗口期内存储的任何 secrets 尚未轮换，应立即轮换。

“自托管”并不自动意味着“更安全”。 Passwordstate 就是自托管的，但它仍然被多次攻陷。自托管会把底层 OS 打补丁、网络加固、数据库维护和监控的责任转移给你的团队。若要让自托管真正提升安全性，你需要：经过加固且及时进行补丁管理的 OS、将密码/secrets manager 隔离开的网络分段、静态数据库加密、对异常访问的监控与告警，以及明确的安全更新应用 SLA。如果这些实践不够扎实，自托管会增加风险而不是降低风险。

不要让密码管理器变成你的 secrets manager。 密码管理器是为交互式的人类使用而设计的——登录网站、与同事共享凭证。机器 secrets（API key、DB 连接字符串、证书）有不同的访问模式、生命周期要求和轮换需求。把它们混在一个工具里，会在审计轨迹和访问控制两方面都制造盲点。

迁移前先审计 Passwordstate 里到底有什么。 团队常常会惊讶地发现陈旧凭证、没有所有者的共享服务账户，或者那些本应在多年前就轮换的 secrets。迁移是一个清理旧账的好机会。

迁移后的凭证轮换不是可选项。 将 secrets 移动到新平台之后，要轮换它们。迁移过程本身会制造一个凭证同时存在于两个系统、导出文件或 shell 历史中的窗口。把迁移视为一次潜在暴露事件，并据此进行轮换。

接下来该怎么做

正确的行动取决于你的 Passwordstate 实例里究竟存放了什么。在评估任何工具之前，先导出完整清单，并对你存储的内容进行分类：人类凭证放在一个桶里，机器 secrets 放在另一个桶里，特权基础设施访问放在第三个桶里。

如果清单几乎完全由人类密码组成（登录凭证、共享账户、WiFi key），那么像 1Password 或 Bitwarden 这样的专用密码管理器就能以比 Passwordstate 更低的运维开销填补空缺。如果自托管是要求，Bitwarden 是更强的选择。如果清单中 API key、token 和服务凭证占很大比重，那么它们应该放进像 Infisical 或云原生选项（AWS Secrets Manager、Azure Key Vault、GCP Secret Manager）这样的 secrets manager 中，具体取决于你的基础设施，而不是密码保险库。如果团队需要针对数据库、服务器和其他基础设施的特权访问控制，那就是 PAM 问题。Infisical PAM 或像 CyberArk 这样的专用 PAM 工具可以直接解决它。

具体的下一步是审计你的 Passwordstate 实例。运行导出，将每一条记录标记为“human”“machine”或“privileged infrastructure”，并标记出过去 12 个月内未轮换的任何内容。这个清单就是迁移计划。其他一切（工具选择、环境映射、集成工作）都建立在你清楚知道自己在保护什么，以及它是如何被访问的基础之上。

Passwordstate 反复出现的安全失败已经清楚表明，继续留在原地会带来真实风险。但在没有计划的情况下迁移，只是把混乱搬到一个新平台。从审计开始。一旦你知道自己面对的是什么，工具选择就会变得直接。

• 原文链接： infisical.com/blog/passw...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～