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

पाठ्यक्रमको लागि नयाँ भर्ना सुरु हुने प्रत्याशामा "डाटाबेस" हामीले तपाईंको लागि उपयोगी लेखको अनुवाद तयार गरेका छौं।

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

MySQL कीरिङ

कीरिङ भनेको स्थानीय फाइल (keyring_file) वा रिमोट सर्भरमा (जस्तै HashiCorp Vault) मा कुञ्जीहरू क्वेरी गर्न, सिर्जना गर्न र मेटाउन सर्भरलाई अनुमति दिने प्लगइनहरू हुन्। कुञ्जीहरू तिनीहरूको पुन: प्राप्तिको गति बढाउनको लागि सधैं स्थानीय रूपमा क्यास गरिन्छ।

प्लगइनहरूलाई दुई भागमा विभाजन गर्न सकिन्छ:

• स्थानीय भण्डारण। उदाहरणका लागि, स्थानीय फाइल (हामी यसलाई फाइल-आधारित कीरिङ भन्छौं)।
• रिमोट भण्डारण। उदाहरणका लागि, भल्ट सर्भर (हामी यसलाई सर्भर-आधारित कीरिङ भन्छौं)।

यो विभाजन महत्त्वपूर्ण छ किनभने भण्डारणका विभिन्न प्रकारहरूले अलि फरक व्यवहार गर्छन्, कुञ्जीहरू भण्डारण र पुन: प्राप्ति गर्दा मात्र होइन, तर तिनीहरूलाई चलाउँदा पनि।

फाइल भण्डारण प्रयोग गर्दा, स्टार्टअपमा, भण्डारणको सम्पूर्ण सामग्रीहरू क्यासमा लोड हुन्छन्: कुञ्जी आईडी, कुञ्जी प्रयोगकर्ता, कुञ्जी प्रकार, र कुञ्जी आफैं।

सर्भर-साइड स्टोरको मामलामा (जस्तै भल्ट सर्भर), केवल कुञ्जी आईडी र कुञ्जी प्रयोगकर्ता स्टार्टअपमा लोड हुन्छन्, त्यसैले सबै कुञ्जीहरू प्राप्त गर्दा स्टार्टअप सुस्त हुँदैन। कुञ्जीहरू अल्छी रूपमा लोड हुन्छन्। अर्थात्, कुञ्जी आफैंले वाल्टबाट मात्र लोड हुन्छ जब यो वास्तवमा आवश्यक हुन्छ। एकचोटि डाउनलोड भएपछि, कुञ्जीलाई मेमोरीमा क्यास गरिन्छ ताकि यसलाई भविष्यमा भल्ट सर्भरमा 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 विकास गरिरहेको थिएँ, म सर्भर चलिरहेको बेला keyring_file परिवर्तनहरू कसरी जाँच गर्ने भन्ने बारे पनि चिन्तित थिएँ। 5.7 मा, फाइल तथ्याङ्कको आधारमा जाँच गरिएको थियो, जुन एक आदर्श समाधान थिएन, र 8.0 मा यसलाई SHA256 चेकसमले प्रतिस्थापन गरिएको थियो।

तपाईंले पहिलो पटक keyring_file चलाउँदा, फाइल तथ्याङ्कहरू र चेकसम गणना गरिन्छ, जुन सर्भरद्वारा सम्झिन्छन्, र तिनीहरू मेल खाएमा मात्र परिवर्तनहरू लागू हुन्छन्। जब फाइल परिवर्तन हुन्छ, चेकसम अद्यावधिक हुन्छ।

हामीले पहिले नै कुञ्जी वाल्टहरूको बारेमा धेरै प्रश्नहरू कभर गरिसकेका छौं। यद्यपि, त्यहाँ अर्को महत्त्वपूर्ण विषय हो जुन प्राय: बिर्सिन्छ वा गलत बुझिन्छ: सर्भरहरूमा साझा कुञ्जीहरू।

मैले भनेको मतलब? क्लस्टरमा प्रत्येक सर्भर (उदाहरणका लागि, पर्कोना सर्भर) भल्ट सर्भरमा छुट्टै स्थान हुनुपर्छ जसमा पर्कोना सर्भरले यसको कुञ्जीहरू भण्डारण गर्नुपर्छ। भण्डारणमा बचत गरिएको प्रत्येक मास्टर कुञ्जीले यसको पहिचानकर्ता भित्र पर्कोना सर्भरको GUID समावेश गर्दछ। यो किन महत्त्वपूर्ण छ? कल्पना गर्नुहोस् कि तपाईंसँग एउटा मात्र भल्ट सर्भर छ र क्लस्टरका सबै पर्कोना सर्भरहरूले त्यो एकल भल्ट सर्भर प्रयोग गर्छन्। समस्या स्पष्ट देखिन्छ। यदि सबै Percona सर्भरहरूले id = 1, id = 2, आदि जस्ता अद्वितीय पहिचानकर्ताहरू बिना मास्टर कुञ्जी प्रयोग गरे भने, क्लस्टरका सबै सर्भरहरूले एउटै मास्टर कुञ्जी प्रयोग गर्नेछन्। GUID ले के प्रदान गर्दछ सर्भरहरू बीचको भिन्नता हो। यदि एक अद्वितीय GUID पहिले नै अवस्थित छ भने सर्भरहरू बीच कुञ्जीहरू साझेदारी गर्ने बारे किन कुरा गर्नुहोस्? त्यहाँ अर्को प्लगइन छ - keyring_udf। यस प्लगइनको साथ, तपाइँको सर्भर प्रयोगकर्ताले आफ्नो कुञ्जीहरू भल्ट सर्भरमा भण्डार गर्न सक्छन्। समस्या तब हुन्छ जब प्रयोगकर्ताले सर्भर १ मा कुञ्जी सिर्जना गर्दछ, उदाहरणका लागि, र त्यसपछि सर्भर २ मा उही आईडीको साथ कुञ्जी सिर्जना गर्ने प्रयास गर्दछ, उदाहरणका लागि:

--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 वा कुनै अन्य keyring प्लगइनले मेमोरीमा रहेका सबै कुञ्जी ID हरू क्यास गर्छ। त्यसैले, नयाँ कुञ्जी सिर्जना गरेपछि, ROB_1 सर्भर १ मा थपिएको छ, र यो कुञ्जीलाई Vault मा पठाउनुका साथै क्यासमा पनि थपिएको छ। अब, जब हामीले एउटै कुञ्जीलाई दोस्रो पटक थप्ने प्रयास गर्छौं, keyring_vault ले जाँच गर्छ कि क्यासमा कुञ्जी अवस्थित छ र त्रुटि फ्याँक्छ।

पहिलो मामला मा स्थिति फरक छ। सर्भर १ र सर्भर २ मा छुट्टाछुट्टै क्यासहरू छन्। सर्भर १ र भल्ट सर्भरको कुञ्जी क्यासमा ROB_1 थपेपछि, सर्भर २ मा रहेको कुञ्जी क्यास सिङ्कबाट बाहिर छ। सर्भर २ मा रहेको क्यासमा कुनै ROB_2 कुञ्जी छैन। यसरी, ROB_1 कुञ्जी keyring_key_store र Vault सर्भरमा लेखिएको छ, जसले वास्तवमा अघिल्लो मानलाई ओभरराइट गर्छ (!)। अब भल्ट सर्भरमा ROB_1 कुञ्जी 2 छ। चाखलाग्दो कुरा के छ भने, Vault सर्भरले त्यस्ता कार्यहरूलाई रोक्दैन र पुरानो मानलाई सजिलै ओभरराइट गर्छ।

अब हामी देख्न सक्छौं किन भल्टमा सर्भर विभाजन महत्त्वपूर्ण हुन सक्छ - जब तपाइँ keyring_udf प्रयोग गर्दै हुनुहुन्छ र भल्टमा कुञ्जीहरू भण्डार गर्न चाहनुहुन्छ। भल्ट सर्भरमा यो विभाजन कसरी प्राप्त गर्ने?

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:
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" डाइरेक्टरी सिर्जना गर्दछ। सर्भर २ को लागि सबै समान छ। जब तपाइँ mount_point/server2 वा mount_point/server1 मा अन्तिम गोप्य मेटाउनुहुन्छ, 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