MySQL માં એન્ક્રિપ્શન: કીસ્ટોર

કોર્સ માટે નવી નોંધણીની શરૂઆતની અપેક્ષાએ "ડેટાબેઝ" અમે તમારા માટે ઉપયોગી લેખનો અનુવાદ તૈયાર કર્યો છે.

પારદર્શક ડેટા એન્ક્રિપ્શન (TDE) માં દેખાયા MySQL માટે Percona સર્વર અને ઘણા સમય માટે MySQL. પરંતુ શું તમે ક્યારેય વિચાર્યું છે કે તે હૂડ હેઠળ કેવી રીતે કાર્ય કરે છે અને TDE તમારા સર્વર પર શું અસર કરી શકે છે? લેખોની આ શ્રેણીમાં આપણે TDE આંતરિક રીતે કેવી રીતે કાર્ય કરે છે તે જોઈશું. ચાલો કી સ્ટોરેજથી શરૂઆત કરીએ, કારણ કે કોઈપણ એન્ક્રિપ્શન કામ કરવા માટે આ જરૂરી છે. પછી અમે MySQL/MySQL માટે Percona સર્વરમાં એન્ક્રિપ્શન કેવી રીતે કાર્ય કરે છે અને MySQL માટે Percona સર્વરમાં કઈ વધારાની સુવિધાઓ છે તેના પર અમે નજીકથી નજર નાખીશું.

MySQL કીરીંગ

કીરીંગ એ પ્લગઈનો છે જે સર્વરને સ્થાનિક ફાઈલ (કીરીંગ_ફાઈલ) અથવા રીમોટ સર્વર (જેમ કે હાશીકોર્પ વોલ્ટ) પર કીઓ ક્વેરી કરવા, બનાવવા અને કાઢી નાખવાની મંજૂરી આપે છે. તેમની પુનઃપ્રાપ્તિને ઝડપી બનાવવા માટે કી હંમેશા સ્થાનિક રીતે કેશ કરવામાં આવે છે.

પ્લગઇન્સને બે કેટેગરીમાં વિભાજિત કરી શકાય છે:

• સ્થાનિક સંગ્રહ. ઉદાહરણ તરીકે, સ્થાનિક ફાઇલ (આપણે તેને ફાઇલ-આધારિત કીરીંગ કહીએ છીએ).
• દૂરસ્થ સંગ્રહ. ઉદાહરણ તરીકે, વૉલ્ટ સર્વર (આપણે તેને સર્વર-આધારિત કીરીંગ કહીએ છીએ).

આ વિભાજન મહત્વપૂર્ણ છે કારણ કે વિવિધ પ્રકારના સ્ટોરેજ સહેજ અલગ રીતે વર્તે છે, માત્ર કીને સંગ્રહિત કરતી વખતે અને પુનઃપ્રાપ્ત કરતી વખતે જ નહીં, પણ તેને ચલાવતી વખતે પણ.

ફાઇલ સ્ટોરેજનો ઉપયોગ કરતી વખતે, સ્ટાર્ટઅપ પર, સ્ટોરેજની સંપૂર્ણ સામગ્રી કેશમાં લોડ થાય છે: કી આઈડી, કી વપરાશકર્તા, કી પ્રકાર અને કી પોતે.

સર્વર-આધારિત સ્ટોર (જેમ કે વૉલ્ટ સર્વર) ના કિસ્સામાં, ફક્ત કી આઈડી અને કી વપરાશકર્તા સ્ટાર્ટઅપ પર લોડ થાય છે, તેથી બધી ચાવીઓ મેળવવાથી સ્ટાર્ટઅપ ધીમું થતું નથી. ચાવીઓ આળસથી લોડ થાય છે. એટલે કે, જ્યારે તેની ખરેખર જરૂર હોય ત્યારે જ ચાવી વૉલ્ટમાંથી લોડ થાય છે. એકવાર ડાઉનલોડ થઈ ગયા પછી, કી મેમરીમાં કેશ કરવામાં આવે છે જેથી ભવિષ્યમાં તેને વૉલ્ટ સર્વર સાથે 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 કહેવામાં આવે છે, તો બેકઅપ કોપી my_biggest_secrets.backup હશે. આગળ, કેશ બદલાઈ જાય છે (કીઓ ઉમેરવામાં આવે છે અથવા કાઢી નાખવામાં આવે છે) અને, જો બધું સફળ થાય, તો કેશ ફાઇલ પર રીસેટ થાય છે. દુર્લભ કિસ્સાઓમાં, જેમ કે સર્વર નિષ્ફળતા, તમે આ બેકઅપ ફાઇલ જોઈ શકો છો. આગલી વખતે જ્યારે કી લોડ થાય ત્યારે બેકઅપ ફાઈલ કાઢી નાખવામાં આવે છે (સામાન્ય રીતે સર્વર પુનઃપ્રારંભ થયા પછી).

સર્વર સ્ટોરેજમાં કી સાચવતી વખતે અથવા કાઢી નાખતી વખતે, સ્ટોરેજને MySQL સર્વર સાથે "સેન્ડ ધ કી" / "કી ડિલીટ કરવાની વિનંતી" આદેશો સાથે કનેક્ટ થવી જોઈએ.

ચાલો સર્વર સ્ટાર્ટઅપ સ્પીડ પર પાછા જઈએ. હકીકત એ છે કે લોંચની ઝડપ તિજોરી દ્વારા જ પ્રભાવિત થાય છે તે ઉપરાંત, સ્ટાર્ટઅપ સમયે વૉલ્ટમાંથી કેટલી ચાવીઓ મેળવવાની જરૂર છે તે મુદ્દો પણ છે. અલબત્ત, સર્વર સ્ટોરેજ માટે આ ખાસ કરીને મહત્વનું છે. સ્ટાર્ટઅપ વખતે, સર્વર તપાસે છે કે એનક્રિપ્ટેડ કોષ્ટકો/ટેબલસ્પેસ માટે કઈ કી જરૂરી છે અને સ્ટોરેજમાંથી કીની વિનંતી કરે છે. માસ્ટર કી એન્ક્રિપ્શન સાથેના "ક્લીન" સર્વર પર, એક માસ્ટર કી હોવી જોઈએ, જે સ્ટોરેજમાંથી પુનઃપ્રાપ્ત થવી જોઈએ. જો કે, મોટી સંખ્યામાં કીની જરૂર પડી શકે છે, ઉદાહરણ તરીકે, જ્યારે બેકઅપ સર્વર પ્રાથમિક સર્વરમાંથી બેકઅપ પુનઃસ્થાપિત કરી રહ્યું હોય. આવા કિસ્સાઓમાં, માસ્ટર કીનું પરિભ્રમણ પ્રદાન કરવું જોઈએ. ભવિષ્યના લેખોમાં આને વધુ વિગતવાર આવરી લેવામાં આવશે, જો કે અહીં હું એ નોંધવા માંગુ છું કે બહુવિધ માસ્ટર કીઝનો ઉપયોગ કરતા સર્વરને શરૂ થવામાં થોડો વધુ સમય લાગી શકે છે, ખાસ કરીને જ્યારે સર્વર-સાઇડ કી સ્ટોરનો ઉપયોગ કરવામાં આવે છે.

હવે કીરીંગ_ફાઈલ વિશે થોડી વધુ વાત કરીએ. જ્યારે હું keyring_file વિકસાવી રહ્યો હતો, ત્યારે સર્વર ચાલતું હોય ત્યારે keyring_file ફેરફારો માટે કેવી રીતે તપાસવું તે અંગે પણ હું ચિંતિત હતો. 5.7 માં, તપાસ ફાઇલ આંકડાઓના આધારે કરવામાં આવી હતી, જે એક આદર્શ ઉકેલ ન હતો, અને 8.0 માં તેને SHA256 ચેકસમ સાથે બદલવામાં આવ્યો હતો.

જ્યારે તમે પ્રથમ વખત કીરીંગ_ફાઈલ ચલાવો છો, ત્યારે ફાઇલના આંકડા અને ચેકસમની ગણતરી કરવામાં આવે છે, જે સર્વર દ્વારા યાદ રાખવામાં આવે છે, અને જો તેઓ મેળ ખાતા હોય તો જ ફેરફારો લાગુ કરવામાં આવે છે. જ્યારે ફાઇલ બદલાય છે, ત્યારે ચેકસમ અપડેટ થાય છે.

અમે પહેલાથી જ કી વૉલ્ટ વિશે ઘણા પ્રશ્નો આવરી લીધા છે. જો કે, ત્યાં એક અન્ય મહત્વપૂર્ણ વિષય છે જે ઘણીવાર ભૂલી જાય છે અથવા ગેરસમજ થાય છે: સર્વર્સ પર કીઓ શેર કરવી.

મારો મતલબ શું છે? ક્લસ્ટરમાં દરેક સર્વર (ઉદાહરણ તરીકે, પરકોના સર્વર) પાસે વૉલ્ટ સર્વર પર એક અલગ સ્થાન હોવું આવશ્યક છે જેમાં પરકોના સર્વરે તેની ચાવીઓ સંગ્રહિત કરવી આવશ્યક છે. સ્ટોરેજમાં સાચવેલ દરેક માસ્ટર કી તેના ઓળખકર્તામાં પરકોના સર્વરનું GUID ધરાવે છે. શા માટે તે મહત્વનું છે? કલ્પના કરો કે તમારી પાસે માત્ર એક જ વૉલ્ટ સર્વર છે અને ક્લસ્ટરમાંના બધા પરકોના સર્વર તે સિંગલ વૉલ્ટ સર્વરનો ઉપયોગ કરે છે. સમસ્યા સ્પષ્ટ જણાય છે. જો બધા પરકોના સર્વર્સ અનન્ય ઓળખકર્તાઓ વગર માસ્ટર કીનો ઉપયોગ કરે છે, જેમ કે id = 1, id = 2, વગેરે, તો ક્લસ્ટરમાંના બધા સર્વર્સ સમાન માસ્ટર કીનો ઉપયોગ કરશે. GUID જે પ્રદાન કરે છે તે સર્વર્સ વચ્ચેનો તફાવત છે. જો અનન્ય GUID પહેલેથી અસ્તિત્વમાં હોય તો સર્વર્સ વચ્ચે કી શેર કરવા વિશે શા માટે વાત કરો? બીજું પ્લગઇન છે - keyring_udf. આ પ્લગઇન સાથે, તમારા સર્વર વપરાશકર્તા તેમની કીને વૉલ્ટ સર્વર પર સંગ્રહિત કરી શકે છે. સમસ્યા ત્યારે થાય છે જ્યારે વપરાશકર્તા સર્વર 1 પર કી બનાવે છે, ઉદાહરણ તરીકે, અને પછી સર્વર 2 પર સમાન ID સાથે કી બનાવવાનો પ્રયાસ કરે છે, ઉદાહરણ તરીકે:

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

રાહ જુઓ. બંને સર્વર એક જ વૉલ્ટ સર્વરનો ઉપયોગ કરી રહ્યાં છે, સર્વર2 પર keyring_key_store ફંક્શન ફેલ ન થવું જોઈએ? રસપ્રદ રીતે, જો તમે એક સર્વર પર તે જ કરવાનો પ્રયાસ કરો છો, તો તમને એક ભૂલ પ્રાપ્ત થશે:

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

તે સાચું છે, ROB_1 પહેલેથી જ અસ્તિત્વમાં છે.

ચાલો પહેલા બીજા ઉદાહરણની ચર્ચા કરીએ. આપણે અગાઉ કહ્યું તેમ, કીરીંગ_વોલ્ટ અથવા અન્ય કીરીંગ પ્લગઈન મેમરીમાં તમામ કી આઈડીને કેશ કરે છે. તેથી, નવી કી બનાવ્યા પછી, સર્વર1 માં ROB_1 ઉમેરવામાં આવે છે, અને આ કીને Vault ને મોકલવા ઉપરાંત, કી પણ કેશમાં ઉમેરવામાં આવે છે. હવે, જ્યારે આપણે એ જ કી બીજી વખત ઉમેરવાનો પ્રયાસ કરીએ છીએ, ત્યારે keyring_vault કેશમાં કી અસ્તિત્વમાં છે કે કેમ તે તપાસે છે અને ભૂલ ફેંકે છે.

પ્રથમ કિસ્સામાં પરિસ્થિતિ અલગ છે. સર્વર1 અને સર્વર2 પાસે અલગ કેશ છે. સર્વર1 અને વૉલ્ટ સર્વર પરની કી કેશમાં ROB_1 ઉમેર્યા પછી, સર્વર2 પરની કી કેશ સમન્વયની બહાર છે. સર્વર2 પરની કેશમાં કોઈ ROB_1 કી નથી. આમ, ROB_1 કી keyring_key_store અને Vault સર્વર પર લખવામાં આવે છે, જે વાસ્તવમાં અગાઉના મૂલ્યને ઓવરરાઈટ (!) કરે છે. હવે વૉલ્ટ સર્વર પર ROB_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 = (...)

આ કિસ્સામાં, બંને સર્વર્સ સમાન માઉન્ટ બિંદુ "mount_point" નો ઉપયોગ કરે છે, પરંતુ અલગ પાથ. જ્યારે તમે આ પાથનો ઉપયોગ કરીને સર્વર1 પર પ્રથમ રહસ્ય બનાવો છો, ત્યારે વૉલ્ટ સર્વર આપમેળે "સર્વર1" ડિરેક્ટરી બનાવે છે. સર્વર 2 માટે બધું સમાન છે. જ્યારે તમે 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) રૂપરેખાંકન ફાઇલના પરિમાણોને અનુરૂપ છે. અલબત્ત, તમે તે કરવા માટે વૉલ્ટ ઉપયોગિતાઓનો ઉપયોગ કરી શકો છો. પરંતુ માઉન્ટ પોઈન્ટની રચનાને સ્વચાલિત કરવાનું સરળ છે. મને આશા છે કે તમને આ માહિતી ઉપયોગી લાગશે અને અમે તમને આ શ્રેણીના આગામી લેખોમાં જોઈશું.

વધુ વાંચો:

• Sysbench અને રેન્ડમ ચલોનું વિતરણ

સોર્સ: www.habr.com