నా పేరు డెనిస్ రోజ్కోవ్, నేను ఉత్పత్తి బృందంలో Gazinformservice కంపెనీలో సాఫ్ట్‌వేర్ డెవలప్‌మెంట్ హెడ్‌ని జటోబా. చట్టం మరియు కార్పొరేట్ నిబంధనలు డేటా నిల్వ భద్రత కోసం కొన్ని అవసరాలను విధిస్తాయి. మూడవ పక్షాలు రహస్య సమాచారానికి ప్రాప్యతను పొందాలని ఎవరూ కోరుకోరు, కాబట్టి ఏదైనా ప్రాజెక్ట్ కోసం క్రింది సమస్యలు ముఖ్యమైనవి: గుర్తింపు మరియు ప్రామాణీకరణ, డేటాకు ప్రాప్యతను నిర్వహించడం, సిస్టమ్‌లోని సమాచారం యొక్క సమగ్రతను నిర్ధారించడం, భద్రతా ఈవెంట్‌లను లాగింగ్ చేయడం. అందువల్ల, నేను DBMS భద్రతకు సంబంధించి కొన్ని ఆసక్తికరమైన అంశాల గురించి మాట్లాడాలనుకుంటున్నాను.

వద్ద ప్రసంగం ఆధారంగా వ్యాసం తయారు చేయబడింది @డేటాబేస్ మీటప్, నిర్వహించారు Mail.ru క్లౌడ్ సొల్యూషన్స్. మీరు చదవకూడదనుకుంటే, మీరు చూడవచ్చు:

వ్యాసం మూడు భాగాలను కలిగి ఉంటుంది:

• కనెక్షన్లను ఎలా భద్రపరచాలి.
• చర్యల ఆడిట్ అంటే ఏమిటి మరియు డేటాబేస్ వైపు ఏమి జరుగుతుందో మరియు దానికి కనెక్ట్ చేయడం ఎలా రికార్డ్ చేయాలి.
• డేటాబేస్‌లోని డేటాను ఎలా రక్షించాలి మరియు దీని కోసం ఏ సాంకేతికతలు అందుబాటులో ఉన్నాయి.

DBMS భద్రత యొక్క మూడు భాగాలు: కనెక్షన్ రక్షణ, కార్యాచరణ ఆడిటింగ్ మరియు డేటా రక్షణ

మీ కనెక్షన్‌లను సురక్షితం చేస్తోంది

మీరు వెబ్ అప్లికేషన్ల ద్వారా ప్రత్యక్షంగా లేదా పరోక్షంగా డేటాబేస్‌కు కనెక్ట్ చేయవచ్చు. నియమం ప్రకారం, వ్యాపార వినియోగదారు, అంటే, DBMSతో పనిచేసే వ్యక్తి, దానితో పరోక్షంగా సంకర్షణ చెందుతారు.

కనెక్షన్‌లను రక్షించడం గురించి మాట్లాడే ముందు, భద్రతా చర్యలు ఎలా నిర్మించబడతాయో నిర్ణయించే ముఖ్యమైన ప్రశ్నలకు మీరు సమాధానం ఇవ్వాలి:

• ఒక వ్యాపార వినియోగదారు ఒక DBMS వినియోగదారుతో సమానమా?
• మీరు నియంత్రించే API ద్వారా మాత్రమే DBMS డేటాకు యాక్సెస్ అందించబడుతుందా లేదా పట్టికలు నేరుగా యాక్సెస్ చేయబడతాయా;
• DBMS ప్రత్యేక రక్షిత విభాగానికి కేటాయించబడిందా, దానితో ఎవరు మరియు ఎలా పరస్పర చర్య చేస్తారు;
• పూలింగ్/ప్రాక్సీ మరియు ఇంటర్మీడియట్ లేయర్‌లు ఉపయోగించబడతాయా, ఇది కనెక్షన్ ఎలా నిర్మించబడింది మరియు డేటాబేస్‌ను ఎవరు ఉపయోగిస్తున్నారు అనే దాని గురించి సమాచారాన్ని మార్చవచ్చు.

ఇప్పుడు కనెక్షన్‌లను సురక్షితం చేయడానికి ఏ సాధనాలను ఉపయోగించవచ్చో చూద్దాం:

1. డేటాబేస్ ఫైర్‌వాల్ క్లాస్ సొల్యూషన్‌లను ఉపయోగించండి. రక్షణ యొక్క అదనపు పొర, కనిష్టంగా, DBMSలో ఏమి జరుగుతుందో పారదర్శకతను పెంచుతుంది మరియు గరిష్టంగా, మీరు అదనపు డేటా రక్షణను అందించగలరు.
2. పాస్‌వర్డ్ విధానాలను ఉపయోగించండి. మీ ఆర్కిటెక్చర్ ఎలా నిర్మించబడిందనే దానిపై వాటి ఉపయోగం ఆధారపడి ఉంటుంది. ఏదైనా సందర్భంలో, DBMSకి కనెక్ట్ చేసే వెబ్ అప్లికేషన్ యొక్క కాన్ఫిగరేషన్ ఫైల్‌లో ఒక పాస్‌వర్డ్ రక్షణ కోసం సరిపోదు. వినియోగదారు మరియు పాస్‌వర్డ్‌ను నవీకరించడం అవసరమని నియంత్రించడానికి మిమ్మల్ని అనుమతించే అనేక DBMS సాధనాలు ఉన్నాయి.

   మీరు వినియోగదారు రేటింగ్ ఫంక్షన్ల గురించి మరింత చదువుకోవచ్చు ఇక్కడ, మీరు MS SQL వల్నరబిలిటీ అసెస్‌మెన్ గురించి కూడా తెలుసుకోవచ్చు ఇక్కడ. 

3. అవసరమైన సమాచారంతో సెషన్ సందర్భాన్ని మెరుగుపరచండి. సెషన్ అపారదర్శకంగా ఉంటే, దాని ఫ్రేమ్‌వర్క్‌లో DBMSలో ఎవరు పనిచేస్తున్నారో మీకు అర్థం కాకపోతే, మీరు నిర్వహిస్తున్న ఆపరేషన్ ఫ్రేమ్‌వర్క్‌లో ఎవరు ఏమి చేస్తున్నారు మరియు ఎందుకు చేస్తున్నారు అనే దాని గురించి సమాచారాన్ని జోడించవచ్చు. ఈ సమాచారం ఆడిట్‌లో చూడవచ్చు.
4. మీకు DBMS మరియు తుది వినియోగదారుల మధ్య నెట్‌వర్క్ విభజన లేకపోతే SSLని కాన్ఫిగర్ చేయండి; ఇది ప్రత్యేక VLANలో లేదు. అటువంటి సందర్భాలలో, వినియోగదారు మరియు DBMS మధ్య ఛానెల్‌ను రక్షించడం అత్యవసరం. భద్రతా సాధనాలు కూడా ఓపెన్ సోర్స్‌లో అందుబాటులో ఉన్నాయి.

ఇది DBMS పనితీరును ఎలా ప్రభావితం చేస్తుంది?

SSL CPU లోడ్‌ను ఎలా ప్రభావితం చేస్తుందో, సమయాలను పెంచుతుంది మరియు TPSని ఎలా తగ్గిస్తుంది మరియు మీరు దీన్ని ఎనేబుల్ చేస్తే అది చాలా ఎక్కువ వనరులను వినియోగిస్తుందో లేదో తెలుసుకోవడానికి PostgreSQL యొక్క ఉదాహరణను చూద్దాం.

Pgbench ఉపయోగించి PostgreSQL లోడ్ చేయడం అనేది పనితీరు పరీక్షలను అమలు చేయడానికి ఒక సాధారణ ప్రోగ్రామ్. ఇది ఒకే వరుస కమాండ్‌లను పదేపదే అమలు చేస్తుంది, బహుశా సమాంతర డేటాబేస్ సెషన్‌లలో, ఆపై సగటు లావాదేవీ రేటును గణిస్తుంది.

SSL లేకుండా మరియు SSLని ఉపయోగించి 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"

vs

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

SSL లేకుండా మరియు SSLని ఉపయోగించి 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"

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 ms
187.695 ms

కనెక్షన్లను ఏర్పాటు చేయడంతో సహా tps
58.168112
53.278062

tps కనెక్షన్‌లను ఏర్పాటు చేయడం మినహా
64.084546
58.725846

CPU
24%
28%

అన్ని లావాదేవీలు ఒకే కనెక్షన్‌లో నిర్వహించబడతాయి

జాప్యం సగటు
6.722 ms
6.342 ms

కనెక్షన్లను ఏర్పాటు చేయడంతో సహా tps
1587.657278
1576.792883

tps కనెక్షన్‌లను ఏర్పాటు చేయడం మినహా
1588.380574
1577.694766

CPU
17%
21%

తేలికపాటి లోడ్ల వద్ద, SSL ప్రభావం కొలత లోపంతో పోల్చవచ్చు. బదిలీ చేయబడిన డేటా మొత్తం చాలా పెద్దది అయితే, పరిస్థితి భిన్నంగా ఉండవచ్చు. మేము ఒక లావాదేవీకి ఒక కనెక్షన్‌ని ఏర్పాటు చేస్తే (ఇది చాలా అరుదు, సాధారణంగా కనెక్షన్ వినియోగదారుల మధ్య భాగస్వామ్యం చేయబడుతుంది), మీకు పెద్ద సంఖ్యలో కనెక్షన్‌లు/డిస్‌కనెక్షన్‌లు ఉన్నాయి, ప్రభావం కొంచెం ఎక్కువగా ఉండవచ్చు. అంటే, తగ్గిన పనితీరు ప్రమాదాలు ఉండవచ్చు, అయినప్పటికీ, రక్షణను ఉపయోగించని విధంగా వ్యత్యాసం చాలా పెద్దది కాదు.

మీరు ఆపరేటింగ్ మోడ్‌లను సరిపోల్చినట్లయితే బలమైన వ్యత్యాసం ఉందని దయచేసి గమనించండి: మీరు ఒకే సెషన్‌లో లేదా వేర్వేరు వాటిలో పని చేస్తున్నారు. ఇది అర్థమయ్యేలా ఉంది: ప్రతి కనెక్షన్‌ని రూపొందించడానికి వనరులు ఖర్చు చేయబడతాయి.

మేము Zabbixని ట్రస్ట్ మోడ్‌లో కనెక్ట్ చేసినప్పుడు మాకు ఒక కేసు ఉంది, అంటే, md5 తనిఖీ చేయబడలేదు, ప్రామాణీకరణ అవసరం లేదు. అప్పుడు కస్టమర్ md5 ప్రమాణీకరణ మోడ్‌ని ప్రారంభించమని అడిగారు. ఇది CPUపై భారీ లోడ్‌ను కలిగిస్తుంది మరియు పనితీరు పడిపోయింది. మేము ఆప్టిమైజ్ చేయడానికి మార్గాలను వెతకడం ప్రారంభించాము. సమస్యకు సాధ్యమయ్యే పరిష్కారాలలో ఒకటి నెట్‌వర్క్ పరిమితులను అమలు చేయడం, DBMS కోసం ప్రత్యేక VLANలను రూపొందించడం, ఎవరు ఎక్కడ నుండి కనెక్ట్ అవుతున్నారో స్పష్టం చేయడానికి సెట్టింగ్‌లను జోడించడం మరియు ప్రామాణీకరణను తీసివేయడం. ప్రామాణీకరణను ప్రారంభించేటప్పుడు ఖర్చులను తగ్గించడానికి మీరు ప్రమాణీకరణ సెట్టింగ్‌లను ఆప్టిమైజ్ చేయవచ్చు, కానీ సాధారణంగా వివిధ పద్ధతుల ప్రమాణీకరణను ఉపయోగించడం పనితీరును ప్రభావితం చేస్తుంది మరియు DBMS కోసం సర్వర్‌ల (హార్డ్‌వేర్) యొక్క కంప్యూటింగ్ శక్తిని రూపకల్పన చేసేటప్పుడు ఈ అంశాలను పరిగణనలోకి తీసుకోవడం అవసరం.

తీర్మానం: అనేక పరిష్కారాలలో, ప్రామాణీకరణలో చిన్న సూక్ష్మ నైపుణ్యాలు కూడా ప్రాజెక్ట్‌ను బాగా ప్రభావితం చేస్తాయి మరియు ఉత్పత్తిలో అమలు చేయబడినప్పుడు మాత్రమే ఇది స్పష్టంగా కనిపించినప్పుడు ఇది చెడ్డది.

యాక్షన్ ఆడిట్

ఆడిట్ అనేది DBMS మాత్రమే కాదు. ఆడిట్ అనేది వివిధ విభాగాలలో ఏమి జరుగుతుందో దాని గురించి సమాచారాన్ని పొందడం. ఇది డేటాబేస్ ఫైర్‌వాల్ లేదా DBMS నిర్మించబడిన ఆపరేటింగ్ సిస్టమ్ కావచ్చు.

వాణిజ్య ఎంటర్‌ప్రైజ్ స్థాయి DBMSలలో ఆడిటింగ్‌తో ప్రతిదీ బాగానే ఉంటుంది, కానీ ఓపెన్ సోర్స్‌లో - ఎల్లప్పుడూ కాదు. PostgreSQL కలిగి ఉన్నవి ఇక్కడ ఉన్నాయి:

• డిఫాల్ట్ లాగ్ - అంతర్నిర్మిత లాగింగ్;
• పొడిగింపులు: pgaudit - డిఫాల్ట్ లాగింగ్ మీకు సరిపోకపోతే, మీరు కొన్ని సమస్యలను పరిష్కరించే ప్రత్యేక సెట్టింగ్‌లను ఉపయోగించవచ్చు.

వీడియోలోని నివేదికకు అదనంగా:

"ప్రాథమిక స్టేట్‌మెంట్ లాగింగ్‌ను log_statement = అన్నీ ఉన్న ప్రామాణిక లాగింగ్ సౌకర్యం ద్వారా అందించవచ్చు.

ఇది పర్యవేక్షణ మరియు ఇతర ఉపయోగాలకు ఆమోదయోగ్యమైనది, కానీ సాధారణంగా ఆడిటింగ్ కోసం అవసరమైన వివరాల స్థాయిని అందించదు.

డేటాబేస్‌లో నిర్వహించబడే అన్ని కార్యకలాపాల జాబితాను కలిగి ఉండటం సరిపోదు.

ఆడిటర్‌కు ఆసక్తి కలిగించే నిర్దిష్ట స్టేట్‌మెంట్‌లను కనుగొనడం కూడా సాధ్యమవుతుంది.

ప్రామాణిక లాగింగ్ వినియోగదారు అభ్యర్థించడాన్ని చూపుతుంది, అయితే pgAudit డేటాబేస్ ప్రశ్నను అమలు చేసినప్పుడు ఏమి జరిగిందనే వివరాలపై దృష్టి పెడుతుంది.

ఉదాహరణకు, డాక్యుమెంట్ చేయబడిన నిర్వహణ విండోలో నిర్దిష్ట పట్టిక సృష్టించబడిందని ఆడిటర్ ధృవీకరించాలనుకోవచ్చు.

ప్రాథమిక ఆడిటింగ్ మరియు grepతో ఇది ఒక సాధారణ పనిలాగా అనిపించవచ్చు, కానీ మీకు ఇలాంటి (ఉద్దేశపూర్వకంగా గందరగోళంగా) ఉదాహరణను అందించినట్లయితే:

చేయండి
ప్రారంభం
'క్రియేట్ టేబుల్ దిగుమతి' || 'ant_table(id int)';
END$$;

ప్రామాణిక లాగింగ్ మీకు దీన్ని అందిస్తుంది:

లాగ్: ప్రకటన: $$ చేయండి
ప్రారంభం
'క్రియేట్ టేబుల్ దిగుమతి' || 'ant_table(id int)';
END$$;

పట్టికలు డైనమిక్‌గా సృష్టించబడిన సందర్భాల్లో ఆసక్తి గల పట్టికను కనుగొనడానికి కొంత కోడ్ పరిజ్ఞానం అవసరం కావచ్చు.

ఇది అనువైనది కాదు, ఎందుకంటే పట్టిక పేరు ద్వారా శోధించడం ఉత్తమం.

ఇక్కడే pgAudit ఉపయోగపడుతుంది.

అదే ఇన్‌పుట్ కోసం, ఇది లాగ్‌లో ఈ అవుట్‌పుట్‌ను ఉత్పత్తి చేస్తుంది:

ఆడిట్: సెషన్,33,1,ఫంక్షన్,DO,,,"DO $$
ప్రారంభం
'క్రియేట్ టేబుల్ దిగుమతి' || 'ant_table(id int)';
END$$;"
ఆడిట్: సెషన్, 33,2, DDL, టేబుల్‌ని సృష్టించండి, టేబుల్, పబ్లిక్. ఇంపార్టెంట్_టేబుల్, క్రియేట్ టేబుల్ ముఖ్యమైన_టేబుల్ (ఐడి INT)

DO బ్లాక్ మాత్రమే లాగిన్ అవ్వడమే కాకుండా, స్టేట్‌మెంట్ రకం, ఆబ్జెక్ట్ రకం మరియు పూర్తి పేరుతో క్రియేట్ టేబుల్ యొక్క పూర్తి టెక్స్ట్ కూడా శోధించడం సులభం చేస్తుంది.

SELECT మరియు DML స్టేట్‌మెంట్‌లను లాగింగ్ చేస్తున్నప్పుడు, స్టేట్‌మెంట్‌లో ప్రస్తావించబడిన ప్రతి సంబంధానికి ప్రత్యేక ఎంట్రీని లాగిన్ చేయడానికి pgAudit కాన్ఫిగర్ చేయబడుతుంది.

నిర్దిష్ట పట్టికను తాకే అన్ని స్టేట్‌మెంట్‌లను కనుగొనడానికి పార్సింగ్ అవసరం లేదు(*) ".

ఇది DBMS పనితీరును ఎలా ప్రభావితం చేస్తుంది?

పూర్తి ఆడిటింగ్ ప్రారంభించబడి పరీక్షలను అమలు చేద్దాం మరియు PostgreSQL పనితీరుకు ఏమి జరుగుతుందో చూద్దాం. అన్ని పారామితుల కోసం గరిష్ట డేటాబేస్ లాగింగ్‌ను ప్రారంభిద్దాం.

మేము కాన్ఫిగరేషన్ ఫైల్‌లో దాదాపు ఏమీ మార్చలేము, గరిష్ట సమాచారాన్ని పొందడానికి డీబగ్5 మోడ్‌ను ఆన్ చేయడం చాలా ముఖ్యమైన విషయం.

postgresql.conf

log_destination = 'stderr'
logging_collector = ఆన్
log_truncate_on_rotation = ఆన్
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = డీబగ్5
log_min_error_statement = డీబగ్5
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_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 సె

RAM
24%
40%

CPU
72%
91%

పరీక్ష 1 (50 కనెక్షన్లు)

10 నిమిషాల్లో లావాదేవీల సంఖ్య
74169
32445

లావాదేవీలు/సెక
123
54

సగటు జాప్యం
405 ms
925 ms

పరీక్ష 2 (150 కనెక్షన్‌లతో 100 సాధ్యం)

10 నిమిషాల్లో లావాదేవీల సంఖ్య
81727
31429

లావాదేవీలు/సెక
136
52

సగటు జాప్యం
550 ms
1432 ms

పరిమాణాల గురించి

DB పరిమాణం
2251 MB
2262 MB

డేటాబేస్ లాగ్ పరిమాణం
X MB MB
X MB MB

బాటమ్ లైన్: పూర్తి ఆడిట్ చాలా మంచిది కాదు. ఆడిట్ నుండి డేటా డేటాబేస్‌లోని డేటా అంత పెద్దదిగా ఉంటుంది లేదా అంతకంటే ఎక్కువ ఉంటుంది. DBMSతో పని చేస్తున్నప్పుడు ఉత్పత్తి చేయబడిన లాగింగ్ మొత్తం ఉత్పత్తిలో ఒక సాధారణ సమస్య.

ఇతర పారామితులను చూద్దాం:

• వేగం పెద్దగా మారదు: లాగింగ్ లేకుండా - 43,74 సెకన్లు, లాగింగ్‌తో - 53,23 సెకన్లు.
• మీరు ఆడిట్ ఫైల్‌ను రూపొందించాల్సిన అవసరం ఉన్నందున RAM మరియు CPU పనితీరు దెబ్బతింటుంది. ఇది ఉత్పాదకతలో కూడా గుర్తించదగినది.

కనెక్షన్ల సంఖ్య పెరిగేకొద్దీ, సహజంగానే, పనితీరు కొద్దిగా క్షీణిస్తుంది.

ఆడిట్ ఉన్న కార్పొరేషన్లలో ఇది మరింత కష్టం:

• చాలా డేటా ఉంది;
• SIEMలోని syslog ద్వారా మాత్రమే కాకుండా ఫైల్‌లలో కూడా ఆడిటింగ్ అవసరం: syslogకి ఏదైనా జరిగితే, డేటా సేవ్ చేయబడిన డేటాబేస్‌కు దగ్గరగా ఒక ఫైల్ ఉండాలి;
• I/O డిస్క్‌లను వృథా చేయకుండా ఆడిటింగ్ కోసం ప్రత్యేక షెల్ఫ్ అవసరం, ఎందుకంటే ఇది చాలా స్థలాన్ని తీసుకుంటుంది;
• సమాచార భద్రతా ఉద్యోగులకు ప్రతిచోటా GOST ప్రమాణాలు అవసరం, వారికి రాష్ట్ర గుర్తింపు అవసరం.

డేటాకు ప్రాప్యతను పరిమితం చేయడం

డేటాను రక్షించడానికి మరియు వాణిజ్య DBMSలు మరియు ఓపెన్ సోర్స్‌లో యాక్సెస్ చేయడానికి ఉపయోగించే సాంకేతికతలను చూద్దాం.

మీరు సాధారణంగా ఏమి ఉపయోగించవచ్చు:

1. విధానాలు మరియు విధులను గుప్తీకరించడం మరియు అస్పష్టం చేయడం (వ్రాపింగ్) - అంటే, చదవగలిగే కోడ్‌ను చదవలేని విధంగా చేసే ప్రత్యేక సాధనాలు మరియు వినియోగాలు. నిజమే, అది మార్చబడదు లేదా తిరిగి మార్చబడదు. ఈ విధానం కొన్నిసార్లు కనీసం DBMS వైపు అవసరమవుతుంది - లైసెన్స్ పరిమితుల తర్కం లేదా అధికార తర్కం ప్రక్రియ మరియు ఫంక్షన్ స్థాయిలో ఖచ్చితంగా గుప్తీకరించబడుతుంది.
2. అడ్డు వరుసల ద్వారా డేటా యొక్క దృశ్యమానతను పరిమితం చేయడం (RLS) అనేది వేర్వేరు వినియోగదారులు ఒక టేబుల్‌ని చూసినప్పుడు, కానీ దానిలో వరుసల విభిన్న కూర్పు, అంటే అడ్డు వరుసల స్థాయిలో ఎవరికైనా చూపబడదు.
3. ప్రదర్శించబడిన డేటాను సవరించడం (మాస్కింగ్) అనేది పట్టికలోని ఒక నిలువు వరుసలో ఉన్న వినియోగదారులు డేటాను లేదా ఆస్టరిస్క్‌లను మాత్రమే చూసినప్పుడు, అంటే కొంతమంది వినియోగదారులకు సమాచారం మూసివేయబడుతుంది. ఏ వినియోగదారుకు వారి యాక్సెస్ స్థాయి ఆధారంగా ఏమి చూపబడుతుందో సాంకేతికత నిర్ణయిస్తుంది.
4. సెక్యూరిటీ DBA/అప్లికేషన్ 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

స్టాప్‌వాచ్ ఆన్‌లో ఉంది.

  id | వచనం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 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

స్టాప్‌వాచ్ ఆన్‌లో ఉంది.

  id | డీక్రిప్ట్ | డీక్రిప్ట్
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 పంక్తులు)

సమయం: 50,203 ms

పరీక్ష ఫలితాలు:

 
ఎన్క్రిప్షన్ లేకుండా
Pgcrypto (డీక్రిప్ట్)

నమూనా 1000 వరుసలు
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

ఎన్‌క్రిప్షన్ పనితీరుపై పెద్ద ప్రభావాన్ని చూపుతుంది. గుప్తీకరించిన డేటా (మరియు డిక్రిప్షన్ సాధారణంగా ఇప్పటికీ మీ లాజిక్‌లో చుట్టబడి ఉంటుంది) యొక్క డిక్రిప్షన్ కార్యకలాపాలకు ముఖ్యమైన వనరులు అవసరం కాబట్టి, సమయం పెరిగినట్లు చూడవచ్చు. అంటే, కొంత డేటాను కలిగి ఉన్న అన్ని నిలువు వరుసలను ఎన్‌క్రిప్ట్ చేయాలనే ఆలోచన పనితీరులో తగ్గుదలతో నిండి ఉంది.

అయితే, ఎన్‌క్రిప్షన్ అనేది అన్ని సమస్యలను పరిష్కరించే వెండి బుల్లెట్ కాదు. డీక్రిప్ట్ చేయబడిన డేటా మరియు డేటాను డీక్రిప్ట్ చేసే మరియు ప్రసారం చేసే ప్రక్రియలో డీక్రిప్షన్ కీ సర్వర్‌లో ఉన్నాయి. అందువల్ల, సిస్టమ్ అడ్మినిస్ట్రేటర్ వంటి డేటాబేస్ సర్వర్‌కు పూర్తి ప్రాప్యత ఉన్న ఎవరైనా కీలను అడ్డగించవచ్చు.

వినియోగదారులందరికీ మొత్తం కాలమ్‌కి ఒక కీ ఉన్నప్పుడు (అందరికీ కాకపోయినా, పరిమిత సెట్‌లోని క్లయింట్‌ల కోసం), ఇది ఎల్లప్పుడూ మంచిది మరియు సరైనది కాదు. అందుకే వారు ఎండ్-టు-ఎండ్ ఎన్‌క్రిప్షన్ చేయడం ప్రారంభించారు, DBMS లో వారు క్లయింట్ మరియు సర్వర్ వైపు డేటాను గుప్తీకరించడానికి ఎంపికలను పరిగణించడం ప్రారంభించారు మరియు అదే కీ-వాల్ట్ నిల్వలు కనిపించాయి - DBMS లో కీ నిర్వహణను అందించే ప్రత్యేక ఉత్పత్తులు వైపు.

MongoDBలో అటువంటి గుప్తీకరణకు ఉదాహరణ

వాణిజ్య మరియు ఓపెన్ సోర్స్ DBMSలో భద్రతా లక్షణాలు

విధులు
రకం
పాస్‌వర్డ్ విధానం
ఆడిట్
విధానాలు మరియు విధుల సోర్స్ కోడ్‌ను రక్షించడం
RLS
ఎన్క్రిప్షన్

ఒరాకిల్
వాణిజ్య
+
+
+
+
+

MsSql
వాణిజ్య
+
+
+
+
+

జటోబా
వాణిజ్య
+
+
+
+
పొడిగింపులు

PostgreSQL
ఉచిత
పొడిగింపులు
పొడిగింపులు
-
+
పొడిగింపులు

మొంగోడిబి
ఉచిత
-
+
-
-
MongoDB ఎంటర్‌ప్రైజ్‌లో మాత్రమే అందుబాటులో ఉంది

పట్టిక పూర్తి కాదు, కానీ పరిస్థితి ఇది: వాణిజ్య ఉత్పత్తులలో, భద్రతా సమస్యలు చాలా కాలం పాటు పరిష్కరించబడ్డాయి, ఓపెన్ సోర్స్‌లో, నియమం ప్రకారం, భద్రత కోసం కొన్ని రకాల యాడ్-ఆన్‌లు ఉపయోగించబడతాయి, చాలా విధులు లేవు , కొన్నిసార్లు మీరు ఏదైనా జోడించాలి. ఉదాహరణకు, పాస్‌వర్డ్ విధానాలు - PostgreSQL అనేక విభిన్న పొడిగింపులను కలిగి ఉంది (1, 2, 3, 4, 5), ఇది పాస్‌వర్డ్ విధానాలను అమలు చేస్తుంది, కానీ, నా అభిప్రాయం ప్రకారం, వాటిలో ఏవీ దేశీయ కార్పొరేట్ సెగ్మెంట్ యొక్క అన్ని అవసరాలను కవర్ చేయవు.

మీకు అవసరమైనవి ఎక్కడా లేకపోతే ఏమి చేయాలి? ఉదాహరణకు, మీరు కస్టమర్‌కు అవసరమైన విధులు లేని నిర్దిష్ట DBMSని ఉపయోగించాలనుకుంటున్నారు.

అప్పుడు మీరు వివిధ DBMSలతో పని చేసే మూడవ పక్ష పరిష్కారాలను ఉపయోగించవచ్చు, ఉదాహరణకు, Crypto DB లేదా Garda DB. మేము దేశీయ సెగ్మెంట్ నుండి పరిష్కారాల గురించి మాట్లాడినట్లయితే, అప్పుడు ఓపెన్ సోర్స్ కంటే GOSTల గురించి వారికి బాగా తెలుసు.

రెండవ ఎంపిక ఏమిటంటే, మీకు అవసరమైన వాటిని మీరే వ్రాయడం, ప్రక్రియ స్థాయిలో అప్లికేషన్‌లో డేటా యాక్సెస్ మరియు ఎన్‌క్రిప్షన్‌ని అమలు చేయడం. నిజమే, ఇది GOST తో మరింత కష్టం అవుతుంది. కానీ సాధారణంగా, మీరు అవసరమైన డేటాను దాచవచ్చు, దానిని DBMSలో ఉంచవచ్చు, ఆపై దాన్ని తిరిగి పొందవచ్చు మరియు అవసరమైన విధంగా డీక్రిప్ట్ చేయవచ్చు, అప్లికేషన్ స్థాయిలోనే. అదే సమయంలో, మీరు అప్లికేషన్‌లోని ఈ అల్గారిథమ్‌లను ఎలా రక్షిస్తారనే దాని గురించి వెంటనే ఆలోచించండి. మా అభిప్రాయం ప్రకారం, ఇది DBMS స్థాయిలో చేయాలి, ఎందుకంటే ఇది వేగంగా పని చేస్తుంది.

ఈ నివేదిక మొదట సమర్పించబడింది @డేటాబేస్‌ల సమావేశం Mail.ru క్లౌడ్ సొల్యూషన్స్ ద్వారా. చూడు видео ఇతర ప్రదర్శనలు మరియు టెలిగ్రామ్‌లో ఈవెంట్ ప్రకటనలకు సభ్యత్వాన్ని పొందండి Mail.ru గ్రూప్‌లో కుబెర్నెట్స్ చుట్టూ.

అంశంపై ఇంకా ఏమి చదవాలి:

1. Ceph కంటే ఎక్కువ: MCS క్లౌడ్ బ్లాక్ నిల్వ.
2. ప్రాజెక్ట్ కోసం డేటాబేస్ను ఎలా ఎంచుకోవాలి కాబట్టి మీరు మళ్లీ ఎంచుకోవలసిన అవసరం లేదు.

మూలం: www.habr.com