A cikin tsammanin fara sabon rajista don kwas Mun shirya muku fassarar labari mai amfani.
Bayyana bayanan sirri (TDE) ya bayyana a ciki da MySQL na ɗan lokaci kaɗan. Amma kun taɓa tunanin yadda yake aiki a ƙarƙashin kaho kuma wane tasiri TDE zai iya yi akan sabar ku? A cikin wannan jerin labaran za mu kalli yadda TDE ke aiki a ciki. Bari mu fara da ma'ajiyar maɓalli, tunda ana buƙatar wannan don kowane ɓoye ya yi aiki. Sa'an nan kuma za mu dubi yadda boye-boye ke aiki a cikin Percona Server don MySQL/MySQL da ƙarin abubuwan da Percona Server na MySQL ke da shi.
MySQL Keyring
Maɓalli plugins ne waɗanda ke ba uwar garken damar yin tambaya, ƙirƙira, da share maɓallai a cikin fayil na gida (keyring_file) ko kan sabar nesa (kamar HashiCorp Vault). Ana adana maɓallai koyaushe a cikin gida don hanzarta dawo da su.
Plugins za a iya raba kashi biyu:
- Ma'ajiyar gida. Misali, fayil na gida (muna kiran wannan maɓalli na tushen fayil).
- Ma'aji mai nisa. Misali, Vault Server (muna kiran wannan maɓalli na tushen sabar).
Wannan rabuwa yana da mahimmanci saboda nau'ikan ajiya daban-daban suna ɗan ɗan bambanta, ba kawai lokacin adanawa da dawo da makullin ba, har ma lokacin gudanar da su.
Lokacin amfani da ma'ajiyar fayil, lokacin farawa, ana loda dukkan abubuwan da ke cikin ma'ajiyar cikin ma'ajiyar: maɓalli id, mai amfani da maɓalli, nau'in maɓalli, da maɓallin kanta.
A cikin shago na gefen uwar garke (kamar Vault Server), maɓallin id kawai da mai amfani da maɓalli ne kawai ake lodawa a lokacin farawa, don haka samun duk maɓallan baya rage saurin farawa. Ana loda maɓallai a kasala. Wato, maɓalli da kansa ana loda shi daga Vault kawai lokacin da ake buƙata. Da zarar an sauke, maɓallin yana ɓoye a cikin ƙwaƙwalwar ajiya don kada ya buƙaci samun dama ta hanyar haɗin TLS zuwa uwar garken Vault a gaba. Na gaba, bari mu kalli irin bayanin da ke cikin mabuɗin.
Babban bayanin ya ƙunshi abubuwa masu zuwa:
- key id - mai gano maɓalli, misali:
INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1 - nau'in maɓalli - nau'in maɓalli dangane da ɓoyayyen algorithm da aka yi amfani da shi, ƙididdiga masu yiwuwa: "AES", "RSA" ko "DSA".
- tsayin mabuɗi - Tsawon maɓalli a cikin bytes, AES: 16, 24 ko 32, RSA 128, 256, 512 da DSA 128, 256 ko 384.
- mai amfani - mai mabuɗin. Idan maɓalli tsarin ne, misali, Master Key, to wannan filin babu kowa. Idan an ƙirƙiri maɓalli ta amfani da keyring_udf, to wannan filin yana gano mai maɓallin.
- key din kanta
Maɓallin an gano shi ta musamman ta hanyar biyu: key_id, mai amfani.
Hakanan akwai bambance-bambance a cikin adanawa da share maɓallai.
Adana fayil yana da sauri. Kuna iya tunanin cewa kantin sayar da maɓalli yana rubuta maɓallin fayil sau ɗaya kawai, amma a'a, akwai ƙarin ci gaba a nan. A duk lokacin da aka yi gyare-gyaren ajiyar fayil, ana fara ƙirƙirar kwafin duk abin ciki. Bari mu ce ana kiran fayil ɗin my_biggest_secrets, sannan kwafin ajiyar zai zama my_biggest_secrets.backup. Bayan haka, ana canza cache (ana ƙara ko share maɓallai) kuma, idan komai ya yi nasara, an sake saita cache ɗin zuwa fayil. A lokuta da ba kasafai ba, kamar gazawar uwar garken, kuna iya ganin wannan fayil ɗin madadin. Ana share fayil ɗin ajiyar lokaci na gaba ana loda maɓallan (yawanci bayan an sake kunna uwar garken).
Lokacin adanawa ko share maɓalli a cikin ma'ajiyar uwar garken, ajiyar dole ne ya haɗa zuwa uwar garken MySQL tare da umarnin "aika maɓallin" / "buƙatar share maɓalli".
Bari mu dawo kan saurin farawa uwar garken. Baya ga cewa rumbun da kanta ta shafi gudun kadawar, akwai kuma batun makullan makullai nawa ne ake bukatar a karbo a lokacin farawa. Tabbas, wannan yana da mahimmanci musamman don ajiyar uwar garke. A lokacin farawa, uwar garken yana duban wane maɓalli ne ake buƙata don rufaffen teburi/spaces ɗin tebur kuma yana buƙatar maɓallin daga ma'ajiyar. A kan uwar garken “tsabta” tare da ɓoyayyen Maɓalli na Jagora, dole ne a sami Maɓallin Jagora ɗaya, wanda dole ne a dawo da shi daga ma’adana. Koyaya, ana iya buƙatar adadin maɓallai mafi girma, misali, lokacin da uwar garken madadin ke dawo da wariyar ajiya daga sabar farko. A irin waɗannan lokuta, ya kamata a ba da jujjuyawar Maɓallin Jagora. Za a rufe wannan dalla-dalla a cikin labarai na gaba, kodayake a nan ina so in lura cewa uwar garken da ke amfani da Maɓallan Jagora da yawa na iya ɗaukar ɗan lokaci kaɗan don farawa, musamman lokacin amfani da kantin maɓalli na gefen uwar garke.
Yanzu bari mu ɗan ƙara magana game da keyring_file. Lokacin da nake haɓaka keyring_file, Na kuma damu da yadda ake bincika canje-canjen keyring_file yayin da sabar ke gudana. A cikin 5.7, an yi rajistan ne bisa kididdigar fayil, wanda ba shine mafita mai kyau ba, kuma a cikin 8.0 an maye gurbin shi da SHA256 checksum.
A karon farko da kuka kunna keyring_file, ana ƙididdige kididdigar fayil da checksum, waɗanda uwar garken ke tunawa, kuma ana amfani da canje-canje kawai idan sun dace. Lokacin da fayil ɗin ya canza, ana sabunta checksum.
Mun riga mun rufe tambayoyi da yawa game da maɓalli masu mahimmanci. Duk da haka, akwai wani muhimmin batu wanda sau da yawa ana mantawa ko rashin fahimta: raba maɓalli a cikin sabobin.
Me nake nufi? Kowane uwar garken (misali, Percona Server) a cikin gungu dole ne ya sami keɓantaccen wuri a kan uwar garken Vault wanda Percona Server ɗin dole ne ya adana maɓallansa. Kowane Maɓallin Jagora da aka ajiye a ma'ajiyar ya ƙunshi GUID na Sabar Percona a cikin mai gano ta. Me yasa yake da mahimmanci? Ka yi tunanin cewa kana da uwar garken Vault guda ɗaya kawai da duk Percona Servers a cikin gungu suna amfani da waccan uwar garken Vault guda ɗaya. Matsalar kamar a bayyane take. Idan duk Sabar Percona sun yi amfani da Maɓallin Jagora ba tare da abubuwan ganowa na musamman ba, kamar id = 1, id = 2, da sauransu, to duk sabar da ke cikin gungu za su yi amfani da Maɓallin Jagora iri ɗaya. Abin da GUID ke bayarwa shine bambanci tsakanin sabobin. Me yasa to magana game da raba maɓallan tsakanin sabobin idan akwai GUID na musamman? Akwai wani plugin - keyring_udf. Tare da wannan plugin ɗin, mai amfani da sabar ku na iya adana makullin su akan uwar garken Vault. Matsalar tana faruwa ne lokacin da mai amfani ya ƙirƙiri maɓalli akan uwar garken1, misali, sannan yayi ƙoƙarin ƙirƙirar maɓalli mai ID iri ɗaya akan uwar garken2, misali:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
--1 значит успешное завершение
--server2:
select keyring_key_store('ROB_1','AES',"543210987654321");
1Jira Duk sabobin biyu suna amfani da uwar garken Vault iri ɗaya, shin bai kamata aikin keyring_key_store ya gaza akan uwar garken2 ba? Abin sha'awa, idan kayi ƙoƙarin yin haka akan sabar guda ɗaya, zaku sami kuskure:
--server1:
select keyring_key_store('ROB_1','AES',"123456789012345");
1
select keyring_key_store('ROB_1','AES',"543210987654321");
0Haka ne, ROB_1 ya riga ya wanzu.
Bari mu fara tattauna misali na biyu. Kamar yadda muka fada a baya, keyring_vault ko wani maɓalli na maɓalli yana adana duk maɓallan ID a cikin ƙwaƙwalwar ajiya. Don haka, bayan ƙirƙirar sabon maɓalli, ana ƙara ROB_1 zuwa uwar garken1, kuma baya ga aika wannan maɓalli zuwa Vault, ana ƙara maɓalli a cikin cache. Yanzu, idan muka yi ƙoƙarin ƙara maɓalli iri ɗaya a karo na biyu, keyring_vault yana bincika ko maɓallin yana cikin cache kuma yana jefa kuskure.
A yanayin farko yanayin ya bambanta. Server1 da uwar garken2 suna da caches daban. Bayan ƙara ROB_1 zuwa maɓalli na maɓalli a kan uwar garken1 da uwar garken Vault, maɓallin maɓalli na kan uwar garken2 ya ƙare aiki tare. Babu maɓalli ROB_2 a cikin cache akan uwar garken1. Don haka, ana rubuta maɓallin ROB_1 zuwa keyring_key_store da uwar garken Vault, wanda a zahiri ya sake rubutawa (!) ƙimar da ta gabata. Yanzu maɓallin ROB_1 akan uwar garken Vault shine 543210987654321. Abin sha'awa shine, uwar garken Vault baya toshe irin waɗannan ayyukan kuma cikin sauƙi yana sake rubuta tsohuwar ƙima.
Yanzu zamu iya ganin dalilin da yasa rabuwar uwar garken a cikin Vault na iya zama mahimmanci - lokacin da kake amfani da keyring_udf kuma kuna son adana maɓalli a cikin Vault. Yadda ake samun wannan rabuwa akan uwar garken Vault?
Akwai hanyoyi guda biyu don rarraba cikin Vault. Kuna iya ƙirƙirar maki daban-daban don kowane uwar garken, ko amfani da hanyoyi daban-daban a cikin madaidaicin dutse ɗaya. An fi kwatanta wannan da misalai. Don haka bari mu fara duba abubuwan hawa ɗaya ɗaya:
--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 = (...)Anan za ku iya ganin cewa uwar garken1 da uwar garken2 suna amfani da wuraren tsaunuka daban-daban. Lokacin rarraba hanyoyin, tsarin zai yi kama da haka:
--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 = (...)A wannan yanayin, duka sabobin suna amfani da madaidaicin dutsen "mount_point", amma hanyoyi daban-daban. Lokacin da ka ƙirƙiri sirrin farko akan uwar garken1 ta amfani da wannan hanyar, uwar garken Vault ta atomatik ta ƙirƙiri kundin adireshi “server1”. Ga uwar garken2 komai yayi kama. Lokacin da kuka goge sirrin ƙarshe a mount_point/server1 ko mount_point/server2, uwar garken Vault shima yana goge waɗannan kundayen adireshi. Idan kuna amfani da rabuwar hanya, dole ne ku ƙirƙiri wurin tudu guda ɗaya kawai kuma ku canza fayilolin daidaitawa ta yadda sabobin ke amfani da hanyoyi daban-daban. Ana iya ƙirƙirar wurin tudu ta amfani da buƙatar HTTP. Yin amfani da CURL ana iya yin haka kamar haka:
curl -L -H "X-Vault-Token: TOKEN" –cacert VAULT_CA
--data '{"type":"generic"}' --request POST VAULT_URL/v1/sys/mounts/SECRET_MOUNT_POINTDuk filayen (TOKEN, VAULT_CA, VAULT_URL, SECRET_MOUNT_POINT) sun dace da ma'auni na fayil ɗin sanyi. Tabbas, zaku iya amfani da kayan aikin Vault don yin haka. Amma yana da sauƙi don sarrafa atomatik ƙirƙirar wurin dutse. Ina fatan za ku sami wannan bayanin da amfani kuma za mu gan ku a cikin labarai na gaba a cikin wannan silsilar.
Kara karantawa:
source: www.habr.com