В преддверии начала нового набора на курс "База данных" Продолжаем публиковать серию статей о шифровании в MySQL. 
В предыдущей статье этой серии ( Шифрование в MySQL: хранилище ключей ) мы говорили о хранилищах ключей.
В этой статье мы рассмотрим, как используется главный ключ, и обсудим преимущества и недостатки шифрования конверта.
Идея шифрования конверта заключается в том, что ключи, используемые для шифрования (ключи табличного пространства), шифруются другим ключом (главным ключом).
Ключи табличного пространства фактически используются для шифрования данных.
Графически это можно представить так:
Главный ключ находится в связке ключей, а ключи табличного пространства — в зашифрованных заголовках табличного пространства (на странице 0 табличного пространства).
На картинке выше:
- Таблица А зашифрована ключом 1 (Ключ 1).
Ключ 1 шифруется с помощью главного ключа и хранится в зашифрованном виде в заголовке таблицы А.
- Таблица B зашифрована ключом 2. Ключ 2 зашифрован с использованием главного ключа (маскирующего ключа) и хранится в зашифрованном виде в заголовке таблицы B.
- И так далее.
ИнноДБ
В InnoDB фактическое шифрование и дешифрование выполняется на уровне ввода-вывода.То есть страница шифруется непосредственно перед записью на диск и расшифровывается сразу после чтения с диска.
В InnoDB шифрование работает только на уровне табличного пространства.
И по умолчанию все таблицы создаются в отдельных табличных пространствах ( табличное пространство «файл на таблицу» ).
Другими словами, создается табличное пространство, которое может содержать только одну таблицу.
Хотя вы также можете создавать таблицы в основном табличном пространстве ( общее табличное пространство ).
Но в любом случае таблица всегда находится в каком-то табличном пространстве.
А поскольку шифрование осуществляется на уровне табличного пространства, оно либо полностью зашифровано, либо нет. То есть невозможно зашифровать только часть таблиц в основном табличном пространстве.
Если по какой-то причине у вас отключено пофайловое пространство, то все таблицы создаются внутри системного табличного пространства.
В Сервер Percona для MySQL вы можете зашифровать системное табличное пространство, используя переменную innodb система табличное пространство шифровать или использовать потоки шифрования, но это все еще экспериментальная функция.
В MySQL этого нет. Прежде чем двигаться дальше, нам нужно взглянуть на структуру идентификатора главного ключа.
Он состоит из UUID, KEY Идентификатор и префикс «INNODBKey».
Это выглядит так: INNODBKey-UUID-KEY. ИДЕНТИФИКАТОР.
UUID — это uuid сервера с зашифрованным табличным пространством.
КЛЮЧ ID — это просто постоянно растущая ценность.
При первом создании мастер-ключа KEY ID равен 1. Во время ротации ключей, когда создается новый главный ключ, KEY ID = 2 и так далее.
Подробнее о ротации мастер-ключей мы поговорим в следующих статьях этой серии.
Теперь, когда мы знаем, как выглядит идентификатор главного ключа, давайте посмотрим на зашифрованный заголовок табличного пространства.
Когда табличное пространство зашифровано, информация о шифровании добавляется в заголовок.
Это выглядит так:
ИДЕНТИФИКАТОР КЛЮЧА – KEY Идентификатор из идентификатора главного ключа, который мы уже обсуждали.
UUID — это uuid сервера, который также используется в идентификаторе главного ключа.
TABLESPACE KEY — ключ табличного пространства, состоящий из 256 бит, случайно сгенерированный сервером.
Вектор инициализации (IV, вектор инициализации) также состоит из 256 случайно сгенерированных битов (хотя должно быть 128 бит).
IV используется для инициализации шифрования и дешифрования AES (из 256 бит используется только 128).
В конце идет контрольная сумма CRC32 для TABLESPACE KEY и IV. Все это время я немного упрощал, говоря, что заголовок содержит зашифрованный ключ табличного пространства.
Фактически ключ табличного пространства и вектор инициализации хранятся и шифруются вместе с использованием главного ключа.
Помните, что перед шифрованием ключа табличного пространства и вектора инициализации для них вычисляется CRC32.
Зачем нужен CRC32?
В двух словах, чтобы убедиться в действительности мастер-ключа.После расшифровки ключа табличного пространства и вектора инициализации вычисляется контрольная сумма и сравнивается с CRC32, хранящимся в заголовке.
Если контрольные суммы совпадают, значит, у нас есть правильный главный ключ и ключ табличного пространства.
В противном случае табличное пространство помечается как отсутствующее (расшифровать его мы все равно не сможем).
Вы можете спросить: в какой момент осуществляется проверка ключа? Ответ: когда запускается сервер.
Сервер с зашифрованными таблицами/табличными пространствами считывает UUID, KEY при запуске.
ID из заголовка и генерирует идентификатор главного ключа.
Затем он получает необходимый главный ключ из набора ключей, расшифровывает ключ табличного пространства и проверяет контрольную сумму.
Еще раз: если контрольная сумма совпадает, то все в порядке, если нет — табличное пространство помечается как отсутствующее.
Если вы прочитали предыдущую статью из этой серии ( Шифрование в MySQL: хранилище ключей ), то, возможно, вы помните, что при использовании серверного хранилища ключей сервер при запуске получает только список идентификаторов ключей, а точнее, идентификатор ключа и идентификатор пользователя, поскольку эта пара однозначно идентифицирует ключ.
Я говорю, что когда сервер запускается, он получает все ключи, необходимые для проверки возможности расшифровки ключей табличного пространства.
Так почему при инициализации в случае с серверным хранилищем загружается только ключ идентификатор и пользователь id, а не все ключи? Потому что вам могут не понадобиться все ключи.
В основном это связано с вращением мастер-ключа.
При ротации главного ключа в хранилище создается новый главный ключ, но старые ключи не удаляются.
Таким образом, в хранилище ключей сервера может находиться много ключей, которые серверу не нужны и поэтому не извлекаются при запуске сервера.
Пришло время поговорить немного о плюсах и минусах шифрования с помощью мастер-ключа.
Самым большим преимуществом является то, что вам нужен только один ключ шифрования (главный ключ), который будет храниться отдельно от ваших зашифрованных данных.
Это обеспечивает быстрый запуск сервера и небольшой объем хранилища, что упрощает управление.
Кроме того, единый мастер-ключ легко регенерировать.
Однако у шифрования с главным ключом есть один большой недостаток: если табличное пространство зашифровано с помощью tablespace_key, оно всегда остается зашифрованным тем же ключом.
Вращение отмычки здесь не поможет. Почему это недостаток? Мы знаем, что в MySQL есть ошибки, которые могут привести к внезапному сбою и созданию основного файла.
Поскольку файл дампа содержит дамп памяти сервера, может случиться так, что дамп будет содержать расшифрованный ключ табличного пространства.
Что еще хуже, расшифрованные ключи табличного пространства хранятся в памяти, которую можно переместить на диск.
Можно сказать, что это не недостаток, так как для доступа к этим файлам и разделу подкачки нужны root-права.
Да.
Но рут нужен только на время.
Как только кто-то получит доступ к расшифрованному ключу табличного пространства, он/она сможет продолжать использовать его для расшифровки данных, даже без привилегий root. Кроме того, диск можно украсть, а раздел подкачки/файлы ядра прочитать с помощью сторонних инструментов.
Цель TDE — сделать его нечитаемым, даже если диск украден.
В Сервер Percona для MySQL Табличное пространство можно повторно зашифровать с помощью новых сгенерированных ключей.
Эта функция называется потоками шифрования и на момент написания этой статьи все еще находится в стадии эксперимента.
Узнайте больше о курсе
Читать далее:
- Шифрование в MySQL: хранилище ключей
-
Реакция Яндекса На Сигнал Копипаста
19 Oct, 24 -
Amarok 1.4 На Базе Библиотеки Qt 4.
19 Oct, 24 -
Хотели Бы Вы Эмигрировать?
19 Oct, 24 -
Ключевые Моменты В Общении Менеджера Проекта
19 Oct, 24 -
Принцип Некомпетентности Лоуренса Дж. Питера
19 Oct, 24
