В очакване на началото на ново записване за курса продължаваме да публикуваме поредица от статии за криптиране в MySQL.
В предишната статия от тази поредица обсъдихме . Днес, въз основа на знанията, получени по-рано, нека да разгледаме въртенето на основните клавиши.
Ротацията на главния ключ включва генериране на нов главен ключ и повторно шифроване на ключовете за таблично пространство (които се съхраняват в заглавките на табличното пространство) с този нов ключ.
Нека си припомним как изглежда заглавката на криптирано таблично пространство:
От предишната статия знаем, че сървърът чете заглавките на всички криптирани таблични пространства при стартиране и запомня най-големия KEY ID. Например, ако имаме три таблици с KEYID = 3 и една маса с КЛЮЧID = 4, тогава максималният ID на ключ ще бъде 4. Нека наречем това KEY ID - MAX KEY ID.
Как работи ротацията на главния ключ
1. Потребителят изпълнява ALTER INNODB MASTER KEY.
2. Сървърът изисква ключодържателя да генерира нов главен ключ със сървърния UUID и KEYID равен на едно плюс MAXKEYДОКУМЕНТ ЗА САМОЛИЧНОСТ. Така че получаваме идентификатор на главен ключ, равен на INNODBКЛЮЧ-UUID-(МАКСKEYID + 1). При успешно генериране на главния ключ, MAX KEY ID се увеличава с единица (т.е. MAXKEYID=МАКСKEYID + 1).
3. Сървърът сканира всички таблични пространства, криптирани с главния ключ, и за всяко таблично пространство:
-
криптира ключа за таблично пространство с новия главен ключ;
-
актуализира идентификатора на ключа до новия MAXKEYДОКУМЕНТ ЗА САМОЛИЧНОСТ;
-
ако UUID е различен от UUID на сървъра, актуализирайте UUID на сървъра.
Както знаем, ИД на главния ключ, използван за дешифриране на таблица, се състои от UUID и ИД на КЛЮЧ, прочетени от заглавката на табличното пространство. Това, което правим сега, е да актуализираме тази информация в заглавката за криптиране на таблично пространство, така че сървърът да получи правилния главен ключ.
Ако имаме таблични пространства от различни местоположения, като например различни резервни копия, тогава те може да използват различни главни ключове. Всички тези главни ключове ще трябва да бъдат извлечени от хранилището при стартиране на сървъра. Това може да забави стартирането на сървъра, особено ако се използва хранилище за ключове от страна на сървъра. С ротацията на главния ключ ние повторно шифроваме ключовете за таблични пространства с един главен ключ, който е еднакъв за всички таблични пространства. Сега сървърът трябва да получи само един главен ключ при стартиране.
Това, разбира се, е само приятен страничен ефект. Основната цел на ротацията на главния ключ е да направи нашия сървър по-сигурен. В случай, че главният ключ по някакъв начин е бил откраднат от трезора (например от сървъра на Vault), е възможно да се генерира нов главен ключ и да се шифроват отново ключовете за таблично пространство, като се обезсили откраднатия ключ. Ние сме в безопасност...почти.
В предишна статия говорих за това как след като ключ за таблично пространство бъде откраднат, трета страна може да го използва за дешифриране на данни. При условие, че има достъп до нашия диск. Ако главният ключ бъде откраднат и имате достъп до шифрованите данни, можете да използвате откраднатия главен ключ, за да декриптирате ключа за таблично пространство и да получите декриптираните данни. Както можете да видите, завъртането на главния ключ не помага в този случай. Ние повторно шифроваме ключа за таблично пространство с новия главен ключ, но действителният ключ, използван за шифроване/декриптиране на данните, остава същият. Следователно "хакерът" може да продължи да го използва за дешифриране на данните. По-рано намекнах за това може да извърши истинско повторно криптиране на таблично пространство, а не просто повторно криптиране на ключ за таблично пространство. Тази функция се нарича нишки за криптиране. Тази функционалност обаче все още е експериментална в момента.
Завъртането на главния ключ е полезно, когато главният ключ е откраднат, но няма начин нападателят да го използва и да декриптира ключовете на табличното пространство.
Прочетете още:
Източник: www.habr.com