Во пресрет на почеток на нови уписи за курсот продолжуваме да објавуваме серија написи за шифрирање во MySQL.
Во претходната статија од оваа серија () разговаравме за сводовите за клучеви. Во оваа статија, ќе погледнеме како се користи главниот клуч и ќе разговараме за предностите и недостатоците на шифрирањето на пликовите.
Идејата зад шифрирањето на пликовите е дека клучевите што се користат за шифрирање (клучевите на табелата) се шифрираат со друг клуч (главниот клуч). Клучевите Tablespace всушност се користат за шифрирање на податоците. Графички може да се претстави вака:
Главниот клуч се наоѓа во приклучокот за клучеви, а клучевите на табелата се наоѓаат во шифрираните заглавија на табеларниот простор (на страница 0 од просторот за маса).
На сликата погоре:
Табелата А е шифрирана со клучот 1 (клуч 1). Клучот 1 е шифриран со помош на главниот клуч и се чува шифриран во заглавието на табелата А.
Табелата Б е шифрирана со клучот 2. Клучот 2 е шифриран со помош на главниот клуч (клуч за маскирање) и се чува шифриран во заглавието на табелата Б.
И така натаму.
Кога серверот треба да ја дешифрира табелата А, тој го враќа главниот клуч од складиштето, го чита шифрираниот клуч 1 од заглавието на табелата А и го дешифрира клучот 1. Дешифрираниот клуч 1 е кеширан во меморијата на серверот и се користи за дешифрирање на табелата А .
InnoDB
Во InnoDB, вистинското шифрирање и дешифрирање се врши на I/O слојот. Односно, страницата е шифрирана непосредно пред да се префрли на дискот и се дешифрира веднаш откако ќе се прочита од дискот.
Во InnoDB, шифрирањето работи само на ниво на маса. И по дифолт, сите табели се креираат во посебни табели (). Со други зборови, се создава простор за маса што може да содржи само една табела. Иако можете да креирате табели и во главниот простор за маса (). Но, во секој случај, табелата секогаш се наоѓа во одреден простор за маса. И бидејќи шифрирањето се врши на ниво на маса, тоа е или целосно шифрирано или не е. Односно, невозможно е да се шифрира само дел од табелите во главниот простор на табелата.
Ако поради некоја причина сте оневозможени датотека-по-табела, тогаш сите табели се креираат внатре во системската маса. ВО можете да го шифрирате системскиот табеларен простор користејќи ја променливата innodbСиспростор за масашифрирајте или користејќи нишки за шифрирање, но ова е сепак експериментална карактеристика. MySQL го нема ова.
Пред да продолжиме понатаму, треба да ја разгледаме структурата на ID на главниот клуч. Се состои од UUID, KEYИД и префикс „INNODBKey“. Изгледа вака: INNODBKey-UUID-KEYИД.
UUID е uuid на серверот со шифрирана маса. КЛУЧИД е едноставно постојано зголемување на вредноста. Кога го креирате главниот клуч KEY за прв патID е 1. За време на ротирање на копчињата, кога се креира нов главен клуч, KEYID = 2 и така натаму. Ќе зборуваме повеќе за главната ротација на копчињата во следните написи од оваа серија.
Сега кога знаеме како изгледа идентификаторот на главниот клуч, да го погледнеме заглавието на шифрираната маса. Кога просторот за маса е шифриран, информациите за шифрирање се додаваат во заглавието. Изгледа вака:
KEY ID е КЛУЧЕНИД од идентификаторот на главниот клуч за кој веќе разговаравме. UUID е uuid на серверот, кој исто така се користи во идентификаторот на главниот клуч. TABLESPACE KEY - клуч за простор на табелата, кој се состои од 256 бита случајно генерирани од серверот. Векторот за иницијализација (IV) исто така се состои од 256 случајно генерирани бита (иако треба да биде 128 бита). IV се користи за иницијализирање на AES шифрирање и дешифрирање (од 256 бита, се користат само 128). На крајот има контролна сума CRC32 за TABLESPACE KEY и IV.
Сето ова време малку поедноставував велејќи дека заглавието го содржи шифрираниот клуч на просторот за маса. Всушност, клучот tablespace и векторот за иницијализација се складираат и шифрираат заедно со помош на главниот клуч. Запомнете дека пред да го шифрирате клучот на табелата и иницијализацијата на векторот, за нив се пресметува CRC32.
Зошто е потребен CRC32?
Накратко, за да се обезбеди валидноста на главниот клуч. По дешифрирањето на клучот за табеларно место и векторот за иницијализација, контролната сума се пресметува и се споредува со CRC32 зачувана во заглавието. Ако контролните суми се совпаѓаат, тогаш го имаме точниот главен клуч и клучот за табеларен простор. Во спротивно, просторот за маса е означен како исчезнат (во секој случај нема да можеме да го дешифрираме).
Може да прашате: во кој момент се врши проверката на клучот? Одговорот е кога ќе стартува серверот. Сервер со шифрирани табели/простори на маса чита UUID, KEY при стартувањеID од заглавието и го генерира главниот ID на клучот. Потоа го добива потребниот главен клуч од приклучокот за клучеви, го дешифрира клучот на табелата и ја потврдува контролната сума. Уште еднаш, ако контролната сума се совпаѓа, тогаш сè е во ред, ако не, просторот за маса е означен како исчезнат.
Ако ја прочитате претходната статија од оваа серија (), тогаш можеби се сеќавате дека кога користите продавница за клучеви заснована на сервер, серверот при стартувањето добива само листа на идентификатори на клучеви, или подобро кажано, идентификатор на клучот и корисничка идентификација, бидејќи овој пар уникатно го идентификува клучот. Сега велам дека кога ќе се стартува серверот, ги добива сите клучеви што му се потребни за да провери дали може да ги дешифрира клучевите на табелата. Па зошто за време на иницијализацијата, во случај на складирање на серверот, се вчитува само клучотID и корисникid, а не сите клучеви? Затоа што можеби нема да ви требаат сите клучеви. Ова главно се должи на главната ротација на копчињата. Кога се ротира главниот клуч, се создава нов главен клуч во сефот, но старите клучеви не се бришат. Така, може да имате многу клучеви во продавницата за копчиња на серверот што не му се потребни на серверот и затоа не се преземаат кога серверот ќе се стартува.
Време е малку да зборуваме за добрите и лошите страни на шифрирањето на главниот клуч. Најголемата предност е што ви треба само еден клуч за шифрирање (главниот клуч), кој ќе се чува одделно од вашите шифрирани податоци. Ова го прави брзото стартување на серверот, а малото складирање, што го прави лесен за управување. Исто така, единствениот главен клуч лесно се регенерира.
Како и да е, шифрирањето на главниот клуч има еден голем недостаток: штом просторот за маса е шифриран со tablespace_key, тој секогаш останува шифриран со истиот клуч. Вртењето на главниот клуч не помага овде. Зошто е ова недостаток? Знаеме дека MySQL има грешки што може да доведат до ненадеен пад и создавање на основна датотека. Бидејќи основната датотека содржи складиште за меморија на серверот, може да се случи депонија да го содржи дешифрираниот клуч за табела простор. За да бидат работите уште полоши, дешифрираните клучеви на масата се зачувани во меморијата, која може да се замени на диск. Може да кажете дека ова не е недостаток бидејќи ви требаат права на root за пристап до овие датотеки и партицијата за размена. Да. Но, root е потребен само некое време. Откако некој ќе има пристап до дешифрираниот клуч на табелата, тој/таа може да продолжи да го користи за дешифрирање податоци, дури и без права на root. Дополнително, дискот може да биде украден, а swap партицијата/јадрените датотеки може да се читаат со помош на алатки од трети страни. Целта на TDE е да го направи нечитлив дури и ако дискот е украден. ВО Можно е повторно да се шифрира просторот на табелата со нови генерирани клучеви. Оваа карактеристика се нарекува нишки за шифрирање и сè уште е експериментална во моментот на пишување.
Прочитај повеќе:
Извор: www.habr.com
