加密我们的备份：达到终点

已发表: 2017-09-02

注意：这篇工程帖子由我们的数据库管理员 Silvia Botros 撰写。 在这里查看她的一些其他 DBA 帖子。

一年前，SendGrid 正在努力争取 SOC2 认证。 每个人都参与其中。 几乎每个交付团队板上都有带有 SOC2 标签的故事，因为我们都希望在第三季度末获得认证。 可以想象，作为数据库的负责人，堆栈的那一部分肯定有一些工作要做。

在我的这项业务范围内努力的任务列表中，确保我们的备份是加密的。 由于我熟悉的领域是 DBA 工具，并且知道 Percona 的 xtrabackup 已经支持加密，因此可以预见我会第一次尝试这项任务。

在测试这种方法时，我考虑了一些重要的事情：

  • 显然，备份需要加密
  • 需要知道和可接受创建备份的开销
  • 在恢复时解密备份的开销需要知道并且可以接受

这意味着首先，我需要能够跟踪我的备份需要多长时间。

跟踪备份时间

SendGrid 使用 Graphite 作为其基础设施指标，虽然绝大多数是通过 Sensu 发送的，但 Graphite 很容易直接通过 bash 行发送指标——非常方便，因为备份脚本是在 bash 中的。 请注意，直接在 Graphite 发送指标不是超级可扩展的，但由于这些备份最多每小时运行一次，这对我的需求来说很好。

结果证明这部分相对容易。

为了解释最后一行发生的事情，我向 Graphite 发送了我正在发送的度量的路径（确保它是唯一的）、度量值，然后是纪元格式的当前时间。 为了简单起见，我决定使用 Netcat，我给它设置了 1 秒的超时时间，否则它永远不会退出。 `graphite url` 是我们在数据中心的 Graphite 的 DNS 端点。

既然我有了一个可以比较的基线，我们就可以开始测试加密方法了。

按照 Percona 关于如何执行此操作的详细文档，我从制作密钥开始。 如果您仔细阅读该文档页面，您可能会意识到一些事情。

这个密钥是要直接传给备份工具的，是可以解密快照的同一个密钥。 这称为对称加密，从本质上讲，它在两个方向上都使用相同的密钥，不如非对称加密安全。 我决定继续测试，看看简单性是否仍然使这成为一种可行的方法。

使用非常小的数据库（几百 MB）进行的测试是成功的。 该工具按预期工作并记录在案，但这更像是一个功能测试，真正的问题是“在我们更大的数据库上加密的损失有多大？” SendGrid 中更多的旧实例已从 1-2 TB 增长到单个 18 TB 的野兽。 我打算用于小型实例的东西也必须在较大的实例上也可以接受。

这就是测试和基准测试变得有趣的地方

我的第一个相当大的测试对象是我们拥有的磁盘上 1 TB 的数据库。 很快我就遇到了一个意想不到的问题。 使用最少的加密设置（1 个线程，默认块大小），我看到备份失败并出现以下错误：

当时，这些数据库使用 512MB 作为事务日志文件大小，这是一个相当繁忙的集群，因此这些文件几乎每分钟都在轮换。 通常，这在数据库性能中会很明显，但它大多被固态驱动器的奇迹所掩盖。 似乎没有设置任何并行加密线程（阅读：使用一个）意味着我们花了很多时间加密 .ibd 文件，以至于我们下面滚动的 innodb 重做日志正在破坏备份。

所以，让我们用一些加密线程再试一次。 作为第一次尝试，我尝试了 50 个线程。 这里的诀窍是在不竞争 CPU 的情况下找到快速加密的最佳点。 我还将“ib_logfiles”的大小增加到每个 1 GB。

这是一个更成功的测试，我很乐意让它在一夜之间冲泡。 在最初的几个晚上，情况似乎很好。 是时候进行一个不会增长太多的备份了，但是备份过程中的平均盒子负载肯定显示了添加的步骤。

然而，当我开始测试恢复时，我发现相同备份的恢复过程在添加加密后从 60 分钟增加到 280 分钟——这意味着我们承诺的灾难恢复时间会受到严重影响。

我们需要把它带回到一个更合理的时间框架。

这就是团队合作和更简单的问题解决方案大放异彩的地方。 我们的一位信息安全团队成员决定看看这个解决方案是否可以简化。 因此，他进行了更多测试，并带回了一些更简单、更安全的东西。 我还没有了解 gpg2，所以这也成为了我的学习练习。

gpg2 的好处是它支持非对称加密。 我们创建了一个密钥对，其中有私有和公共部分。 公共部分用于加密您决定提供给 gpg2 的任何流或文件，而私有机密可用于解密。

对我们的备份脚本进行的更改以添加加密对此进行了提炼。 删除了一些参数以使其更易于阅读：

另一方面，在恢复备份时，我们只需确保主机的密钥环中有一个可接受的密钥，然后使用以下命令：

由于我也是 gpg2 的新手，这对我来说是一个学习机会。 Colin，我们出色的 InfoSec 团队成员，继续使用 gpg2 测试备份和恢复，直到他确认使用 gpg2 比使用 xtrabackup 的内置压缩具有多种优势，包括：

  • 它是不对称的
  • 它的解密秘密管理相对容易轮换（更多内容见下文）
  • 它与工具无关，这意味着任何其他类型的不使用 xtrabackup 的备份都可以使用相同的方法
  • 它在解密时使用了多个内核，这给了我们更好的恢复时间

总是有改进的余地

我仍然看到改进空间的一个地方是我们如何处理可以解密这些文件的秘密。 目前，我们将它们包含在我们的企业密码管理解决方案中，但是从那里获取它，然后使用它来测试备份是一个手动过程。 我们计划的下一步是实施 Hashicorp 的 Vault，并使用它无缝地在指定的主机上提取密钥进行解密，然后将其从本地环中删除，以便轻松用于自动化测试并仍然受到保护。

最终，我们在不牺牲备份性能或灾难恢复 SLA 的情况下及时获得了所有数据库备份以符合我们的 SOC2 需求。 我和我们的信息安全团队一起完成这项任务很有趣，并从中学习了新工具。 另外，当最简单的解决方案最终成为最适合一个人的任务时，这总是很好的。