🥇सुरक्षा और डीबीएमएस: सुरक्षा उपकरण चुनते समय आपको क्या याद रखना चाहिए

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

यह आलेख एक भाषण के आधार पर तैयार किया गया था @डेटाबेसमीटअप, का आयोजन किया Mail.ru क्लाउड सॉल्यूशंस. अगर आप पढ़ना नहीं चाहते तो देख सकते हैं:

लेख के तीन भाग होंगे:

कनेक्शन कैसे सुरक्षित करें.
कार्यों का ऑडिट क्या है और डेटाबेस साइड पर क्या हो रहा है और उससे कनेक्ट हो रहा है उसे कैसे रिकॉर्ड किया जाए।
डेटाबेस में ही डेटा को कैसे सुरक्षित रखा जाए और इसके लिए कौन सी तकनीकें उपलब्ध हैं।

DBMS सुरक्षा के तीन घटक: कनेक्शन सुरक्षा, गतिविधि ऑडिटिंग और डेटा सुरक्षा

अपने कनेक्शन सुरक्षित करना

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

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

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

अब आइए देखें कि कनेक्शन सुरक्षित करने के लिए किन उपकरणों का उपयोग किया जा सकता है:

डेटाबेस फ़ायरवॉल क्लास समाधान का उपयोग करें। सुरक्षा की एक अतिरिक्त परत, कम से कम, डीबीएमएस में जो हो रहा है उसकी पारदर्शिता बढ़ाएगी, और अधिकतम, आप अतिरिक्त डेटा सुरक्षा प्रदान करने में सक्षम होंगे।
पासवर्ड नीतियों का प्रयोग करें. उनका उपयोग इस बात पर निर्भर करता है कि आपका आर्किटेक्चर कैसे बनाया गया है। किसी भी स्थिति में, डीबीएमएस से कनेक्ट होने वाले वेब एप्लिकेशन की कॉन्फ़िगरेशन फ़ाइल में एक पासवर्ड सुरक्षा के लिए पर्याप्त नहीं है। ऐसे कई DBMS उपकरण हैं जो आपको यह नियंत्रित करने की अनुमति देते हैं कि उपयोगकर्ता और पासवर्ड को अपडेट करने की आवश्यकता है।
आप उपयोगकर्ता रेटिंग फ़ंक्शंस के बारे में अधिक पढ़ सकते हैं यहां, आप MS SQL भेद्यता आकलनकर्ताओं के बारे में भी पता लगा सकते हैं यहां.
आवश्यक जानकारी के साथ सत्र के संदर्भ को समृद्ध करें। यदि सत्र अपारदर्शी है, आप यह नहीं समझते हैं कि इसके ढांचे के भीतर डीबीएमएस में कौन काम कर रहा है, तो आप किए जा रहे ऑपरेशन के ढांचे के भीतर, कौन क्या कर रहा है और क्यों कर रहा है, इसके बारे में जानकारी जोड़ सकते हैं। यह जानकारी ऑडिट में देखी जा सकती है.
यदि आपके पास DBMS और अंतिम उपयोगकर्ताओं के बीच नेटवर्क पृथक्करण नहीं है, तो SSL कॉन्फ़िगर करें; यह एक अलग VLAN में नहीं है। ऐसे मामलों में, उपभोक्ता और डीबीएमएस के बीच के चैनल की सुरक्षा करना अनिवार्य है। सुरक्षा उपकरण खुले स्रोत में भी उपलब्ध हैं।

इसका DBMS के प्रदर्शन पर क्या प्रभाव पड़ेगा?

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

प्रदर्शन परीक्षण चलाने के लिए pgbench का उपयोग करके PostgreSQL लोड करना एक सरल प्रोग्राम है। यह संभवतः समानांतर डेटाबेस सत्रों में आदेशों के एकल अनुक्रम को बार-बार निष्पादित करता है, और फिर औसत लेनदेन दर की गणना करता है।

एसएसएल के बिना और एसएसएल का उपयोग करके परीक्षण 1 - प्रत्येक लेनदेन के लिए कनेक्शन स्थापित किया गया है:

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require 
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

एसएसएल के बिना और एसएसएल का उपयोग करके परीक्षण 2 - सभी लेन-देन एक कनेक्शन में किए जाते हैं:

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres sslmode=require
sslrootcert=rootCA.crt sslcert=client.crt sslkey=client.key"

pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"

अन्य सेटिंग:

scaling factor: 1
query mode: simple
number of clients: 10
number of threads: 1
number of transactions per client: 5000
number of transactions actually processed: 50000/50000

परीक्षण के परिणाम:

कोई एसएसएल नहीं
एसएसएल

प्रत्येक लेनदेन के लिए एक कनेक्शन स्थापित किया जाता है

विलंबता औसत
171.915 एमएस
187.695 एमएस

कनेक्शन स्थापित करने सहित टीपीएस
58.168112
53.278062

कनेक्शन स्थापित करने को छोड़कर टीपीएस
64.084546
58.725846

सी पी यू
24% तक
28% तक

सभी लेन-देन एक ही कनेक्शन में किये जाते हैं

विलंबता औसत
6.722 एमएस
6.342 एमएस

कनेक्शन स्थापित करने सहित टीपीएस
1587.657278
1576.792883

कनेक्शन स्थापित करने को छोड़कर टीपीएस
1588.380574
1577.694766

सी पी यू
17% तक
21% तक

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

कृपया ध्यान दें कि यदि आप ऑपरेटिंग मोड की तुलना करते हैं तो एक मजबूत अंतर है: आप एक ही सत्र में या अलग-अलग सत्र में काम कर रहे हैं। यह समझने योग्य है: प्रत्येक कनेक्शन बनाने पर संसाधन खर्च किए जाते हैं।

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

निष्कर्ष: कई समाधानों में, प्रमाणीकरण में छोटी-छोटी बारीकियाँ भी परियोजना को बहुत प्रभावित कर सकती हैं और यह बुरा है जब यह केवल उत्पादन में लागू होने पर ही स्पष्ट हो जाता है।

कार्रवाई लेखापरीक्षा

ऑडिट सिर्फ DBMS ही नहीं हो सकता. ऑडिट विभिन्न क्षेत्रों में क्या हो रहा है, इसके बारे में जानकारी प्राप्त करने के बारे में है। यह या तो डेटाबेस फ़ायरवॉल या ऑपरेटिंग सिस्टम हो सकता है जिस पर DBMS बनाया गया है।

व्यावसायिक उद्यम स्तर के DBMS में ऑडिटिंग के साथ सब कुछ ठीक है, लेकिन खुले स्रोत में - हमेशा नहीं। यहाँ PostgreSQL में क्या है:

डिफ़ॉल्ट लॉग - अंतर्निहित लॉगिंग;
एक्सटेंशन: pgaudit - यदि डिफ़ॉल्ट लॉगिंग आपके लिए पर्याप्त नहीं है, तो आप अलग सेटिंग्स का उपयोग कर सकते हैं जो कुछ समस्याओं का समाधान करती हैं।

वीडियो में रिपोर्ट के अलावा:

"बेसिक स्टेटमेंट लॉगिंग को log_statement = all के साथ एक मानक लॉगिंग सुविधा द्वारा प्रदान किया जा सकता है।

यह निगरानी और अन्य उपयोगों के लिए स्वीकार्य है, लेकिन ऑडिटिंग के लिए आमतौर पर आवश्यक विवरण का स्तर प्रदान नहीं करता है।

डेटाबेस पर किए गए सभी कार्यों की सूची होना पर्याप्त नहीं है।

उन विशिष्ट बयानों को ढूंढना भी संभव होना चाहिए जो ऑडिटर के लिए रुचिकर हों।

मानक लॉगिंग से पता चलता है कि उपयोगकर्ता ने क्या अनुरोध किया है, जबकि pgAudit इस विवरण पर ध्यान केंद्रित करता है कि जब डेटाबेस ने क्वेरी निष्पादित की तो क्या हुआ।

उदाहरण के लिए, ऑडिटर यह सत्यापित करना चाह सकता है कि दस्तावेज़ रखरखाव विंडो के भीतर एक विशेष तालिका बनाई गई थी।

बुनियादी ऑडिटिंग और ग्रेप के साथ यह एक सरल कार्य प्रतीत हो सकता है, लेकिन क्या होगा यदि आपके सामने ऐसा कुछ (जानबूझकर भ्रमित करने वाला) उदाहरण प्रस्तुत किया जाए:

करो$$
शुरू
'टेबल आयात बनाएं' निष्पादित करें || 'ant_table (id int)';
END$$;

मानक लॉगिंग आपको यह देगी:

लॉग: कथन: $$ करें
शुरू
'टेबल आयात बनाएं' निष्पादित करें || 'ant_table (id int)';
END$$;

ऐसा प्रतीत होता है कि रुचि की तालिका खोजने के लिए उन मामलों में कुछ कोड ज्ञान की आवश्यकता हो सकती है जहां तालिकाएं गतिशील रूप से बनाई जाती हैं।

यह आदर्श नहीं है, क्योंकि केवल तालिका नाम से खोजना बेहतर होगा।

यहीं पर पीजीऑडिट काम आता है।

उसी इनपुट के लिए, यह लॉग में यह आउटपुट उत्पन्न करेगा:

ऑडिट: सत्र,33,1,फ़ंक्शन,करो,,,"करो $$
शुरू
'टेबल आयात बनाएं' निष्पादित करें || 'ant_table (id int)';
END$$;"
ऑडिट: सत्र,33,2,डीडीएल, तालिका बनाएं, तालिका, सार्वजनिक.महत्वपूर्ण_टेबल, तालिका बनाएं महत्वपूर्ण_टेबल (आईडी आईएनटी)

न केवल डीओ ब्लॉक लॉग किया गया है, बल्कि स्टेटमेंट प्रकार, ऑब्जेक्ट प्रकार और पूर्ण नाम के साथ क्रिएट टेबल का पूरा टेक्स्ट भी लॉग किया गया है, जिससे खोज आसान हो गई है।

SELECT और DML स्टेटमेंट लॉग करते समय, pgAudit को स्टेटमेंट में संदर्भित प्रत्येक संबंध के लिए एक अलग प्रविष्टि लॉग करने के लिए कॉन्फ़िगर किया जा सकता है।

किसी विशेष तालिका को छूने वाले सभी कथनों को खोजने के लिए किसी पार्सिंग की आवश्यकता नहीं है(*). "

इसका DBMS के प्रदर्शन पर क्या प्रभाव पड़ेगा?

आइए पूर्ण ऑडिटिंग सक्षम करके परीक्षण चलाएं और देखें कि PostgreSQL प्रदर्शन का क्या होता है। आइए सभी मापदंडों के लिए अधिकतम डेटाबेस लॉगिंग सक्षम करें।

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

postgresql.conf

लॉग_डेस्टिनेशन = 'stderr'
लॉगिंग_कलेक्टर = चालू
log_truncat_on_rotation = चालू
लॉग_रोटेशन_आयु = 1 दिन
लॉग_रोटेशन_आकार = 10एमबी
log_min_messages = डीबग5
log_min_error_statement = डीबग5
log_min_duration_statement = 0
डिबग_प्रिंट_पार्स = चालू
डिबग_प्रिंट_रीराइट = चालू
डिबग_प्रिंट_प्लान = चालू
डिबग_प्रिटी_प्रिंट = चालू
लॉग_चेकप्वाइंट = चालू
लॉग_कनेक्शन = चालू
लॉग_डिस्कनेक्शन = चालू
लॉग_अवधि = चालू
लॉग_होस्टनाम = चालू
लॉग_लॉक_वेट्स = चालू
log_replication_commands = चालू
log_temp_files = 0
log_timezone = 'यूरोप/मॉस्को'

1 सीपीयू, 2,8 गीगाहर्ट्ज, 2 जीबी रैम, 40 जीबी एचडीडी के पैरामीटर वाले पोस्टग्रेएसक्यूएल डीबीएमएस पर, हम कमांड का उपयोग करके तीन लोड परीक्षण करते हैं:

$ pgbench -p 3389 -U postgres -i -s 150 benchmark
$ pgbench -p 3389 -U postgres -c 50 -j 2 -P 60 -T 600 benchmark
$ pgbench -p 3389 -U postgres -c 150 -j 2 -P 60 -T 600 benchmark

परीक्षा के परिणाम:

कोई लॉगिंग नहीं
लॉगिंग के साथ

कुल डेटाबेस भरने का समय
43,74 सेकंड
53,23 सेकंड

डकैती
24% तक
40% तक

सी पी यू
72% तक
91% तक

परीक्षण 1 (50 कनेक्शन)

10 मिनट में लेनदेन की संख्या
74169
32445

लेनदेन/सेकंड
123
54

औसत विलंबता
405 एमएस
925 एमएस

परीक्षण 2 (150 कनेक्शन और 100 संभव)

10 मिनट में लेनदेन की संख्या
81727
31429

लेनदेन/सेकंड
136
52

औसत विलंबता
550 एमएस
1432 एमएस

आकार के बारे में

डीबी आकार
2251 एमबी
2262 एमबी

डेटाबेस लॉग आकार
0 MB
4587 MB

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

आइए अन्य मापदंडों को देखें:

गति ज्यादा नहीं बदलती: लॉगिंग के बिना - 43,74 सेकंड, लॉगिंग के साथ - 53,23 सेकंड।
रैम और सीपीयू का प्रदर्शन प्रभावित होगा, क्योंकि आपको एक ऑडिट फ़ाइल तैयार करने की आवश्यकता होगी। यह उत्पादकता में भी ध्यान देने योग्य है।

जैसे-जैसे कनेक्शनों की संख्या बढ़ेगी, स्वाभाविक रूप से, प्रदर्शन थोड़ा खराब हो जाएगा।

ऑडिट वाले निगमों में यह और भी कठिन है:

बहुत सारा डेटा है;
ऑडिटिंग की आवश्यकता न केवल SIEM में syslog के माध्यम से होती है, बल्कि फाइलों में भी होती है: यदि syslog में कुछ होता है, तो डेटाबेस के करीब एक फ़ाइल होनी चाहिए जिसमें डेटा सहेजा जाता है;
ऑडिटिंग के लिए, एक अलग शेल्फ की आवश्यकता होती है ताकि I/O डिस्क पर बर्बादी न हो, क्योंकि इसमें बहुत अधिक जगह लगती है;
ऐसा होता है कि सूचना सुरक्षा कर्मचारियों को हर जगह GOST मानकों की आवश्यकता होती है, उन्हें राज्य की पहचान की आवश्यकता होती है।

डेटा तक पहुंच प्रतिबंधित करना

आइए उन तकनीकों पर नज़र डालें जिनका उपयोग डेटा की सुरक्षा और उसे वाणिज्यिक डीबीएमएस और ओपन सोर्स में एक्सेस करने के लिए किया जाता है।

आप आम तौर पर क्या उपयोग कर सकते हैं:

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

यह DBMS के प्रदर्शन को कैसे प्रभावित करता है?

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

आइए pgcrypto के साथ परीक्षण करें. आइए एन्क्रिप्टेड डेटा और नियमित डेटा के साथ एक तालिका बनाएं। नीचे टेबल बनाने के लिए कमांड दिए गए हैं, पहली पंक्ति में एक उपयोगी कमांड है - डीबीएमएस पंजीकरण के साथ ही एक्सटेंशन बनाना:

CREATE EXTENSION pgcrypto;
CREATE TABLE t1 (id integer, text1 text, text2 text);
CREATE TABLE t2 (id integer, text1 bytea, text2 bytea);
INSERT INTO t1 (id, text1, text2)
VALUES (generate_series(1,10000000), generate_series(1,10000000)::text, generate_series(1,10000000)::text);
INSERT INTO t2 (id, text1, text2) VALUES (
generate_series(1,10000000),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'),
encrypt(cast(generate_series(1,10000000) AS text)::bytea, 'key'::bytea, 'bf'));

इसके बाद, आइए प्रत्येक तालिका से डेटा नमूना बनाने का प्रयास करें और निष्पादन समय को देखें।

एन्क्रिप्शन फ़ंक्शन के बिना तालिका से चयन करना:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

स्टॉपवॉच चालू है.

आईडी | पाठ 1 | टेक्स्ट 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 पंक्तियाँ)

समय: 1,386 मि.से

एन्क्रिप्शन फ़ंक्शन वाली तालिका से चयन:

psql -c "timing" -c "select id, decrypt(text1, 'key'::bytea, 'bf'),
decrypt(text2, 'key'::bytea, 'bf') from t2 limit 1000;"
"host=192.168.220.129 dbname=taskdb user=postgres sslmode=disable" > 2.txt

स्टॉपवॉच चालू है.

आईडी | डिक्रिप्ट | डिक्रिप्ट
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 पंक्तियाँ)

समय: 50,203 मि.से

परीक्षण के परिणाम:

एन्क्रिप्शन के बिना
पीजीक्रिप्टो (डिक्रिप्ट)

नमूना 1000 पंक्तियाँ
1,386 एमएस
50,203 एमएस

सी पी यू
15% तक
35% तक

डकैती

+ 5%

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

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

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

MongoDB में ऐसे एन्क्रिप्शन का एक उदाहरण

वाणिज्यिक और मुक्त स्रोत DBMS में सुरक्षा सुविधाएँ

कार्य
टाइप
पासवर्ड नीति
लेखा परीक्षा
प्रक्रियाओं और कार्यों के स्रोत कोड की सुरक्षा करना
आरएलएस
कूटलेखन

ओरेकल
व्यावसायिक
+
+
+
+
+

एमएसक्यूएल
व्यावसायिक
+
+
+
+
+

जटोबा
व्यावसायिक
+
+
+
+
एक्सटेंशन

पोस्टग्रेएसक्यूएल
मुक्त
एक्सटेंशन
एक्सटेंशन
-
+
एक्सटेंशन

मोंगोडीबी
मुक्त
-
+
-
-
केवल MongoDB एंटरप्राइज़ में उपलब्ध है

तालिका पूर्ण नहीं है, लेकिन स्थिति यह है: वाणिज्यिक उत्पादों में, सुरक्षा समस्याओं को लंबे समय से हल किया गया है, खुले स्रोत में, एक नियम के रूप में, सुरक्षा के लिए कुछ प्रकार के ऐड-ऑन का उपयोग किया जाता है, कई फ़ंक्शन गायब हैं , कभी-कभी आपको कुछ जोड़ना पड़ता है। उदाहरण के लिए, पासवर्ड नीतियां - PostgreSQL में कई अलग-अलग एक्सटेंशन हैं (1, 2, 3, 4, 5), जो पासवर्ड नीतियों को लागू करते हैं, लेकिन, मेरी राय में, उनमें से कोई भी घरेलू कॉर्पोरेट सेगमेंट की सभी जरूरतों को पूरा नहीं करता है।

अगर आपके पास कहीं भी वह नहीं है जिसकी आपको जरूरत है तो क्या करें?? उदाहरण के लिए, आप एक विशिष्ट DBMS का उपयोग करना चाहते हैं जिसमें वे फ़ंक्शन नहीं हैं जिनकी ग्राहक को आवश्यकता होती है।

फिर आप तृतीय-पक्ष समाधानों का उपयोग कर सकते हैं जो विभिन्न DBMS के साथ काम करते हैं, उदाहरण के लिए, क्रिप्टो DB या गार्डा DB। यदि हम घरेलू खंड के समाधानों के बारे में बात कर रहे हैं, तो वे खुले स्रोत की तुलना में GOSTs के बारे में बेहतर जानते हैं।

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

यह रिपोर्ट पहली बार प्रस्तुत की गई थी @डेटाबेस मीटअप Mail.ru क्लाउड सॉल्यूशंस द्वारा। देखना वीडियो अन्य प्रदर्शन और टेलीग्राम पर ईवेंट घोषणाओं की सदस्यता लें Mail.ru ग्रुप पर कुबेरनेट्स के आसपास.

विषय पर और क्या पढ़ना है:

स्रोत: www.habr.com

सुरक्षा और डीबीएमएस: सुरक्षा उपकरण चुनते समय आपको क्या याद रखना चाहिए

अपने कनेक्शन सुरक्षित करना

इसका DBMS के प्रदर्शन पर क्या प्रभाव पड़ेगा?

कार्रवाई लेखापरीक्षा

इसका DBMS के प्रदर्शन पर क्या प्रभाव पड़ेगा?

डेटा तक पहुंच प्रतिबंधित करना

यह DBMS के प्रदर्शन को कैसे प्रभावित करता है?

वाणिज्यिक और मुक्त स्रोत DBMS में सुरक्षा सुविधाएँ

एक टिप्पणी जोड़ें उत्तर रद्द