期待新课程开始招生 我们将继续发布一系列关于 MySQL 加密的文章。
在本系列的上一篇文章中（）我们讨论了密钥库。 在本文中，我们将了解如何使用主密钥并讨论信封加密的优点和缺点。
信封加密背后的想法是，用于加密的密钥（表空间密钥）使用另一个密钥（主密钥）进行加密。 表空间密钥实际上用于加密数据。 从图形上来说，它可以这样表示：
主密钥位于密钥环中，表空间密钥位于加密的表空间标头中（位于表空间的第 0 页）。
上图中：
-
表A使用密钥1（Key 1）加密。 密钥1使用主密钥加密，并加密存储在表A的表头中。
-
表 B 使用密钥 2 加密。 密钥 2 使用主密钥（屏蔽密钥）进行加密，并加密存储在表 B 的标头中。
-
等。
当服务器需要解密表A时，它从存储中检索主密钥，从表A的表头中读取加密密钥1，并对密钥1进行解密。解密后的密钥1缓存在服务器内存中，用于解密表A 。
InnoDB的
在InnoDB中，实际的加密和解密是在I/O层完成的。 也就是说，页面在刷新到磁盘之前进行加密，并在从磁盘读取之后立即进行解密。
在InnoDB中，加密仅在表空间级别起作用。 默认情况下，所有表都创建在单独的表空间中（）。 换句话说，创建的表空间只能包含一个表。 尽管您也可以在主表空间中创建表（）。 但无论如何，表总是位于某个表空间中。 由于加密是在表空间级别进行的，因此它要么完全加密，要么不加密。 也就是说，不可能只加密主表空间中的部分表。
如果由于某种原因禁用了 file-per-table，则所有表都会在系统表空间内创建。 在 您可以使用 innodb 变量加密系统表空间系统表空间加密或使用加密线程，但这仍然是一个实验性功能。 MySQL没有这个。
在继续之前，我们需要看一下主密钥 ID 的结构。 它由UUID、KEY组成ID 和前缀“INNODBKey”。 它看起来像这样：INNODBKey-UUID-KEYID。
UUID 是具有加密表空间的服务器的 uuid。 钥匙ID只是一个不断增加的值。 第一次创建主密钥KEY时ID为1。在密钥轮换期间，当创建新的主密钥时，KEYID = 2 等等。 我们将在本系列的下一篇文章中详细讨论主密钥轮换。
现在我们知道主密钥标识符是什么样子，让我们看看加密的表空间标头。 当表空间被加密时，加密信息被添加到标头中。 它看起来像这样：
密钥 ID 是密钥ID来自我们已经讨论过的主密钥ID。 UUID是服务器的uuid，也用于主密钥标识符。 TABLESPACE KEY - 表空间密钥，由服务器随机生成的 256 位组成。 初始化向量 (IV) 也由 256 个随机生成的位组成（尽管它应该是 128 位）。 IV 用于初始化 AES 加密和解密（256 位中，仅使用了 128 位）。 最后是 TABLESPACE KEY 和 IV 的 CRC32 校验和。
一直以来，我都在稍微简化一下，说标头包含表空间的加密密钥。 事实上，表空间密钥和初始化向量是使用主密钥一起存储和加密的。 请记住，在加密表空间密钥和初始化向量之前，会为它们计算 CRC32。
为什么需要 CRC32？
简而言之，就是保证主密钥的有效性。 解密表空间密钥和初始化向量后，计算校验和并与标头中存储的 CRC32 进行比较。 如果校验和匹配，则我们拥有正确的主密钥和表空间密钥。 否则，表空间将被标记为丢失（无论如何我们都无法解密它）。
你可能会问：什么时候进行密钥验证？ 答案是服务器启动时。 具有加密表/表空间的服务器在启动时读取 UUID、KEY从标头中获取 ID 并生成主密钥 ID。 然后，它从密钥环中获取所需的主密钥，解密表空间密钥，并验证校验和。 再次，如果校验和匹配，则一切正常，如果不匹配，则表空间被标记为丢失。
如果您阅读了本系列的上一篇文章（），那么您可能还记得，当使用基于服务器的密钥存储时，服务器在启动时仅接收密钥标识符列表，或者更确切地说，密钥 id 和用户 id，因为这对唯一标识密钥。 现在我说的是，当服务器启动时，它会收到检查它是否可以解密表空间密钥所需的所有密钥。 那么为什么在初始化时，在服务器存储的情况下，只加载keyID 和用户id，而不是所有键？ 因为您可能不需要所有钥匙。 这主要是由于主密钥轮换造成的。 轮换主密钥时，会在保管库中创建新的主密钥，但不会删除旧密钥。 因此，服务器密钥库中可能有许多服务器不需要的密钥，因此在服务器启动时不会检索这些密钥。
现在是时候谈谈主密钥加密的优点和缺点了。 最大的优点是您只需要一个加密密钥（主密钥），该密钥将与您的加密数据分开存储。 这使得服务器启动速度快，存储空间小，易于管理。 而且单个主密钥很容易重新生成。
然而，主密钥加密有一个很大的缺点：一旦使用 tablespace_key 加密表空间，它就始终保持使用相同密钥的加密状态。 旋转主钥匙在这里没有帮助。 为什么这是一个缺点？ 我们知道 MySQL 存在一些错误，可能会导致突然崩溃并创建核心文件。 由于核心文件包含服务器内存转储，因此转储可能包含解密的表空间密钥。 更糟糕的是，解密的表空间密钥存储在内存中，可以交换到磁盘。 您可以说这不是一个缺点，因为您需要 root 权限才能访问这些文件和交换分区。 是的。 但root只需要一段时间。 一旦某人有权访问解密的表空间密钥，即使没有 root 权限，他/她也可以继续使用它来解密数据。 此外，磁盘可能被盗，交换分区/核心文件可以使用第三方工具读取。 TDE 的目标是即使磁盘被盗也无法读取。 在 可以使用新生成的密钥重新加密表空间。 此功能称为加密线程，在撰写本文时仍处于实验阶段。
阅读更多：
来源： habr.com
