पंक्ति स्तरीय सुरक्षा का गहन अन्वेषण

परिचय

समेकन का उपयोग करके डेटाबेस समाधानों को लाइसेंस देने की लागत को कम करने के तरीके के बारे में संगठन अधिक से अधिक चिंतित हो रहे हैं। इंस्टेंस और डेटाबेस के बीच मौजूदा एक-से-कई संबंधों का लाभ उठाकर SQL सर्वर में कुछ समेकन प्राप्त किया जा सकता है। हालांकि, ऐसे मामले हैं जहां समाधान मांग करता है कि डेटा को एक तालिका में समेकित किया जाए। ऐसे मामले में, डेटा तक पहुंच को प्रतिबंधित करने के बारे में चिंता हो सकती है।

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

परिदृश्य

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

सिक्योरेबल्स की पहचान करें

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

Listing 1 – Core Tables in West African Commercial Bank Database;
-- Customers;
create table Customers
(CustID int identity (1000,1) not null Primary Key
,FirstName varchar(100)
,LastName varchar(100)
,PhoneNo bigint
,ContactAddress varchar(4000)
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,AccountNo1 bigint
,AccountNo2 bigint
,AccountNo3 bigint
,AccountNo1Curr char (3)
,AccountNo2Curr char (3)
,AccountNo3Curr char (3)
)
GO

-- Transactions;
create table Transactions
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

-- Transaction_History;
create table Transaction_History
(TranID int identity (1000,1) not null 
,AcctID int foreign key references Accounts (AcctID)
,TranDate datetime 
,TranAmt money
,AffiliateID char(3) foreign key references Affiliates(AffiliateID)
,primary key (TranID,TranDate))
ON PartSch (TranDate)

फिर हम तालिकाओं का एक सेट बनाते हैं जिसका उपयोग हम कर्मचारियों की पहचान करने के लिए कर सकते हैं। इस सेटअप में, प्रत्येक कर्मचारी के पास एक ScopeID . होता है जो निर्धारित करता है कि वह किस हद तक डेटा को देख सकता है या उसमें हेरफेर कर सकता है:

1. राष्ट्रीय - एक कर्मचारी केवल कर्मचारी के देश में डेटा में हेरफेर कर सकता है (जहां वह काम करता है)
2. क्षेत्रीय - एक कर्मचारी केवल कर्मचारी के क्षेत्र (जैसे पश्चिम अफ्रीका) में डेटा में हेरफेर कर सकता है
3. वैश्विक - एक कर्मचारी किसी भी देश में डेटा में हेरफेर कर सकता है जहां बैंक की शाखा होगी

प्रत्येक कार्यक्षेत्र को उनके पदनाम के आधार पर कर्मचारियों को सौंपा गया है। एक समूह प्रबंधक का कार्यक्षेत्र है वैश्विक , कंट्री मैनेजर का कार्यक्षेत्र क्षेत्रीय होता है और एक कार्यकारी का कार्यक्षेत्र राष्ट्रीय है . डेटा तक पहुंच को प्रतिबंधित करने का पारंपरिक तरीका अक्सर भूमिकाओं और अनुमतियों का उपयोग होता है। किसी भूमिका के लिए अनुमतियाँ असाइन करना और बाद में किसी उपयोगकर्ता को भूमिका असाइन करने का अर्थ है कि उपयोगकर्ता के पास उस भूमिका से संबद्ध अनुमतियाँ हैं जो प्रश्न में तालिका में सेट किए गए संपूर्ण डेटा के लिए हैं। पंक्ति स्तर की सुरक्षा हमें कुछ और बारीक करने का अवसर देती है:उपयोगकर्ता की SELECT/UPDATE/DELETE अनुमतियों को तालिका में सेट किए गए डेटा के सबसेट तक सीमित करें (बारीक अभिगम नियंत्रण)।

<मजबूत>अंजीर। 1. स्टाफस्कोप और स्टाफ टेबल्स

डेटाबेस भूमिकाएं और उपयोगकर्ता

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

Listing 2 – Staff, Database User IDs and Roles

-- Populate Staff Table
use WACB
go
insert into Staff values ('John','Edu',DATABASE_PRINCIPAL_ID(),'Manager','233205678493','2','Accra, Ghana','EGH');
insert into Staff values ('Margaret','Harrison',DATABASE_PRINCIPAL_ID(),'Group Manager','2348030006574','3','Lagos, Nigeria','ENG');
insert into Staff values ('Edward','Antwi',DATABASE_PRINCIPAL_ID(),'Executive','22824567493','1','Lome, Togo','ETG');
insert into Staff values ('Barbara','Orji',DATABASE_PRINCIPAL_ID(),'Executive','22424567493','1','Abuja, Nigeria','ENG');
GO

-- Create Database User IDs for Staff
create user jedu without login;
create user mharrison without login;
create user eantwi without login;
create user borji without login;

-- Associate Database Principal IDs with Staff
update staff set DBUserID=DATABASE_PRINCIPAL_ID(concat(left(firstname,1),lastname));


-- Create Database Roles
create role [National] ;
create role [Regional] ;
create role [Global] ;

-- Grant Permissions on Desired Tables to Database Roles
grant select on customers to [National];
grant select, update on customers to Regional;
grant select, update on customers to Global;
grant select on Transactions to Regional, Global;
grant select on Transaction_History to Regional, Global;
grant update on Transactions to Global;


-- Grant Database Roles to Database Users Associated with Staff
alter role [National] add member eantwi;
alter role [National] add member borji;
alter role [Regional] add member jedu;
alter role [Global] add member mharrison;

संक्षेप में अब तक हमने जो किया है वह है:

1. उन तालिकाओं को बनाएं/पहचानें जिन्हें हमें सुरक्षित करने की आवश्यकता है
2. पंक्ति स्तर (स्कोप) पर डेटा तक पहुंच को प्रतिबंधित करने के लिए उपयोग किए जाने वाले मानदंडों को इंगित करने वाली तालिकाएं बनाएं
3. बनाई गई डेटाबेस भूमिकाएं और उपयोगकर्ता जिन पर हम प्रतिबंध लागू करेंगे
4. भूमिकाओं और अनुमतियों का उपयोग करके कोर टेबल ("टेबल लेवल सुरक्षा") तक प्रतिबंधित पहुंच

भविष्यवाणी कार्य और सुरक्षा नीति

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

Listing 3 - Implement Row Level Security

-- Create Predicate Function
create schema rls;
go

create function rls.AccessPredicate (@AffiliateID char(3))
returns table
with schemabinding
as
return select 1 as access 
from dbo.Staff as s 
join dbo.StaffScope ss on s.ScopeID=ss.ScopeID 
join dbo.Affiliates a on s.AffiliateID=a.AffiliateID
where (
IS_MEMBER('National')=1
and s.DBUserID=DATABASE_PRINCIPAL_ID()
and @AffiliateID=s.AffiliateID
)
OR
(
IS_MEMBER('Regional')=1
and @AffiliateID in (select a.AffiliateID from dbo.Affiliates where Region='West Africa')
)
OR
(
IS_MEMBER('Global')=1
);
GO

-- Create Security Policy
create security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Customers,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions,
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Customers after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transactions after update,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

-- Alter Security Policy
alter security policy rls.dataSecurityPol
add filter predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History,
add block predicate rls.AccessPredicate (AffiliateID) on dbo.Transaction_History after update;
GO

विधेय फ़ंक्शन उन शर्तों को परिभाषित करता है जो एक प्रिंसिपल के लिए दिलचस्प डेटा के सबसेट को देखने के लिए पूरी होनी चाहिए। इस फ़ंक्शन में, तीन शर्तें हैं:

1. स्टाफ का डेटाबेस उपयोगकर्ता राष्ट्रीय . का सदस्य है भूमिका और सहबद्ध आईडी कर्मचारियों से मेल खाता है या
2. स्टाफ का डेटाबेस उपयोगकर्ता क्षेत्रीय . का सदस्य है भूमिका और सहबद्ध आईडी संबद्ध आईडी . की सूची से मेल खाता है पश्चिम अफ्रीकी क्षेत्र से संबंधित है या
3. स्टाफ का डेटाबेस उपयोगकर्ता वैश्विक . का सदस्य है

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

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

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

कार्यान्वयन का परीक्षण

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

<मजबूत>अंजीर। 2. कर्मचारियों की सूची

Listing 4 – Testing the Implementation

select * from Customers;
execute ('select * from Customers') as user='eantwi';
execute ('select * from Customers') as user='borji';
execute ('select * from Customers') as user='jedu';
execute ('select * from Customers') as user='mharrison';

पहली पंक्ति में, मैं ग्राहकों . से पूछताछ करता हूं sysadmin, . के रूप में तालिका लेकिन मुझे कोई पंक्तियाँ नहीं मिलती हैं। मतलब एक व्यवस्थापक भी प्रतिरूपण के बिना RLS के प्रभावों को ओवरराइड नहीं कर सकता।

<मजबूत>अंजीर। 4. SysAdmin कोई पंक्तियाँ नहीं देखता है

बारबरा और एडवर्ड दोनों कार्यकारी हैं और राष्ट्रीय दायरे से संबंधित हैं लेकिन वे विभिन्न देशों में काम करते हैं इसलिए वे ग्राहकों को अपने संबंधित सहयोगियों से जुड़े हुए देखते हैं। (अंजीर में स्टाफ के नाम देखें। 1)।

<मजबूत>अंजीर। 5. कार्यकारी अपने संबद्ध की पंक्तियों को देखते हैं

जॉन और मार्गरेट देश और समूह प्रबंधक हैं। वे क्षेत्रीय . से संबंधित हैं और वैश्विक क्रमशः स्कोप। जॉन पश्चिम अफ्रीका के लिए डेटा देखता है, जबकि मार्गरेट सभी क्षेत्रों के लिए डेटा देखता है।

<मजबूत>अंजीर। 6. प्रबंधक अपने क्षेत्र की पंक्तियाँ देखते हैं

परिणाम अन्य सभी तालिकाओं के लिए समान हैं जिन पर सुरक्षा नीति लागू की गई है। देखें कि बिना अनुमति के लेन-देन . पर तालिका, पंक्ति स्तर सुरक्षा का कोई मूल्य नहीं है।

<मजबूत>अंजीर। 7. लेन-देन पर कोई चयन अनुमति नहीं टेबल

Listing 5 – Permissions on Transactions Table
grant select on dbo.Transactions to [National];

<मजबूत>अंजीर। 8. लेनदेन कार्यकारी अधिकारियों द्वारा देखी गई तालिका

निष्कर्ष

पंक्ति स्तर सुरक्षा SQL सर्वर की बारीक अभिगम नियंत्रण क्षमता का दोहन करने का एक शक्तिशाली तरीका है। इस सुविधा का उपयोग करने के लिए आवश्यक है कि आप SQL Server 2016 या उच्चतर चला रहे हों। जैसा कि नाम से ही स्पष्ट है, इसका उद्देश्य "टेबल स्तर की सुरक्षा" का ध्यान रखने के बाद जटिल प्रश्नों का उपयोग करके तालिका के भीतर पंक्तियों तक पहुंच को प्रतिबंधित करना है। जिन परिदृश्यों में इस क्षमता को लागू किया जा सकता है, वे अंतहीन हैं, इस प्रकार यह एक विस्तृत श्रृंखला के वातावरण के लिए बहुत उपयोगी है। अच्छी तरह से एक्सप्लोर करें और देखें कि यह आपके लिए क्या कर सकता है।

संदर्भ

इसाकोव, वी। (2018)। परीक्षा संदर्भ 70-764 एक SQL डेटाबेस अवसंरचना का व्यवस्थापन . पियर्सन एजुकेशन

पंक्ति-स्तरीय सुरक्षा