डीबीए डेटा का संरक्षक है, और अभिभावक होने के दो पहलू हैं। पहली अखंडता है। इसमें डेटाबेस संगतता की जाँच करना, बैकअप बनाना, और, यदि कोई समस्या दिखाई दे, एक अच्छी तरह से डिज़ाइन की गई, व्यापक डेटाबेस पुनर्प्राप्ति योजना जैसे कार्य शामिल हैं।
दूसरा पहलू सुरक्षा है। यह सुनिश्चित करने का सुझाव देता है कि केवल अधिकृत उपयोगकर्ताओं के पास डेटा तक पहुंच है, और केवल उस डेटा तक पहुंच है जिसकी उन्हें आवश्यकता है।
आप वेब पर सुरक्षा के लिए समर्पित कई संसाधन पा सकते हैं। हालांकि, मुझे लगता है कि कुछ महत्वपूर्ण बातों पर उचित ध्यान नहीं दिया जाता है। इस लेख में, मैं इन विकल्पों पर ध्यान केंद्रित करना चाहता हूं और प्रदर्शित करना चाहता हूं कि उनके बारे में जागरूक होना और उन्हें सही तरीके से संभालना क्यों महत्वपूर्ण है।
SQL सर्वर से समझौता करने का मिशन
आइए एक रोल-प्लेइंग गेम लें जिसमें आप एक सीक्रेट एजेंट हैं, और आपका मिशन, क्या आपको इसे स्वीकार करना चाहिए, TargetDB से बहुत महत्वपूर्ण डेटा चोरी करना है SQL सर्वर द्वारा होस्ट किया गया डेटाबेस। आपको यह डेटा प्राप्त करने और इसे हटाने की आवश्यकता है।
आपके लिए एक लॉगिन प्राप्त करना संभव है, लेकिन सर्वर पर प्रत्येक लॉगिन में लक्ष्य डेटाबेस और डेटा पर स्पष्ट अस्वीकृत अनुमतियाँ हैं। केवल वही जानकारी जो हमारा एजेंट आपको प्रदान कर सकता है, वह है जो आपके लॉगिन के निर्माण के दौरान सुरक्षा प्रोटोकॉल द्वारा सत्यापन के लिए बनाई गई है।
लक्ष्य सर्वर से डेटाबेस जानकारी।
सर्वर अनुमतियाँ:
डेटाबेस अनुमतियाँ:
प्रत्येक अच्छे एजेंट के रूप में, आइए होमवर्क करें और जांचें कि आप किसके साथ काम कर रहे हैं।
आप केवल लॉग इन नहीं कर सकते और TargetDB . से जुड़ सकते हैं , चूंकि आपके लॉगिन और इसके मैप किए गए उपयोगकर्ता के लिए हर एक अनुमति को स्पष्ट रूप से अस्वीकार कर दिया गया है। आपको दूसरे डेटाबेस से प्रवेश करना होगा।
एक बंद दरवाज़ा
क्रॉस-डेटाबेस क्रियाएं करना आसान काम नहीं है। इसे एक बंद दरवाजा समझें जिस पर दो ताले हों। हम यहां तकनीकी विवरण पर ध्यान केंद्रित नहीं करेंगे, लेकिन आप EXECUTE AS MSDN लेख का उपयोग करके डेटाबेस प्रतिरूपण का विस्तार करने का उल्लेख कर सकते हैं (मैं ऐसा करने की अत्यधिक अनुशंसा करता हूं)।
पहला लॉक है प्रमाणक पर भरोसा करना , और दूसरा है डेटाबेस पर भरोसा करना ।
आइए पहले लॉक से शुरू करते हैं। प्रमाणक पर विश्वास करने का अर्थ है कि किसी अन्य डेटाबेस B तक पहुंच के लिए, डेटाबेस A के स्वामी को (स्पष्ट रूप से या परोक्ष रूप से) प्रमाणीकरण प्रदान किया जाना चाहिए डेटाबेस बी में अनुमति।
एक मिनट रुकिए! डेटाबेस स्तर पर प्रमाणक स्वयं डेटाबेस का स्वामी होता है (इसे db_owner के साथ न मिलाएं) डेटाबेस भूमिका!)।
डेटाबेस स्वामियों की जाँच करें:
भले ही वे प्रति सर्वर एक खाते का उपयोग करके बहुत अच्छे अभ्यास का पालन करते हैं, जो कि SA . नहीं है , इस तरह उन्होंने कृपया आपके लिए पहला ताला खोल दिया है।
आइए दूसरे लॉक पर ध्यान दें।
किसी तरह, आपको सर्वर पर TRUSTWORTHY . के साथ एक डेटाबेस बनाना होगा संपत्ति चालू . यहां सबसे अच्छा अभ्यास TRUSTWORTHY डेटाबेस प्रॉपर्टी को बंद पर सेट करना है ।
यही वह समय है जब हमें कहना चाहिए:क्या होगा यदि आपके पास पहले से ही ऐसा डेटाबेस है?
यह MSDB डेटाबेस है।
दूसरा ताला तैयार है। आपको किसी भी ताले को तोड़ने की जरूरत नहीं पड़ी।
db_owner भूमिका का महत्व
अभी आपको एक चुनौती से निपटना है। किसी तरह, आपको db_owner . के साथ MSDB डेटाबेस में प्रवेश करने की आवश्यकता है डेटाबेस भूमिका क्योंकि इसमें निहित, प्रतिरूपण अनुमति है।
चूंकि MSDB आमतौर पर डेटाबेस प्रशासकों के ध्यान में नहीं है, इसलिए यह मिशन अब असंभव नहीं है। आइए देखें कि आप केवल इसलिए क्या कर सकते हैं क्योंकि आपको db_owner . वाला उपयोगकर्ता मिल गया है MSDB डेटाबेस में डेटाबेस की भूमिका:
TargetDB . से कनेक्ट करने का प्रयास करें :
यह एक अपेक्षित त्रुटि है। दिए गए लॉगिन पर लागू सुरक्षा प्रोटोकॉल याद रखें। आइए इसे शुरू करते हैं।
TargetDB . से कनेक्ट करने का प्रयास करें और लक्ष्य डेटा का चयन करने के लिए:
यह काम करता हैं! आइए इसे संशोधित करें और उसके बाद कार्रवाई को सत्यापित करें।
बस इतना ही।
मिशन पूरा हुआ।
जैसा कि आपने देखा, मैंने एक विशेष सुरक्षा डेटाबेस कॉन्फ़िगरेशन संयोजन पर ध्यान केंद्रित किया। वे डेटाबेस के स्वामी थे और TRUSTWORTHY डेटाबेस विकल्प MSDB पर विशेष ध्यान दे रहा है। प्रस्तुत परिदृश्य सिर्फ एक था जिसमें संवेदनशील डेटा को उसी तरह से समझौता किया जा सकता है। आइए अब एक और संभावित परिदृश्य की समीक्षा करें।
डेटाबेस स्वामी + विश्वसनीय
आइए प्रसिद्ध समस्या से शुरू होने वाले पृष्ठभूमि विवरण की जांच करें:डेटाबेस स्वामित्व। आपके डेटाबेस के स्वामी को किस लॉगिन विवरण का उपयोग करना चाहिए? बहुत से लोग कहते हैं कि SA एक उपयुक्त विकल्प है।
मैंने एक त्वरित Google खोज की और निम्न जैसे उत्तर पाए:
“मुझे याद नहीं है कि यह मेरे लिए कभी भी चिंता का विषय रहा हो। रिपोर्ट में परेशान दिखने के अलावा, या उपयोगकर्ता के पास डेटाबेस होने पर उसे हटाने में असमर्थ होने के अलावा, लेकिन मुझे नहीं लगता कि यह सर्वर संचालन को प्रभावित करता है। आप बस सा . चुन सकते हैं एकरूपता के लिए।"
या
“मुझे नहीं लगता कि एसए या किसी अन्य उपयोगकर्ता द्वारा डेटाबेस का मालिक होना किसी चिंता का विषय होना चाहिए। क्या मायने रखता है कि आपके डेटाबेस में कौन 'क्या' कर रहा है। इसलिए, वैध विशेषाधिकार वाले उपयोगकर्ता बनाना एक अच्छा विचार है। सरलता के लिए, आप स्वामी को SA के रूप में निर्दिष्ट कर सकते हैं।"
वर्तमान स्थिति यह है कि SA खाते को डेटाबेस स्वामी के रूप में उपयोग करना सबसे खराब अभ्यास है . मुझे व्यक्तिगत रूप से लगता है कि इस विषय से संबंधित प्रत्येक ब्लॉग और प्रत्येक दस्तावेज़ में इसे हाइलाइट किया जाना चाहिए।
यदि हम केवल वैध विशेषाधिकार वाले उपयोगकर्ता बनाते हैं, तो यह पर्याप्त होगा, लेकिन दुर्भाग्य से, चीजें आमतौर पर इस तरह काम नहीं करती हैं। आपको 'संभावित सबसे खराब' परिदृश्यों के लिए तैयार रहने की आवश्यकता है। ज़रा सोचिए, यदि डिफ़ॉल्ट डेटाबेस स्वामी SA . होता तो हम अपने पहले के उदाहरणों में क्या कर सकते थे? !
चलिए दूसरे विकल्प के साथ चलते हैं, TRUSTWORTHY डेटाबेस विकल्प। स्थिति थोड़ी बेहतर है लेकिन फिर भी एक आम समस्या है। जैसा कि आमतौर पर माना जाता है, यहां सबसे अच्छा अभ्यास 'भरोसेमंद' डेटाबेस संपत्ति को बंद पर सेट करना है . हमने अभी देखा है कि यह विकल्प खराब . क्यों है ।
लेकिन यही सब कुछ नहीं है। यदि आप इस गुण को जांचने के लिए कुछ स्क्रिप्ट खोजने का प्रयास करते हैं, तो आपको शायद इस तरह की एक स्क्रिप्ट मिल जाएगी:
SELECT name FROM sys.databases WHERE is_trustworthy_on = 1 AND name != 'msdb'sp_Blitz स्क्रिप्ट जो SQL सर्वर स्वास्थ्य की जाँच करती है, डेटाबेस की डिफ़ॉल्ट सेटिंग्स (TRUSTWORTHY सहित 0 के डिफ़ॉल्ट मान के रूप में) की भी जाँच करती है और प्रत्येक डेटाबेस की रिपोर्ट करती है जिसमें गैर-डिफ़ॉल्ट सेटिंग्स होती हैं। हालांकि, स्क्रिप्ट सिस्टम डेटाबेस को छोड़ देती है।
इसके अलावा, एक एमएस केबी आलेख है, जो इस विषय पर केंद्रित है। SQL सर्वर में TRUSTWORTHY डेटाबेस सेटिंग्स का उपयोग करने के लिए दिशानिर्देश देखें:
लेख में एक कोड नमूना है, जो उन डेटाबेस को सूचीबद्ध करता है जिनके पास TRUSTWORTHY बिट चालू है, और जिनके डेटाबेस स्वामी sysadmin सर्वर भूमिका से संबंधित हैं:
SELECT SUSER_SNAME(owner_sid) AS DBOWNER, d.name AS DATABASENAME
FROM sys.server_principals r
INNER JOIN sys.server_role_members m ON r.principal_id = m.role_principal_id
INNER JOIN sys.server_principals p ON
p.principal_id = m.member_principal_id
inner join sys.databases d on suser_sname(d.owner_sid) = p.name
WHERE is_trustworthy_on = 1 AND d.name NOT IN ('MSDB') and r.type = 'R' and r.name = N'sysadmin'
इन लिपियों में क्या सामान्य है? प्रत्येक स्क्रिप्ट में MSDB शामिल नहीं है, लेकिन जैसा कि MS KB लेख नोट करता है, आपने इसे हमारे "मिशन" में देखा है:
नोट :डिफ़ॉल्ट रूप से, MSDB डेटाबेस के लिए TRUSTWORTHY सेटिंग चालू पर सेट होती है। इस सेटिंग को इसके डिफ़ॉल्ट मान से बदलने से MSDB डेटाबेस का उपयोग करने वाले SQL सर्वर घटकों द्वारा अनपेक्षित व्यवहार हो सकता है।
मैं इस बात पर जोर देना चाहूंगा कि इस खंड का मुख्य फोकस न तो TRUSTWORTHY डेटाबेस विकल्प है और न ही डेटाबेस स्वामी की संपत्ति, बल्कि इन दो विकल्पों का संयोजन है। मैंने ज्यादातर MSDB पर ध्यान केंद्रित किया है क्योंकि डिफ़ॉल्ट रूप से MSDB डेटाबेस के लिए TRUSTWORTHY सेटिंग चालू पर सेट है।
निष्कर्ष
अभी के लिए इतना ही। हमने SQL सर्वर सुरक्षा से संबंधित व्यावहारिक परिदृश्यों की जाँच की और जाँच की। हमने डेटाबेस के स्वामी और TRUSTWORTHY डेटाबेस सेटिंग के रूप में ऐसे महत्वपूर्ण डेटाबेस विकल्पों की भी समीक्षा की।
मैं केवल इन विकल्पों पर प्रकाश डालना चाहता था - क्योंकि वे महत्वपूर्ण हैं, खासकर जब हम उनके बारे में संयोजन में बात करते हैं।
