Numele meu este Denis Rozhkov, sunt șeful de dezvoltare software la compania Gazinformservice, în echipa de produse jatoba. Legislația și reglementările corporative impun anumite cerințe pentru securitatea stocării datelor. Nimeni nu dorește ca terți să obțină acces la informații confidențiale, așa că următoarele aspecte sunt importante pentru orice proiect: identificarea și autentificarea, gestionarea accesului la date, asigurarea integrității informațiilor din sistem, înregistrarea evenimentelor de securitate. Prin urmare, vreau să vorbesc despre câteva puncte interesante privind securitatea DBMS.

Articolul a fost pregătit pe baza unui discurs la @DatabasesMeetup, organizat Mail.ru Cloud Solutions. Dacă nu vrei să citești, poți urmări:

Articolul va avea trei părți:

• Cum securizați conexiunile.
• Ce este un audit al acțiunilor și cum să înregistrați ceea ce se întâmplă pe partea bazei de date și cum să vă conectați la aceasta.
• Cum să protejați datele din baza de date în sine și ce tehnologii sunt disponibile pentru aceasta.

Trei componente ale securității DBMS: protecția conexiunii, auditarea activității și protecția datelor

Asigurați-vă conexiunile

Vă puteți conecta la baza de date direct sau indirect prin intermediul aplicațiilor web. De regulă, utilizatorul de afaceri, adică persoana care lucrează cu SGBD, interacționează indirect cu acesta.

Înainte de a vorbi despre protejarea conexiunilor, trebuie să răspundeți la întrebări importante care determină modul în care vor fi structurate măsurile de securitate:

• Este un utilizator de afaceri echivalent cu un utilizator DBMS?
• dacă accesul la datele DBMS este oferit numai printr-un API pe care îl controlați sau dacă tabelele sunt accesate direct;
• dacă SGBD este alocat unui segment protejat separat, cine interacționează cu acesta și cum;
• dacă se utilizează pooling/proxy și straturile intermediare, care pot schimba informații despre cum este construită conexiunea și cine folosește baza de date.

Acum să vedem ce instrumente pot fi folosite pentru a securiza conexiunile:

1. Utilizați soluții de clasă firewall pentru baze de date. Un strat suplimentar de protecție va crește, cel puțin, transparența a ceea ce se întâmplă în DBMS și, la maximum, veți putea oferi protecție suplimentară a datelor.
2. Folosiți politicile de parole. Utilizarea lor depinde de modul în care este construită arhitectura dvs. În orice caz, o singură parolă din fișierul de configurare al unei aplicații web care se conectează la DBMS nu este suficientă pentru protecție. Există o serie de instrumente DBMS care vă permit să controlați dacă utilizatorul și parola necesită actualizare.

   Puteți citi mai multe despre funcțiile de evaluare a utilizatorilor aici, puteți afla și despre MS SQL Vulnerability Assessmen aici. 

3. Îmbogățiți contextul sesiunii cu informațiile necesare. Dacă sesiunea este opacă, nu înțelegeți cine lucrează în SGBD în cadrul acestuia, puteți, în cadrul operațiunii efectuate, să adăugați informații despre cine face ce și de ce. Aceste informații pot fi văzute în audit.
4. Configurați SSL dacă nu aveți o separare de rețea între DBMS și utilizatorii finali; nu este într-un VLAN separat. În astfel de cazuri, este imperativ să se protejeze canalul dintre consumator și DBMS însuși. Instrumentele de securitate sunt disponibile și în sursă deschisă.

Cum va afecta acest lucru performanța DBMS?

Să ne uităm la exemplul PostgreSQL pentru a vedea cum SSL afectează încărcarea procesorului, crește timpul și scade TPS și dacă va consuma prea multe resurse dacă îl activați.

Încărcarea PostgreSQL folosind pgbench este un program simplu pentru rularea testelor de performanță. Execută o singură secvență de comenzi în mod repetat, eventual în sesiuni paralele de baze de date, apoi calculează rata medie de tranzacție.

Testul 1 fără SSL și folosind SSL — se stabilește legătura pentru fiecare tranzacție:

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"

Testul 2 fără SSL și folosind SSL — toate tranzacțiile sunt efectuate într-o singură conexiune:

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"

Alte setari:

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

Rezultatele testelor:

 
FĂRĂ SSL
SSL

Se stabilește o conexiune pentru fiecare tranzacție

medie de latență
171.915 ms
187.695 ms

tps inclusiv stabilirea conexiunilor
58.168112
53.278062

tps excluzând stabilirea conexiunilor
64.084546
58.725846

Procesor
24%
28%

Toate tranzacțiile sunt efectuate într-o singură conexiune

medie de latență
6.722 ms
6.342 ms

tps inclusiv stabilirea conexiunilor
1587.657278
1576.792883

tps excluzând stabilirea conexiunilor
1588.380574
1577.694766

Procesor
17%
21%

La sarcini ușoare, influența SSL este comparabilă cu eroarea de măsurare. Dacă cantitatea de date transferate este foarte mare, situația poate fi diferită. Dacă stabilim o singură conexiune per tranzacție (acest lucru este rar, de obicei conexiunea este partajată între utilizatori), aveți un număr mare de conexiuni/deconectări, impactul poate fi puțin mai mare. Adică pot exista riscuri de scădere a performanței, însă diferența nu este atât de mare încât să nu folosească protecție.

Vă rugăm să rețineți că există o diferență puternică dacă comparați modurile de operare: lucrați în cadrul aceleiași sesiuni sau în altele diferite. Acest lucru este de înțeles: resursele sunt cheltuite pentru crearea fiecărei conexiuni.

Am avut un caz când am conectat Zabbix în modul de încredere, adică md5 nu a fost verificat, nu a fost nevoie de autentificare. Apoi clientul a cerut să activeze modul de autentificare md5. Acest lucru a pus o sarcină mare asupra procesorului, iar performanța a scăzut. Am început să căutăm modalități de optimizare. Una dintre posibilele soluții la problemă este implementarea restricțiilor de rețea, crearea de VLAN-uri separate pentru DBMS, adăugarea de setări pentru a clarifica cine se conectează de unde și eliminarea autentificării.De asemenea, puteți optimiza setările de autentificare pentru a reduce costurile atunci când activați autentificarea, dar în general, utilizarea diferitelor metode de autentificare afectează performanța și necesită luarea în considerare a acestor factori la proiectarea puterii de calcul a serverelor (hardware) pentru SGBD.

Concluzie: într-o serie de soluții, chiar și micile nuanțe de autentificare pot afecta foarte mult proiectul și este rău când acest lucru devine clar doar atunci când este implementat în producție.

Audit de acțiune

Auditul poate fi nu numai DBMS. Un audit se referă la obținerea de informații despre ceea ce se întâmplă în diferite segmente. Acesta poate fi fie un firewall de bază de date, fie sistemul de operare pe care este construit SGBD.

În SGBD-urile comerciale la nivel Enterprise, totul este în regulă cu auditarea, dar în sursă deschisă - nu întotdeauna. Iată ce are PostgreSQL:

• jurnal implicit - înregistrare încorporată;
• extensii: pgaudit - dacă înregistrarea implicită nu este suficientă pentru dvs., puteți utiliza setări separate care rezolvă unele probleme.

Adăugare la raport în videoclip:

„Înregistrarea de bază a declarațiilor poate fi furnizată de o facilitate standard de înregistrare cu log_statement = all.

Acest lucru este acceptabil pentru monitorizare și alte utilizări, dar nu oferă nivelul de detaliu necesar de obicei pentru audit.

Nu este suficient să aveți o listă cu toate operațiunile efectuate pe baza de date.

De asemenea, ar trebui să fie posibil să se găsească declarații specifice care sunt de interes pentru auditor.

Înregistrarea standard arată ce a cerut utilizatorul, în timp ce pgAudit se concentrează pe detaliile a ceea ce s-a întâmplat când baza de date a executat interogarea.

De exemplu, auditorul poate dori să verifice dacă un anumit tabel a fost creat într-o fereastră de întreținere documentată.

Aceasta poate părea o sarcină simplă cu auditare de bază și grep, dar ce ar fi dacă vi s-ar prezenta ceva ca acest exemplu (intenționat confuz):

DO$$
ÎNCEPE
EXECUTĂ „CREATE TABLE import” || 'ant_table(id int)';
END$$;

Înregistrarea standard vă va oferi următoarele:

LOG: declarație: DO $$
ÎNCEPE
EXECUTĂ „CREATE TABLE import” || 'ant_table(id int)';
END$$;

Se pare că găsirea tabelului de interes poate necesita anumite cunoștințe de cod în cazurile în care tabelele sunt create dinamic.

Acest lucru nu este ideal, deoarece ar fi de preferat să căutați pur și simplu după numele tabelului.

Aici este locul în care pgAudit este util.

Pentru aceeași intrare, va produce această ieșire în jurnal:

AUDIT: SESIUNEA,33,1,FUNȚIA,DO,,,"DO $$
ÎNCEPE
EXECUTĂ „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)

Nu numai blocul DO este înregistrat, ci și textul complet al CREATE TABLE cu tipul instrucțiunii, tipul obiectului și numele complet, ușurând căutarea.

Când se înregistrează instrucțiuni SELECT și DML, pgAudit poate fi configurat să înregistreze o intrare separată pentru fiecare relație la care se face referire în instrucțiune.

Nu este necesară analizarea pentru a găsi toate declarațiile care ating un anumit tabel (*) ».

Cum va afecta acest lucru performanța DBMS?

Să rulăm teste cu auditarea completă activată și să vedem ce se întâmplă cu performanța PostgreSQL. Să activăm înregistrarea maximă a bazei de date pentru toți parametrii.

Nu schimbăm aproape nimic în fișierul de configurare, cel mai important lucru este să pornim modul debug5 pentru a obține maximum de informații.

postgresql.conf

log_destination = 'stderr'
logging_collector = activat
log_truncate_on_rotation = activat
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages = depanare5
log_min_error_statement = depanare5
log_min_duration_statement = 0
debug_print_parse = activat
debug_print_rewritten = activat
debug_print_plan = activat
debug_pretty_print = activat
log_checkpoints = activat
log_connections = activat
log_disconnections = pornit
log_duration = pornit
log_hostname = activat
log_lock_waits = pornit
log_replication_commands = activat
log_temp_files = 0
log_timezone = „Europa/Moscova”

Pe un DBMS PostgreSQL cu parametri de 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, efectuăm trei teste de încărcare folosind comenzile:

$ 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

Rezultatele testului:

Fără înregistrare
Cu logare

Timp total de umplere a bazei de date
43,74 sec
53,23 sec

RAM
24%
40%

Procesor
72%
91%

Testul 1 (50 de conexiuni)

Numărul de tranzacții în 10 minute
74169
32445

Tranzacții/sec
123
54

Latența medie
405 ms
925 ms

Testul 2 (150 de conexiuni cu 100 posibile)

Numărul de tranzacții în 10 minute
81727
31429

Tranzacții/sec
136
52

Latența medie
550 ms
1432 ms

Despre dimensiuni

Dimensiunea DB
2251 MB
2262 MB

Dimensiunea jurnalului bazei de date
0 Мб
4587 Мб

Concluzia: un audit complet nu este foarte bun. Datele din audit vor fi la fel de mari ca și datele din baza de date în sine, sau chiar mai mult. Cantitatea de jurnalizare care este generată atunci când lucrați cu un SGBD este o problemă comună în producție.

Să ne uităm la alți parametri:

• Viteza nu se schimbă mult: fără înregistrare - 43,74 secunde, cu înregistrare - 53,23 secunde.
• Performanța RAM și CPU va avea de suferit, deoarece trebuie să generați un fișier de audit. Acest lucru este vizibil și în productivitate.

Pe măsură ce numărul de conexiuni crește, desigur, performanța se va deteriora ușor.

În corporațiile cu audit este și mai dificil:

• sunt multe date;
• auditarea este necesară nu numai prin syslog în SIEM, ci și în fișiere: dacă se întâmplă ceva cu syslog, trebuie să existe un fișier aproape de baza de date în care sunt salvate datele;
• este necesar un raft separat pentru auditare pentru a nu irosi discuri I/O, deoarece ocupă mult spațiu;
• Se întâmplă că angajații de securitate a informațiilor au nevoie de standarde GOST peste tot, au nevoie de identificare de stat.

Restricționarea accesului la date

Să ne uităm la tehnologiile care sunt utilizate pentru a proteja datele și pentru a le accesa în SGBD-uri comerciale și open source.

Ce poți folosi în general:

1. Criptarea și înfundarea procedurilor și funcțiilor (Wrapping) - adică instrumente și utilitare separate care fac codul lizibil să nu fie citit. Adevărat, atunci nu poate fi nici schimbat, nici refactorizat înapoi. Această abordare este uneori necesară cel puțin pe partea DBMS - logica restricțiilor de licență sau logica de autorizare este criptată exact la nivel de procedură și funcție.
2. Limitarea vizibilității datelor după rânduri (RLS) este atunci când diferiți utilizatori văd un tabel, dar o compoziție diferită a rândurilor din acesta, adică ceva nu poate fi afișat cuiva la nivel de rând.
3. Editarea datelor afișate (mascare) este atunci când utilizatorii dintr-o coloană a tabelului văd fie date, fie doar asteriscuri, adică pentru unii utilizatori informațiile vor fi închise. Tehnologia determină cărui utilizator i se arată în funcție de nivelul de acces.
4. Securitate DBA/Aplicație Controlul accesului DBA/DBA se referă, mai degrabă, la restricționarea accesului la DBMS în sine, adică angajații de securitate a informațiilor pot fi separați de administratorii bazelor de date și administratorii de aplicații. Există puține astfel de tehnologii în sursă deschisă, dar există o mulțime de ele în DBMS-urile comerciale. Sunt necesare atunci când există mulți utilizatori cu acces la serverele înșiși.
5. Restricționarea accesului la fișiere la nivel de sistem de fișiere. Puteți acorda drepturi și privilegii de acces directoare, astfel încât fiecare administrator să aibă acces doar la datele necesare.
6. Acces obligatoriu și ștergerea memoriei - aceste tehnologii sunt rar utilizate.
7. Criptarea end-to-end direct din DBMS este criptare la nivelul clientului cu managementul cheilor pe partea serverului.
8. Criptarea datelor. De exemplu, criptarea coloanei este atunci când utilizați un mecanism care criptează o singură coloană a bazei de date.

Cum afectează acest lucru performanța DBMS?

Să ne uităm la exemplul de criptare coloană în PostgreSQL. Există un modul pgcrypto, care vă permite să stocați câmpurile selectate în formă criptată. Acest lucru este util atunci când doar unele date sunt valoroase. Pentru a citi câmpurile criptate, clientul transmite o cheie de decriptare, serverul decriptează datele și le returnează clientului. Fără cheie, nimeni nu poate face nimic cu datele tale.

Să testăm cu pgcrypto. Să creăm un tabel cu date criptate și date obișnuite. Mai jos sunt comenzile pentru crearea tabelelor, în prima linie există o comandă utilă - crearea extensiei în sine cu înregistrarea 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'));

În continuare, să încercăm să facem un eșantion de date din fiecare tabel și să ne uităm la timpii de execuție.

Selectarea dintr-un tabel fără funcție de criptare:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

Cronometrul este pornit.

  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 linii)

Timp: 1,386 ms

Selectare dintr-un tabel cu funcție de criptare:

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

Cronometrul este pornit.

  id | decripta | decriptează
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 linii)

Timp: 50,203 ms

Rezultatele testelor:

 
Fără criptare
Pgcrypto (decriptare)

Eșantion de 1000 de rânduri
1,386 ms
50,203 ms

Procesor
15%
35%

RAM
 
+ 5%

Criptarea are un impact mare asupra performanței. Se poate observa că timpul a crescut, deoarece operațiunile de decriptare a datelor criptate (și decriptarea este, de obicei, încă cuprinsă în logica dvs.) necesită resurse semnificative. Adică, ideea de a cripta toate coloanele care conțin unele date este plină de o scădere a performanței.

Cu toate acestea, criptarea nu este un glonț de argint care rezolvă toate problemele. Datele decriptate și cheia de decriptare în timpul procesului de decriptare și transmitere a datelor sunt localizate pe server. Prin urmare, cheile pot fi interceptate de cineva care are acces deplin la serverul bazei de date, cum ar fi un administrator de sistem.

Când există o cheie pentru întreaga coloană pentru toți utilizatorii (chiar dacă nu pentru toți, dar pentru clienții unui set limitat), aceasta nu este întotdeauna bună și corectă. De aceea au început să facă criptare end-to-end, în DBMS au început să ia în considerare opțiunile de criptare a datelor pe partea de client și server și au apărut aceleași depozite de chei-seif - produse separate care asigură managementul cheilor pe DBMS latură.

Un exemplu de astfel de criptare în MongoDB

Caracteristici de securitate în SGBD comercial și open source

Funcții
Tip
Politica privind parolele
De audit
Protejarea codului sursă al procedurilor și funcțiilor
RLS
Criptare

Oracol
comercial
+
+
+
+
+

MsSql
comercial
+
+
+
+
+

jatoba
comercial
+
+
+
+
extensii

PostgreSQL
Gratuit
extensii
extensii
-
+
extensii

MongoDb
Gratuit
-
+
-
-
Disponibil numai în MongoDB Enterprise

Tabelul este departe de a fi complet, dar situația este următoarea: în produsele comerciale, problemele de securitate au fost rezolvate de mult timp, în open source, de regulă, se folosesc un fel de suplimente pentru securitate, lipsesc multe funcții , uneori trebuie să adaugi ceva. De exemplu, politicile de parole - PostgreSQL are multe extensii diferite (1, 2, 3, 4, 5), care implementează politici de parole, dar, în opinia mea, niciuna dintre ele nu acoperă toate nevoile segmentului corporativ intern.

Ce să faci dacă nu ai nicăieri ceea ce ai nevoie? De exemplu, doriți să utilizați un anumit SGBD care nu are funcțiile cerute de client.

Apoi puteți utiliza soluții terțe care funcționează cu diferite SGBD, de exemplu, Crypto DB sau Garda DB. Dacă vorbim de soluții din segmentul autohton, atunci ei știu despre GOST-uri mai bine decât în ​​open source.

A doua opțiune este să scrieți singur ceea ce aveți nevoie, să implementați accesul la date și criptarea în aplicație la nivel de procedură. Adevărat, va fi mai dificil cu GOST. Dar, în general, puteți ascunde datele după cum este necesar, le puteți pune într-un SGBD, apoi le puteți prelua și decripta după cum este necesar, chiar la nivelul aplicației. În același timp, gândiți-vă imediat cum veți proteja acești algoritmi în aplicație. În opinia noastră, acest lucru ar trebui făcut la nivel DBMS, pentru că va funcționa mai repede.

Acest raport a fost prezentat pentru prima dată la @Databases Meetup de Mail.ru Cloud Solutions. Uite video alte spectacole și abonați-vă la anunțurile despre evenimente pe Telegram În jurul Kubernetes la Mail.ru Group.

Ce să mai citești pe subiect:

1. Mai mult decât Ceph: stocare în cloud MCS.
2. Cum să alegi o bază de date pentru un proiect, astfel încât să nu fii nevoit să alegi din nou.

Sursa: www.habr.com