Напередодні старту нового набору на курс продовжуємо публікувати серію статей про шифрування 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