Oracle में डेटाबेस सुरक्षा

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

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

पहुंच अनुमतियां

अधिकांश कंपनियों में मैंने काम किया, सभी प्रशासकों और डेवलपर्स के पास डेटाबेस तक पूरी पहुंच थी, साथ ही आईटी विभाग का एक कर्मचारी एक भगवान था और जो कुछ भी चाहता था वह कर सकता था। ऐसा क्यों होता है? इसके दो कारण हैं:

1. एक विभाग में काम करते हुए, कर्मचारी हर दिन 8 घंटे एक दूसरे से मिल सकते हैं और दोस्त बन सकते हैं। वे कैसे पहुंच प्रदान नहीं कर सकते? दोस्ती एक चीज है लेकिन बिजनेस बिजनेस है।
2. कुछ एक्सेस अधिकार देने या कुछ कॉन्फ़िगरेशन को संशोधित करने के लिए कुछ विशेषाधिकारों की आवश्यकता हो सकती है। कभी-कभी, प्रशासक सोचते हैं कि प्रोग्रामर सेटिंग्स को बेहतर तरीके से कॉन्फ़िगर करते हैं। इस प्रकार, वे प्रोग्रामर को अनावश्यक एक्सेस अधिकार प्रदान करते हैं। इसके बजाय, प्रोग्रामर को प्रशासन में शामिल नहीं होना चाहिए और इसके लिए उनके पास कोई अधिकार नहीं होना चाहिए।

मेरे अनुभव में, दूसरी समस्या बहुत आम है, इसलिए, हम इसका विस्तार से विश्लेषण करेंगे।

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

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

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

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

उपयोगकर्ता और भूमिकाएं

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

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

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

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

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

सुरक्षा ऑडिट

यदि प्रत्येक उपयोगकर्ता आपके डेटाबेस में अपने स्वयं के खाते के अंतर्गत काम कर रहा है, तो आप वर्तमान उपयोगकर्ता को निर्धारित करने के लिए उपयोगकर्ता चर को कॉल कर सकते हैं, उदाहरण के लिए:

SELECT user from dual

यह क्वेरी एक उपयोगकर्ता नाम लौटाएगी, जिसके तहत सर्वर से कनेक्शन खोला गया है। यदि एक नाम का उपयोग करके कई लोग लॉग इन कर सकते हैं, तो यह क्वेरी दोनों के लिए समान नाम लौटाएगी और यह ऑडिट के लिए बेकार होगी। विशेष रूप से, यदि सर्वर स्तर पर तालाबंदी नियंत्रण होता है।

यदि कई उपयोगकर्ता एक ही उपयोगकर्ता नाम का उपयोग करके लॉग इन कर सकते हैं, तो यह जटिल है, लेकिन फिर भी संभव है, यह पहचानना कि किसने खाते में लॉग इन किया है। निम्नलिखित प्रश्न सत्र के बारे में विस्तृत जानकारी प्राप्त करने की अनुमति देता है:

select s.user#, s.username, s.osuser, s.terminal, s.program
from sys.v_$session s
WHERE username=user

जैसा कि आप देख सकते हैं, क्वेरी ने उपयोगकर्ता नाम, डेटाबेस से जुड़ा, ऑपरेटिंग सिस्टम में एक नाम, एक टर्मिनल उपयोगकर्ता नाम और एक प्रोग्राम लौटा दिया।

यहां, आप sys सिस्टम स्कीमा से v_$session दृश्य तक पहुंच सकते हैं। यह दृश्य सर्वर से कनेक्शन के बारे में कुछ जानकारी देता है। WHERE क्लॉज में, हम आउटपुट को केवल वर्तमान उपयोगकर्ता तक ही सीमित रखते हैं। परिणामस्वरूप, क्वेरी उपयोगकर्ता आईडी, नाम, ऑपरेटिंग सिस्टम में नाम, टर्मिनल और उस प्रोग्राम को लौटाती है जिससे कनेक्शन स्थापित किया गया था।

जब आप एक उपयोगकर्ता नाम और एक टर्मिनल नाम जानते हैं, तो आप निश्चित रूप से एक उपयोगकर्ता की पहचान कर सकते हैं। यह जानने के लिए कि वर्तमान उपयोगकर्ता को किन भूमिकाओं में जोड़ा गया है, आप निम्न क्वेरी चला सकते हैं:

SELECT GRANTED_ROLE 
FROM dba_role_privs 
WHERE grantee=user

खाता सुरक्षा

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

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

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

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

यह जांचने के लिए कि उपयोगकर्ता एक ही नाम के दो अलग-अलग कंप्यूटरों से एक साथ काम नहीं करते हैं, आप निम्न क्वेरी निष्पादित कर सकते हैं:

select s.username, s.terminal, count(*)
from sys.v_$session s
WHERE username=user
HAVING count(*)>1
GROUP BY s.username, s.terminal

वास्तव में, इसे कोई रिकॉर्ड वापस नहीं करना चाहिए।

दृश्य

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

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

SELECT list of fields
FROM view, table_1, table_2
WHERE some parameters

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

अब, क्वेरी को देखते हैं जैसे डेटाबेस अनुकूलक इसे देखता है:

SELECT list of fields
FROM (SELECT ...), table1, table2
WHERE some parameters

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

डेटा सुरक्षा

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

डेटा के लिए सबसे खतरनाक संचालन क्रमशः अद्यतन और हटाना, संशोधन और हटाना है। आपको इन अधिकारों को सावधानीपूर्वक देने की आवश्यकता है। सुनिश्चित करें कि डेटा को संशोधित या हटाया जा सकता है। केवल इस मामले में, उपयुक्त अधिकारों का चयन करें। कुछ टेबल केवल प्रकृति द्वारा बढ़ाए जाते हैं।

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

ग्रांट ऑपरेटर का उपयोग करके अधिकार प्रदान किया जाता है। सामान्य तौर पर, यह इस तरह दिखता है:

उपयोगकर्ताओं या भूमिकाओं को ON ऑब्जेक्ट्स के अधिकार देने के लिए अनुदान दें

उदाहरण के लिए, निम्न क्वेरी User1 को टेस्टटेबल टेबल डालने और देखने का अधिकार देती है:

GRANT Select, Insert ON TestTable TO User1

विदेशी कुंजी

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

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

बैकअप

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

अग्रिम में सबसे प्रभावी बैकअप नीति विकसित करना आवश्यक है। इससे क्या तात्पर्य है? डेटा हानि के कारण डाउनटाइम और कार्य क्षमता की बहाली के क्षण तक न्यूनतम होना चाहिए। डेटा हानि भी न्यूनतम होनी चाहिए, और बैकअप उपयोगकर्ता के काम को प्रभावित नहीं करना चाहिए। यदि धन और अवसर हैं, तो RAID, क्लस्टर या यहां तक ​​कि डेटा प्रतिकृति जैसे सिस्टम का उपयोग करना बेहतर है।

बैकअप और रिकवरी एक अलग और दिलचस्प विषय है। हम इसे यहां स्पर्श नहीं कर सके, लेकिन हम इस पर विस्तार से विचार नहीं करेंगे।

सारांश

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

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

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

यह भी पढ़ें:

डेटाबेस एक्सेस अनुमतियां सेट करना