Moje ime je Denis Rozhkov, ja sam šef razvoja softvera u kompaniji Gazinformservice, u timu proizvoda Jatoba. Zakonodavstvo i korporativni propisi nameću određene zahtjeve za sigurnost pohranjivanja podataka. Niko ne želi da treća lica dobiju pristup povjerljivim informacijama, tako da su sljedeća pitanja važna za svaki projekat: identifikacija i autentifikacija, upravljanje pristupom podacima, osiguranje integriteta informacija u sistemu, evidentiranje sigurnosnih događaja. Stoga želim da govorim o nekim zanimljivim tačkama u vezi sa sigurnošću DBMS-a.

Članak je pripremljen na osnovu govora na @DatabasesMeetup, organizovano Mail.ru Cloud rješenja. Ako ne želite čitati, možete pogledati:

Članak će imati tri dijela:

• Kako osigurati veze.
• Šta je revizija radnji i kako zabilježiti što se događa na strani baze podataka i povezivanje s njom.
• Kako zaštititi podatke u samoj bazi podataka i koje tehnologije su za to dostupne.

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

Osiguravanje vaših veza

Možete se povezati s bazom podataka direktno ili indirektno putem web aplikacija. Po pravilu, poslovni korisnik, odnosno osoba koja radi sa DBMS-om, sa njim komunicira indirektno.

Prije nego što počnete govoriti o zaštiti veza, morate odgovoriti na važna pitanja koja određuju kako će sigurnosne mjere biti strukturirane:

• Da li je jedan poslovni korisnik ekvivalentan jednom korisniku DBMS-a?
• da li je pristup DBMS podacima omogućen samo preko API-ja koji vi kontrolirate ili se tablicama pristupa direktno;
• da li je DBMS dodijeljen posebnom zaštićenom segmentu, ko sa njim komunicira i kako;
• da li se koriste objedinjavanje/proxy i međuslojevi, što može promijeniti informacije o tome kako je veza izgrađena i ko koristi bazu podataka.

Sada da vidimo koji se alati mogu koristiti za osiguranje veza:

1. Koristite rješenja klasa firewall baze podataka. Dodatni sloj zaštite će, u najmanju ruku, povećati transparentnost onoga što se dešava u DBMS-u, a maksimalno ćete moći pružiti dodatnu zaštitu podataka.
2. Koristite politiku lozinki. Njihova upotreba zavisi od toga kako je izgrađena vaša arhitektura. U svakom slučaju, jedna lozinka u konfiguracijskoj datoteci web aplikacije koja se povezuje na DBMS nije dovoljna za zaštitu. Postoji niz DBMS alata koji vam omogućavaju da kontrolišete da li je potrebno ažuriranje korisnika i lozinke.

   Možete pročitati više o funkcijama ocjenjivanja korisnika ovdje, također možete saznati o MS SQL procjenilu ranjivosti ovdje. 

3. Obogatite kontekst sesije potrebnim informacijama. Ako je sesija neprozirna, ne razumijete ko radi u DBMS-u u njegovom okviru, možete u okviru operacije koja se izvodi dodati informacije o tome ko šta radi i zašto. Ove informacije se mogu vidjeti u reviziji.
4. Konfigurirajte SSL ako nemate mrežno razdvajanje između DBMS-a i krajnjih korisnika; nije u zasebnom VLAN-u. U takvim slučajevima, imperativ je zaštititi kanal između potrošača i samog DBMS-a. Sigurnosni alati su također dostupni u otvorenom kodu.

Kako će to uticati na performanse DBMS-a?

Pogledajmo primjer PostgreSQL-a da vidimo kako SSL utječe na opterećenje CPU-a, povećava tajming i smanjuje TPS, te da li će potrošiti previše resursa ako ga omogućite.

Učitavanje PostgreSQL-a pomoću pgbench-a je jednostavan program za pokretanje testova performansi. Izvršava jedan niz naredbi uzastopno, moguće u paralelnim sesijama baze podataka, a zatim izračunava prosječnu stopu transakcije.

Test 1 bez SSL-a i korištenjem SSL-a — 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"

vs

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

Test 2 bez SSL-a i korištenjem SSL-a — sve transakcije se obavljaju 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"

vs

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

Ostala podešavanja:

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:

 
NO SSL
SSL

Za svaku transakciju se uspostavlja veza

prosjek kašnjenja
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 obavljaju u jednoj vezi

prosjek kašnjenja
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, uticaj SSL-a je uporediv sa greškom merenja. Ako je količina prenesenih podataka vrlo velika, situacija može biti drugačija. Ako uspostavimo jednu vezu po transakciji (ovo je rijetko, obično se veza dijeli između korisnika), imate veliki broj konekcija/prekidanja, utjecaj može biti malo veći. Odnosno, mogu postojati rizici od smanjenja performansi, međutim, razlika nije toliko velika da se ne koristi zaštita.

Imajte na umu da postoji velika razlika ako uporedite režime rada: radite u istoj sesiji ili u različitim. To je razumljivo: resursi se troše na stvaranje svake veze.

Imali smo slučaj kada smo Zabbix povezali u trust modu, odnosno md5 nije bio provjeren, nije bilo potrebe za autentifikacijom. Tada je kupac tražio da omogući md5 način provjere autentičnosti. Ovo je dovelo do velikog opterećenja CPU-a, a performanse su pale. Počeli smo tražiti načine za optimizaciju. Jedno od mogućih rješenja problema je implementacija mrežnih ograničenja, pravljenje zasebnih VLAN-ova za DBMS, dodavanje postavki da bude jasno ko se odakle povezuje i uklanjanje autentikacije. Također možete optimizirati postavke autentifikacije kako biste smanjili troškove prilikom omogućavanja autentifikacije, ali općenito korištenje različitih metoda autentifikacije utječe na performanse i zahtijeva uzimanje ovih faktora u obzir prilikom dizajniranja računarske snage servera (hardvera) za DBMS.

Zaključak: u nizu rješenja čak i male nijanse u autentifikaciji mogu uvelike utjecati na projekt i loše je kada to postane jasno tek kada se implementira u produkciji.

Akciona revizija

Revizija može biti ne samo DBMS. Revizija je prikupljanje informacija o tome šta se dešava u različitim segmentima. To može biti ili zaštitni zid baze podataka ili operativni sistem na kojem je izgrađen DBMS.

U komercijalnim DBMS-ovima na nivou preduzeća sve je u redu sa revizijom, ali u otvorenom kodu - ne uvek. Evo šta PostgreSQL ima:

• default log - ugrađeno evidentiranje;
• ekstenzije: pgaudit - ako zadano evidentiranje nije dovoljno za vas, možete koristiti zasebne postavke koje rješavaju neke probleme.

Dodatak izvještaju u videu:

„Osnovno evidentiranje iskaza može biti omogućeno standardnim alatom za evidentiranje sa log_statement = all.

Ovo je prihvatljivo za praćenje i druge upotrebe, ali ne pruža nivo detalja koji je tipično potreban za reviziju.

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

Također bi trebalo biti moguće pronaći specifične izjave koje su od interesa za revizora.

Standardno evidentiranje pokazuje šta je korisnik tražio, dok se pgAudit fokusira na detalje onoga što se dogodilo kada je baza podataka izvršila upit.

Na primjer, revizor može htjeti provjeriti da li je određena tablica kreirana unutar dokumentiranog prozora održavanja.

Ovo može izgledati kao jednostavan zadatak s osnovnom revizijom i grep-om, ali što ako vam se prikaže nešto poput ovog (namjerno zbunjujućeg) primjera:

DO$$
BEGIN
IZVRŠITE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

Standardno evidentiranje će vam dati ovo:

LOG: izjava: DO $$
BEGIN
IZVRŠITE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

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

Ovo nije idealno, jer bi bilo poželjno jednostavno pretraživati ​​po imenu tabele.

Ovdje pgAudit dobro dolazi.

Za isti ulaz, proizvest će ovaj izlaz u dnevniku:

REVIZIJA: SESIJA,33,1,FUNKCIJA,URADITI,,,"URADITI $$
BEGIN
IZVRŠITE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
REVIZIJA: SESIJA,33,2,DDL,KREIRAJ TABELU,TABELU,javno.važna_tabela,KREIRAJ TABELU važna_tabela (id INT)

Zapisuje se ne samo blok DO, već i puni tekst CREATE TABLE sa tipom iskaza, tipom objekta i punim imenom, što olakšava pretraživanje.

Prilikom evidentiranja SELECT i DML izraza, pgAudit se može konfigurirati da evidentira poseban unos za svaki odnos naveden u izrazu.

Nije potrebno raščlanjivanje da bi se pronašli svi iskazi koji dodiruju određenu tabelu (*) ».

Kako će to uticati na performanse DBMS-a?

Pokrenimo testove sa omogućenom potpunom revizijom i vidimo šta se dešava sa performansama PostgreSQL-a. Omogućimo maksimalno evidentiranje baze podataka za sve parametre.

Ne mijenjamo gotovo ništa u konfiguracijskoj datoteci, najvažnije je uključiti debug5 mod kako biste dobili maksimalne informacije.

postgresql.conf

log_destination = 'stderr'
logging_collector = uključeno
log_truncate_on_rotation = uključeno
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 = 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_wait = uključeno
log_replication_commands = uključeno
log_temp_files = 0
log_timezone = 'Evropa/Moskva'

Na PostgreSQL DBMS-u sa parametrima 1 CPU, 2,8 GHz, 2 GB RAM-a, 40 GB HDD, vršimo tri testa opterećenja pomoću naredbi:

$ 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:

Nema evidentiranja
Sa secanjem

Ukupno vrijeme punjenja baze podataka
43,74 sec
53,23 sec

RAM-a
24%
40%

CPU
72%
91%

Test 1 (50 veza)

Broj transakcija u 10 minuta
74169
32445

Transakcije/sek
123
54

Prosječna latencija
405 ms
925 ms

Test 2 (150 veza sa 100 mogućih)

Broj transakcija u 10 minuta
81727
31429

Transakcije/sek
136
52

Prosječna latencija
550 ms
1432 ms

O veličinama

DB veličina
2251 MB
2262 MB

Veličina dnevnika baze podataka
0 MB
4587 MB

Zaključak: potpuna revizija nije baš dobra. Podaci iz revizije bit će veliki koliko i podaci u samoj bazi podataka, ili čak i više. Količina evidentiranja koja se generiše pri radu sa DBMS-om je čest problem u proizvodnji.

Pogledajmo ostale parametre:

• Brzina se ne mijenja mnogo: bez evidentiranja - 43,74 sekunde, sa evidentiranjem - 53,23 sekunde.
• Performanse RAM-a i CPU-a će patiti, jer morate da generišete datoteku revizije. To je vidljivo i u produktivnosti.

Kako se broj veza povećava, naravno, performanse će se blago pogoršati.

U korporacijama sa revizijom je još teže:

• ima mnogo podataka;
• revizija je potrebna ne samo preko syslog-a u SIEM-u, već iu datotekama: ako se nešto desi syslog-u, mora postojati datoteka blizu baze podataka u kojoj su podaci pohranjeni;
• potrebna je posebna polica za reviziju kako se ne bi trošili I/O diskovi, jer zauzima puno prostora;
• Dešava se da zaposlenici u informacionoj sigurnosti svugdje trebaju GOST standarde, zahtijevaju državnu identifikaciju.

Ograničavanje pristupa podacima

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

Šta općenito možete koristiti:

1. Šifrovanje i zamagljivanje procedura i funkcija (Wrapping) - to jest, zasebni alati i uslužni programi koji čine čitljivi kod nečitljivim. Istina, tada se ne može ni promijeniti ni refaktorirati natrag. Ovaj pristup je ponekad potreban barem na strani DBMS-a - logika ograničenja licence ili logika autorizacije je šifrirana precizno na razini procedure i funkcije.
2. Ograničavanje vidljivosti podataka po redovima (RLS) je kada različiti korisnici vide jednu tabelu, ali različit sastav redova u njoj, odnosno ne može se nešto pokazati nekome na nivou reda.
3. Uređivanje prikazanih podataka (Maskiranje) je kada korisnici u jednoj koloni tabele vide ili podatke ili samo zvjezdice, odnosno za neke korisnike informacije će biti zatvorene. Tehnologija određuje kojem korisniku se šta prikazuje na osnovu njegovog nivoa pristupa.
4. Sigurnost DBA/Aplikacija DBA/DBA kontrola pristupa se radije radi o ograničavanju pristupa samom DBMS-u, odnosno, zaposleni u sigurnosti informacija mogu biti odvojeni od administratora baza podataka i administratora aplikacija. Malo je takvih tehnologija u otvorenom kodu, ali ih ima dosta u komercijalnim DBMS-ovima. Potrebni su kada postoji mnogo korisnika koji imaju pristup samim serverima.
5. Ograničavanje pristupa datotekama na nivou sistema datoteka. Možete dodijeliti prava i privilegije pristupa direktorijima tako da svaki administrator ima pristup samo potrebnim podacima.
6. Obavezni pristup i brisanje memorije - ove tehnologije se rijetko koriste.
7. Enkripcija od kraja do kraja direktno iz DBMS-a je šifrovanje na strani klijenta sa upravljanjem ključevima na strani servera.
8. Šifrovanje podataka. Na primjer, kolonsko šifriranje je kada koristite mehanizam koji šifrira jedan stupac baze podataka.

Kako to utiče na performanse DBMS-a?

Pogledajmo primjer stupnog šifriranja u PostgreSQL-u. Postoji pgcrypto modul, koji vam omogućava da pohranite odabrana polja u šifriranom obliku. Ovo je korisno kada su samo neki podaci vrijedni. Da bi pročitao šifrovana polja, klijent prenosi ključ za dešifrovanje, server dešifruje podatke i vraća ih klijentu. Bez ključa niko ne može ništa učiniti s vašim podacima.

Hajde da testiramo sa pgcrypto. Kreirajmo tabelu sa šifrovanim podacima i regularnim podacima. Ispod su naredbe za kreiranje tabela, u prvom redu nalazi se korisna naredba - kreiranje same ekstenzije uz DBMS registraciju:

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, pokušajmo napraviti uzorak podataka iz svake tablice i pogledati vrijeme izvršenja.

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

Vrijeme: 1,386 ms

Izbor iz tabele sa funkcijom enkripcije:

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šifrirati | dešifrirati
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 redova)

Vrijeme: 50,203 ms

Rezultati ispitivanja:

 
Bez enkripcije
Pgcrypto (dešifriranje)

Uzorak 1000 redova
1,386 ms
50,203 ms

CPU
15%
35%

RAM-a
 
+ 5%

Šifrovanje ima veliki uticaj na performanse. Može se vidjeti da se tajming povećao, budući da operacije dešifriranja šifriranih podataka (a dešifriranje je obično još uvijek umotano u vašu logiku) zahtijevaju značajne resurse. Odnosno, ideja šifriranja svih stupaca koji sadrže neke podatke prepuna je smanjenja performansi.

Međutim, enkripcija nije srebrni metak koji rješava sve probleme. Dešifrovani podaci i ključ za dešifrovanje tokom procesa dešifrovanja i prenosa podataka nalaze se na serveru. Stoga ključeve može presresti neko ko ima pun pristup serveru baze podataka, kao što je administrator sistema.

Kada postoji jedan ključ za cijelu kolonu za sve korisnike (čak i ako ne za sve, ali za klijente ograničenog skupa), to nije uvijek dobro i ispravno. Zbog toga su počeli raditi end-to-end enkripciju, u DBMS-u su počeli razmatrati opcije za šifriranje podataka na strani klijenta i servera, a pojavila su se ista ta skladište ključeva - zasebni proizvodi koji pružaju upravljanje ključevima na DBMS-u strana.

Primjer takve enkripcije u MongoDB

Sigurnosne karakteristike u komercijalnim i otvorenim DBMS-ima

Funkcije
Tip
Politika lozinke
revizija
Zaštita izvornog koda procedura i funkcija
RLS
Encryption

proročanstvo
komercijalno
+
+
+
+
+

MsSql
komercijalno
+
+
+
+
+

Jatoba
komercijalno
+
+
+
+
ekstenzije

PostgreSQL
besplatno
ekstenzije
ekstenzije
-
+
ekstenzije

MongoDb
besplatno
-
+
-
-
Dostupno samo u MongoDB Enterprise

Tabela je daleko od potpune, ali situacija je sljedeća: u komercijalnim proizvodima sigurnosni problemi su već dugo riješeni, u otvorenom kodu se u pravilu koriste neka vrsta dodataka za sigurnost, nedostaju mnoge funkcije , ponekad morate nešto dodati. Na primjer, pravila lozinki - PostgreSQL ima mnogo različitih ekstenzija (1, 2, 3, 4, 5), koji implementiraju politiku lozinki, ali, po mom mišljenju, nijedna od njih ne pokriva sve potrebe domaćeg korporativnog segmenta.

Šta učiniti ako nigdje nemate ono što vam treba? Na primjer, želite koristiti određeni DBMS koji nema funkcije koje korisnik zahtijeva.

Tada možete koristiti rješenja treće strane koja rade s različitim DBMS-ovima, na primjer, Crypto DB ili Garda DB. Ako govorimo o rješenjima iz domaćeg segmenta, onda oni znaju o GOST-ovima bolje nego u otvorenom kodu.

Druga opcija je da sami napišete ono što vam treba, implementirate pristup podacima i enkripciju u aplikaciji na nivou procedure. Istina, s GOST-om će biti teže. Ali općenito, možete sakriti podatke po potrebi, staviti ih u DBMS, zatim ih dohvatiti i dešifrirati po potrebi, direktno na razini aplikacije. Istovremeno, odmah razmislite kako ćete zaštititi ove algoritme u aplikaciji. Po našem mišljenju, to bi trebalo uraditi na nivou DBMS-a, jer će to brže raditi.

Ovaj izvještaj je prvi put predstavljen na @Databases Meetup by Mail.ru Cloud Solutions. Vidi видео ostale nastupe i pretplatite se na najave događaja u Telegramu Oko Kubernetesa u Mail.ru grupi.

Šta još pročitati na temu:

1. Više od Ceph-a: MCS cloud block memorija.
2. Kako odabrati bazu podataka za projekat tako da ne morate ponovo birati.

izvor: www.habr.com