Microsoft के पास SQL सर्वर 2017 में कई सुरक्षा सुविधाएँ हैं जो विभिन्न उद्देश्यों के लिए उपयोगी हैं, यह इस बात पर निर्भर करता है कि आप किस चीज़ की रक्षा करने का प्रयास कर रहे हैं और आप किस खतरे से बचाव करने का प्रयास कर रहे हैं। इन सुरक्षा सुविधाओं में से कुछ के प्रदर्शन निहितार्थ हो सकते हैं जिनके बारे में आपको पता होना चाहिए क्योंकि आप तय करते हैं कि आप किसे लागू करना चाहते हैं। एक परिचय के रूप में, मैं इनमें से कई सुरक्षा सुविधाओं के कुछ मुख्य अंशों को शामिल करूँगा।
पारदर्शी डेटाबेस एन्क्रिप्शन (TDE)
ट्रांसपेरेंट डेटा एन्क्रिप्शन (TDE) SQL सर्वर का रेस्ट पर एन्क्रिप्शन का रूप है, जिसका अर्थ है कि आपकी डेटा फ़ाइलें, लॉग फ़ाइल, tempdb फ़ाइलें, और आपका SQL सर्वर पूर्ण, अंतर और लॉग बैकअप एन्क्रिप्ट किया जाएगा जब आप किसी उपयोगकर्ता डेटाबेस पर TDE को सक्षम करते हैं . यह आपके डेटा को उन डेटाबेस या डेटाबेस बैकअप फ़ाइलों तक पहुंचने वाले किसी व्यक्ति से तब तक सुरक्षित रखता है जब तक कि उस व्यक्ति के पास आपके एन्क्रिप्शन प्रमाणपत्र और कुंजी तक पहुंच न हो।
उपयोगकर्ता डेटाबेस के लिए प्रारंभिक टीडीई एन्क्रिप्शन स्कैन डेटाबेस में प्रति डेटा फ़ाइल में एक पृष्ठभूमि सीपीयू थ्रेड का उपयोग करेगा (यदि डेटा फ़ाइलें अलग लॉजिकल ड्राइव पर स्थित हैं), धीरे-धीरे डेटा फ़ाइल की संपूर्ण सामग्री को मेमोरी में पढ़ने की दर से लगभग 52MB/सेकंड प्रति डेटा फ़ाइल (यदि डेटा फ़ाइलें अलग लॉजिकल ड्राइव पर स्थित हैं)।
डेटा को तब आपके चुने हुए एन्क्रिप्शन एल्गोरिथम के साथ एन्क्रिप्ट किया जाता है, और फिर डेटा फ़ाइल में लगभग 55MB/प्रति सेकंड (प्रति डेटा फ़ाइल, यदि वे अलग लॉजिकल ड्राइव पर हैं) पर वापस लिखा जाता है। ये क्रमिक पढ़ने और लिखने की दरें जानबूझकर थ्रॉटल की गई प्रतीत होती हैं और विभिन्न प्रकार के भंडारण के साथ कई प्रणालियों पर मेरे परीक्षण में सुसंगत हैं।
प्रारंभिक TDE एन्क्रिप्शन प्रक्रिया SQL सर्वर के नीचे पृष्ठ स्तर पर होती है, इसलिए यह लॉकिंग या लेनदेन लॉग गतिविधि उत्पन्न नहीं करता है जैसा कि आप किसी इंडेक्स के पुनर्निर्माण के साथ देखेंगे। आप वैश्विक TF 5004 को सक्षम करके एक TDE एन्क्रिप्शन स्कैन को रोक सकते हैं, और TF 5004 को अक्षम करके और अपने ALTER DATABASE dbNAME SET ENCRYTION ON कमांड को फिर से चलाकर, बिना किसी प्रगति के नुकसान के इसे रोक सकते हैं।
एन्क्रिप्शन/डिक्रिप्शन का CPU प्रभाव SQL Server 2016 और नए पर बहुत कम हो जाता है यदि आपके पास एक ऐसा प्रोसेसर है जो AES-NI हार्डवेयर निर्देशों का समर्थन करता है। सर्वर स्पेस में, इन्हें दो-सॉकेट सर्वरों के लिए Intel Xeon 5600 उत्पाद परिवार (Westmere-EP) और चार और आठ-सॉकेट सर्वरों के लिए Intel Xeon E7-4800/8800 उत्पाद परिवार (Westmere-EX) में पेश किया गया था। किसी भी नए इंटेल उत्पाद परिवार के पास एईएस-एनआई समर्थन भी होगा। यदि आपको संदेह है कि आपका प्रोसेसर एईएस-एनआई का समर्थन करता है या नहीं, तो आप सीपीयू-जेड से निर्देश फ़ील्ड आउटपुट में "एईएस" की तलाश कर सकते हैं, जैसा कि आप चित्र 1 में देखते हैं।
चित्र 1:CPU-Z आउटपुट AES निर्देश समर्थन दिखा रहा है
आपके द्वारा TDE के साथ एक डेटाबेस को एन्क्रिप्ट करने के बाद, TDE के रनटाइम प्रभाव का अनुमान लगाना कठिन है क्योंकि यह पूरी तरह से आपके कार्यभार पर निर्भर करता है। उदाहरण के लिए, यदि आपका कार्यभार पूरी तरह से SQL सर्वर बफर पूल में फिट बैठता है तो अनिवार्य रूप से TDE से शून्य ओवरहेड होगा। यदि दूसरी ओर आपके कार्यभार में पूरी तरह से टेबल स्कैन शामिल हैं जहां पृष्ठ पढ़ा जाता है और फिर लगभग तुरंत फ़्लश हो जाता है जो अधिकतम जुर्माना लगाएगा। I/O अस्थिर कार्यभार के लिए अधिकतम दंड आमतौर पर आधुनिक हार्डवेयर और SQL Server 2016 या बाद के संस्करण के साथ 5% से कम है।
TDE डिक्रिप्शन का अतिरिक्त कार्य तब होता है जब आप डेटा को स्टोरेज से बफर पूल में पढ़ते हैं, और TDE एन्क्रिप्शन का अतिरिक्त कार्य तब होता है जब आप डेटा को वापस स्टोरेज में लिखते हैं। यह सुनिश्चित करना कि आप मेमोरी के दबाव में नहीं हैं, एक बड़ा पर्याप्त बफर पूल होने से और इंडेक्स और क्वेरी ट्यूनिंग करने से स्पष्ट रूप से टीडीई के प्रदर्शन प्रभाव में कमी आएगी। TDE FILESTREAM डेटा को एन्क्रिप्ट नहीं करता है, और एक TDE एन्क्रिप्टेड डेटाबेस अपनी डेटा फ़ाइलों के लिए त्वरित फ़ाइल आरंभीकरण का उपयोग नहीं करेगा।
SQL सर्वर 2016 से पहले, TDE और नेटिव बैकअप कम्प्रेशन एक साथ अच्छी तरह से काम नहीं करते थे। SQL सर्वर 2016 और बाद के संस्करण के साथ, आप TDE और मूल बैकअप संपीड़न का एक साथ उपयोग कर सकते हैं, जब तक कि आप एक MAXTRANSFERSIZE निर्दिष्ट करते हैं जो कि बैकअप कमांड में 64K से अधिक है। यह भी बहुत महत्वपूर्ण है कि आप अपने संचयी अपडेट के साथ वर्तमान हैं, क्योंकि SQL सर्वर 2016 और SQL सर्वर 2017 दोनों के लिए कई महत्वपूर्ण TDE-संबंधित हॉटफिक्स हैं। अंत में, TDE अभी भी है और केवल एंटरप्राइज़ संस्करण SQL सर्वर 2016 के बाद भी सुविधा है। SP1 (जिसने मानक संस्करण में कई केवल-एंटरप्राइज़ सुविधाएँ जोड़ी हैं)।
पंक्ति-स्तरीय सुरक्षा (आरएलएस)
रो-लेवल सिक्योरिटी (आरएलएस) उपयोगकर्ता की विशेषताओं के आधार पर रीड एक्सेस और अधिकांश राइट-लेवल एक्सेस को सीमित करता है। RLS विधेय-आधारित अभिगम नियंत्रण कहलाती है। SQL सर्वर डेटाबेस टियर में एक्सेस प्रतिबंध लागू करता है, और जब भी किसी भी स्तर से डेटा एक्सेस करने का प्रयास किया जाता है, तो उन्हें हर बार लागू किया जाएगा।
RLS एक विधेय फ़ंक्शन बनाकर काम करता है जो उन पंक्तियों को सीमित करता है जिन तक उपयोगकर्ता पहुंच सकता है और फिर उस फ़ंक्शन को किसी तालिका में लागू करने के लिए सुरक्षा नीति और सुरक्षा विधेय का उपयोग करता है।
सुरक्षा विधेय दो प्रकार के होते हैं, जो फ़िल्टर विधेय और ब्लॉक विधेय हैं। फ़िल्टर विधेय अनिवार्य रूप से एक WHERE क्लॉज जोड़कर पढ़ने के संचालन के लिए उपलब्ध पंक्तियों को चुपचाप फ़िल्टर करेगा (चयन करें, अद्यतन करें, और हटाएं), जो फ़िल्टर की गई पंक्तियों को परिणाम सेट में दिखने से रोकता है। आधार तालिका से डेटा पढ़ते समय फ़िल्टर विधेय लागू किया जाता है, और उपयोगकर्ता या एप्लिकेशन को यह नहीं पता होगा कि परिणामों से पंक्तियों को फ़िल्टर किया जा रहा है। प्रदर्शन के दृष्टिकोण से यह महत्वपूर्ण है कि एक पंक्ति स्टोर इंडेक्स हो जो आपके RLS फ़िल्टर विधेय को कवर करता हो।
ब्लॉक स्पष्ट रूप से विधेय करता है, (एक त्रुटि संदेश के साथ) ब्लॉक राइट ऑपरेशंस (इन्सर्ट के बाद, अपडेट के बाद, अपडेट से पहले, और डिलीट करने से पहले) जो ब्लॉक विधेय का उल्लंघन करेगा।
फ़िल्टर और ब्लॉक विधेय इनलाइन तालिका-मूल्यवान फ़ंक्शन के रूप में बनाए जाते हैं। फ़िल्टरिंग फ़ंक्शन को प्रासंगिक बेस टेबल पर लागू करने और सक्षम करने के लिए आपको CREATE SECURITY POLICY T-SQL स्टेटमेंट का उपयोग करने की भी आवश्यकता होगी
RLS को SQL Server 2016 में जोड़ा गया था और यह SQL Server 2016 और नए के सभी संस्करणों में उपलब्ध है। आरएलएस फाइलस्ट्रीम, पॉलीबेस और अनुक्रमित दृश्यों के साथ काम नहीं करेगा। आरएलएस पूर्ण-पाठ खोज के प्रदर्शन को नुकसान पहुंचा सकता है और यह कॉलमस्टोर इंडेक्स प्रश्नों को बैच मोड के बजाय पंक्ति मोड का उपयोग करके समाप्त करने के लिए मजबूर कर सकता है। इस Microsoft ब्लॉग पोस्ट में RLS के प्रदर्शन प्रभाव के बारे में अधिक जानकारी है। आरएलएस प्रदर्शन को ट्यून करने के लिए क्वेरी स्टोर का उपयोग करने का एक अच्छा उदाहरण यहां है।
डायनामिक डेटा मास्किंग (DDM)
डायनामिक डेटा मास्किंग (DDM) संवेदनशील डेटा एक्सपोज़र को गैर-विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए मास्क करके सीमित करने में मदद कर सकता है। DDM तालिका-स्तर पर लागू किया जाता है, इसलिए सभी प्रश्न डेटा मास्किंग से प्रभावित होते हैं, जबकि वास्तविक मास्किंग नियम तालिका में अलग-अलग कॉलम में लागू होते हैं।
आप चार प्रकार के डेटा मास्क का उपयोग कर सकते हैं, जिनमें डिफ़ॉल्ट, ईमेल, कस्टम स्ट्रिंग और यादृच्छिक शामिल हैं। एक डिफ़ॉल्ट मास्क डेटा प्रकार के आधार पर डेटा का पूर्ण डिफ़ॉल्ट मास्किंग प्रदान करता है। उदाहरण के लिए, एक स्ट्रिंग डेटा प्रकार को वास्तविक डेटा के बजाय 'XXXX' का मास्क मिलेगा। एक ईमेल मास्क वास्तविक ईमेल पते का पहला अक्षर लौटाएगा, उसके बाद [email protected] के साथ, वास्तविक डोमेन प्रत्यय की परवाह किए बिना। एक कस्टम स्ट्रिंग मास्क बीच में एक कस्टम पैडिंग के साथ स्ट्रिंग के पहले और आखिरी अक्षर दिखाएगा। अंत में, एक यादृच्छिक मुखौटा का उपयोग संख्यात्मक डेटा को मुखौटा करने और एक परिभाषित सीमा में एक यादृच्छिक मान प्रदान करने के लिए किया जाता है। डेटा मास्क को CREATE TABLE स्टेटमेंट में या ALTER COLUMN स्टेटमेंट के साथ बनाया जा सकता है।
डायनामिक डेटा मास्किंग विशेषाधिकार प्राप्त उपयोगकर्ताओं के लिए कोई मास्किंग प्रदान नहीं करता है जो अभी भी सीधे आपकी टेबल से पूछताछ कर सकते हैं और बिना मास्क वाले डेटा देख सकते हैं। मास्किंग नियमों का उपयोग एन्क्रिप्टेड कॉलम (हमेशा एन्क्रिप्टेड), कंप्यूटेड कॉलम या फाइलस्ट्रीम डेटा के साथ नहीं किया जा सकता है। यदि किसी कॉलम पर मौजूदा इंडेक्स हैं जिन्हें आप मास्क करना चाहते हैं, तो आपको इंडेक्स को छोड़ना होगा, कॉलम पर मास्क बनाना होगा और फिर इंडेक्स को फिर से बनाना होगा। उन प्रश्नों को लिखकर मास्क किए गए डेटा कॉलम के मानों का अनुमान लगाना भी संभव है जो उपयोगकर्ता को अंततः एक नकाबपोश कॉलम के लिए मान का अनुमान लगाने की अनुमति देते हैं।
डायनामिक डेटा मास्किंग को SQL सर्वर 2016 में पेश किया गया था, और यह SQL सर्वर के सभी संस्करणों में उपलब्ध है। डीडीएम वास्तविक एन्क्रिप्शन की तरह एक मजबूत सुरक्षा उपाय नहीं है, लेकिन दूसरी ओर, इसका प्रदर्शन प्रभाव काफी नगण्य प्रतीत होता है।
