自托管 vs. 云端密码管理器

一些客户有询问过自托管密码管理解决方案（如 Bitwarden）的利弊 。 因我在这个话题上有很多经验，我想分享一些使用如 Keeper 之类的云端密码管理器，而不是自托管密码保险库的关键原因。

自托管解决方案的好处

我能想到的自托管密码管理平台的唯一优势是当用户在隔离式的网络环境中只使用一台台式计算机。 这种情况不适用于绝大多数个人或企业。

自托管解决方案的缺点

基础设施的管理

在自托管解决方案中，客户要负责容器部署、服务器托管、负载平衡、SSL 证书、路由和防火墙等。 客户将从管理终端用户的职责转移到管理整个软件平台的职责。 当出现问题时，管理员承担全部责任。

在以下几个方面需要专业知识：

• Docker 容器
• Docker Swarm 用于高可用性
• 数据库服务器托管、维护、升级和备份
• 负载平衡
• 防火墙/网络应用程序防火墙 (WAF)
• Windows 或 Linux 服务管理
• 实例修补、备份和恢复
• 硬件管理 – 服务器、网络基础设施（路由器、交换机）、防火墙/安全设备、存储阵列和电子设备的安装和持续维护。
• 设施维护 – 紧急电源备份（发电机、电池）、环境、实体安全和访问控制。

Keeper 部署在多个地理数据中心中的一个大型云基础设施中，在美国有一支由 DevOps 人员组成的全职团队负责管理、保护和监控环境。

部署自定义设置

在自托管解决方案中，所有部署的应用程序都必须由管理员和每个终端用户修改，从而做到包含自定义 URL 端点设置。 用户将面临挑战，而且必须与托管端点维持网络连接。 您还可以通过组策略和移动设备管理 (MDM) 推行这些设置，但前提必须是您对所有终端设备拥有完全的控制。 任何您控制之外的设备都必须由管理员或用户手动配置。

Keeper 的最终用户应用程序不需要配置，它们打开即用。

缺乏关键使用案例

在密码保险库服务的本地安装中，有几个使用案例可能不合用。 例如：

• 实时同步和推送需要云基础设施连接。 供应商可能会提供云中继来解决这个问题，但这样就失去了使用自托管的意义。
  
• 将单点登录（SSO） 与内部关键管理服务集成将是非常复杂
  
• 与 API 的集成将需要从开发/生产服务器到目标自托管端点的网络路由

Keeper 提供实时同步，不需要任何本地服务来运行或与 SSO 集成。 所有 API 都使用零知识加密直接与 Keeper 云通信。 无需内部网络路由的更改。

安全漏洞

为了允许终端用户访问远程系统或移动设备上的保险库，托管应用程序必须向目标暴露入网访问。 这意味着该服务将被公开访问，并允许机器人和不良行为者攻击它。 因此，您必须得购买和部署第三方前端 WAF 解决方案，例如 Cloudflare、AWS Shield 等。

Keeper 是一个托管在 Amazon Web Services 中的经完全管理的零知识解决方案。 Amazon Shield/WAF 被部署来控制分布式拒绝服务 (DDoS) 和其他机器人攻击。

软件更新

使用自托管解决方案，所有本地软件都必须连续地备份、修补、下架和重新启动。 一个瞬息万变的保险库解决方案需要在各种平台上（如网络、桌面、移动、浏览器扩展等）进行许多移动组件和不断的产品更新。 快速的更新步伐将导致任何本地产品需要频繁的软件补丁。 而且总是存在坏补丁或错过补丁导致严重问题的可能性风险。

Keeper 在所有平台上的软件都是最新的，并修补了最新的安全更新。 无需客户干预。

备份和恢复

数据库、服务器、配置和容器都必须备份。 恢复必须持续地进行测试和验证。 如果每天备份是在数据库的内部实例中执行的话，那么将在这 24 小时内具有丢失关键密码的风险。

Keeper 的数据库基础设施是多地区、多地带。 数据备份可以在 30 天内恢复到任何时间点，精确到秒钟。 此外，Keeper 的记录历史功能从一开始就为平台中存储的每个密码或记录提供完整的历史更改。

恶意内部人

在一个自托管解决方案中，管理员可以完全控制软件和存储。 这也使管理员能够控制用户的保险库，甚至管理员的管理员和 C 级高管的保险库。

往更深一步走的话，如果管理员从源代码构建服务，他们还可以引入错误、漏洞和特权升级。 在大多数环境下，管理团队和管理人员不得允许管理员提高他们的特权并访问用户保险库的内容。

Keeper 使用零知识与零信任安全架构构建。 Keeper 可以轻松配置来创建有限权限的授权管理员角色。 Keeper 管理员永远无法解密不受他们管理的用户的保险库。

开源风险

为开源社区提供完整的前端和后端源代码仓库是值得一提的，且在透明度上有帮助。 然而，对于大多数企业来说，其安全优势很有限。 如果恶意攻击者的拉取请求在没有经过充足的同行评审的情况下被开源项目接受，那么就可能会引入漏洞。 仅仅因为源代码是公开的，并不意味着安全研究人员正在对代码进行安全漏洞的分析和测试。 我们都知道漏洞在许多公开源代码项目中可以存在数年。

Keeper 与业界领先的网络安全研究人员签订合同，对内外部的 Keeper 软件目标进行季度渗透测试，并拥有完整的源代码访问权限。 Keeper 还与 Bugcrowd 合作管理其漏洞披露计划 (VDP)。 想阅读更多，请访问 https://bugcrowd.com/keepersecurity。

Keeper 的 API 和软件开发包（SDK）如命令和密钥管理器等是公共源代码，可在我们的 Github 仓库中获取。

员工流动的审计缺口

不可避免的一种情况是，控制该环境的管理员最终也可能会离开组织。 这有可能会留下一个未受管理、未经维护或不安全的系统。 此外，如果就算管理员被终止或以不良条件离开，也没有任何恶意行为的审核记录（如复制用户保险库副本、引入漏洞或销毁数据等）。

Keeper 有一个高级报告和警报模块 (ARAM)，其中包含所有用户活动的审核跟踪。 Keeper 管理员永远无法直接访问其最终用户的保险库数据。

如果您有任何问题，请给我们发送电子邮件：security@keepersecurity.com。