3 数据恢复

灾难恢复是为发生自然或人为灾难后在组织中恢复或延续业务关键信息做准备的流程、策略和过程。其中包括：

  • 恢复点目标 (Recovery Point Objective, RPO)：业务持续性计划规定的恢复数据的时间点。这通常是关于企业确定在灾难情况下什么是“可接受的损失”的定义。这可以是小时数、天数或者甚至周数。

  • 恢复时间目标 (Recovery Time Objective, RTO)：为了避免与中断业务持续性关联的不可接受的后果，业务流程必须在发生灾难（或中断）后多长时间内“恢复”。使用组合服务网络时该项可能是分钟数。请参见图 3-2。

OKM 可以跨越多个地理上分离的站点。这样可以极大地降低发生销毁整个群集的灾难的风险。通过群集 KMA，可进行数据库条目的复制和工作负荷平衡。虽然不太可能需要重新创建整个群集，但是可以通过从最近的数据库备份重新创建 OKM 环境来恢复大部分关键数据。

设计加密/归档策略时，一个非常重要的设计元素是，可以在恢复站点复制和保管在任何站点生成的关键数据。

如果失去某个站点，该备份数据可以传输到另一个运行站点。同级站点的 KMA 将知道与磁带卷关联的数据单元和密钥，将可以获得继续业务运营所需的加密数据。

站点操作恢复时，可以在相同或不同位置轻松恢复群集的损坏部分。

许多公司使用第三方灾难恢复 (disaster recovery, DR) 站点的服务，从而可以尽快重新开始其业务运营。定期未公布的 DR 测试说明了公司从自然或人为灾难进行恢复的准备程度。存在很多可能方案，下面讨论了一些方案。

共享资源 提供灾难恢复的成本效益元素
复制 通过从完整 KMA 复制来恢复
方案 1 预定位 KMA
方案 2 共享 KMA
方案 3 密钥传输
方案 4 从备份恢复
备份方法 可能有帮助的一些准则

备份和密钥共享注意事项

OKM 备份和密钥共享（导入/导出）是数据库密集操作，可以在 KMA 执行备份或密钥传输操作时减少 KMA 上的响应时间。

如果可能，在 OKM 备份和传输时段减少磁带机工作负荷。

如果不可能，则考虑以下选项：

  • OKM 备份和密钥传输可以在任何 KMA 上进行，但是最好每次使用相同 KMA。这最可能是设置调用 OKM 备份实用程序的 cron 作业的方式。

  • 如果群集足够大，则 KMA 可以专用作管理 KMA。

    • 此 KMA 不应具有服务网络连接，从而其在任何时间都不会负担磁带机密钥请求，特别是在备份或密钥传输时段。

    • 此 KMA 还可用于 OKM GUI 会话，从而从其他 KMA 卸下处理与管理相关的请求的任务。

  • 备份和密钥传输 KMA 的管理网络连接越快，在备份和密钥传输时段越能够处理其他负荷。

    这对于所有 KMA 都是正确的，特别是对于执行备份的 KMA，因为它在备份时段将跟不上处理复制请求。具有快速网络连接将有助于最大程度降低复制积压，例如延迟。

  • 将备份和密钥传输 KMA 放在磁带机未使用的站点中。然后，磁带机优先选择其分配到的站点内的其他 KMA，并避免使用备份和密钥传输 KMA。

  • 向包含磁带机的站点添加更多 KMA，从而将在更多 KMA 中进行密钥请求的负载平衡。这样可以减少备份和密钥传输 KMA 必须处理的密钥请求数量。

密钥池大小确定

OKM 管理员应该知道每时间单位以及 OKM 备份时段或密钥传输时段要创建的最坏情况密钥数量。

对于本讨论，我们假定计算了每小时的密钥使用率。

注:

KMA 预生成密钥，从而在密钥池在服务器内运行之前，来自代理的密钥创建请求实际上不会导致在 KMA 上创建密钥。服务器忙碌时，密钥池维护者可以延迟其操作。

总群集密钥池大小必须足够大，以便 KMA 可以在备份时段从其密钥池分发预生成的密钥。

密钥池大小太小时，KMA 会用完预生成的密钥并开始返回无现成密钥错误。发生这种情况并且它进一步加剧了备份/密钥传输时段的性能问题时，磁带机将故障转移到其他 KMA。

对于大多数客户来说，默认密钥池大小为 1000 个密钥应该已足够，除非备份时段的估计最坏情况密钥创建率超过了此值。

应定期观察 OKM 备份时段，因为随着数据库变大该时段会逐渐增加。备份时段超过阈值时，可能需要对密钥池大小进行调整。如果密钥使用率因为整体磁带工作负荷更改而增长，也应该调整密钥池大小。

共享资源

共享资源可以提供灾难恢复的成本效益元素。

如果公司专门进行记录管理、数据破坏以及数据连续性和恢复，则购买多个用户可用于各种操作（包括备份和归档）的设备。

对于灾难恢复，客户可以短期使用磁带机、磁带库和共享资源站点的其他资源来执行灾难恢复测试或灾难的实际恢复。

有两种灾难恢复和密钥管理方法。

  • 客户可以将 KMA 放在 DR 站点并使用 WAN 连接将这些 KMA 配置到其生产群集中。这些 KMA 专用于特定客户并允许客户的密钥始终位于 DR 站点以供使用。

    使用这种方法，当客户在共享资源站点的 KMA 中注册磁带机并加入 OKM 群集后，可以开始进行恢复。

    可以通过将 OKM GUI 连接到 DR 站点的 KMA 来执行此操作。在实际灾难恢复情况中，这些可能只是客户群集中的剩余 KMA。

    磁带机注册可以在几分钟内完成。注册完成后并且已经配置了磁带机，则可以开始磁带生产。

  • 另一种方法是将客户的生产 OKM 的备份恢复到共享资源站点提供的 KMA 中。这样不再需要广域网 (wide area network, WAN) 链接和现场的专用 KMA，但是需要额外时间来恢复数据库。

    使用这种方法，恢复操作需要普通 OKM 备份文件和核心安全备份。这种恢复方法需要法定数目的密钥拆分凭证成员以进行核心安全备份。

    恢复操作每 100,000 个密钥大约需要 20 分钟。

    恢复完成后，必须注册并配置磁带机。

    DR 站点需要三个文件：

    • 核心安全备份文件

    • .xml 备份文件

    • .dat 备份文件

    这些文件由备份官创建。

从其他站点复制

图 3-1 和图 3-2 显示了两个地理上分离的站点示例，一个 OKM 群集，群集中具有四个 KMA，每个站点有两个 KMA。

在初始安装过程中，配置第一个 KMA 后，任何附加 KMA（新的或更换的）将从群集中的其他 KMA 进行自复制。

恢复单个 KMA 不会影响群集中的其他 KMA，只要至少有一个 KMA 保持运行即可。

图 3-1 是恢复点目标示例。在此示例中，恢复业务持续性到整个站点的时间点可能需要数月。

  • 如果站点 1 被销毁，而站点 2 仍旧完整：

    客户必须更换基础结构中的所有销毁设备，包括群集的 KMA 和磁带机。

    站点恢复并运行后：

    • 安装并创建新 KMA（需要安全官和法定成员）。

    • 加入现有群集，对于新 KMA，一次加入一个。

    • 安装和激活新磁带机。

    • 注册新磁带机，现在称为代理。

    然后，站点 1 从完整站点 2 中的现存 KMA 进行自复制。

图 3-2 是恢复时间目标示例。在此示例中，恢复业务持续性的时间量以分钟为单位。

  • 如果站点 1 的 KMA 被销毁，而站点 2 的基础结构仍旧完整：

    通过连接两个站点之间的磁带机的广域“服务”网，站点 2 中的完整 KMA 可以继续两个站点之间的磁带操作。

    在站点 1 更换 KMA 后，如上所述，它们将从完整站点 2 中的现存 KMA 进行自复制。

    在 QuickStart 程序过程中，客户选择：

    (2) Join Existing Cluster

    对于每个新 KMA，一次加入一个。

图 3-1 从其他站点复制－恢复点目标

周围文本对 图 3-1 进行了说明。

图 3-2 服务网络延续－恢复时间目标

周围文本对 图 3-2 进行了说明。

方案 1：预定位 KMA

在此方案中，客户具有包含多个站点的大型环境。每个站点使用：

  • 一对 KMA 和基础结构来支持自动磁带加密

  • 单个群集，其中所有 KMA 共享密钥。

连同多个站点，此客户还在属于客户的 OKM 群集一部分的灾难恢复 (Disaster Recovery, DR) 站点处维护和使用设备。

有关此方案，请参见图 3-3。

此客户使用简单备份方案，其中包含：

  • 每日增量备份

  • 每周差异备份

  • 每月完全备份。

每月备份在 DR 站点进行复制并发送到非现场存储设备，存储 90 天。在 90 天保留期后，磁带将被回收。

因为客户在 DR 站点拥有设备，所以此站点只是直接处理备份和归档进程的客户的扩展。

图 3-3 预定位设备

周围文本对 图 3-3 进行了说明。

方案 2：共享 KMA

此方案非常类似于方案 1：预定位 KMA；但是，灾难恢复站点拥有设备并且与多个其他客户共享资源。

有关此方案，请参见图 3-4。

因为此灾难恢复站点支持其他 DR 客户机，所以您无法假定该站点始终配置进行支持加密的进程。

注:

必须先将 KMA 重置为出厂设置，然后才能为不同客户创建配置。

在 DR 站点，

  • 客户从 DR 站点清单中选择适当设备。

  • DR 站点对设备和基础结构进行相应配置。

重要提示:

客户必须为 DR 站点提供三个 OKM 备份文件：

  • 核心安全备份文件

  • .xml 备份文件

  • .dat 备份文件

在 DR 站点，客户

  • 使用 QuickStart 向导配置初始 KMA

  • 从 OKM 备份文件恢复 KMA

  • 激活、启用或将磁带机切换为支持加密（DR 代表）

  • 在 DR 站点 KMA 群集中注册磁带机。

作业完成后，灾难恢复站点需要：

  • 在代理中关闭加密

  • 从群集移除磁带机或重置磁带机口令短语

  • 将 KMA 重置为出厂默认值。

断开基础结构和网络的连接。

图 3-4 共享 KMA

周围文本对 图 3-4 进行了说明。

方案 3：密钥传输伙伴

密钥传输也称为密钥共享。通过传输，可以在伙伴或独立群集之间安全地交换密钥及关联数据单元，交换加密的介质时需要使用传输。

注:

DR 站点还可以配置为密钥传输伙伴。

此过程要求传输中的各方建立公钥/私钥对。初始配置完成后：

  • 发送方使用导出密钥生成文件传输。

  • 然后，接收方使用导入密钥接收密钥和关联数据

实践中，不建议使用密钥传输伙伴进行灾难恢复。但是，如果备份过程中 DR 站点创建密钥，执行密钥传输会将 DR 站点密钥增量式地添加到已经存在的数据库。

密钥传输过程要求每个用户为每个 OKM 群集配置一个传输伙伴。

  • 一个传输伙伴从他们的 OKM 群集导出密钥。

  • 另一个传输伙伴将密钥导入他们的 OKM 群集。

配置密钥传输伙伴时，管理员必须按需要多个角色的特定顺序执行任务，这些角色包括：

  • 安全官角色

  • 合规官角色

  • 操作员角色。

要配置密钥传输伙伴，请参阅《OKM Administration Guide》，并且：

  1. 为参与密钥交换的两个 OKM 群集配置密钥传输伙伴。

  2. 建立公钥/私钥交换来与 OKM 群集通信。例如，在发送电子邮件时，两个站点可以使用建立的通信方法来保护电子邮件交换并验证其来源和收件人。

    存在指纹等机制来防止在传输过程中修改此信息。

  3. 收集法定信息来批准创建新传输伙伴。

  4. 向一个或多个密钥组分配传输伙伴。

  5. 从一个 OKM 群集导出密钥并将其导入另一个群集。可以多次执行此操作。

图 3-5 传输密钥伙伴

周围文本对 图 3-5 进行了说明。

方案 4：从备份恢复

备份是指生成数据副本，从而在灾难或其他数据丢失事件后可以使用这些副本恢复原始数据。

这些副本通常称为“备份”，其用于：

  • 在灾难后恢复站点（灾难恢复）

  • 在意外删除或破坏文件后恢复文件

确定和使用适用于每个部门、组、组织或业务的备份方案非常重要。确定备份过程按所预期的那样运行也非常重要。

对于 OKM，以下项可用于帮助创建并且在需要时恢复 OKM。

  • 备份

    在备份过程中创建的文件，包含恢复 KMA 需要的所有信息。使用专为备份生成的“密钥”对该文件进行加密。该密钥包含在相应的备份密钥文件中。

  • 备份密钥文件

    在备份过程中生成的文件，包含用于加密备份文件的密钥。该文件使用系统“主密钥”进行加密。使用法定数目的密钥拆分凭证从核心安全备份文件中提取主密钥。

  • 备份操作员

    一种用户角色，负责保护和存储数据和密钥。

注:

有关更多信息，请参见"备份方法"。

备份位置：

请注意，OKM 备份位置应处于位于适当安全距离的站点处，从而单一建筑着火不会销毁所有数据。该距离还应考虑自然灾害。

例如，如果所有备份站点都位于新奥尔良的建筑中，则在类似卡特里娜飓风的灾难中将无法避免数据损坏。

恢复：

仅当群集中的所有 KMA 都已失败时，例如如果站点被火灾销毁，才需要从备份进行恢复。

注:

从备份恢复 OKM 需要法定信息。备份操作员创建和维护备份，安全官恢复这些备份。确保有所需数目的法定用户。

要从备份恢复系统，请参阅《OKM Administration Guide》，并且：

  1. 选择 "Secure Information Management" > "Backup List"。这样可以查看备份文件的历史记录和详细信息。

  2. 在 "Backup List" 屏幕中突出显示要恢复的备份，然后双击备份条目。此时将显示 "Backup Details" 对话框。

  3. 单击 "Restore" 按钮。此时将显示 "Restore Backup" 对话框。

    图 3-6 从备份恢复

    周围文本对 图 3-6 进行了说明。

  4. 单击 "Start" 按钮。

    上载完成后，将显示 "Key Split Quorum Authentication" 对话框。

    核心安全备份法定用户必须键入其用户名和口令短语来对操作进行验证。

  5. 单击 "OK" 按钮。此时将指示恢复的进度。

备份方法

请记住，每个客户和每种情况都不相同。下面是可能有帮助的一些准则：

备份频率。有两种以不同方式处理的备份：

  • 核心安全备份，必须使用特殊策略保护该备份。

  • 需要保护的密钥数据的数据库备份。

核心安全备份

核心备份包含 OKM 的主要组件，即根密钥材料。在初始化群集时生成的就是此密钥材料。根密钥材料保护主密钥，主密钥是一种对称密钥，用于保护在 KMA 上存储的数据单元密钥。

核心安全备份采用密钥拆分方案进行保护，该方案需要在密钥拆分凭证中定义的法定数目用户。此法定数目的用户必须提供其用户名和口令短语来对根密钥材料解包。

方法：

核心备份必须优先于第一个数据库备份，然后在密钥拆分的成员更改时仅需要重复此核心备份（法定）。这是特殊处理和保护的安全项。这是恢复 OKM 的任何备份所必需的。

作为最佳做法，在客户选择的便携介质（例如 CD、USB 闪存盘或外部硬盘驱动器）上的两个安全位置保存此备份的两个副本。

创建和保护新核心备份时，应该销毁旧的核心备份。

数据库备份

注:

备份操作员负责保护和存储数据及其密钥。

数据库备份包含两个文件：备份文件和备份密钥文件。这些文件名自动生成，不过您可以对其进行编辑。

每个 KMA 在被创建时将创建 1000 个密钥（默认）。在安装过程中这可能会有所不同。每个 KMA 控制并分配其自己的密钥。发放 10 个密钥后，KMA 会创建 10 个密钥来补充它们。

密钥将复制到 OKM 中的所有 KMA。

数据库备份使用 AES-256 进行加密；因此是安全的。

方法：

示例一：数据库备份－OKM 群集中的多个站点

  • 密钥在保护密钥以免损坏。

  • 密钥通过复制受到保护。

因为数据中心按地理位置放置，所以客户应该从不需要进行群集的总体灾难恢复。为此客户创建备份不像示例二那样紧要；但是在将单个 KMA 中所有生成的密钥发放到数据单元之前，先创建核心安全备份，然后创建数据库备份。

示例二：数据库备份－OKM 群集中的一个物理站点

  • 局部性灾难可能会销毁整个 OKM。

  • 数据库备份是密钥的唯一保护。

维护核心安全和数据库备份的非现场副本。对于最低保护：

表 3-1 数据库备份计算

1.

计算使用每个磁带一个密钥方式最初将加密多少磁带。

  

2.

发放最初创建的密钥需要多少小时、天或周？注意：每个 KMA 在被创建时将创建 1000 个密钥（默认）

  

3.

计算挂载的多少磁带具有过期的密钥加密期间？

  

4.

一起添加这两项计算

  

5.

假定仅一个 KMA 发放所有密钥并且在初始密钥全部发放之前备份数据库。这样可以向计算提供 50% 的安全系数。

  

6.

基于新磁带输入重复此计算并重用加密期间失效期。

  

要考虑的事项：

  • 归档副本或不归档副本。

  • 记住旧备份包含您可能不需要保留的用户、密码和其他敏感数据。

  • 生成并归档两个最新数据库备份以防发生备份介质故障。

  • 因为您计算了 50% 的安全系数（假定仅一个 KMA 发放密钥），所以任一个备份都包含所有活动密钥。

  • 从不归档数据库的旧副本。

  • 如果您通常由于策略或合规原因而删除密钥，可以从以前的备份恢复已删除的密钥。

  • 保留冗余副本。不创建两个备份。

  • 生成两个相同备份以防止发生备份介质故障。此方案还可以确保在备份期间不发放其他密钥，从而使两个副本不同。