डेटाबेस बैकअप एन्क्रिप्शन - सर्वोत्तम अभ्यास

ऑफ़साइट बैकअप संग्रहण किसी भी संगठन की आपदा पुनर्प्राप्ति योजना का एक महत्वपूर्ण हिस्सा होना चाहिए। डेटा को एक अलग भौतिक स्थान में संग्रहीत करने की क्षमता, जहां यह एक भयावह घटना से बच सकता है जो आपके प्राथमिक डेटा केंद्र के सभी डेटा को नष्ट कर देता है, आपके डेटा के अस्तित्व और आपके संगठन की निरंतरता सुनिश्चित करता है। ऑफसाइट बैकअप स्टोर करने के लिए क्लाउड स्टोरेज सेवा काफी अच्छी विधि है। कोई फर्क नहीं पड़ता कि आप क्लाउड प्रदाता का उपयोग कर रहे हैं या यदि आप डेटा को किसी बाहरी डेटा केंद्र में कॉपी कर रहे हैं, तो ऐसे मामलों में बैकअप एन्क्रिप्शन आवश्यक है। हमारे पिछले ब्लॉगों में से एक में, हमने आपके बैकअप को एन्क्रिप्ट करने के कई तरीकों पर चर्चा की थी। आज हम बैकअप एन्क्रिप्शन के कुछ सर्वोत्तम अभ्यासों पर ध्यान केंद्रित करेंगे।

सुनिश्चित करें कि आपके रहस्य सुरक्षित हैं

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

आप चाबियों को एक प्रमुख प्रबंधन प्रणाली या एक तिजोरी में स्टोर कर सकते हैं - अमेज़ॅन के केएमएस या हैशिकॉर्प के वॉल्ट जैसे चुनने के लिए बाजार में कई विकल्प हैं। यहां तक ​​​​कि अगर आप उन समाधानों का उपयोग नहीं करने का निर्णय लेते हैं, तब भी आपको सामान्य सुरक्षा प्रथाओं को लागू करना चाहिए जैसे कि यह सुनिश्चित करने के लिए कि केवल सही उपयोगकर्ता ही आपकी कुंजी और पासवर्ड तक पहुंच सकते हैं। आपको अपनी बैकअप स्क्रिप्ट को इस तरह से तैयार करने पर भी विचार करना चाहिए कि आप चल रही प्रक्रियाओं की सूची में कुंजी या पासवर्ड को उजागर नहीं करेंगे। आदर्श रूप से, उन्हें कुछ आदेशों के तर्क के रूप में पारित करने के बजाय फ़ाइल में रखें।

असममित एन्क्रिप्शन पर विचार करें

सममित और असममित एन्क्रिप्शन के बीच मुख्य अंतर यह है कि एन्क्रिप्शन और डिक्रिप्शन दोनों के लिए सममित एन्क्रिप्शन का उपयोग करते समय, आप एकल कुंजी या पासवर्ड का उपयोग करते हैं। इसके लिए प्रक्रिया के दोनों सिरों पर उच्च सुरक्षा मानकों की आवश्यकता होती है। आपको यह सुनिश्चित करना होगा कि जिस होस्ट पर आप डेटा एन्क्रिप्ट करते हैं वह बहुत सुरक्षित है क्योंकि सममित एन्क्रिप्शन कुंजी का रिसाव आपके सभी एन्क्रिप्टेड बैकअप तक पहुंच की अनुमति देगा।

दूसरी ओर, यदि आप असममित एन्क्रिप्शन का उपयोग करते हैं, तो आपके पास दो कुंजियाँ होती हैं:डेटा को एन्क्रिप्ट करने के लिए सार्वजनिक कुंजी और डिक्रिप्शन के लिए निजी कुंजी। इससे चीजें बहुत आसान हो जाती हैं - आपको वास्तव में सार्वजनिक कुंजी की परवाह करने की ज़रूरत नहीं है। भले ही इससे समझौता किया गया हो, फिर भी यह बैकअप से डेटा तक किसी भी प्रकार की पहुंच की अनुमति नहीं देगा। आपको केवल Private key की सुरक्षा पर ध्यान देना है। यह आसान है - आप दैनिक आधार पर बैकअप एन्क्रिप्ट कर रहे हैं (यदि अधिक बार नहीं) जबकि समय-समय पर पुनर्स्थापना होती है, जिससे निजी कुंजी को अधिक सुरक्षित स्थान (यहां तक ​​​​कि एक समर्पित भौतिक उपकरण पर) में संग्रहीत करना संभव हो जाता है। नीचे एक बहुत ही त्वरित उदाहरण दिया गया है कि कैसे आप कुंजी जोड़ी बनाने और डेटा एन्क्रिप्ट करने के लिए इसका उपयोग करने के लिए gpg का उपयोग कर सकते हैं।

सबसे पहले, आपको कुंजियाँ बनानी होंगी:

[email protected]:~# gpg --gen-key
gpg (GnuPG) 1.4.20; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: directory `/root/.gnupg' created
gpg: new configuration file `/root/.gnupg/gpg.conf' created
gpg: WARNING: options in `/root/.gnupg/gpg.conf' are not yet active during this run
gpg: keyring `/root/.gnupg/secring.gpg' created
gpg: keyring `/root/.gnupg/pubring.gpg' created
Please select what kind of key you want:
   (1) RSA and RSA (default)
   (2) DSA and Elgamal
   (3) DSA (sign only)
   (4) RSA (sign only)
Your selection?
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
         0 = key does not expire
      <n>  = key expires in n days
      <n>w = key expires in n weeks
      <n>m = key expires in n months
      <n>y = key expires in n years
Key is valid for? (0)
Key does not expire at all
Is this correct? (y/N) y

You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
    "Heinrich Heine (Der Dichter) <[email protected]>"

Real name: Krzysztof Ksiazek
Email address: [email protected]
Comment: Backup key
You selected this USER-ID:
    "Krzysztof Ksiazek (Backup key) <[email protected]>"

Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
You need a Passphrase to protect your secret key.

इसने सार्वजनिक और निजी दोनों कुंजियाँ बनाईं। इसके बाद, आप डेटा को एन्क्रिप्ट करने के लिए उपयोग करने के लिए अपनी सार्वजनिक कुंजी निर्यात करना चाहते हैं:

gpg --armor --export [email protected] > mybackupkey.asc

इसके बाद, आप इसका उपयोग अपने बैकअप को एन्क्रिप्ट करने के लिए कर सकते हैं।

[email protected]:~# xtrabackup  --backup --stream=xbstream  | gzip | gpg -e --armor -r [email protected] -o /backup/pgp_encrypted.backup

अंत में, एक उदाहरण कि आप अपने बैकअप को डिक्रिप्ट करने के लिए अपनी प्राथमिक कुंजी का उपयोग कैसे कर सकते हैं (इस मामले में यह स्थानीय कुंजी रिंग में संग्रहीत है):

[email protected]:/backup# gpg -d /backup/pgp_encrypted.backup | gunzip | xbstream -x
encryption: using gcrypt 1.6.5

You need a passphrase to unlock the secret key for
user: "Krzysztof Ksiazek (Backup key) <[email protected]>"
4096-bit RSA key, ID E047CD69, created 2018-11-19 (main key ID BC341551)

gpg: gpg-agent is not available in this session
gpg: encrypted with 4096-bit RSA key, ID E047CD69, created 2018-11-19
      "Krzysztof Ksiazek (Backup key) <[email protected]>"

अपनी एन्क्रिप्शन कुंजियां घुमाएं

कोई फर्क नहीं पड़ता कि आपने किस प्रकार का एन्क्रिप्शन लागू किया, सममित या असममित, आपको कुंजी रोटेशन के बारे में सोचना होगा। सबसे पहले, चाबियों को घुमाने के लिए एक तंत्र होना बहुत जरूरी है। सुरक्षा भंग के मामले में यह उपयोगी हो सकता है, और आपको बैकअप एन्क्रिप्शन और डिक्रिप्शन के लिए उपयोग की जाने वाली कुंजियों को जल्दी से बदलना होगा। बेशक, सुरक्षा उल्लंघन के मामले में, आपको यह विचार करने की आवश्यकता है कि पुराने बैकअप के साथ क्या होने वाला है जो समझौता किए गए कुंजियों का उपयोग करके एन्क्रिप्ट किए गए थे। उनके साथ समझौता किया गया है, हालांकि वे अभी भी उपयोगी हो सकते हैं और पुनर्प्राप्ति बिंदु उद्देश्य के अनुसार आवश्यक हो सकते हैं। उन्हें फिर से एन्क्रिप्ट करने या गैर-समझौता किए गए स्थानीयकरण में ले जाने सहित कुछ विकल्प हैं।

एन्क्रिप्शन प्रक्रिया को समानांतर बनाकर तेज करें

यदि आपके पास एन्क्रिप्शन प्रक्रिया के समानांतरकरण को लागू करने का विकल्प है, तो इस पर विचार करें। एन्क्रिप्शन का प्रदर्शन ज्यादातर CPU शक्ति पर निर्भर करता है, इस प्रकार अधिक CPU कोर को फ़ाइल को एन्क्रिप्ट करने के लिए समानांतर में काम करने की अनुमति देने के परिणामस्वरूप बहुत कम एन्क्रिप्शन समय होना चाहिए। कुछ एन्क्रिप्शन उपकरण ऐसा विकल्प देते हैं। उनमें से एक है एक्स्ट्राबैकअप जिसमें एम्बेडेड एन्क्रिप्शन का उपयोग करने और प्रक्रिया को समानांतर करने का विकल्प है।

आप जो खोज रहे हैं वह या तो "--encrypt-key" या "--encrypt-key-file" विकल्प है जो एम्बेडेड एन्क्रिप्शन को सक्षम करता है। ऐसा करते समय आप "--encrypt-threads" और "--encrypt-chunk-size" को भी परिभाषित कर सकते हैं। दूसरा एन्क्रिप्शन के लिए एक कार्यशील बफर को बढ़ाता है, पहले यह परिभाषित करता है कि एन्क्रिप्शन के लिए कितने थ्रेड्स का उपयोग किया जाना चाहिए।

बेशक, यह केवल उन समाधानों में से एक है जिसे आप लागू कर सकते हैं। आप इसे शेल टूल्स का उपयोग करके प्राप्त कर सकते हैं। नीचे एक उदाहरण:

[email protected]:~# files=2 ; mariabackup --user=root --backup --pass=pass --stream=xbstream  |split -b 60M - backup ; ls backup* |  parallel -j ${files} --workdir "$(pwd)" 'echo "encrypting {}" ; openssl  enc -aes-256-cbc -salt -in "{}" -k mypass > "111{}"'

यह किसी भी तरह से एक सही समाधान नहीं है क्योंकि आपको पहले से पता होना चाहिए कि कितना बड़ा, कम या ज्यादा, बैकअप इसे पूर्वनिर्धारित फ़ाइलों की पूर्वनिर्धारित संख्या में विभाजित करना होगा जो समानांतर स्तर से मेल खाते हैं जिसे आप प्राप्त करना चाहते हैं (यदि आप 2 सीपीयू का उपयोग करना चाहते हैं) कोर, आपके पास दो फाइलें होनी चाहिए, यदि आप 4 कोर, 4 फाइलें आदि का उपयोग करना चाहते हैं)। इसके लिए डिस्क स्थान की भी आवश्यकता होती है जो बैकअप के आकार से दोगुना होता है, क्योंकि पहले यह स्प्लिट का उपयोग करके कई फाइलें उत्पन्न करता है और फिर एन्क्रिप्शन एन्क्रिप्टेड फाइलों का एक और सेट बनाता है। दूसरी ओर, यदि आपका डेटा सेट आकार स्वीकार्य है और आप एन्क्रिप्शन प्रदर्शन में सुधार करना चाहते हैं, तो यह एक विकल्प है जिस पर आप विचार कर सकते हैं। बैकअप को डिक्रिप्ट करने के लिए आपको प्रत्येक व्यक्तिगत फाइल को डिक्रिप्ट करना होगा और फिर उन्हें एक साथ जोड़ने के लिए 'कैट' का उपयोग करना होगा।

अपने बैकअप का परीक्षण करें

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

आपके पास एक पुनर्स्थापना परीक्षण प्रक्रिया होनी चाहिए। आदर्श रूप से, प्रत्येक बैकअप के बाद पुनर्स्थापना परीक्षण निष्पादित किया जाएगा। कम से कम, आपको अपने बैकअप का प्रति वर्ष दो बार परीक्षण करना चाहिए। निश्चित रूप से आपको इसका परीक्षण करना होगा जैसे ही बैकअप प्रक्रिया में बदलाव शुरू किया गया था। क्या आपने बैकअप में संपीड़न जोड़ा है? क्या आपने एन्क्रिप्शन विधि बदल दी है? क्या आपने एन्क्रिप्शन कुंजी घुमाई? उन सभी कार्रवाइयों का आपके बैकअप को वास्तव में पुनर्स्थापित करने की आपकी क्षमता पर कुछ प्रभाव पड़ सकता है। इसलिए आपको हर बदलाव के बाद पूरी प्रक्रिया का परीक्षण करना सुनिश्चित करना चाहिए।

ClusterControl सत्यापन प्रक्रिया को स्वचालित कर सकता है, दोनों मांग पर या प्रत्येक बैकअप के बाद निर्धारित।

मौजूदा बैकअप को सत्यापित करने के लिए, आपको बस सूची में से एक को चुनना होगा, "पुनर्स्थापना" विकल्प पर क्लिक करना होगा और फिर पुनर्स्थापना विज़ार्ड के माध्यम से जाना होगा। सबसे पहले, आपको यह सत्यापित करना होगा कि आप किस बैकअप को पुनर्स्थापित करना चाहते हैं।

फिर, अगले चरण पर, आपको पुनर्स्थापना और सत्यापन विकल्प चुनना चाहिए।

आपको उस होस्ट के बारे में कुछ जानकारी देनी होगी जिस पर आप पुनर्स्थापना का परीक्षण करना चाहते हैं। इसे SSH के माध्यम से ClusterControl इंस्टेंस से एक्सेस करना होगा। आप पुनर्स्थापना परीक्षण सर्वर को चालू रखने का निर्णय ले सकते हैं (और यदि आप आंशिक पुनर्स्थापना के लिए जाना चाहते हैं तो उसमें से कुछ आंशिक डेटा डंप करें) या इसे बंद कर दें।

अंतिम चरण यह सत्यापित करने के बारे में है कि आपने सही विकल्प बनाए हैं या नहीं। यदि हाँ, तो आप बैकअप सत्यापन कार्य प्रारंभ कर सकते हैं।

यदि सत्यापन सफलतापूर्वक पूरा हो गया है, तो आप देखेंगे कि बैकअप को बैकअप की सूची में सत्यापित के रूप में चिह्नित किया गया है।

यदि आप इस प्रक्रिया को स्वचालित करना चाहते हैं, तो यह ClusterControl के साथ भी संभव है। बैकअप शेड्यूल करते समय आप बैकअप सत्यापन सक्षम कर सकते हैं:

यह बैकअप शेड्यूलिंग विज़ार्ड में एक और चरण जोड़ता है।

यहां आपको फिर से उस होस्ट को परिभाषित करना होगा जिसे आप बैकअप पुनर्स्थापना परीक्षणों के लिए उपयोग करना चाहते हैं, यह तय करें कि क्या आप उस पर सॉफ़्टवेयर स्थापित करना चाहते हैं (या हो सकता है कि आपने इसे पहले ही कर लिया हो), यदि आप पुनर्स्थापना सर्वर को ऊपर रखना चाहते हैं और क्या आप बैकअप के पूरा होने के तुरंत बाद उसका परीक्षण करना चाहते हैं या हो सकता है कि आप थोड़ा इंतजार करना चाहें।