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


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

यह लेख @Dat डेटाबेस मीटअप द्वारा लिखा गया था , जिसे Mail.ru Cloud Solutions ने होस्ट किया था यदि आप पढ़ना नहीं चाहते हैं, तो आप देख सकते हैं:


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

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


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

कनेक्शन संरक्षण


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

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

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

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

  1. डेटाबेस फ़ायरवॉल वर्ग समाधान का उपयोग करें। सुरक्षा की एक अतिरिक्त परत, कम से कम, डीबीएमएस में हो रही पारदर्शिता को बढ़ाएगी, अधिकतम के रूप में - आप अधिक डेटा सुरक्षा प्रदान कर सकते हैं।
  2. . , . — -, , . , , .

    , MS SQL Vulnerability Assessmen
  3. . , , , , , . .
  4. SSL कॉन्फ़िगर करें, यदि आपके पास अंत उपयोगकर्ताओं से DBMS का नेटवर्क पृथक्करण नहीं है, तो यह अलग VLAN में नहीं है। ऐसे मामलों में, उपभोक्ता और खुद डीबीएमएस के बीच चैनल की सुरक्षा करना आवश्यक है। संरक्षण उपकरण खुले स्रोत के बीच हैं।

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


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

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

SSL के बिना टेस्ट 1 और 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"

बनाम

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

SSL के बिना टेस्ट 2 और 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"

बनाम

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 मि
कनेक्शन स्थापित करने सहित tps58.16811253.278062
कनेक्शन स्थापित करने को छोड़कर tps64.08454658.725846
सी पी यू24%28%
सभी लेन-देन एक कनेक्शन में किए जाते हैं।
विलंबता औसत6.722 मि6.342 एमएस
कनेक्शन स्थापित करने सहित tps1587.6572781576.792883
कनेक्शन स्थापित करने को छोड़कर tps1588.3805741577.694766
सी पी यू17%21%

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

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

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

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

क्रियाओं का लेखा-जोखा


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

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

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

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

“ऑपरेटरों का मूल पंजीकरण, log_statement = सभी के साथ मानक लॉगिंग सुविधा प्रदान किया जा सकता है।

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

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

ऑडिटर के लिए विशिष्ट कथनों को खोजने के लिए भी संभव होना चाहिए।

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

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

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

DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

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

लॉग: स्टेटमेंट: DO $$
BEGIN
EXECUTE 'CREATE TABLE import' || 'ant_table (id INT)';
END $$;

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

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

यह वह जगह है जहाँ pgAudit उपयोगी होगा।

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

AUDIT: सत्र, 33.1, समारोह, डीओ,, "" $ $
BEGIN
EXECUTE 'क्रिएट टेबल आयात' || 'ant_table (id INT)';
END $$; "
AUDIT: सत्र, 33,2, DDL, CREATE TABLE, TABLE, public.important_table, CREATE TABLE important_table (id INT)

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

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

किसी विशिष्ट तालिका ( * ) से संबंधित सभी कथन खोजने के लिए पार्स करने की आवश्यकता नहीं है " ।

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


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

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

postgresql.conf
log_destination = 'stderr'
logging_collector = पर
log_truncate_on_rotation = पर
log_rotation_age = 1 दिन
log_rotation_size = 10 एमबी
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse =
debug_print_rewritten = पर
debug_print_plan = पर
debug_pretty_print = पर
log_checkpoints = पर
log_connections = पर
log_disconnections = पर
log_duration = पर
log_hostname = पर
log_lock_waits = पर
log_replication_commands = पर
log_temp_files = 0
log_timezone =

PostgreSQL DBMS पर 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 मिनट में लेनदेन की संख्या74,16932,445
लेन-देन / सेक12354
औसत देरी405 मि925 मि
टेस्ट 2 (100 संभव पर 150 कनेक्शन)
10 मिनट में लेनदेन की संख्या81,72731,429
लेन-देन / सेक13652
औसत देरी550 मि1432 एमएस
आकारों के बारे में
DB आकार2251 एमबी2262 एमबी
डेटाबेस लॉग आकार0 एमबी4587 एमबी

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

हम अन्य मापदंडों को देखते हैं:

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

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

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

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

डेटा एक्सेस प्रतिबंध


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

एक पूरे के रूप में क्या इस्तेमाल किया जा सकता है:

  1. एन्क्रिप्शन और प्रक्रियाओं और कार्यों (रैपिंग) के obfuscation - यानी, अलग उपकरण और उपयोगिताओं जो पठनीय कोड से कोड को अपठनीय बनाते हैं। सच है, तो इसे न तो बदला जा सकता है और न ही वापस रिफैक्ट किया जा सकता है। इस तरह के दृष्टिकोण को कभी-कभी कम से कम डीबीएमएस पक्ष की आवश्यकता होती है - लाइसेंसिंग प्रतिबंध या प्राधिकरण तर्क का तर्क प्रक्रिया और फ़ंक्शन के स्तर पर ठीक से एन्क्रिप्ट किया गया है।
  2. (RLS) — , , - - .
  3. (Masking) — , , - . , .
  4. Security DBA/Application DBA/DBA — , , , database- application-. open source , . , .
  5. . , , .
  6. — .
  7. End-to-end encryption — client-side .
  8. . , — , .

?


आइए 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

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

  आईडी | पाठ 1 | text2
------ + ------- + -------
1 | 1 | 1
2 | 2 | 2
3 | 3 |
...
९९ | | 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

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

  आईडी | डिक्रिप्ट | डिक्रिप्ट
----- + -------------- + ------------
१ | \ x31 | \ x31
2 | \ x32 | \ x32
3 | \ x33 | \ x33
...
999 | \ x393939 | \ x393939
1000 | \ x31303030 | \ x31303030
(1000 लाइनें)

समय: 50.203 एमएस

परीक्षण के परिणाम :
 कोई एन्क्रिप्शन नहींPgcrypto (डिक्रिप्ट)
1000 पंक्ति में लाने1,386 एमएस50,203 एमएस
सी पी यूपंद्रह%35%
राम + 5%

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

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

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


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

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


कार्यएक प्रकारपासवर्ड नीतिलेखा परीक्षाप्रक्रियाओं और कार्यों के लिए स्रोत कोड की रक्षा करनाआरएलएसएन्क्रिप्शन
आकाशवाणीव्यावसायिक+++++
msqlव्यावसायिक+++++
Jatobaव्यावसायिक++++एक्सटेंशन
PostgreSQLनि: शुल्कएक्सटेंशनएक्सटेंशन-+एक्सटेंशन
MongoDBनि: शुल्क-+--केवल MongoDB एंटरप्राइज में उपलब्ध है

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

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

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

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

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

विषय पर और क्या पढ़ें :

  1. सेफ़ से अधिक: एमसीएस ब्लॉक क्लाउड स्टोरेज
  2. प्रोजेक्ट के लिए डेटाबेस का चयन कैसे करें, ताकि फिर से चयन न हो

All Articles