मेरो नाम डेनिस रोजकोभ हो, म उत्पादन टोलीमा Gazinformservice कम्पनीमा सफ्टवेयर विकासको प्रमुख हुँ। जाटोबा। कानून र कर्पोरेट नियमहरूले डेटा भण्डारणको सुरक्षाको लागि निश्चित आवश्यकताहरू लागू गर्दछ। कोही पनि तेस्रो पक्षहरूले गोप्य जानकारीमा पहुँच प्राप्त गर्न चाहँदैनन्, त्यसैले निम्न मुद्दाहरू कुनै पनि परियोजनाको लागि महत्त्वपूर्ण छन्: पहिचान र प्रमाणीकरण, डाटामा पहुँच व्यवस्थापन, प्रणालीमा जानकारीको अखण्डता सुनिश्चित गर्ने, सुरक्षा घटनाहरू लग गर्ने। त्यसकारण, म DBMS सुरक्षा सम्बन्धी केही रोचक बिन्दुहरूको बारेमा कुरा गर्न चाहन्छु।

लेख मा एक भाषण को आधार मा तयार गरिएको थियो @DatabasesMeetup, संगठित Mail.ru क्लाउड समाधान। यदि तपाइँ पढ्न चाहनुहुन्न भने, तपाइँ हेर्न सक्नुहुन्छ:

लेख तीन भाग हुनेछ:

• जडानहरू कसरी सुरक्षित गर्ने।
• कार्यहरूको लेखापरीक्षण भनेको के हो र डाटाबेस साइडमा के भइरहेको छ र यसलाई जडान गर्ने कसरी रेकर्ड गर्ने।
• डाटाबेसमा नै डाटा कसरी सुरक्षित गर्ने र यसका लागि कस्ता प्रविधिहरू उपलब्ध छन्।

DBMS सुरक्षा को तीन घटक: जडान सुरक्षा, गतिविधि लेखा र डाटा सुरक्षा

तपाईंको जडानहरू सुरक्षित गर्दै

तपाइँ वेब अनुप्रयोगहरू मार्फत प्रत्यक्ष वा अप्रत्यक्ष रूपमा डाटाबेसमा जडान गर्न सक्नुहुन्छ। एक नियम को रूप मा, व्यापार प्रयोगकर्ता, त्यो हो, DBMS संग काम गर्ने व्यक्ति, यो अप्रत्यक्ष रूपमा अन्तरक्रिया गर्दछ।

जडानहरू सुरक्षित गर्ने बारे कुरा गर्नु अघि, तपाईंले सुरक्षा उपायहरू कसरी संरचित गरिनेछ भनेर निर्धारण गर्ने महत्त्वपूर्ण प्रश्नहरूको जवाफ दिन आवश्यक छ:

• के एक व्यापार प्रयोगकर्ता एक DBMS प्रयोगकर्ता बराबर छ?
• DBMS डाटामा पहुँच तपाईंले नियन्त्रण गर्ने एपीआई मार्फत मात्र उपलब्ध गराइन्छ, वा तालिकाहरू सीधै पहुँच गरिएको छ कि छैन;
• DBMS छुट्टै सुरक्षित खण्डमा आवंटित गरिएको छ कि छैन, कसले यससँग अन्तरक्रिया गर्छ र कसरी;
• के पूलिङ/प्रोक्सी र मध्यवर्ती तहहरू प्रयोग गरिन्छ, जसले जडान कसरी बनाइन्छ र कसले डाटाबेस प्रयोग गरिरहेको छ भन्ने बारे जानकारी परिवर्तन गर्न सक्छ।

अब हेरौं कुन उपकरण जडानहरू सुरक्षित गर्न प्रयोग गर्न सकिन्छ:

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

   तपाइँ प्रयोगकर्ता मूल्याङ्कन कार्यहरूको बारेमा थप पढ्न सक्नुहुन्छ यहाँ, तपाईले MS SQL Vulnerability Assessmen बारे पनि पत्ता लगाउन सक्नुहुन्छ यहाँ. 

3. आवश्यक जानकारीको साथ सत्रको सन्दर्भलाई समृद्ध बनाउनुहोस्। यदि सत्र अपारदर्शी छ भने, तपाईंले DBMS मा यसको ढाँचा भित्र कसले काम गरिरहेको छ भनेर बुझ्नुहुन्न, तपाईं, सञ्चालन भइरहेको कार्यको ढाँचा भित्र, कसले र किन गरिरहेको छ भन्ने बारे जानकारी थप्न सक्नुहुन्छ। यो जानकारी लेखापरीक्षणमा देख्न सकिन्छ।
4. यदि तपाइँसँग DBMS र अन्तिम प्रयोगकर्ताहरू बीच नेटवर्क विभाजन छैन भने SSL कन्फिगर गर्नुहोस्; यो छुट्टै VLAN मा छैन। यस्तो अवस्थामा, उपभोक्ता र DBMS बीचको च्यानलको सुरक्षा गर्न अनिवार्य छ। सुरक्षा उपकरणहरू खुला स्रोतमा पनि उपलब्ध छन्।

यसले DBMS को प्रदर्शनलाई कसरी असर गर्छ?

PostgreSQL को उदाहरण हेरौं कि कसरी SSL ले CPU लोडलाई असर गर्छ, समय बढाउँछ र TPS घटाउँछ, र यदि तपाईंले यसलाई सक्षम गर्नुभयो भने यसले धेरै स्रोतहरू खपत गर्छ कि गर्दैन।

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

परीक्षण 1 बिना SSL र SSL प्रयोग गरेर - प्रत्येक लेनदेनको लागि जडान स्थापित छ:

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"

vs

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

परीक्षण 2 बिना SSL र SSL प्रयोग गरेर - सबै लेनदेन एक जडान मा प्रदर्शन गरिन्छ:

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"

vs

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

परीक्षण नतीजा:

 
कुनै SSL छैन
SSL

प्रत्येक लेनदेनको लागि जडान स्थापित छ

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

जडानहरू स्थापना सहित tps
58.168112
53.278062

जडानहरू स्थापना बाहेक tps
64.084546
58.725846

CPU
24%
28%

सबै लेनदेन एक जडान मा प्रदर्शन गरिन्छ

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

जडानहरू स्थापना सहित tps
1587.657278
1576.792883

जडानहरू स्थापना बाहेक tps
1588.380574
1577.694766

CPU
17%
21%

हल्का लोडहरूमा, SSL को प्रभाव मापन त्रुटिसँग तुलना गर्न सकिन्छ। यदि स्थानान्तरण गरिएको डाटाको मात्रा धेरै ठूलो छ भने, स्थिति फरक हुन सक्छ। यदि हामीले प्रति लेनदेन एक जडान स्थापना गर्छौं (यो दुर्लभ छ, सामान्यतया जडान प्रयोगकर्ताहरू बीच साझा गरिन्छ), तपाईंसँग धेरै संख्यामा जडानहरू/विच्छेदहरू छन्, प्रभाव थोरै ठूलो हुन सक्छ। त्यो हो, त्यहाँ कम प्रदर्शन को जोखिम हुन सक्छ, तथापि, भिन्नता यति ठूलो छैन कि सुरक्षा प्रयोग नगर्ने।

कृपया ध्यान दिनुहोस् कि यदि तपाइँ अपरेटिङ मोडहरू तुलना गर्नुहुन्छ भने त्यहाँ एक बलियो भिन्नता छ: तपाइँ एउटै सत्र भित्र वा फरकमा काम गर्दै हुनुहुन्छ। यो बुझ्न योग्य छ: स्रोतहरू प्रत्येक जडान सिर्जना गर्न खर्च गरिन्छ।

हामीसँग एउटा केस थियो जब हामीले ट्रस्ट मोडमा Zabbix जडान गर्यौं, त्यो हो, md5 जाँच गरिएको थिएन, प्रमाणीकरणको लागि कुनै आवश्यकता थिएन। त्यसपछि ग्राहकले md5 प्रमाणीकरण मोड सक्षम गर्न आग्रह गरे। यसले CPU मा भारी भार राख्यो, र प्रदर्शन घट्यो। हामीले अप्टिमाइज गर्ने तरिकाहरू खोज्न थाल्यौं। समस्याको सम्भावित समाधानहरू मध्ये एउटा नेटवर्क प्रतिबन्धहरू लागू गर्नु, DBMS का लागि छुट्टै VLAN बनाउनु, को कहाँबाट जडान भइरहेको छ भनेर स्पष्ट पार्न सेटिङहरू थप्नुहोस् र प्रमाणीकरण हटाउनु हो। तपाईं प्रमाणीकरण सक्षम गर्दा लागत घटाउन प्रमाणीकरण सेटिङहरू पनि अनुकूलन गर्न सक्नुहुन्छ, तर सामान्यतया विभिन्न विधिहरूको प्रयोग प्रमाणीकरणले कार्यसम्पादनलाई असर गर्छ र DBMS को लागि सर्भर (हार्डवेयर) को कम्प्युटिङ पावर डिजाइन गर्दा यी कारकहरूलाई ध्यानमा राख्न आवश्यक हुन्छ।

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

कार्य लेखापरीक्षण

अडिट DBMS मात्र हुन सक्दैन। लेखापरीक्षण भनेको विभिन्न खण्डहरूमा के भइरहेको छ भन्ने बारे जानकारी प्राप्त गर्ने बारे हो। यो या त डाटाबेस फायरवाल वा DBMS बनाइएको अपरेटिङ सिस्टम हुन सक्छ।

व्यावसायिक उद्यम स्तर DBMSs मा सबै कुरा लेखा परीक्षण संग ठीक छ, तर खुला स्रोत मा - सधैं होइन। यहाँ PostgreSQL के छ:

• पूर्वनिर्धारित लग - निर्मित लगिङ;
• विस्तारहरू: pgaudit - यदि पूर्वनिर्धारित लगिङ तपाईंको लागि पर्याप्त छैन भने, तपाईंले केही समस्याहरू समाधान गर्ने छुट्टै सेटिङहरू प्रयोग गर्न सक्नुहुन्छ।

भिडियोमा रिपोर्टमा थप्नुहोस्:

"आधारभूत कथन लगिङ log_statement = all सँग मानक लगिङ सुविधाद्वारा प्रदान गर्न सकिन्छ।

यो अनुगमन र अन्य प्रयोगहरूको लागि स्वीकार्य छ, तर सामान्यतया लेखा परीक्षणको लागि आवश्यक विवरणको स्तर प्रदान गर्दैन।

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

लेखापरीक्षकको चासोका विशेष कथनहरू फेला पार्न पनि सम्भव हुनुपर्छ।

मानक लगिङले प्रयोगकर्ताले के अनुरोध गरेको देखाउँछ, जबकि pgAudit ले डाटाबेसले क्वेरी कार्यान्वयन गर्दा के भयो भन्ने विवरणमा केन्द्रित हुन्छ।

उदाहरणका लागि, लेखा परीक्षकले दस्तावेज मर्मत सञ्झ्याल भित्र एउटा विशेष तालिका सिर्जना गरिएको हो भनी प्रमाणित गर्न चाहन्छ।

यो आधारभूत लेखापरीक्षण र grep को साथ एक साधारण कार्य जस्तो लाग्न सक्छ, तर के हुन्छ यदि तपाईंलाई यस्तो (जानाजानी भ्रामक) उदाहरणको साथ प्रस्तुत गरिएको थियो:

गर्नुहोस्$$
BEGIN
'तालिका आयात सिर्जना गर्नुहोस्' कार्यान्वयन गर्नुहोस् || 'ant_table(id int)';
अन्त्य$$;

मानक लगिङले तपाईंलाई यो दिनेछ:

LOG: कथन: DO $$
BEGIN
'तालिका आयात सिर्जना गर्नुहोस्' कार्यान्वयन गर्नुहोस् || 'ant_table(id int)';
अन्त्य$$;

यस्तो देखिन्छ कि तालिकाहरू गतिशील रूपमा सिर्जना गरिएका अवस्थामा रुचिको तालिका फेला पार्न केही कोड ज्ञान आवश्यक हुन सक्छ।

यो आदर्श होइन, किनकि यो केवल तालिका नाम द्वारा खोजी गर्न उपयुक्त हुनेछ।

यो जहाँ pgAudit काममा आउँछ।

उही इनपुटको लागि, यसले लगमा यो आउटपुट उत्पादन गर्नेछ:

लेखापरीक्षण: सत्र, ३३,१, प्रकार्य, गर,,," DO$$
BEGIN
'तालिका आयात सिर्जना गर्नुहोस्' कार्यान्वयन गर्नुहोस् || 'ant_table(id int)';
अन्त्य$$;"
लेखापरीक्षण: सत्र,३३,२,डीडीएल,तालिका सिर्जना गर्नुहोस्,तालिका,सार्वजनिक.महत्वपूर्ण_तालिका,तालिका महत्वपूर्ण_तालिका सिर्जना गर्नुहोस् (आईडी आईएनटी)

DO ब्लक मात्र लगाइएको छैन, तर कथन प्रकार, वस्तु प्रकार, र पूरा नाम सहितको CREATE TABLE को पूर्ण पाठ पनि खोज्न सजिलो बनाइन्छ।

SELECT र DML कथनहरू लग गर्दा, pgAudit लाई कथनमा सन्दर्भ गरिएको प्रत्येक सम्बन्धको लागि छुट्टै प्रविष्टि लग गर्न कन्फिगर गर्न सकिन्छ।

कुनै विशेष तालिका छुने सबै कथनहरू फेला पार्न कुनै पार्सिङ आवश्यक पर्दैन (*) »।

यसले DBMS को प्रदर्शनलाई कसरी असर गर्छ?

पूर्ण अडिटिङ सक्षम गरी परीक्षणहरू चलाउनुहोस् र PostgreSQL कार्यसम्पादनमा के हुन्छ हेर्नुहोस्। सबै प्यारामिटरहरूको लागि अधिकतम डाटाबेस लगिङ सक्षम गरौं।

हामी कन्फिगरेसन फाइलमा लगभग केहि परिवर्तन गर्दैनौं, सबैभन्दा महत्त्वपूर्ण कुरा अधिकतम जानकारी प्राप्त गर्न debug5 मोड खोल्नु हो।

postgresql.conf

log_destination = 'stderr'
लगिङ_कलेक्टर = अन
log_truncate_on_rotation = अन
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = अन
debug_pretty_print = अन
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_hostname = on
log_lock_wait = अन
log_replication_commands = अन
log_temp_files = 0
log_timezone = 'युरोप/मस्को'

1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD को प्यारामिटरहरू भएको PostgreSQL DBMS मा, हामी आदेशहरू प्रयोग गरेर तीन लोड परीक्षणहरू सञ्चालन गर्छौं:

$ 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%

CPU
72%
91%

परीक्षण १ (५० जडानहरू)

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

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

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

परीक्षण २ (सम्भावित १०० संग १५० जडानहरू)

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

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

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

आकारहरूको बारेमा

DB आकार
MB MB
MB MB

डाटाबेस लग आकार
0 एमबी
4587 एमबी

तल्लो रेखा: पूर्ण अडिट धेरै राम्रो छैन। लेखापरीक्षणको डाटा डाटाबेसमा रहेको डाटा जत्तिकै ठूलो हुनेछ वा त्योभन्दा पनि बढी हुनेछ। DBMS सँग काम गर्दा उत्पन्न हुने लगिङको मात्रा उत्पादनमा सामान्य समस्या हो।

अन्य प्यारामिटरहरू हेरौं:

• गति धेरै परिवर्तन गर्दैन: लग बिना - 43,74 सेकेन्ड, लगिङ संग - 53,23 सेकेन्ड।
• RAM र CPU कार्यसम्पादनमा असर पर्नेछ, किनकि तपाईंले अडिट फाइल उत्पन्न गर्न आवश्यक छ। यो उत्पादकत्वमा पनि उल्लेखनीय छ।

जडानहरूको संख्या बढ्दै जाँदा, स्वाभाविक रूपमा, प्रदर्शन थोरै बिग्रन्छ।

लेखापरीक्षणको साथ निगमहरूमा यो अझ गाह्रो छ:

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

डाटा पहुँच प्रतिबन्ध

डाटा सुरक्षित गर्न र यसलाई व्यावसायिक DBMS र खुला स्रोतमा पहुँच गर्न प्रयोग गरिने प्रविधिहरू हेरौं।

तपाइँ सामान्यतया के प्रयोग गर्न सक्नुहुन्छ:

1. इन्क्रिप्शन र प्रक्रिया र प्रकार्यहरूको अस्पष्टता (रेपिङ) - त्यो हो, पढ्न योग्य कोड अपठनीय बनाउने अलग उपकरण र उपयोगिताहरू। साँचो, त्यसोभए यसलाई न परिवर्तन गर्न सकिन्छ न त फिर्ता गर्न सकिन्छ। यो दृष्टिकोण कहिलेकाहीं कम्तिमा DBMS पक्षमा आवश्यक हुन्छ - इजाजतपत्र प्रतिबन्ध वा प्राधिकरण तर्कको तर्क प्रक्रिया र प्रकार्य स्तरमा ठीक इन्क्रिप्ट गरिएको छ।
2. पङ्क्तिहरू (RLS) द्वारा डेटाको दृश्यता सीमित गर्नु भनेको विभिन्न प्रयोगकर्ताहरूले एउटा तालिका देख्दा, तर यसमा पङ्क्तिहरूको फरक संरचना, अर्थात्, पङ्क्ति स्तरमा कसैलाई केही देखाउन सकिँदैन।
3. तालिकाको एउटा स्तम्भमा प्रयोगकर्ताहरूले डेटा वा ताराहरू मात्र देख्दा प्रदर्शित डाटा (मास्किङ) सम्पादन गर्नु हो, अर्थात् केही प्रयोगकर्ताहरूको लागि सूचना बन्द हुनेछ। टेक्नोलोजीले कुन प्रयोगकर्तालाई उनीहरूको पहुँच स्तरको आधारमा देखाइन्छ भनेर निर्धारण गर्दछ।
4. सुरक्षा DBA/Application DBA/DBA पहुँच नियन्त्रण भनेको DBMS मा पहुँच प्रतिबन्धित गर्ने बारे हो, अर्थात्, सूचना सुरक्षा कर्मचारीहरूलाई डाटाबेस प्रशासकहरू र अनुप्रयोग प्रशासकहरूबाट अलग गर्न सकिन्छ। त्यहाँ खुला स्रोतमा त्यस्ता प्रविधिहरू थोरै छन्, तर व्यावसायिक DBMS मा ती धेरै छन्। तिनीहरू आवश्यक हुन्छन् जब त्यहाँ धेरै प्रयोगकर्ताहरू सर्भरहरूमा पहुँच भएका हुन्छन्।
5. फाइल प्रणाली स्तरमा फाइलहरूमा पहुँच प्रतिबन्ध। तपाईंले निर्देशिकाहरूलाई अधिकार र पहुँच विशेषाधिकारहरू प्रदान गर्न सक्नुहुन्छ ताकि प्रत्येक प्रशासकसँग आवश्यक डाटामा मात्र पहुँच हुन्छ।
6. अनिवार्य पहुँच र मेमोरी क्लियरिङ - यी प्रविधिहरू विरलै प्रयोग गरिन्छ।
7. DBMS बाट सिधै एन्ड-टु-इन्ड इन्क्रिप्सन सर्भर साइडमा कुञ्जी व्यवस्थापनको साथ क्लाइन्ट-साइड इन्क्रिप्सन हो।
8. डाटा एन्क्रिप्शन। उदाहरणका लागि, स्तम्भ इन्क्रिप्सन भनेको जब तपाइँ डाटाबेसको एकल स्तम्भलाई इन्क्रिप्ट गर्ने मेकानिजम प्रयोग गर्नुहुन्छ।

यसले DBMS को प्रदर्शनलाई कसरी असर गर्छ?

PostgreSQL मा स्तम्भ इन्क्रिप्शन को उदाहरण हेरौं। त्यहाँ एक pgcrypto मोड्युल छ, यसले तपाईंलाई गुप्तिकरण फारममा चयन गरिएका क्षेत्रहरू भण्डारण गर्न अनुमति दिन्छ। यो उपयोगी हुन्छ जब केवल केहि डेटा मूल्यवान हुन्छ। इन्क्रिप्टेड फिल्डहरू पढ्नको लागि, क्लाइन्टले डिक्रिप्शन कुञ्जी पठाउँछ, सर्भरले डाटा डिक्रिप्ट गर्छ र क्लाइन्टमा फिर्ता गर्छ। कुञ्जी बिना, कसैले तपाइँको डेटा संग केहि गर्न सक्दैन।

pgcrypto को साथ परीक्षण गरौं। एन्क्रिप्टेड डाटा र नियमित डाटाको साथ तालिका बनाउनुहोस्। तल तालिकाहरू सिर्जना गर्नका लागि आदेशहरू छन्, पहिलो पङ्क्तिमा त्यहाँ एक उपयोगी आदेश छ - DBMS दर्ताको साथ एक्स्टेन्सन सिर्जना गर्नुहोस्:

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

स्टपवाच सक्रिय छ।

  आईडी | text1 | text2
——+——-+——-
१ | १ | १
१ | १ | १
१ | १ | १
...
९९७ | ९९७ | ९९७
९९७ | ९९७ | ९९७
९९७ | ९९७ | ९९७
१००० | १००० | १०००
(1000 लाइनहरू)

समय: 1,386 ms

ईन्क्रिप्शन प्रकार्यको साथ तालिकाबाट चयन:

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

स्टपवाच सक्रिय छ।

  आईडी | डिक्रिप्ट | डिक्रिप्ट
——+—————+———
१ | x1 | x31
१ | x2 | x32
३ | x3 | x33
...
१ | x999 | x393939
३ | x1000 | x31303030
(1000 लाइनहरू)

समय: 50,203 ms

परीक्षण नतीजा:

 
एन्क्रिप्शन बिना
Pgcrypto (डिक्रिप्ट)

नमूना 1000 पङ्क्तिहरू
1,386 एमएस
50,203 एमएस

CPU
15%
35%

र्याम
 
+ 5%

इन्क्रिप्शनले प्रदर्शनमा ठूलो प्रभाव पार्छ। यो देख्न सकिन्छ कि समय बढेको छ, किनकि एन्क्रिप्टेड डाटाको डिक्रिप्शन अपरेसनहरू (र डिक्रिप्शन सामान्यतया अझै पनि तपाईंको तर्कमा बेरिएको छ) महत्त्वपूर्ण स्रोतहरू चाहिन्छ। त्यो हो, केहि डेटा समावेश सबै स्तम्भहरू इन्क्रिप्ट गर्ने विचार प्रदर्शनमा कमीले भरिएको छ।

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

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

MongoDB मा यस्तो ईन्क्रिप्शन को एक उदाहरण

व्यावसायिक र खुला स्रोत DBMS मा सुरक्षा सुविधाहरू

कार्यहरू
टाइप गर्नुहोस्
पासवर्ड नीति
अडिट
प्रक्रिया र कार्यहरूको स्रोत कोडको सुरक्षा गर्दै
RLS
गुप्तिकरण

बजेट
व्यावसायिक
+
+
+
+
+

MsSql
व्यावसायिक
+
+
+
+
+

जाटोबा
व्यावसायिक
+
+
+
+
विस्तार

PostgreSQL
नि:शुल्क
विस्तार
विस्तार
-
+
विस्तार

मंगोडीबी
नि:शुल्क
-
+
-
-
MongoDB Enterprise मा मात्र उपलब्ध छ

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

के गर्ने यदि तपाईलाई चाहिने कुरा कतै छैन भने? उदाहरण को लागी, तपाइँ एक विशिष्ट DBMS प्रयोग गर्न चाहानुहुन्छ जसमा ग्राहकलाई आवश्यक पर्ने कार्यहरू छैनन्।

त्यसपछि तपाइँ तेस्रो-पक्ष समाधानहरू प्रयोग गर्न सक्नुहुन्छ जुन विभिन्न DBMS सँग काम गर्दछ, उदाहरणका लागि, Crypto DB वा Garda DB। यदि हामी घरेलु खण्डबाट समाधानहरूको बारेमा कुरा गर्दैछौं भने, उनीहरूलाई खुला स्रोतमा भन्दा GOSTs बारे राम्रोसँग थाहा छ।

दोस्रो विकल्प भनेको तपाई आफैलाई चाहिने कुरा लेख्नु हो, प्रक्रिया स्तरमा अनुप्रयोगमा डाटा पहुँच र इन्क्रिप्सन लागू गर्नुहोस्। साँचो, यो GOST संग अधिक कठिन हुनेछ। तर सामान्यमा, तपाईले आवश्यकता अनुसार डाटा लुकाउन सक्नुहुन्छ, यसलाई DBMS मा राख्नुहोस्, त्यसपछि यसलाई पुन: प्राप्त गर्नुहोस् र आवश्यकता अनुसार डिक्रिप्ट गर्नुहोस्, दायाँ अनुप्रयोग स्तरमा। एकै समयमा, तुरुन्तै सोच्नुहोस् कि तपाइँ कसरी अनुप्रयोगमा यी एल्गोरिदमहरू सुरक्षित गर्नुहुन्छ। हाम्रो विचारमा, यो DBMS स्तरमा गरिनु पर्छ, किनभने यसले छिटो काम गर्नेछ।

यो रिपोर्ट पहिलो पटक प्रस्तुत गरिएको थियो @Databases Meetup Mail.ru क्लाउड समाधान द्वारा। हेर видео अन्य प्रदर्शनहरू र टेलिग्राममा घटना घोषणाहरूको सदस्यता लिनुहोस् Mail.ru Group मा Kubernetes को वरिपरि.

बिषयमा अरु के पढ्नु होला:

1. Ceph भन्दा बढि: MCS क्लाउड ब्लक भण्डारण.
2. कसरी एक परियोजना को लागी एक डाटाबेस छनोट गर्न को लागी तपाईले फेरि छनौट गर्नु पर्दैन.

स्रोत: www.habr.com