MySQL में एन्क्रिप्शन: कीस्टोर

पाठ्यक्रम के लिए नए नामांकन की शुरुआत की प्रत्याशा में "डेटाबेस" आपके लिए एक उपयोगी लेख का अनुवाद तैयार किया है।

पारदर्शी डेटा एन्क्रिप्शन (टीडीई) सामने आया MySQL के लिए पेरकोना सर्वर और MySQL पिछले कुछ समय से। लेकिन क्या आपने कभी सोचा है कि यह हुड के नीचे कैसे काम करता है और टीडीई का आपके सर्वर पर क्या प्रभाव पड़ सकता है? इस लेख श्रृंखला में, हम देखेंगे कि TDE आंतरिक रूप से कैसे काम करता है। आइए कुंजी भंडारण से शुरुआत करें, क्योंकि किसी भी एन्क्रिप्शन के काम करने के लिए यह आवश्यक है। फिर हम इस बात पर करीब से नज़र डालेंगे कि MySQL/MySQL के लिए Percona सर्वर में एन्क्रिप्शन कैसे काम करता है और MySQL के लिए Percona सर्वर में कौन सी अतिरिक्त सुविधाएँ उपलब्ध हैं।

MySQL कीरिंग

कीरिंग्स प्लगइन्स हैं जो सर्वर को स्थानीय फ़ाइल (कीरिंग_फाइल) या रिमोट सर्वर (उदाहरण के लिए, हाशीकॉर्प वॉल्ट में) में कुंजी क्वेरी करने, बनाने और हटाने की अनुमति देते हैं। पुनर्प्राप्ति में तेजी लाने के लिए कुंजियाँ हमेशा स्थानीय रूप से कैश की जाती हैं।

प्लगइन्स को दो श्रेणियों में विभाजित किया जा सकता है:

• स्थानीय भंडारण। उदाहरण के लिए, एक स्थानीय फ़ाइल (हम इसे फ़ाइल-आधारित कीरिंग कहते हैं)।
• दूरस्थ भंडारण. उदाहरण के लिए वॉल्ट सर्वर (हम इसे सर्वर-आधारित कीरिंग कहते हैं)।

यह पृथक्करण महत्वपूर्ण है क्योंकि विभिन्न भंडारण प्रकार न केवल चाबियाँ संग्रहीत और पुनर्प्राप्त करते समय, बल्कि जब वे शुरू होते हैं तब भी थोड़ा अलग व्यवहार करते हैं।

फ़ाइल संग्रहण का उपयोग करते समय, संग्रहण की सभी सामग्री स्टार्टअप पर कैश में लोड की जाती है: कुंजी आईडी, कुंजी उपयोगकर्ता, कुंजी प्रकार और स्वयं कुंजी।

बैक-एंड स्टोर (उदाहरण के लिए, वॉल्ट सर्वर) के मामले में, स्टार्टअप पर केवल कुंजी आईडी और कुंजी उपयोगकर्ता लोड किए जाते हैं, इसलिए सभी कुंजी प्राप्त करने से स्टार्टअप धीमा नहीं होता है। चाबियाँ आलस्य से लोड की जाती हैं। यानी वॉल्ट से चाबी तभी लोड होती है जब उसकी वास्तव में जरूरत होती है। डाउनलोड करने के बाद, कुंजी को मेमोरी में कैश कर दिया जाता है ताकि भविष्य में वॉल्ट सर्वर पर टीएलएस कनेक्शन के माध्यम से इसे एक्सेस करने की कोई आवश्यकता न हो। इसके बाद, विचार करें कि कीस्टोर में कौन सी जानकारी मौजूद है।

मुख्य जानकारी में निम्नलिखित शामिल हैं:

• कुंजी आईडी - मुख्य पहचानकर्ता, उदाहरण के लिए:
  INNODBKey-764d382a-7324-11e9-ad8f-9cb6d0d5dc99-1
• कुंजी प्रकार - प्रयुक्त एन्क्रिप्शन एल्गोरिदम के आधार पर कुंजी प्रकार, संभावित मान: "एईएस", "आरएसए" या "डीएसए"।
• कुंजी लंबाई - कुंजी लंबाई बाइट्स में, एईएस: 16, 24 या 32, आरएसए 128, 256, 512 और डीएसए 128, 256 या 384।
• उपयोगकर्ता कुंजी का स्वामी है. यदि कुंजी एक सिस्टम कुंजी है, जैसे मास्टर कुंजी, तो यह फ़ील्ड खाली है। यदि कुंजी 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 चलाने पर, फ़ाइल आँकड़े और चेकसम की गणना सर्वर द्वारा की जाती है और याद रखी जाती है, और परिवर्तन केवल तभी लागू किए जाते हैं जब वे मेल खाते हों। जब फ़ाइल बदलती है, तो चेकसम अपडेट हो जाता है।

हम पहले ही कीस्टोर्स के बारे में कई प्रश्नों पर चर्चा कर चुके हैं। हालाँकि, एक और महत्वपूर्ण विषय है जिसे अक्सर भुला दिया जाता है या गलत समझा जाता है - सर्वरों में कुंजी साझा करना।

मेरा क्या मतलब है? क्लस्टर में प्रत्येक सर्वर (उदाहरण के लिए, पेरकोना सर्वर) का वॉल्ट सर्वर पर एक अलग स्थान होना चाहिए जिसमें पेरकोना सर्वर को अपनी चाबियाँ संग्रहीत करनी होंगी। वॉल्ट में संग्रहीत प्रत्येक मास्टर कुंजी में उसकी आईडी के भीतर पेरकोना सर्वर GUID होता है। यह महत्वपूर्ण क्यों है? कल्पना करें कि आपके पास केवल एक वॉल्ट सर्वर है और क्लस्टर के सभी पेरकोना सर्वर इस एकल वॉल्ट सर्वर का उपयोग करते हैं। समस्या स्पष्ट प्रतीत होती है. यदि सभी पेरकोना सर्वर बिना किसी विशिष्ट पहचानकर्ता, जैसे आईडी = 1, आईडी = 2, आदि के साथ एक मास्टर कुंजी का उपयोग करते हैं, तो क्लस्टर के सभी सर्वर एक ही मास्टर कुंजी का उपयोग करेंगे। GUID यही प्रदान करता है - सर्वरों के बीच अंतर। यदि पहले से ही एक अद्वितीय GUID है तो सर्वर के बीच कुंजी साझा करने की बात क्यों करें? एक और प्लगइन है - keyring_udf. इस प्लगइन के साथ, आपके सर्वर का उपयोगकर्ता अपनी चाबियाँ वॉल्ट सर्वर पर संग्रहीत कर सकता है। समस्या तब होती है जब कोई उपयोगकर्ता एक कुंजी बनाता है, उदाहरण के लिए, सर्वर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 में जोड़ा जाता है, और इस कुंजी को वॉल्ट में भेजने के अलावा, कुंजी को कैश में भी जोड़ा जाता है। अब, जब हम उसी कुंजी को दूसरी बार जोड़ने का प्रयास करते हैं, तो keyring_vault जाँच करता है कि कुंजी कैश में मौजूद है या नहीं और एक त्रुटि देता है।

पहले मामले में स्थिति अलग है. सर्वर1 और सर्वर2 में अलग-अलग कैश हैं। सर्वर1 और वॉल्ट सर्वर पर कुंजी कैश में ROB_1 जोड़ने के बाद, सर्वर2 पर कुंजी कैश सिंक से बाहर है। सर्वर2 पर कैश में ROB_1 कुंजी नहीं है। इस प्रकार, ROB_1 कुंजी keyring_key_store और वॉल्ट सर्वर को लिखी जाती है, जो वास्तव में पिछले मान को अधिलेखित (!) कर देती है। अब वॉल्ट सर्वर पर ROB_1 कुंजी 543210987654321 है। दिलचस्प बात यह है कि वॉल्ट सर्वर ऐसी कार्रवाइयों को ब्लॉक नहीं करता है और पुराने मान को आसानी से ओवरराइट कर देता है।

अब हम देखते हैं कि जब आप keyring_udf का उपयोग करते हैं और वॉल्ट में चाबियाँ संग्रहीत करना चाहते हैं तो वॉल्ट में सर्वर द्वारा अलगाव क्यों महत्वपूर्ण हो सकता है। वॉल्ट सर्वर में ऐसा पृथक्करण कैसे प्रदान करें?

वॉल्ट पर विभाजन करने के दो तरीके हैं। आप प्रत्येक सर्वर के लिए अलग-अलग माउंट पॉइंट बना सकते हैं, या एक ही माउंट पॉइंट के भीतर अलग-अलग पथों का उपयोग कर सकते हैं। इसे दिखाने का सबसे अच्छा तरीका उदाहरणों के साथ है। तो आइए पहले अलग-अलग माउंट बिंदुओं को देखें:

--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 के लिए, सब कुछ समान है। जब आप mount_point/server1 या mount_point/server2 में अंतिम रहस्य हटाते हैं, तो वॉल्ट सर्वर उन निर्देशिकाओं को भी हटा देता है। यदि आप स्प्लिट पथों का उपयोग कर रहे हैं, तो आपको केवल एक माउंट पॉइंट बनाना होगा और कॉन्फ़िगरेशन फ़ाइलों को बदलना होगा ताकि सर्वर अलग पथों का उपयोग करें। HTTP अनुरोध के साथ एक माउंट पॉइंट बनाया जा सकता है। कर्ल के साथ यह इस प्रकार किया जा सकता है:

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