उदाहरण पर हमेशा उपलब्धता समूह में SQL सर्वर में पारदर्शी डेटा एन्क्रिप्शन (TDE)

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

SQL द्वारा प्रदान किए गए दो एन्क्रिप्शन विकल्प हैं:sql tde बनाम हमेशा एन्क्रिप्टेड। इस लेख में, मैं एक परिदृश्य प्रदर्शित करने जा रहा हूँ जिसमें डीबीए को विस्तार पर अतिरिक्त ध्यान देने की आवश्यकता है। जैसा कि शीर्षक कहता है, यह डेटाबेस के भीतर डेटा एन्क्रिप्शन से निपटने के लिए उचित तरीके से आपका मार्गदर्शन करेगा जो कि ऑलवेजऑन उपलब्धता समूह सेटअप का एक हिस्सा है।

प्रारंभिक विचार

मैं अपने मामले को बनाने के लिए तकनीक के रूप में ट्रांसपेरेंट डेटा एन्क्रिप्शन (TDE) का उपयोग करूंगा। यह SQL सर्वर के सभी समर्थित संस्करणों पर लागू होता है। यह उल्लेख करना महत्वपूर्ण है कि यह सुविधा केवल निम्नलिखित SQL सर्वर संस्करणों में उपलब्ध है:

• एसक्यूएल सर्वर 2019 मूल्यांकन, मानक, डेवलपर, उद्यम
• एसक्यूएल सर्वर 2017 मूल्यांकन, डेवलपर, उद्यम
• एसक्यूएल सर्वर 2016 मूल्यांकन, डेवलपर, उद्यम
• एसक्यूएल सर्वर 2014 मूल्यांकन, डेवलपर, उद्यम
• एसक्यूएल सर्वर 2012 मूल्यांकन, डेवलपर, उद्यम
• SQL सर्वर 2008R2 डाटासेंटर, मूल्यांकन, डेवलपर, उद्यम
• एसक्यूएल सर्वर 2008 मूल्यांकन, डेवलपर, उद्यम

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

नोट: TDE सुविधा SQL सर्वर एक्सप्रेस संस्करण में समर्थित नहीं है।

इस पोस्ट में उपलब्धता समूह बनाने के चरणों को शामिल नहीं किया जाएगा, और मैं पहले से ही परीक्षण उद्देश्यों के लिए बनाए गए एक पर भरोसा कर रहा हूं। आप इस बारे में अधिक पढ़ सकते हैं कि Linux पर SQL Server AlwaysOn उपलब्धता समूहों को कैसे परिनियोजित किया जाए।

वातावरण विंडोज-आधारित है, लेकिन सिद्धांत बहुत समान होंगे यदि आप विभिन्न प्लेटफॉर्म (जैसे लिनक्स पर SQL सर्वर या Azure SQL प्रबंधित इंस्टेंस) का उपयोग करते हैं।

अस्थायी डेटा एन्क्रिप्शन क्या है

हमारे द्वारा TDE का उपयोग करने का मुख्य कारण आपके SQL डेटाबेस के लिए डेटा और लॉग फ़ाइल सुरक्षा है। अपने व्यक्तिगत डेटा को चोरी होने से बचाने के लिए, इसका बचाव करना एक अच्छा विचार है, साथ ही यह एन्क्रिप्शन प्रक्रिया बहुत आसान है। पृष्ठ को डिस्क में लिखे जाने से पहले, पृष्ठ स्तर पर फ़ाइलें एन्क्रिप्ट की जाती हैं। हर बार जब आप अपना डेटा एक्सेस करना चाहते हैं, तो यह डिक्रिप्ट हो जाता है। TDE कार्यान्वयन के बाद, आपको डेटाबेस को पुनर्स्थापित करने या संलग्न करने के लिए एक विशिष्ट प्रमाणपत्र और एक कुंजी की आवश्यकता होगी। यही एक एन्क्रिप्शन एल्गोरिथम है।

माइक्रोसॉफ्ट SQL सर्वर उपलब्धता समूह उदाहरण

मेरे परीक्षण उपलब्धता समूह में 2 प्रतिकृतियां हैं, प्रत्येक का अपना वीएम है। यहाँ बुनियादी गुण हैं:

जैसा कि आप देख सकते हैं, कुछ भी फैंसी नहीं है, सिंक्रोनस प्रतिबद्ध मोड का उपयोग करके और मैन्युअल विफलता मोड के तहत केवल कुछ प्रतिकृतियां हैं।

निम्न स्क्रीनशॉट "परीक्षण" नामक डेटाबेस को प्रदर्शित करता है। इसे SQL सर्वर ऑलवेजऑन उपलब्धता समूह में जोड़ा जाता है और यह समकालिक अवस्था में होता है।

SQL सर्वर में TDE कैसे सक्षम करें

यहाँ "परीक्षण" डेटाबेस के लिए SQL सर्वर TDE को सक्षम करने के चरण दिए गए हैं। नोट :हम वर्तमान प्राथमिक प्रतिकृति में निम्नलिखित चरणों को निष्पादित करेंगे।

चरण 1

मास्टर डेटाबेस में एक मास्टर कुंजी बनाएँ।

USE master;
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = '<UseStrongPasswordHere>';

चरण 2

मास्टर कुंजी द्वारा सुरक्षित प्रमाणपत्र बनाएं।

CREATE CERTIFICATE TestCertificate WITH SUBJECT = 'My test Certificate';

चरण 3

डेटाबेस एन्क्रिप्शन कुंजी (DEK) बनाएं और इसे चरण 2 में बनाए गए प्रमाणपत्र से सुरक्षित करें।

USE test;
GO
CREATE DATABASE ENCRYPTION KEY
WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE TestCertificate;

चरण 4

एन्क्रिप्शन का उपयोग करने के लिए "परीक्षण" डेटाबेस सेट करें।

ALTER DATABASE test
SET ENCRYPTION ON;

कैसे जांचें कि TDE सक्षम है या नहीं?

आपके द्वारा किए जाने के बाद, आपको यह पुष्टि करने की आवश्यकता है कि SQL सर्वर में पारदर्शी डेटा एन्क्रिप्शन "परीक्षण" डेटाबेस के लिए सक्षम है।

डेटाबेस गुण . में अनुभाग में, विकल्प पर जाएं पृष्ठ। वहां, राज्य पर ध्यान दें खिड़की के नीचे का क्षेत्र। एन्क्रिप्शन सक्षम किया गया मान सत्य होना चाहिए ।

इसकी पुष्टि के लिए आप निम्न TSQL कोड भी चला सकते हैं:

SELECT name,is_encrypted
FROM sys.databases
WHERE name = 'test'

प्रमुख प्रबंधन और प्रमाणन समस्या

नोट: अगर आपको पता चले कि tempdb भी एन्क्रिप्ट किया गया है तो आश्चर्यचकित न हों। ऐसा इसलिए है क्योंकि tempdb वह जगह है जहां सभी डेटाबेस से डेटा का उपयोग करके सभी प्रकार के संचालन (जैसे सॉर्टिंग, हैश जॉइन इत्यादि) होते हैं। इसलिए, यदि कम से कम एक उपयोगकर्ता डेटाबेस एन्क्रिप्ट किया गया है, तो उस विशेष डेटाबेस से संचालन tempdb में जा सकता है, जिसे उस डेटा को उपयोगकर्ता डेटाबेस में वापस करने की आवश्यकता होगी। इसलिए, अनएन्क्रिप्टेड डेटा को वापस भेजना समस्या का प्रतिनिधित्व करेगा।

आप अपने डेटाबेस की सुरक्षा बढ़ाने के लिए SQL सर्वर में बैकअप एन्क्रिप्शन के बारे में अधिक पढ़ सकते हैं।

आप निम्न TSQL कोड का उपयोग यह पुष्टि करने के लिए कर सकते हैं कि "परीक्षण" डेटाबेस के लिए एक डेटाबेस मास्टर कुंजी मौजूद है जो प्रमाणपत्र द्वारा एन्क्रिप्ट किया गया है (जैसा कि चरण 3 में निष्पादित किया गया है):

SELECT 
	DB_NAME(database_id) AS DB,
	create_date,
	key_algorithm,
	key_length,
	encryptor_thumbprint,
	encryptor_type
FROM sys.dm_database_encryption_keys
WHERE DB_NAME(database_id) = 'test'

अब तक इतना अच्छा, कम से कम प्राथमिक प्रतिकृति के लिए। लेकिन क्या होता है अगर हम sys.databases . को क्वेरी करते हैं द्वितीयक प्रतिकृति में "परीक्षण" डेटाबेस की एन्क्रिप्शन स्थिति की पुष्टि करने के लिए सिस्टम दृश्य?

उपलब्धता समूह डेटाबेस से संबंधित हर चीज को एक प्रतिकृति से दूसरी प्रतिकृति में दोहराता है। हालांकि, सेकेंडरी रेप्लिका स्पष्ट रूप से बताती है कि यह एन्क्रिप्टेड नहीं है।

आइए इसके बारे में किसी भी सुराग के लिए हमारी माध्यमिक प्रतिकृति देखें:

डेटाबेस की स्थिति है “सिंक्रोनाइज़िंग नहीं/संदिग्ध” – बिल्कुल अच्छा नहीं लग रहा। हालाँकि, द्वितीयक प्रतिकृति के त्रुटि लॉग का निरीक्षण करने के बाद, मैं निम्नलिखित देख सकता हूँ:

2021-04-10 00:40:55.940	spid39s	Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.940	spid39s	Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950	spid39s	Error: 33111, Severity: 16, State: 3.
2021-04-10 00:40:55.950	spid39s	Cannot find server certificate with thumbprint '0xDF36E3D052086AA05BBB1C64A72A2CAB5A98F240'.
2021-04-10 00:40:55.950	spid39s	Always On Availability Groups data movement for database 'test' has been suspended for the following reason: "system" (Source ID 2; Source string: 'SUSPEND_FROM_REDO'). To resume data movement on the database, you will need to resume the database manually. For information about how to resume an availability database, see SQL Server Books Online.
2021-04-10 00:40:55.950	spid39s	Error: 3313, Severity: 21, State: 2.
2021-04-10 00:40:55.950	spid39s	During redoing of a logged operation in database 'test', an error occurred at log record ID (34:743:1). Typically, the specific failure is previously logged as an error in the Windows Event Log service. Restore the database from a full backup, or repair the database.  

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

क्यों?

क्योंकि उपलब्धता समूह सिस्टम डेटाबेस से डेटा की प्रतिकृति नहीं बनाते हैं। अनुपलब्ध सर्वर प्रमाणपत्र प्राथमिक प्रतिकृति मास्टर डेटाबेस में रहता है।

SQL सर्वर में TDE प्रमाणपत्र कैसे जांचें और सेट करें

आइए प्राइमरी रेप्लिका मास्टर डेटाबेस में सर्वर सर्टिफिकेट का बैकअप जेनरेट करें। फिर इसे सेकेंडरी रेप्लिका के मास्टर डेटाबेस में पुनर्स्थापित करते हैं।

वर्तमान प्राथमिक प्रतिकृति से बैकअप उत्पन्न करने के लिए निम्नलिखित TSQL कोड का उपयोग करें जिसमें TDE सक्षम के साथ "परीक्षण" डेटाबेस है:

USE master;
GO
BACKUP CERTIFICATE TestCertificate
TO FILE = 'C:\temp\TestCertificate.cer'                                                          
WITH PRIVATE KEY (file='C:\temp\TestCertificate.pvk',
ENCRYPTION BY PASSWORD='<YourStrongPasswordHere>');

द्वितीयक प्रतिकृति में प्रमाणपत्र को पुनर्स्थापित करने का प्रयास करने से पहले, पहले जांच लें कि क्या डेटाबेस मास्टर कुंजी मास्टर डेटाबेस में मौजूद है। यदि नहीं, तो इसे ठीक चरण 1 की तरह बनाएं।

द्वितीयक प्रतिकृति में प्रमाणपत्र को पुनर्स्थापित करने के लिए निम्न TSQL कोड का उपयोग करें। नोट :पहले .cer और .pvk फ़ाइलों को लक्ष्य निर्देशिका में कॉपी करना सुनिश्चित करें।

USE master;
GO
CREATE CERTIFICATE TestCertificate
  FROM FILE = 'C:\temp\TestCertificate.cer'
  WITH PRIVATE KEY ( 
    FILE = N'C:\temp\TestCertificate.pvk',
 DECRYPTION BY PASSWORD = '<YourStrongPasswordHere>'
  );

इस प्रकार, द्वितीयक प्रतिकृति में प्रमाणपत्र को पुनर्स्थापित करने के बाद भी, "परीक्षण" डेटाबेस की स्थिति समान रहती है:

चूंकि "परीक्षण" डेटाबेस के लिए डेटा आंदोलन रुका हुआ है, आइए इसे मैन्युअल रूप से देखें कि क्या हम इस बार भाग्यशाली हैं:

हां! ऑपरेशन सफल रहा। "परीक्षण" डेटाबेस न केवल पूरी तरह से सिंक्रनाइज़ और स्वस्थ है बल्कि टीडीई के साथ एन्क्रिप्टेड भी है।

इसके अलावा, प्रतिकृतियों की भूमिकाओं को स्वैप करने के लिए मैन्युअल विफलता के प्रदर्शन के बाद, सब कुछ पूरी तरह से ठीक काम करना जारी रखता है।

निष्कर्ष

दिखाया गया समाधान पूरी तरह से ठीक काम करता है। हालांकि, यह सभी मामलों में आदर्श नहीं हो सकता है, खासकर यदि आप एक डीबीए हैं जो योजना बनाना और चीजों को "सही" तरीके से करना पसंद करते हैं। मुझे "सही" इस प्रकार दिखाई देता है:

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

मैं "सही" के लिए डबल-कोट्स फेंक रहा हूं क्योंकि जिस तरह से मैंने समाधान प्रस्तुत किया है, मुझे द्वितीयक प्रतिकृति में संदिग्ध के रूप में चिह्नित डेटाबेस मिला है। यह अकेले शायद कई अवांछित झंडे/अलर्ट/उंगली-पॉइंटिंग उठाएगा। यह अनावश्यक शोर है जिसे आप ऑलवेज ऑन अवेलेबिलिटी ग्रुप सेटअप में टीडीई की योजना बनाने और ठीक से लागू करने के लिए सभी विचारों को ध्यान में रखते हुए आसानी से टाल सकते हैं।

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

यदि आप जागरूक नहीं हैं, तो SQL पूर्ण हमेशा एन्क्रिप्टेड को कॉन्फ़िगर करने में आपकी बहुत सहायता कर सकता है, जो संवेदनशील डेटा की सुरक्षा के लिए एक और उपयोगी तकनीक है।

ध्यान रखें कि यदि आप हमेशा उपलब्धता समूह परिदृश्य में हमेशा एन्क्रिप्टेड से निपटने की योजना बना रहे हैं तो आपको उसी पर विचार करने की आवश्यकता होगी जिस पर इस आलेख में चर्चा की गई है। हालाँकि, SQL पूर्ण v6.7 द्वारा पेश की जाने वाली सुविधाएँ यह सुनिश्चित करने के लिए डिज़ाइन की गई हैं कि आप बल्ले से ही सफल हों।