MySQLде шифрлөө: Ачкыч дүкөнү

Курска жаңы кабыл алуунун башталышын күтүү менен "Маалымат базасы" Биз сиздер үчүн пайдалуу макаланын котормосун даярдадык.

Transparent Data Encryption (TDE) пайда болгон MySQL үчүн Percona Server жана MySQL бир топ убакыт бою. Бирок сиз анын капоттун астында кантип иштээри жана TDE сиздин сервериңизге кандай таасир этиши жөнүндө ойлонуп көрдүңүз беле? Бул макалалар сериясында биз TDE кантип ички иштээрин карап чыгабыз. Келгиле, ачкыч сактагычынан баштайлы, анткени бул ар кандай шифрлөөнүн иштеши үчүн талап кылынат. Андан кийин биз MySQL/MySQL үчүн Percona серверинде шифрлөө кантип иштээрин жана MySQL үчүн Percona серверинин кандай кошумча мүмкүнчүлүктөрү бар экенин кылдат карап чыгабыз.

MySQL Keyring

Keyring – серверге локалдык файлдагы (keyring_file) же алыскы сервердеги (мисалы, HashiCorp Vault) ачкычтарды суроого, түзүүгө жана жок кылууга мүмкүндүк берген плагиндер. Ачкычтар аларды издөөнү тездетүү үчүн ар дайым жергиликтүү кэште сакталат.

Плагиндерди эки категорияга бөлүүгө болот:

• Жергиликтүү сактагыч. Мисалы, жергиликтүү файл (биз муну файлга негизделген ачкыч деп атайбыз).
• Алыскы сактагыч. Мисалы, Vault Server (биз муну серверге негизделген ачкыч деп атайбыз).

Бул бөлүү маанилүү, анткени сактоонун ар кандай түрлөрү ачкычтарды сактоодо жана алууда гана эмес, аларды иштетүүдө да бир аз башкачараак иштешет.

Файл сактагычты колдонууда, ишке киргенде, сактагычтын бүт мазмуну кэшке жүктөлөт: ачкыч идентификатору, негизги колдонуучу, ачкыч түрү жана ачкычтын өзү.

Сервер тарабында жайгашкан дүкөндө (мисалы, Vault Server), баштоодо ачкыч идентификатору жана негизги колдонуучу гана жүктөлөт, андыктан бардык ачкычтарды алуу баштоону жайлатпайт. Ачкычтар жалкоолук менен жүктөлөт. Башкача айтканда, ачкычтын өзү Vault'дан чындыгында керек болгондо гана жүктөлөт. Жүктөлүп алынгандан кийин, ачкыч эстутумда кэштелет, андыктан келечекте Vault серверине TLS туташуулары аркылуу кирүүнүн кереги жок. Андан кийин, негизги дүкөндө кандай маалымат бар экенин карап көрөлү.

Негизги маалымат төмөнкүлөрдү камтыйт:

• ачкыч ID — негизги идентификатор, мисалы:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• ачкыч түрү — колдонулган шифрлөө алгоритмине негизделген ачкыч түрү, мүмкүн болгон маанилер: “AES”, “RSA” же “DSA”.
• ачкычтын узундугу — байттагы ачкычтын узундугу, AES: 16, 24 же 32, RSA 128, 256, 512 жана DSA 128, 256 же 384.
• колдонуучу - ачкычтын ээси. Эгерде ачкыч система болсо, мисалы, Master Key, анда бул талаа бош. Эгерде ачкыч keyring_udf аркылуу түзүлсө, анда бул талаа ачкычтын ээсин аныктайт.
• ачкыч өзү

Ачкыч жуп тарабынан уникалдуу аныкталат: key_id, колдонуучу.

Ачкычтарды сактоодо жана жок кылууда да айырмачылыктар бар.

Файлды сактоо ылдамыраак. Сиз ачкыч дүкөнү жөн гана файлдын ачкычын бир жолу жазып жатат деп ойлошуңуз мүмкүн, бирок жок, бул жерде дагы көп нерселер бар. Файл сактагычына өзгөртүү киргизилген сайын, биринчи кезекте бардык мазмундун камдык көчүрмөсү түзүлөт. Айталы, файл my_biggest_secrets деп аталат, анда камдык көчүрмө my_biggest_secrets.backup болот. Андан кийин, кэш өзгөртүлөт (ачкычтар кошулат же жок кылынат) жана баары ийгиликтүү болсо, кэш файлга кайра коюлат. Сейрек учурларда, мисалы, сервердин катасы, сиз бул камдык файлды көрө аласыз. Камдык файл ачкычтар кийинки жолу жүктөлгөндө жок кылынат (көбүнчө сервер кайра иштетилгенден кийин).

Ачкычты сервердик сактагычта сактоодо же жок кылууда, сактоочу MySQL серверине “ачкычты жөнөтүү” / “ачкычты жок кылууну талап кылуу” буйруктары менен туташуу керек.

Серверди баштоо ылдамдыгына кайтып келели. Ишке киргизүү ылдамдыгына сейфтин өзү таасир этээринен тышкары, ишке киргизүүдө сактагычтан канча ачкычты алуу керек деген маселе да бар. Албетте, бул сервер сактоо үчүн өзгөчө маанилүү. Ишке киргенде сервер шифрленген таблицалар/таблицалар үчүн кайсы ачкыч талап кылынарын текшерет жана сактагычтан ачкычты сурайт. Мастер Ачкычтын шифрленген "таза" серверинде сактагычтан алынышы керек болгон бир Башкы ачкыч болушу керек. Бирок, мисалы, резервдик сервер негизги серверден камдык көчүрмөнү калыбына келтирип жатканда, көбүрөөк сандагы баскычтар талап кылынышы мүмкүн. Мындай учурларда, Башкы ачкычтын айлануусу камсыз кылынышы керек. Бул келечектеги макалаларда кененирээк каралат, бирок бул жерде мен бир нече Мастер ачкычтарды колдонгон сервердин ишке кириши бир аз көбүрөөк убакыт талап кылынышы мүмкүн экенин белгилегим келет, айрыкча сервер тараптагы ачкычтар дүкөнүн колдонууда.

Эми keyring_file жөнүндө бир аз көбүрөөк сүйлөшөлү. Мен keyring_file иштеп жатканда, сервер иштеп жатканда keyring_file өзгөрүүлөрдү кантип текшерүү керек деп тынчсыздандым. 5.7де текшерүү файл статистикасынын негизинде жүргүзүлдү, бул идеалдуу чечим болгон эмес, ал эми 8.0дө ал SHA256 текшерүү суммасы менен алмаштырылган.

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

Биз буга чейин негизги сактагычтар тууралуу көптөгөн суроолорду карадык. Бирок, көп учурда унутулуп калган же туура эмес түшүнгөн дагы бир маанилүү тема бар: серверлер аркылуу ачкычтарды бөлүшүү.

Мен эмнени айткым келет? Кластердеги ар бир сервердин (мисалы, Percona Server) Vault серверинде өзүнчө жайгашкан жери болушу керек, анда Percona Server өз ачкычтарын сакташы керек. Сактагычта сакталган ар бир башкы ачкыч өзүнүн идентификаторунун ичиндеги Percona серверинин GUID'ин камтыйт. Бул эмне үчүн маанилүү? Элестетиңиз, сизде бир гана Vault Server бар жана кластердеги бардык Percona серверлери ошол жалгыз Vault серверин колдонушат. Көйгөй ачык көрүнөт. Эгерде бардык Percona серверлери id = 1, id = 2 ж.б. сыяктуу уникалдуу идентификаторлору жок Башкы ачкычты колдонсо, кластердеги бардык серверлер бир эле Башкы ачкычты колдонушат. GUID серверлердин ортосундагы айырманы камсыз кылат. Эгер уникалдуу GUID мурунтан эле бар болсо, анда эмне үчүн серверлер ортосунда ачкычтарды бөлүшүү жөнүндө сүйлөшөсүз? Дагы бир плагин бар - keyring_udf. Бул плагин менен сиздин сервер колдонуучу өз ачкычтарын Vault серверинде сактай алат. Маселе, мисалы, колдонуучу сервер1де ачкыч түзүп, анан сервер2де ошол эле ID менен ачкыч түзүүгө аракет кылганда пайда болот, мисалы:

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

Күтө тур. Эки сервер тең бирдей Vault серверин колдонуп жатат, 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 ачкыч кэште бар же жок экенин текшерип, ката кетирет.

Биринчи учурда абал башкача. Server1 жана server2 өзүнчө кэштерге ээ. ROB_1 сервер1 жана Vault сервериндеги ачкыч кэшке кошулгандан кийин, сервер2деги ачкыч кэш шайкештештирилбейт. Server2деги кэште 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 = (...)

Бул жерде сиз server1 жана server2 ар кандай орнотуу чекиттерин колдонуп жатканын көрө аласыз. Жолдорду бөлгөндө, конфигурация төмөнкүдөй болот:

--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 утилиталарын колдоно аласыз. Бирок орнотуу пунктун түзүүнү автоматташтыруу оңой. Бул маалымат сизге пайдалуу деп үмүттөнөм жана биз сизди бул сериянын кийинки макалаларында көрөбүз.

Кененирээк:

• Sysbench жана кокус чоңдуктарды бөлүштүрүү

Source: www.habr.com