В очакване на началото на ново записване за курса продължаваме да публикуваме поредица от статии за криптиране в MySQL.
В предишната статия от тази серия () говорихме за хранилища за ключове. В тази статия ще разгледаме как се използва главният ключ и ще обсъдим предимствата и недостатъците на криптирането с плик.
Идеята зад криптирането с пликове е, че ключовете, използвани за криптиране (ключове за таблично пространство), са криптирани с друг ключ (главния ключ). Ключовете за таблично пространство всъщност се използват за криптиране на данни. Графично може да се представи така:
Главният ключ е в хранилището за ключове, а ключовете за таблично пространство са в заглавките на шифрованите таблични пространства (на страница 0 от табличното пространство).
На снимката по-горе:
Таблица A е шифрована с ключ 1 (Ключ 1). Ключ 1 е шифрован с помощта на главния ключ и се съхранява шифрован в заглавката на таблица A.
Таблица B е шифрована с ключ 2 (Ключ 2). Ключ 2 е шифрован с помощта на ключа за маскиране и се съхранява шифрован в заглавката на таблица B.
И така нататък.
Когато сървърът трябва да декриптира таблица A, той получава главния ключ от хранилището, чете криптиран ключ 1 от заглавката на таблица A и декриптира ключ 1. Декриптираният ключ 1 се кешира в паметта на сървъра и се използва за декриптиране на таблица A .
InnoDB
В InnoDB действителното криптиране и декриптиране се извършва на I/O ниво. Това означава, че страницата е криптирана точно преди да бъде заредена на диска и декриптирана веднага след като бъде прочетена от диска.
В InnoDB криптирането работи само на ниво таблично пространство. И по подразбиране всички таблици се създават в отделни таблични пространства (). С други думи, създава се таблично пространство, което може да съдържа само една таблица. Въпреки че можете да създавате таблици и в основното таблично пространство (). Но във всеки случай таблицата винаги е в някакво таблично пространство. И тъй като криптирането се извършва на ниво таблично пространство, то е или напълно криптирано, или не. Това означава, че е невъзможно да се шифрова само част от таблиците в основното таблично пространство.
Ако по някаква причина сте деактивирали файл за таблица, тогава всички таблици се създават в системното таблично пространство. IN можете да шифровате табличното пространство на системата с помощта на променливата innodbсистаблично пространствокриптиране или използване на нишки за криптиране, но това все още е експериментална функция. MySQL няма това.
Преди да продължим, трябва да разгледаме структурата на ID на главния ключ. Състои се от UUID, KEYID и префикс "INNODBKey". Изглежда така: INNODBKey-UUID-KEYДОКУМЕНТ ЗА САМОЛИЧНОСТ.
UUID е uuid на сървъра с шифрованото таблично пространство. КЛЮЧID е просто постоянно нарастваща стойност. Когато създавате главния ключ KEY за първи пътID е 1. По време на ротация на ключ, когато се създава нов главен ключ, KEYID = 2 и така нататък. Ще говорим повече за ротацията на главния ключ в следващите статии от тази серия.
След като вече знаем как изглежда идентификаторът на главния ключ, нека да разгледаме шифрованата заглавка на табличното пространство. Когато таблично пространство е шифровано, информацията за шифроване се добавя към заглавката. Изглежда така:
KEY ID е KEYID от ID на главния ключ, който вече обсъдихме. UUID е uuid на сървъра и се използва също в идентификатора на главния ключ. TABLESPACE KEY - ключ за таблично пространство, който се състои от 256 бита, произволно генериран от сървъра. Инициализиращият вектор (IV, инициализационен вектор) също се състои от 256 произволно генерирани бита (въпреки че трябва да е 128 бита). IV се използва за инициализиране на AES криптиране и декриптиране (от 256 бита се използват само 128). В края има CRC32 контролна сума за TABLESPACE KEY и IV.
През цялото това време малко опростявах, като казвах, че заглавката съдържа шифрования ключ на табличното пространство. Всъщност ключът на табличното пространство и векторът за инициализация се съхраняват и криптират заедно с помощта на главния ключ. Не забравяйте, че преди ключът за таблично пространство и векторът за инициализация да бъдат криптирани, CRC32 се изчислява за тях.
Защо е необходим CRC32?
С две думи, за да се уверите, че основният ключ е валиден. След декриптиране на ключа за таблично пространство и вектора за инициализация се изчислява контролна сума и се сравнява с CRC32, съхранен в заглавката. Ако контролните суми съвпадат, тогава имаме правилния главен ключ и ключ за таблично пространство. В противен случай табличното пространство се маркира като липсващо (все още не можем да го дешифрираме).
Може да попитате: в кой момент се извършва проверката на ключовете? Отговорът е, когато сървърът стартира. Сървър с криптирани таблици/таблични пространства чете UUID, KEY при стартиранеID от заглавката и генерира ID на главния ключ. След това получава необходимия главен ключ от ключодържателя, декриптира ключа за таблично пространство и проверява контролната сума. Още веднъж, ако контролната сума съвпада, тогава всичко е наред, не - табличното пространство е маркирано като липсващо.
Ако сте прочели последната статия от тази серия (), тогава може би не забравяйте, че когато използвате сървърно хранилище за ключове, сървърът получава само списък с идентификатори на ключове при стартиране, по-точно идентификатор на ключ и идентификатор на потребител, тъй като тази двойка уникално идентифицира ключа. Това, което казвам сега, е, че сървърът, при стартиране, получава всички ключове, от които се нуждае, за да провери дали ключовете на табличното пространство могат да бъдат дешифрирани. Така че защо при инициализиране, в случай на съхранение на сървър, се зарежда само ключid и потребителid, а не всички ключове? Защото може да не ви трябват всички ключове. Това се дължи главно на ротацията на главния ключ. Когато главният ключ се завърти в трезора, се създава нов главен ключ, но старите ключове не се изтриват. По този начин може да имате много ключове в хранилището за ключове на сървъра, които не са необходими на сървъра и следователно не се извличат при стартиране на сървъра.
Време е да поговорим малко за плюсовете и минусите на криптирането с главен ключ. Най-голямото предимство е, че имате нужда само от един ключ за криптиране (главния ключ), който ще се съхранява отделно от вашите криптирани данни. Това прави стартирането на сървъра бързо и съхранението малко, което го прави лесен за управление. Освен това единственият главен ключ е лесен за регенериране.
Криптирането с главен ключ обаче има един голям недостатък: след като табличното пространство е криптирано с tablespace_key, то винаги остава криптирано със същия ключ. Завъртането на главния ключ не помага тук. Защо това е недостатък? Знаем, че MySQL има грешки, които могат да доведат до срив и създаване на основен файл. Тъй като основният файл съдържа дъмп на паметта на сървъра, може да се случи дъмпът да съдържа декриптирания ключ за таблично пространство. Дори по-лошо, декриптираните ключове за таблично пространство се съхраняват в паметта, която може да бъде разменена на диск. Можете да кажете, че това не е недостатък, тъй като имате нужда от root права за достъп до тези файлове и суап дяла. да Но root е необходим само за известно време. След като някой има достъп до дешифрирания ключ за таблично пространство, той/тя може да продължи да го използва за декриптиране на данни, дори без root достъп. В допълнение, дискът може да бъде откраднат, а суап / основните файлове могат да бъдат прочетени с помощта на инструменти на трети страни. Целта на TDE е да го направи нечетим дори ако дискът бъде откраднат. IN Възможно е повторно шифроване на табличното пространство с нови генерирани ключове. Тази функция се нарича нишки за криптиране и все още е експериментална към момента на писане.
Прочетете още:
Източник: www.habr.com
