В преддверии старта нового набора на курс продолжаем публиковать серию статей про шифрование в MySQL.
В предыдущей статье этой серии мы обсудили, . Сегодня, основываясь на полученных ранее знаниях, посмотрим на ротацию главных ключей.
Ротация главных ключей заключается в том, что генерируется новый главный ключ и этим новым ключом повторно шифруются ключи табличных пространств (которые хранятся в заголовках табличных пространств).
Давайте вспомним, как выглядит заголовок зашифрованного табличного пространства:
Из предыдущей статьи мы знаем, что сервер при запуске считывает заголовки всех зашифрованных табличных пространств и запоминает самый большой KEY ID. Например, если у нас есть три таблицы с KEYID = 3 и одна таблица с KEYID = 4, то максимальный идентификатор ключа будет равен 4. Давайте назовем этот KEY ID — MAX KEY ID.
Как работает ротация главного ключа
1. Пользователь выполняет ALTER INNODB MASTER KEY.
2. Сервер запрашивает в хранилище ключей (keyring) генерацию нового главного ключа с UUID сервера и KEYID, равным увеличенному на единицу MAXKEYID. Таким образом, мы получаем идентификатор главного ключа, равный INNODBKEY-UUID- (MAXKEYID + 1). При успешной генерации главного ключа MAX KEY ID увеличивается на единицу (т.е. MAXKEYID = MAXKEYID + 1).
3. Сервер просматривает все табличные пространства, зашифрованные с помощью главного ключа, и для каждого табличного пространства:
-
шифрует ключ табличного пространства новым главным ключом;
-
обновляет идентификатор ключа на новый MAXKEYID;
-
если UUID отличается от UUID сервера, то обновляет UUID сервера.
Как мы знаем, идентификатор главного ключа (Master Key ID), используемый для расшифровки таблицы, состоит из UUID и KEY ID, считанных из заголовка табличного пространства. Что мы делаем сейчас, так это обновляем эту информацию в заголовке шифрования табличного пространства, чтобы сервер получал правильный главный ключ.
Если у нас есть табличные пространства, полученные из разных мест, например, из разных резервных копий, то они могут использовать разные главные ключи. Все эти главные ключи необходимо будет получить из хранилища при запуске сервера. Это может замедлить запуск сервера, особенно если используется серверное хранилище ключей. С помощью ротации главного ключа мы повторно шифруем ключи табличных пространств одним главным ключом, одинаковым для всех табличных пространств. Теперь при запуске сервер должен получить только один главный ключ.
Это, конечно, лишь приятный побочный эффект. Главная цель ротации главных ключей — сделать наш сервер более безопасным. В случае если главный ключ был каким-либо образом украден из хранилища (например, из Vault Server), то можно сгенерировать новый главный ключ и повторно зашифровать ключи табличных пространств, сделав украденный ключ недействительным. Мы в безопасности… почти.
В предыдущей статье я говорил о том, что после кражи ключа табличного пространства третья сторона может использовать его для расшифровки данных. При условии, что есть доступ к нашему диску. В случае кражи главного ключа и наличия доступа к зашифрованным данным, можно использовать украденный главный ключ для расшифровки ключа табличного пространства и получить расшифрованные данные. Как видим, ротация главного ключа в этом случае не помогает. Мы повторно шифруем ключ табличного пространства новым главным ключом, но фактический ключ, используемый для шифрования / дешифрования данных, остается прежним. Поэтому «хакер» может и дальше использовать его для расшифровки данных. Ранее я намекал, что может выполнять настоящее повторное шифрование табличных пространств, а не только простое повторное шифрование ключа табличного пространства. Эта функция называется потоками шифрования (encryption threads). Однако на данный момент эта функциональность все еще экспериментальная.
Ротация главного ключа полезна, когда главный ключ украден, но у злоумышленника нет возможности его использовать и расшифровать ключи табличных пространств.
Читать ещё:
Источник: habr.com