SQL Server 2016 में रो-लेवल सिक्योरिटी के साथ डेटा सुरक्षा बढ़ाएं

Microsoft® ने SQL Server® में सुरक्षा पर ध्यान केंद्रित किया है, और लगभग सभी रिलीज़ में या तो मौजूदा सुविधाओं में वृद्धि हुई है या नई सुरक्षा सुविधाएं पेश की गई हैं। SQL Server 2016 में, Microsoft ने उपयोगकर्ताओं को अपने डेटा की सुरक्षा में मदद करने के लिए कई नई सुरक्षा सुविधाएं पेश कीं, जिनमें रो-लेवल सिक्योरिटी, ऑलवेज एन्क्रिप्टेड, और डायनामिक डेटा मास्किंग शामिल हैं।

परिचय

मेरे पिछले ब्लॉग में, मैंने SQL Server 2016 में डायनामिक डेटा मास्किंग के बारे में लिखा था। इस ब्लॉग में, मैं रो-लेवल सिक्योरिटी (RLS) सुविधा का परिचय देता हूं, जो आपको यह नियंत्रित करने में सक्षम बनाती है कि किन उपयोगकर्ताओं की टेबल में पंक्तियों तक पहुंच है। RLS आपको क्वेरी निष्पादित करने वाले उपयोगकर्ता की विशेषताओं के आधार पर डेटा पर प्रतिबंध लागू करने में सक्षम बनाता है। RLS आपको विभिन्न उपयोगकर्ताओं के लिए पूर्ण पारदर्शिता के साथ डेटा तक पहुंच को आसानी से नियंत्रित करने में मदद करता है।

RLS की आवश्यकता

ऐसे समय होते हैं जब हमें चुनिंदा उपयोगकर्ताओं को केवल चुनिंदा डेटा वापस करने की आवश्यकता होती है। अतीत में, हम व्यू बनाकर और उन व्यू पर उपयोगकर्ता चयन अनुमति देकर ऐसा करते थे। हालांकि, डेटा की बढ़ती मात्रा और उपयोगकर्ताओं की संख्या को समायोजित करने के लिए आवश्यक व्यू की संख्या के साथ वह दृष्टिकोण अनियंत्रणीय हो गया। इसलिए Microsoft ने नई परिस्थितियों में सुरक्षा आवश्यकता को पूरा करने के लिए RLS पेश किया।

RLS टेबल में पंक्तियों तक पहुंच पर फाइन-ग्रेन्ड नियंत्रण सक्षम करता है, जिससे आप एप्लिकेशन के लिए पूर्ण पारदर्शिता के साथ आसानी से नियंत्रित कर सकते हैं कि कौन से उपयोगकर्ता किस डेटा तक पहुंच सकते हैं।

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

SQL Server 2016 में रो-लेवल सिक्योरिटी के साथ डेटा सुरक्षा बढ़ाएं

छवि स्रोत: https://sqlwithmanoj.com/2015/07/13/implementing-row-level-security-rls-with-sql-server-2016/

RLS गुण

RLS के निम्नलिखित गुण हैं:

फाइन-ग्रेन्ड एक्सेस भूमिका (विशिष्ट पंक्तियों पर पढ़ने और लिखने दोनों पहुंच को नियंत्रित करें)
एप्लिकेशन पारदर्शिता (कोई एप्लिकेशन परिवर्तन आवश्यक नहीं)
डेटाबेस के भीतर एक्सेस को केंद्रीकृत करें
कार्यान्वयन और रखरखाव में आसान

RLS कैसे काम करता है

RLS लागू करने के लिए, आपको निम्नलिखित तत्वों पर विचार करने की आवश्यकता है:

प्रेडिकेट फ़ंक्शन
सिक्योरिटी प्रेडिकेट
सिक्योरिटी पॉलिसी

निम्नलिखित अनुभाग इन आइटम का वर्णन करते हैं।

प्रेडिकेट फ़ंक्शन

एक प्रेडिकेट फ़ंक्शन एक इन-लाइन टेबल वैल्यू फ़ंक्शन है जो जांचता है कि क्वेरी निष्पादित करने वाले उपयोगकर्ता की उस पर परिभाषित तर्क के आधार पर डेटा तक पहुंच है या नहीं। यह फ़ंक्शन प्रत्येक पंक्ति के लिए 1 लौटाता है जिसे एक्सेस करने की अनुमति है।

सिक्योरिटी प्रेडिकेट

सिक्योरिटी प्रेडिकेट प्रेडिकेट फ़ंक्शन को टेबल से बांधने में मदद करता है। RLS दो प्रकार के सिक्योरिटी प्रेडिकेट का समर्थन करता है: फ़िल्टर प्रेडिकेट और ब्लॉक प्रेडिकेट। फ़िल्टर प्रेडिकेट प्रेडिकेट फ़ंक्शन में परिभाषित तर्क के अनुसार निम्नलिखित ऑपरेशन के लिए चुपचाप डेटा को फ़िल्टर करता है बिना किसी त्रुटि के:

SELECT
UPDATE
DELETE

ब्लॉक प्रेडिकेट स्पष्ट रूप से एक त्रुटि उत्पन्न करता है और उपयोगकर्ता को प्रेडिकेट फ़ंक्शन तर्क का उल्लंघन करने वाले डेटा पर निम्नलिखित ऑपरेशन का उपयोग करने से रोकता है:

AFTER INSERT
AFTER UPDATE
BEFORE UPDATE
BEFORE DELETE

सिक्योरिटी पॉलिसी

एक सिक्योरिटी पॉलिसी ऑब्जेक्ट RLS के लिए बनाया जाता है जो प्रेडिकेट फ़ंक्शन को संदर्भित करने वाले सभी सिक्योरिटी प्रेडिकेट को समूहित करता है।

उपयोग के मामले

यहां कुछ डिज़ाइन उदाहरण हैं कि RLS का उपयोग कैसे किया जा सकता है:

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

RLS लागू करें

RLS को लागू करने का एक उदाहरण निम्नलिखित है:

चरण 1: RowFilter डेटाबेस बनाने और टेस्ट के लिए दो उपयोगकर्ता बनाने के लिए निम्न कोड चलाएं:

CREATE DATABASE RowFilter; 
GO 
USE RowFilter; 
GO 
CREATE USER userBrian WITHOUT LOGIN; 
CREATE USER userJames WITHOUT LOGIN; 
GO

चरण 2: उदाहरणों के साथ एक टेबल बनाने और नए उपयोगकर्ताओं को SELECT विशेषाधिकार देने के लिए निम्न कोड चलाएं:

CREATE TABLE dbo.SalesFigures ( 
[userCode] NVARCHAR(10), 
[sales] MONEY) 
GO 
INSERT INTO dbo.SalesFigures VALUES ('userBrian',100), ('userJames',250), ('userBrian',350) 
GO 
GRANT SELECT ON dbo.SalesFigures TO userBrian 
GRANT SELECT ON dbo.SalesFigures TO userJames 
GO

चरण 3: फ़िल्टर प्रेडिकेट फ़ंक्शन जोड़ने के लिए निम्न कोड चलाएं:

CREATE FUNCTION dbo.rowLevelPredicate (@userCode as sysname) 
RETURNS TABLE 
WITH SCHEMABINDING 
AS 
RETURN SELECT 1 AS rowLevelPredicateResult WHERE @userCode = USER_NAME(); 
GO

चरण 4: dbo.SalesFigures टेबल पर फ़िल्टर प्रेडिकेट जोड़ने के लिए निम्न कोड चलाएं:

CREATE SECURITY POLICY UserFilter 
ADD FILTER PREDICATE dbo.rowLevelPredicate(userCode) ON dbo.SalesFigures 
WITH (STATE = ON); 
GO

चरण 5: चरण 2 में जोड़े गए उपयोगकर्ता के साथ परिणामों का टेस्ट करने के लिए निम्न कोड चलाएं:

EXECUTE AS USER = 'userBrian'; 
SELECT * FROM dbo.SalesFigures; 
REVERT; 
GO

यह कोड दो पंक्तियाँ लौटाता है, जैसा कि नीचे दिखाया गया है:

EXECUTE AS USER = 'userJames'; 
SELECT * FROM dbo.SalesFigures; 
REVERT; 
GO

यह कोड एक पंक्ति लौटाता है, जैसा कि नीचे दिखाया गया है:

अनुमतियां

सिक्योरिटी पॉलिसी बनाने, बदलने या हटाने के लिए ALTER ANY SECURITY POLICY अनुमति की आवश्यकता होती है।

सिक्योरिटी पॉलिसी बनाने या हटाने के लिए स्कीमा पर ALTER अनुमति की आवश्यकता होती है।

इसके अतिरिक्त, प्रत्येक प्रेडिकेट के लिए निम्नलिखित अनुमतियों की आवश्यकता होती है, जो जोड़ी जाती हैं:

प्रेडिकेट के रूप में उपयोग किए जाने वाले फ़ंक्शन पर SELECT और REFERENCES अनुमतियां।
पॉलिसी से बंधे लक्ष्य टेबल पर REFERENCES अनुमति।
लक्ष्य टेबल से उपयोग किए जाने वाले प्रत्येक कॉलम पर तर्क के रूप में REFERENCES अनुमति।

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

यदि सिक्योरिटी पॉलिसी SCHEMABINDING = OFF के साथ बनाई गई है, तो उपयोगकर्ताओं को प्रेडिकेट फ़ंक्शन और प्रेडिकेट फ़ंक्शन के भीतर उपयोग किए जाने वाले किसी भी अतिरिक्त टेबल, व्यू, या फ़ंक्शन पर SELECT या EXECUTE अनुमति होनी चाहिए ताकि लक्ष्य टेबल को क्वेरी किया जा सके। यदि सिक्योरिटी पॉलिसी SCHEMABINDING = ON के साथ बनाई गई है, जो डिफ़ॉल्ट है, तो जब उपयोगकर्ता लक्ष्य टेबल को क्वेरी करते हैं तो ये अनुमति जांच बायपास हो जाती है।

SQL Server 2016 RLS संशोधित करना

किसी पॉलिसी के लिए SQL Server RLS को अक्षम करने के लिए निम्न कार्य करें:

UseFilter सिक्योरिटी पॉलिसी को State = off के साथ बदलें।

फ़िल्टर और सिक्योरिटी पॉलिसी को हटाने के लिए निम्न कार्य करें:

UseFilter सिक्योरिटी पॉलिसी को हटाएं।
dbo.rowlevelPredicate फ़ंक्शन को हटाएं।

सर्वोत्तम अभ्यास

Microsoft ये सर्वोत्तम अभ्यास सुझाता है:

हम अत्यधिक अनुशंसा करते हैं कि आप RLS ऑब्जेक्ट्स (प्रेडिकेट फ़ंक्शन और सिक्योरिटी पॉलिसी) के लिए एक अलग स्कीमा बनाएं।
ALTER ANY SECURITY POLICY अनुमति उच्च-विशेषाधिकार प्राप्त उपयोगकर्ताओं (जैसे सिक्योरिटी पॉलिसी मैनेजर) के लिए अभिप्रेत है। सिक्योरिटी पॉलिसी मैनेजर को उन टेबल पर SELECT अनुमति की आवश्यकता नहीं होती जिनकी वे रक्षा करते हैं।
प्रेडिकेट फ़ंक्शन में प्रकार रूपांतरण से बचें ताकि संभावित रनटाइम त्रुटियों से बचा जा सके।
जहां भी संभव हो प्रेडिकेट फ़ंक्शन में रिकर्सन से बचें ताकि प्रदर्शन गिरावट से बचा जा सके। क्वेरी ऑप्टिमाइज़र डायरेक्ट रिकर्सन का पता लगाने की कोशिश करता है। हालांकि, यह इनडायरेक्ट रिकर्सन (जैसे जब कोई दूसरा फ़ंक्शन प्रेडिकेट फ़ंक्शन को कॉल करता है) को खोजने की गारंटी नहीं देता।
प्रदर्शन को अधिकतम करने के लिए प्रेडिकेट फ़ंक्शन में अत्यधिक टेबल जॉइन से बचें।

RLS में सीमाएं और प्रतिबंध

RLS पर लागू होने वाली कुछ सीमाएं निम्नलिखित हैं:

प्रेडिकेट फ़ंक्शन को SCHEMABINDING के साथ बनाया जाना चाहिए। यदि कोई फ़ंक्शन SCHEMABINDING के बिना बनाया गया है, और आप इसे सिक्योरिटी पॉलिसी से बांधने का प्रयास करते हैं, तो यह एक त्रुटि फेंकता है।
इंडेक्स्ड व्यू उस टेबल पर नहीं बनाए जा सकते जिस पर RLS लागू है।
इन-मेमोरी टेबल RLS के लिए समर्थित नहीं हैं।
फुल-टेक्स्ट इंडेक्स समर्थित नहीं हैं।

निष्कर्ष

SQL Server 2016 में RLS सुविधा के साथ, आप एप्लिकेशन लेवल पर परिवर्तन किए बिना डेटाबेस लेवल पर रिकॉर्ड के लिए सुरक्षा प्रदान कर सकते हैं। आप अपने मौजूदा कोड के साथ प्रेडिकेट फ़ंक्शन और नई सिक्योरिटी पॉलिसी सुविधा का उपयोग करके RLS लागू कर सकते हैं, बिना अपने डेटाबेस में डेटा मैनिपुलेशन लैंग्वेज (DML) कोड को बदले।

टिप्पणी करने या प्रश्न पूछने के लिए फीडबैक टैब का उपयोग करें।

विशेषज्ञ प्रशासन, प्रबंधन और कॉन्फ़िगरेशन के साथ अपने वातावरण को अनुकूलित करें

Rackspace के एप्लिकेशन सर्विसेज (RAS) विशेषज्ञ अनुप्रयोगों के एक विस्तृत पोर्टफोलियो में निम्नलिखित पेशेवर और प्रबंधित सेवाएं प्रदान करते हैं:

ईकॉमर्स और डिजिटल एक्सपीरियंस प्लेटफॉर्म
एंटरप्राइज रिसोर्स प्लानिंग (ERP)
बिजनेस इंटेलिजेंस
सेल्सफोर्स कस्टमर रिलेशनशिप मैनेजमेंट (CRM)
डेटाबेस
ईमेल होस्टिंग और उत्पादकता

हम प्रदान करते हैं:

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

अभी चैट करें शुरू करने के लिए।