Moje ime je Denis Rožkov, sem vodja razvoja programske opreme v podjetju Gazinformservice, v produktni ekipi . Zakonodaja in poslovni predpisi nalagajo določene zahteve glede varnosti shranjevanja podatkov. Nihče ne želi, da tretje osebe dobijo dostop do zaupnih informacij, zato so za vsak projekt pomembna naslednja vprašanja: identifikacija in avtentikacija, upravljanje dostopa do podatkov, zagotavljanje celovitosti informacij v sistemu, beleženje varnostnih dogodkov. Zato želim govoriti o nekaterih zanimivih točkah v zvezi z varnostjo DBMS.
Članek je bil pripravljen na podlagi govora na organizirano . Če ne želite brati, si lahko ogledate:
Članek bo imel tri dele:
- Kako zavarovati povezave.
- Kaj je revizija dejanj in kako beležiti dogajanje na strani baze podatkov in povezovanje z njo.
- Kako zaščititi podatke v sami bazi in katere tehnologije so za to na voljo.
Tri komponente varnosti DBMS: zaščita povezave, revizija dejavnosti in zaščita podatkov
Varovanje vaših povezav
Z bazo podatkov se lahko povežete neposredno ali posredno prek spletnih aplikacij. Praviloma poslovni uporabnik, to je oseba, ki dela z DBMS, z njim komunicira posredno.
Preden govorite o zaščiti povezav, morate odgovoriti na pomembna vprašanja, ki določajo, kako bodo strukturirani varnostni ukrepi:
- Ali je en poslovni uporabnik enakovreden enemu uporabniku DBMS?
- ali je dostop do podatkov DBMS zagotovljen samo prek API-ja, ki ga nadzirate, ali pa se do tabel dostopa neposredno;
- ali je DBMS dodeljen ločenemu zaščitenemu segmentu, kdo in kako sodeluje z njim;
- ali se uporabljajo združevanje/proxy in vmesne plasti, ki lahko spremenijo informacije o tem, kako je zgrajena povezava in kdo uporablja bazo podatkov.
Zdaj pa poglejmo, katera orodja je mogoče uporabiti za zaščito povezav:
- Uporabite rešitve razreda požarnega zidu zbirke podatkov. Dodatna plast zaščite bo vsaj povečala preglednost dogajanja v DBMS, največ pa boste lahko zagotovili dodatno zaščito podatkov.
- Uporabite politike gesel. Njihova uporaba je odvisna od tega, kako je zgrajena vaša arhitektura. Vsekakor eno geslo v konfiguracijski datoteki spletne aplikacije, ki se povezuje z DBMS, ni dovolj za zaščito. Obstajajo številna orodja DBMS, ki vam omogočajo nadzor nad tem, ali je treba uporabnika in geslo posodobiti.
Preberete lahko več o funkcijah ocenjevanja uporabnikov , lahko izveste tudi o MS SQL Vulnerability Assessmen .
- Obogatite kontekst seje s potrebnimi informacijami. Če je seja nepregledna, ne razumete, kdo dela v DBMS v njenem okviru, lahko v okviru izvajane operacije dodate informacije o tem, kdo počne kaj in zakaj. Ta podatek je razviden iz revizije.
- Konfigurirajte SSL, če nimate omrežne ločitve med DBMS in končnimi uporabniki; ni v ločenem VLAN. V takih primerih je nujno zaščititi kanal med potrošnikom in samim DBMS. Varnostna orodja so na voljo tudi v odprti kodi.
Kako bo to vplivalo na delovanje DBMS?
Oglejmo si primer PostgreSQL, da vidimo, kako SSL vpliva na obremenitev procesorja, poveča čase in zmanjša TPS ter ali bo porabil preveč virov, če ga omogočite.
Nalaganje PostgreSQL z uporabo pgbench je preprost program za izvajanje testov zmogljivosti. Ponavljajoče izvaja eno samo zaporedje ukazov, po možnosti v vzporednih sejah zbirke podatkov, nato pa izračuna povprečno stopnjo transakcije.
Test 1 brez SSL in z uporabo SSL — povezava se vzpostavi za vsako transakcijo:
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 brez SSL in z uporabo SSL — vse transakcije se izvajajo v eni povezavi:
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"Druge nastavitve:
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/50000Rezultati testiranja:
NI SSL
SSL
Za vsako transakcijo se vzpostavi povezava
povprečna zakasnitev
171.915 ms
187.695 ms
tps vključno z vzpostavljanjem povezav
58.168112
53.278062
tps brez vzpostavljanja povezav
64.084546
58.725846
CPU
24%
28%
Vse transakcije se izvajajo v eni povezavi
povprečna zakasnitev
6.722 ms
6.342 ms
tps vključno z vzpostavljanjem povezav
1587.657278
1576.792883
tps brez vzpostavljanja povezav
1588.380574
1577.694766
CPU
17%
21%
Pri majhnih obremenitvah je vpliv SSL primerljiv z merilno napako. Če je količina prenesenih podatkov zelo velika, je lahko situacija drugačna. Če vzpostavimo eno povezavo na transakcijo (to je redko, običajno je povezava deljena med uporabniki), imate veliko število povezav/prekinitev povezave, je lahko vpliv nekoliko večji. To pomeni, da lahko obstaja nevarnost zmanjšane učinkovitosti, vendar razlika ni tako velika, da ne bi uporabili zaščite.
Upoštevajte, da obstaja velika razlika, če primerjate načine delovanja: delate znotraj iste seje ali v različnih. To je razumljivo: sredstva se porabijo za ustvarjanje vsake povezave.
Imeli smo primer, ko smo Zabbix povezali v načinu zaupanja, to je, da md5 ni bil preverjen, ni bilo potrebe po avtentikaciji. Nato je stranka prosila, da omogoči način preverjanja pristnosti md5. To je močno obremenilo CPE in zmogljivost je padla. Začeli smo iskati načine za optimizacijo. Ena od možnih rešitev problema je uvedba omrežnih omejitev, izdelava ločenih VLAN-jev za DBMS, dodajanje nastavitev, da bo jasno, od kod se povezuje, in odstranitev avtentikacije.Prav tako lahko optimizirate nastavitve avtentikacije, da zmanjšate stroške pri omogočanju avtentikacije, vendar na splošno uporaba različnih metod avtentikacije vpliva na zmogljivost in zahteva upoštevanje teh dejavnikov pri načrtovanju računalniške moči strežnikov (strojne opreme) za DBMS.
Zaključek: v številnih rešitvah lahko že majhne nianse pri preverjanju pristnosti močno vplivajo na projekt in slabo je, če se to pokaže šele, ko se implementira v produkcijo.
Akcijska revizija
Revizija ni samo DBMS. Pri reviziji gre za pridobivanje informacij o tem, kaj se dogaja v različnih segmentih. To je lahko požarni zid baze podatkov ali operacijski sistem, na katerem je zgrajen DBMS.
V komercialnih DBMS-jih na ravni Enterprise je z revizijo vse v redu, v odprtokodnih pa ne vedno. Evo, kaj ima PostgreSQL:
- privzeti dnevnik - vgrajeno beleženje;
- razširitve: pgaudit - če vam privzeto beleženje ne zadostuje, lahko uporabite ločene nastavitve, ki rešijo nekatere težave.
Dodatek k poročilu v videu:
"Osnovno beleženje stavkov je mogoče zagotoviti s standardnim pripomočkom za beleženje z log_statement = all.
To je sprejemljivo za spremljanje in druge uporabe, vendar ne zagotavlja ravni podrobnosti, ki je običajno potrebna za revizijo.
Ni dovolj, da imamo seznam vseh operacij, izvedenih v bazi podatkov.
Prav tako mora biti mogoče najti posebne izjave, ki zanimajo revizorja.
Standardno beleženje prikazuje, kaj je uporabnik zahteval, medtem ko se pgAudit osredotoča na podrobnosti o tem, kaj se je zgodilo, ko je baza podatkov izvedla poizvedbo.
Na primer, revizor bo morda želel preveriti, ali je bila določena tabela ustvarjena znotraj dokumentiranega obdobja vzdrževanja.
To se morda zdi preprosta naloga z osnovnim revidiranjem in grepom, toda kaj, ko bi vam predstavili nekaj takega (namerno zmeden) primer:
DO$$
ZAČETI
IZVEDI 'CREATE TABLE import' || 'ant_table(id int)';
KONEC$$;
Standardno beleženje vam bo dalo to:
LOG: izjava: DO $$
ZAČETI
IZVEDI 'CREATE TABLE import' || 'ant_table(id int)';
KONEC$$;
Zdi se, da iskanje zanimive tabele morda zahteva nekaj znanja kode v primerih, ko so tabele ustvarjene dinamično.
To ni idealno, saj bi bilo bolje iskati preprosto po imenu tabele.
Tukaj pride prav pgAudit.
Za isti vnos bo ustvaril ta izhod v dnevniku:
REVIZIJA: SESSION,33,1,FUNCTION,DO,,,"DO $$
ZAČETI
IZVEDI 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
REVIZIJA: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)
Zapisuje se ne samo blok DO, ampak tudi celotno besedilo CREATE TABLE z vrsto stavka, vrsto objekta in polnim imenom, kar olajša iskanje.
Pri beleženju stavkov SELECT in DML lahko pgAudit konfigurirate tako, da beleži ločen vnos za vsako razmerje, navedeno v stavku.
Za iskanje vseh stavkov, ki se dotikajo določene tabele, ni potrebno razčlenjevanje () ».
Kako bo to vplivalo na delovanje DBMS?
Zaženimo teste z omogočenim popolnim nadzorom in poglejmo, kaj se zgodi z zmogljivostjo PostgreSQL. Omogočimo maksimalno beleženje baze podatkov za vse parametre.
V konfiguracijski datoteki ne spreminjamo skoraj ničesar, najpomembnejše je, da vklopimo način debug5, da dobimo največ informacij.
postgresql.conf
log_destination = 'stderr'
logging_collector = vklopljeno
log_truncate_on_rotation = vklopljeno
dnevnik_rotacije_starost = 1d
velikost_rotacije dnevnika = 10 MB
log_min_messages = razhroščevanje5
log_min_error_statement = razhroščevanje5
log_min_duration_statement = 0
debug_print_parse = vklopljeno
debug_print_rewritten = vklopljeno
debug_print_plan = vklopljeno
debug_pretty_print = vklopljeno
log_checkpoints = vklopljeno
log_connections = vklopljeno
log_disconnections = vklopljeno
trajanje dnevnika = vklopljeno
ime_gostitelja dnevnika = vklopljeno
log_lock_wait = vklopljeno
log_replication_commands = vklopljeno
log_temp_files = 0
log_timezone = 'Evropa/Moskva'
Na DBMS PostgreSQL s parametri 1 CPE, 2,8 GHz, 2 GB RAM, 40 GB HDD izvedemo tri obremenitvene teste z uporabo ukazov:
$ 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 benchmarkRezultati testov:
Brez beleženja
S sečnjo
Skupni čas polnjenja baze podatkov
43,74 sek
53,23 sek
RAM
24%
40%
CPU
72%
91%
Test 1 (50 povezav)
Število transakcij v 10 minutah
74169
32445
Transakcije/sek
123
54
Povprečna zakasnitev
405 ms
925 ms
Test 2 (150 povezav s 100 možnimi)
Število transakcij v 10 minutah
81727
31429
Transakcije/sek
136
52
Povprečna zakasnitev
550 ms
1432 ms
O velikostih
velikost DB
2251 MB
2262 MB
Velikost dnevnika baze podatkov
0 MB
4587 MB
Bistvo: popolna revizija ni zelo dobra. Podatki iz revizije bodo tako veliki kot podatki v sami bazi ali celo več. Količina beleženja, ki se ustvari pri delu z DBMS, je pogosta težava v proizvodnji.
Poglejmo še druge parametre:
- Hitrost se ne spreminja veliko: brez beleženja - 43,74 sekunde, z beleženjem - 53,23 sekunde.
- Zmogljivost RAM-a in procesorja bo prizadeta, saj morate ustvariti revizijsko datoteko. To se pozna tudi pri produktivnosti.
Ko se število povezav poveča, se bo zmogljivost seveda nekoliko poslabšala.
V družbah z revizijo je še težje:
- podatkov je veliko;
- revizija ni potrebna samo prek syslog v SIEM, ampak tudi v datotekah: če se kaj zgodi s syslogom, mora biti blizu baze podatkov datoteka, v kateri so shranjeni podatki;
- za revizijo je potrebna posebna polica, da ne zapravljamo I/O diskov, saj zavzame veliko prostora;
- Dogaja se, da zaposleni na področju informacijske varnosti povsod potrebujejo standarde GOST, zahtevajo državno identifikacijo.
Omejitev dostopa do podatkov
Oglejmo si tehnologije, ki se uporabljajo za zaščito podatkov in dostop do njih v komercialnih DBMS in odprtokodnih sistemih.
Kaj lahko na splošno uporabite:
- Šifriranje in zamegljevanje postopkov in funkcij (Wrapping) – to so ločena orodja in pripomočki, ki naredijo berljivo kodo neberljivo. Res je, potem ga ni mogoče niti spremeniti niti refaktorirati nazaj. Ta pristop je včasih potreben vsaj na strani DBMS - logika licenčnih omejitev ali avtorizacijska logika je šifrirana natančno na ravni postopkov in funkcij.
- Omejevanje vidnosti podatkov po vrsticah (RLS) je takrat, ko različni uporabniki vidijo eno tabelo, a različno sestavo vrstic v njej, se pravi, da se nekaj nekomu ne more pokazati na ravni vrstice.
- Urejanje prikazanih podatkov (maskiranje) je, ko uporabniki v enem stolpcu tabele vidijo podatke ali samo zvezdice, kar pomeni, da bodo za nekatere uporabnike informacije zaprte. Tehnologija določa, kateremu uporabniku je kaj prikazano glede na njegovo raven dostopa.
- Pri nadzoru dostopa DBA/Application DBA/DBA gre bolj za omejevanje dostopa do samega DBMS, to pomeni, da je zaposlene na področju informacijske varnosti mogoče ločiti od skrbnikov baz podatkov in skrbnikov aplikacij. V odprti kodi je takih tehnologij malo, v komercialnih DBMS pa jih je veliko. Potrebni so, ko je veliko uporabnikov z dostopom do samih strežnikov.
- Omejitev dostopa do datotek na ravni datotečnega sistema. Imenikom lahko dodelite pravice in privilegije za dostop, tako da ima vsak skrbnik dostop samo do potrebnih podatkov.
- Obvezen dostop in brisanje pomnilnika - te tehnologije se redko uporabljajo.
- Šifriranje od konca do konca neposredno iz DBMS je šifriranje na strani odjemalca z upravljanjem ključev na strani strežnika.
- Šifriranje podatkov. Na primer, stolpčno šifriranje je, ko uporabite mehanizem, ki šifrira en sam stolpec baze podatkov.
Kako to vpliva na delovanje DBMS?
Oglejmo si primer stolpčnega šifriranja v PostgreSQL. Obstaja modul pgcrypto, ki vam omogoča shranjevanje izbranih polj v šifrirani obliki. To je uporabno, kadar so dragoceni samo nekateri podatki. Za branje šifriranih polj odjemalec pošlje ključ za dešifriranje, strežnik dešifrira podatke in jih vrne odjemalcu. Brez ključa nihče ne more narediti ničesar z vašimi podatki.
Preizkusimo s pgcrypto. Ustvarimo tabelo s šifriranimi podatki in navadnimi podatki. Spodaj so ukazi za ustvarjanje tabel, v prvi vrstici je uporaben ukaz - ustvarjanje same razširitve z registracijo 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'));Nato poskusimo narediti vzorec podatkov iz vsake tabele in si oglejmo čase izvajanja.
Izbiranje iz tabele brez funkcije šifriranja:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtŠtoparica je vklopljena.
id | besedilo1 | besedilo2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 vrstic)
Čas: 1,386 ms
Izbira iz tabele s funkcijo š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Štoparica je vklopljena.
id | dešifrirati | dešifrirati
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 vrstic)
Čas: 50,203 ms
Rezultati testiranja:
Brez šifriranja
Pgcrypto (dešifriranje)
Vzorec 1000 vrstic
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Šifriranje ima velik vpliv na zmogljivost. Vidimo lahko, da se je čas povečal, saj operacije dešifriranja šifriranih podatkov (in dešifriranje je običajno še vedno zavito v vašo logiko) zahtevajo znatna sredstva. To pomeni, da je zamisel o šifriranju vseh stolpcev, ki vsebujejo nekaj podatkov, polna zmanjšanja zmogljivosti.
Vendar pa šifriranje ni rešitev, ki bi rešila vse težave. Dešifrirani podatki in ključ za dešifriranje med procesom dešifriranja in prenosa podatkov se nahajajo na strežniku. Zato lahko ključe prestreže nekdo, ki ima poln dostop do strežnika baze podatkov, na primer sistemski skrbnik.
Ko obstaja en ključ za celoten stolpec za vse uporabnike (tudi če ne za vse, ampak za stranke omejenega nabora), to ni vedno dobro in pravilno. Zato so začeli izvajati šifriranje od konca do konca, v DBMS so začeli razmišljati o možnostih šifriranja podatkov na strani odjemalca in strežnika in pojavili so se ti isti shrambe trezorjev ključev - ločeni izdelki, ki zagotavljajo upravljanje ključev na DBMS. strani.
Varnostne funkcije v komercialnih in odprtokodnih DBMS
Funkcije
Tip
Politika gesla
Revizija
Zaščita izvorne kode postopkov in funkcij
RLS
šifriranje
Oracle
komercialni
+
+
+
+
+
MsSql
komercialni
+
+
+
+
+
komercialni
+
+
+
+
razširitve
PostgreSQL
brezplačno
razširitve
razširitve
-
+
razširitve
MongoDb
brezplačno
-
+
-
-
Na voljo samo v MongoDB Enterprise
Tabela še zdaleč ni popolna, vendar je stanje takšno: v komercialnih izdelkih so varnostni problemi že dolgo rešeni, v odprtokodnih se za varnost praviloma uporabljajo nekakšni dodatki, veliko funkcij manjka , včasih je treba kaj dodati. Na primer pravilniki o geslih - PostgreSQL ima veliko različnih razširitev (, , , , ), ki izvajajo politike gesel, vendar po mojem mnenju nobena ne pokriva vseh potreb domačega korporativnega segmenta.
Kaj storiti, če nikjer nimate tistega, kar potrebujete? Na primer, želite uporabiti določen DBMS, ki nima funkcij, ki jih zahteva stranka.
Nato lahko uporabite rešitve tretjih oseb, ki delujejo z različnimi DBMS, na primer Crypto DB ali Garda DB. Če govorimo o rešitvah iz domačega segmenta, potem o GOST-ih vedo bolje kot v odprti kodi.
Druga možnost je, da sami napišete, kar potrebujete, implementirate dostop do podatkov in šifriranje v aplikaciji na nivoju procedure. Res je, z GOST bo težje. Toda na splošno lahko podatke po potrebi skrijete, jih postavite v DBMS, nato jih po potrebi pridobite in dešifrirate, prav na ravni aplikacije. Ob tem takoj pomislite, kako boste zaščitili te algoritme v aplikaciji. Po našem mnenju je treba to narediti na ravni DBMS, ker bo delovalo hitreje.
To poročilo je bilo prvič predstavljeno na avtor Mail.ru Cloud Solutions. Poglejdruge predstave in se naročite na obvestila o dogodkih na Telegramu .
Kaj še prebrati na to temo:
- .
- .
Vir: www.habr.com