ProHoster > Блог > басқарма > MySQL жүйесінде шифрлау: Кілттер қоймасы

MySQL жүйесінде шифрлау: Кілттер қоймасы

Курсқа жаңа қабылдаудың басталуын күтумен «Дерекқор» Біз сізге пайдалы мақаланың аудармасын дайындадық.

MySQL жүйесінде шифрлау: Кілттер қоймасы

Transparent Data Encryption (TDE) пайда болды MySQL үшін Percona сервері және MySQL біраз уақыт. Бірақ сіз оның қақпақ астында қалай жұмыс істейтіні және TDE сіздің серверіңізге қандай әсер етуі мүмкін екендігі туралы ойландыңыз ба? Осы мақалалар сериясында TDE ішкі жүйеде қалай жұмыс істейтінін қарастырамыз. Кілттерді сақтаудан бастайық, өйткені бұл кез келген шифрлаудың жұмыс істеуі үшін қажет. Содан кейін MySQL/MySQL үшін Percona серверінде шифрлау қалай жұмыс істейтінін және MySQL үшін Percona серверінің қандай қосымша мүмкіндіктері бар екенін егжей-тегжейлі қарастырамыз.

MySQL кілттері

Keyring — серверге жергілікті файлдағы (keyring_file) немесе қашықтағы сервердегі (мысалы, HashiCorp Vault) кілттерді сұрауға, жасауға және жоюға мүмкіндік беретін плагиндер. Кілттерді іздеуді жылдамдату үшін әрқашан жергілікті жерде кэштеледі.

Плагиндерді екі санатқа бөлуге болады:

  • Жергілікті сақтау. Мысалы, жергілікті файл (біз оны файлға негізделген кілттер деп атаймыз).
  • Қашықтан сақтау. Мысалы, Vault Server (біз оны серверге негізделген кілттер деп атаймыз).

Бұл бөлу маңызды, себебі әр түрлі сақтау түрлері кілттерді сақтау және шығарып алу кезінде ғана емес, сонымен қатар оларды іске қосу кезінде де аздап басқаша әрекет етеді.

Файл жадын пайдаланған кезде, іске қосу кезінде жадтың барлық мазмұны кэшке жүктеледі: кілт идентификаторы, негізгі пайдаланушы, кілт түрі және кілттің өзі.

Сервер жағындағы дүкен жағдайында (мысалы, Vault сервері) іске қосу кезінде тек кілт идентификаторы мен негізгі пайдаланушы жүктеледі, сондықтан барлық кілттерді алу іске қосуды бәсеңдетпейді. Кілттер жалқау жүктеледі. Яғни, кілттің өзі Vault ішінен шын мәнінде қажет болғанда ғана жүктеледі. Жүктеп алынғаннан кейін кілт жадта кэштеледі, сондықтан оған болашақта Vault серверіне TLS қосылымдары арқылы қол жеткізу қажет емес. Әрі қарай, негізгі дүкенде қандай ақпарат бар екенін қарастырайық.

Негізгі ақпарат мыналарды қамтиды:

  • кілт идентификаторы — кілт идентификаторы, мысалы:
    INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
  • кілт түрі — қолданылатын шифрлау алгоритміне негізделген кілт түрі, мүмкін мәндер: «AES», «RSA» немесе «DSA».
  • кілт ұзындығы — байттағы кілт ұзындығы, AES: 16, 24 немесе 32, RSA 128, 256, 512 және DSA 128, 256 немесе 384.
  • пайдаланушы - кілттің иесі. Егер кілт жүйелік болса, мысалы, Негізгі кілт, онда бұл өріс бос болады. Егер кілт keyring_udf арқылы жасалса, онда бұл өріс кілттің иесін анықтайды.
  • кілттің өзі

Кілт жұп арқылы бірегей түрде анықталады: key_id, пайдаланушы.

Кілттерді сақтау мен жоюда да айырмашылықтар бар.

Файлды сақтау жылдамырақ. Сіз кілттер қоймасы файлдың кілтін бір рет жазады деп ойлауыңыз мүмкін, бірақ жоқ, бұл жерде тағы да көп нәрсе бар. Файл жадына өзгертулер енгізілгенде, алдымен барлық мазмұнның сақтық көшірмесі жасалады. Айталық, файл менің_ең үлкен_құпияларым деп аталады, содан кейін сақтық көшірме my_biggest_secrets.backup болады. Содан кейін кэш өзгертіледі (кілттер қосылады немесе жойылады) және бәрі сәтті болса, кэш файлға қалпына келтіріледі. Сирек жағдайларда, мысалы, сервер ақаулығы, сіз бұл сақтық көшірме файлын көре аласыз. Сақтық көшірме файлы кілттер келесі рет жүктелген кезде жойылады (әдетте сервер қайта іске қосылғаннан кейін).

Сервер қоймасында кілтті сақтау немесе жою кезінде сақтау орны MySQL серверіне «кілтті жіберу» / «кілтті жоюды сұрау» пәрмендерімен қосылуы керек.

Серверді іске қосу жылдамдығына оралайық. Іске қосу жылдамдығына қойманың өзі әсер ететіндігінен басқа, іске қосу кезінде қоймадан қанша кілтті алу керектігі туралы мәселе де бар. Әрине, бұл әсіресе серверді сақтау үшін маңызды. Іске қосу кезінде сервер шифрланған кестелер/кестелер кеңістігі үшін қандай кілт қажет екенін тексереді және жадтан кілтті сұрайды. Негізгі кілт шифрлауы бар «таза» серверде бір негізгі кілт болуы керек, оны сақтаудан шығарып алу керек. Дегенмен, мысалы, сақтық көшірме сервері негізгі серверден сақтық көшірмені қалпына келтіріп жатқанда, кілттердің көбірек саны қажет болуы мүмкін. Мұндай жағдайларда басты кілттің айналуын қамтамасыз ету керек. Бұл болашақ мақалаларда толығырақ қарастырылады, дегенмен мен бірнеше негізгі кілттерді пайдаланатын сервердің іске қосылуы сәл ұзағырақ уақыт алуы мүмкін екенін атап өткім келеді, әсіресе сервер жағындағы кілттер қоймасын пайдаланған кезде.

Енді keyring_file туралы аздап сөйлесейік. Мен keyring_file файлын әзірлеген кезде мен сервер жұмыс істеп тұрған кезде keyring_file өзгерістерін қалай тексеруге болатыны туралы алаңдадым. 5.7-де тексеру файл статистикасы негізінде орындалды, бұл идеалды шешім емес еді, ал 8.0-де ол SHA256 бақылау сомасымен ауыстырылды.

keyring_file бірінші рет іске қосылғанда, файл статистикасы мен бақылау сомасы есептеледі, оларды сервер есте сақтайды және өзгертулер сәйкес келген жағдайда ғана қолданылады. Файл өзгерген кезде бақылау сомасы жаңартылады.

Біз кілт қоймалары туралы көптеген сұрақтарды қарастырдық. Дегенмен, жиі ұмытылатын немесе дұрыс түсінілмейтін тағы бір маңызды тақырып бар: серверлер арқылы кілттерді ортақ пайдалану.

Мен не айтқым келеді? Кластердегі әрбір сервер (мысалы, Percona сервері) Percona сервері өз кілттерін сақтауы тиіс қойма серверінде бөлек орынға ие болуы керек. Жадта сақталған әрбір басты кілт өзінің идентификаторындағы Percona серверінің GUID кодын қамтиды. Неліктен маңызды? Сізде тек бір қойма сервері бар екенін және кластердегі барлық Percona серверлері сол жалғыз Vault серверін пайдаланатынын елестетіңіз. Мәселе анық сияқты. Егер барлық Percona серверлері id = 1, id = 2, т.б. сияқты бірегей идентификаторлары жоқ негізгі кілтті пайдаланса, кластердегі барлық серверлер бірдей басты кілтті пайдаланады. GUID қамтамасыз ететін нәрсе серверлер арасындағы айырмашылық болып табылады. Неліктен бірегей GUID бұрыннан бар болса, серверлер арасында кілттерді ортақ пайдалану туралы айту керек? Тағы бір плагин бар - keyring_udf. Бұл плагин арқылы сервер пайдаланушысы өз кілттерін Vault серверінде сақтай алады. Мәселе, мысалы, пайдаланушы сервер1-де кілт жасағанда, содан кейін сервер2-де бірдей идентификаторы бар кілтті жасауға тырысқанда пайда болады, мысалы:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1

Күте тұрыңыз. Екі сервер де бірдей қойма серверін пайдалануда, keyring_key_store функциясы сервер2-де сәтсіздікке ұшырауы керек емес пе? Бір қызығы, егер сіз бір серверде солай істеуге тырыссаңыз, сіз қатені аласыз:

--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0

Дұрыс, ROB_1 бұрыннан бар.

Алдымен екінші мысалды талқылайық. Жоғарыда айтқанымыздай, keyring_vault немесе кез келген басқа кілттік плагин жадтағы барлық негізгі идентификаторларды кэштейді. Сонымен, жаңа кілтті жасағаннан кейін ROB_1 сервер1-ге қосылады және бұл кілтті Vault-қа жіберуден басқа, кілт кэшке де қосылады. Енді сол кілтті екінші рет қосуға тырысқанда, keyring_vault кілттің кэште бар-жоғын тексереді және қате жібереді.

Бірінші жағдайда жағдай басқаша. Сервер1 және сервер2 бөлек кэштерге ие. ROB_1 файлын сервер1 мен қойма серверіндегі кілт кэшіне қосқаннан кейін сервер2 ішіндегі кілт кэш синхрондалмаған. Сервер2 кэшінде ROB_1 кілті жоқ. Осылайша, ROB_1 кілті keyring_key_store және Vault серверіне жазылады, ол іс жүзінде алдыңғы мәнді қайта жазады (!). Енді Vault серверіндегі ROB_1 кілті 543210987654321. Бір қызығы, Vault сервері мұндай әрекеттерді блоктамайды және ескі мәнді оңай қайта жазады.

Енді біз Vault ішіндегі серверді бөлу неліктен маңызды болуы мүмкін екенін көреміз - keyring_udf пайдалану кезінде және кілттерді Vault ішінде сақтағыңыз келгенде. Vault серверінде бұл бөлуге қалай қол жеткізуге болады?

Vault ішіне бөлудің екі жолы бар. Әрбір сервер үшін әртүрлі бекіту нүктелерін жасауға немесе бір бекіту нүктесінде әртүрлі жолдарды пайдалануға болады. Бұл мысалдармен жақсы суреттелген. Сондықтан алдымен жеке бекіту нүктелерін қарастырайық: 

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = server1_mount
token = (...)
vault_ca = (...)

--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = sever2_mount
token = (...)
vault_ca = (...)

Мұнда сервер1 және сервер2 әртүрлі бекіту нүктелерін пайдаланып жатқанын көре аласыз. Жолдарды бөлу кезінде конфигурация келесідей болады:

--server1:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/server1
token = (...)
vault_ca = (...)
--server2:
vault_url = http://127.0.0.1:8200
secret_mount_point = mount_point/sever2
token = (...)
vault_ca = (...)

Бұл жағдайда екі сервер де бірдей «mount_point» орнату нүктесін, бірақ әртүрлі жолдарды пайдаланады. Осы жолды пайдаланып server1-де бірінші құпияны жасаған кезде, Vault сервері автоматты түрде «server1» каталогын жасайды. Server2 үшін бәрі ұқсас. mount_point/server1 немесе mount_point/server2 ішіндегі соңғы құпияны жойған кезде, Vault сервері де сол каталогтарды жояды. Жолды бөлуді пайдаланған жағдайда, серверлер бөлек жолдарды пайдаланатындай етіп тек бір бекіту нүктесін жасап, конфигурация файлдарын өзгерту керек. Бекіту нүктесін HTTP сұрауы арқылы жасауға болады. CURL көмегімен мұны келесідей жасауға болады:

curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINT

Барлық өрістер (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) конфигурация файлының параметрлеріне сәйкес келеді. Әрине, дәл осылай істеу үшін Vault утилиталарын пайдалануға болады. Бірақ бекіту нүктесін жасауды автоматтандыру оңайырақ. Сізге бұл ақпарат пайдалы деп үміттенемін және біз сізді осы сериядағы келесі мақалаларда көреміз.

MySQL жүйесінде шифрлау: Кілттер қоймасы

Ары қарай оқу:

Ақпарат көзі: www.habr.com

пікір қалдыру