Keeper 如何保护您的数据？ 安全和透明。

Keeper Security 的零信任和零知识加密模型确保即使在最坏的情况下，您的 Keeper Vault中的所有内容也会受到多重层次的保护和加密。 Keeper 在过去的十多年中坚守承诺致力于保护您最宝贵的数据，以及贯彻我们一流的安全模型和透明的方法与公众分享数据。

Keeper 在保护客户信息方面与竞争对手相比有许多独特之处。 上一次 LastPass 的数据泄露引发了我们如何在发生数据泄露情况下保护存储的保险库里面信息的疑问。 尽管 Keeper 采取了广泛的安全防护措施来防止泄漏事件，客户也理所当然地想了解我们在发生泄漏事件时的能做的保护措施。 此页面上有一份详细描述 Keeper 加密模型的文档。 这篇博客文章将概述在数据泄露事件中可以保护用户的关键措施。

保险库数据加密

Keeper 使用一个基于客户生成加密密钥的多层加密系统。 256 位 AES 记录级密钥和文件夹级密钥在客户端设备上生成，用于加密存储的保险库记录。保险库的所有内容都经过加密，包括登录信息、文件附件、TOTP 代码、支付信息、URL 和自定义字段等。

加密密钥在设备上本地生成，保持零知识并支持记录和文件夹共享等高级功能。 零知识意味着每个用户对 Keeper Vault 中所有个人信息的加密和解密拥有完全控制权，而且甚至连 Keeper 的员工都无法访问他们存储的任何信息。

记录密钥和文件夹密钥由另一个为 256 位 AES 的数据密钥包装。

在用户设备上，另一个 256 位 AES 的客户端密钥将被生成，用于加密本地离线缓存（假设您的管理员允许离线访问）。 最终，256 位 AES 数据密钥会使用另一个密钥进行加密，这将在下一节中描述。

保护数据密钥

解密用户的保险库需要对数据密钥进行解密。

对于使用主密码登录的用户：解密和加密数据密钥的密钥是使用基于密码的密钥派生函数（PBKDF2）从用户的主密码派生而来的，默认情况下最多进行 1,000,000 次迭代。 用户输入主密码后，将本地生成密钥，然后解封数据密钥。 数据密钥解密后，将用于解开各个记录密钥和文件夹密钥。 然后记录密钥将在本地解密存储的每个记录内容。

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

关键点：

• 对于用主密码登录的客户，使用一个强大而独特的主密码至关重要，同时要执行 1,000,000 次的 PBKDF2 迭代。 通过使用 Keeper Admin Console，Keeper 管理员可以轻松地在基于角色的执行策略中对终端用户强制实施主密码复杂性规则和迭代。
• 对于通过单一登录（SSO）的=产品（如 Azure、Okta、Ping、ADFS 或其他身提供份者）部署 Keeper 的客户，无需涉及到主密码，且不存在主密码密钥派生的威胁媒介。 在这个模型中，所有数据的加密都使用椭圆曲线密钥。 使用 Keeper SSO 连接进行的数据保护已经具有充分的文档记录并已获得专利。 此功能的高级概述可在这里查看。
• 以下是一个对 Keeper 的加密模型文档中有关使用密码派生密钥与椭圆曲线（EC）密钥加密保险库强度的详细描述和数学证明。 值得注意的一点是比特币区块链使用的是 ECC-256。 这就在 256 位椭圆曲线的强度上创造了一个实质上为 3000 亿美元的猎赏。

对于想向用户部署安全的密码管理器的企业来说，Keeper SSO 连接提供了最高水平的数据保护，同时与当前的身份堆栈实现无缝集成。由于它不使用主密码，即消除了对存储数据进行暴力攻击的威胁媒介。

传输过程中的加密

Keeper 是一个使用亚马逊网络服务（AWS）在多个地理区域托管加密数据的 SaaS （服务型软件）平台。 客户可以将他们的 Keeper 租户托管于他们首选的主要区域。 客户数据（存储的密文）和对平台的访问将被隔离到客户选择的特定区域。

所有发送到 Keeper 服务器的加密负载都使用 256 位 AES 传输密钥进行包装，不仅保护了传输层的安全（TLS），还防止中间人攻击。 传输密钥是在客户端设备上生成的，并通过服务器的椭圆曲线公钥使用ECIES 加密后传输到服务器。

此传输密钥除了加密在已经打包到有效负载中的数据加密之上还提供了额外的 256 位加密层。 加密隧道直接连接用户设备与 Keeper 环境中的应用服务器。

云保护

Keeper 已经创建了一个先进的云身份验证和网络通信模型，专为最高级别的隐私、安全和信任而设计。

对于使用主密码登录的用户： ：第二个最多进行 1,000,000 次迭代的 PBKDF2 密钥将在本地生成，然后使用 HMAC_SHA256 散列生成身份验证令牌。

对于使用 SSO（单一登录）或免密码技术登录的用户： 用户可以通过其 SSO 身份提供者进行身份验证，然后在其设备上本地解密其保险库的密文。 每个设备都有自己的椭圆曲线（EC）公钥/私钥对和加密数据密钥。 要登录到新设备，用户必须使用现有的设备执行批准，或者通过拥有特权的管理员批准新设备。

在 Keeper 的云保险库（托管于 AWS 上），我们将每个用户的保险库存储为加密的密文，该密文在用户设备上进行了本地加密。 除了对有效负载和传输进行加密之外，Keeper 还使用 AWS 环境中的硬件安全模块对存储的加密数据密钥进行超级加密。

认证和合规

Keeper 是世界上最安全、经认证、经过测试和审核的密码安全平台。 Keeper 拥有业内最长的 SOC 2 和 ISO 27001 认证。 Keeper 符合 GDPR、CCPA、获得 FedRAMP 授权、获得 StateRAMP 授权，并由 TrustArc 获得在线隐私认证。 Keeper 已通过 PCI DSS认证。

关键点：

• Keeper 不会将云基础设施访问密钥等机密存储在源代码中。 我们定期扫描源代码，查找机密信息。
• Keeper 的源代码虽然保存在 Github Enterprise 中，但里面并不提供访问用户保险库所需的信息。 数据的加密发生在本地设备级别上，大部分发布在我们的公共 Github 仓库中的源代码是作为 Keeper 的 Commander 和密钥管理程序产品的一部分。
• Keeper 不会使用 Twilio 等第三方提供商提供 2FA。 Keeper 的商家不会受到任何数据泄露的影响。
• Keeper 不会向任何第三方提供对我们的 AWS 数据中心的管理或访问权限。 所有基础设施的管理都由 Keeper Security 的本地美国公民全职员工执行。
• Keeper 拥有业内最多的安全认证。 Keeper 已通过 SOC2 认证、获得了 FedRamp 授权、获得了 StateRamp 授权和已通过 ISO27001 认证。

我们对透明度的承诺

Keeper 不仅致力于安全，而且我们还很执着不已。 这也是为什么我们将我们的加密模型的每一个细节都公开给大众。 我们相信客户应该了解我们在不断变化的网络安全环境中为确保数据安全所采取的每一步。

Keeper 的零信任和零知识加密模型确保即使在最坏的情况下，您的 Keeper Vault也能得到保护，我们不断进行安全测试来确保我们始终是保护您的最珍贵数据的最强解决方案。Keeper Vault

Keeper 每季度以第三方渗透测试团队，包括 NCC Group 和 Cybertest，对我们所有的产品和系统进行应用层渗透测试。 这包括对内部和外部暴露所有源代码权限的系统进行模拟入侵者风格的渗透测试。

Keeper 与 Bugcrowd 合作管理我们的漏洞猎赏和漏洞披露计划（VDP）。 Keeper Security VDP 可以在 bugcrowd.com/keepersecurity 上找到。

为了增加透明度，Keeper 在所有平台上发布详细的更新说明。 如果您有任何疑问，请发送电子邮件至安全支持 @keepersecurity.com。