Шифровање у МиСКЛ: Складиште кључева

У ишчекивању почетка новог уписа курса "База података" За вас смо припремили превод корисног чланка.

Транспарентно шифровање података (ТДЕ) појавило се у Перцона сервер за МиСКЛ и МиСКЛ већ неко време. Али да ли сте икада размишљали о томе како функционише испод хаубе и какав утицај ТДЕ може имати на ваш сервер? У овој серији чланака ћемо погледати како ТДЕ функционише интерно. Почнимо са складиштењем кључева, пошто је ово потребно да би било које шифровање функционисало. Затим ћемо детаљније погледати како шифровање функционише у Перцона серверу за МиСКЛ/МиСКЛ и које додатне функције има Перцона Сервер за МиСКЛ.

МиСКЛ Кеиринг

Кеиринг су додаци који омогућавају серверу да тражи, креира и брише кључеве у локалној датотеци (кеиринг_филе) или на удаљеном серверу (као што је ХасхиЦорп Ваулт). Кључеви се увек кеширају локално како би се убрзало њихово преузимање.

Додаци се могу поделити у две категорије:

• Локално складиште. На пример, локална датотека (ми ово зовемо привезак за кључеве заснован на фајловима).
• Удаљено складиштење. На пример, Ваулт Сервер (ми ово зовемо привезак за кључеве заснован на серверу).

Ово раздвајање је важно јер се различити типови складишта понашају мало другачије, не само када се чувају и преузимају кључеви, већ и када се покрећу.

Када користите складиште датотека, након покретања, цео садржај складишта се учитава у кеш: ИД кључа, корисник кључа, тип кључа и сам кључ.

У случају продавнице засноване на серверу (као што је Ваулт Сервер), при покретању се учитавају само ИД кључа и корисник кључа, тако да преузимање свих кључева не успорава покретање. Кључеви се лењо учитавају. То јест, сам кључ се учитава из трезора само када је заиста потребан. Када се једном преузме, кључ се кешује у меморију тако да му се у будућности не треба приступати преко ТЛС конекција са Ваулт сервером. Затим, погледајмо које су информације присутне у складишту кључева.

Кључне информације садрже следеће:

• ИД кључа — идентификатор кључа, на пример:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• тип кључа — тип кључа на основу коришћеног алгоритма шифровања, могуће вредности: „АЕС“, „РСА“ или „ДСА“.
• дужина кључа — дужина кључа у бајтовима, АЕС: 16, 24 или 32, РСА 128, 256, 512 и ДСА 128, 256 или 384.
• корисник - власник кључа. Ако је кључ системски, на пример, главни кључ, онда је ово поље празно. Ако је кључ креиран помоћу кеиринг_удф, онда ово поље идентификује власника кључа.
• сам кључ

Кључ је јединствено идентификован паром: ИД кључа, корисник.

Такође постоје разлике у чувању и брисању кључева.

Складиштење датотека је брже. Можда мислите да складиште кључева једноставно уписује кључ у датотеку једном, али не, овде се дешава више. Кад год се изврши модификација складишта датотека, прво се креира резервна копија целокупног садржаја. Рецимо да се датотека зове ми_биггест_сецретс, онда ће резервна копија бити ми_биггест_сецретс.бацкуп. Затим се мења кеш (кључеви се додају или бришу) и, ако је све успешно, кеш се ресетује у датотеку. У ретким случајевима, као што је квар сервера, можете видети ову датотеку резервне копије. Датотека резервне копије се брише следећи пут када се кључеви учитају (обично након поновног покретања сервера).

Када чувате или бришете кључ у складишту сервера, складиште мора да се повеже са МиСКЛ сервером помоћу команди „пошаљи кључ“ / „захтевај брисање кључа“.

Вратимо се на брзину покретања сервера. Поред чињенице да на брзину покретања утиче сам трезор, постоји и питање колико кључева из трезора треба преузети при покретању. Наравно, ово је посебно важно за складиштење сервера. Приликом покретања, сервер проверава који кључ је потребан за шифроване табеле/просторе табела и захтева кључ из складишта. На „чистом“ серверу са шифровањем главног кључа, мора постојати један главни кључ, који се мора преузети из складишта. Међутим, може бити потребан већи број кључева, на пример, када резервни сервер враћа резервну копију са примарног сервера. У таквим случајевима треба обезбедити ротацију главног кључа. Ово ће бити детаљније објашњено у будућим чланцима, иако бих овде желео да напоменем да серверу који користи више главних кључева може бити потребно мало дуже да се покрене, посебно када се користи складиште кључева на страни сервера.

Хајде сада да причамо мало више о кеиринг_филе. Када сам развијао кеиринг_филе, такође сам се бринуо о томе како да проверим промене у кеиринг_филе док сервер ради. У верзији 5.7 провера је извршена на основу статистике фајла, што није било идеално решење, ау 8.0 је замењена контролном сумом СХА256.

Када први пут покренете кеиринг_филе, израчунавају се статистика датотеке и контролни збир, које сервер памти, а промене се примењују само ако се подударају. Када се датотека промени, контролни збир се ажурира.

Већ смо покрили многа питања о трезорима кључева. Међутим, постоји још једна важна тема која се често заборавља или погрешно разуме: дељење кључева на серверима.

Оно што мислим? Сваки сервер (на пример, Перцона сервер) у кластеру мора имати засебну локацију на Ваулт серверу у којој Перцона сервер мора да чува своје кључеве. Сваки главни кључ сачуван у складишту садржи ГУИД Перцона сервера у оквиру свог идентификатора. Зашто је важно? Замислите да имате само један Ваулт сервер и да сви Перцона сервери у кластеру користе тај један Ваулт сервер. Проблем изгледа очигледан. Ако би сви Перцона сервери користили главни кључ без јединствених идентификатора, као што су ид = 1, ид = 2, итд., онда би сви сервери у кластеру користили исти главни кључ. Оно што ГУИД пружа је разлика између сервера. Зашто онда причати о дељењу кључева између сервера ако већ постоји јединствени ГУИД? Постоји још један додатак - кеиринг_удф. Помоћу овог додатка, корисник вашег сервера може да складишти своје кључеве на Ваулт серверу. Проблем се јавља када корисник креира кључ на серверу1, на пример, а затим покуша да креира кључ са истим ИД-ом на серверу2, на пример:

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

Чекати. Оба сервера користе исти Ваулт сервер, зар функција кеиринг_кеи_сторе не би требало да не успе на серверу2? Занимљиво је да ако покушате да урадите исто на једном серверу, добићете грешку:

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

Тако је, РОБ_1 већ постоји.

Хајде да прво размотримо други пример. Као што смо раније рекли, кеиринг_ваулт или било који други додатак за кључеве кешира све ИД-ове кључева у меморији. Дакле, након креирања новог кључа, РОБ_1 се додаје на сервер1, а поред слања овог кључа у Ваулт, кључ се додаје и у кеш меморију. Сада, када покушамо да додамо исти кључ по други пут, кеиринг_ваулт проверава да ли кључ постоји у кешу и даје грешку.

У првом случају ситуација је другачија. Сервер1 и сервер2 имају одвојене кеш меморије. Након додавања РОБ_1 у кеш кључева на серверу1 и Ваулт серверу, кеш кључева на серверу2 није синхронизован. Нема кључа РОБ_2 у кешу на серверу1. Дакле, кључ РОБ_1 се уписује у кеиринг_кеи_сторе и на Ваулт сервер, који заправо замењује (!) претходну вредност. Сада је кључ РОБ_1 на серверу трезора 543210987654321. Занимљиво је да сервер трезора не блокира такве радње и лако преписује стару вредност.

Сада можемо да видимо зашто партиционисање сервера у трезору може бити важно – када користите кеиринг_удф и желите да сачувате кључеве у трезору. Како постићи ово раздвајање на Ваулт серверу?

Постоје два начина за партицију у Ваулт. Можете креирати различите тачке монтирања за сваки сервер или користити различите путање унутар исте тачке монтирања. Ово је најбоље илустровано примерима. Дакле, хајде да прво погледамо појединачне тачке монтирања:

--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 = (...)

У овом случају, оба сервера користе исту тачку монтирања "моунт_поинт", али различите путање. Када креирате прву тајну на сервер1 користећи ову путању, сервер Ваулт аутоматски креира директоријум „сервер1“. За сервер2 све је слично. Када избришете последњу тајну у моунт_поинт/сервер1 или моунт_поинт/сервер2, сервер трезора такође брише те директоријуме. У случају да користите раздвајање путања, морате креирати само једну тачку монтирања и променити конфигурационе датотеке тако да сервери користе одвојене путање. Тачка монтирања се може креирати помоћу ХТТП захтева. Користећи ЦУРЛ ово се може урадити овако:

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

Сва поља (ТОКЕН, ВАУЛТ_ЦА, ВАУЛТ_УРЛ, СЕЦРЕТ_МОУНТ_ПОИНТ) одговарају параметрима конфигурационе датотеке. Наравно, можете користити Ваулт услужне програме да урадите исто. Али лакше је аутоматизовати креирање тачке монтирања. Надам се да ће вам ове информације бити корисне и видимо се у наредним чланцима у овој серији.

Опширније:

• Сисбенцх и дистрибуција случајних променљивих

Извор: ввв.хабр.цом