ProHoster > Blog > Administrim > Siguria dhe DBMS: çfarë duhet të mbani parasysh kur zgjidhni mjete mbrojtëse

Siguria dhe DBMS: çfarë duhet të mbani parasysh kur zgjidhni mjete mbrojtëse

Siguria dhe DBMS: çfarë duhet të mbani parasysh kur zgjidhni mjete mbrojtëse

Unë quhem Denis Rojkov, jam drejtori i zhvillimit të softuerit në kompaninë «Gazinformservis», në ekipin e produktit Jatoba. Legjislacioni dhe normat korporative vënë kërkesa të veçanta për sigurinë e ruajtjes së të dhënave. Askush nuk dëshiron që palët e treta të kenë qasje në informatat konfidenciale, prandaj për çdo projekt janë të rëndësishme pyetje të tilla: identifikimi dhe autentikimi, menaxhimi i qasjeve në të dhëna, sigurimi i integritetit të informacionit në sistem, regjistrimi i ngjarjeve të sigurisë. Prandaj dëshiroj të flas për disa momente interesante që kanë të bëjnë me sigurinë e DBMS.

Artikulli është përgatitur sipas një prezantimi në @Databases Meetup, të organizuar Mail.ru Cloud Solutions. Nëse nuk dëshironi të lexoni, mund të shihni:

Luaj videon

Artikulli do të ketë tri pjesë:
  • Si tĂ« mbrohen lidhjet.
  • ÇfarĂ« Ă«shtĂ« auditi i veprimeve dhe si tĂ« regjistrohet se çfarĂ« ndodh nga ana e bazĂ«s sĂ« tĂ« dhĂ«nave dhe lidhjes me tĂ«.
  • Si tĂ« mbrohen tĂ« dhĂ«nat nĂ« vetĂ« bazĂ«n e tĂ« dhĂ«nave dhe çfarĂ« teknologjish pĂ«rdoren pĂ«r kĂ«tĂ«.

Siguria dhe DBMS: çfarë duhet të mbani parasysh kur zgjidhni mjete mbrojtëse
Tre componente të sigurisë së DBMS: mbrojtja e lidhjeve, auditimi i veprimeve dhe mbrojtja e të dhënave

Mbrojtja e lidhjeve

Mund të lidheni me bazën e të dhënave si direkt, ashtu edhe në mënyrë indirekte përmes aplikacioneve web. Rregullisht, përdoruesi nga business, dmth, personi që punon me DBMS, ndërvepron me të jo drejtpërdrejt.

Para se të flasim për mbrojtjen e lidhjeve, duhet të përgjigjemi në pyetje të rëndësishme, nga të cilat varet se si do të organizohen masat e sigurisë:

  • Ă«shtĂ« ekuivalent njĂ« pĂ«rdorues biznesi me njĂ« pĂ«rdorues tĂ« DBMS;
  • a sigurohet qasja nĂ« tĂ« dhĂ«nat e DBMS vetĂ«m pĂ«rmes API-sĂ« qĂ« ju kontrolloni, apo ka qasje direkt nĂ« tabelat;
  • a Ă«shtĂ« DBMS e ndarĂ« nĂ« njĂ« segment tĂ« veçantĂ« tĂ« mbrojtur, kush dhe si ndĂ«rvepron me tĂ«;
  • a pĂ«rdoren pooling/proxy dhe shtresa ndĂ«rmjetĂ«se qĂ« mund tĂ« ndryshojnĂ« informacionin se si Ă«shtĂ« krijuar lidhja dhe kush e pĂ«rdor bazĂ«n e tĂ« dhĂ«nave.

Tani le të shohim cilat mjete mund të aplikohen për mbrojtjen e lidhjeve:

  1. Përdorni zgjidhje të klasës database firewall. Një shtesë mbrojtëse do të rrisë përshtatshmërinë e asaj që ndodh në DBMS, për maksimum do të jeni në gjendje të siguroni mbrojtje të mëtejshme për të dhënat.
  2. Përdorni politikat e fjalëkalimeve. Aplikimi i tyre varet nga si është ndërtuar arkitektura juaj. Megjithatë, një fjalëkalim në skedarin e konfigurimit të aplikacionit web që lidhet me DBMS nuk është i mjaftueshëm për mbrojtje. Ka një sërë mjetesh DBMS që lejojnë të kontrolloni që përdoruesi dhe fjalëkalimi kërkojnë përditësim.

    Lexoni më shumë rreth funksioneve të vlerësimit të përdoruesve. këtu, ashtu siç mund të mësoni për MS SQL Vulnerability Assessment. këtu. 

  3. Pasuroni kontekstin e seancës me informacionin e nevojshëm. Nëse sesioni është i pandriçuar, nuk kuptoni kush po punon brenda DBMS, mund të plotësoni informacionin mbi atë se kush, çfarë dhe pse bën atë që po bëhet në kuadër të operacionit të ekzekutuar. Ky informacion mund të shihet në audit.
  4. Konfiguroni SSL nëse nuk keni një ndarje rrjetesh të DBMS nga përdoruesit përfundimtarë, nëse ajo nuk është në një VLAN të veçantë. Në raste të tilla, është e domosdoshme të mbrohet kanali midis konsumatorit dhe vetë DBMS. Ka gjithashtu mjete mbrojtjeje mes tyre dhe open source.

Si do të ndikojë kjo në performancën e DBMS?

Të shohim një shembull me PostgreSQL, si SSL ndikon në ngarkesën e CPU, rritjen e kohëve të përgjigjes dhe zvogëlimin e TPS, a do të humbasë shumë burime nëse e aktivizojmë.

NgarkojmĂ« PostgreSQL, duke pĂ«rdorur pgbench — Ă«shtĂ« njĂ« program i thjeshtĂ« pĂ«r tĂ« ekzekutuar teste performancĂ«. Ai ekzekuton njĂ« sekuencĂ« komandash tĂ« njĂ«jta shumĂ« herĂ«, ndoshta nĂ« seanca paralele tĂ« bazĂ«s sĂ« tĂ« dhĂ«nave, dhe mĂ« pas llogarit shpejtĂ«sinĂ« mesatare tĂ« transaksioneve.

Testi 1 pa SSL dhe me pĂ«rdorimin e SSL. — lidhja krijohet me ç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"

vs

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

Testi 2 pa SSL dhe me pĂ«rdorimin e SSL. — tĂ« gjitha transaksionet ekzekutohen 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"

vs

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

Cilësimet e tjera:

faktori i shkallës: 1
modi i kërkimeve: i thjeshtë
numri i klientëve: 10
numri iThreads: 1
numri i transaksioneve për klient: 5000
numri i transaksioneve që u përpunuan në të vërtetë: 50000/50000

Rezultatet e testimit:

 
NUK KA SSL
SSL

Lidhja krijohet me çdo transaksion.

mesatarja e vonesës
171.915 ms
187.695 ms

tps duke përfshirë krijimin e lidhjeve
58.168112
53.278062

tps duke përjashtuar krijimin e lidhjeve
64.084546
58.725846

CPU
24%
28%

Të gjitha transaksionet ekzekutohen në një lidhje.

mesatarja e vonesës
6.722 ms
6.342 ms

tps duke përfshirë krijimin e lidhjeve.
1587.657278
1576.792883

tps duke përjashtuar krijimin e lidhjeve
1588.380574
1577.694766

CPU
17%
21%

Me ndikime të vogla, efekti i SSL është i ngjashëm me gabimin e matjes. Nëse volumi i të dhënave që transmetohet është shumë i madh, situata mund të jetë ndryshe. Nëse ne krijojmë një lidhje për çdo transaksion (kjo ndodh rrallë, zakonisht lidhjet ndahen midis përdoruesve), ju keni një numër të madh lidhjesh/çlirimesh, efekti mund të jetë pak më i madh. Kjo do të thotë se rreziqet për reduktimin e performancës mund të jenë, megjithatë, diferenca nuk është aq e madhe sa për të mos përdorur mbrojtjen.

Vini re — ka njĂ« ndryshim tĂ« madh nĂ«se krahasoni modelet e punĂ«s: brenda njĂ« seance jeni duke punuar ose nĂ« mĂ«nyra tĂ« ndryshme. Kjo Ă«shtĂ« e qartĂ«: krijimi i çdo lidhjeje kĂ«rkon burime.

Kishim një rast kur u lidhëm me Zabbix në modalitetin trust, dmth nuk e verifikonim md5, nuk kishte nevojë për autentikim. Më pas, klienti kërkoi të aktivizohej modaliteti i autentikimit md5. Kjo shkaktoi një ngarkesë të madhe në CPU, performanca ra. Filluam të kërkojmë mënyra optimizimi. Një nga zgjidhjet e mundshme për këtë problem është të realizojmë kufizime rrjeti, të krijojmë VLAN të veçantë për DBMS, të shtojmë konfigurime për të qartë se kush dhe nga ku lidhet dhe të heqim autentikimin. Gjithashtu, mund të optimizojmë konfigurimet e autentikimit për të reduktuar kostot kur aktivizohet autentikimi, por në përgjithësi përdorimi i metodave të ndryshme të autentikimit ndikon në performancë dhe kërkon që të merren parasysh këta faktorë gjatë projektimit të kapaciteve përpunuese të serverëve (harduerit) për DBMS.

Përfundim: në disa zgjidhje, edhe nuanca të vogla në autentikim mund të kenë ndikim të madh në projekt dhe është keq kur kjo kuptohet vetëm gjatë zbatimit në prodhim.

Auditi i veprimeve

Auditi mund të mos jetë vetëm i DBMS. Auditi është marrja e informacionit për atë që ndodh në segmente të ndryshme. Kjo mund të jetë edhe një firewall database, edhe sistemi operativ në të cilin ndërtohet DBMS.

NĂ« DBMS komerciale tĂ« nivelit Enterprise, auditi Ă«shtĂ« nĂ« rregull, nĂ« open source — jo gjithmonĂ«. KĂ«tu Ă«shtĂ« çfarĂ« ka nĂ« PostgreSQL:

  • default log — regjistrim i integruar;
  • extensions: pgaudit — nĂ«se ju mungon regjistrimi standard, mund tĂ« pĂ«rdorni konfigurime tĂ« veçanta qĂ« zgjidhin disa nga problematikat.

Shtesë për raportin në video:

"Regjistrimi bazik i operatorëve mund të sigurohet me një mjet standard regjistrimi me log_statement = all.

Kjo është e pranueshme për monitorim dhe përdorime të tjera, por nuk siguron nivelin e detajeve që zakonisht kërkohet për auditimin.

Nuk mjafton të kesh një listë të gjitha operacioneve të kryera me bazën e të dhënave.

Po ashtu, duhet të ketë mundësinë për të gjetur deklaratat specifike që janë të rëndësishme për auditorin.

Mjeti standard i regjistrimit tregon ato që ka kërkuar përdoruesi, ndërsa pgAudit përqendrohet në detaje të asaj që ndodhi kur baza e të dhënave ekzekutoi kërkesën.

Për shembull, auditorit mund t'i duhet të sigurohet që një tabelë specifike u krijua brenda një periudhe të dokumentuar mirëmbajtjeje.

Kjo mund të duket si një detyrë e thjeshtë për auditim bazik dhe grep, por çfarë ndodh nëse ju paraqitet diçka si ky shembull (qëllimisht i ngatërruar):

DO $$
FILLON
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
MERR FUND $$;

Regjistrimi standard do t'ju japë këtë:

LOG: statement: DO $$
FILLON
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
MERR FUND $$;

Duket se për të gjetur tabelën e interesit, mund të nevojitet njohuri për kodin në rastet kur tabelat krijohen dinamikisht.

Kjo nuk është ideale, pasi do të ishte më e preferuar që thjesht të kërkohej sipas emrit të tabelës.

Këtu do t'i vlejë pgAudit.

Për të njëjtin hyrje, ai do të japë këtë dalje në regjistër:

AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
FILLON
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
MERR FUND $$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)

Jo vetëm blloku DO regjistrohet, por gjithashtu teksti i plotë CREATE TABLE me llojin e operatorit, llojin e objektit dhe emrin e plotë, duke e bërë më të lehtë kërkimin.

Kur regjistrohen operatorët SELECT dhe DML, pgAudit mund të konfigurohet për të regjistruar një hyrje të veçantë për çdo marrëdhënie që referohet në operator.

Nuk kërkohet analizë sintaksore për të gjetur të gjitha operatorët që prekin një tabelë specifike (*)».

Si do të ndikojë kjo në performancën e DBMS?

Le të bëjmë teste duke përfshirë auditimin e plotë dhe të shohim çfarë ndodh me performancën e PostgreSQL. Le të aktivizojmë regjistrimin maksimal të DB për të gjitha parametrat.

NĂ« dosjen e konfigurimit, pothuajse nuk ndryshojmĂ« asgjĂ«, nga tĂ« rĂ«ndĂ«sishmet – aktivizojmĂ« modin 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ë DBMS PostgreSQL me parametrat 1 CPU, 2.8 GHz, 2 GB RAM, 40 GB HDD, bëjmë tre teste stresi, 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 benchmark

Rezultatet e testeve:

Pa regjistrim
Me regjistrim

Koha finale për mbushjen e DB
43.74 sekondë
53.23 sekondë

RAM
24%
40%

CPU
72%
91%

Testi 1 (50 lidhje)

Numri i transaksioneve për 10 minuta
74169
32445

Transaksione/s
123
54

Vonesa mesatare
405 ms
925 ms

Testi 2 (150 lidhje me 100 të mundshme)

Numri i transaksioneve për 10 minuta
81727
31429

Transaksione/s
136
52

Vonesa mesatare
550 ms
1432 ms

Rreth madhësive

Madhësia e DB
2251 MB
2262 MB

Madhësia e regjistrimeve të DB
0 MB
4587 MB

Në përfundim: auditimi i plotë nuk është shumë më i mirë. Të dhënat nga auditi do të jenë sa të dhënat vetë në databazë, ndoshta dhe më shumë. Ky volum regjistrimi që krijohet gjatë punës 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 pĂ«r RAM dhe CPU do tĂ« ulet, pasi Ă«shtĂ« e nevojshme tĂ« formohet njĂ« skedar me auditin. Kjo Ă«shtĂ« gjithashtu e dukshme nĂ« prodhim.

Me rritjen e numrit të lidhjeve, natyrisht, treguesit do të përkeqësohen pak.

Në korporata me audit është edhe më e vështirë:

  • tĂ« dhĂ«na shumĂ«;
  • auditimi nuk Ă«shtĂ« i nevojshĂ«m vetĂ«m nĂ«pĂ«rmjet syslog nĂ« SIEM, por edhe nĂ« skedarĂ«t: ndoshta ndodh diçka me syslog, duhet tĂ« ketĂ« njĂ« skedar afĂ«r databazĂ«s ku ruhen tĂ« dhĂ«nat;
  • pĂ«r auditimin nevojitet njĂ« raft i veçantĂ«, qĂ« tĂ« mos dĂ«shtojnĂ« disqet nga I/O, pasi zĂ« shumĂ« hapĂ«sirĂ«;
  • ndodhi qĂ« punonjĂ«sit e sigurisĂ« kĂ«rkojnĂ« gjithmonĂ« standarde, kĂ«rkojnĂ« identifikimin sipas standardeve.

Kufizimi i aksesit në të dhëna

Të shohim teknologjitë që përdorin për mbrojtjen e të dhënave dhe aksesin në to në DBMS komerciale dhe open source.

ÇfarĂ« mund tĂ« pĂ«rdorim nĂ« pĂ«rgjithĂ«si:

  1. Kriptimi dhe obfuscimi i procedurave dhe funksioneve (Wrapping) - pra, vegla dhe utilitete të veçanta, të cilat bëjnë që kodi i lexueshëm të bëhet i padukshëm. Megjithatë, pastaj nuk mund të ndryshohet dhe as të ristrukturohet përsëri. Ky qasje është ndonjëherë e nevojshme të paktën në anën e DBMS - logjika e kufizimeve të licencës ose logjika e autorizimit kriptohet saktësisht në nivelin e procedurës dhe funksionit.
  2. 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 rreshtave ndahet, dmth disa njerëzve nuk u lejohet të shohin diçka në nivel rreshti.
  3. Redaktimi i të dhënave të dukshme (Masking) është kur përdoruesit në një kolonë të tabelës shohin ose të dhënat ose vetëm yje, dmth për disa përdorues informatat do të jenë të mbyllura. Teknologjia përcakton se cilit përdorues çfarë t'i tregojë me marrë parasysh nivelin e aksesit.
  4. Përjashtimi i aksesit Security DBA/Application DBA/DBA është më shumë për kufizimin e aksesit në vetë DBMS-në, dmth punonjësit e sigurisë mund të ndahen nga administruesit e database dhe administruesit e aplikacioneve. Në burim të hapur ka pak teknologji të tilla, por në DBMS-të komerciale ka shumë. Ato janë të nevojshme kur ka shumë përdorues me akses në vetë serverët.
  5. Kufizimi i aksesit në skedarë në nivelin e sistemit të skedarëve. Mund të jepen të drejta, privilegje të aksesit në katalogë, në mënyrë që çdo administrator të merrte akses vetëm në të dhënat e nevojshme.
  6. Aksesi i mandatuar dhe pastrimi i memories janë teknologji që përdoren rrallë.
  7. Kriptimi provë-deri-në-deri në vetë DBMS-në është kriptimi nga pala e klientit me menaxhimin e çelësave në anën e serverit.
  8. Kriptimi i të dhënave. Për shembull, kriptimi kolonial - kur përdorni një mekanizëm që kripton një kolonë të vetme të bazës.

Si ndikon kjo në performancën e DBMS-së?

Le të shikojmë shembullin e kriptimit kolonial në PostgreSQL. Atje ka modulin pgcrypto, ai lejon ruajtjen e fushave të zgjedhura në format të koduar. Kjo është e dobishme kur vetëm disa të dhëna kanë vlerë. Për të lexuar fushat e koduara, klienti transferon çelësin dekryptues, serveri dekrypton të dhënat dhe i dorëzon 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.. Ta krijojmë një tabelë me të dhëna të kriptuara dhe me të dhëna të zakonshme. Më poshtë janë komandat për të krijuar tabelat, në rreshtin e parë është një komandë e dobishme - krijimi i zgjerimit me regjistrimin e DBMS-së:

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ë bëjmë një përzgjedhje të dhënash nga secila tabelë dhe do të shohim koha e ekzekutimit.

PĂ«rzgjedhja 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.txt

Numëruesi është aktivizuar.

  id | text1 | text2
——+——-+——-
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

PĂ«rzgjedhja 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.txt

Numëruesi është aktivizuar.

  id | decrypt | decrypt
——+—————+————
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 (çdecrypt)

PĂ«rzgjedhja e 1000 rreshtave
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+5%

Enkriptimi ndikon ndjeshĂ«m nĂ« performancĂ«n. ËshtĂ« e dukshme se koha Ă«shtĂ« rritur, sepse operacionet e dekryptimit tĂ« tĂ« dhĂ«nave tĂ« enkriptura (dhe dekryptimi zakonisht Ă«shtĂ« i mbĂ«shtjellĂ« nĂ« logjikĂ«n tuaj) kĂ«rkojnĂ« burime tĂ« konsiderueshme. Pra, ideja pĂ«r tĂ« enkriptuar tĂ« gjitha kolonat qĂ« pĂ«rmbajnĂ« disa tĂ« dhĂ«na sjell me vete ulje tĂ« performancĂ«s.

Përveç kësaj, enkriptimi nuk është një plumb argjendi që zgjith çdo problem. 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 administratorët e sistemit.

Kur ka njĂ« çelĂ«s pĂ«r tĂ« gjithĂ« kolonĂ«n pĂ«r tĂ« gjithĂ« pĂ«rdoruesit (edhe nĂ«se jo pĂ«r tĂ« gjithĂ«, por pĂ«r njĂ« grup tĂ« kufizuar klientĂ«sh), kjo nuk Ă«shtĂ« gjithmonĂ« mirĂ« dhe e drejtĂ«. PikĂ«risht pĂ«r kĂ«tĂ« filluan tĂ« bĂ«jnĂ« enkriptimin end-to-end, nĂ« DBM filluan tĂ« shqyrtojnĂ« mundĂ«sitĂ« e enkriptimit tĂ« dhĂ«nave nga ana e klientit dhe serverit, u shfaqĂ«n ato depozita key-vault — produkte tĂ« veçanta qĂ« ofrojnĂ« menaxhimin e çelĂ«save nga ana e DBM.

Siguria dhe DBMS: çfarë duhet të mbani parasysh kur zgjidhni mjete mbrojtëse
Shembuj të tillë të enkriptimit në MongoDB

Mjetet e sigurisë në DBM komerciale dhe open source

Funksionet
Lloji
Politika e Fjalëkalimit
Auditimi
Mbrojtja e kodit burimor të procedurave dhe funksioneve
RLS
Enkriptimi

Oracle
Komerciale
+
+
+
+
+

MsSql
Komerciale
+
+
+
+
+

Jatoba
Komerciale
+
+
+
+
zgjerime

PostgreSQL
Falë
zgjerime
zgjerime
—
+
zgjerime

MongoDb
Falë
—
+
—
—
E disponueshme vetëm në MongoDB Enterprise

Tabela nuk Ă«shtĂ« aspak e plotĂ«, por situata Ă«shtĂ« kjo: nĂ« produktet komerciale, problemet e sigurisĂ« janĂ« zgjidhur prej kohĂ«sh, nĂ« open source, zakonisht pĂ«r sigurinĂ« pĂ«rdorin disa shtesa, shumĂ« funksione mungojnĂ«, ndonjĂ«herĂ« duhet tĂ« shkruash diçka. PĂ«r shembull, politikat e fjalĂ«kalimeve — nĂ« PostgreSQL ka shumĂ« zgjerime tĂ« ndryshme1, 2, 3, 4, 5), tĂ« cilat zbatojnĂ« politika passwordi, por tĂ« gjitha nevojat e segmentit tĂ« brendshĂ«m korporativ, sipas mendimit tim, asnjĂ« nuk e mbulon.

ÇfarĂ« tĂ« bĂ«ni, nĂ«se nuk ka gjĂ«kundi atĂ« qĂ« nevojitet? ĐĐ°ĐżŃ€ĐžĐŒĐ”Ń€, Ń…ĐŸŃ‡Đ”Ń‚ŃŃ ĐžŃĐżĐŸĐ»ŃŒĐ·ĐŸĐČать ĐŸĐżŃ€Đ”ĐŽĐ”Đ»Đ”ĐœĐœŃƒŃŽ СУБД, ĐČ ĐșĐŸŃ‚ĐŸŃ€ĐŸĐč ĐœĐ”Ń‚ Ń„ŃƒĐœĐșцоĐč, ĐșĐŸŃ‚ĐŸŃ€Ń‹Đ” Ń‚Ń€Đ”Đ±ŃƒĐ”Ń‚ Đ·Đ°ĐșазчОĐș.

Atëherë mund të përdorni zgjidhje të palëve të treta, të cilat funksionojnë me DBMS të ndryshme, për shembull, "Kripto DB" ose "Garda DB". Nëse flasim për zgjidhje nga segmenti i brendshëm, atje dinë më mirë për GOST-të sesa në open source.

Opsioni i dytĂ« — tĂ« shkruani vetĂ« atĂ« qĂ« nevojitet, tĂ« realizoni nĂ« nivelin e procedurave qasje nĂ« tĂ« dhĂ«na dhe enkriptimin nĂ« aplikacion. E vĂ«rteta, me GOST-in do tĂ« jetĂ« mĂ« e vĂ«shtirĂ«. Por nĂ« pĂ«rgjithĂ«si — mund tĂ« fshihni tĂ« dhĂ«nat, ashtu siç duhet, t’i vendosni nĂ« DBMS, pastaj t’i merrni dhe t’i dekoloni si duhet, drejtpĂ«rdrejt 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 tĂ« bĂ«het nĂ« nivelin e DBMS, sepse kĂ«shtu do tĂ« punojĂ« mĂ« shpejt.

Ky raport u paraqit për herë të parë në @Databases Meetup nga Mail.ru Cloud Solutions. Shikoni video prezentime të tjera dhe abonohuni në njoftimet e ngjarjeve në Telegram Rreth Kubernetes në Mail.ru Group.

ÇfarĂ« tjetĂ«r tĂ« lexoni mbi kĂ«tĂ« temĂ«:

  1. Më shumë se Ceph: ruajtja bllok e cloud-it MCS.
  2. Si të zgjidhni një bazë të dhënash për projektin, që të mos zgjidhni përsëri.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster