close

Keeper 致力于保护您的信息

Keeper 使用同类最佳的安全技术来保护您的信息,减少数据泄露的风险。

Keeper 提供同类软件中最佳的安全性

私人主密码

只有用户知道和可以访问他们的主密码以及用来加密和解密其信息的密钥。

深层加密

用户数据的加密和解密是在设备层次,而不是在 Keeper 的服务器或云端。

最强加密

Keeper 使用广泛被接受为最强加密的 AES 256 位加密和 PBKDF2 算法来保护您的信息。

多步验证

Keeper 支持多步验证、生物特征识别登录以及使用 Apple Watch 或 Android Wear 来确认您身份的 Keeper DNA。

安全/可靠的云保管库

Keeper 使用位于多个地理位置的 Amazon AWS 来托管和运营 Keeper 保管库和架构,为客户提供最快最安全的云存储。静止数据和传输数据完全隔离在客户首选的全球数据中心。

总览

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

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

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

数据保护

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

保存在Keeper内的信息只能由该用户本人访问,因为这些信息都是即时被加密或在用户使用该设备的Keeper应用程序被即时解密的,即使是在该用户使用Keeper的网络应用程序时。Keeper所使用的加密方法是著名的,并被广为认可的256位AES(高级加密标准)算法。256位AES加密算法是军用级别的加密技术并由美国政府认可来用于加密高度敏感信息。根据美国国家安全系统委员会出版的CNSSP-15,256位AES密钥长度能足够安全地加密美国政府的分类数据中的最高机密数据。

用于加密和解密用户记录的密钥不保存且不被传送至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 (U2F) 安全密钥

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

紧急访问(数字遗产)

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

帐户恢复

在帐户注册期间,用户将被要求选择一个安全问题和答案。此外,在注册期间,Keeper 将生成一个数据密钥,用于加密和解密与每条保管库记录一同存储的记录密钥。用户的数据密钥使用主密码进行加密,每个记录密钥都使用数据密钥进行加密。用户保管库的每条记录都有单独的不同记录密钥。

帐户恢复工作原理是存储使用所选安全问题和答案加密的用户数据密钥的第二个副本。若要完成保管库恢复,用户需要输入电子邮件验证码以及两步验证码(若已在帐户中启用)。我们建议您创建高强度的安全问题和答案,并在“设置”页面打开 Keeper 的两步验证功能。Keeper Business 客户还可以通过 Keeper 管理控制台强制执行两步验证。

数据加密技术

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

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

数据加密技术

共享

每位用户有一个2048位RSA密钥用于记录共享。已共享数据库记录是由接受者的公共密钥来加密的。接受者使用其私人密钥来解密数据。这使用户只能与预期接收者共享记录,因为只有接收者才能解密该数据。

密钥生成

Keeper使用PBKDF2 HMAC-SHA256算法,进行至少1000回合以将密码转换为 256位加密密钥。

由主密码生成的密钥并不直接用户加密该用户的数据,但是,该密钥被用于加密另一个密钥-“数据密钥”。数据密钥被用于加密数据和其他密钥,如RSA密钥。

所有未直接通过主密码来生成的密钥都是由该用户的设备上一个随机且安全的随机数字生成器所生成的。比方说,数据密钥和RSA密钥是通过一个用户的设备所生成的,因为这两个密钥是通过该用户的设备所生成的,(不是通过Keeper's Cloud Security Vault所生成的。),Keeper无法看到该用户的密钥。

密钥存储

所有必须储存的密钥(如:每个用户的RSA密码和数据密钥)都在储存或传输前被加密。解密任何密钥,需要使用该用户的主密码。由于Keeper's Cloud Security Vault 无法访问用户的主密码,我们无法解密您的任何密钥或数据。

Keeper 云安全保管库

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

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

记录版本控制

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

Keeper Business

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

Keeper Business

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

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

在加密层,存储在 Keeper 平台中的每个记录(例如密码或凭据)都有一个唯一的记录标识符(记录 UID)。每个记录均通过记录密钥进行加密。共享文件夹有共享文件夹密钥,每个团队都有团队密钥,每个用户都有用户密钥。每个需要用户帐户转移功能的角色都有一个角色强制密钥。用户设备上的静态数据通过用户密钥进行加密。用户密钥通过用户主密码进行加密。

通过共享文件夹密钥对记录密钥进行加密,可以将记录添加至共享文件夹。通过用户密钥对记录密钥进行加密,可以将记录直接共享给用户。通过用户密钥对共享文件夹密钥进行加密,可以将用户添加至共享文件夹。通过团队密钥对共享文件夹密钥进行加密,可以将团队添加至共享文件夹。通过用户密钥对团队密钥进行加密,可以将用户添加至团队。

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

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

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

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

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

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

Keeper SSO Connect

为了保持零知识安全性并确保为用户提供无缝的 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 客户并不上传域名信息,而是仅下载域名信息。

BreachWatch Process

图 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 位“客户端密钥”,迭代可高达 100,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支持256位和128位SSL以用来加密在客户端应用程序和KSI的云存储之间所传输的所有数据。与之相同的加密受到百万企业和个人用户的信赖,满足例如网上银行、网上购物、买卖股票、访问医疗信息和纳税申报等日常网络交易安全需要。

KSI部署由Digicert签署的使用SHA2算法的TLS证书,该证书是目前由商业证书颁发机构提供的最安全的数字签名算法。SHA2算法与广泛被使用的SHA1算法相比,安全性明显更高。SHA1算法中的数学弱点可能被利用。SHA2帮助防止伪造证书。伪造证书可能会被攻击者用来冒充网站发行。

KSI也支持证书透明度(CT)。CT由谷歌倡议,用于创建由证书颁发机构签署的公开审计记录。CT有助于防止未经授权的实体证书发放。目前最新版本的Chrome网络浏览器支持CT。如果了解更多关于证书透明度(CT),请访问: http://www.certificate-transparency.org/

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
  • TLS_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
  • TLS_RSA_WITH_AES_128_CBC_SHA256
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
  • TLS_RSA_WITH_AES_256_CBC_SHA256

密钥固定

Keeper 的原生客户端支持 HTTP公钥固定 (HPKP)。HPKP 是一种允许 HTTPS 网站抵制攻击者使用伪造证书进行假冒的安全机制。

跨站脚本 (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 管理员阻止用户安装未经浏览器相应应用商店批准的第三方浏览器扩展。

iOS Keychain 和 Touch ID®

iOS设备上的Touch ID功能使您能通过您的指纹在iOS设备上访问您的Keeper数据库。为了提供这个方便的功能,您的主密码的一个难解的版本被储存在iOS Keychain上面。为该功能创建的iOS Keychain项目不与iCloud Keychain同步,因此它不会离开您的iOS移动设备。

我们建议您使用一个复杂的主密码并使用多因素验证以为您的加密的Keeper数据库提供最强大的保护。在您的iOS移动设备上使用Touch ID相对使用一个复杂的主密码而言更加方便。我们还建议您使用一个超过4位数的密码来保护您的iOS Keychain。

iOS及其应用程序使用iOS Keychain来安全地储存保密信息。 iOS应用程序使用iOS Keychain来储存各类敏感信息,包括网站密码、秘钥、信用卡卡号和Apple Pay™的相关信息。Keeper不使用iOS Keychain来储存您的Keeper记录-所有Keeper记录由256位AES加密技术进行保护并安全地储存在Keeper数据库中。iOS Keychain也采用该设备的密码由256位AES加密技术进行加密。 因此,即使您的设备遇到遗失、被盗或者攻击者得到该移动设备,他们将无法访问任何所储存在Keeper内的信息。没有设备密码,黑客无法解密iOS Keychain。同样道理,没有Keeper的主密码,Keeper数据库无法被解密。

Apple Watch®

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

Keeper DNA®

Keeper DNA 是多步验证之外的一个新的创新功能。当与配对的 Apple Watch 配合使用时,Keeper DNA 可提供无比方便而安全的多步验证方法。Keeper DNA 使用存储在 Keeper 保管库中的安全令牌来生成基于时间的代码以进行多步验证。这些基于时间的身份验证请求可以通过点按 Apple Watch(或 Android Wear)的屏幕或用户手动输入,自动从该设备批准和发送。多层加密、触控 ID 和多步验证帮助 Keeper DNA 成为最优雅、最安全、最先进的可用身份验证方法。

合规与审核

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 合规性和下载数据处理协议。

保护患者医疗数据

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

渗透测试

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

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

KSI由迈克菲( McAfee Secure)每日进行安全测试,以确保Keeper网络应用程序和KSI's Cloud Security Vault 是安全的并远离已知远程攻击和安全漏洞,同时拒绝服务攻击。 您可以在Keeper网站上找到迈克菲安全徽章以确认Keeper网站、网络应用程序和Cloud Security Vault的每日测试。

此外,每个月McAfee Secure会对Keeper网站、网络应用程序和Cloud Security Vault进行一个外部的综合扫描。Keeper 员工也定期通过McAfee Secure实行按需外部扫描。

支付处理以及遵守PCI标准

为确保站内信用卡和借记卡支付安全,KSI 网站使用PayPal Payments Pro支付方式。 PayPal Payments Pro已通过支付卡行业数据安全标准(PCIDSS)认证。

EU-US Privacy Shield

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

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

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

全天候远程监控

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

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

仿冒或伪造的电子邮件

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

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

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

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

  • SOC 1 / SSAE 16 / ISAE 3402
    (SAS70)
  • SOC 2
  • SOC 3
  • PCI DSS Level 1
  • ISO 27001
  • FedRamp
  • DIACAP
  • FISMA
  • ITAC
  • FIPS 140-2
  • CSA
  • MPAA

漏洞报告和 Bug 赏金计划

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


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

指南

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

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

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

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

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

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

提交报告

Keeper 与 Bugcrowd 合作管理我们的漏洞披露计划。请通过 [https://bugcrowd.com/keepersecurity] 提交报告。