Курска жаңы кабыл алуунун башталышын күтүү менен биз MySQLде шифрлөө жөнүндө бир катар макалаларды жарыялоону улантабыз.
Бул сериядагы мурунку макалада () биз ачкыч дүкөндөрү жөнүндө сүйлөштүк. Бул макалада биз башкы ачкыч кандайча колдонуларын карап чыгабыз жана конвертти шифрлөөнүн артыкчылыктары менен кемчиликтерин талкуулайбыз.
Конвертти шифрлөөнүн идеясы - шифрлөө үчүн колдонулган ачкычтар (таблица мейкиндиги ачкычтары) башка ачкыч (башкы ачкыч) менен шифрленген. Tablespace ачкычтары чындыгында маалыматтарды шифрлөө үчүн колдонулат. Графикалык түрдө бул төмөнкүчө чагылдырууга болот:
Башкы ачкыч ачкычтар сактагычында, ал эми таблица мейкиндигинин ачкычтары шифрленген таблица мейкиндиктеринин баштарында (таблица мейкиндигинин 0-бетинде).
Жогорудагы сүрөттө:
-
А таблицасы 1-ачкыч менен шифрленген (1-ачкыч). 1-ачкыч башкы ачкычтын жардамы менен шифрленген жана А таблицасынын баш жагында шифрленген бойдон сакталат.
-
В таблицасы 2-ачкыч менен шифрленген (2-ачкыч). 2 ачкыч маскар ачкычынын жардамы менен шифрленген жана В таблицасынын баш жагында шифрленген бойдон сакталат.
-
Ал эми чындыгында андай эмес.
Сервер А таблицасынын шифрин чечиши керек болгондо, ал дүкөндөн башкы ачкычты алат, А таблицанын баш жагындагы 1-шифрленген ачкычты окуйт жана 1-ачкычтын шифрин чечет. Шифрленген ачкыч 1 сервердин эс тутумунда кэштелет жана А таблицасын чечмелөө үчүн колдонулат. .
InnoDB
InnoDBде иш жүзүндөгү шифрлөө жана чечмелөө I/O деңгээлинде ишке ашырылат. Башкача айтканда, барак дискке куюлганга чейин шифрленген жана дисктен окугандан кийин дароо чечмеленет.
InnoDBде шифрлөө стол мейкиндигинде гана иштейт. Жана демейки боюнча бардык таблицалар өзүнчө таблицаларда түзүлөт (). Башкача айтканда, бир гана таблицаны камтый турган таблица мейкиндиги түзүлөт. Негизги стол мейкиндигинде да таблицаларды түзө аласыз (). Бирок, кандай болгон күндө да, үстөл ар дайым кандайдыр бир стол мейкиндигинде болот. Жана шифрлөө стол мейкиндигинде жасалгандыктан, ал толугу менен шифрленген же жок. Башкача айтканда, сиз негизги таблица мейкиндигинде таблицалардын бир бөлүгүн гана шифрлей албайсыз.
Эгер кандайдыр бир себептерден улам сизде файл-таблица өчүрүлгөн болсо, анда бардык таблицалар системанын таблица мейкиндигинде түзүлөт. IN innodb өзгөрмөсүн колдонуп системанын таблица мейкиндигин шифрлей аласызSYSстол мейкиндигишифрлөө же шифрлөө жиптерин колдонуу, бирок бул дагы эле эксперименталдык өзгөчөлүк. MySQLде бул жок.
Улантуудан мурун, башкы ачкыч идентификаторунун структурасын карап чыгышыбыз керек. Ал UUID, KEY туратID жана "INNODBKey" префикси. Бул төмөнкүдөй көрүнөт: INNODBKey-UUID-KEYID.
UUID - шифрленген стол мейкиндиги бар сервердин uuid. ачкычID - бул барган сайын өсүп жаткан баалуулук. Сиз биринчи жолу башкы ачкычты түзгөндөID – 1. Ачкычты айландыруу учурунда, жаңы башкы ачкыч түзүлгөндө, КАЙТID = 2 жана башкалар. Башкы ачкычты айландыруу жөнүндө биз бул сериянын кийинки макалаларында көбүрөөк сүйлөшөбүз.
Эми биз башкы ачкыч идентификатору кандай экенин билгенден кийин, шифрленген таблица мейкиндигинин башын карап көрөлү. Таблица мейкиндиги шифрленгенде, шифрлөө маалыматы баш сөзгө кошулат. Бул төмөнкүдөй көрүнөт:
KEYID - АЧКЫЧБиз буга чейин талкуулаган башкы ачкычтын идентификатору. UUID сервердин uuid болуп саналат жана ошондой эле башкы ачкыч идентификаторунда колдонулат. TABLESPACE АЧКЫЧЫ – сервер тарабынан туш келди түзүлгөн 256 биттен турган таблица мейкиндиги ачкычы. Инициализация вектору (IV, инициализация вектору) да туш келди түзүлгөн 256 биттен турат (бирок ал 128 бит болушу керек). IV AES шифрлөө жана чечмелөө үчүн колдонулат (256 биттин ичинен 128и гана колдонулат). Аягында TABLESPACE KEY жана IV үчүн CRC32 текшерүү суммасы бар.
Ушул убакыттын баарында мен темада шифрленген стол мейкиндигинин ачкычы бар экенин айтып, бир аз жөнөкөйлөштүрдүм. Чынында, стол мейкиндигинин ачкычы жана инициализация вектору башкы ачкычтын жардамы менен бирге сакталат жана шифрленет. Эсиңизде болсун, стол мейкиндигинин ачкычы жана инициализация вектору шифрленгенге чейин, алар үчүн CRC32 эсептелинет.
Эмне үчүн CRC32 керек?
Кыскача айтканда, негизги ачкыч жарактуу экенине ынануу үчүн. Таблица мейкиндигинин ачкычын жана инициализация векторун чечмелегенден кийин текшерүү суммасы эсептелет жана баш маалыматта сакталган CRC32 менен салыштырылат. Эгерде текшерүү суммалары дал келсе, анда бизде туура башкы ачкыч жана таблица мейкиндиги ачкычы бар. Болбосо, стол мейкиндиги жок деп белгиленет (биз дагы эле анын шифрин чече албайбыз).
Сиз сурасаңыз болот: баскычтарды текшерүү кайсы учурда жүргүзүлөт? Жооп сервер качан иштей баштайт. Шифрленген таблицалар/таблица мейкиндиктери бар сервер ишке киргенде UUID, KEY окуйтаталышынан ID жана негизги ачкыч ID жаратат. Андан кийин ал ачкычтан керектүү башкы ачкычты алат, таблица мейкиндигинин ачкычын чечмелейт жана текшерүү суммасын текшерет. Дагы бир жолу, текшерүү суммасы дал келсе, анда баары өз ордунда, жок - стол мейкиндиги жок деп белгиленет.
Эгер сиз бул сериядагы акыркы макаланы окусаңыз (), анда, балким, эсиңизде болсун, сервер ачкычтар дүкөнүн колдонууда сервер ишке киргенде гана ачкыч идентификаторлорунун тизмесин, тагыраак айтканда, ачкыч идентификаторун жана колдонуучунун идентификаторун алат, анткени бул жуп ачкычты уникалдуу түрдө аныктайт. Мен азыр айтып жаткан нерсе, сервер ишке киргенде, стол мейкиндигинин ачкычтарын чечмелөө мүмкүн экенин текшерүү үчүн бардык ачкычтарды алат. Эмне үчүн, инициализациялоодо, сервер сактагычында, ачкыч гана жүктөлөтid жана колдонуучуid жана бардык ачкычтар эмес? Анткени сизге бардык ачкычтар керек эмес. Бул негизинен башкы ачкычтын айлануусуна байланыштуу. Башкы ачкыч сейфте айландырылганда, жаңы башкы ачкыч түзүлөт, бирок эски ачкычтар жок кылынбайт. Ошентип, сервердин ачкыч кампасында серверге кереги жок, ошондуктан сервер башталганда алынбай турган көптөгөн ачкычтар болушу мүмкүн.
Мастер ачкычты колдонуу менен шифрлөөнүн артыкчылыктары жана кемчиликтери жөнүндө бир аз сүйлөшүүгө убакыт келди. Эң чоң артыкчылыгы - сизге бир гана шифрлөө ачкычы (башкы ачкыч) керек, ал сиздин шифрленген маалыматтарыңыздан өзүнчө сакталат. Бул серверди тез баштоону жана сактоону кичине кылып, башкарууну жеңилдетет. Жана ошондой эле жалгыз башкы ачкычты калыбына келтирүү оңой.
Бирок, башкы ачкыч шифрлөөнүн бир чоң кемчилиги бар: таблица мейкиндиги tablespace_key менен шифрленгенден кийин, ал ар дайым ошол эле ачкыч менен шифрленген бойдон калат. Бул жерде башкы баскычты айлантуу жардам бербейт. Эмне үчүн бул кемчилик? MySQLде анын бузулушуна жана негизги файлды түзүшүнө алып келе турган мүчүлүштүктөр бар экенин билебиз. Негизги файл сервердин эс тутумунун таштандысын камтыгандыктан, бул таштандыда шифрленген таблица мейкиндигинин ачкычын камтышы мүмкүн. Андан да жаманы, шифрленген стол мейкиндигинин ачкычтары эстутумда сакталат, аларды дискке алмаштырууга болот. Сиз бул кемчилик эмес деп айта аласыз, анткени бул файлдарга жана своп бөлүгүнө кирүү үчүн тамыр уруксаттары керек. Ооба. Бирок тамыр бир азга гана керек. Кимдир бирөө шифрленген таблица мейкиндигинин ачкычына кирүү мүмкүнчүлүгүнө ээ болгондон кийин, ал аны маалыматтын шифрин чечмелөө үчүн колдоно берет, ал тургай, тамырга кирүү мүмкүнчүлүгү жок. Мындан тышкары, диск уурдалышы мүмкүн, ал эми алмашуу / негизги файлдарды үчүнчү тараптын куралдары менен окууга болот. TDE максаты - диск уурдалып кетсе да, аны окулбай коюу. IN жаңы түзүлгөн ачкычтар менен стол мейкиндигин кайра шифрлөө мүмкүн. Бул өзгөчөлүк шифрлөө жиптери деп аталат жана бул жазуу учурунда дагы эле эксперименталдык.
Кененирээк:
Source: www.habr.com