ओरेकल। पंक्ति स्तर सुरक्षा

समस्या का परिचय

वर्तमान में, किसी भी संगठन में उपयोगकर्ता के बारे में निश्चित ज्ञान के आधार पर जानकारी तक पहुंच का अंतर होता है। ऐसा ज्ञान संगठन में उपयोगकर्ता की भूमिका, उसकी स्थिति या संरचनात्मक इकाई जिसमें उपयोगकर्ता काम करता है, हो सकता है। बहुत से लोग जानते हैं कि उपयोगकर्ता नाम, तालिकाओं, विचारों और ट्रिगर्स के आधार पर सरल तंत्र का उपयोग करके पहुंच को प्रतिबंधित करने की समस्या को हल किया जा सकता है।

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

create table clients ( clientid integer, clientname varchar2(30), clientphone varchar2(7), clientoffice integer ); 

"माथे में" समाधान कंपनी के प्रत्येक विभाग के लिए एक अलग प्रस्तुति बनाना है। उदाहरण के लिए:

 create or replace view clients_10 as select clientid, clientname, clientphone from clients where clientoffice = 10; 

इस प्रकार, हमें विचारों की संख्या को बराबर बनाए रखना होगा
<number_ofiltrable_tables> * <number_of संरचनात्मक_डेपार्टमेंट> ,
और प्रत्येक उपयोगकर्ता को आवश्यक डेटा "भेजें" भी। मूर्खतापूर्ण और उबाऊ व्यवसाय।
आइए पिछले उदाहरण को बेहतर बनाने का प्रयास करें:

 create or replace view v_clients as select clientid, clientname, clietnphone from office where clientoffice = (select useroffice from users where username = user); 

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

आरएलएस प्रौद्योगिकी

आरएलएस प्रौद्योगिकी ( पंक्ति-स्तरीय सुरक्षा या पंक्ति-स्तरीय सुरक्षा ) सुरक्षा नीतियों को बनाने की क्षमता प्रदान करती है जो उपयोगकर्ताओं को डेटाबेस में जानकारी तक पहुंचने से रोकती है। जैसा कि ऊपर उल्लेख किया गया है, सुरक्षा नीतियां आपको या तो पूरे या आंशिक रूप से "करीब" जानकारी की अनुमति देती हैं, या उस पर केवल कुछ संचालन की अनुमति देती हैं। तकनीक को पहले ओरेकल 8 आई में पेश किया गया था, लेकिन भविष्य के संस्करणों में इसकी क्षमताओं में काफी विस्तार किया गया है।
जब कोई डेटाबेस ऑब्जेक्ट एक सुरक्षा नीति से जुड़ा होता है, तो एक विशेष PL / SQL फ़ंक्शन में दर्ज किए गए तर्क के माध्यम से एक्सेस कंट्रोल किया जाता है। सहमत हूं कि एनटीएच सर्किट के दर्जनों प्रतिनिधित्वों की तुलना में कई सॉफ्टवेयर कार्यों का समर्थन करना बहुत आसान है।
जब कोई उपयोगकर्ता प्रत्यक्ष या अप्रत्यक्ष रूप से डेटाबेस ऑब्जेक्ट (तालिका, दृश्य) को एक्सेस करता है, तो सर्वर गतिशील रूप से SQL स्टेटमेंट को संशोधित करता है जहां इसे समर्पित करता है, जिसे सुरक्षा फ़ंक्शन द्वारा लौटाया जाता है।

सुरक्षा समारोह

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

 create or replace function policy_func (p_schema varchar2, p_object varchar2) return varchar2 is begin if (user = 'MGR_10_20_30 ') then return 'clientoffice in (10, 20, 30)'; elseif return 'clientoffice = (select useroffice from users where username = user)'; end if; end; 

उपर्युक्त फ़ंक्शन उपयोगकर्ता की SQL क्वेरी में जहाँ ग्राहक = office_no को समर्पित करेगा, जहाँ office_no उस विभाग की संख्या है जिसमें उपयोगकर्ता काम कर रहा है। लॉगिन MGR_10_20_30 के साथ उपयोगकर्ता के लिए, जिसमें (10, 20, 30) में क्लाइंट को समर्पित किया जाएगा। इस प्रकार, इस उपयोगकर्ता के पास तीन विभागों की ग्राहक जानकारी उपलब्ध होगी।

DBMS_RLS पैकेज प्रक्रियाएँ

Add_policy

खैर, इस बिंदु पर हमने सभी आवश्यक प्रारंभिक कार्य किए हैं, और हमारे लिए जो कुछ भी है वह हमारे डेटाबेस में सुरक्षा नीति को जोड़ना है। सुरक्षा नीति DBMS_RLS add_policy पैकेज प्रक्रिया द्वारा लॉग की गई है:

 DBMS_RLS.ADD_POLICY ( object_schema IN VARCHAR2 NULL, object_name IN VARCHAR2, policy_name IN VARCHAR2, function_schema IN VARCHAR2 NULL, policy_function IN VARCHAR2, statement_types IN VARCHAR2 NULL, update_check IN BOOLEAN FALSE, enable IN BOOLEAN TRUE, static_policy IN BOOLEAN FALSE, policy_type IN BINARY_INTEGER NULL, long_predicate IN BOOLEAN FALSE, sec_relevant_cols IN VARCHAR2 NULL, sec_relevant_cols_opt IN BINARY_INTEGER NULL ); 

क्लाइंट तालिका के लिए सुरक्षा नीति जोड़ें:

 Begin DBMS_RLS.ADD_POLICY ( object_schema => 'myuser', object_name => 'clients', policy_name => 'clients_policy', function_schema => 'myuser', policy_function => 'policy_func', statement_types => 'select, insert, update, delete', update_check => true ); End; 

अब हमारे द्वारा उपयोग की जाने वाली प्रक्रिया के मापदंडों के बारे में संक्षेप में:
object_schema और object_name एक तालिका, दृश्य या पर्यायवाची है जिसके लिए पॉलिसी जोड़ी गई है, और डेटाबेस स्कीमा जिसमें ऑब्जेक्ट स्थित है।
policy_name जोड़ने के लिए सुरक्षा नीति का नाम है। नाम प्रत्येक तालिका या व्यक्तिगत रूप से देखने के लिए अद्वितीय होना चाहिए।
function_schema और policy_function - सुरक्षा फ़ंक्शन का नाम जो विधेय उत्पन्न करता है, और डेटाबेस स्कीमा जिसमें फ़ंक्शन स्थित होता है।
statement_types - ऐसे बयान, जिन पर सुरक्षा नीति लागू होती है।
update_check - यह विकल्प INSERT या UPDATE संचालन को रोकता है यदि INSERT या UPDATE विधेय में निर्दिष्ट खोज शर्तों का उल्लंघन करता है।
अब हम सुरक्षा नीति को कार्रवाई में देख सकते हैं:

 select username, useroffice from users; 

उपयोगकर्ता MGR_10 के लिए:

 select user from dual; 

 select * from clients; 

उपयोगकर्ता MGR_20 के लिए:

 select user from dual; 

 select * from clients; 

उपयोगकर्ता MGR_10_20_30 के लिए:

 select user from dual; 

 select * from clients; 

डेटाबेस में विचारों के बारे में जानकारी, उपयोगकर्ता_पॉलिटिक्स, ऑल_पोलिट्रीज़, डीबीए_पोलिट्रीज़ में देखी जाती है। आइए DBA अधिकारों वाले उपयोगकर्ता के अंतर्गत एक क्वेरी निष्पादित करें:

 select * from dba_policies; 

Drop_policy

तदनुसार, चूंकि सुरक्षा नीति बनाने की एक प्रक्रिया है, अर्थात, इसे हटाने की एक प्रक्रिया:

 DBMS_RLS.DROP_POLICY ( object_schema IN VARCHAR2 NULL, object_name IN VARCHAR2, policy_name IN VARCHAR2 ); 

आइए हमारी सुरक्षा नीति को हटाने का प्रयास करें:

 Begin DBMS_RLS.DROP_POLICY ( object_schema => 'myuser', object_name => 'clients', policy_name => 'clients_policy' ); End; 

अब DBA अधिकारों वाले उपयोगकर्ता के साथ डेटाबेस में नीतियों की उपलब्धता की जाँच करें:

 select * from dba_policies; 

Enable_policy

सुरक्षा नीतियों को जोड़ने / हटाने के अलावा, मौजूदा नीतियों को अस्थायी रूप से निलंबित करना संभव है। ऐसा करने के लिए, enable_policy प्रक्रिया का उपयोग करें, जो नीति को निष्क्रिय स्थिति में रखता है (enable => false) या नीति को फिर से शुरू करता है (enable => true):

 DBMS_RLS.ENABLE_POLICY ( object_schema IN VARCHAR2 NULL, object_name IN VARCHAR2, policy_name IN VARCHAR2, enable IN BOOLEAN TRUE) ); 

 select * from dba_policies; 

 Begin DBMS_RLS.ENABLE_POLICY ( object_schema => 'myuser', object_name => 'clients', policy_name => 'clients_policy', enable => false ); End; 

 select * from dba_policies; 

 Begin DBMS_RLS.ENABLE_POLICY ( object_schema => 'myuser', object_name => 'clients', policy_name => 'clients_policy' ); End; 

 select * from dba_policies; 

मुझे लगता है कि सबसे चौकस, dbms_rls पैकेज के add_policy प्रक्रिया के सक्षम पैरामीटर को देखा। यह पैरामीटर इंगित करता है कि निर्माण के तुरंत बाद पॉलिसी सक्रिय या निष्क्रिय होगी या नहीं। डिफ़ॉल्ट मान सत्य है।

Refresh_policy

प्रक्रिया आपको आरएलएस नीति को अपडेट करने की अनुमति देती है। यदि एक सुरक्षा नीति को डायनामिक के अलावा किसी अन्य प्रकार से परिभाषित किया जाता है, तो कुछ समय के लिए पॉलिसी की भविष्यवाणी को अपडेट नहीं किया जा सकता है, क्योंकि यह स्मृति में कैश्ड है। इसलिए, यदि पॉलिसी को तुरंत अपडेट करने की आवश्यकता है, तो आपको REFRESH_POLICY प्रक्रिया को निष्पादित करने की आवश्यकता है, जो पॉलिसी फ़ंक्शन को फिर से निष्पादित करेगी और कैश में विधेय को अपडेट करेगी।

 DBMS_RLS.REFRESH_POLICY ( object_schema IN VARCHAR2 NULL, object_name IN VARCHAR2 NULL, policy_name IN VARCHAR2 NULL ); 

निष्कर्ष

यह लेख सबसे सरल उदाहरण पर विचार करता है, जैसा कि वे कहते हैं, "उंगलियों पर"। अगले लेख में, हम संदर्भों और नीतियों के समूहों का उपयोग करके सुरक्षा पर विचार करेंगे।

सुरक्षित रहें! कमिट!