🥇Шифриране в MySQL: ротация на Master Key

В навечерието на старта на новия набор курс «Бази данни» продължаваме с публикуването на серия статии за криптиране в MySQL.

В предишната статия от тази серия обсъдихме, как работи криптирането с главния ключ (Master Key). Днес, основавайки се на получените преди знания, ще разгледаме ротацията на главните ключове.

Ротацията на главните ключове се състои в това, че се генерира нов главен ключ и с него отново се криптират ключовете на таблиците (които са съхранени в заглавията на таблиците).

Нека си припомним как изглежда заглавието на криптирана таблица:

От предишната статия знаем, че сървърът при стартиране прочита заглавията на всички криптирани таблици и запомня най-голямото 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), можем да генерираме нов главен ключ и отново да шифроваме ключовете на таблиците, като направим откраднатия ключ невалиден. Ние сме в безопасност... почти.

В предишната статия говорих за това, че след кражба на ключа на таблицата трета страна може да го използва за декодиране на данни. При условие, че има достъп до нашия диск. В случай на кражба на главния ключ и достъп до шифрованите данни, може да се използва откраднатият главен ключ за декодиране на ключа на таблицата и получаване на декодирани данни. Както виждаме, ротацията на главния ключ в този случай не помага. Ние отново шифроваме ключа на таблицата с нов главен ключ, но действителният ключ, който се използва за шифроване / декодиране на данни, остава същият. Следователно "хакерът" може да продължи да го използва за декодиране на данни. По-рано намекнах, че Percona Server for MySQL може да извършва истинско повторно шифроване на таблиците, а не просто простото повторно шифроване на ключа на таблицата. Тази функция се нарича потоци на шифроване (encryption threads). Въпреки това, към момента тази функционалност все още е експериментална.

Ротацията на главния ключ е полезна, когато главният ключ е откраднат, но атакуващият няма възможност да го използва и декодира ключовете на таблиците.

Запишете се за безплатно демо-урок.