🥇Sigurnost i DBMS: Što treba imati na umu pri odabiru sigurnosnih alata

Zovem se Denis Rozhkov, voditelj sam razvoja softvera u Gazinformserviceu, u timu za proizvode. jatobaZakonodavstvo i korporativni propisi nameću određene zahtjeve za sigurnost pohrane podataka. Nitko ne želi da treće strane dobiju pristup povjerljivim informacijama, stoga su sljedeća pitanja važna za svaki projekt: identifikacija i autentifikacija, upravljanje pristupom podacima, osiguravanje integriteta informacija u sustavu i zapisivanje sigurnosnih događaja. Stoga bih želio raspraviti o nekim zanimljivim aspektima sigurnosti DBMS-a.

Članak je pripremljen na temelju govora na @Susret s bazama podataka, organiziran Mail.ru Cloud rješenjaAko ne želite čitati, možete pogledati:

Članak će imati tri dijela:

Kako osigurati veze.
Što je revizija akcija i kako zabilježiti što se događa s bazom podataka i vezom s njom.
Kako zaštititi podatke u samoj bazi podataka i koje su tehnologije dostupne za to.

Tri komponente sigurnosti DBMS-a: sigurnost veze, revizija akcija i zaštita podataka

Zaštita veze

S bazom podataka možete se povezati izravno ili neizravno putem web aplikacija. Poslovni korisnik, odnosno osoba koja radi s DBMS-om, obično s njim komunicira neizravno.

Prije rasprave o sigurnosti veze, važno je odgovoriti na nekoliko važnih pitanja koja će odrediti kako će sigurnosne mjere biti strukturirane:

Je li jedan poslovni korisnik ekvivalentan jednom DBMS korisniku?
Je li pristup DBMS podacima omogućen samo putem API-ja koji vi kontrolirate ili postoji izravan pristup tablicama?
je li DBMS dodijeljen zasebnom zaštićenom segmentu, tko s njim komunicira i kako;
koriste li se slojevi poolinga/proxyja i middlewarea koji mogu promijeniti informacije o tome kako je veza izgrađena i tko koristi bazu podataka.

Sada pogledajmo koji se alati mogu koristiti za osiguranje veza:

Koristite rješenja vatrozida za baze podataka. Ovaj dodatni sloj zaštite će, minimalno, povećati transparentnost onoga što se događa u DBMS-u, a maksimalno, pružiti dodatnu zaštitu podataka.
Koristite pravila za lozinke. Njihova implementacija ovisi o tome kako je izgrađena vaša arhitektura. U svakom slučaju, sama lozinka u konfiguracijskoj datoteci web aplikacije koja se povezuje s DBMS-om nije dovoljna za zaštitu. Brojni DBMS alati omogućuju vam da osigurate da su korisnička imena i lozinke ažurirani.
Više o funkcijama ocjenjivanja korisnika možete pročitati здесьTakođer možete saznati više o procjeni ranjivosti MS SQL-a ovdje.
Obogatite kontekst sesije relevantnim informacijama. Ako je sesija neprozirna i ne razumijete tko radi u DBMS-u unutar nje, možete nadopuniti kontekst izvršene operacije informacijama o tome tko što radi i zašto. Ove informacije mogu se vidjeti u reviziji.
Konfigurirajte SSL ako nemate mrežnu odvojenost između DBMS-a i krajnjih korisnika i ako se ne nalazi na zasebnoj VLAN mreži. U takvim slučajevima bitno je osigurati kanal između korisnika i samog DBMS-a. Dostupni su sigurnosni alati, uključujući i one otvorenog koda.

Kako će ovo utjecati na performanse DBMS-a?

Pogledajmo PostgreSQL kao primjer kako SSL utječe na opterećenje CPU-a, povećava vrijeme odziva i smanjuje TPS te hoće li njegovo omogućavanje potrošiti previše resursa.

Naglašavamo PostgreSQL korištenjem pgbencha, jednostavnog programa za pokretanje testova performansi. On opetovano izvršava jedan niz naredbi, moguće u paralelnim sesijama baze podataka, a zatim izračunava prosječnu brzinu transakcije.

Test 1 bez SSL-a i sa SSL-om — veza se uspostavlja za svaku transakciju:

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 bez SSL-a i sa SSL-om — sve transakcije se izvršavaju u jednoj vezi:

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"

Ostale postavke:

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

Rezultati ispitivanja:

BEZ SSL-a
SSL

Za svaku transakciju uspostavlja se veza.

prosječna latencija
171.915 ms
187.695 ms

tps uključujući uspostavljanje veza
58.168112
53.278062

TPS isključujući uspostavljanje veza
64.084546
58.725846

CPU
24%
28%

Sve transakcije se izvršavaju u jednoj vezi.

prosječna latencija
6.722 ms
6.342 ms

tps uključujući uspostavljanje veza
1587.657278
1576.792883

TPS isključujući uspostavljanje veza
1588.380574
1577.694766

CPU
17%
21%

Pri malim opterećenjima, utjecaj SSL-a usporediv je s pogreškom mjerenja. Ako je količina prenesenih podataka vrlo velika, situacija može biti drugačija. Ako uspostavimo jednu vezu po transakciji (ovo je rijetko; veza se obično dijeli između korisnika) i imate veliki broj veza/prekida, utjecaj može biti nešto veći. To znači da može postojati rizik od degradacije performansi, ali razlika nije dovoljno značajna da negira potrebu za zaštitom.

Imajte na umu da postoji značajna razlika pri usporedbi načina rada: radite li unutar iste sesije ili u različitim sesijama. To je razumljivo: stvaranje svake veze zahtijeva resurse.

Imali smo slučaj gdje smo se spajali na Zabbix u načinu rada s povjerenjem, što znači da nismo provjeravali MD5 i autentifikacija nije bila potrebna. Tada je kupac zatražio omogućavanje MD5 autentifikacije. To je jako opteretilo CPU i performanse su pale. Počeli smo tražiti opcije optimizacije. Jedno moguće rješenje je implementacija mrežnih ograničenja, stvaranje zasebnih VLAN-ova za DBMS, dodavanje postavki kako bi se jasno naznačilo tko se spaja i odakle te onemogućavanje autentifikacije. Također možete optimizirati postavke autentifikacije kako biste smanjili opterećenje omogućavanja autentifikacije, ali općenito, korištenje različitih metoda autentifikacije utječe na performanse i zahtijeva razmatranje tih čimbenika prilikom projektiranja računalne snage poslužitelja (hardvera) za DBMS.

Zaključak: u nekim rješenjima čak i male nijanse u autentifikaciji mogu imati značajan utjecaj na projekt, a loše je kada to postane očito tek nakon implementacije u produkciji.

Revizija postupaka

Revizija nije ograničena samo na DBMS. Revizija uključuje prikupljanje informacija o tome što se događa u različitim segmentima. To može uključivati vatrozid baze podataka ili operativni sustav na kojem je DBMS izgrađen.

Komercijalni DBMS-ovi na razini poduzeća imaju izvrsnu reviziju, ali sustavi otvorenog koda to nemaju uvijek. Evo što PostgreSQL ima:

zadani zapisnik — ugrađeno zapisivanje;
proširenja: pgaudit — ako vam zadano zapisivanje nije dovoljno, možete koristiti zasebne postavke koje rješavaju neke od problema.

Dodatak izvješću u videu:

Osnovno zapisivanje naredbi može se osigurati standardnim alatom za zapisivanje s log_statement = all.

To je prihvatljivo za praćenje i druge namjene, ali ne pruža razinu detalja koja je obično potrebna za reviziju.

Nije dovoljno imati popis svih operacija izvršenih na bazi podataka.

Također bi trebalo biti moguće identificirati specifične tvrdnje koje su od interesa za revizora.

Standardna mogućnost zapisivanja prikazuje što je korisnik zatražio, dok se pgAudit fokusira na detalje onoga što se dogodilo kada je baza podataka izvršila upit.

Na primjer, revizor bi mogao htjeti provjeriti je li određena tablica kreirana unutar dokumentiranog vremenskog okvira održavanja.

Ovo se može činiti kao jednostavan zadatak za osnovnu reviziju i grep, ali što ako vam se prikaže nešto poput ovog (namjerno nejasnog) primjera:

DO $$
POČETI
IZVRŠI 'KREIRAJ TABLICU uvoz' || 'ant_table(id int)';
KRAJ $$;

Standardno zapisivanje će vam dati ovo:

LOG: izjava: DO $$
POČETI
IZVRŠI 'KREIRAJ TABLICU uvoz' || 'ant_table(id int)';
KRAJ $$;

Čini se da pronalaženje tablice od interesa može zahtijevati određeno poznavanje koda u slučajevima kada se tablice kreiraju dinamički.

Ovo nije idealno, jer bi bilo poželjnije jednostavno pretraživati po nazivu tablice.

Tu dobro dođe pgAudit.

Za isti ulaz, u zapisniku će se ispisati ovaj izlaz:

REVIZIJA: SESIJA,33,1,FUNKCIJA,URADI,,,"URADI $$
POČETI
IZVRŠI 'KREIRAJ TABLICU uvoz' || 'ant_table(id int)';
KRAJ $$;"
REVIZIJA: SESIJA,33,2,DDL,STVORI TABLICU,TABLICA,javna.važna_tablica,STVORI TABLICU važna_tablica (id INT)

Ne zapisuje se samo DO blok, već i puni tekst CREATE TABLE s vrstom operatora, vrstom objekta i punim imenom, što olakšava pretraživanje.

Prilikom zapisivanja SELECT i DML naredbi, pgAudit se može konfigurirati da zapisi zaseban unos za svaku relaciju na koju se u naredbi upućuje.

Nije potrebno parsiranje kako bi se pronašli svi izrazi koji utječu na određenu tablicu (*) ».

Kako će ovo utjecati na performanse DBMS-a?

Pokrenimo testove s omogućenom potpunom revizijom i vidimo što će se dogoditi s performansama PostgreSQL-a. Omogućit ćemo maksimalno zapisivanje u bazu podataka za sve parametre.

U konfiguracijskoj datoteci gotovo ništa ne mijenjamo, najvažnije je omogućiti debug5 način rada kako bismo dobili maksimalne informacije.

postgresql.conf

odredište_zapisnika = 'stderr'
logging_collector = uključeno
log_truncate_on_rotation = uključeno
log_rotation_age = 1d
veličina_rotacije_log = 10 MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = uključeno
debug_print_rewritten = uključeno
debug_print_plan = uključeno
debug_pretty_print = uključeno
log_checkpoints = uključeno
log_connections = uključeno
log_disconnections = uključeno
log_duration = uključeno
log_hostname = uključeno
log_lock_waits = uključeno
log_replication_commands = uključeno
log_temp_files = 0
log_timezone = 'Europa/Moskva'

Na PostgreSQL DBMS-u s parametrima 1 CPU, 2,8 GHz, 2 GB RAM-a, 40 GB HDD-a, provodimo tri testa opterećenja koristeći naredbe:

$ 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

Rezultati testa:

Zabranjena bilježenje
S sječom drva

Ukupno vrijeme potrebno za popunjavanje baze podataka
43,74 sek
53,23 sek

RAM
24%
40%

CPU
72%
91%

Test 1 (50 veza)

Broj transakcija u 10 minuta
74169
32445

Transakcije/sek
123
54

Prosječno kašnjenje
405 ms
925 ms

Test 2 (150 veza od 100 mogućih)

Broj transakcija u 10 minuta
81727
31429

Transakcije/sek
136
52

Prosječno kašnjenje
550 ms
1432 ms

O veličinama

Veličina baze podataka
2251 MB
2262 MB

Veličina zapisnika baze podataka
0 MB
4587 MB

Zaključak: potpuna revizija nije dobra ideja. Podaci revizije bit će veliki kao i sama baza podataka, ili čak i veći. Ovaj volumen zapisa koji se generira pri radu s DBMS-om čest je problem u produkcijskim okruženjima.

Pogledajmo ostale parametre:

Brzina se ne mijenja puno: bez bilježenja - 43,74 sekunde, s bilježenjem - 53,23 sekunde.
Performanse RAM-a i CPU-a će pasti zbog potrebe za generiranjem datoteke revizije. To je također primjetno na produkcijskim sustavima.

Kako se broj veza povećava, performanse će se prirodno malo pogoršati.

U korporacijama je revizija još složenija:

ima puno podataka;
Revizija je potrebna ne samo putem sysloga u SIEM-u, već i u datotekama: ako se nešto dogodi syslogu, mora postojati datoteka blizu baze podataka u kojoj su podaci spremljeni;
Za reviziju je potrebna zasebna polica kako bi se izbjegao pad u I/O operacijama diska, jer zauzima puno prostora;
Događa se da zaposlenici informacijske sigurnosti svugdje trebaju GOST standarde; potrebna im je GOST identifikacija.

Ograničavanje pristupa podacima

Pogledajmo tehnologije koje se koriste za zaštitu podataka i pristup njima u komercijalnim i DBMS-ovima otvorenog koda.

Što se općenito može koristiti:

Šifriranje i zamagljivanje procedura i funkcija (Wrapping) su odvojeni alati i uslužni programi koji pretvaraju čitljiv kod u nečitljiv. Međutim, ovaj kod se kasnije ne može mijenjati ili refaktorirati. Ovaj pristup je ponekad potreban, barem na strani DBMS-a - logika ograničenja licence ili logika autorizacije šifrira se na razini procedure i funkcije.
Vidljivost na razini retka (RLS) je kada različiti korisnici vide istu tablicu, ali se sastav redaka u njoj razlikuje, što znači da nekim korisnicima nije dopušteno vidjeti nešto na razini retka.
Maskiranje je kada korisnici vide podatke ili samo zvjezdice u stupcu tablice, što znači da neki korisnici neće vidjeti informacije. Tehnologija određuje koji korisnici što vide na temelju njihove razine pristupa.
Sigurnosni DBA/DBA aplikacije/Kontrola pristupa DBA više se odnosi na ograničavanje pristupa samom DBMS-u, što znači da osoblje za sigurnost informacija može biti odvojeno od administratora baza podataka i aplikacija. Iako su tehnologije otvorenog koda rijetke, komercijalni DBMS-ovi ih imaju mnogo. Potrebni su kada više korisnika ima pristup samim poslužiteljima.
Ograničite pristup datotekama na razini datotečnog sustava. Možete dodijeliti dozvole i privilegije direktorijima tako da svaki administrator ima pristup samo podacima koji su mu potrebni.
Obavezni pristup i čišćenje memorije su tehnologije koje se rijetko koriste.
End-to-end enkripcija izravno unutar DBMS-a je enkripcija na strani klijenta s upravljanjem ključevima na strani poslužitelja.
Šifriranje podataka. Na primjer, stupčasto šifriranje - kada koristite mehanizam koji šifrira jedan stupac baze podataka.

Kako ovo utječe na performanse DBMS-a?

Pogledajmo primjer stupčastog šifriranja u PostgreSQL-u. Ima modul pgcrypto koji vam omogućuje pohranjivanje odabranih polja u šifriranom obliku. To je korisno kada su samo neki podaci vrijedni. Za čitanje šifriranih polja, klijent daje ključ za dešifriranje, poslužitelj dešifrira podatke i vraća ih klijentu. Bez ključa nitko ne može ništa učiniti s vašim podacima.

Pokrenimo test s pgcryptoIzradimo tablicu sa šifriranim i regularnim podacima. U nastavku su naredbe za izradu tablica, a prvi redak sadrži korisnu naredbu za izradu samog proširenja i registraciju DBMS-a:

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

Zatim ćemo pokušati izdvojiti podatke iz svake tablice i pogledati vremena izvršavanja.

Odabir iz tablice bez funkcije šifriranja:

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

Štoperica je uključena.

id | tekst1 | tekst2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 redaka)

Vrijeme: 1,386 ms

Izvadak iz tablice s funkcijom šifriranja:

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

Štoperica je uključena.

id | dešifriranje | dešifriranje
——+—————+—————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 redaka)

Vrijeme: 50,203 ms

Rezultati ispitivanja:

Bez enkripcije
Pgcrypto (dešifriranje)

Odabir 1000 redaka
1,386 ms
50,203 ms

CPU
15%
35%

RAM

+ 5%

Šifriranje ima značajan utjecaj na performanse. Vrijeme se očito povećalo, jer dešifriranje šifriranih podataka (a dešifriranje je obično obavijeno vlastitom logikom) zahtijeva značajne resurse. Stoga je šifriranje svih stupaca koji sadrže podatke povezano s degradacijom performansi.

Međutim, enkripcija nije čarobni štapić koji rješava sve probleme. Dešifrirani podaci i ključ za dešifriranje ostaju na poslužitelju tijekom dešifriranja i prijenosa podataka. Stoga ključeve može presresti netko s punim pristupom poslužitelju baze podataka, poput administratora sustava.

Imati jedan ključ za cijeli stupac za sve korisnike (čak i ako ne za sve, već za ograničeni skup klijenata) nije uvijek dobra ili prikladna praksa. Zbog toga je uvedena end-to-end enkripcija, DBMS-ovi su počeli razmatrati opcije za šifriranje podataka i na strani klijenta i na strani poslužitelja, te su se pojavili isti ti trezori ključeva - zasebni proizvodi koji omogućuju upravljanje ključevima na strani DBMS-a.

Primjer takvog šifriranja u MongoDB-u

Sigurnosne značajke u komercijalnim i open source DBMS-ovima

Funkcije
Vrsta
Politika zaporke
Revizija
Zaštita izvornog koda procedura i funkcija
RLS
Šifriranje

Proročanstvo
komercijalni
+
+
+
+
+

MsSql
komercijalni
+
+
+
+
+

jatoba
komercijalni
+
+
+
+
ekstenzije

PostgreSQL
Besplatno
ekstenzije
ekstenzije
-
+
ekstenzije

MongoDB
Besplatno
-
+
-
-
Dostupno samo u MongoDB Enterprise verziji

Ova tablica je daleko od potpune, ali situacija je sljedeća: komercijalni proizvodi već dugo rješavaju sigurnosne probleme, dok se proizvodi otvorenog koda obično oslanjaju na dodatke za sigurnost; mnoge značajke nedostaju, a ponekad je potreban dodatni kod. Na primjer, pravila o lozinkama - PostgreSQL ima mnogo različitih proširenja (1, 2, 3, 4, 5), koje implementiraju politike lozinki, ali, po mom mišljenju, nijedna od njih ne pokriva sve potrebe domaćeg korporativnog segmenta.

Što učiniti ako nigdje ne možete pronaći ono što vam trebaNa primjer, možda želite koristiti određeni DBMS koji nema značajke koje korisnik zahtijeva.

Tada možete koristiti rješenja trećih strana koja rade s različitim DBMS-ovima, kao što su Crypto DB ili Garda DB. Ako govorimo o domaćim rješenjima, ona bolje razumiju GOST standarde od rješenja otvorenog koda.

Druga je mogućnost da sami napišete potrebne podatke, implementirate pristup podacima i šifriranje na razini aplikacije. Istina, to će biti teže s GOST standardima. Ali općenito, podatke možete sakriti po potrebi, pohraniti ih u DBMS, a zatim ih po potrebi dohvatiti i dešifrirati, upravo na razini aplikacije. Međutim, dobro razmislite kako ćete zaštititi te algoritme u aplikaciji. Po našem mišljenju, to bi trebalo učiniti na razini DBMS-a, jer će brže raditi.

Ovo je izvješće prvi put predstavljeno na @Databases Meetup od Mail.ru Cloud Solutions. Izgled video ostale izvedbe i pretplatite se na najave događaja na Telegramu Oko Kubernetesa u Mail.ru grupi.

Što još pročitati na temu:

Izvor: www.habr.com