DPA 术语

定义

在本增编中，下列术语的含义如下：

1. 关联方是指直接或间接控制、由主题实体控制，或与主题实体共同控制的任何实体。 就本定义而言，“控制”是指直接或间接拥有或控制主题实体超过 50% 的表决权益。
2. 适用法律是指适用于客户数据处理的所有法律，其中可能包括欧盟数据保护法、欧洲联盟或其任何成员国的其他法律，以及客户或客户数据受其管辖的任何其他国家的法律。
3. 控制者是指单独或与他人共同确定个人数据处理的目的和方法的实体。
4. 数据主体是指其个人数据在本增编的背景下处理的自然人。
5. 欧盟数据保护法是指 GDPR 和电子隐私指令 2002/58/EC（经 2009/136/EC 指令修订，并不时进行修订和更换）及其国家实施立法（如有）。
6. GDPR 是指欧盟一般数据保护条例 2016/679；
7. 个人数据是指与已识别或可识别的自然人相关的任何信息。
8. 处理者是指代表控制人处理个人数据的实体。
9. 正在处理或处理是指对个人数据单独或成组执行的任何操作或一组操作，无论是否通过自动化手段进行，例如收集、记录、组织、构建、存储、适应或更改、检索、咨询、使用、通过传播披露、传播或以其他方式提供、调整或组合、限制、删除或销毁个人数据
10. 服务是指 Keeper 根据协议为客户提供或开展的服务和其他活动；
11. 标准合同条款是指将个人数据传输给设在第三国的处理者的标准合同条款，这些处理者无法确保欧盟委员会 2021 年 6 月 4 日发布的第 2021/914 号决定中规定的适当数据保护级别，该条款作为附件附在子附录 C 中。
12. 子处理者是指 Keeper Security 聘用的处理与服务相关的个人数据的任何处理者。

个人数据的处理

1. 增编中规定的处理目的是由 Keeper 提供协议中规定的服务。双方同意，就 Keeper 代表客户进行的数据处理而言，客户为控制者，Keeper 为处理者；但在下文第 4 段所述的有限处理情形中，Keeper 作为独立控制者。Keeper 处理的个人数据类别和类型列于子附录 A。除非适用法律另有规定，本增编项下个人数据的处理期限应与本协议有效期一致。
2. Keeper 只能根据客户的成文指示（“指示”）采取行动和处理个人数据，除非法律要求在没有此类指示的情况下采取行动。 签订本增编时的指示是，Keeper 只能以提供协议中所述的服务为目的处理个人数据。 根据本增编的条款，并经各方相互同意，客户可以发布与本增编的条款相一致的额外书面指示。 客户负责确保提供书面指示的所有个人均获得这样做的授权。
3. Keeper 将告知客户其认为违反适用法律（包括欧盟数据保护法）的任何指示，并在已确认或修改之前不会执行该指示。

机密和安全

1. Keeper 应将所有个人数据视为严格机密信息。 除非客户书面同意，否则不得复制、传输或以其他方式处理与指示相冲突的个人数据。 Keeper 的员工应承担保密义务，确保员工应严格保密地对待本增编中规定的所有个人数据。 个人数据仅提供给需要访问此类个人数据以提供服务和本增编的人员。
2. Keeper 应实施本协议和适用法律中规定的适当技术和组织措施，包括 GDPR 第 32 条。安全措施将根据技术进步和发展而定。 Keeper 可以不时更新或修改安全措施，前提是此类更新和修改不会导致整体安全性的下降。 Keeper 的信息安全政策见子附录 D 。

数据主体的权利

1. 如果客户收到数据主体根据适用法律行使数据主体权利的请求，并且对该请求的正确合法答复需要 Keeper 的协助，则 Keeper 应通过提供必要的信息和文档来协助客户。 Keeper 应获得合理的时间，以便根据适用法律协助客户处理此类请求。
2. 如果 Keeper 收到数据主体根据适用法律行使数据主体权利的请求，并且此类请求涉及客户的个人数据，除非法律禁止，否则 Keeper 将立即请求转发给客户，并且除非客户另有指示，否则不会直接回复该人。

个人数据泄露

1. 如果发生违规行为，Keeper 应立即通知客户，这可能导致意外或非法销毁、丢失、更改、未经授权披露或访问代表客户传输、存储或以其他方式处理的个人数据（“个人数据泄露”）。
2. Keeper 应做出合理的努力，确定此类违规的原因，并采取其认为必要的步骤来确定原因，并防止此类违约事件再次发生。

合规和审计权利文档

1. 根据客户的请求，出于某种原因或在 GDPR 第 28 条规定的范围内，Keeper 应向客户提供证明其遵守本增编所必需的所有相关信息，并应允许并合理配合审计，包括客户或客户授权的审计师的检查。 客户应发出将进行的任何审计或文件检查的通知，并应做出合理的努力，以避免在此类审核或检查过程中对 Keeper 的场所、设备和业务造成损害或中断。 任何审计或文件检查应在不少于六十 (60) 个日历日的合理的事先书面通知的情况下进行，并且每年不得超过一次。
2. 在提供上述内容之前，可能会要求客户签署一份 Keeper 可以合理接受的保密协议。

数据传输

1. 双方将源自欧洲经济区（“EEA”）的个人数据传输给位于尚未收到欧盟委员会具有约束力的充分性决定的 EEA 以外国家的缔约方，此类传输应遵守适用的数据传输法律要求，并且仅根据客户的成文指示进行。
2. 如果客户认为这些措施不足以满足任何特定情况下的法律要求，则客户应向 Keeper 提供此类意见的理由的书面通知，且双方应真诚地共同努力，寻找双方同意的替代方案。

子处理者

1. Keeper 获得一般授权，可以聘请第三方处理个人数据（“子处理者”），而无需获得客户的任何进一步的书面特定授权。 Keeper 应与任何子处理者签订书面子处理者协议。 此类协议至少应提供与适用于 Keeper 的数据保护义务相同的数据保护义务，包括本增编中规定的义务。 Keeper 应持续监控和控制其子处理者遵守适用的数据保护法的情况，如果提出书面要求，应向客户提供此类监控和控制的文档。
2. 如果子处理者在欧盟/欧洲经济区以外执行约定服务，则 Keeper 应采取适当措施，确保其根据数据保护法的可接受性。
3. 在签订本协议时，Keeper 正在使用子附录 B 中列出的子处理者。Keeper 应通知客户任何新的子处理者，此类通知可以在授权此类子处理者前至少十（10）个工作日，通过 https://www.keepersecurity.com/GDPR.html或通过电子邮件（如果客户请求在执行本增编后的十 (10) 天内向 gdpr@keepersecurity.com 发送电子邮件来请求接收通知
4. 客户可以在收到客户关于潜在新子处理者的通知后的十 (10) 个工作日内通过电子邮件gdpr@keepersecurity.com 向处理者发出书面通知，真诚地反对 Keeper 使用新的子处理者。 此类书面通知至少应包括客户的诚意，以及提出异议的合理理由。 Keeper 应尽商业上合理的努力，为客户提供服务的变更，或建议客户对服务的使用进行商业合理的更改，以避免被质疑的子处理者处理个人数据。 如果客户在十 (10)个工作日内未提出任何异议，则应视为同意相关子处理者。
5. 如果客户向新的子处理者提出异议，并且 Keeper 无法满足客户的异议，则客户可以通过书面通知 要求 Keeper 终止服务，但仅限于在不使用受到质疑的新子处理者的情况下 Keeper 无法提供的服务。
6. Keeper 对任何子处理者的客户负责，如同对自己的行为和疏忽负责一样。

终止；返回或删除个人数据

1. 在协议到期或终止后，Keeper 将根据协议的规定删除或返回其拥有的所有个人数据，除非适用法律要求 Keeper 保留部分或全部个人数据（在这种情况下，Keeper 将存档数据并采取合理的措施，防止对个人数据进行进一步处理）。 本增编的条款将继续适用于此类个人数据。

数据保护影响评估和事先协商

1. 如果 Keeper 的协助是必要且相关的，双方将在根据 GDPR 第 35 条准备数据保护影响评估的合理必要的范围内进行合作，并根据 GDPR 第 36 条进行事先协商。双方在履行此类义务时将各自承担各自的费用。

其他

1. 修改增编：本增编只能通过由各缔约方签名的书面修正案进行修改。

2. 管辖法律：本增编受管辖协议的法律管辖，并应根据该法律进行解释。
3. 无效和可分割性；冲突：如果具有管辖权的法院或行政机构发现本增编的任何规定无效或不可执行，则此类条款的无效或不可执行不影响本增编的任何其他规定，不受此类无效或不可执行影响的所有规定仍将保持完全有效。 如果本增编与双方签订的标准合同条款（如有）之间存在任何不一致，则以标准合同条款为准。

子附录 A

个人数据

1. Keeper 在提供服务时处理以下类型的个人数据：
2. 传输的个人数据涉及联系人信息（姓名、地址、电子邮件、电话）、实体数据、IP 地址、设备标识符和应用程序版本信息。

数据主体的类别

1. Keeper 代表客户处理以下类别数据主体的个人数据：
   1. 客户
   2. 客户的授权最终用户，包括客户的员工。

子附录 B – 已批准子处理者

1. Keeper 的子处理器最新列表可在 https://www.keepersecurity.com/legal/sub-processors/ 获取。该列表包含各子处理者的法人实体名称及其所在地信息。子处理者名单会不定期更新，客户可在 Keeper 信任中心注册，以接收相关更新通知。

子附录 C

（欧盟标准合同条款）

标准合同条款（处理者）

识别组织所需的其他信息：不适用

（数据导入者）

每个为“一方”；共同为“各方”，

已同意以下合同条款（“条款”），以便在保护个人的隐私和基本权利和自由方面提供充分的保障，以便数据导出者将子附录 A 中规定的个人数据传输给数据的数据导入者。

使合同具有约束力（如有）的其他必要信息：

第 1 条

目的和范围

1. 这些标准合同条款的目的是确保遵守欧洲议会和理事会 2016 年 4 月 27 日关于在处理个人数据方面保护自然人的法规 (EU) 2016/679，以及关于将个人数据传输到第三国的此类数据自由移动（通用数据保护条例） (1) 的要求。
2. 缔约方：
   1. 正在传输如附件 I 中（以下称为每个“数据导出者”）列出的个人数据的自然人或法人、公共当局、机构或其他实体（以下称为“实体”），以及
   2. 通过也是这些条款缔约方的另一实体直接或间接从数据导出者那里接收个人数据的第三国的实体（如附件 I 所列）（以下称为每个“数据导入者”）；

已同意这些标准合同条款（以下简称“条款”）。

3. 这些条款适用于附件 I 中规定的个人数据的传输
4. 包含其中提及的附件的这些条款的附录是这些条款的组成部分。

第 2 条

条款的效力和不变性

1. 这些条款根据法规 (EU) 2016/679 的第 46(1) 条和第 46(2)(c) 条，规定了适当的保障措施，包括可强制执行的数据主体权利和有效的法律救济，以及关于从控制者到处理者和/或处理者到处理者的数据传输， 符合法规 (EU) 2016/679 第 28(7) 条的标准合同条款，前提是它们未进行修改，除非选择适当的模块或在附录中添加或更新信息。 这并不阻止双方将这些条款中规定的标准合同条款纳入更广泛的合同中，并/或添加其他条款或额外保障措施，前提是它们不直接或间接地抵触这些条款，也不影响数据主体的基本权利或自由。
2. 这些条款不影响数据导出者根据法规 (EU) 2016/679 承担的义务。

第 3 条

第三方受益人

1. 数据主体可以作为第三方受益人对数据导出者和/或数据导入者调用和执行这些条款，但以下情况例外：
   • 第 1 条、第 2 条、第 3 条、第 6 条、第 7 条；
   • 第 8 条–模块 1：第 8.5(e) 条和第 8.9(b) 条；模块 2：第 8.1(b)、 8.9(a)、(c)、(d) 和(e) 条；模块 3：第 8.1(a)、(c) 和 (d) 条以及第 8.9(a)、(c)、(d)、(f) 和 (g) 条；模块 4：第 8.1(b) 条和第 8.3(b) 条；
   • 第 9 条–模块 2：第 9(a)、(c)、(d) 和 (e) 条；
   • 第 12 条 - 模块 2：第 12(a)、(d) 和 (f) 条
   • 第 15.1(c)、(d) 和 (e) 条；
   • 第 16(e) 条；
   • 第 18 条–第 18 (a) 和 (b) 条。
2. 第 (a) 段不影响法规 (EU) 2016/679 规定的数据主体权利

第 4 条

解释

1. 如果这些条款使用的是法规 (EU) 2016/679 中定义的术语，则这些术语的含义应与该法规中的含义相同。
2. 这些条款应根据法规 (EU) 2016/679 的规定进行阅读和解释。
3. 这些条款的解释不得与法规 (EU) 2016/679 中规定的权利和义务相冲突。

第 5 条

层次

如果这些条款与双方在商定此条款时或此后签订这些条款时存在的相关协议的规定存在冲突，则以这些条款为准。

第 6 条

传输说明

传输的详细信息，特别是传输的个人数据的类别和传输目的，详见附件 I 。

第 7 条（可选）

对接条款

1. 非这些条款缔约方的实体，可以作为数据导出者或数据导入者随时加入这些条款，方法是填写附录并签署附件 I。
2. 一旦完成附录并签署了附件 I，加入实体即应成为这些条款的缔约方，并根据附件 I 中的指定拥有数据导出者或数据导入者的权利和义务。
3. 加入实体在成为缔约方之前的时期内不具有这些条款规定的权利或义务。

第 II 节 – 各方的义务

第 8 条

数据保护措施

数据导出者保证已做出合理的努力，确定数据导入者能够通过实施适当的技术和组织措施，履行这些条款规定的义务。

模块 2：从控制者传输给处理者

8.1 说明

1. 数据导入者应仅根据数据导出者的成文指示处理个人数据。 数据导出者可以在整个合同期内提供此类指示。
2. 数据导入者如果无法遵循这些说明，应立即通知数据导出者

8.2 目的限制

数据导入者应仅为传输的特定目的处理个人数据，如附件 I 中所述，除非数据导出者另有指示。

8.3 透明度

根据请求，数据导出者应向数据主体免费提供这些条款的副本，包括缔约方填写的附录。 在保护商业机密或其他机密信息的必要范围内，包括附件 II 和个人数据中描述的措施，数据导出者可以在共享副本之前编辑这些条款附录的部分文本，但在数据主体无法理解其内容或行使他/她的权利的情况下，应提供有意义的摘要。 根据请求，双方应尽可能在不透露已编辑信息的情况下向数据主体提供编辑的原因。 本条款不影响数据导出者根据法规 (EU) 2016/679 第 13 条和第 14 条承担的义务。

8.4 准确度

如果数据导入者发现其收到的个人数据不准确或已过时，应立即通知数据导出者。 在这种情况下，数据导入者应与数据导出者合作，删除或更正数据。

8.5 处理和删除或返回数据的持续时间

数据导入者的处理仅在附件 I 规定的时间内进行。提供处理服务结束后，数据导入者应根据数据导出者的选择，删除代表数据导出者处理的所有个人数据，并向数据导出者证明已这样做，或者将代表其处理的所有个人数据返回给数据导出者，并删除现有副本。 在数据被删除或返回之前，数据导入者应继续确保遵守这些条款。 如果适用于数据导入者的当地法律禁止返回或删除个人数据，则数据导入者保证将继续确保遵守这些条款，并仅在该当地法律要求的范围和时间内处理。 这不影响第 14 条，特别是第 14(e) 条对数据导入者提出的要求，如果数据导入者有理由相信其正在或已经受到不符合第 14(a) 条要求的法律或做法的约束，则在整个合同期内应通知数据导出者。

8.6 处理安全

1. 数据导入者和数据导出者（在整个传输过程中）应实施适当的技术和组织措施，以确保数据的安全，包括防止导致意外或非法销毁、丢失、更改、未经授权披露或访问该数据的安全漏洞（以下称为“个人数据泄露”）。 在评估适当的安全级别时，双方应适当考虑最新技术、实施成本、处理的性质、范围、背景和目的，以及数据主体处理所涉及的风险。 如果可以以这种方式实现处理目的，双方尤其应考虑采用加密或假名化，包括在传输期间。 在假名化的情况下，将个人数据归属给特定数据主体的额外信息应尽可能由数据导出者独家控制。 在遵守本段规定的义务时，数据导入者至少应实施附件 II 中规定的技术和组织措施。 数据导入者应进行定期检查，以确保这些措施继续提供适当的安全级别。
2. 数据导入者应仅在实施、管理和监控合同所严格要求的范围内，向其员工授予对个人数据的访问权限。 它应确保被授权处理个人数据的人员已承诺保密，或承担适当的法定保密义务。
3. 如果发生涉及数据导入者根据这些条款处理的个人数据的个人数据泄露，则数据导入者应采取适当的措施解决违规，包括采取措施减轻其不利影响。数据导入者还应在得知违规后，立即通知数据导出者。 此类通知应包含可以获得更多信息的联系人的详细信息、违规性质的描述（包括相关的数据主体和个人数据记录的类别和大约数量）、可能的后果以及为解决违规行为而采取或提议采取的措施，包括酌情采取可减轻其可能的不利影响的措施。 如果无法同时提供所有信息，则初始通知应包含当时可用的信息，并且进一步信息一旦可用，随后应立即提供，不得无故拖延。
4. 数据导入者应与数据导出者合作并给予协助，以使数据导出者能够遵守法规 (EU) 2016/679 规定的义务，特别是通知合格监管机构和受影响的数据主体，同时考虑到处理的性质和数据导入者可用的信息。

8.7 敏感数据

如果传输涉及揭示种族或族裔出身、政治观点、宗教或哲学信仰的个人数据，或工会成员身份、遗传数据或用于唯一识别自然人的生物识别数据， 有关健康或个人性生活或性取向的数据，或与刑事定罪和违法有关的数据（以下称为“敏感数据”），则数据导入者应采用附件 I 中描述的特定限制和/或额外保障措施。

8.8 继续传输

数据导入者仅应根据数据导出者的成文指示向第三方披露个人数据。 此外，数据仅可以披露给位于欧盟以外的第三方（与数据导入者相同的国家或另一个第三国，以下称为“继续传输”），前提是该第三方正在或同意根据相应模块受这些条款的约束，或如果：

1. 继续传输是传输给受益于根据法规 (EU) 2016/679 第 45 条作出的涵盖继续传输的充分性决定的国家；

2. 第三方根据第 46 条或第 47 条确保适当的保障措施

   关于所述处理的 (EU) 2016/679 法规；

3. 在特定的行政、监管或司法程序的背景下，继续传输对于确立、行使或辩护法律主张是必要的；或者
4. 为了保护数据主体或其他自然人的切身利益，继续传输是必要的。

任何进一步传输均以数据导入者遵守这些条款中的所有其他保障措施为前提，特别是目的限制。

8.9 文档和合规

1. 数据导入者应迅速充分地处理数据导出者提出的与这些条款中规定的处理相关的询问。
2. 双方应能够证明其遵守这些条款。 特别是，数据导入者应保留代表数据导出者进行的处理活动的适当文档。
3. 数据导入者应向数据导出者提供所有必要的信息，以证明其遵守这些条款中规定的义务，并应数据导出者的请求，以合理的间隔或如果有不合规迹象，允许并有助于对这些条款涵盖的处理活动进行审计。 在决定审核或审计时，数据导出者可以考虑数据导入者持有的相关认证。
4. 数据导出者可以选择自己进行审核，也可以委托独立审计师进行审核。 审计可能包括在数据导入者的场所或物理设施进行检查，并在适当情况下应以合理通知的方式进行。
5. 双方应根据请求向合格监管机构提供第 (b) 段和第 (c) 段提及的信息，包括任何审计的结果。

第 9 条

模块 2：从控制者传输给处理者

1. 特定的事先授权 未经数据导出者事先的特定书面授权，数据导入者不得将其根据这些条款代表数据导出者执行的任何处理活动分包给子处理者。 数据导入者应在子处理者参与前至少 4 周提交特定授权请求，并提供使数据导出者能够决定授权所需的必要信息。 数据导出者已经授权的子处理者名单见子附录 B 。双方应及时更新子附录。
2. 如果数据导入者聘请子处理者（代表数据导出者）执行特定处理活动，则应通过书面合同执行，该合同实质上规定了与这些条款对数据导入者具有约束力的义务相同的义务，包括数据主体的第三方受益人权利。 双方同意，通过遵守本条款，数据导入者即履行其第 8.8 条规定的义务。 数据导入者应确保子处理者遵守数据导入者根据这些条款承担的义务。
3. 数据导入者应根据数据导出者的请求向数据导出者提供此类子处理者协议的副本，以及任何后续修订。 在保护商业机密或其他机密信息（包括个人数据）的必要范围内，数据导入者可以在共享副本之前修改协议的文本。
4. 数据导入者应继续对数据导出者全面负责，以履行子处理者与其数据导入者的合同中规定的义务。 在子处理者未能履行其合同规定的义务的情况下，数据导入者应通知数据导出者。
5. 数据导入者应与子处理者约定第三方受益人条款，即 – 如果数据导入者事实上失踪、在法律上已不存在或破产 – 数据导出者应有权终止子处理者合同，并指示子处理者删除或返回个人数据

第 10 条

数据主体权利

模块 2：从控制者传输给处理者

1. 数据导入者应将其从数据主体收到的任何请求迅速通知数据导出者。 除非已获得数据导出者授权，否则不得自行响应该请求。
2. 数据导入者应协助数据导出者履行其义务，响应数据主体根据法规 (EU) 2016/679 行使权利的请求。 在这方面，缔约方应在附件二中列出适当的技术和组织措施，同时考虑到提供援助的处理性质，以及所需援助的范围和程度。
3. 在履行第 (a) 段和第 (b) 段中规定的义务时，数据导入者应遵守数据导出者的指示。

第 11 条

纠正

1. 数据导入者应通过个人通知或在其网站上，以透明且易于访问的格式通知数据主体授权处理投诉的联系人。 它应迅速处理其从数据主体收到的任何投诉。

模块 2：从控制者传输给处理者

2. 如果数据主体与缔约方之一之间就遵守这些条款存在争议，则该缔约方应尽最大努力及时友好地解决问题。 双方应相互告知此类争议，并在适当情况下合作解决此类争议。
3. 如果数据主体根据第 3 条调用第三方受益人权利，则数据导入者应接受数据主体的决定，条件是：
   1. 向其惯常居住地或工作地点的成员国的监管机构，或第 13 条规定的合格监管机构提出投诉；
   2. 是指在第 18 条含义范围内将争议提交有管辖权的法院。
4. 双方接受，数据主体可以根据法规 (EU) 2016/679 第 80(1) 条规定的条件由非营利机构、组织或协会代表。
5. 数据导入者应遵守根据适用的欧盟或成员国法律具有约束力的决定。
6. 数据导入者同意，数据主体所做的选择不会影响其根据适用法律寻求补救的实质性和程序性权利。

第 12 条

责任

模块 2：从控制者传输给处理者

1. 每一方应就其违反这些条款而给另一方造成的任何损害，向另一方承担责任。
2. 因为数据导入者或其子处理者违反这些条款规定的第三方受益人权利而导致数据主体的任何材料或非材料损害，所以数据导入者应对数据主体负责，并且数据主体有权获得赔偿。
3. 尽管有第 (b) 段的规定，但因为数据导出者或数据导入者（或其子处理者）违反这些条款规定的第三方受益人权利而导致的任何材料或非材料损害，所以数据导出者应对数据主体负责，并且数据主体有权获得赔偿。 这不影响数据导出者的责任，如果数据导出者是代表控制者行事的处理者，则不影响控制者根据法规 (EU) 2016/679 或法规 (EU) 2018/1725 （如适用）承担的责任。
4. 双方同意，如果数据导出者根据第 (c) 段对数据导入者（或其子处理者）造成的损害负责，则它有权向数据导入者索回与数据导入者对损害承担的责任相对应的部分赔偿。
5. 如果超过一方对违反这些条款而给数据主体造成的任何损害负责，则所有责任方应共同承担责任，并且数据主体有权在法院对其中任何一方提起诉讼。
6. 双方同意，如果一方根据第 (e) 段承担责任，则它有权向另一方索回与其对损害的责任相符的部分赔偿。
7. 数据导入者不得调用子处理者的行为以避免自己的责任。

第 13 条

监督

模块 2：从控制者传输给处理者

1. 如附件 I 所示，负责确保数据导出者遵守法规 (EU) 2016/679 的监管机构应担任合格监管机构。
2. 数据导入者同意在任何旨在确保遵守这些条款的程序中接受合格监管机构的管辖并与其合作。 特别是，数据导入者同意回复查询、提交审计并遵守监管机构采取的措施，包括补救和补偿措施。 它应该向监管机构提供书面确认，确认已采取了必要行动。

第 III 节 – 公共当局访问情况下的当地法律和义务

第 14 条

影响遵守条款的地方法律和做法

模块 2：从控制者传输给处理者

1. 双方保证，他们没有理由相信适用于数据导入者处理个人数据的第三目的地国家/地区的法律和做法，包括任何披露个人数据的要求或授权公共当局访问的措施，会阻止数据导入者履行这些条款规定的义务。 这是基于这样的理解，即尊重基本权利和自由本质，且不超出民主社会为保障法规 (EU) 2016/679 第 23(1) 条所列目标之一的必需和相称的法律和做法，与这些条款不冲突。
2. 双方声明，在提供第 (a) 段中的保证时，他们已特别考虑了以下因素：
   1. 传输的特定情况，包括处理链的长度、涉及的行为者数量和使用的传输渠道；预期继续传输；接收者类型；处理目的；传输个人数据的类别和格式； 传输发生的经济部门；传输数据的存储位置；
   2. 第三目的地国家/地区的法律和做法—包括要求向公共当局披露数据或授权此类当局访问权限的法律和做法—与传输的特定情况以及适用的限制和保障措施相关；
   3. 为补充这些条款规定的保障措施而制定的任何相关合同、技术或组织保障措施，包括在传输期间以及在目的地国家/地区处理个人数据时采取的措施。
3. 数据导入者保证，在根据第 (b) 段进行评估时，已尽最大努力为数据导出者提供相关信息，并同意将继续与数据导出者合作，以确保遵守这些条款。
4. 双方同意根据第 (b) 段记录评估，并根据请求将其提供给合格监管机构。
5. 如果数据导入者同意这些条款后并在合同期间有理由相信其正在或已经受到不符合第 (a) 段要求的法律或做法的约束，包括更改第三国的法律或采取表明在实践中适用不符合第 (a) 段要求的措施（例如披露请求），则应同意立即通知数据导出者。
6. 根据第 (e) 段发出通知后，或者如果数据导出者有理由相信数据导入者无法再履行这些条款规定的义务，则数据导出者应立即确定数据导出者和/或数据导入者为解决这种情况而采取的适当措施（例如，确保安全和机密性的技术或组织措施）。 数据导出者如果认为无法确保此类传输的适当保障措施，或者如果合格监管机构指示这样做，则应暂停数据传输。 在这种情况下，数据导出者有权终止合同，只要它涉及根据这些条款处理个人数据。 如果合同涉及两个以上缔约方，则数据导出者可以仅对相关缔约方行使此终止权利，除非双方另有约定。 如果合同根据本条款终止，则应适用第 16(d) 和 (e) 条。

第 15 条

数据导入者在公共当局访问时的义务

模块 2：从控制者传输给处理者

15.1. 通知

1. 数据导入者同意通知数据导出者，并在可能的情况下立即通知数据主体（必要时在数据导出者的帮助下）：
   1. 根据目的地国家/地区法律收到公共当局（包括司法当局）的具有法律约束力的请求，以披露根据这些条款传输的个人数据；此类通知应包括有关请求的个人数据、请求当局、请求的法律依据和提供的响应的信息；或
   2. 了解公共当局根据目的地国家/地区的法律对根据这些条款传输的个人数据的任何直接访问；此类通知应包括导入者可用的所有信息。
2. 如果根据目的地国家/地区的法律，禁止数据导入者通知数据导出者和/或数据主体，则数据导入者同意尽最大努力获得禁令的豁免，以期尽快传达尽可能多的信息。 数据导入者同意记录其所做的最大努力，以便能够根据数据导出者的请求进行演示。
3. 在目的地国家/地区法律允许的情况下，数据导入者同意在合同期间定期向数据导出者提供尽可能多的关于收到的请求的相关信息（特别是请求数量、请求数据类型、请求权限、请求是否受到质疑以及此类质疑的结果等）。
4. 数据导入者同意在合同期间根据第 (a) 至 (c) 段保留信息，并根据请求将其提供给合格监管机构。
5. 第 (a) 至 (c) 段不影响数据导入者根据第 14(e) 条和第 16 条承担的义务，即在无法遵守这些条款时立即通知数据导出者的义务。

15.2. 合法性和数据最小化审查

1. 数据导入者同意审查披露请求的合法性，特别是它是否仍属于授予请求公共当局的权力范围内，并且如果经过仔细评估后得出结论，有合理的理由认为该请求根据目的地国家/地区的法律、国际法规定的适用义务和国际礼让原则是非法的，则会对该请求提出质疑。 数据导入者应在相同条件下寻求上诉的可能性。 当对请求提出质疑时，数据导入者应寻求临时措施，以暂停请求的影响，直到合格司法机构就其案情作出决定。 在根据适用的程序规则要求这样做之前，它不会披露请求的个人数据。 这些要求不影响数据导入者根据第 14(e) 条承担的义务。
2. 数据导入者同意记录其法律评估和对披露请求的任何质疑，并在目的地国家/地区法律允许的范围内，将文档提供给数据导出者。 它还应根据请求将其提供给合格监管机构。
3. 数据导入者同意，在响应披露请求时，根据对该请求的合理解释，提供允许的最少数量的信息。

第 IV 节 – 最终规定

第 16 条

不遵守条款和终止

1. 数据导入者如果出于任何原因无法遵守这些条款，则应立即通知数据导出者。
2. 如果数据导入者违反这些条款或无法遵守这些条款，则数据导出者应暂停将个人数据传输给数据导入者，直到再次确保合规或合同终止。 这不影响第 14(f) 条。
3. 在以下情况下，数据导出者有权终止合同，只要它涉及根据这些条款处理个人数据。
   1. 数据导出者已根据 (b) 段暂停将个人数据传输给数据导入者，并且在一段合理时间内和在任何情况下在暂停后的一个月内未能恢复对这些条款的遵守；
   2. 数据导入者严重或持续违反这些条款；或
   3. 数据导入者未能遵守合格法院或监管机构就其根据这些条款承担的义务作出的具有约束力的决定。

   在这些情况下，它应将此类不合规情况通知合格监管机构[对于模块 3：和控制者]。 如果合同涉及两个以上缔约方，则数据导出者可以仅对相关缔约方行使此终止权利，除非双方另有约定。

4. 在合同终止之前根据 (c) 段传输的个人数据应根据数据导出者的选择立即返回给数据导出者，或将其全部删除。 同样也适用于数据的任何副本。 数据导入者应向数据导出者证明数据已删除。 在数据被删除或返回之前，数据导入者应继续确保遵守这些条款。 如果适用于数据导入者的当地法律禁止返回或删除个人数据，则数据导入者保证将继续确保遵守这些条款，并仅在该当地法律要求的范围和时间内处理数据。
5. 在以下情况下，任一缔约方均可撤销其受这些条款约束的协议， (i) 欧盟委员会根据法规 (EU) 2016/679 第 45(3) 条作出涵盖这些条款适用的个人数据的传输的决定； 或 (ii) 法规 (EU)2016/679 成为将个人数据传输到国家/地区法律框架的一部分。 这不影响法规 (EU)2016/679 规定的适用于所述处理的其他义务。

第 17 条

管辖法律

这些条款应受数据导出者所在的欧盟成员国法律管辖。 如果此类法律不允许第三方受益人权利，则应受另一个允许第三方受益人权利的欧盟成员国的法律管辖。 双方同意，这将成为爱尔兰法律。

第 18 条

模块 2：从控制者传输给处理者

1. 因这些条款而产生的任何争议应由欧盟成员国法院解决。
2. 双方同意这些法院应为爱尔兰（请注明成员国）法院。
3. 数据主体还可以在他/她惯常居住地的成员国法院对数据导出者和/或数据导入者提起法律诉讼。
4. 双方同意接受此类法院的管辖。

标准合同条款附件 I

标准合同条款附件 II

本附录是条款的一部分，必须由各方填写并签署。

子附录 D

Keeper Security, Inc.

安全告知

Keeper Security, Inc. (KSI) 热衷于通过 Keeper 移动和桌面安全软件保护客户的信息。 数以百万计的消费者和企业信任 Keeper 来保护和访问他们的密码和私人信息。

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

数据保护

零信任始于密码安全。 KSI 使用基于不信任体系结构内的任何用户的零信任安全框架创建其产品。 零信任假设所有用户和设备都可能受到威胁，因此，每个用户必须经过验证和身份验证，然后才能访问网站、应用程序或系统。 此网络安全框架是 Keeper 网络安全平台的基础。 该平台让 IT 管理员可以全面了解他们正在访问的所有用户、系统和设备，这有助于确保遵守行业和监管要求。 要在组织中拥有零信任框架，必须具有由零知识安全体系结构支持的世界级密码安全。

KSI 是一家零知识安全提供商。 Keeper 用户是对其数据加密和解密有完全控制权的唯一人员。使用 Keeper，加密和解密仅在登录保管库时在用户的设备上发生。 存储在用户保管库中的每条记录都使用在用户设备上生成的随机 256 位 AES 密钥进行加密。 记录密钥受另一个密钥（称为数据密钥）保护。 数据密钥通过从用户的主密码中派生的设备密钥进行加密。 存储在用户设备上的静态数据也通过另一个密钥（称为客户端密钥）进行加密。 用户设备之间的安全记录同步也在网络层进行加密，并通过 Keeper 的 Cloud Security Vault 进行路由。 此多层加密模型提供了业界最先进的数据保护。

解密数据所需的加密密钥始终驻留在 Keeper 用户端。KSI 无法解密用户存储的数据。 KSI 无法访问客户的主密码，也无法访问存储在 Keeper 保管库中的记录。 KSI 无法远程访问客户的设备，也无法解密客户的保管库。 Keeper Security 可以访问的唯一信息是用户的电子邮件地址、设备类型和订阅计划详细信息（例如 Keeper Unlimited）。 如果用户的设备丢失或被盗，则 KSI 可以协助访问加密的备份文件，以便在设备被更换后还原用户的保管库。

Keeper 中存储和访问的信息仅可供客户访问，因为这些信息将在正在使用的设备上即时加密和解密 - 即使使用 Keeper Web App 也是如此。 Keeper 使用的加密方法是一种可信赖的著名算法，称为 AES （高级加密标准），采用 256 位的密钥长度。根据美国国家安全系统委员会出版的 CNSSP-15，采用 256 位密钥长度的 AES 对于加密美国政府高至“最高机密”的机密数据足够安全。Keeper 经 NIST CMVP 认证和验证，达到 FIPS 140-3 标准（证书编号 3976 - https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/3976）

用于加密和解密客户记录的密码密钥并不存储或传输至 Keeper 的 Cloud Security Vault。然而，为了提供多设备间的同步功能，此密钥的加密版本将存储在 Cloud Security Vault 中，并在成功登录保管库和多因素身份验证后提供给用户帐户中的设备。 该加密密码密钥仅可在设备上进行解密来作为后续数据密码密钥使用。

高强度主密码

强烈建议客户为其 Keeper 帐户选择高强度的主密码。此主密码不应在 Keeper 以外的任何地方使用。 用户永远不应该与任何人共享其主密码。

两步验证

为了防止未经授权访问您的保管库、网站和应用程序，Keeper 还提供两步验证。 两步验证是一种身份验证方法，要求提供三种身份验证因素中的两种或多种：知识因素、拥有因素和固有因素。

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

使用 TOTP MFA/2FA 方法时，Keeper 使用加密安全的随机数生成器生成 10 字节的密钥。 此代码有效期约一分钟，通过 SMS、Duo Security、RSA SecurID、TOTP 应用程序、Google 身份验证器或与 Keeper DNA 兼容的可穿戴设备（如 Apple Watch 或 Android Wear）发送给用户。

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

要激活两步验证，请访问 Keeper 应用程序的设置或安全屏幕。 Keeper Business 客户可以通过 Keeper Admin Console 的角色强制设置功能选择强制使用两步验证登录保管库和支持的两步验证方法。

FIDO2 安全密钥

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

紧急访问（数字遗产）

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

账号恢复

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

帐户恢复的工作方式（使用安全问题方法）是通过存储使用所选安全答案加密的用户数据密钥的第二份副本。 若要完成保管库恢复，用户需要输入电子邮件验证码以及两步验证码（若已在帐户中启用）。我们建议您创建高强度的安全问题和答案，并在“设置”页面打开 Keeper 的两步验证功能。根据 Keeper Business 帐户的配置，用户可以获得不同的恢复方法，例如恢复密钥或多个分离密钥。 此外，客户可以禁用帐户恢复。Keeper Business 客户也可以通过 Keeper 管理控制台执行两步验证。

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

客户端加密

用户数据是在其设备上而不是在Cloud Security Vault上进行加密或解密的。我们将此称为“加密用户端”，因为用户端（如： iPhone、 Android 设备、Desktop App 等）在执行数据的本地加密和解密。Cloud Security Vault 储存 256 位加密密文，这类加密密文对侵入者来说基本上是没用的。即使数据在用户端设备和Cloud Security Vault之间进行传输的时候被窃取，该文件无法被解密，也无法用来攻击或损害用户的私人数据。

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

共享

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

密钥生成

Keeper 使用高达 1,000,000 次迭代的 PBKDF2 和 HMAC-SHA256 来将用户的主密码转换为 256 位的加密密钥。PBKDF2 迭代基于设备平台，并由用户在 Keeper 的“高级设置”页面中进行管理。

密钥存储

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

Keeper 云安全保管库

Cloud Security Vault 是指KSI'专有的软件和网络架构，托管在亚马逊网络服务（AWS）基础设施上。当用户将其 Keeper 记录与其帐户中的其他设备同步时，加密的二进制数据将通过加密的 TLS 隧道发送，并以加密格式存储在 Keeper 的 Cloud Security Vault 中。

记录版本控制

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

Keeper Business

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

记录级加密

在加密层，存储在 Keeper 平台中的每条记录（例如密码或凭据）都有一个唯一的记录标识符（记录 UID）。每条记录都使用记录密钥进行加密。 共享文件夹具有共享文件夹密钥，每个团队都有团队密钥和公钥/私钥对，并且每个用户都有用户数据密钥、客户端密钥和公钥/私钥对。 每个需要用户帐户可转移的角色都具有角色执行密钥和公钥/私钥对。 用户设备上的静态数据使用用户的客户端密钥进行加密。 用户的数据密钥和客户端密钥使用用户的主密码进行加密。

用户创建的记录使用用户的数据密钥进行加密。 通过使用共享文件夹密钥对记录密钥进行加密，将记录添加到共享文件夹。 通过使用用户的公钥对记录密钥进行加密，将记录直接共享给用户。 通过使用用户的公钥对共享文件夹密钥进行加密，将用户添加到共享文件夹。 通过使用团队的公钥对共享文件夹密钥进行加密，将团队添加到共享文件夹中。 通过使用用户的公钥对团队密钥进行加密，将用户添加到团队。

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

Keeper for Business 提供了一套安全而强大的控制措施，可控制组织单位、角色、团队和共享文件夹。 Keeper 的强大后端控制提供了最强健的安全层，可提供最低特权访问和全面委托管理。

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

通过允许执行转移操作的各管理员密钥对强制密钥进行加密。应用于单独用户组的单独强制措施可指定为由单独的管理员组转移。

用户的数据密钥（对于应用于实施的角色中的用户）使用角色实施的公钥进行加密（下面引用为用户的共享数据密钥）。

帐户转移时先进行锁定，然后再转移并删除用户的帐户。这将确保没有秘密执行的操作。用户的共享数据密钥由管理员检索和解密。 这用于解密已转移用户可以访问的所有记录密钥、团队密钥和文件夹密钥，并且这些密钥与正在传输的用户的公钥共享。 管理员不会接收记录和文件夹数据，而是简单地转移密钥。 只有收件人可以访问记录和文件夹数据。

所有加密都是在客户端中进行，Keeper 在任何时候都无法解密正在共享或转移的信息此外，用户的客户端密钥在任何时候都不会被共享。 因此，如果没有用户的主密码，则无法解密用户设备上缓存的数据。 从团队、共享文件夹或直接共享中移除的用户将不会再从团队、共享文件夹或记录收到新的数据。尽管记录、文件夹和团队密钥已泄露给管理员，但这些密钥无法用于访问底层记录或文件夹数据。

可以将多个不同的管理特权分配给分层树的各个部分，以允许特权角色的成员在我们的 Keeper 管理控制台中执行操作。

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

团队可以轻松地将共享文件夹分发给用户组。

权限保护和加密保护是我们两种非常不同的安全模型。 由于权限保护不需要交换密钥，因此具有充分权限的 Keeper 人员可以更改权限，以便无法编辑他/她可以访问的记录的用户可以获得编辑记录的能力。 一旦密钥被用户泄露，它就变成了底层数据的权限问题，而不是加密问题。

Keeper Active Directory / LDAP Bridge

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

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

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

单点登录 (SAML) 身份验证

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® On-Prem

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）。

BreachWatch

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

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

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

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

在 Business 和 Enterprise 客户激活 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 解决方案和体系结构。利用 Amazon AWS，Keeper 可以根据需要无缝地扩展资源，为客户提供最快最安全的云存储环境。KSI 采用多区域和多地域环境运营，以最大限度保证正常运行时间，并为客户提供最快的响应时间。

服务器认证

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

传输层加密

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

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

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

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA

密钥固定

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

跨站脚本 (XSS) 攻击保护

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

访问 KeeperSecurity.com 和 KeeperSecurity.eu 域名仅限于通过使用 TLS v1.3 的 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® 和 Face 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 保管库。

生物识别

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

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

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 设备）的屏幕或用户手动输入，自动从该设备批准和发送。多层加密、Touch ID和多因素认证使Keeper DNA成为目前最先进、最安全且操作界面最优美的认证方式。

合规与审核

FedRAMP High 认证

Keeper ICAM & Identity Security Platform for Government 是 Keeper Security 为公共部门组织提供的密码管理和网络安全平台。Keeper ICAM & Identity Security Platform for Government 是已获得 FedRAMP 认证的高影响级别提供商，托管于 AWS GovCloud（美国）。Keeper ICAM & Identity Security Platform for Government 可以在 FedRAMP 市场上找到。

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

GovRAMP 高级授权

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

符合 SOC 2

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

ISO 27001、27017 和 27018 认证

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

GDPR 合规性

Keeper 致力于对我们的业务流程和产品进行更改和改进，以确保我们在 2018 年 5 月 25 日之前为 GDPR 做好准备。

符合 ITAR

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

Keeper ICAM & Identity Security Platform for Government 的 FedRAMP 中等环境通过以下方式支持 ITAR 要求：

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

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

有关 ITAR 的更多信息。

FSQS-NL 认证

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

保护患者医疗数据

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

HIPAA 合规性和业务伙伴协议

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

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

数字运营弹性法案 (DORA) 合规

为了支持遵守《数字运营弹性法案》(DORA)，Keeper 保持全面的运营和安全措施，以保护 Keeper 的软件和系统。 这包括但不限于，实施有效的风险管理流程，跟踪和管理正常运行时间的可用性，维护严格的内部安全政策，要求进行内部安全培训，以及建立事件响应协议。 Keeper 持续监控、更新和完善程序，以降低风险，并确保 Keeper 软件和服务的运营功能和安全性。

渗透测试

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

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

McAfee Secure 每天都对 KSI 进行检测，以确保 Keeper Web 应用和 KSI 的 Cloud Security Vault 对已知的远程攻击、漏洞和拒绝服务攻击保持安全。在 Keeper 网站上可以找到 McAfee Secure 徽章来确认 Keeper 网站、Web 应用和 Cloud Security Vault 进行了每日检测。

McAfee Secure 每月在 Keeper 网站、Keeper Web 应用程序和 Keeper Cloud Security Vault 上进行全面的外部安全扫描。 Keeper 的工作人员通过 McAfee Secure 定期进行按需外部扫描。

支付处理以及遵守PCI标准

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

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

欧盟-美国隐私盾

Keeper Web 客户端、Android 应用程序、Windows Phone 应用程序、iPhone/iPad 应用程序和浏览器扩展程序已通过欧盟隐私盾认证，符合美国商务部的欧盟-美国协议。 隐私盾计划，符合欧盟委员会的数据保护指令。

关于美国商务部美国和欧盟隐私盾计划的详细内容，请参考：https://www.privacyshield.gov

经 FIPS 140-3 验证

Keeper 使用 FIPS 140-3 验证的加密模块，以满足政府和公共部门严格的安全要求。 Keeper 的加密已通过 NIST CMVP 认证，并经认可的第三方实验室根据 FIPS 140 标准进行了验证。 Keeper 已获得 NIST CMVP 颁发的编号为 3967 的证书

符合 FDA 21 CFR 第 11 部分要求

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

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

详细的稽查轨迹

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

电子签名

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

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

Keeper由美国商务部工业安全局认证，符合出口管理条例（EAR），其出口商品分类控制数为5D992。

有关 EAR 的更多信息，请访问：https://www.bis.doc.gov

全天候远程监控

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

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

仿冒或伪造的电子邮件

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

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

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

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

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

漏洞报告和 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

子附录 E

英国增编

专员将根据《2018 年数据保护法》的第 S119A(1) 条发布标准数据保护条款

欧盟委员会标准合同条款的国际数据传输增编

B1.0 版本，2022 年 3 月 21 日生效

本增编已由进行受限制传输的缔约方的信息专员发布。 信息专员认为，在以具有法律约束力的合同形式签订时，它为受限制传输提供了适当的保障措施。

第 1 部分：表格

表 1：缔约方

表 2：选定 SCC、模块和选定条款

表 3：附录信息

“附录信息”是指必须为已批准的欧盟 SCC（除缔约方外）的附录中规定的选定模块提供的信息，本增编的相关信息载于：

附件 1A：缔约方名单：见缔约方之间增编的附件 1。

附件 1B：传输说明：请参见各方之间增编的子附录 A。

附件 II：技术和组织措施，包括确保数据安全的技术和组织措施：请参见各方之间增编的子附录 D。

附件 III：子处理者名单（仅限模块 2 和 3）：请参见各方之间增编的子附录 B。

表 4：当已批准增编发生变化时终止本增编

第 2 部分：强制性条款

签订本增编

1. 各方同意受本增编中规定的条款和条件的约束，作为交换，另一方也同意受本增编的约束。
2. 尽管已批准的欧盟 SCC 的附件 1A 和第 7 条要求各方签名，但为了进行受限制传输，各方可以以任何方式签订本增编，使其对缔约方具有法律约束力，并允许数据主体执行本增编中规定的权利。 签订本增编将具有与签署已批准的欧盟 SCC 和已批准的欧盟 SCC 的任何部分相同的效力。

本增编的解释

3. 如果本增编使用已批准的欧盟 SCC 中定义的术语，则这些术语的含义应与已批准的欧盟 SCC 中定义的术语相同。 此外，以下术语具有以下含义：

4. 本增编必须始终以符合英国数据保护法的方式进行解释，以便履行缔约方提供适当保障措施的义务。
5. 如果增编中包含的条款以已批准的欧盟 SCC 或已批准的增编不允许的方式修改了已批准的 SCC，则此类修订将不会纳入本增编中，并且将取代已批准的欧盟 SCC 的等效规定。
6. 如果英国数据保护法与本增编之间存在任何不一致或冲突，则以英国数据保护法为准。
7. 如果本增编的含义不清楚或有多个含义，则适用与英国数据保护法最接近的含义。
8. 任何提及立法（或立法的特定规定）均指随着时间的推移可能会发生变化的立法（或特定规定）。 这包括在本增编生效后已合并、重新颁布和/或替换该立法（或特定规定）的地方。

层次

9. 尽管已批准的欧盟 SCC 的第 5 条规定，已批准的欧盟 SCC 优先于各方之间的所有相关协议，但各方同意，对于受限制传输，以第 10 节中的层次结构为准。
10. 如果已批准的增编与增编的欧盟 SCC（如适用）之间存在任何不一致或冲突，则已批准的增编将取代增编的欧盟 SCC，除非（在此范围内）增编欧盟 SCC 的条款为数据主体提供了更大的保护，在这种情况下，这些条款将取代已批准的增编。
11. 如果本增编纳入了已签订的为保护受一般数据保护条例 (EU) 2016/679 约束的传输的增编欧盟 SCC，则双方承认，本增编中的任何内容均不影响这些增编欧盟 SCC。

合并和更改 EU SCC

12. 本增编纳入了增编欧盟 SCC，这些增编已进行了必要的修订，以便：
    1. 在英国数据保护法适用于数据导出者在进行数据传输时的处理的情况下，他们共同处理数据导出者向数据导入者进行的数据传输，并为这些数据传输提供适当的保障措施；
    2. 第 9 至 11 节将取代增编欧盟 SCC 的第 5 条（层次结构）；以及
    3. 本增编（包括纳入其中的增编欧盟 SCC）：(1) 受英格兰和威尔士法律管辖，并且 (2) 由此产生的任何争议均由英格兰和威尔士法院解决，除非双方明确选择了苏格兰或北爱尔兰的法律和/或法院。
13. 除非双方已商定满足第 12 节要求的替代修订，否则将适用第 15 节的规定。
14. 除了满足第 12 条的要求外，不得对已批准的欧盟 SCC 进行任何修订。
15. 对增编欧盟 SCC（用于第 12 条）进行了以下修订：

    1. 提及的“条款”是指本增编，并纳入了增编欧盟 SCC；

    2. 在第 2 条中，删除以下词语：

       “以及，根据法规 (EU) 2016/679 第 28(7) 条的标准合同条款，关于从控制者到处理者和/或处理者到处理者的数据传输”；

    3. 第 6 条（传输说明）替换为：

       “传输的详细信息，特别是传输的个人数据的类别和传输目的，详列于附件 I.B，其中英国数据保护法适用于数据导出者在进行该传输时的处理。;

    4. 将模块 1 的第 8.7(i) 条替换为：

       “根据英国 GDPR 第 17A 条（涵盖继续传输）的规定，它是受益于充分性法规的国家”；

    5. 将模块 2 和 3 的第 8.8(i) 条替换为：

       “继续传输是传输给根据英国 GDPR 第 17A 条（涵盖继续传输）受益于充分性法规的国家；”

    6. 提及“法规 (EU) 2016/679”，“欧洲议会和理事会 2016 年 4 月 27 日发布的关于在处理个人数据方面保护自然人和此类数据自由移动的法规 (EU) 2016/679”和“该法规”均被“英国数据保护法”取代。 将提及“法规 (EU) 2016/679”的特定条款替换为英国数据保护法的相应条款或章节；

    7. 已删除提及法规 (EU) 2018/1725；

    8. 提及的“欧洲联盟”、“联盟”、“欧盟”、“欧盟成员国”、“成员国”和“欧盟或成员国”均替换为“英国”；

    9. 将模块 1 的第 10(b)(i) 条中对“第 12(c)(i) 条”的引用替换为“第 11(c)(i) 条”；

    10. 第 13 (a) 条和附件 I 第 C 部分未使用；

    11. 将“合格监管机构”和“监管机构”都替换为“信息专员”；

    12. 在第 16(e) 条中，将 (i) 小节替换为：

        
        

        “国务卿根据《2018 年数据保护法 》第 17A 条制定法规，其涵盖这些条款适用的个人数据的传输；”

    13. 第 17 条已替换为：

        
        

        “这些条款受英格兰和威尔士法律管辖。”;

    14. 第 18 条已替换为：

        
        

        “因这些条款而产生的任何争议应由英格兰和威尔士法院解决。 数据主体还可以向联合王国任何国家的法院对数据导出者和/或数据导入者提起法律诉讼。 双方同意接受此类法院的管辖。“；并且

    15. 除脚注 8、9、10 和 11 外，已批准的欧盟 SCC 的脚注不构成增编的一部分。

本增编的修订

16. 双方可能同意更改增编欧盟 SCC 的第 17 条和/或第 18 条，以引用苏格兰或北爱尔兰的法律和/或法院。
17. 如果双方希望更改第 1 部分：已批准增编的表格中包含的信息的格式，则可以书面同意更改，前提是该更改不会降低适当保障措施。
18. ICO 可以不时发布修订后的已批准的增编，该增编：
    1. 对已批准增编进行合理且相称的更改，包括纠正已批准增编中的错误；和/或
    2. 反映英国数据保护法的变更；

修订后的已批准增编将指定对已批准增编的更改生效的开始日期，以及缔约方是否需要审查本增编，包括附录信息。 从指定的开始日期开始，本增编将按照修订后的已批准增编中的规定自动修订。

19. 在 ICO 根据第18 条发布了修订后的已批准增编的情况下，如果在表 4“在已批准的增编发生变化时终止增编”中选择的任何缔约方，将直接导致已批准增编中在以下方面发生重大、不成比例且明显的增加：
    1. 履行其增编中规定的义务的直接成本；和/或
    2. 增编中规定的风险，

在任一情况下，它首先采取了合理步骤来降低这些成本或风险，使其不构成重大和不成比例的成本和风险，然后该缔约方可以在合理通知期结束时终止本增编，方法是在修订后的已批准增编开始日期之前向另一方提供该期间的书面通知。

20. 双方不需要任何第三方的同意即可对本增编进行更改，但任何更改必须根据其条款进行。

备选的第 2 部分强制性条款：