🥇MySQL жүйесінде шифрлау: Негізгі кілтті пайдалану

Курсқа жаңа қабылдаудың басталуын күтумен «Дерекқор» біз MySQL шифрлау туралы мақалалар сериясын жариялауды жалғастырамыз.

Осы сериядағы алдыңғы мақалада (MySQL жүйесінде шифрлау: Кілттер қоймасы) біз кілт қоймалары туралы сөйлестік. Бұл мақалада біз негізгі кілттің қалай қолданылатынын қарастырамыз және конвертті шифрлаудың артықшылықтары мен кемшіліктерін талқылаймыз.

Конвертті шифрлаудың идеясы шифрлау үшін пайдаланылатын кілттер (кесте кеңістігі кілттері) басқа кілтпен (басты кілт) шифрланады. Кесте кеңістігі кілттері шын мәнінде деректерді шифрлау үшін қолданылады. Графикалық түрде оны келесідей көрсетуге болады:

Басты кілт кілттерде, ал кесте кеңістігінің кілттері шифрланған кесте кеңістігінің тақырыптарында (кесте кеңістігінің 0-бетінде) орналасқан.

Жоғарыдағы суретте:

А кестесі 1-кілтпен шифрланған (1-кілт). 1-кілт басты кілт арқылы шифрланады және А кестесінің тақырыбында шифрланған түрде сақталады.
В кестесі 2 кілтімен шифрланған. 2-кілт басты кілт (маскер кілті) арқылы шифрланады және В кестесінің тақырыбында шифрланған түрде сақталады.
Тағыда басқа.

Серверге А кестесінің шифрын ашу қажет болғанда, ол негізгі кілтті жадтан шығарып алады, А кестесінің тақырыбынан шифрланған кілт 1-ді оқиды және 1-ші кілттің шифрын шешеді. Шифры ашылған кілт 1 сервер жадында кэштеледі және А кестесінің шифрын ашу үшін пайдаланылады. .

InnoDB

InnoDB жүйесінде нақты шифрлау және шифрды шешу енгізу/шығару деңгейінде орындалады. Яғни, бет дискіге тазартылғанға дейін шифрланады және дискіден оқылған соң бірден шифры ашылады.

InnoDB жүйесінде шифрлау тек кесте кеңістігі деңгейінде жұмыс істейді. Әдепкі бойынша барлық кестелер бөлек кесте кеңістігінде жасалады (кесте кеңістігі үшін файл). Басқаша айтқанда, тек бір кестеден тұратын кесте кеңістігі жасалады. Негізгі кесте кеңістігінде де кестелер жасауға болады (жалпы кесте кеңістігі). Бірақ кез келген жағдайда кесте әрқашан кейбір кесте кеңістігінде орналасады. Ал шифрлау кесте кеңістігі деңгейінде жүзеге асырылатындықтан, ол толығымен шифрланған немесе шифрланған емес. Яғни, негізгі кесте кеңістігіндегі кестелердің бір бөлігін ғана шифрлау мүмкін емес.

Егер қандай да бір себептермен сізде әр кестеге файл өшірілген болса, онда барлық кестелер жүйелік кесте кеңістігінде жасалады. IN MySQL үшін Percona сервері innodb айнымалысы арқылы жүйелік кесте кеңістігін шифрлай аласызжүйекесте кеңістігішифрлау немесе шифрлау ағындарын пайдалану, бірақ бұл әлі де эксперименттік мүмкіндік. MySQL-де бұл жоқ.

Әрі қарай қозғалмас бұрын, басты кілт идентификаторының құрылымын қарастыруымыз керек. Ол UUID, KEY тұрадыID және "INNODBKey" префиксі. Ол келесідей көрінеді: INNODBKey-UUID-KEYЖеке куәлік.

UUID - шифрланған кесте кеңістігі бар сервердің uuid коды. КілтИдентификатор - бұл үнемі өсіп келе жатқан мән. Басты кілт KEY бірінші рет жасағандаИдентификатор – 1. Кілттерді айналдыру кезінде, жаңа басты кілт жасалғанда, KEYID = 2 және т.б. Басты кілттерді айналдыру туралы толығырақ осы сериядағы келесі мақалаларда айтатын боламыз.

Енді біз негізгі кілт идентификаторының қандай болатынын білеміз, шифрланған кесте кеңістігінің тақырыбын қарастырайық. Кесте кеңістігі шифрланған кезде шифрлау ақпараты тақырыпқа қосылады. Бұл келесідей көрінеді:

KEY ID - KEYБіз бұрын талқылаған басты кілт идентификаторының идентификаторы. UUID - сервердің uuid коды, ол негізгі кілт идентификаторында да қолданылады. TABLESPACE KEY – сервермен кездейсоқ құрылған 256 биттен тұратын кесте кеңістігі кілті. Инициализация векторы (IV) да кездейсоқ құрылған 256 биттен тұрады (бірақ ол 128 бит болуы керек). IV AES шифрлауын және шифрын шешуді инициализациялау үшін қолданылады (256 биттен тек 128 ғана пайдаланылады). Соңында TABLESPACE KEY және IV үшін CRC32 бақылау сомасы бар.

Осы уақыт бойы мен тақырыпта кесте кеңістігінің шифрланған кілті бар екенін айтып, аздап жеңілдедім. Іс жүзінде кесте кеңістігінің кілті мен инициализация векторы басты кілт арқылы бірге сақталады және шифрланады. Кесте кеңістігінің кілтін және инициализация векторын шифрлау алдында олар үшін CRC32 есептелетінін есте сақтаңыз.

CRC32 не үшін қажет?

Бір сөзбен айтқанда, басты кілттің жарамдылығын қамтамасыз ету үшін. Кесте кеңістігі кілті мен инициализация векторының шифрын шешкеннен кейін бақылау сомасы есептеледі және тақырыпта сақталған CRC32-мен салыстырылады. Егер бақылау сомасы сәйкес келсе, бізде дұрыс негізгі кілт пен кесте кеңістігінің кілті бар. Әйтпесе, кесте кеңістігі жоқ деп белгіленеді (бәрібір біз оның шифрын шеше алмаймыз).

Сіз сұрақ қоюыңыз мүмкін: кілтті тексеру қай уақытта жүзеге асырылады? Жауап сервер іске қосылғанда. Шифрланған кестелері/кесте кеңістіктері бар сервер іске қосу кезінде UUID, KEY деп оқидыТақырыптағы идентификатор және негізгі кілт идентификаторын жасайды. Содан кейін ол кілттік сақинадан қажетті басты кілтті алады, кесте кеңістігінің кілтін ашады және бақылау сомасын тексереді. Тағы да, егер бақылау сомасы сәйкес келсе, онда бәрі жақсы, егер жоқ болса, кесте кеңістігі жоқ деп белгіленеді.

Егер сіз осы сериядағы алдыңғы мақаланы оқысаңыз (MySQL жүйесінде шифрлау: Кілттер қоймасы), серверге негізделген кілттер қоймасын пайдаланған кезде сервер іске қосылғанда тек кілт идентификаторларының тізімін, дәлірек айтсақ, кілт идентификаторы мен пайдаланушы идентификаторын алатынын еске түсіре аласыз, өйткені бұл жұп кілтті бірегей түрде анықтайды. Енді мен сервер іске қосылғанда, ол кесте кеңістігі кілттерінің шифрын шеше алатынын тексеру үшін барлық кілттерді алатынын айтамын. Неліктен инициализация кезінде, серверді сақтау жағдайында тек кілт жүктеледіидентификатор және пайдаланушыid, және барлық кілттер емес пе? Өйткені сізге барлық кілттер қажет болмауы мүмкін. Бұл негізінен басты кілттің айналуына байланысты. Негізгі кілт айналдырылған кезде қоймада жаңа басты кілт жасалады, бірақ ескі кілттер жойылмайды. Осылайша, сервер кілттер қоймасында серверге қажет емес, сондықтан сервер іске қосылғанда алынбайтын көптеген кілттер болуы мүмкін.

Негізгі кілтті шифрлаудың артықшылықтары мен кемшіліктері туралы аздап айтудың уақыты келді. Ең үлкен артықшылығы - шифрланған деректеріңізден бөлек сақталатын бір ғана шифрлау кілті (басты кілт) қажет. Бұл серверді іске қосуды жылдам және жадты аз етеді, бұл басқаруды жеңілдетеді. Сондай-ақ жалғыз басты кілтті қалпына келтіру оңай.

Дегенмен, басты кілтті шифрлаудың бір үлкен кемшілігі бар: кесте кеңістігі tablespace_key арқылы шифрланғанда, ол әрқашан бірдей кілтпен шифрланған болып қалады. Негізгі кілтті бұру бұл жерде көмектеспейді. Неліктен бұл кемшілік? Біз MySQL-де кенеттен бұзылуға және негізгі файлды жасауға әкелетін қателер бар екенін білеміз. Негізгі файлда сервер жады демпі болғандықтан, дампте шифры шешілген кесте кеңістігі кілті болуы мүмкін. Ең нашарлау үшін, шифры шешілген кесте кеңістігінің кілттері жадта сақталады, оларды дискіге ауыстыруға болады. Сіз бұл кемшілік емес деп айта аласыз, өйткені сізге осы файлдарға және своп бөліміне кіру үшін түбірлік құқықтар қажет. Иә. Бірақ тамыр біраз уақытқа ғана қажет. Біреуде шифры шешілген кесте кеңістігінің кілтіне қол жеткізгеннен кейін, ол оны деректер шифрын шешу үшін, тіпті түбірлік артықшылықтарсыз пайдалануды жалғастыра алады. Сонымен қатар, диск ұрлануы мүмкін және своп бөлімі/негізгі файлдар үшінші тарап құралдарының көмегімен оқуға болады. TDE мақсаты - диск ұрланса да оны оқылмайтын ету. IN MySQL үшін Percona сервері Жаңа жасалған кілттермен кесте кеңістігін қайта шифрлауға болады. Бұл мүмкіндік шифрлау ағындары деп аталады және жазу кезінде әлі де эксперименталды.

Курс туралы көбірек біліңіз