Më quajnë Denis Rojkov, unë jam drejtor i zhvillimit të software-it në kompaninë «Gazinformservice», në ekipin e produktit . Legjislacioni dhe normat e korporatave vendosin kërkesa të caktuara për sigurinë e ruajtjes së të dhënave. Askush nuk dëshiron që palë të treta të kenë qasje në informacionin konfidencial, prandaj për çdo projekt, pyetje të tilla janë të rëndësishme: identifikimi dhe autentikimi, menaxhimi i qasjes së të dhënave, sigurimi i integritetit të informacionit në sistem, regjistrimi i ngjarjeve të sigurisë. Prandaj, dua të flas për disa momente interesante që lidhen me sigurinë e SGBD.
Artikulli është përgatitur sipas një paraqitjeje në organizuar . Nëse nuk doni të lexoni, mund ta shihni:
Artikulli do të ketë tre pjesë:
- Si të mbrohet lidhjet.
- ĂfarĂ« Ă«shtĂ« auditi i veprimeve dhe si tĂ« regjistrohet çfarĂ« ndodh nga ana e bazĂ«s sĂ« tĂ« dhĂ«nave dhe lidhjes sĂ« saj.
- Si të mbrohen të dhënat në vetë bazën e të dhënave dhe cilat teknologji ekzistojnë për këtë.
Tre komponentët e sigurisë së SGBD: mbrojtja e lidhjeve, auditi i veprimeve dhe mbrojtja e të dhënave
Mbrojtja e lidhjeve
Lidhja me bazën e të dhënave mund të bëhet si direkt ashtu edhe nëpërmjet aplikacioneve web. Në përgjithësi, përdoruesi nga ana e biznesit, domethënë një njeri që punon me SGBD, ndërvepron me të jo drejtpërdrejt.
Përpara se të flasim për mbrojtjen e lidhjeve, duhet të përgjigjemi në pyetje të rëndësishme, që do të determinojnë se si do të ndërtohen masat e sigurisë:
- a është ekuivalent një përdorues biznesi me një përdorues të SGBD;
- a sigurohet akses në të dhënat e SGBD vetëm përmes API-së, e cila ju kontrolloni, apo ka akses në tabela direkt;
- a është SGBD e ndarë në një segment të veçantë të mbrojtur, kush dhe si ndërvepron me të;
- a përdoret pooling/proxy dhe shtresa ndërmjetëse që mund të ndryshojnë informacionin për mënyrën se si është ndërtuar lidhja dhe kush përdor bazën e të dhënave.
Tani le të shohim se cilat mjete mund të aplikojmë për të mbrojtur lidhjet:
- PĂ«rdorni zgjidhje tĂ« klasĂ«s database firewall. NjĂ« shtresĂ« e shtuar mbrojtjeje, tĂ« paktĂ«n do tĂ« rritĂ« transparencĂ«n e asaj qĂ« ndodh nĂ« SGBD, maksimumi â do tĂ« mund tĂ« sigurosh mbrojtje tĂ« shtuar pĂ«r tĂ« dhĂ«nat.
- Përdorni politikat e fjalëkalimeve. Zbatimi i tyre varet nga mënyra se si është ndërtuar arhitektura juaj. Në çdo rast, një fjalëkalim në skedarin e konfigurimit të aplikacionit web që lidhet me DBMS është i pamjaftueshëm për mbrojtje. Ekzistojnë një sërë mjetesh DBMS që lejojnë monitorimin e kërkesës për azhurnimin e përdoruesit dhe fjalëkalimit.
Lexoni mĂ« shumĂ« rreth funksionaliteteve tĂ« vlerĂ«simit tĂ« pĂ«rdoruesve. , gjithashtu mund tĂ« mĂ«soni pĂ«r MS SQL Vulnerability Assessment. .Â
- Pasuroni kontekstin e sesionit me informacionin e nevojshëm. Nëse sesioni është i paqartë, nuk kuptoni se kush po punon brenda tij në DBMS, mund të shtoni informacion rreth asaj që bën, kush është dhe përse, gjatë operacionit të kryer. Ky informacion mund të shihet në audit.
- Konfiguroni SSL-në, nëse nuk keni ndarje rrjeti ndërmjet DBMS-së dhe përdoruesve të fundit, që nuk është në një VLAN të veçantë. Në këto raste, është domosdoshmërisht të mbroni kanalin ndërmjet konsumatorit dhe vetë DBMS-së. Ekzistojnë mjete mbrojtëse gjithashtu edhe në mes open source.
Si do të ndikojë kjo në performancën e DBMS-së?
Le të shohim shembujt e PostgreSQL, si SSL ndikon në ngarkesën e CPU, rritjen e kohëve dhe zvogëlimin e TPS, a do të harxhohen shumë burime nëse aktivizohet.
Ngarkohet PostgreSQL duke pĂ«rdorur pgbench â kjo Ă«shtĂ« njĂ« program i thjeshtĂ« pĂ«r tĂ« ekzekutuar teste performance. Ai pĂ«rsĂ«rit njĂ« sekuencĂ« komandash disa herĂ«, ndoshta nĂ« seanca paralele tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, dhe mĂ« pas llogarit shpejtĂ«sinĂ« mesatare tĂ« transaksioneve.
Test 1 pa SSL dhe duke pĂ«rdorur SSL â lidhja vendoset nĂ« çdo transaksion:
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"ndaj
pgbench.exe --connect -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Test 2 pa SSL dhe duke pĂ«rdorur SSL â tĂ« gjitha transaksionet kryhen nĂ« njĂ« lidhje:
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"ndaj
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Cilësime të tjera:
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/50000Rezultatet e testimit:
Â
PA SSL
SSL
Vendoset lidhja në çdo transaksion
mesatarja e vonesës
171.915 ms
187.695 ms
tps duke përfshirë vendosjen e lidhjeve
58.168112
53.278062
tps duke përjashtuar lidhjet e vendosura
64.084546
58.725846
CPU
24%
28%
Të gjitha transaksionet kryhen në një lidhje
mesatarja e vonesës
6.722 ms
6.342 ms
tps përfshirë vendosjen e lidhjeve
1587.657278
1576.792883
tps duke përjashtuar lidhjet e vendosura
1588.380574
1577.694766
CPU
17%
21%
Në ngarkesa të vogla, ndikimi i SSL është i krahasueshëm me gabimin e matjes. Nëse vëllimi i të dhënave të transferuara është shumë i madh, situata mund të jetë ndryshe. Nëse ne vendosim një lidhje për çdo transaksion (kjo ndodh rrallë, zakonisht lidhjet ndahen ndërmjet përdoruesve), keni një numër të madh lidhjesh/çlirimesh, ndikimi mund të jetë pak më i madh. Pra, ka rreziqe për një ulje të performancës, megjithatë, dallimi nuk është aq i madh sa të mos përdoret mbrojtja.
Kujdes â ka njĂ« dallim tĂ« madh nĂ«se krahasohen modet e funksionimit: brenda njĂ« seance punoni ose nĂ« tĂ« ndryshme. Kjo Ă«shtĂ« e qartĂ«: krijimi i çdo lidhjeje kĂ«rkon burime.
Kemi njĂ« rast kur lidhĂ«m Zabbix nĂ« modin besnik, domethĂ«nĂ« nuk e kontrollonim md5, nuk kishte nevojĂ« pĂ«r autentifikim. MĂ« pas, klienti kĂ«rkoi tĂ« aktivizohej modi i autentifikimit md5. Kjo shkaktoi njĂ« ngarkesĂ« tĂ« madhe nĂ« CPU, performanca ra. Nisi njĂ« kĂ«rkim pĂ«r mundĂ«si optimizimi. NjĂ« nga zgjidhjet e mundshme pĂ«r problemin â tĂ« zbatohet njĂ« kufizim rrjeti, tĂ« krijohen VLAN tĂ« veçanta pĂ«r DBMS, tĂ« shtohen konfigurime pĂ«r tĂ« bĂ«rĂ« tĂ« qartĂ« se kush dhe nga ku lidhet dhe tĂ« hiqet autentifikimi. Gjithashtu, mund tĂ« optimizohen parametrat e autentifikimit pĂ«r tĂ« ulur kostot gjatĂ« aktivizimit tĂ« autentifikimit, por nĂ« pĂ«rgjithĂ«si, pĂ«rdorimi i metodave tĂ« ndryshme tĂ« autentifikimit ndikon nĂ« performancĂ« dhe duhet tĂ« merret parasysh kĂ«to faktorĂ« gjatĂ« projektimit tĂ« kapaciteteve kompjuterike tĂ« serverĂ«ve (harduerit) pĂ«r DBMS.
Përfundimi: në disa zgjidhje, madje edhe nuanca të vogla në autentifikim mund të ndikojnë ndjeshëm në projekt dhe është keq kur kjo kuptohet vetëm gjatë zbatimit në prodhim.
Auditi i veprimeve
Auditi nuk është vetëm për SGBD. Auditi është marrja e informacionit mbi atë që ndodh në segmente të ndryshme. Kjo mund të jetë edhe një firewall database, edhe sistemi operativ mbi të cilin është ndërtuar SGBD.
NĂ« SGBD komerciale tĂ« nivelit Enterprise, auditi Ă«shtĂ« i mirĂ«, por nĂ« open source â jo gjithmonĂ«. KĂ«tu Ă«shtĂ« çfarĂ« ka nĂ« PostgreSQL:
- log default â logimi i ndĂ«rtuar;
- ekstensionet: pgaudit â nĂ«se ju mungon logimi standard, mund tĂ« pĂ«rdorni konfigurime tĂ« veçanta qĂ« zgjidhin disa probleme.
Shtesë për raportin në video:
«Regjistrimi fillestar i operatorëve mund të sigurohet nga një mjet standard i regjistrimit me log_statement = all.
Kjo është e pranueshme për monitorim dhe përdorime të tjera, por nuk siguron nivelin e detajeve që është zakonisht i nevojshëm për auditet.
Nuk mjafton të kesh një listë të të gjitha operacioneve që kryhen me bazën e të dhënave.
Duhet gjithashtu të ketë mundësinë për të gjetur afirmatat specifike që janë të rëndësishme për auditorin.
Mjeti i standardit të regjistrimit tregon atë që kërkoi përdoruesi, ndërsa pgAudit fokusohet në detajet e asaj që ndodhi kur baza e të dhënave kryente kërkesën.
Për shembull, një auditor mund të dëshirojë të sigurojë që një tavolinë specifike të jetë krijuar në një dritare shërbimi të dokumentuar.
Kjo mund të duket si një detyrë e thjeshtë për një audit të bazuar dhe grep, por çfarë nëse ju paraqitet diçka si ky shembull (me qëllim të ndërlikuar):
DO $$
FILLIM
EXECUTE âCREATE TABLE importâ || âant_table (id INT)â;
END $$;
Mbajtja e standardit të regjistrit do t'ju japë këtë:
LOG: statement: DO $$
FILLIM
EXECUTE âCREATE TABLE importâ || âant_table (id INT)â;
END $$;
Duket se për të gjetur tavolinën e interesit mund të kërkohet disa njohuri për kodin në raste kur tavolinat janë krijuar dinamikisht.
Kjo nuk është ideale, pasi do të ishte e preferueshme të kërkoni thjesht sipas emrit të tavolinës.
Këtu është ku do të jetë e dobishme pgAudit.
Për të njëjtën hyrje ai do të japë këtë dalje në regjistër:
AUDIT: SESSION,33,1,FUNCTION,DO,,,«DO $$
FILLIM
EXECUTE âCREATE TABLE importâ || âant_table (id INT)â;
END $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)
Regjistrohet jo vetëm blloku DO, por edhe teksti i plotë CREATE TABLE me llojin e operatorit, llojin e objektit dhe emrin e plotë, duke lehtësuar kërkimin.
Me regjistrimin e operatorëve SELECT dhe DML, pgAudit mund të konfiguroni për të regjistruar një hyrje të veçantë për çdo marrëdhënie që referohet në operator.
Nuk kërkohet një analizë sintaksore për të gjetur të gjithë operatorët që lidhen me një tabelë të caktuar,)».
Si do të ndikojë kjo në performancën e DBMS-së?
Le të kryejmë testime me përfshirjen e auditit të plotë dhe të shohim çfarë do të ndodhë me performancën e PostgreSQL. Do të aktivizojmë maksimalin e regjistrimit të DB sipas të gjitha parametrave.
Nuk bĂ«jmĂ« pothuajse asnjĂ« ndryshim nĂ« skedarin e konfigurimit, nga tĂ« rĂ«ndĂ«sishmet â aktivizojmĂ« rejimin debug5 pĂ«r tĂ« marrĂ« maksimumin e informacionit.
postgresql.conf
log_destination = âstderrâ
logging_collector = on
log_truncate_on_rotation = on
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 = on
debug_pretty_print = on
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_hostname = on
log_lock_waits = on
log_replication_commands = on
log_temp_files = 0
log_timezone = âEurope/Moscowâ
Në SGBD PostgreSQL me parametrat 1 CPU, 2.8 GHz, 2 GB RAM, 40 GB HDD, realizojmë tre teste ngarkese, duke përdorur komandat:
$ 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 benchmarkRezultatet e testimit:
Pa regjistrim
Me regjistrim
Koha totale e mbushjes së DB
43.74 sek
53.23 sek
RAM
24%
40%
CPU
72%
91%
Testi 1 (50 lidhje)
Numri i transaksioneve për 10 minuta
74169
32445
Transaksione/sek
123
54
Vonesa mesatare
405 ms
925 ms
Testi 2 (150 lidhje të mundshme 100)
Numri i transaksioneve për 10 minuta
81727
31429
Transaksione/sek
136
52
Vonesa mesatare
550 ms
1432 ms
PĂ«rmasat
Madhësia e DB
2251 MB
2262 MB
Madhësia e logjeve të DB
0 MB
4587 MB
Në fund: auditimi i plotë nuk është shumë i mirë. Të dhënat e auditimit do të jenë në vëllim si të dhënat në vetë bazën e të dhënave, madje edhe më shumë. Ky vëllim i regjistrimit, i cili gjenerohet në punën me DBMS, është një problem i zakonshëm në prodhim.
Shikojmë parametrat e tjerë:
- ShpejtĂ«sia nuk ndryshon shumĂ«: pa regjistrim â 43,74 sek, me regjistrim â 53,23 sek.
- Performanca në RAM dhe CPU do të bjerë, pasi duhen krijuar skedarët me auditimin. Kjo është gjithashtu e dukshme në prodhim.
Me rritjen e numrit të lidhjeve, natyrisht, rezultatet do të përkeqësohen pak.
Në korporata me auditim është akoma më e komplikuar:
- të dhënat janë të shumta;
- auditimi nevojitet jo vetëm përmes syslog në SIEM, por edhe në skedarë: përndryshe nëse ndodhi diçka me syslog, duhet të ketë një skedar afër bazës, ku do të ruhen të dhënat;
- për auditimin nevojitet një raft i veçantë, për të mos rënë në I/O të disqeve, pasi ai zë shumë hapësirë;
- ka raste kur punonjësit e sigurisë kërkojnë mëkatësi, ato kërkojnë identifikim të akredituar.
Kufizimi i aksesit në të dhëna
Le të shohim teknologjitë që përdoren për të mbrojtur të dhënat dhe qasjen në to në sistemet komerciale të menaxhimit të të dhënave dhe open source.
ĂfarĂ« mund tĂ« pĂ«rdoret nĂ« pĂ«rgjithĂ«si:
- Kriptimi dhe obfuskimi i procedurave dhe funksioneve (Wrapping) - pra, vegla dhe utilitetet të veçanta që e bëjnë kodin e lexueshëm të papërshkueshëm. Megjithatë, më vonë nuk mund ta ndryshosh ose ta riparosh përsëri. Ky qasje ndonjëherë kërkohet minimalisht në anën e DBMS - logjika e kufizimeve të licencës ose logjika e autorizimit është e koduar saktësisht në nivelin e procedurës dhe funksionit.
- Kufizimi i dukshmërisë së të dhënave sipas rreshtave (RLS) - është kur përdorues të ndryshëm shohin një tabelë, por përbërja e ndryshme e rreshtave në të, do të thotë se dikujt diçka nuk mund t'i tregohet në nivelin e rreshtave.
- Editimi i të dhënave të shfaqura (Masking) - është kur përdoruesit në një kolonë tabelar shohin ose të dhëna, ose vetëm yje, pra për disa përdorues informacioni do të jetë i mbyllur. Teknologjia përcakton se çfarë duhet t'i tregosh çdo përdoruesi duke marrë parasysh nivelin e aksesit.
- Ndara e qasjes Security DBA/Application DBA/DBA â nĂ« fakt, kjo lidhet me kufizimin e qasjes nĂ« vetĂ« DBMS-nĂ«, dmth punonjĂ«sit e sigurisĂ« mund tĂ« ndahen nga administratorĂ«t e database dhe administratorĂ«t e aplikacioneve. NĂ« teknologjitĂ« open source ka pak tĂ« tilla, ndĂ«rsa nĂ« DBMS-tĂ« komerciale ka mjaftueshĂ«m. Ato janĂ« tĂ« nevojshme kur ka shumĂ« pĂ«rdorues me qasje nĂ« vetĂ« serverat.
- Kufizimi i qasjes në skedarë në nivele të sistemit të skedarëve. Mund të jepen të drejta, privilegje qasje në katalogë, në mënyrë që çdo administrator të ketë qasje vetëm në të dhënat e nevojshme.
- Qasja e mandatuar dhe pastrimi i memories â kĂ«to teknologji pĂ«rdoren rrallĂ«.
- Kriptimi end-to-end direkt nĂ« DBMS â kjo Ă«shtĂ« kriptimi nĂ« anĂ«n e klientit me menaxhim tĂ« çelsave nĂ« anĂ«n e serverit.
- Kriptimi i tĂ« dhĂ«nave. PĂ«r shembull, kriptimi kolonash â kur pĂ«rdorni mekanizmin qĂ« kripton njĂ« kolonĂ« tĂ« veçantĂ« tĂ« bazĂ«s.
Si ndikon kjo në performancën e DBMS?
Le të shohim një shembull të enkriptimit në kolona në PostgreSQL. Ka një modul pgcrypto, që lejon ruajtjen e fusha të zgjedhura në mënyrë të enkriptuar. Kjo është e dobishme kur vetëm disa të dhëna kanë vlerë. Për të lexuar fushat e enkriptuara, klienti kalon çelësin e dekriptimit, serveri dekriptojnë të dhënat dhe i kthen ato klientit. Pa çelësin, askush nuk mund të bëjë asgjë me të dhënat tuaja.
Le tĂ« bĂ«jmĂ« njĂ« test me pgcrypto. Do tĂ« krijojmĂ« njĂ« tabelĂ« me tĂ« dhĂ«na tĂ« enkriptuara dhe me tĂ« dhĂ«na tĂ« zakonshme. MĂ« poshtĂ« janĂ« komandat pĂ«r krijimin e tabelave, nĂ« rreshtin e parĂ« Ă«shtĂ« njĂ« komandĂ« e dobishme â krijimi i vetĂ« zgjerimit me regjistrimin e 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'));Më pas, do të përpiqemi të marrim të dhëna nga secila tabelë dhe të shohim kohët e ekzekutimit.
Këtu është kërkesa nga tabela pa funksionin e enkriptimit:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtKronometri është aktivizuar.
  id | teksti1 | teksti2
ââ+ââ-+ââ-
1 | 1 Â Â | 1
2 | 2 Â Â | 2
3 | 3 Â Â | 3
âŠ
997 | 997 Â | 997
998 | 998 Â | 998
999 | 999 Â | 999
1000 | 1000Â | 1000
(1000 rreshta)
Koha: 1.386 ms
Mostër nga tabela me funksionin e enkriptimit:
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.txtKronometri është aktivizuar.
  id | dekryptim  | dekryptim
ââ+âââââ+ââââ
1 | x31 Â | x31
2 | x32 Â | x32
3 | x33 | x33
âŠ
999 | x393939 Â | x393939
1000 | x31303030 | x31303030
(1000 rreshta)
Koha: 50.203 ms
Rezultatet e testimit:
Â
Pa enkriptim
Pgcrypto (dekryptim)
Mostër 1000 rreshta
1.386 ms
50.203 ms
CPU
15%
35%
RAM
Â
+5%
Enkriptimi ka njĂ« ndikim tĂ« fortĂ« nĂ« performancĂ«. ĂshtĂ« e dukshme se koha Ă«shtĂ« rritur, pasi operacionet e dekryptimit tĂ« tĂ« dhĂ«nave tĂ« enkriptuara (dhe dekryptimi zakonisht Ă«shtĂ« i mbĂ«shtjellĂ« nĂ« logjikĂ«n tuaj) kĂ«rkojnĂ« burime tĂ« konsiderueshme. KĂ«shtu, ideja pĂ«r tĂ« enkriptuar tĂ« gjitha kolonat qĂ« pĂ«rmbajnĂ« disa tĂ« dhĂ«na Ă«shtĂ« e rrezikshme pĂ«r uljen e performancĂ«s.
Megjithatë, enkriptimi nuk është një plumb argjendi që zgjidh të gjitha problemet. Të dhënat e dekryptuara dhe çelësi i dekryptimit gjatë procesit të dekryptimit dhe transmetimit të të dhënave ndodhen në server. Prandaj, çelësat mund të kapen nga ata që kanë qasje të plotë në serverin e bazës së të dhënave, siç janë administratorët e sistemit.
Kur pĂ«r tĂ« gjithĂ« pĂ«rdoruesit Ă«shtĂ« njĂ« çelĂ«s pĂ«r tĂ«rĂ« kolonĂ«n (edhe nĂ«se jo pĂ«r tĂ« gjithĂ«, por pĂ«r klientĂ«t e njĂ« grupi tĂ« kufizuar), â kjo nuk Ă«shtĂ« gjithmonĂ« e mirĂ« dhe e saktĂ«. PikĂ«risht pĂ«r kĂ«tĂ« arsye filluam tĂ« bĂ«jmĂ« enkriptim end-to-end, nĂ« DBMS po shqyrtojmĂ« opsione pĂ«r enkriptimin e tĂ« dhĂ«nave nga klienti dhe serveri, u shfaqĂ«n ato tĂ« famshme depozita tĂ« key-vault - produkte tĂ« veçanta qĂ« ofrojnĂ« menaxhimin e çelĂ«save nĂ« anĂ«n e DBMS.
Mjetet e sigurisë në DBMS komerciale dhe open source
Funksionet
Tipo
Politika e Fjalëkalimeve
Auditimi
Mbrojtja e kodit burimor të procedurave dhe funksioneve
RLS
Enkriptimi
Oracle
Komerciale
+
+
+
+
+
MsSql
Komerciale
+
+
+
+
+
Komerciale
+
+
+
+
zgjerimet
PostgreSQL
Falë
zgjerimet
zgjerimet
â
+
zgjerimet
MongoDb
Falë
â
+
â
â
I disponueshëm vetëm në MongoDB Enterprise
Tabela nuk Ă«shtĂ« aspak e plotĂ«, por situata Ă«shtĂ« kĂ«shtu: nĂ« produktet komerciale, detyrat e sigurisĂ« janĂ« zgjidhur prej kohĂ«sh, nĂ« open source, zakonisht pĂ«rdoren ndonjĂ« shtesĂ« pĂ«r sigurinĂ«, shumĂ« funksione mungojnĂ«, ndonjĂ«herĂ« duhet tĂ« shtosh diçka vetĂ«. PĂ«r shembull, politikat e fjalĂ«kalimeve â nĂ« PostgreSQL ka shumĂ« zgjerime tĂ« ndryshme (, , , , ), qĂ« realizojnĂ« politikat e fjalĂ«kalimeve, por nevojat e sektorit korporativ vendas, sipas mendimit tim, asnjĂ« nuk i mbulon.
ĂfarĂ« tĂ« bĂ«jmĂ« nĂ«se nuk ka asgjĂ« qĂ« na nevojitet? ĐĐ°ĐżŃĐžĐŒĐ”Ń, Ń ĐŸŃĐ”ŃŃŃ ĐžŃĐżĐŸĐ»ŃĐ·ĐŸĐČĐ°ŃŃ ĐŸĐżŃĐ”ĐŽĐ”Đ»Đ”ĐœĐœŃŃ ĐĄĐŁĐĐ, ĐČ ĐșĐŸŃĐŸŃĐŸĐč ĐœĐ”Ń ŃŃĐœĐșŃĐžĐč, ĐșĐŸŃĐŸŃŃĐ” ŃŃДбŃĐ”Ń Đ·Đ°ĐșĐ°Đ·ŃĐžĐș.
Atëherë mund të përdorni zgjidhje të jashtme që punojnë me sisteme të ndryshme DB, si "Kripto BD" ose "Garda BD". Nëse flasim për zgjidhje nga sektori vendas, atje dihet më shumë për standartet GOST se sa në open source.
Varianti i dytë është të shkruani vetë atë që ju nevojitet, të realizoni në nivelin e procedurave aksesin në të dhëna dhe enkriptimin në aplikacion. E vërteta është se me GOST-it do të jetë më e vështirë. Por në përgjithësi, ju mund të fshihni të dhënat siç duhet, t'i ruani në DB dhe pastaj t'i nxirrni dhe t'i dekriptoni siç duhet, direkt në nivelin e aplikacionit. Në të njëjtën kohë, mendoni se si do t'i mbroni këto algoritme në aplikacion. Sipas mendimit tonë, kjo duhet bërë në nivelin e DB, sepse do të funksionojë më shpejt.
Ky raport u shpërnda për herë të parë në nga Mail.ru Cloud Solutions. Shikoniprezantime të tjera dhe abonohuni për njoftimet mbi ngjarjet në Telegram .
ĂfarĂ« tjetĂ«r tĂ« lexoni nĂ« kĂ«tĂ« temĂ«:
- .
- .
Burimi: habr.com
