Keeper 致力于数据保护和密码管理程序安全性

总览

Keeper Security, Inc. (KSI) 热衷于通过Keeper的移动设备和桌面电脑安全软件来保护用户的数据安全。数百万的用户的企业信赖并使用Keeper来保护他们的密码和个人信息的安全性。

Keeper的软件一直不断进行更新和改进以提供给我们的客户最新的数据安全保护技术。本页面将对Keeper的安全架构，加密方法和最新版本的宿主环境进行概述。涉及我们加密和安全技术详情的概述可在本文中找到。

我们的隐私政策以及使用条款可通过以下链接查看：

Privacy Policy 条款与条件

数据保护

零信任始于密码安全。KSI 使用零信任安全框架创建其产品，该框架基于不信任体系结构中的任何用户。零信任假定所有用户和设备都可能受到威胁，因此，每个用户在访问网站、应用或系统之前都必须经过验证和认证。此网络安全框架是 Keeper 网络安全平台的基础。我们的平台使 IT 管理员能够全面了解他们访问的所有用户、系统和设备，从而有助于确保符合行业和法规要求。为了在组织中建立零信任框架，其必须具有由零知识安全体系结构提供支持的世界级密码安全性。

零信任体系结构

点击 i 信息图标以进一步了解。

最终用户

任何客户端设备上的 Keeper 用户，包括电脑、手机、浏览器和命令行。

Identity Provider

IdP 是一项存储和管理用户身份的服务。

SAML 应用

允许跨安全域扩展 SSO，使 Web 浏览器 SSO 成为可能。

SecOps、DevOps 和 IT

可访问高度敏感的帐户、登录信息和机密的特权用户。

Keeper Admin Console

使用此平台为最终用户配置和强制实施业务策略。

Keeper Connection Manager (KCM)

无需 VPN 即可实现对您的基础设施的零信任网络访问。

Keeper Secrets Manager (KSM)

保护基础设施机密，例如 API 密钥、数据库密码、访问密钥、证书和任何类型的机密数据。

Keeper Enterprise 密码管理程序（EPM）

保护您的密码和个人信息免受网络犯罪分子的攻击。

客户端设备、机器和浏览器

访问安全密码保管库的最终用户设备。

Windows、Linux、MySQL、SQL Server、PostgreSQL

特权用户经常访问的各类端点。

Jenkins、GitHub、Terraform、PowerShell

用于自动化应用构建和开发流程的 DevOps 和开发人员工具。

基于密码的应用

需要进行登录的网站、应用和系统。

观看零信任视频

KSI无法访问用户的主密码，KSI也无法访问用户保存在Keeper数据库内的记录信息。KSI无法远程访问用户的设备或解密其数据。Keeper Security 能唯一访问的信息是该用户的电子邮件，设备种类，套餐订阅详情（如：Keeper Backup）。如果某个用户的设备丢失或被盗， KSI能帮助用户在更换设备后，访问其加密的备份文件以还原该信息。

保存在Keeper内的信息只能由该用户本人访问，因为这些信息都是即时被加密或在用户使用该设备的Keeper应用程序被即时解密的，即使是在该用户使用Keeper的网络应用程序时。Keeper所使用的加密方法是著名的，并被广为认可的256位AES（高级加密标准）算法。256位AES加密算法是军用级别的加密技术并由美国政府认可来用于加密高度敏感信息。根据美国国家安全系统委员会出版的CNSSP-15，256位AES密钥长度能足够安全地加密美国政府的分类数据中的最高机密数据。 Keeper 经 NIST CMVP 认证和验证，达到 FIPS 140-2 标准（证书编号 3976 - https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976）

用于加密和解密用户记录的密钥不保存且不被传送至Keeper's Cloud Security Vault。然而，为了提供多设备间的同步功能，该密钥的加密版本被保存在Cloud Security Vault 上，并提供给该用户的所有设备上。这个加密的密钥只能在解密后才能作为设备的数据密钥来使用。

高强度主密码

我们强烈建议我们的用户为其Keeper账户设置一个高强度的主密码。该主密码不应该在Keeper以外的范围使用。同时，用户不应该将该主密码透露给其他任何人。

两步验证

为防止您的保管库、网站和应用被未经授权访问，Keeper 还支持两步验证。两步验证是一种身份验证方法，要求提供三种身份验证因素中的两种或多种：知识因素、拥有因素和固有因素。有关两步验证的更多信息请参阅此链接。

Keeper 使用您知道的东西（您的密码）和您拥有的东西（您的电话）来在您的主密码或设备受到威胁的情况下为您提供额外的安全保障。为此，我们生成 TOTP（基于时间的一次性密码）。

Keeper 使用加密安全随机数生成器来生成一个 10 字节的密钥。此代码有效时间约为一分钟，并通过短信、Duo Security、RSA SecurID、TOTP 应用、Google Authenticator 或与 Keeper DNA 兼容的可穿戴设备（如 Apple Watch 或 Android Wear）发送给用户。

在您的移动设备上使用 Google Authenticator 或 TOTP 应用时，Keeper 服务器内部会生成一个包含您密钥的二维码，并且不会传送给第三方。每次用户停用然后重新启用两步验证时，将生成一个新的密钥。

若要激活两步验证，请访问 Keeper DNA 或 Keeper Web App 的设置页面。Keeper Business 客户可以通过 Keeper Admin Console 的角色强制设置功能选择强制使用两步验证登录保管库和支持的两步验证方法。

FIDO WebAuthn 安全密钥

Keeper 支持兼容 FIDO WebAuthn 的基于硬件的安全密钥设备（例如 YubiKey ）作为第二步验证。安全密钥提供了方便而安全的方式来执行两步验证，而无需用户手动输入 6 位数字验证码。可以为用户的保管库配置多个安全密钥。对于不支持安全密钥设备的平台，用户可以回退到配置的其他两步验证方法。若要配置安全密钥和其他两步验证方法，请访问 Keeper 应用程序的“设置”页面。

紧急访问（数字遗产）

Keeper 支持添加最多 5 位紧急联系人，并授予其在发生紧急情况或死亡事件时访问保管库的权限。在指定的等待时间结束后，紧急联系人将获得访问用户保管库的权限。共享保管库的过程为零知识，并且用户的主密码从不直接共享。在原用户设置的等待时间过去后，将使用 RSA 加密来与紧急联系人共享 256 位的 AES 密钥。因此，紧急联系人必须有一个 Keeper 帐户（以及 RSA 公钥/私钥对）来接受邀请。

帐户恢复

在帐户注册期间，可能会要求用户选择自定义的安全问题和答案或者其他类型的恢复方法。此外，在注册期间，Keeper 将生成一个 256 位 AES 数据密钥，用于加密和解密与每条保管库记录一同存储的记录密钥。用户的数据密钥采用从主密码派生的密钥加密，并使用 PBKDF2 进行最多 1,000,000 次迭代，每个 AES-256 记录密钥均采用 AES-256 数据密钥加密。用户保管库中的每条记录都有单独的不同客户端生成的记录密钥。

帐户恢复的工作原理（使用安全问题方法）是存储用户数据密钥的第二个副本，并使用从选定的安全答案派生的密钥加密，最多迭代 1,000,000 次。若要完成保管库恢复，用户需要输入电子邮件验证码以及两步验证码（若已在帐户中启用）。我们建议您创建高强度的安全问题和答案，并在“设置”页面打开 Keeper 的两步验证功能。基于 Keeper Enterprise 帐户的配置，可能会禁用帐户的恢复。通过 Keeper 管理控制台亦可对 Keeper Enterprise 客户强制两步验证。

Business 和 Enterprise 客户可使用 Keeper 的帐户转移政策为其用户提供零知识帐户恢复方法。

客户端加密

用户数据是在其设备上而不是在Cloud Security Vault上进行加密或解密的。我们将此称为“加密用户端”，因为用户端（如： iPhone、 Android 设备、网络应用程序等）在执行所有的加密工作。 Cloud Security Vault 储存原始的二进制文件，这类二进制文件对侵入者来说基本上是没有的。即使数据在用户端Cloud Security Vault之间进行传送的时候被窃取，该文件无法被解密，也无法用来攻击或损害用户的私人数据。

破解或黑掉一个对称的256位密钥需要相当于2¹²⁸倍128位密钥的计算能力。理论上说，这将需要该台设备3×10⁵¹年时间来用尽256位密钥空间。

共享

每个用户都有公钥和私钥 256 位椭圆曲线 (ECC secp256r1) 密钥对，用于在用户之间共享其他密钥（例如记录密钥、文件夹密钥和团队密钥）。共享信息采用接收人的公钥进行加密。接收人使用其私钥对共享信息进行解密。这允许用户仅与预期的接收人共享记录，因为只有接收人可以对其进行解密。为了与旧记录兼容，亦可使用 2048 位 RSA 密钥。

密钥生成

Keeper 的默认身份验证方法是使用用户选择的主密码。采用 PBKDF2 从主密码派生出一个密钥，并用于解密用户的其他密钥，例如 256 位 AES 数据密钥。在本地生成第二个 PBKDF2 密钥，然后使用 HMAC_SHA256 进行哈希处理以派生出身份验证令牌。在用户的设备通过验证并完成两步验证之前，使用主密码进行身份验证的能力将受到限制。PBKDF2 迭代次数默认为 1,000,000 次。Keeper 管理员还可以在 Keeper 管理控制台中强制设置 PBKDF2 迭代级别。

密钥存储

所有机密的密钥，例如每个用户的 Elliptic Curve 私钥、RSA 私钥和 AES-256 数据密钥，在存储或传输之前都经过了加密。对于使用主密码登录的消费者和企业用户，将从主密码派生出一个密钥，用于解密任何存储的密钥。对于使用 SSO 身份提供程序登录的企业客户，在成功进行身份验证后将向设备提供加密密钥，并使用用户的私钥来解密数据密钥和其他保管库密钥。由于 Keeper 的 Cloud Security Vault 无法访问用户的主密码或加密密钥，因此我们无法解密您存储的任何密钥或数据。

Keeper 云安全保管库

Cloud Security Vault 是指KSI'专有的软件和网络架构，托管在亚马逊网络服务（AWS）基础设施上。

当用户将他们的Keeper数据库与其账户下的其它设备进行同步时，加密的二进制文件通过储存在Keeper's Cloud Security Vault 上的加密的SSL通道以加密的方式来进行传送的。

记录版本控制

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

Keeper Business

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

记录级加密

Keeper 基于客户端生成的密钥实现多层加密系统。记录级密钥和文件夹级密钥在本地设备上生成，用于加密存储的每条保管库记录（例如密码）。例如，如果您的保管库中有 10,000 条记录，则还有 10,000 个 AES 记录密钥用于保护数据。

密钥在本地设备生成以保持零知识，并支持记录和文件夹共享等高级功能。记录和文件夹密钥由其他密钥（例如数据密钥和客户端密钥）包装。

角色、团队、共享文件夹和委派管理

Keeper 企业版提供了一套安全而稳健的组织单位、角色、团队和共享文件夹控制。Keeper 强大的后端控制是一层最稳健的安全层，提供最低权限访问和全面委派管理。

对于强制用户帐户可转移的角色：

通过允许执行转移操作的各管理员密钥对强制密钥进行加密。

（注：应用至不同用户组的不同强制可能会被指定为由不同的管理员组进行转移。）

（为应用强制角色中的用户）生成帐户文件夹密钥并通过强制密钥进行加密。提供给用户的所有记录和共享文件夹都有对应的通过帐户文件夹密钥进行加密的密钥。

帐户转移时先进行锁定，然后再转移并删除用户的帐户。这将确保没有秘密执行的操作。帐户文件夹密钥和元数据允许最终能够解密记录数据，但不允许直接访问。因此，只有在记录分配给某个人后，那个人方可使用记录，其他人则无法访问。

所有加密均是在客户端侧执行，Keeper 在任何时候均无法对共享或传输的信息进行解密。此外，在任何时候用户密钥均不会被共享。从团队、共享文件夹或直接共享中移除的用户将不会再从团队、共享文件夹或记录收到新的数据。因此，即使某个人的密钥被泄露，该密钥亦无法用于访问底层数据。

一些不同的管理特权可能会被分配给允许特权角色中的成员在 Keeper Admin Console 中执行操作的分层树的不同部分。

服务器端和客户端的强制政策亦可能应用于角色来管理个人组客户端的行为。

团队允许共享文件夹轻松分配至用户组。

Keeper Active Directory / LDAP Bridge

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

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

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

单点登录 (SAML 2.0) 身份验证

Keeper Business 客户可以配置 Keeper 使用标准的 SAML 2.0 标识产品来对用户进行身份验证以进入其 Keeper 保管库。Keeper 是各主要 SSO 身份验证标识提供程序（例如 Google Apps、Microsoft Azure、Okta、Ping Identity 等）预配置的一项服务提供程序。Keeper 用于在零知识环境下对用户进行身份验证以进入其保管库的机制称为 Keeper SSO Connect^®，已申请专利。Keeper SSO Connect^® 是 Keeper Business 管理员安装在其自己的基础设施（位于本地或云端）中的一款软件应用，作为 SAML 2.0 服务提供程序端点。当在特定的组织单位激活时，Keeper SSO Connect^® 可为 Keeper Business 最终用户管理所有的加密密钥。在成功完成身份验证进入企业单点登录身份验证标识提供程序后，用户登录至 Keeper 并通过必要的加密密钥来解密其保管库。Keeper SSO Connect^® 软件可运行在 Windows、Mac 和 Linux 环境下。

SSO Connect^® Cloud

Keeper SSO Connect^® Cloud 为 Keeper Enterprise 客户提供一种在零知识加密保管库中对用户进行身份验证和解密存储数据的方法，通过第三方身份提供程序 (IdP) 在全云环境中使用标准的 SAML 2.0 协议进行身份验证。

在此实施过程中，用户可以通过 SSO 身份提供程序进行身份验证，然后在其设备上本地解密其保管库的密文。每部设备都有自己的 EC（椭圆曲线）公钥/私钥对和加密数据密钥。每位用户都有自己的数据密钥。如要登录到新设备，用户必须使用现有设备来进行批准，或者具有权限的管理员亦可批准新设备。

此功能的重要性是，用户可以使用存储在 Keeper 云端的加密密钥解密其保管库。Keeper 云无法解密用户设备上的数据密钥，从而确保了零知识。用户的数据密钥（“DK）使用设备私钥（“DPRIV”）进行解密，加密数据密钥（“EDK”）仅在通过其指定身份提供程序（例如 Okta、Azure、AD FS）成功认证后提供给用户。

对于 SSO Connect^® Cloud 用户，将生成椭圆曲线私钥并存储在每部设备本地。对于基于 Chromium 的 Web 浏览器，Keeper 保管库将本地设备 EC 私钥（“DPRIV”）存储为不可导出的加密密钥。在 iOS 和 Mac 设备上，密钥存储于设备钥匙串。如果可用，Keeper 会使用安全存储机制。

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

不同的设备/平台具有不同的安全级别，因此，为了提供最佳安全性，我们建议使用最新的基于 Chromium 的 Web 浏览器。

作为防止设备被黑攻击的一般保护，我们还建议所有设备（例如台式电脑）均使用磁盘级加密和最新反恶意软件进行保护。

SSO 设备批准

如要登录到新设备，用户必须使用现有设备来进行批准，或者具有权限的管理员亦可批准新设备。新设备生成一组新的公钥/私钥，批准设备将使用新设备的公钥加密用户的数据密钥。新设备的加密数据密钥 (EDK) 提供给请求用户/设备，然后用户可以解密其数据密钥，随后用于解密用户的保管库数据。在解密的保管库数据中，用户可以解密其他私有加密密钥，例如记录密钥、文件夹密钥、团队密钥等。

此功能的重要性是，用户可以使用 Keeper 云端存储的加密密钥解密其保管库，并且不需要任何本地或用户托管的应用服务来管理加密密钥。Keeper 云无法解密用户设备上的数据密钥，从而确保了零知识。用户的数据密钥使用设备私钥（DPRIV）进行解密，EDK 仅在通过其指定的身份提供程序（例如 Okta、Azure、AD FS）成功认证后提供给用户。

从管理员的角度来看，其好处是：易于设置，无需托管软件来管理加密密钥，正如 Keeper 当前的 SSO Connect^® 加密模型所述。
此模型中唯一的工作流更改（与 Keeper SSO Connect^® 的本地实现相比）是用户必须在活动设备上执行新设备批准，或将执行设备批准的职责委派给 Keeper 管理员。

Keeper SSO Connect^® 本地

SSO Connect^® 本地为自托管集成，需要一个 Windows 或 Linux 托管的应用服务器。 为了保持零知识安全性并确保为用户提供无缝的 SSO 体验，必须在客户的服务器上安装 Keeper SSO Connect^®。Windows、Mac 和 Linux 环境均完全支持高可用性 (HA) 负载平衡操作模式。
Keeper SSO Connect^® 为每个已开通服务的用户自动生成并维护主密码，这是一个随机生成的
256 位密钥。此主密码使用 SSO 密钥进行加密。SSO 密钥使用树密钥进行加密。SSO 密钥是在 Keeper SSO Connect^® 服务启动时从服务器获取，然后使用树密钥进行解密，树密钥存储在服务器本地以支持自动服务启动。SSO Connect^® 与 Keeper 的 Cloud Security Vault 之间的通信使用传输密钥进行保护。

BreachWatch

BreachWatch 可在保管库内不断扫描 Keeper 的记录是否涉及公共数据泄露，并向用户发出警报。BreachWatch 采用零知识体系结构，通过多种分层技术来保护客户的信息。概括如下：

1. 通过安全的密钥加密散列函数和匿名化将密码与被泄露的帐户信息数据库进行比较。
2. 在检查是否符合泄露的密码或存储在 BreachWatch 服务器之前，客户密码将通过硬件安全模块 (HSM) 和不可导出的密钥进行处理。
3. Keeper 客户使用匿名的 BreachWatch ID 与 BreachWatch 进行交互，这些 ID 与其他 Keeper 客户标识符无关。
4. BreachWatch 通过不同的匿名 ID 将用户名和密码分离为不同的服务，以取消用户名和域名与密码的关联。
5. BreachWatch 客户并不上传域名信息，而是仅下载域名信息。

图 1. 通过 BreachWatch 获取客户散列密码数据的路径。BreachWatch 服务器仅存储使用 HSM 和不可导出密钥加密的密码。BreachWatch 客户在与 BreachWatch 服务器交互时使用匿名 ID。

为了建立安全的服务，Keeper 将 BreachWatch 分为三个服务，分别用于检查域名、用户名、密码以及用户名 + 密码对。Keeper 客户端应用程序使用加密的 REST API 联系每个后端服务。

域名扫描

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

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

事件记录和报告

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

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

离线模式

离线模式允许用户在无法联机连接至 Keeper 或其 SSO 身份提供程序时访问其保管库。此功能在 Keeper 的移动应用和桌面应用中提供，商业用户亦可在主流的 Web 浏览器中使用此功能。

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

网络体系结构

KSI 在北美、欧洲和澳大利亚使用 Amazon AWS 进行本地化数据隐私保护和地理隔离，以托管和运营 Keeper 解决方案和体系结构。 KSI使用亚马逊AWS服务来管理Keeper解决方案及其体系架构。使用亚马逊AMS服务能满足Keeper的无缝扩展资源需求并提供给用户最高速且最安全的云储存环境。 KSI设有多时区、多地区的客服环境体系，以便在第一时间回复来自客户的问询。

服务器认证

Keeper Cloud Security Vault 通过可对来自客户端设备的每个请求进行身份验证的 API 进行保护。在客户端设备上，使用 PBKDF2-HMAC-SHA256 和随机加密盐从主密码派生出 256 位“身份验证密钥”。通过使用 SHA-256 对“身份验证密钥”进行哈希处理来生成“身份验证哈希”。登录时，身份验证哈希将与 Cloud Security Vault 中存储的身份验证哈希进行比较。登录后，将生成一个会话令牌，并供客户端设备用于后续请求。此身份验证令牌必须每 30 分钟或根据服务器的请求进行续订。

传输层加密

KSI supports 256-bit and 128-bit SSL to encrypt all data transport between the client application and KSI’s cloud-based storage. This is the same level of encryption trusted by millions of individuals and businesses everyday for web transactions requiring security, such as online banking, online shopping, trading stocks, accessing medical information and filing tax returns.

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

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

• 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

跨站脚本 (XSS) 攻击保护

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

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

在 Keeper 浏览器扩展中，Keeper 不会提示用户从页面框架区域内登录其保管库。登录至扩展发生在浏览器的浏览器扩展工具栏区域内。在 Web 浏览器上登录至保管库将始终发生在存在于内容页面之外的 KeeperSecurity.com 域名、KeeperSecurity.eu 域名或 Keeper 浏览器扩展工具栏。

Chrome、Firefox、Edge 和 Opera 上的 Keeper 浏览器扩展通过 iFrame 在网站的登录页面上注入记录数据，以确保没有恶意网站能够访问注入的内容。注入 iFrames 的记录内容也仅限于存储在用户保管库中与目标网站域名匹配的保管库记录。除非网站域名与 Keeper 保管库记录的网站域名字段匹配，否则 Keeper 不会提供自动填充登录或密码数据。

Internet Explorer 扩展使用单独的本机应用程序窗口来登录和访问记录。这些单独的窗口不受 XSS 攻击，因为无法从浏览器访问它们。这允许 Internet Explorer 的扩展在页面内提供登录窗口。除非记录与网址根域名匹配，否则扩展不会显示记录。

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

合规与审核

FedRAMP StateRAMP ITAR FIPS 140-2 SOC2 ISO 27001 GDPR Compliant FDA 21 CFR
Part 11 Compliant HIPAA Compliant FSQS-NL

SOC 2认证通过

用户数据库记录受严格严密监控的内部控制规范的保护。根据美国注册会计师协会服务组织控制架构，Keeper被认证为符合SOC 2 的2类标准。根据美国注册会计师协会Trust服务原则框架中所定义的标准控制的实施， SOC 2认证有助于确保您的数据库的安全性。

ISO 27001 认证（信息安全管理体系）

Keeper 通过了 ISO 27001 认证，涵盖了支持 Keeper Enterprise 平台的 Keeper Security 信息管理系统。Keeper 的 ISO 27001 认证范围包括数字保管库和云服务的管理和运营、软件和应用程序开发，以及数字保管库和云服务的数字资产保护。

GDPR 合规性

Keeper 致力于对我们的业务流程和产品进行更改和改进，以确保我们在 2018 年 5 月 25 日之前为 GDPR 做好准备。请点击此处以进一步了解 Keeper 的 GDPR 合规性和下载数据处理协议。

FedRAMP 已授权

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

联邦风险和授权管理计划 (FedRAMP) 是美国联邦政府的一项计划，为云产品和服务的安全评估、授权和持续监视提供标准化方法。FedRAMP 使政府机构能够使用现代云技术，重点是联邦信息的安全和保护，并帮助加速采用安全的云解决方案。

有关 FedRAMP 的更多信息，请访问 https://www.gsa.gov/technology/government-it-initiatives/fedramp。

经 StateRAMP 授权

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

StateRAMP 的管理委员会采用对提供商安全要求进行标准化的政策和程序。然后，StateRAMP 的项目管理办公室通过独立审核和持续监视来验证政府使用的云产品是否满足所采用的安全要求。StateRAMP 使政府机构能够使用现代云技术，重点是敏感信息的安全和保护，并帮助加速采用安全的云解决方案...

有关 StateRAMP 的更多信息，请访问 https://stateramp.org。

ITAR 合规性

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

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

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

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

有关 ITAR 的更多信息，请访问 https://www.pmddtc.state.gov/。

符合 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 部分的更多信息，请参阅 https://www.fda.gov/regulatory-information/search-fda-guidance-documents/part-11-electronic-records-electronic-signatures-scope-and-application

保护患者医疗数据

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

HIPAA 合规性和业务伙伴协议

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

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

渗透测试

Keeper 定期与第三方专家（包括 NCC Group, Secarma、Cybertest 和独立安全研究人员）对我们的所有产品和系统进行渗透测试。Keeper 还与 Bugcrowd 合作管理漏洞披露计划 (VDP)。

第三方安全扫描和渗透测试

Tenable 每天都会对 Keeper 的基础设施进行扫描，以确保 Keeper Web 应用和 KSI 的 Cloud Security Vault 免遭已知的远程攻击、漏洞和拒绝服务攻击。Keeper 员工会审核并纠正所有发现的问题。

支付处理以及遵守PCI标准

KSI 使用 PayPal 和 Stripe 来安全地处理通过 KSI 支付网站进行的信用卡和借记卡付款。PayPal 和 Stripe 是符合 PCI-DSS 标准的交易处理解决方案。

KSI 已通过 PCI-DSS 标准认证。

EU-US Privacy Shield

Keeper的web客户端、Android 应用程序、Windows Phone 应用程序、iPhone/iPad应用程序和浏览器扩展已由欧盟安全港认证并符合美国 商务部的欧盟-美国安全港项目，同时也符合欧盟数据保护指令。
关于欧盟和美国商务部达成的“信息安全港”协议的详细内容，请参考： https://www.privacyshield.gov

经 FIPS 140-2 验证

Keeper 使用经验证符合 FIPS 140-2 的加密模块来满足严格的政府和公共部门安全要求。Keeper 的加密已通过 NIST CMVP 认证，并由经认可的第三方实验室验证为达到 FIPS 140 标准。NIST CMVP 向 Keeper 颁发了证书（编号 3976）

FSQS-NL 认证

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

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

Keeper由美国商务部工业安全局认证，符合出口管理条例（EAR），其出口商品分类控制数为5D992。
了解更多关于美国出口管理条例 (EAR)的信息： https://www.bis.doc.gov

全天候远程监控

Keeper全天候由一个全球性第三方监控网络监控，从而确保我们的网站和Cloud Security Vault 在全球范围可使用。

如果关于此安全告知有任何疑问，请联系我们。

仿冒或伪造的电子邮件

如果您收到一封声称来自KSI的电子邮件，并且您并不确定该邮件是否属实的情况，那么它可能是一封网络钓鱼邮件，发件人的电子邮件是伪造的或欺骗邮件。在这种情况下，该电子邮件可能包含一个网站，看起来像keepersecurity.com但其实不是我们的网站链接。这个钓鱼网站可能会要求您输入您的Keeper主密码或者要求您在您的电脑上安装您实际上不需要的软件以盗取您的个人信息或访问您的电脑。 也有一些钓鱼邮件包含链接，这类链接能将您带到有潜在危险的网站。这类钓鱼邮件有时也会包含附件，这些附件通常为有害的软件，被称为”恶意软件”。如果您在您的收件箱发现可疑邮件，您应该立即删除而不是点击该邮件中包含的链接或是打开其附件。

如果您认为这封声称来自KSI的邮件为钓鱼邮件，或者您对KSI的安全事项有任何疑问，请随时联系我们。

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

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

SOC 2 PCI Compliant FIPS-140-2 ISO 27001 FedRAMP StateRAMP

漏洞报告和 Bug 赏金计划

对于负责任地披露潜在的安全问题，Keeper Security 将遵循行业最佳实践。我们非常重视您的安全和隐私，并致力于保护客户的隐私和个人数据。KSI 的使命是构建世界上最安全的创新安全应用，我们相信来自全球安全研究人员社区的 Bug 报告是确保 KSI 产品和服务安全的重要组成部分。

保持用户安全是我们作为一个组织的价值观核心。我们重视善意黑客的反馈，并相信持续保持与黑客社区的联系有助于我们确保其安全和隐私，并使互联网成为一个更安全的地方。这包括鼓励负责任的安全测试和批露安全漏洞。

指南

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

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

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

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

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

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

提交报告

Keeper 与 Bugcrowd 合作管理我们的漏洞披露计划。

请通过 [https://bugcrowd.com/keepersecurity] 提交报告。

附加信息

产品文档

Keeper 的文档门户包含产品手册、技术信息、发行说明和最终用户指南，请访问 https://docs.keeper.io

系统状态

实时系统状态请访问：https://statuspage.keeper.io