SQL फ़ायरवॉल के साथ अपने PostgreSQL डेटाबेस को साइबर हमले से कैसे बचाएं

आज की दुनिया में, संगठनों को अपनी सूचना संपत्तियों के खिलाफ साइबर हमलों के अभूतपूर्व स्तर के खतरे का सामना करना पड़ रहा है।

साइबर हमले कई रूपों में आ सकते हैं। ऐसे ही एक हमले को एसक्यूएल इंजेक्शन . कहा जाता है . SQL इंजेक्शन के साथ, दुष्ट खिलाड़ी किसी भी सिस्टम के बैकएंड डेटाबेस को लक्षित करते हैं। आमतौर पर, ये प्रणालियाँ सार्वजनिक-सामना करने वाली होती हैं। हैकर्स एक डेटाबेस को प्रतीत होने वाली सहज और नियमित क्वेरी भेजने का प्रयास करते हैं - उन पैरामीटरों को छोड़कर जो उन सूचनाओं को उजागर कर सकते हैं जिन्हें उन्हें नहीं देखना चाहिए, या गलत जानकारी के साथ डेटाबेस को दूषित कर सकते हैं, या सिस्टम को क्रैश कर सकते हैं।

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

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

ऐसा ही एक सुरक्षा उपाय एक डेटाबेस फ़ायरवॉल है। नियमित फ़ायरवॉल की तरह, डेटाबेस फ़ायरवॉल श्वेतसूची या ब्लैकलिस्ट के आधार पर ट्रैफ़िक को फ़िल्टर करता है। वे यह समझने के लिए सिस्टम एक्सेस पैटर्न से "सीख" भी सकते हैं कि किन बयानों पर भरोसा किया जा सकता है और क्या नहीं। इस तरह के टूल का उपयोग करने से SQL इंजेक्शन से सुरक्षा की एक मजबूत परत जुड़ जाती है।

इस लेख में, हम SQL फ़ायरवॉल के बारे में बात करेंगे , PostgreSQL डेटाबेस की सुरक्षा के लिए एक डेटाबेस फ़ायरवॉल। SQL फ़ायरवॉल 2ndQuadrant द्वारा निर्मित और समर्थित है, जो PostgreSQL प्रौद्योगिकियों में अग्रणी है।

SQL फ़ायरवॉल कैसे काम करता है

SQL फ़ायरवॉल PostgreSQL 9.4 और इसके बाद के संस्करण के विस्तार के रूप में आता है। हालांकि यह वर्तमान में PostgreSQL संस्करण 10 तक समर्थित है, बाद के संस्करणों का समर्थन करने के लिए आगे का काम जारी है।

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

उदाहरण के लिए, किसी एप्लिकेशन के लॉन्च से पहले, प्रत्येक कॉन्फ़िगर किया गया उपयोगकर्ता एक नियंत्रित वातावरण में डेटाबेस के विरुद्ध उत्पादन-गुणवत्ता नमूना वर्कलोड चला सकता है। एक मानव उपयोगकर्ता खाते को केवल-पढ़ने के लिए क्वेरी चलाने की अनुमति दी जा सकती है, जबकि एक एप्लिकेशन उपयोगकर्ता खाते को पढ़ने और लिखने दोनों को चलाने की अनुमति दी जा सकती है। SQL फ़ायरवॉल तब श्वेतसूची मानव और एप्लिकेशन उपयोगकर्ता खातों दोनों के लिए प्रश्नों को पढ़ता है और केवल एप्लिकेशन उपयोगकर्ता खाते के लिए प्रश्न लिखता है। यदि कोई मानव उपयोगकर्ता INSERT, DELETE या UPDATE को चलाने का प्रयास करता है, तो SQL फ़ायरवॉल ऑपरेशन को अस्वीकार कर देगा। जैसे-जैसे एप्लिकेशन विकसित होता है, श्वेतसूची को बदलते कार्यभार के साथ फिर से प्रशिक्षित किया जा सकता है।

प्रत्येक अवरुद्ध विवरण SQL फ़ायरवॉल द्वारा लॉग किया जाता है, जिसका अर्थ है कि संचालन दल इन लॉग को अपने लॉग प्रबंधन समाधानों को भेज सकते हैं और हर बार अपवाद होने पर सतर्क हो सकते हैं।

पर्यावरण की स्थापना

इस लेख में, हम Red Hat Enterprise Linux 7 पर चलने वाले सिंगल-नोड PostgreSQL 10 इंस्टेंस के लिए SQL फ़ायरवॉल स्थापित करेंगे। लेखन के समय, RHEL/CentOS 7 और PostgreSQL 10 उच्चतम समर्थित संस्करण हैं। हालांकि, जैसा कि पहले उल्लेख किया गया है, आगे समर्थन आ रहा है।

नोट

[कृपया ध्यान दें कि SQL फ़ायरवॉल एक व्यावसायिक रूप से लाइसेंस प्राप्त उत्पाद है जो 24/7 सहायता ग्राहकों के लिए उपलब्ध है। यह 2ndQuadrant सार्वजनिक वेबसाइट से डाउनलोड के लिए उपलब्ध नहीं है।]

चरण 1:PostgreSQL 10 स्थापित करना

हमारा परीक्षण सिस्टम एक Amazon EC2 इंस्टेंस है जो Red Hat Enterprise Linux 7.2 चला रहा है।

# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)

हम PostgreSQL 10 (x86-64) के लिए RPM रेपो डाउनलोड करने के लिए निम्न कमांड चलाते हैं।

# yum install https://download.postgresql.org/pub/repos/yum/reporpms/EL-7-x86_64/pgdg-redhat-repo-latest.noarch.rpm -y

इसके बाद, हम सर्वर और क्लाइंट पैकेज स्थापित करते हैं।

# yum install postgresql10-server postgresql10 -y

एक बार पैकेज सफलतापूर्वक स्थापित हो जाने के बाद, हम डेटाबेस को इनिशियलाइज़ करने के लिए initdb कमांड चलाते हैं।

# /usr/pgsql-10/bin/postgresql-10-setup initdb

Initializing database ... OK

इसके बाद, हम postgresql.conf फ़ाइल में निम्नलिखित परिवर्तन करते हैं। डिफ़ॉल्ट रूप से, यह /var/lib/pgsql/10/data/ निर्देशिका के अंतर्गत है।

listen_addresses = '*'

और फिर, निम्न पंक्ति को pg_hba.conf फ़ाइल में जोड़ें (फिर से, डिफ़ॉल्ट रूप से, यह /var/lib/pgsql/10/data/ निर्देशिका के अंतर्गत है)।

host    all all    <our IP address range>    md5

फिर हम PostgreSQL सेवा शुरू करते हैं और इसे स्वचालित रूप से प्रारंभ करने के लिए सक्षम करते हैं।

# systemctl start postgresql-10.service
# systemctl enable postgresql-10.service

अंत में, हम उपयोगकर्ता को पोस्टग्रेज करने और पासवर्ड बदलने के रूप में psql से डेटाबेस इंस्टेंस में लॉग इन करते हैं।

# su - postgres
-bash-4.2$ psql
psql (10.12)
Type "help" for help.

postgres=# \password
Enter new password:
Enter it again:
postgres=#

चरण 2:नमूना डेटाबेस पुनर्स्थापित करें

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

पगिला :लोकप्रिय MySQL Sakila डेटाबेस का PostgreSQL संस्करण
चिनूक : डिजिटल मीडिया स्टोर के बारे में एक डेटाबेस

चरण 3:भूमिकाएं और उपयोगकर्ता बनाएं

बनाए गए डेटाबेस के साथ, हम दो उपयोगकर्ता भूमिकाएँ बनाते हैं। एक को "human_user" कहा जाता है, दूसरे को "app_user" कहा जाता है।

मानव_उपयोगकर्ता भूमिका किसी भी व्यक्ति का प्रतिनिधित्व करती है जो बैक-एंड से या क्लाइंट टूल के साथ डेटाबेस तक पहुंचता है। app_user भूमिका उस खाते का प्रतिनिधित्व करती है जिसका उपयोग एप्लिकेशन डेटाबेस से कनेक्ट करने के लिए करेगा।

psql -d postgres -c "CREATE ROLE human_user WITH  NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';"
psql -d postgres -c "CREATE ROLE app_user WITH  NOSUPERUSER NOCREATEDB NOCREATEROLE NOINHERIT LOGIN NOREPLICATION PASSWORD '<a tough password>';"

उपयोगकर्ता भूमिकाओं को पोस्टग्रेज़ उपयोगकर्ता के रूप में निम्नलिखित कमांड चलाकर चिनूक और पैगिला डेटाबेस तक पहुंचने की अनुमति दी जाती है:

$ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO app_user;"

$ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;"
$ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;"

$ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO app_user;"
$ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO app_user;"

$ psql -d postgres -c "GRANT CONNECT ON DATABASE pagila, chinook TO human_user;"

$ psql -d chinook -c "GRANT USAGE ON SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;"
$ psql -d chinook -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;"

$ psql -d pagila -c "GRANT USAGE ON SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT USAGE, SELECT ON ALL SEQUENCES IN SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT SELECT, INSERT, UPDATE, DELETE, TRUNCATE, TRIGGER, REFERENCES ON ALL TABLES IN SCHEMA public TO human_user;"
$ psql -d pagila -c "GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO human_user;"

चरण 4:SQL फ़ायरवॉल स्थापित करना

SQL फ़ायरवॉल स्थापित करना एक सीधी प्रक्रिया है। सबसे पहले, हम पैकेज स्थापित करते हैं।

# rpm -ivh postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm

warning: postgresql10-sqlfirewall-3.0-1.el7.x86_64.rpm: Header V4 RSA/SHA1 Signature, key ID ******: NOKEY
Preparing...                          ################################# [100%]
Updating / installing...

1:postgresql10-sqlfirewall-3.0-1.el################################# [100%]

फिर हम share_preload_libraries पैरामीटर को बदलकर postgresql.conf फ़ाइल को अपडेट करते हैं।

shared_preload_libraries = 'sqlfirewall'

एक बार हो जाने के बाद, हम PostgreSQL सेवा को पुनः आरंभ करते हैं।

# systemctl restart postgresql-10.service

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

$ psql -U postgres -d chinook -c "CREATE EXTENSION sqlfirewall;"
Password for user postgres:
CREATE EXTENSION
-bash-4.2$ psql -U postgres -d pagila -c "CREATE EXTENSION sqlfirewall;"
Password for user postgres:
CREATE EXTENSION

नीचे दी गई छवि दोनों डेटाबेस पर स्थापित एक्सटेंशन दिखाती है। ध्यान दें कि दोनों डेटाबेस में "sqlfirewall" नामक एक विशेष स्कीमा भी बनाया गया है। इस स्कीमा में SQL फ़ायरवॉल के संचालन से संबंधित सभी डेटाबेस ऑब्जेक्ट शामिल हैं।

हम यह भी देख सकते हैं कि "sqlfirewall_manager" नामक एक नई भूमिका स्वचालित रूप से बनाई गई है। इस भूमिका में जोड़े गए उपयोगकर्ता sqlfirewall स्कीमा में कार्यों और दृश्यों तक पहुंच सकते हैं।

चरण 5:SQL फ़ायरवॉल को कॉन्फ़िगर करना

फिर कई पैरामीटर postgresql.conf . में जोड़े जाते हैं फ़ाइल। Red Hat Enterprise Linux और इसके डेरिवेटिव डिस्ट्रोस के लिए, इस फ़ाइल के लिए डिफ़ॉल्ट निर्देशिका स्थान /var/lib/pgsql/10/data/ है।

निम्नलिखित कोड स्निपेट में, हम फ़ाइल को संपादित कर रहे हैं और कई पैरामीटर जोड़ रहे हैं।

# vim /var/lib/pgsql/10/data/postgresql.conf

sqlfirewall.whitelist = 'verbose'
sqlfirewall.track = 'all'
sqlfirewall.track_utility = 'true'
sqlfirewall.save = 'true'

फिर हम सभी कॉन्फ़िगरेशन पुनः लोड करते हैं।

$ psql -U postgres -d postgres
Password for user postgres:
psql (10.12)
Type "help" for help.

postgres=# SELECT pg_reload_conf();
 pg_reload_conf
----------------
 t
(1 row)

इसके बाद, हम प्रक्रिया को एक सेकंड के लिए सोने देते हैं।

postgres=# SELECT pg_sleep(1);
 pg_sleep
----------
(1 row)

और फिर दोनों डेटाबेस में श्वेतसूची की स्थिति की जाँच करें। यदि चरणों का पालन किया गया था, तो दोनों डेटाबेस में श्वेतसूचीकरण सक्षम होना चाहिए।

postgres=# \connect pagila
You are now connected to database "pagila" as user "postgres".
pagila=# show sqlfirewall.whitelist;
 sqlfirewall.whitelist
-----------------------
 verbose
(1 row)

pagila=# \connect chinook;
You are now connected to database "chinook" as user "postgres".
chinook=# show sqlfirewall.whitelist;
 sqlfirewall.whitelist
-----------------------
 verbose
(1 row)

आइए हम अभी-अभी जोड़े गए मापदंडों के बारे में जानें।

sqlfirewall.whitelist फ़ायरवॉल की श्वेतसूची कार्यक्षमता को सक्षम करने के लिए पैरामीटर का उपयोग किया जाता है। इस पैरामीटर में दो मान हो सकते हैं:"वर्बोज़" या "प्रोटेक्ट"।

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

sqlfirewall.track . को असाइन किए गए मान और sqlfirewall.track_utility पैरामीटर सुनिश्चित करते हैं कि SQL फ़ायरवॉल श्वेतसूची के उद्देश्यों के लिए सभी कथनों को ट्रैक कर रहा है।

अंत में, sqlfirewall.save को सेट करना "सत्य" के लिए पैरामीटर यह सुनिश्चित करता है कि श्वेतसूचीबद्ध कथन सर्वर के रिबूट होने पर भी बने रहें।

SQL फ़ायरवॉल चलाना

SQL फ़ायरवॉल चलाने में एक्सटेंशन के साथ आने वाले कई फ़ंक्शन शामिल होते हैं।

चरण 1:SQL फ़ायरवॉल फ़ंक्शंस को समझना

SQL फ़ायरवॉल एक्सटेंशन डेटाबेस के sqlfirewall स्कीमा में कई फ़ंक्शन बनाता है जहाँ यह स्थापित है। इनमें से अधिकांश फ़ंक्शन केवल सुपरयूज़र या sqlfirewall_manager भूमिका के सदस्यों द्वारा निष्पादित किए जा सकते हैं।

आइए इनमें से कुछ कार्यों पर शीघ्रता से विचार करें।

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

श्वेतसूची_मोड पैरामीटर के तीन मान हो सकते हैं:

जब यह "रिकॉर्ड पर सेट हो जाए) ”, SQL फ़ायरवॉल उपयोगकर्ता द्वारा निष्पादित सभी कथनों को उपयोगकर्ता की श्वेतसूची में रिकॉर्ड करेगा
जब "ENFORCE . पर सेट किया जाता है ”, SQL फ़ायरवॉल श्वेतसूची को लागू करेगा। श्वेतसूची में शामिल नहीं किए गए किसी भी कथन से त्रुटि होगी
“OFF . का मान ” उपयोगकर्ता के लिए श्वेतसूची की कार्यक्षमता को बंद कर देता है, और उपयोगकर्ता किसी भी प्रश्न को निष्पादित करने में सक्षम नहीं होगा

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

sqlfirewall_whitelist_delete_entry फ़ंक्शन का उपयोग उपयोगकर्ता की श्वेतसूची से अलग-अलग क्वेरी आईडी निकालने के लिए किया जाता है। यह तब उपयोगी हो सकता है जब आपके पास किसी उपयोगकर्ता के लिए बहुत अधिक अनुमत क्वेरी हों और आप उसे फ़ाइन-ट्यून करना चाहते हों। फ़ंक्शन दो पैरामीटर लेता है:उपयोगकर्ता नाम और क्वेरी आईडी। आप sqlfirewall दृश्य को देखकर उस क्वेरी की आईडी प्राप्त कर सकते हैं जिसे आप श्वेतसूची से बाहर करना चाहते हैं।

sqlfirewall_whitelist_users फ़ंक्शन कोई पैरामीटर नहीं लेता है। यह उन उपयोगकर्ताओं की सूची लौटाता है जिनके खाते के लिए श्वेतसूचीकरण सक्षम है।

आप sqlfirewall_whitelist_export . का उपयोग करके किसी उपयोगकर्ता के लिए श्वेतसूची निर्यात कर सकते हैं समारोह। यह फ़ंक्शन दो पैरामीटर लेता है:उपयोगकर्ता नाम और फ़ाइल नाम जहां यह उपयोगकर्ता के श्वेतसूची वाले बयानों को निर्यात करता है। फ़ाइल उस स्थान पर होनी चाहिए जहाँ PostgreSQL सर्वर प्रक्रिया की लेखन पहुँच हो।

sqlfirewall_whitelist_export फ़ंक्शन के समान, sqlfirewall_whitelist_import फ़ंक्शन किसी उपयोगकर्ता के लिए निर्यात की गई श्वेतसूची फ़ाइल को उस उपयोगकर्ता के लिए किसी भिन्न PostgreSQL इंस्टेंस में आयात करने के लिए उपयोग किया जाता है। यह फ़ंक्शन दो पैरामीटर, उपयोगकर्ता नाम और आयात की जाने वाली फ़ाइल भी लेता है। फ़ाइल उस स्थान पर होनी चाहिए जहाँ से PostgreSQL सर्वर प्रक्रिया इसे पढ़ सकती है।

साथ ही, लक्ष्य डेटाबेस को स्रोत डेटाबेस की बाइनरी कॉपी होना चाहिए - इसका मतलब है कि लक्ष्य को स्ट्रीमिंग प्रतिकृति या pg_basebackup कमांड वाले स्रोत से बनाए गए PostgreSQL इंस्टेंस का हिस्सा होना चाहिए। स्रोत डेटाबेस के तार्किक डंप से बनाए गए डेटाबेस श्वेतसूची फ़ाइल आयात नहीं कर सकते हैं - ऐसे मामलों में, श्वेतसूची को मैन्युअल रूप से कॉन्फ़िगर करना होगा।

चरण 2:उपयोगकर्ताओं के लिए श्वेतसूची सक्षम करना

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

नीचे दिए गए कोड स्निपेट में, हम सुपरयूसर पोस्टग्रेज के रूप में निम्नलिखित कमांड चला रहे हैं।

postgres=# \connect pagila
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');\
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# \connect chinook
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'RECORD');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

हम sqlfirewall_whitelist_users() फ़ंक्शन चलाकर भी पुष्टि कर सकते हैं।

$ psql -U postgres -d pagila -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"
Password for user postgres:
 sqlfirewall_whitelist_users
-----------------------------
 (17479,human_user,RECORD)
 (17480,app_user,RECORD)
(2 rows)

$ psql -U postgres -d chinook -c "SELECT sqlfirewall.sqlfirewall_whitelist_users();"
Password for user postgres:
 sqlfirewall_whitelist_users
-----------------------------
 (17479,human_user,RECORD)
 (17480,app_user,RECORD)
(2 rows)

चरण 3:कार्यभार चलाना

श्वेतसूची सक्षम और रिकॉर्डिंग के साथ, हम app_user खाते पर स्विच करते हैं और नीचे दिखाए गए अनुसार कुछ प्रश्न चलाते हैं। ध्यान दें कि कैसे app_user विभिन्न तालिकाओं से विभिन्न "आईडी फ़ील्ड" (customer_id, Staff_id, EmployeeID, आदि) का चयन कर रहा है।

postgres=# \c - app_user
Password for user app_user:
You are now connected to database "postgres" as user "app_user".
postgres=> \connect pagila
You are now connected to database "pagila" as user "app_user".
pagila=> SELECT customer_id, first_name, last_name, email FROM public.customer;
...
pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;
...
pagila=> SELECT staff_id, first_name, last_name, email FROM public.staff;
...
pagila=> \connect chinook;
You are now connected to database "chinook" as user "app_user".
chinook=> SELECT "CustomerId", "FirstName", "LastName", "Phone" FROM public."Customer";
...
chinook=> SELECT "EmployeeId", "FirstName", "LastName", "Phone", "Email" FROM public."Employee";
...

इसके बाद, हम human_user खाते पर स्विच करते हैं और कुछ टेबल पर कुछ साधारण क्वेरीज़ चलाते हैं जिन्हें app_user ने एक्सेस किया है।

postgres=# \c - human_user
Password for user human_user:
You are now connected to database "postgres" as user "human_user".
postgres=> \connect pagila;
You are now connected to database "pagila" as user "human_user".
pagila=> SELECT payment_date, amount FROM public.payment;
...
pagila=> SELECT first_name, last_name, email FROM public.customer;
...
pagila=> \connect chinook;
You are now connected to database "chinook" as user "human_user".
chinook=> SELECT "FirstName", "LastName", "Phone", "Email" FROM public."Employee";
...

अगर हम किसी भी डेटाबेस से sqlfirewall व्यू को पोस्टग्रेज यूजर के रूप में क्वेरी करते हैं, तो हम उन प्रश्नों को देख सकते हैं जिन्हें प्रत्येक उपयोगकर्ता के लिए श्वेतसूची में रखा गया था।

चरण 4:श्वेतसूची लागू करना

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

postgres=# \connect pagila;
You are now connected to database "pagila" as user "postgres".
pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

pagila=# \connect chinook;
You are now connected to database "chinook" as user "postgres".
chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('human_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

chinook=# SELECT sqlfirewall.sqlfirewall_whitelist_mode('app_user', 'ENFORCE');
 sqlfirewall_whitelist_mode
----------------------------
 t
(1 row)

चरण 5:परीक्षण

श्वेतसूची का परीक्षण करने के लिए, हमने मानव_उपयोगकर्ता के रूप में पेजिला डेटाबेस में लॉग इन किया और पहले चलाए गए आदेशों को चलाने का प्रयास किया

chinook=# \c - human_user;
Password for user human_user:
You are now connected to database "chinook" as user "human_user".
chinook=> \connect pagila;
You are now connected to database "pagila" as user "human_user".

pagila=> SELECT payment_date, amount FROM public.payment;
...
pagila=> SELECT first_name, last_name, email FROM public.customer;
...

आदेश सफल होते हैं। ऐसा इसलिए है क्योंकि ये आदेश पहले मानव_उपयोगकर्ता द्वारा चलाए गए थे और श्वेतसूची में थे।

अब हम निम्न कमांड को चलाने का प्रयास करते हैं। ध्यान दें कि कैसे human_user दो अतिरिक्त क्षेत्रों के साथ एक क्वेरी चलाने का प्रयास कर रहा है। यह क्वेरी पहले app_user द्वारा चलाई गई थी।

pagila=> SELECT payment_id, customer_id, payment_date, amount FROM public.payment;

इस तरह के संदेश के साथ कथन विफल हो जाता है:

ERROR:  Execution of non-whitelisted statement prohibited

ऐसा इसलिए हो रहा है क्योंकि मानव_उपयोगकर्ता ने पहले इस तालिका से केवल दो फ़ील्ड का चयन करने के लिए एक आदेश चलाया था, न कि अतिरिक्त फ़ील्ड (भुगतान आईडी और ग्राहक आईडी) जिसे वह अब एक्सेस करने का प्रयास कर रहा है। SQL फ़ायरवॉल ने अपनी पिछली क्वेरी को एक ज्ञात कार्यभार के रूप में रिकॉर्ड किया और उस क्वेरी को श्वेतसूची में डाल दिया। जैसे ही वह अपनी क्वेरी में उन दो नए क्षेत्रों को जोड़ने का प्रयास करता है, फ़ायरवॉल उसे रोक रहा है।

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

तो, क्या होगा यदि उपयोगकर्ता को वैध उद्देश्य के लिए इन दो अतिरिक्त क्षेत्रों की आवश्यकता है? ऐसे मामले में उपयोगकर्ता के लिए श्वेतसूची मोड को फिर से "रिकॉर्ड" में बदलना होगा ताकि नई क्वेरी चल सकें, और SQL फ़ायरवॉल उन्हें श्वेतसूची में डाल सके।

आइए समाप्त करने से पहले एक और परीक्षण चलाते हैं। इस बार, हम मान लेंगे कि एक हैकर ने app_user खाते से छेड़छाड़ की है और "भुगतान" तालिका के खिलाफ एक डिलीट स्टेटमेंट चलाना चाहता है। याद रखें कि हमने टेबल पर उपयोगकर्ता को DELETE और TRUNCATE विशेषाधिकार दिए थे।

इसलिए हम app_user के रूप में लॉग इन करते हैं, और एक DELETE स्टेटमेंट चलाते हैं।

pagila=> \c - app_user
Password for user app_user:
You are now connected to database "pagila" as user "app_user".
pagila=> DELETE FROM public.payment;
ERROR:  Execution of non-whitelisted statement prohibited

निष्कर्ष

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

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

हालांकि, डीबीए और सिस्टम एडमिनिस्ट्रेटर को कुछ बिंदुओं के बारे में पता होना चाहिए:

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

दूसरे, जब अलग-अलग SELECT, INSERT, UPDATE, और DELETE स्टेटमेंट्स को व्हाइटलिस्ट किया जाता है, तो SQL फ़ायरवॉल अलग-अलग मामलों (अपरकेस, मिक्स्ड केस या लोअरकेस) में लिखे गए इन कमांड्स में इस्तेमाल होने वाले ऑब्जेक्ट नामों को समान मानेगा। अन्य सभी कमांड की तुलना टेक्स्ट क्वेरी स्ट्रिंग्स के आधार पर की जाएगी। इसलिए, उदाहरण के लिए, SQL फ़ायरवॉल "BEGIN" और "प्रारंभ" और "प्रारंभ" को अलग-अलग क्वेरी के भाग के रूप में मानेगा।

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

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