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

अभ्यासक्रमासाठी नवीन नावनोंदणी सुरू होण्याच्या अपेक्षेने "डेटाबेस" आम्ही तुमच्यासाठी उपयुक्त लेखाचे भाषांतर तयार केले आहे.

पारदर्शक डेटा एन्क्रिप्शन (TDE) मध्ये दिसू लागले MySQL साठी Percona सर्व्हर आणि काही काळ MySQL. परंतु तुम्ही कधीही विचार केला आहे की ते हुड अंतर्गत कसे कार्य करते आणि TDE चा तुमच्या सर्व्हरवर काय परिणाम होऊ शकतो? लेखांच्या या मालिकेत आम्ही TDE अंतर्गत कसे कार्य करते ते पाहू. चला की स्टोरेजसह प्रारंभ करूया, कारण कोणत्याही एन्क्रिप्शन कार्य करण्यासाठी हे आवश्यक आहे. त्यानंतर MySQL/MySQL साठी Percona Server मध्ये एन्क्रिप्शन कसे कार्य करते आणि MySQL साठी Percona सर्व्हरमध्ये कोणती अतिरिक्त वैशिष्ट्ये आहेत यावर आम्ही बारकाईने लक्ष देऊ.

MySQL कीरिंग

कीरिंग हे प्लगइन आहेत जे सर्व्हरला स्थानिक फाइल (keyring_file) किंवा रिमोट सर्व्हरवर (जसे की HashiCorp Vault) की क्वेरी करण्यास, तयार करण्यास आणि हटविण्याची परवानगी देतात. की त्यांच्या पुनर्प्राप्तीची गती वाढवण्यासाठी नेहमी स्थानिक पातळीवर कॅश केल्या जातात.

प्लगइन दोन श्रेणींमध्ये विभागले जाऊ शकतात:

• स्थानिक स्टोरेज. उदाहरणार्थ, स्थानिक फाइल (आम्ही याला फाइल-आधारित कीरिंग म्हणतो).
• रिमोट स्टोरेज. उदाहरणार्थ, व्हॉल्ट सर्व्हर (आम्ही याला सर्व्हर-आधारित कीरिंग म्हणतो).

हे पृथक्करण महत्त्वाचे आहे कारण विविध प्रकारचे स्टोरेज थोडेसे वेगळे वागतात, केवळ की साठवताना आणि पुनर्प्राप्त करतानाच नव्हे तर त्या चालवताना देखील.

फाइल स्टोरेज वापरताना, स्टार्टअप झाल्यावर, स्टोरेजची संपूर्ण सामग्री कॅशेमध्ये लोड केली जाते: की आयडी, की वापरकर्ता, की प्रकार आणि की स्वतः.

सर्व्हर-साइड स्टोअरच्या बाबतीत (जसे की व्हॉल्ट सर्व्हर), फक्त की आयडी आणि की वापरकर्ता स्टार्टअपवर लोड केले जातात, त्यामुळे सर्व की मिळवण्याने स्टार्टअपची गती कमी होत नाही. कळा आळशीपणे लोड केल्या जातात. म्हणजेच, किल्ली जेव्हा प्रत्यक्षात आवश्यक असेल तेव्हाच व्हॉल्टमधून लोड केली जाते. एकदा डाउनलोड केल्यावर, की मेमरीमध्ये कॅश केली जाते जेणेकरून भविष्यात ती 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. या प्लगइनसह, तुमचा सर्व्हर वापरकर्ता त्यांच्या की व्हॉल्ट सर्व्हरवर संग्रहित करू शकतो. जेव्हा वापरकर्ता सर्व्हर 1 वर की तयार करतो आणि नंतर सर्व्हर 2 वर समान आयडी असलेली की तयार करण्याचा प्रयत्न करतो तेव्हा समस्या उद्भवते, उदाहरणार्थ:

--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 आधीपासून अस्तित्वात आहे.

प्रथम दुसऱ्या उदाहरणावर चर्चा करू. आम्ही आधी म्हटल्याप्रमाणे, keyring_vault किंवा इतर कोणतेही keyring प्लगइन मेमरीमधील सर्व की आयडी कॅश करते. त्यामुळे, नवीन की तयार केल्यानंतर, सर्व्हर1 मध्ये ROB_1 जोडली जाते आणि ही की Vault ला पाठवण्याव्यतिरिक्त, कॅशेमध्ये की देखील जोडली जाते. आता, जेव्हा आपण तीच की दुसऱ्यांदा जोडण्याचा प्रयत्न करतो, तेव्हा keyring_vault कॅशेमध्ये की अस्तित्वात आहे की नाही हे तपासते आणि त्रुटी टाकते.

पहिल्या प्रकरणात परिस्थिती वेगळी आहे. सर्व्हर1 आणि सर्व्हर 2 मध्ये वेगळे कॅशे आहेत. सर्व्हर1 आणि व्हॉल्ट सर्व्हरवरील की कॅशेमध्ये ROB_1 जोडल्यानंतर, सर्व्हर 2 वरील की कॅशे समक्रमित झाली आहे. सर्व्हर 2 वरील कॅशेमध्ये ROB_1 की नाही. अशाप्रकारे, ROB_1 की keyring_key_store आणि Vault सर्व्हरवर लिहिली जाते, जी प्रत्यक्षात मागील मूल्य (!) ओव्हरराईट करते. आता Vault सर्व्हरवरील ROB_1 की 543210987654321 आहे. विशेष म्हणजे, Vault सर्व्हर अशा क्रियांना अवरोधित करत नाही आणि जुने मूल्य सहजपणे ओव्हरराइट करते.

आता आपण पाहू शकतो की व्हॉल्टमध्ये सर्व्हरचे विभाजन का महत्त्वाचे असू शकते - जेव्हा तुम्ही 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 = (...)

या प्रकरणात, दोन्ही सर्व्हर समान माउंट पॉइंट "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