🥇Securitate și SGBD: despre ce trebuie să ținem cont când alegem soluțiile de protecție

Mă numesc Denis Roșcov, sunt șeful dezvoltării software la compania „Gazinformservis”, în echipa de produs. Jatoba. Legislația și normele corporative impun anumite cerințe pentru securitatea stocării datelor. Nimeni nu își dorește ca terțe părți să aibă acces la informații confidențiale, așa că pentru orice proiect sunt importante următoarele întrebări: identificarea și autentificarea, gestionarea accesului la date, asigurarea integrității informațiilor în sistem, înregistrarea evenimentelor de securitate. Prin urmare, vreau să împărtășesc câteva aspecte interesante legate de securitatea SGBD-ului.

Articolul a fost pregătit pe baza unei prezentări la @Databases Meetup, organizată Soluții Cloud Mail.ru. Dacă nu doriți să citiți, puteți viziona:

Articolul va conține trei părți:

Cum să protejezi conexiunile.
Ce este auditul acțiunilor și cum să înregistrezi ce se întâmplă din partea bazei de date și a conexiunii la aceasta.
Cum să protejezi datele din baza de date în sine și ce tehnologii există pentru aceasta.

Cele trei componente ale securității SGBD-ului: protecția conexiunilor, auditul acțiunilor și protecția datelor.

Protecția conexiunilor

Conectarea la baza de date se poate face atât direct, cât și indirect prin aplicații web. De obicei, utilizatorul din partea afacerii, adică persoana care lucrează cu SGBD-ul, interacționează cu acesta nu direct.

Înainte de a discuta despre protecția conexiunilor, trebuie să răspundem la întrebări importante, de la care depinde cum vor fi structurate măsurile de securitate:

este echivalent un utilizator de afaceri cu un utilizator al SGBD-ului;
accesul la datele SGBD-ului este asigurat doar prin API-ul pe care îl controlezi, sau există acces direct la tabele;
SGBD-ul este izolat într-un segment protejat, cine și cum interacționează cu acesta;
se folosește pooling/proxy și straturi intermediare care pot modifica informațiile despre cum este structurat conectarea și cine utilizează baza de date.

Acum să vedem ce instrumente pot fi aplicate pentru protecția conexiunilor:

Utilizați soluții de tip firewall pentru baze de date. Un strat suplimentar de protecție, cel puțin, va crește transparența a ceea ce se întâmplă în SGBD, la maximum — veți putea oferi o protecție suplimentară a datelor.
Utilizați politicile de parolă. Aplicarea acestora depinde de modul în care este construită arhitectura dumneavoastră. În orice caz, o singură parolă în fișierul de configurare al aplicației web, care se conectează la baza de date, nu este suficientă pentru protecție. Există o serie de instrumente pentru baze de date care permit controlul asupra faptului că utilizatorul și parola necesită actualizare.
Puteți citi mai multe despre funcțiile de evaluare a utilizatorilor aici, de asemenea, puteți afla despre MS SQL Vulnerability Assessment aici.
Îmbogățiți contextul sesiunii cu informațiile necesare. Dacă sesiunea nu este transparentă, nu înțelegeți cine lucrează în cadrul acesteia în baza de date; puteți completa informațiile despre cine, ce și de ce face, în cadrul operațiunii efectuate. Aceste informații pot fi văzute în audit.
Configurați SSL dacă nu aveți o separare a rețelei database de utilizatorii finali, nu este într-un VLAN separat. În astfel de cazuri, este esențial să protejați canalul între consumator și baza de date însăși. Există instrumente de protecție, inclusiv între cele open source.

Cum va afecta aceasta performanța bazei de date?

Să ne uităm la exemplul PostgreSQL pentru a observa cum SSL influențează încărcarea CPU, creșterea timpurilor de reacție și scăderea TPS, pentru a verifica dacă nu se vor consuma prea multe resurse atunci când este activat.

Încărcăm PostgreSQL folosind pgbench - acesta este un program simplu pentru rularea testelor de performanță. Acesta execută repetat o secvență de comenzi, posibil în sesiuni paralele ale bazei de date, și apoi calculează viteza medie a tranzacțiilor.

Test 1 fără SSL și cu utilizarea SSL — conexiunea este stabilită la 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"

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

Test 2 fără SSL și cu utilizarea 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"

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

Alte setări:

factori de scalare: 1
mod de interogare: simplu
număr de clienți: 10
număr de fire: 1
număr de tranzacții per client: 5000
număr de tranzacții efectiv procesate: 50000/50000

Rezultatele testării:

FĂRĂ SSL
SSL

Conexiunea este stabilită la fiecare tranzacție

latency medie
171.915 ms
187.695 ms

tps inclusiv stabilirea conexiunilor
58.168112
53.278062

tps excluzând stabilirea conexiunilor
64.084546
58.725846

CPU
24%
28%

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

latency medie
6.722 ms
6.342 ms

tps inclusiv stabilirea conexiunilor
1587.657278
1576.792883

tps excluzând stabilirea conexiunilor
1588.380574
1577.694766

CPU
17%
21%

În cazul unor sarcini mici, influența SSL este comparabilă cu eroarea de măsurare. Dacă volumul de date transmise este foarte mare, situația poate fi diferită. Dacă stabilim o conexiune pentru fiecare tranzacție (ceea ce se întâmplă rar, de obicei conexiunea este partajată între utilizatori), aveți un număr mare de conectări/deconectări, influența poate fi puțin mai mare. Asta înseamnă că există riscuri de scădere a performanței, însă diferența nu este atât de mare încât să nu se folosească protecția.

Rețineți că există o diferență semnificativă atunci când comparăm modurile de operare: în cadrul unei sesiuni lucrați sau în sesiuni diferite. Acest lucru este evident: resurse sunt consumate pentru crearea fiecărei conexiuni.

Am avut un caz în care am conectat Zabbix în modul trust, adică nu am verificat md5, nu a fost necesară autentificarea. Apoi clientul a solicitat activarea modului de autentificare md5. Acesta a generat o mare sarcină pe CPU, iar performanța a scăzut. Am căutat soluții de optimizare. Una dintre posibilele soluții ale problemei este implementarea unei restricții de rețea, crearea unor VLAN-uri separate pentru SGBD, adăugarea de setări pentru a înțelege cine și de unde se conectează și eliminarea autentificării. De asemenea, se pot optimiza setările de autentificare pentru a reduce costurile în activarea autentificării, dar în general utilizarea diverselor metode de autentificare influențează performanța și necesită să ținem cont de acești factori în proiectarea puterii de calcul a serverelor (hardware) pentru SGBD.

Concluzie: în unele soluții, chiar și nuanțele minore în autentificare pot influența semnificativ proiectul și este rău când acest lucru devine evident doar în timpul implementării în producție.

Auditoriatul acțiunilor

Auditoriatul nu poate fi doar pentru SGBD. Auditoriatul este obținerea de informații despre ceea ce se întâmplă în diferite segmente. Acesta poate fi și un firewall de bază de date, și sistemul de operare pe care se construiește SGBD-ul.

În SGBD-urile comerciale de nivel Enterprise, auditoriatul este bine implementat, în open source – nu întotdeauna. Iată ce există în PostgreSQL:

logul implicit – logare încorporată;
extensii: pgaudit – dacă vă lipsesc funcțiile de logare implicite, puteți utiliza setări separate care rezolvă parte din probleme.

Complemet la raport în video:

Înregistrarea de bază a operatorilor poate fi asigurată printr-un instrument standard de înregistrare cu log_statement = all.

Aceasta este acceptabilă pentru monitorizare și alte utilizări, dar nu oferă nivelul de detaliere de care are nevoie de obicei un audit.

Nu este suficient să ai o listă cu toate operațiunile efectuate asupra bazei de date.

De asemenea, ar trebui să existe posibilitatea de a găsi afirmațiile specifice care sunt de interes pentru auditor.

Instrumentul standard de înregistrare arată ceea ce a solicitat utilizatorul, în timp ce pgAudit se concentrează pe detaliile a ceea ce s-a întâmplat atunci când baza de date a executat cererea.

De exemplu, auditorul ar putea dori să se asigure că o tabelă specifică a fost creată într-o fereastră de întreținere documentată.

Aceasta poate părea o sarcină simplă pentru un audit de bază și grep, dar ce se întâmplă dacă primești ceva asemănător (intentionally confuz) exemplului:

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

Înregistrarea standard îți va oferi aceasta:

LOG: statement: DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;

Pare că pentru a găsi tabela de interes ar putea fi necesare cunoștințe de cod în cazurile în care tabelele sunt create dinamic.

Acest lucru nu este ideal, deoarece ar fi preferabil să cauți pur și simplu după numele tabelei.

Aici pgAudit va fi util.

Pentru aceeași intrare, acesta va genera următoarea ieșire în jurnal:

AUDIT: SESSION,33,1,FUNCTION,DO,,,«DO $$
BEGIN
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)

Se înregistrează nu doar blocul DO, ci și textul complet CREATE TABLE cu tipul de operator, tipul de obiect și numele complet, ceea ce facilitează căutarea.

Înregistrând operatorii SELECT și DML, pgAudit poate fi configurat pentru a înregistra o intrare separată pentru fiecare relație la care se face referire în operator.

Nu este necesară analiza sintaxei pentru a găsi toți operatorii care se referă la o tabelă specifică (*)».

Cum va afecta aceasta performanța bazei de date?

Să facem teste cu activarea auditului complet și să vedem ce se va întâmpla cu performanța PostgreSQL. Vom activa logarea maximă a bazei de date pentru toate parametrii.

În fișierul de configurare nu schimbăm aproape nimic, din ce este important – activăm modul debug5 pentru a obține cele mai multe informații.

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'

Pe baza SGBD PostgreSQL cu parametrii 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, se efectuează trei teste de stres 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 testării:

Fără logare
Cu logare

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

RAM
24%
40%

CPU
72%
91%

Test 1 (50 conexiuni)

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

Tranzacții/sec
123
54

Întârzierea medie
405 ms
925 ms

Test 2 (150 conexiuni la 100 posibile)

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

Tranzacții/sec
136
52

Întârzierea medie
550 ms
1432 ms

Despre dimensiuni

Dimensiunea bazei de date
2251 MB
2262 MB

Dimensiunea jurnalelor bazei de date
0 MB
4587 MB

În concluzie: auditarea completă nu este foarte bună. Volumul de date provenit din audit va fi echivalent cu cel din baza de date însăși, sau chiar mai mare. Un asemenea volum de logare generat în timpul utilizării SGBD-ului este o problemă obișnuită în producție.

Să ne uităm la alte parametrii:

Viteza nu se schimbă semnificativ: fără logare — 43,74 sec, cu logare — 53,23 sec.
Performanța RAM și CPU va cădea, deoarece este necesar să se genereze un fișier cu audit. Aceasta se observă și în producție.

Pe măsură ce numărul de conexiuni crește, desigur, parametrii se vor deteriora ușor.

În corporații, auditul este și mai complicat:

sunt multe date;
auditul este necesar nu doar prin syslog în SIEM, ci și în fișiere: în caz că syslog se defectează, trebuie să existe un fișier aproape de bază în care să fie stocate datele;
pentru audit este nevoie de un raft aparte pentru a nu afecta I/O-ul discurilor, deoarece ocupă mult spațiu;
se întâmplă ca angajații de securitate a informației să necesite norme GOST, cerând identificarea conform acestor standarde.

Restricționarea accesului la date

Să vedem tehnologiile utilizate pentru protejarea datelor și accesul la ele în SGBD comerciale și open source.

Ce poate fi utilizat în general:

Criptarea și obfuscarea procedurilor și funcțiilor (Wrapping) — adică instrumente și utilitare separate care transformă codul citibil în cod ilizibil. Cu toate acestea, ulterior nu mai poate fi modificat sau refactorizat înapoi. Această abordare este uneori necesară cel puțin la nivelul SGBD-ului — logica restricțiilor de licență sau logica autorizării este criptată exact la nivelul procedurilor și funcțiilor.
Restricția vizibilității datelor pe rânduri (RLS) este atunci când utilizatori diferiți văd aceeași tabelă, dar cu un conținut diferit de rânduri, adică unor persoane nu li se pot afișa anumite informații la nivel de rând.
Editarea datelor afișate (Masking) se referă la situația în care utilizatorii dintr-o coloană a tabelei văd fie datele, fie doar asteriscuri, adică unele informații vor fi ascunse pentru anumiți utilizatori. Tehnologia determină ce utilizatorilor le este afișat pe baza nivelului de acces.
Restricționarea accesului Security DBA/Application DBA/DBA se referă, mai degrabă, la limitarea accesului la baza de date, adică angajații de securitate pot fi separați de administratorii bazei de date și de administratorii aplicațiilor. În open source, aceste tehnologii sunt rare, dar sunt suficient de comune în bazele de date comerciale. Ele sunt necesare atunci când există mulți utilizatori cu acces la serverele în sine.
Restricția accesului la fișiere la nivelul sistemului de fișiere. Se pot acorda drepturi, privilegii de acces la directoare, astfel încât fiecare administrator să aibă acces doar la datele necesare.
Accesul mandatar și curățarea memoriei sunt tehnologii care sunt utilizate rar.
Criptarea end-to-end a bazei de date se referă la criptarea pe partea clientului cu gestionarea cheilor pe partea serverului.
Criptarea datelor. De exemplu, criptarea pe coloană este atunci când folosiți un mecanism care criptează o coloană separată a bazei de date.

Cum afectează asta performanța bazei de date?

Să ne uităm la exemplul criptării pe coloană în PostgreSQL. Acolo există modulul pgcrypto, care permite stocarea unor câmpuri selectate în format criptat. Acest lucru este util atunci când doar anumite date au valoare. Pentru a citi câmpurile criptate, clientul trimite cheia de decriptare, serverul decriptează datele și le returnează clientului. Fără cheie, nimeni nu va putea accesa datele dumneavoastră.

Să facem un test cu pgcrypto. Vom crea o tabelă cu date criptate și cu date normale. Mai jos sunt comenzile pentru crearea tabelelor; în prima linie se află o comandă utilă – crearea extensiei cu înregistrarea bazei de date:

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'));

Apoi vom încerca să facem o selecție de date din fiecare tabel și să analizăm timpii de executare.

Selecția din tabel fără funcția 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 de rânduri)

Timp: 1,386 ms

Selecția din tabel cu funcția 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 | decrypt | decrypt
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
…
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 de rânduri)

Timp: 50,203 ms

Rezultatele testării:

Fără criptare
Pgcrypto (decrypt)

Selecția 1000 de rânduri
1,386 ms
50,203 ms

CPU
15%
35%

RAM

+5%

Criptarea afectează semnificativ performanța. Se observă că timpul a crescut, deoarece operațiile de decriptare a datelor criptate (iar decriptarea este de obicei învelită în logica dumneavoastră) necesită resurse semnificative. Astfel, ideea de a cripta toate coloanele care conțin date este predispusă la o scădere a performanței.

În același timp, criptarea nu este o panacee care să rezolve toate problemele. Datele decriptate și cheia de decriptare se află pe server în timpul decriptării și transmiterii datelor. Prin urmare, cheile pot fi interceptate de cei care au acces complet la serverul de baze de date, de exemplu, de un administrator de sistem.

Când pentru întreaga coloană toți utilizatorii au o singură cheie (chiar dacă nu pentru toți, ci pentru clienți dintr-un set restrâns), aceasta nu este întotdeauna benefică și corectă. Din acest motiv s-au început implementările de criptare end-to-end; în SGBD-uri au fost explorate opțiuni de criptare a datelor din partea clientului și serverului, fiind dezvoltate acele soluții de tip key-vault — produse separate care asigură gestionarea cheilor din partea SGBD-ului.

Un exemplu de criptare în MongoDB

Mijloace de securitate în SGBD-uri comerciale și open source

Functions
Tip
Politica de Parole
Audit
Protecția codului sursă al procedurilor și funcțiilor
RLS
Criptare

Oracle
Comercial
+
+
+
+
+

MsSql
Comercial
+
+
+
+
+

Jatoba
Comercial
+
+
+
+
extensii

PostgreSQL
Gratuit
extensii
extensii
—
+
extensii

MongoDb
Gratuit
—
+
—
—
Disponibil în MongoDB Enterprise doar

Tabelul nu este deloc complet, dar situația este aceasta: în produsele comerciale problemele de securitate au fost rezolvate de mult, în open source, de regulă, pentru securitate se folosesc diverse extensii, lipsesc multe funcții, uneori trebuie să se adauge ceva. De exemplu, politicile de parole — în PostgreSQL există multe extensii diferite.1, 2, 3, 4, 5), care implementează politici de parole, dar toate nevoile sectorului corporativ autohton, după părerea mea, niciuna nu le acoperă.

Ce să faci dacă nu găsești ceea ce ai nevoie?? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Atunci poți folosi soluții externe care funcționează cu diferite SGBD-uri, de exemplu, „Crypto DB” sau „Garda DB”. Dacă este vorba despre soluții din sectorul autohton, acolo cunosc mai bine standardele GOST decât în open source.

A doua variantă este să scrii tu însuți ceea ce ai nevoie, implementând la nivel de proceduri accesul la date și criptarea în aplicație. Totuși, cu GOST va fi mai complicat. Dar în general, poți ascunde datele așa cum trebuie, le poți stoca în SGBD, apoi le poți extrage și decripta așa cum este necesar, chiar la nivelul aplicației. În același timp, gândește-te cum vei proteja aceste algoritmi la nivel de aplicație. După părerea noastră, acest lucru ar trebui să se întâmple la nivel de SGBD, deoarece așa va funcționa mai repede.

Această prezentare a avut loc pentru prima dată la @Databases Meetup de la Mail.ru Cloud Solutions. Vezi video alte prezentări și abonează-te la anunțurile evenimentelor în Telegram În jurul Kubernetes în Mail.ru Group.

What else to read on the topic:

Sursa: habr.com