Keeper 对凭证安全和数据保护有极高的热情

总览

Keeper Security, Inc. 致力于通过 Keeper 手机和桌面安全软件来保护客户的信息。数以百万计的消费者和企业信任 Keeper 来保护和访问他们的密码和私人信息。

Keeper 的软件将不断改进和更新，为我们的客户提供最新的技术和保护。本页概述了 Keeper 当前发布版本的安全体系结构、加密方法和托管环境。本文介绍了我们的加密和安全方法的技术细节概述。

我们的隐私政策和使用条款请参见我们网站上的以下链接：

零信任平台

Keeper 采用零信任体系结构，确保每个用户在访问网站、应用或系统之前都必须经过确认和身份验证。

Keeper Enterprise Password Management (EPM) 让企业能够全面了解和控制员工的密码做法，使 IT 管理员能够监视密码使用情况并强制实施安全最佳做法。

Keeper Secrets Manager (KSM) 为工程团队提供了一个平台来管理所有凭据，包括基础设施机密、SSH 密钥、API 密钥和证书，并具备 SDK 和 CI/CD 集成功能。

Keeper Connection Manager (KCM) 是一款远程桌面网关，可让 DevOps 和 IT 团队通过 Web 浏览器对 RDP、SSH、数据库、内部 Web 应用和 Kubernetes 端点轻松进行零信任网络访问 (ZTNA)，无需代理。

Keeper 的世界一流安全详情

保管库数据加密

Keeper 提供了基于最低特权的多层加密模型。在客户端设备上生成 256 位 AES 记录级密钥和文件夹级密钥，用于加密存储的每条保管库记录。保管库记录及其所有内容均已完全加密，包括登录名、文件附件、TOTP 验证码、付款信息、URL 和自定义字段。

加密密钥在本地设备生成以保持零知识，并支持记录和文件夹共享等高级功能。零知识意味着每个用户都可以完全控制其 Keeper 保管库中所有个人信息的加密和解密，其他任何人（甚至是 Keeper 员工）都无法访问其存储的任何信息。

记录密钥和文件夹密钥由 256 位 AES 数据密钥加密，该数据密钥对每个用户都是唯一的，并在用户的设备上生成。

在用户的设备上，会生成另一个 256 位 AES 客户端密钥，用于加密本地离线缓存（如果您的企业管理员允许离线访问）。最后，使用另一个密钥对 256 位 AES 数据密钥进行加密，如下一节所述。

保管库加密方法

Keeper 使用不同的方式加密数据，视用户的登录方式而定。对于消费者和家庭方案成员，使用的是主密码和生物识别身份验证。对于以 SSO 登录的 Business 和 Enterprise 用户，Keeper 使用椭圆曲线加密来提供安全的无密码体验。

对于使用主密码登录的用户：用于解密和加密数据密钥的密钥是从用户的主密码派生而来，利用基于密码的密钥派生函数 (PBKDF2) 进行计算，迭代次数为 1,000,000 次。用户输入主密码后，密钥将在本地派生，然后解开数据密钥。数据密钥被解密，并用于解开单个记录和文件夹密钥。每个密钥的解密会将记录内容存储在用户的设备本地。

对于使用 SSO 或无密码技术登录的用户：椭圆曲线加密用于在设备级对数据进行加密和解密。使用本地的 ECC-256 (secp256r1) 私钥来解密数据密钥。数据密钥被解密后用于解开单个记录和文件夹密钥。然后，记录密钥将解密每个存储的记录内容。加密的数据密钥通过一个推送系统或密钥交换服务（称为"设备批准"）在用户的设备之间传输。为了保持零知识，设备批准由最终用户在本地管理。

SSO 加密模型

首个设备流程（新用户入职）

1. 生成数据密钥、共享密钥对和设备 EC 私钥/公钥对
2. 数据密钥使用设备 EC 公钥加密并存储在云端 (DEDK)
3. 用户使用其身份提供程序 (IdP) 登录
4. 通过 IdP 登录后，Keeper 会验证已签名的 SAML 断言
5. 保管库成功创建，用户完成入职

现有设备流程

1. 用户使用其身份提供程序 (IdP) 登录
2. 通过 IdP 登录后，Keeper 会验证已签名的 SAML 断言
3. Keeper 将设备加密的数据密钥 (DEDK) 传送给用户
4. 数据密钥使用设备 EC 私钥解密
5. 数据密钥解密文件夹密钥和记录密钥
6. 记录密钥解密记录内容

新设备或无法识别设备流程

1. 在每个新设备上，都会生成一个 EC 私钥/公钥对
2. 用户使用其身份提供程序 (IdP) 登录
3. 通过 IdP 登录后，Keeper 会验证已签名的 SAML 断言
4. 设备通过 Keeper Push、管理员批准或 Keeper Automator 服务获得“批准”（*参见下方“设备批准”）
5. 在批准过程中，使用新设备的公钥对数据密钥进行加密
6. 设备加密的数据密钥 (DEDK) 发送给用户

设备批准

• 设备批准是一种在保持零知识的情况下将用户的数据密钥安全地传送到其新设备的机制
• 用户可以通过使用新设备的公钥加密数据密钥来批准其设备
• 管理员可以通过管理控制台、Commander 或 Keeper Automator 服务批准设备
• 管理员解密用户的数据密钥，并使用新设备的公钥重新加密数据密钥
• Keeper Automator 服务可以在客户的基础设施上执行自动设备批准
• Keeper Automator 检查 SAML 签名，解开数据密钥，并使用新设备的公钥对数据密钥进行加密

阅读有关 Keeper Automator 服务的更多信息。

SSO Connect Cloud 的设备级安全性

对于 SSO Connect Cloud 用户，将生成椭圆曲线私钥并存储在每部设备本地。在现代 Web 浏览器和基于 Electron 的 Keeper 桌面应用中，Keeper 保管库将本地设备 EC 私钥（“DPRIV”）存储为不可导出的 CryptoKey。在 iOS 和 macOS 设备上，密钥存储在设备钥匙串中。在 Android 设备上，密钥通过 Android 密钥库进行加密，并使用了加密共享首选项。如果可用，Keeper 会在每个操作系统上使用安全存储机制。

设备私钥不直接用于加密或解密保管库数据。通过身份提供程序成功进行身份验证后，将使用单独的密钥（未存储）来解密保管库数据。因此，离线提取本地设备私钥并无法解密用户的保管库。

静态数据加密

Keeper 使用 AWS 托管 Keeper 平台和体系结构。我们的 AWS 数据中心位于多个地理位置，客户可以在任意的首选主要区域托管 Keeper 租户。这样可以确保客户数据和对平台的访问将隔离在该特定区域。

保管库的静态数据在用户设备本地使用 AES-256 GCM 进行加密，传输中的加密数据使用 TLS 1.3 进行加密，并在有效负载中应用了另一层加密。通过使用记录级加密来隔离客户数据。

Keeper 加密模型遵循以下结构：

• 在 GCM 模式下，所有保管库均使用客户端生成的唯一 256 位 AES 密钥进行加密。
• 共享文件夹中所有记录级密钥均采用 256 位 AES 共享文件夹密钥封装。
• 保管库用户的记录和文件夹密钥使用另一个称为数据密钥的 256 位 AES 密钥进行加密。
• 对于 Keeper Secrets Manager (KSM)，用户的记录和文件夹密钥使用 256 位 AES 应用密钥进行加密。
• 对于使用主密码登录的用户，解密和加密数据的密钥是来自于主密码。
• 采用 SSO 或无密码技术登录时，使用椭圆曲线加密在设备上对数据进行加密和解密。
• 每个加密的有效负载均发送至 Keeper 服务器，并使用 256 位 AES 传输密钥和 TLS 进行封装，以防御中间人 (MITM) 攻击。密钥在客户端生成，并通过服务器的公共椭圆曲线密钥使用 ECIES 加密进行传输。
• 用户之间安全共享机密使用了椭圆曲线加密密钥分发。

记录版本控制

Keeper 为存储在用户保管库的每一条记录维护完整的加密版本历史，确保重要的数据绝不会丢失。通过 Keeper 客户端应用，用户可以检查记录历史，并可还原任意个人保管库记录。若在 Keeper 中存储的密码或文件被更改或删除，用户始终可以执行时间点还原。

Keeper Business

购买 Keeper Business 的客户还可对其用户和设备进行额外的一层控制。Keeper 管理员可使用基于云端的管理控制台来完全控制用户入职、离职、基于角色的权限、委派管理、团队、Active Directory/LDAP 集成、两步验证、单点登录和安全强制策略。Keeper 的基于角色的强制策略可完全进行自定义，并可扩展至任何规模的组织。

静态数据超级加密

除了在 AWS 基础设施中仅存储设备加密的密文外，Keeper 还使用不可导出的密钥对多区域硬件安全模块 (HSM) 进行超级加密。

备份的加密和保护

在产品/用户级别，Keeper 的软件保留了每条记录的完整修改历史。因此，如果用户需要进行恢复，他们可以随时通过用户界面不受限制地查看并恢复所存储 Keeper 记录的先前版本。

在系统级别，Keeper 的加密数据库和文件对象会在多个地理区域进行复制和备份，以便在发生灾难时能够恢复。除了对设备生成的密文进行超级加密外，所有备份均使用 AES-256 加密。

对于需要协助恢复的客户（例如，由于客户意外删除了保管库或共享文件夹），Keeper 的支持团队可以在 30 天内协助恢复至任意时刻（可精确到分钟）。Keeper 支持团队可以协助进行各种恢复操作，例如用户恢复、保管库恢复或完整的企业数据恢复。

帐户恢复

24 单词恢复短语允许 Keeper 客户在丢失或忘记主密码时重新获得对其 Keeper 保管库的访问权限。

Keeper 使用与用于保护加密钱包相同的 BIP39 单词列表来实施恢复短语功能。BIP39 中使用的单词列表是一个包含 2,048 个单词的集合，用于生成具有 256 比特熵的加密密钥。这种恢复方法通常用于热门的比特币和加密货币钱包。BIP39 列表中的每个单词都经过精心选择，以提高辨认度，并减少恢复过程出错的可能性。用户应把恢复短语写下来，并存放在一个安全的地方，例如保险柜。

恢复短语生成一个 256 位 AES 密钥，用于加密用户数据密钥的副本。若要恢复帐户并重置主密码，用户需使用恢复短语以及电子邮件验证和两步验证 (2FA)。

企业管理员可以在角色强制执行策略级别禁用帐户恢复功能。

企业加密密钥

Keeper Enterprise 和 Business 客户可以管理 Keeper 平台的诸多不同功能，例如基于角色的访问策略、预配、身份验证和管理。

管理员功能受到 Keeper 平台的保护，包括加密和授权。授权可确保只有指定用户才能执行某些功能。加密可确保指定的管理员只能在物理设备层面和加密技术层面执行涉及保管库数据或企业控制密钥的功能。这方面的一些示例包括：

• Keeper 的平台实际上是一个密钥管理平台，用户和管理员拥有对其私钥的完全控制权。
• 在创建设备、用户和团队时使用公钥和私钥的加密密钥对。
• 用于转移保管库和执行设备批准的角色策略使用公钥和私钥进行加密。
• 椭圆曲线 (EC) 密钥对用于在用户之间以及企业级的个人用户与管理员之间共享数据。
• 敏感的使用数据（例如记录的密码强度）使用只有管理员才能解密的企业公钥进行加密。
• 每条企业用户保管库记录的记录标题、URL 和记录类型字段均使用企业公钥进行加密，并可由分配了合规报告权限的管理员在 Keeper 管理控制台中进行解密。

设备验证

在用户尝试登录帐户之前，他们必须先通过设备批准和验证步骤。设备验证可防范帐号枚举，并保护您免受暴力攻击。

使用主密码登录的客户可以通过多种方法进行设备验证，包括：

• 电子邮件验证码
• 通过 TOTP 或文本消息输入 2FA 验证码
• 使用 Keeper Push^™ 向已识别的设备发送消息

对于使用 Keeper SSO Connect Cloud 进行身份验证的客户，设备批准是通过密钥传输完成，其中用户的加密数据密钥将传送至设备，然后使用用户的椭圆曲线私钥在本地进行解密。设备批准方法包括以下几种：

• Keeper Push（使用推送通知）给现有用户设备
• 通过 Keeper 管理员控制台进行管理员批准
• 通过 Keeper Automator 服务自动批准
• 通过 Commander CLI 自动进行管理员批准

了解有关设备批准的更多信息。

数据隐私

Keeper 符合 GDPR 标准，并致力于继续确保我们的流程和产品在欧盟和全球范围内为客户维持 GDPR 合规。 We comply with the EU-U.S. Data Privacy Framework ("EU-U.S. DPF"), the UK Extension to the EU-U.S. DPF, the German Federal Data Protection Act (BDSG) and the Swiss-U.S. Data Privacy Framework ("Swiss-U.S. DPF") as set forth by the U.S. Department of Commerce.

请参阅 Keeper 的 GDPR 隐私政策。

Keeper 的所有应用均没有跟踪器或执行跟踪的第三方库。例如，这份报告提供了 Keeper 的 Android 应用的相关信息，显示未安装任何跟踪器。

数据隔离

Keeper 是一个完全托管的 SaaS 平台，其在多个地理位置隔离的 AWS 数据中心托管其数据。机构可以在其首选区域中托管其 Keeper 租户。将客户数据和平台访问隔离至那个具体区域.

可用区域：

• 美国 (US)
• 美国政府云 (US_GOV)
• 欧洲 (EU)
• 澳大利亚 (AU)
• 日本 (JP)
• 加拿大 (CA)

传输中加密

Keeper 保管库受到 API 的保护，这些 API 通过用户设备上的授权进行验证。

• 用户在登录时将获取一个会话令牌，在每次 API 调用时都会发送该令牌。
• 会话令牌由后端服务器管理和控制。
• 登录可以通过主密码、生物识别、会话恢复或 SAML 2.0 SSO 身份验证来完成。

使用主密码时，用户设备使用 PBKDF2-HMAC_SHA256 获得 256 位的身份验证密钥，迭代次数为 1,000,000 次，并随机加盐。通过使用 SHA-256 对身份验证密钥进行哈希运算来创建身份验证哈希。登录时，身份验证哈希将与 Keeper 保管库中存储的身份验证哈希进行比较。用户登录后，服务器上会创建会话令牌并发送给用户，供设备用于后续的 API 请求。若要允许持续使用客户端到服务器的通信，会话必须处于活动状态。

• Keeper 使用 256 位和 128 位 TLS 对 100% 存储在用户应用和 Keeper 安全文件存储中的数据进行加密。
• Keeper 部署使用 SHA2 算法签名的 TLS 证书。SHA2 是目前由商业证书颁发机构提供的最安全的签名算法。Keeper 使用 SHA2 可以防止攻击者使用伪造的证书来冒充某个网站。

云身份验证

Keeper 创建了一个高级云身份验证和网络通信模型，具有最高级别的隐私、安全、信任和透明度。这个身份验证模型的一些关键特性包括：

可与任何 SAML 2.0 提供者集成

Keeper 可集成所有兼容 SAML 2.0 的身份提供程序，包括 Okta、Microsoft Entra ID (Azure)、AD FS、Google Workspace、Centrify、OneLogin、Ping Identity、JumpCloud、Duo、Auth0 等。

我们的产品提供两种不同的 SSO 类型：SSO Connect Cloud 和 SSO Connect On-Prem。这两种实现方法都采用了零知识体系结构，可为用户提供无缝的身份验证。

绝不通过网络层传输用户主密码

与大多数 SaaS 服务不同，Keeper 用户的登录凭据从不离开其设备。当用户使用主密码登录 Keeper 时，将在本地设备上使用 PBKDF2 来派生一个 256 位 AES 密钥用于解密。在设备级另外生成一个 PBKDF2 密钥，然后使用 HMAC_SHA256 进行哈希处理以创建身份验证令牌。Keeper 对用户的解密密钥保持零知识。

客户端设备与 Keeper 云之间的流量无法被拦截或破解

发送至 Keeper 服务器的所有加密有效负载均使用 256 位 AES 传输密钥和 TLS 封装，以防范中间人 (MITM) 攻击。传输密钥在客户端设备生成，并通过服务器的 EC 公钥使用 ECIES 加密传输至服务器。

没有验证步骤就无法使用新设备登录帐户

如果未使用验证方法，用户就无法使用新设备登录其 Keeper 帐户。Keeper 支持多种类型的验证方法，具体取决于身份验证方案。

验证后，在用户输入其主密码前执行多因素身份验证 (MFA)

如果用户已配置或强制启用了 MFA，则必须先通过此步骤，然后才能输入主密码。

在设备验证和 MFA 步骤成功之后才能输入主密码

如果未设置验证方法，用户将无法继续输入其主密码。这种高级身份验证可以抵御多种常见的攻击方法，包括暴力攻击、密码喷洒、枚举攻击和 MITM 攻击。

多因素身份验证 (MFA)

为了防止未经授权访问客户的帐户，Keeper 提供了多步验证 (MFA)，这是一种要求使用两个或多个身份验证因素（包括知识因素、拥有因素和/或固有因素）的身份验证方法。进一步了解如何在 Keeper 中设置 MFA。

如果您的主密码被泄露或设备遭到入侵，Keeper 可通过结合您的主密码和您拥有的设备来提供额外的一层安全保护。Keeper 支持 FIDO2 WebAuthn 硬件密钥和基于软件的解决方案，例如 TOTP 和短信。

采用 TOTP MFA/2FA 方法时，Keeper 将使用加密安全随机数生成器来生成一个 10 字节的密钥。验证码在大约一分钟内有效，一旦成功进行了身份验证，就不能再次使用。Keeper 支持任何 TOTP 应用，包括 Google 身份验证器和 Microsoft 身份验证器。Keeper 还可直接与 Duo 和 RSA SecurID 等热门的 MFA 服务集成。

在移动设备上使用 MFA 身份验证器（例如 Google 身份验证器、Microsoft 身份验证器或其他 TOTP 应用）时，Keeper 服务器内部会生成一个包含您密钥的二维码。用户每次激活 MFA 时，都会生成一个新密钥。

若要激活 MFA，请访问 Keeper Web 应用、桌面应用或 iOS/Android 应用的设置页面。Keeper Business 管理员还可以通过 Keeper 管理控制台强制使用 MFA 和支持的 MFA 方法。

通过 Keeper 支持兼容 FIDO2 的 WebAuth，可以使用基于硬件的安全密钥设备（例如 YubiKey 和 Google Titan 密钥）作为额外的验证因素。还支持使用物理设备或 Web 浏览器的通行密钥作为 2FA 方法。安全密钥提供了一种安全的方式来执行 MFA，而无需用户手动输入验证码。

Android Smart Watch Apple Smart Watch DUO Entrust Google Authenticator Microsoft Authenticator RSA SecureID 短信 Titan Security Key TOTP Yubico

Keeper Active Directory / LDAP Bridge

Keeper Bridge 可以集成 Active Directory 和 LDAP 服务器，以进行用户预配和入职。Keeper Bridge 通信首先由具有管理 Bridge 权限的管理员进行授权。系统生成传输密钥并共享给 Keeper，以用于随后的所有通信。传输密钥可用于授权 Bridge 进行除了初始化之外的所有操作。传输密钥可以随时重新生成，并且每 30 天自动轮换一次。

传输密钥仅用于传输，这意味着如果密钥泄露，可以重新初始化或撤销它，而不会导致数据或权限的任何损失。

Keeper Bridge 不可为某个角色或用户提供特权。若无需强制密钥，其可以将用户添加至特权角色。Keeper Bridge 无法将自己或用户提升超过其管理的树的部分。并不是所有操作都可以通过 Bridge 完成，例如，Bridge 可以禁用活动用户，但不可以删除用户。必须由管理员选择是否要删除或转移用户。

使用 MFA 进行 SSO 身份验证

使用 SSO解决方案部署 Keeper 后，比如 EntraID/ AzureAD、Okta、Ping、Google Workspace 或任何其他 SAML 2.0 身份提供者，则可以在 IdP 登录过程中全面管理 MFA。 Keeper 还支持所有设备类型和应用程序的 Azure 条件访问策略。

身份提供程序和 Keeper 均可强制要求使用 MFA。例如，在用户通过身份提供程序的 MFA 步骤后，他们还可能会被要求在 Keeper 界面上通过第二个 MFA 步骤。此策略可以由 Keeper 管理员强制执行。

Amazon Web Services CAS Centrify DUO F5 Google Workplace IBM Security JumpCloud Microsoft ADFS Onelogin Okta Ping Identity

使用 SSO Connect Cloud 进行 SAML 2.0 身份验证

Keeper SSO Connect Cloud 使企业客户能够将 Keeper 与任何符合 SAML 2.0 标准的身份提供程序完全集成，并为其用户部署加密的保管库。

SAML implementation with Keeper allows a user to authenticate through their SSO IdP and then decrypt their vault ciphertext on their device. Every user device has an individual Elliptic Curve (EC) key pair and encrypted data key. In addition, each user has their own 256-bit AES data key. When signing in to Keeper using a new device, the user must utilize existing devices to perform an approval or, alternatively, an admin with privileges can approve their device.

This capability is essential so a user can decrypt their vault locally, on their device, without the requirement of a master password or password key derivation. Zero knowledge is maintained because the cloud cannot decrypt the user's data key. Instead, the device-encrypted data key (DEDK) is provided to the user upon successful authentication of the IdP (e.g., Okta, Azure, Google Workspace, AD FS, Ping, Duo, Jumpcloud, etc.). The data key for the user is decrypted locally on the device with the elliptic curve device private key. Keeper holds US Utility Patents on this technology, which has been in production since 2015.

Keeper Automator 是一项可选服务，在 SSO 身份提供者成功登录后执行即时团队批准、设备批准和团队用户配置.

运行 Automator 后，用户可以在身份提供者成功进行身份验证后，在新设备上无缝访问Keeper（未事先批准），无需采取任何进一步的批准步骤。

Keeper SSO Connect On-Prem

虽然大多数客户均部署了 Keeper SSO Connect Cloud，但需要本地解决方案的客户可以部署 SSO Connect On-Prem，这是一种需要使用 Windows 或 Linux 托管应用程序服务器的自托管集成。 为保持零知识安全并确保用户的顺畅 SSO 体验，必须在客户的服务器上安装 Keeper SSO Connect。 高可用度 (HA) 负载平衡操作模式和硬件安全模块超级加密完全支持 Windows、Mac 和 Linux 环境。

Keeper SSO Connect 会自动为每位预配用户生成和维护主密码，这是一个随机生成的 256 位密钥。此主密码使用 SSO 密钥进行加密。SSO 密钥使用树密钥进行加密。SSO 密钥是在 Keeper SSO Connect 服务启动时从服务器获取，然后使用树密钥进行解密。树密钥存储在服务器本地以支持自动服务启动。SSO Connect 与 Keeper 的 Cloud Security Vault 之间的通信使用传输密钥进行保护。SAML 通信经过加密签名，并采用 RSA-SHA256 或 ECDSA-SHA256 签名算法保护，具体取决于客户提供的加密密钥类型（RSA 或 ECC）。

共享

Keeper 支持在用户之间、内部团队甚至在组织之外（如果 Keeper 管理员允许）安全地共享记录。

共享记录

Keeper 用户可以直接相互共享记录。为此，Keeper 首先要求用户从其保管库中提供椭圆曲线公钥。每条记录都有一个记录密钥，该密钥使用接收者的椭圆曲线公钥进行加密，并同步到用户的 Keeper 保管库。

加密共享记录的所有者使用其椭圆曲线私钥解密记录密钥。记录密钥还将使用用户的数据密钥再次加密，密文存储在接收者的保管库中。

单次共享

Keeper 单次共享允许与任何人限时安全共享记录，例如密码、凭据、机密、连接、文档或其他机密信息，即使他们没有 Keeper 帐户。Keeper 单次共享加密模型使用与 Keeper Secrets Manager (KSM) 相同的技术，KSM 是一个用于保护云基础设施的零知识和零信任平台。

1. 在用户的 Keeper 保管库中，发送方通过点击“单次共享”来生成单次访问权限。256 位 AES 记录密钥使用一次性访问令牌进行加密，加密值存储在 Keeper 保管库中。
2. 用户可以使用简单的 URL 或二维码将一次性访问令牌分享给接收者。URL 中包含访问令牌的部分位于 URL 的“片段标识符”部分，这个永远不会发送给 Keeper 的服务器。因此，Keeper 无法访问或解密信息，并保持零知识。
3. URL 在用户的浏览器中打开，设备随之加载了保管库应用。令牌直接传递给本地保管库应用，而不会发送到服务器。
4. 然后，接收者使用其设备生成最终用户端 EC 密钥对，私钥被本地存储在设备浏览器的 CryptoKey 存储中。
5. 接收者首次使用时，SDK 库将使用一次性访问令牌的哈希值进行身份验证。然后，Keeper 的服务器使用加密的记录密文和加密的记录密钥进行响应。
6. 设备使用一次性访问令牌对记录密钥进行解密，然后解密其中的内容。密钥存储在客户端设备上，可以是在浏览器的 CryptoKey 存储中，或者是在另一个存储位置。
7. 该设备的加密记录密钥将被删除，以确保令牌无法再次使用。之后，必须使用私钥对客户端请求进行签名。
8. 在同一设备上发送更多调用时，会附带一个定义设备的标识符以及一个使用客户端私钥签名的请求。通过 ECDSA 签名对给定设备标识符的请求使用了设备的客户端公钥，并由服务器进行检查。Keeper 处理请求，然后服务器将经过加密的记录以密文形式返回给用户的设备。
9. 除了记录级加密外，客户端设备还将创建随机生成的 AES-256 位传输密钥，该密钥使用 Keeper 云 API 的公钥进行加密。客户端设备使用传输密钥解密来自服务器的响应，然后使用记录密钥解密密文响应有效负载，从而解密记录的内容。

Share Admin

Keeper 的共享管理员功能是一种基于角色的访问控制 (RBAC) 权限，可为管理员提供对组织共享文件夹和记录的提升特权。共享管理员对其可以访问的任何共享记录拥有完全的用户和记录特权。

Secrets Manager 加密模型

Keeper Secrets Manager 是面向 IT 和 DevOps 专业人员的零知识平台。团队可使用该解决方案在整个软件开发和部署生命周期中管理密钥。

Secrets Manager 使用以下加密模型

• 加密和解密是在设备本地进行（而不是在服务器上）。
• 设备上从不存储纯文本。
• 服务器从不接收纯文本。
• 任何人（包括 Keeper 员工、第三方或中介方）都无法解密机密。
• 客户端设备在用户的控制下管理用于加密和解密机密的密钥。
• 在 GCM 模式下，每个机密都由客户端生成的 256 位 AES 加密密钥进行加密。
• 如果机密包含在共享文件夹中，则记录密钥由共享文件夹密钥封装。
• 256 位 AES 应用密钥在客户端生成，用于解密共享文件夹和记录密钥。然后，记录密钥将解密单个机密。
• Keeper 服务器使用 256 位 AES 密钥和 TLS 进行封装，以防御 MITM 攻击。
• 传输密钥在客户端设备生成，并通过服务器的 EC 公钥使用 ECIES 加密传输至服务器。
• 椭圆曲线加密用于在用户之间共享机密，以进行安全的密钥分发。
• 多层加密提供用户、群组和管理员级的访问控制。
• 在保管库中管理的机密被划分成不同部分，并隔离在指定的 Secrets Manager 设备，这些设备被授权访问记录和文件夹。

用于密码轮换的 Keeper 密钥管理器模型

• 在客户环境中安装了一个称为网关的独特客户端 Keeper Secrets Manager (KSM)。
• 网关与 Keeper 路由器建立一条安全的出站连接。
• 该路由器是一个托管在 Keeper 的 AWS 环境中的云服务，可便于 Keeper 后端 API、最终用户应用（Web 保管库、桌面应用等）和安装在用户环境中的网关之间进行通信。
• 使用当前的会话令牌，在最终用户设备（例如 Web 保管库）和 Keeper 路由器之间建立 WebSocket 连接。
• Keeper 路由器验证会话令牌并对会话进行身份验证。发送到 Keeper 路由器的所有加密有效负载均使用 256 位 AES 密钥和 TLS 进行封装，以防御 MITM 攻击。
• 256 位 AES 密钥在最终用户设备上创建，并通过路由器的 EC 公密使用 ECIES 加密传输至服务器。
• 轮换和发现请求通过已建立的 Websocket 通信渠道在最终用户设备（或 Keeper 调度程序）和网关之间发出。
• 在进行轮换期间，当网关需要从 Keeper 保管库获取机密时，它会使用 Keeper Secrets Manager API 对机密进行身份验证和解密，以保持零知识。
• 与任何其他 Secrets Manager 设备一样，除了加密和签名过程之外，还可以基于 IP 地址限制访问。

零信任连接和隧道安全

零信任 KeeperPAM 提供无需 VPN 即可建立云和本地特权会话、创建隧道、建立直接基础设施访问和安全远程数据库访问的能力。

连接是使用 Web 浏览器的可视远程会话。用户和目标设备之间的交互是在网络浏览器窗口或在 Keeper Desktop 应用程序内完成。

隧道是通过 Keeper 网关在本地保管库客户端之间建立的通往目标端点的 TCP/IP 连接。 用户可以使用任何本地应用程序与目标端点通信，比如命令行终端、GUI 应用程序或数据库管理应用程序（比如 MySQLWorkbench）。

用户建立连接或隧道后：

1. 保管库客户端应用程序与 Keeper 路由器基础设施通信，以启动 WebRTC 连接，该连接由存储在相关 Keeper 记录内的 ECDH 对称密钥保护。
2. Keeper 网关通过仅出站的 WebSockets 与 Keeper 路由器通信。此链接中有具体说明。
3. Keeper 网关使用 Keeper 密钥管理器 API 从保管库中检索必要的密钥，包括 ECDH 对称密钥。
4. 如果是连接，保管库客户端（使用 Apache Guacamole 协议）通过 WebRTC 连接将数据传递给 Keeper 网关 ，然后使用Guacd 连接到 Keeper 记录中找到的目的地。
5. 如果是隧道功能（端口转发），则在运行 KeeperDesktop 软件的本地设备上打开本地端口。发送到本地端口的数据通过 WebRTC 连接传输到 Keeper 网关，随后转发到 Keeper 记录中定义的目标端点。
6. 连接的会话记录由 AES-256 加密密钥（以下称“记录密钥”）保护，该密钥在每次会话的 Keeper网关上生成。 记录密钥另外还使用 HKDF 衍生的 AES-256 资源密钥包装。

远程浏览器隔离安全

Keeper 远程浏览器隔离技术通过 Keeper Connection Manager Docker 容器或 Keeper网关保护对内部 Web 应用程序或任何其他基于网络资源的访问。

使用 Connection Manager Docker 容器方法：

1. 用户使用托管在 Docker 容器中网络服务对 Keeper Connection Manager 进行身份验证。
2. 用户为目标网络应用程序启动远程浏览器隔离会话。在用户的浏览器和托管的 Keeper Connection Manager 网络服务之间，通过 HTTPS 进行的通信由 Let's Encrypt 或客户指定证书保护。
3. 在 Keeper Connection Manager Docker 容器中，在沙箱中执行嵌入式 Chromium 版本，使用本地显示驱动程序呈现目标网站，该驱动程序使用 Apache Guacamole 协议将页面的可见内容实时流式传输到用户的网络浏览器。

将 Keeper 网关与 Keeper Web 保管库或桌面应用程序一起使用 Keeper 网关：

1. 保管库客户端应用程序与 Keeper 路由器基础设施通信，以启动 WebRTC 连接，该连接由存储在相关 Keeper 记录内的 ECDH 对称密钥保护。
2. Keeper 网关通过仅出站的 WebSockets 与 Keeper 路由器通信。此链接中有具体说明。
3. Keeper 网关使用 Keeper Secrets Manager API 从保管库中检索必要的密钥，包括 ECDH 对称密钥。
4. 保管库客户端（使用 Apache Guacamole 协议）通过 WebRTC 连接将数据传递给 Keeper 网关 ，然后使用 HTTP 或者 HTTPS 连接到 Keeper 记录中找到的目的地。
5. 连接的会话记录由 AES-256 加密密钥（以下称“记录密钥”）保护，该密钥在每次会话的 Keeper网关上生成。 记录密钥另外还使用 HKDF 衍生的 AES-256 资源密钥包装。

浏览器隔离保护

使用远程浏览器隔离协议激活若干安全措施：

1. 被保护的 Web 应用程序端点从 Keeper Connection Manager 网关到用户的本地设备均有一层 TLS 包裹，无论是否在网关和端点之间使用 TLS - 以保护用户本地网络免受 MITM 攻击或数据包检查。
2. 远程浏览会话使用画布和图形渲染将交互直观地投射到用户的本地设备。目标网站的 JavaScript 代码或 HTML 在用户的本地机器上执行。
3. 由于目标网站代码不会在本地执行，本地浏览器也无法直接访问底层应用程序代码，因此隔离的 Web 应用程序可以免受反射型跨站脚本漏洞、跨站请求伪造和 API 滥用等攻击媒介的侵害。
4. 可以通过 URL 和资源请求过滤限制最终用户执行目标端点的数据泄露。即使目标网络应用程序允许操作，文件上传和下载也会受到限制。
5. 可以记录浏览会话和击键以进行审计和合规目的，从而提供对基于网络的会话进行法证分析的能力。
6. 从网关自动填充到目标网络应用程序的凭证绝不会传输到用户的设备，用户无法在其本地设备上访问，从而防止秘密泄露。
7. 通过防火墙策略，可以要求用户只能通过远程浏览器隔离会话访问目标 Web 应用程序，从而减少来自浏览器或本地设备恶意软件的威胁。
8. 即使应用程序不支持目标 Web 应用程序，也要使用单点登录和/或 MFA 身份验证保护目标 Web 应用程序。Keeper 通过本文件中所述的高级身份验证方法保护对保管库和任何远程浏览器隔离会话的访问。

BreachWatch^®

Keeper 在 AWS 上运行着一个称为 BreachWatch 的托管式独立架构。BreachWatch 在物理上与 Keeper API 和用户记录是分开的。

BreachWatch 服务器上的物理硬件安全模块 (HSM) 用于处理、哈希和存储来自暗网数据泄露事件的数十亿个唯一密码。所有密码均在 Keeper 的服务器上使用 HMAC_SHA512 哈希方法进行处理，并使用不可导出的密钥在 HSM 中进行哈希运算。

在客户端设备上激活 BreachWatch 时，会根据每条记录生成 HMAC_SHA512 哈希，并发送给服务器。在服务器上，通过 HSM 使用不可导出的密钥以 HMAC_SHA512 创建第二个哈希。对“哈希的哈希”进行比较，以检查凭据是否已泄露。

BreachWatch 的架构旨在防止泄露的密码与用户保管库中的密码相关联，无论数据泄露的规模如何。泄露密码的检测使用了物理 HSM，确保哈希运算只能在线执行，以防止对数据的任何暴力攻击。

• 密码经过两次 HMAC_512 哈希处理：一次在客户端设备上使用“胡椒粉”进行哈希，另一次在 AWS CloudHSM 中使用硬件安全模块和不可导出的密钥进行哈希。
• 之所以采用 HMAC_512 是因为它利用了强大的哈希函数以及不可导出的机密密钥。因此，对哈希进行离线攻击并不可行。
• 使用密码学哈希函数的结果生成消息认证码 (MAC) 扩展了哈希函数的用途。其结果不仅取决于消息，还依赖于另一个可能是机密密钥的输入。

BreachWatch 是 100% 由 Keeper 构建，它使用了 SpyCloud 数据源，但 Keeper 从不将任何数据发送给第三方。

域扫描

BreachWatch 客户下载涉及泄露的域名列表，并在本地执行检查。

用户名和密码扫描

客户端设备连接到 BreachWatch 并上传一份哈希处理后的用户名（或密码）列表，以及客户端选择的随机标识符（用户名检查服务和密码检查服务使用不同的标识符）。使用硬件安全模块 (HSM) 和存储在 HSM 中标记为不可导出的密钥（这意味着 HSM 将仅在本地处理 HMAC，并且无法提取密钥）通过 HMAC 在上传时处理这些密码哈希值。将这些 HMAC 输入（用户名或密码）与已使用相同 HMAC 和密钥处理的泄露数据集进行比较。任何匹配项都将报告给客户端设备。任何不匹配的值则与客户端的匿名 ID 一起存储。

当有新的泄露用户名和密码添加到系统时，它们将在 HSM 中使用 HMAC 进行处理，添加至 BreachWatch 数据集，并与存储的客户端值进行比较。任何匹配项都将进入该客户端 ID 警报队列。

客户端定期连接 BreachWatch 并出示其 BreachWatch ID。任何消息队列均会被下载，客户端亦将上传任何以相同方式处理的新的或更改的用户名和密码。

BreachWatch 服务的安全性采用首次使用时信任 (TOFU)。也就是说，客户端必须假定当客户端上传其散列值时，BreachWatch 服务器未处于恶意状态（即，未被攻击者攻击）。使用 HSM 处理这些值后，可以防止离线破解尝试。换句话说，即使攻击者窃取了存储的客户端值的数据集，如果没有存储在 HSM 中的 HMAC 密钥，他们也无法离线破解这些值。

如果检测到密码泄露，客户端设备将向 BreachWatch 服务器发送用户名 + 密码组合哈希值，然后由其执行相同的 HMAC 哈希比较，以确定用户名 + 密码组合是否泄露，如果是，则返回泄露相关的域名，以便客户端设备确定用户名 + 密码 + 域名是否匹配。如果客户端设备上所有三个参数都匹配，则会向用户发送泄露严重性的警报。

面向商业和企业客户的 BreachWatch

在 Business 和 Enterprise 客户激活 BreachWatch 后，每次用户登录 Keeper 时，都会自动扫描最终用户的保管库。在用户设备上扫描的 BreachWatch 摘要数据使用企业公钥进行加密，并由企业管理员在登录至 Keeper 管理控制台时进行解密。此加密信息包括电子邮件地址、高风险记录数、已解决记录数和已忽略记录数。Keeper 管理员可以在管理控制台的用户界面中查看用户级摘要统计信息。

事件记录和报告

当集成高级报告和警报时，还可以选择将 Keeper 最终用户设备配置为将详细的实时事件传输给第三方 SIEM 解决方案和 Keeper 管理控制台报告界面。事件数据包含电子邮件地址、记录 UID、IP 地址和设备信息（事件不包括任何解密的记录数据，因为 Keeper 是零知识平台，无法解密用户数据）。

默认情况下，不会将详细的 BreachWatch 事件数据发送给高级报告和警报模块或任何连接的外部记录系统。若要激活向高级报告和警报模块报告事件级的 BreachWatch 数据，您必须在特定角色 > “强制策略” > “保管库功能”页面中启用事件角色强制策略。激活后，最终用户客户端设备将开始发送此类事件数据。由于集成第三方 SIEM 解决方案可从 Keeper 后端传输数据给目标 SIEM，因此该事件信息可由目标 SIEM 读取，并可用于识别组织内哪些记录和哪些用户的密码具有高风险。如果 Keeper 管理员不希望将记录级事件数据发送给 Keeper 高级报告和警报模块，则可以禁用此设置。

Splunk Sumo Logic LogRhythm Syslog Push IBM QRadar Azure Sentinel AWS S3 Bucket Devo Datadog Logz.io Elastic

离线模式

离线模式允许用户在无法在线连接至 Keeper 或其 SSO 身份提供程序时访问其保管库。此功能可在 Keeper 的移动应用、桌面应用以及所有浏览器的 Web 保管库中使用。

此功能的工作原理是将保管库的副本复制到用户的本地设备。离线存储的保管库数据使用 AES-GCM 加密算法进行加密，采用随机生成并通过 PBKDF2-HMAC-SHA512 保护的 256 位“客户端密钥”，迭代 1,000,000 次，并加入随机加密盐。加密盐和迭代信息存储在本地。当用户输入其主密码或使用生物识别时，将使用加密盐和迭代信息获得密钥，并尝试解密客户端密钥。然后使用客户端密钥来解密存储的记录缓存。如果在用户的保管库上启用了自我摧毁保护，那么在 5 次尝试登录失败后将自动删除所有本地存储的保管库数据。对于 Business 客户，离线访问可以根据 Keeper 管理员的角色强制策略进行限制。

紧急访问（数字遗产）

Keeper 的个人和家庭方案允许用户添加最多五个紧急联系人，以便在用户去世或发生其他紧急情况时授予他们访问保管库的权限。用户指定一个等待时间，在等待时间结束后，紧急联系人将获得访问用户保管库的权限。与紧急联系人共享保管库为零知识，并且从不共享用户的主密码。此外，还使用了 2048 位 RSA 加密与 256 位 AES 密钥。紧急联系人必须拥有 Keeper 帐户才能接受信息。

网络架构

Keeper 在北美（商业或 GovCloud）、欧洲、澳大利亚、日本和加拿大使用 AWS 来托管和运营 Keeper 解决方案及体系结构，以实现本地化数据隐私和地理隔离。利用 AWS，Keeper 可以根据需要无缝地扩展资源，为客户提供最快最安全的云存储环境。Keeper 采用多区域和多地域环境运营，以最大限度保证正常运行时间，并为客户提供最快的响应时间。Enterprise 客户可以在任意首选主要区域托管其 Keeper 租户。客户数据和对平台的访问隔离在该特定区域。

云身份验证

Keeper 创建了一个高级云身份验证和网络通信模型，旨在提供最高级别的隐私、安全和信任。身份验证模型的一些关键特性是：

• 主密码从不通过网络层传输。与大多数 SaaS 服务不同，登录凭据从不离开设备。在本地设备上使用 PBKDF2 来派生用于解密的 256 位 AES 密钥。在本地生成第二个 PBKDF2 密钥，然后使用 HMAC_SHA256 进行哈希处理以派生出身份验证令牌。Keeper 的 Cloud Security Vault 对用户的解密密钥保持零知识。
• 客户端设备与 Keeper 云之间的通信无法被拦截或解密。Keeper 利用密钥固定以及设备与 Keeper 服务器之间的额外网络级加密（传输密钥）来确保防御 MITM 攻击。
• 未经设备验证步骤，新设备将无法登录帐户。在通过这一步骤之前，无法对帐户进行任何登录尝试。Keeper 支持多种类型的设备验证方法，具体取决于所使用的身份验证方案
• 2FA 是在设备验证之后、输入主密码之前执行。如果用户已设置或强制启用了 2FA，则此步骤必须在输入主密码之前完成。
• 只有在设备验证和 2FA 步骤成功之后才能输入主密码。如果未先执行设备验证和 2FA，用户将无法继续进行主密码输入步骤。这个高级身份验证流程可抵御多种攻击方式，包括暴力攻击、密码喷洒、枚举攻击和 MITM 攻击。

传输中加密

Keeper Cloud Security Vault 受到 API 的保护，这些 API 通过客户端设备的授权进行验证。客户端在登录时将获取一个会话令牌，在每次 API 调用时都会发送该令牌。会话令牌在服务器上进行跟踪。登录可以通过主密码、会话恢复或 SAML 2.0 SSO 身份验证来完成。

使用主密码时，客户端设备使用 PBKDF2-HMAC-SHA256 获得 256 位的 “身份验证密钥”，迭代次数为 1,000,000 次，随机加盐 128 位。通过使用 SHA-256 对身份验证密钥进行哈希运算来生成“身份验证哈希”。登录时，身份验证哈希将与 Cloud Security Vault 中存储的身份验证哈希进行比较。登录后，服务器上会生成会话令牌并发送给客户端，供客户端设备用于后续的 API 请求。会话必须处于活动状态，才能继续使用客户端到服务器的通信。

Keeper 支持 256 位和 128 位 TLS，用于加密客户端应用与 Keeper 云存储之间的所有数据传输。

Keeper 部署由 DigiCert 签名的 TLS 证书使用了 SHA2 算法，这是商业证书颁发机构目前提供的最安全的签名算法。SHA2 比更广泛使用的 SHA1 安全得多，后者由于算法中所为人知的数学弱点而可能会被利用。SHA2 有助于防止颁发伪造证书，攻击者可能使用这些证书来冒充网站。

Keeper 还支持证书透明度 (CT)，这是 Google 的一项举措，用于创建由证书颁发机构签名的可公开审核的证书记录。CT 有助于防止未经授权的实体颁发证书。最新版本的 Chrome、Safari 和 Brave 网络浏览器当前已支持 CT。有关证书透明度的更多信息，请访问：https://certificate.transparency.dev/。Keeper 支持以下 TLS 密码套件：

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• ECDHE-ECDSA-AES128-GCM-SHA256
• ECDHE-RSA-AES128-GCM-SHA256
• ECDHE-ECDSA-AES128-SHA256
• ECDHE-RSA-AES128-SHA256
• ECDHE-ECDSA-AES256-GCM-SHA384
• ECDHE-RSA-AES256-GCM-SHA384
• ECDHE-ECDSA-AES256-SHA384
• ECDHE-RSA-AES256-SHA384

Keeper 在 iOS 和 Android 上的客户端设备还实现了密钥固定，这是一种安全机制，可防止攻击者使用伪造的数字证书冒充身份。

跨站点脚本 (XSS) 攻击预防

Keeper Web 保管库实施严格的内容安全策略，限制出站请求的来源，并阻止执行明确来自 Keeper 的脚本之外的所有脚本，包括内联脚本和事件处理 HTML 属性，此减少或消除跨站脚本攻击的大多数载体。

访问 Keeper 域名仅限于通过使用 TLS 1.3 的 HTTPS，并由 HTTP 严格传输安全协议强制执行。这可以防止各种数据包嗅探、数据修改和中间人攻击。

在 Keeper 浏览器扩展中，Keeper 不会在页面框架区域内提示用户输入其保管库凭据。登录至扩展发生在浏览器的浏览器扩展工具栏区域内。在 Web 浏览器上登录到保管库将始终发生在 keepersecurity.com、keepersecurity.eu、keepersecurity.com.au、keepersecurity.jp、keepersecurity.ca 或 govcloud.keepersecurity.us 域中，或者从存在于内容页面之外的 Keeper 浏览器扩展工具栏进行。

Keeper 浏览器扩展在网页的登录表单中嵌入了一个 iFrame，以确保任何恶意网站都无法访问注入的内容。注入 iFrames 的记录内容也仅限于存储在用户保管库中与目标网站域名匹配的保管库记录。除非网站域名与 Keeper 保管库记录的网站域名字段匹配，否则 Keeper 不会提供自动填充登录信息或密码数据。除非记录与网址根域名匹配，否则扩展不会显示记录。

第三方浏览器扩展在 Web 浏览器中可能具有提升的权限，并且可以访问页面内的信息。因此，建议 Keeper 管理员阻止用户从浏览器的相应应用商店安装第三方浏览器扩展。

生物识别

Keeper 原生支持 Windows Hello、触控 ID、面容 ID 和 Android 生物识别。通常使用主密码或企业 SSO 登录 (SAML 2.0) 登录其 Keeper 保管库的客户也可以使用生物识别登录其设备。生物识别必须由 Keeper 管理员在角色策略中启用。激活此功能时，使用主密码和启用 SSO 的用户亦可通过生物识别功能实现离线访问。

在设备上启用生物识别登录时，密钥将随机生成并存储在设备的安全隔离区（例如钥匙串或密钥库）。用户的数据密钥使用生物识别密钥进行加密。成功完成生物识别身份验证后，将获取密钥，然后用户即可解密其保管库。

iOS 钥匙串、触控 ID 和面容 ID

iOS 设备上的触控 ID 和面容 ID 允许用户使用生物识别访问其 Keeper 保管库。为了提供这一方便的功能，软件将随机生成 256 位“生物识别密钥”并存储在 iOS 钥匙串中。为此功能创建的 iOS 钥匙串项未指定为与 iCloud 钥匙串同步，因此不会离开您的 iOS 移动设备。

强烈建议您使用复杂的主密码，并启用多步验证，以便为您加密的 Keeper 保管库提供最大的安全性。使用触控 ID 和面容 ID 可以让在 iOS 移动设备上使用复杂的主密码更方便。另外建议您设置一个比至少 4 位数更长的密码来确保 iOS 钥匙串安全。

iOS 和各类应用通过 iOS 钥匙串安全地存储身份凭据。iOS 应用使用 iOS 钥匙串来存储各种敏感信息，包括网站密码、密钥、信用卡号码和 Apple Pay 信息。Keeper 不使用 iOS 钥匙串来存储您的 Keeper 记录 - 所有 Keeper 记录都使用 256 位 AES 加密进行保护，并安全地存储在 Keeper 保管库中。iOS 钥匙串亦使用设备的密码以 256 位 AES 加密进行加密。即使设备丢失或被盗或攻击者获得了对移动设备的物理访问，他们也无法访问任何存储在 Keeper 中信息。没有密码无法解密 iOS 钥匙串，没有用户的 Keeper 主密码无法解密 Keeper 保管库。

Apple Watch^®

Apple Watch的收藏功能使您能在配对的Apple Watch上查看选定的记录。Keeper记录必须被加入Watch收藏后才能在Apple Watch进行查看。一个配对的Apple Watch与Keeper的Watch扩展进行通讯，该扩展在iOS Keeper应用程序以外的沙盘进行透明的运行。Keeper的Watch扩展也使用iOS Keychain来安全地储存并访问秘钥以确保其与iOS Keeper应用程序进行无缝且安全的通讯。

KeeperDNA^®

KeeperDNA 提供了一种使用智能手表设备的多步验证方法。KeeperDNA 使用存储在 Keeper 保管库中的安全令牌来生成基于时间的验证码以进行多步验证。这些基于时间的身份验证请求可以通过点按 Apple Watch（或 Android Wear 设备）的屏幕或用户手动输入，自动从该设备批准和发送。

员工离职（保管库转移）

为节点激活帐户转移策略后，用户设备上的管理控制台将创建公钥/私钥对的节点策略。当用户登录保管库时，最终用户的数据密钥（适用于启用了角色强制策略的用户）将使用策略的公钥进行加密。私钥使用管理员的公钥进行加密，然后管理员可以通过保管库转移来解密角色强制密钥。

执行保管库转移时，Keeper 管理员必须先锁定用户的帐户。接下来就可以立即进行保管库转移，然后删除用户的帐户。这将确保没有秘密执行的操作。在执行转移时，首先解开角色强制私钥，然后解开用户的数据密钥，从而获取用户的数据密钥。数据密钥用于解开记录密钥、团队密钥和文件夹密钥。

所有加密都是在客户端的管理控制台中进行，Keeper 在任何时候都无法解密正在共享或转移的信息。此外，任何时候都不会共享用户的客户端数据密钥。从团队、共享文件夹或直接共享中移除的用户将不会再从团队、共享文件夹或记录收到新的数据。尽管在操作过程中，在本地为管理员解密了记录、文件夹和团队密钥，但这些密钥不能用于访问底层的记录或文件夹数据。

在保管库转移期间，管理员仅收到加密的数据密钥、加密的记录密钥和加密的文件夹密钥。他们对这些密钥进行解密，然后使用目标保管库的公钥重新加密。他们永远无法访问实际的记录数据。Keeper 不会使用数据密钥直接加密客户端存储的数据，加密发生在设备上。

认证与合规

Keeper 是全球最安全的、经过认证、测试和审核的密码安全解决方案和特权访问管理平台。 Keeper 拥有业内历史最悠久的 SOC 2 和 ISO 认证。Keeper 已通过 ISO 27001、27017 和 27018 认证。Keeper 符合 GDPR、CCPA、HIPAA 要求，已获 FedRAMP 和 StateRAMP 授权，已通过 PCI DSS 认证和 TrustArc 隐私认证。

• Keeper 的软件开发团队由位于美国的全职员工组成。
• Keeper 不会在源代码中存储密码、凭据或机密（例如访问密钥）。我们会定期扫描源代码是否有这类信息。
• 虽然 Keeper 的源代码托管在私有的 GitHub Enterprise 上，但并未提供访问用户保管库所需的信息，因为数据加密是在设备级别进行。其中大部分代码作为 Keeper 的 Commander 和 Secrets Manager 产品的一部分发布在我们的公共 GitHub 存储库中。
• Keeper 不会将第三方 MFA 提供者代码嵌入到我们的应用中。Keeper 的供应商没有经历过任何涉及 Keeper 的泄露事件。
• Keeper 不向任何第三方提供管理或访问我们的 AWS 数据中心的权限。所有管理工作均由 Keeper Security 位于美国并拥有美国国籍的全职员工执行。

经 FIPS 140-3 验证

Keeper 使用经 FIPS 140-3 验证的加密模块来满足严格的政府和公共部门安全要求。Keeper 的加密已通过 NIST 加密模块验证计划 (CMVP) 认证，并由经认可的第三方实验室验证为达到 FIPS 140 标准。

Keeper 使用 FIPS 140-3 验证加密，已根据 NIST CMVP 颁发 证书 #4743。

符合 ITAR

Keeper Security Government Cloud (KSGC) 支持遵守美国国际武器贸易条例 (ITAR)。受 ITAR 出口法规约束的公司必须通过限制仅美国公民可访问受保护数据和限制受保护数据的物理位置位于美国来控制非预期出口。

KSGC 的 FedRAMP 中等环境通过以下方式支持 ITAR 要求：

• 完全合规的数据存储托管在 AWS GovCloud 上，并且仅限位于美国。
• KSGC 对传输数据和静态数据均进行了安全加密。
• 零知识和零信任安全与细粒度权限相结合，使组织能够确保只有经批准的人员才能访问敏感数据。
• 强大的合规报告功能为所有执行的操作和输入的数据提供可追溯的电子审核跟踪。
• 隔离的客户成功团队由美国公民组成，经过专门培训以安全地处理受出口控制和 ITAR 管制的数据，没有来自非美国的支持人员。

Keeper FedRAMP 环境已由独立的第三方评估组织 (3PAO) 审核，以验证是否采取了适当的控制措施来支持客户出口合规计划，并继续按照要求每年进行审核以保持合规。

有关 ITAR 的更多信息。

FedRAMP 已授权

KSGC 是 Keeper Security 为公共部门组织提供的密码管理和网络安全平台。KSGC 是一个经 FedRAMP 授权的中等影响级别提供商，托管于 AWS GovCloud（美国）。KSGC 可以在 FedRAMP 市场上找到。

联邦风险和授权管理计划 (FedRAMP) 是美国联邦政府的一项计划，为云产品和服务的安全评估、授权和持续监视提供标准化方法。FedRAMP 旨在加速政府机构采用基于云的现代解决方案，重点是联邦信息的安全和保护。了解有关 FedRAMP 的更多信息。

经 StateRAMP 授权

StateRAMP 是在 FedRAMP 之后十年左右开发的，其目标是鼓励各州和地方政府采用基于云的安全解决方案。通常获得 StateRAMP 授权需要大约两年的时间，得益于 Keeper 已获得了 FedRAMP 授权，使得这个过程通过相互认可计划得到简化。

符合 SOC 2

客户保管库记录使用严格且受到严密监视的内部控制措施进行保护。根据 AICPA 服务组织控制框架，Keeper 已连续十多年经认证符合 SOC 2 类型 2 标准。SOC 2 合规有助于通过实施 AICPA 信任服务原则框架中定义的标准化控制来确保用户保管库的安全。

ISO 认证

Keeper 已通过 ISO 27001、27017 和 27018 认证，涵盖 Keeper 安全信息管理系统和云基础设施，支持 Keeper 企业平台。Keeper 的 ISO 认证包括数字金库和云服务的管理和运营、云安全控制、数据隐私控制、软件和应用程序开发，以及数字金库和云服务的数字资产保护。

符合 FDA 21 CFR 第 11 部分要求

Keeper 符合 21 CFR 第 11 部分的要求，该部分适用于在需高度监管的环境中工作的科学家，包括进行临床试验的研究人员。该法规规定了美国 FDA 的标准，其中电子记录和签名被视为可信赖、可靠且等同于采用手写签名的纸质记录。具体而言，科学家必须确保其使用的所有软件均符合 21 CFR 第 11 部分关于以下方面的规定：

用户身份的安全控制 - Keeper 符合 21 CFR 第 11 部分对限制用户访问及其特权的安全功能的要求，包括确保所有用户具有唯一的用户名和密码、检测和防范未经授权的系统访问以及锁定已泄露帐户的能力。

详细的稽查轨迹

在 FDA 检查期间，监管者将要求研究人员提供稽查轨迹，详细说明所有操作按时间顺序进行的记录。Keeper 的合规报告功能使研究人员能够轻松生成可追溯的电子稽查轨迹。

电子签名

当文档需要具有法律约束力的电子签名时，21 CFR 第 11 部分要求将签名附加到唯一的登录名和密码或生物识别信息上。Keeper 支持这一要求，它使研究人员能够确保所有用户都具有唯一的用户名和密码，并安全地存储在只有用户才能访问的数字保管库中。

有关 21 CFR 第 11 部分的更多信息，请点击此处。

保护患者医疗数据

Keeper 软件符合全球医疗数据保护标准，包括但不限于 HIPAA（健康保险流通与责任法案）和 DPA（数据保护法案）。

HIPAA 合规性和业务伙伴协议

Keeper 是一个通过 SOC2 认证和 ISO 27001 认证的零知识安全平台，符合 HIPAA 要求。我们严格遵守和控制隐私性、机密性、完整性和可用性。使用此安全体系结构，Keeper 无法解密、查看或访问存储在用户 Keeper 保管库中的任何信息，包括 ePHI。基于上述原因，Keeper 不是健康保险流通与责任法案 (HIPAA) 中定义的业务伙伴，因此不受业务伙伴协议的约束。

若要了解更多为医疗保健提供商和医疗保险公司提供的其他好处，请阅读完整的安全披露，并访问我们的企业指南。

FSQS-NL 认证

Keeper Security EMEA Limited 获得了荷兰 Hellios 金融服务资格体系 (FSQS-NL) 的认证，其代表认可在荷兰的安全、质量和创新方面的最高标准。该标准证明符合金融市场行为监管局和审慎监管局的要求，以确保大型银行和金融机构使用 Keeper Enterprise 软件的可信赖性。

符合美国出口管理条例（EAR）美国商务部出口许可

Keeper 获得了美国商务部工业和安全局的认证，出口商品管制分类编码为 5D992，符合《出口管理条例》(EAR)。
关于 EAR 的更多信息请参阅：https://www.bis.doc.gov

24x7 远程监控

Keeper 由全职 DevOps 员工和一个全球第三方监视网络进行 24x7x365 全天候监视，以确保我们的网站和 Cloud Security Vault 在全球范围内可用。

如果您对此安全披露有任何疑问，请联系我们。

网络钓鱼或仿冒电子邮件

如果您收到一封声称是 Keeper Security 发送的电子邮件而不确定其是否合法，则有可能是一封发件人电子邮件地址经伪造或“欺骗”的“钓鱼邮件”。在这种情况下，电子邮件可能包含一个看起来网站像是 KeeperSecurity.com 但并不是我们网站的链接。该网站可能会要求您提供您的 Keeper Security 主密码，或尝试在您的电脑上安装不需要的软件，以试图窃取您的个人信息或访问您的电脑。一些其他电子邮件包含可能会将您重定向至其他有潜在危险的网站的链接。邮件的附件通常还可能包含您不需要的称为“恶意软件”的软件。 如果您不确定您收件箱中收到的某封电子邮件是否安全，您应该删除它而不点击任何链接或打开任何附件。

如果您希望报告您认为是伪造的声称是 Keeper 发送的电子邮件，或者您有其他涉及其他事项的安全问题，请联系我们。

托管基础设施经过最严格的行业标准认证

Keeper网站和云储存使用安全的亚马逊网络服务（AWS）的云计算基础设施。使用AWS云基础设施的Keeper体系结构已满足以下的第三方的认证，报告和证书：

漏洞报告和 Bug 赏金计划

Keeper Security 致力于开发市面上最安全的密码和特权访问管理解决方案。我们致力于保护客户的隐私和个人数据。Keeper 的使命是构建世界上最安全、最具创新性的安全平台，我们相信来自全球安全研究人员社区的 Bug 报告对于确保 Keeper 产品和服务安全至关重要。

Keeper 进行了广泛的内部和外部测试，包括由 NCC Group 和 CyberTest 执行的具有完整源代码访问权限的渗透测试。Keeper 与 Bugcrowd 合作管理其漏洞披露计划。总体而言，这有利于整个行业，而且还支持了社会公益。

指南

Keeper 的漏洞披露政策提出了我们对与善意黑客合作的期望，以及您对我们可以期望什么。

如果安全测试和报告是在本政策的指南内完成，我们：

• 将视其为根据《计算机欺诈和滥用法》获得授权。
• 将视其可豁免数字千年版权法（DMCA），不会因绕过任何安全或技术控制而向您提出索赔。
• 将视其为合法，不会针对您追究或支持任何与本计划相关的法律诉讼。
• 将与您合作，快速了解并解决问题。
• 如果您是首位报告问题的人，我们将公开认可您的贡献，并根据问题进行代码或配置更改。

如果您在任何时候担心或不确定测试的方式是否符合本政策的指南和范围，请在继续之前与 security@keepersecurity.com 联系。

为了鼓励善意的安全测试和披露发现的漏洞，我们敬请您：

• 避免侵犯用户隐私，损害用户体验，扰乱生产或公司系统和/或破坏数据。
• 仅在下方链接的 Bugcrowd 漏洞披露计划规定的范围内进行研究，并尊重超出范围的系统和活动。
• 如果您在测试期间接触到任何用户数据，请立即通过 security@keepersecurity.com 联系我们。
• 在公开披露任何漏洞发现之前，请给我们合理的时间来分析、确认和解决报告的问题。

请通过此链接提交报告：https://bugcrowd.com/keepersecurity

透明度

Keeper 不仅致力于安全；我们对安全极度热衷。这就是为什么我们向公众公开我们的加密模型每一个细节的原因。我们相信，面对不断变化的网络安全环境，我们的客户理应了解我们为确保其数据安全所采取的每一步措施。

Keeper 的零信任和零知识加密模型可确保即使在最坏的情况下，您的 Keeper 保管库也能受到保护，并且我们会持续进行安全测试，以确保我们始终是保护您最宝贵数据的最佳解决方案。

现代奴隶制声明

产品文档

Keeper 的文档门户包含产品手册、技术信息、发布说明和最终用户指南，请访问此链接获取。

产品发布说明

为了提高透明度，Keeper 针对每个平台提供了详细的发布说明。

系统状态

实时系统状态可以在这里找到。