Volám sa Denis Rozhkov, som vedúcim vývoja softvéru v spoločnosti Gazinformservice v produktovom tíme . Legislatíva a podnikové predpisy kladú určité požiadavky na bezpečnosť ukladania údajov. Nikto nechce, aby tretie strany získali prístup k dôverným informáciám, preto sú pre každý projekt dôležité tieto otázky: identifikácia a autentifikácia, riadenie prístupu k údajom, zabezpečenie integrity informácií v systéme, zaznamenávanie bezpečnostných udalostí. Preto chcem hovoriť o niektorých zaujímavých bodoch týkajúcich sa bezpečnosti DBMS.
Článok bol pripravený na základe prejavu o organizovaný . Ak sa vám nechce čítať, môžete si pozrieť:
Článok bude mať tri časti:
- Ako zabezpečiť spojenia.
- Čo je audit akcií a ako zaznamenávať, čo sa deje na strane databázy a pripájať sa k nej.
- Ako chrániť údaje v samotnej databáze a aké technológie sú na to k dispozícii.
Tri komponenty zabezpečenia DBMS: ochrana pripojenia, audit činnosti a ochrana údajov
Zabezpečenie vašich spojení
K databáze sa môžete pripojiť buď priamo, alebo nepriamo cez webové aplikácie. Firemný používateľ, teda osoba, ktorá pracuje s DBMS, s ním spravidla nepriamo interaguje.
Predtým, ako budete hovoriť o ochrane pripojení, musíte odpovedať na dôležité otázky, ktoré určujú, ako budú bezpečnostné opatrenia štruktúrované:
- Je jeden podnikový používateľ ekvivalentný jednému používateľovi DBMS?
- či je prístup k údajom DBMS poskytovaný iba prostredníctvom rozhrania API, ktoré riadite, alebo či sa k tabuľkám pristupuje priamo;
- či je DBMS pridelený samostatnému chránenému segmentu, kto a ako s ním interaguje;
- či sa používajú združovacie/proxy a medzivrstvy, čo môže zmeniť informácie o tom, ako sa vytvára spojenie a kto používa databázu.
Teraz sa pozrime, aké nástroje možno použiť na zabezpečenie pripojení:
- Použite riešenia triedy databázového firewallu. Dodatočná vrstva ochrany minimálne zvýši transparentnosť toho, čo sa deje v DBMS, a maximálne budete môcť poskytnúť dodatočnú ochranu údajov.
- Používajte zásady hesiel. Ich použitie závisí od toho, ako je postavená vaša architektúra. V každom prípade jedno heslo v konfiguračnom súbore webovej aplikácie, ktorá sa pripája k DBMS, na ochranu nestačí. Existuje množstvo nástrojov DBMS, ktoré vám umožňujú kontrolovať, že používateľ a heslo vyžadujú aktualizáciu.
Môžete si prečítať viac o funkciách hodnotenia používateľov , môžete sa tiež dozvedieť o MS SQL Vulnerability Assessmen .
- Obohaťte kontext relácie o potrebné informácie. Ak je relácia neprehľadná, nerozumiete, kto pracuje v DBMS v jej rámci, môžete v rámci vykonávanej operácie doplniť informácie o tom, kto čo robí a prečo. Tieto informácie je možné vidieť v audite.
- Nakonfigurujte SSL, ak nemáte sieťové oddelenie medzi DBMS a koncovými používateľmi; nie je v samostatnej VLAN. V takýchto prípadoch je nevyhnutné chrániť kanál medzi spotrebiteľom a samotným DBMS. Bezpečnostné nástroje sú dostupné aj v open source.
Ako to ovplyvní výkon DBMS?
Pozrime sa na príklad PostgreSQL, aby sme videli, ako SSL ovplyvňuje zaťaženie CPU, zvyšuje časovanie a znižuje TPS a či nebude spotrebovávať príliš veľa zdrojov, ak ho povolíte.
Načítanie PostgreSQL pomocou pgbench je jednoduchý program na spustenie výkonnostných testov. Opakovane vykonáva jednu sekvenciu príkazov, prípadne v paralelných databázových reláciách, a potom vypočítava priemernú rýchlosť transakcie.
Test 1 bez SSL a pomocou SSL — spojenie sa vytvorí pre každú transakciu:
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 pomocou SSL — všetky transakcie sa vykonávajú v jednom spojení:
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"Iné nastavenia:
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/50000Výsledky testu:
ŽIADNE SSL
SSL
Pre každú transakciu sa vytvorí spojenie
priemerná latencia
171.915 ms
187.695 ms
tps vrátane nadväzovania spojení
58.168112
53.278062
tps okrem nadväzovania pripojení
64.084546
58.725846
CPU
24%
28%
Všetky transakcie sa vykonávajú v jednom spojení
priemerná latencia
6.722 ms
6.342 ms
tps vrátane nadväzovania spojení
1587.657278
1576.792883
tps okrem nadväzovania pripojení
1588.380574
1577.694766
CPU
17%
21%
Pri nízkej záťaži je vplyv SSL porovnateľný s chybou merania. Ak je množstvo prenesených dát veľmi veľké, situácia môže byť iná. Ak vytvoríme jedno pripojenie na transakciu (je to zriedkavé, zvyčajne je pripojenie zdieľané medzi používateľmi), máte veľký počet pripojení/odpojení, vplyv môže byť o niečo väčší. To znamená, že môžu existovať riziká zníženia výkonu, rozdiel však nie je taký veľký, aby sa nepoužívala ochrana.
Upozorňujeme, že existuje veľký rozdiel, ak porovnáte prevádzkové režimy: pracujete v rámci rovnakej relácie alebo v rôznych režimoch. Je to pochopiteľné: zdroje sa vynakladajú na vytvorenie každého spojenia.
Mali sme prípad, keď sme pripojili Zabbix v režime dôvery, to znamená, že md5 nebolo skontrolované, nebolo potrebné autentifikovať. Potom zákazník požiadal o povolenie režimu autentifikácie md5. To spôsobilo veľké zaťaženie CPU a výkon klesol. Začali sme hľadať spôsoby optimalizácie. Jedným z možných riešení problému je implementácia sieťových obmedzení, vytvorenie samostatných VLAN pre DBMS, pridanie nastavení, aby bolo jasné, kto sa odkiaľ pripája, a odstránenie autentifikácie Môžete tiež optimalizovať nastavenia autentifikácie, aby ste znížili náklady pri povolení autentifikácie, ale vo všeobecnosti použitie rôznych metód autentifikácie ovplyvňuje výkon a vyžaduje zohľadnenie týchto faktorov pri navrhovaní výpočtového výkonu serverov (hardvéru) pre DBMS.
Záver: v mnohých riešeniach môžu aj malé nuansy v autentifikácii výrazne ovplyvniť projekt a je zlé, keď sa to prejaví až pri implementácii vo výrobe.
Akčný audit
Audit môže byť nielen DBMS. Audit je o získavaní informácií o dianí v rôznych segmentoch. Môže to byť buď databázový firewall alebo operačný systém, na ktorom je postavená DBMS.
V komerčnej podnikovej úrovni DBMS je všetko v poriadku s auditom, ale v open source - nie vždy. Tu je to, čo má PostgreSQL:
- predvolený protokol - vstavané protokolovanie;
- rozšírenia: pgaudit - ak vám štandardné protokolovanie nestačí, môžete použiť samostatné nastavenia, ktoré vyriešia niektoré problémy.
Dodatok k správe vo videu:
"Základné protokolovanie výpisov môže byť zabezpečené štandardným protokolovacím zariadením s log_statement = all.
To je prijateľné na monitorovanie a iné použitie, ale neposkytuje úroveň podrobností, ktorá sa zvyčajne vyžaduje pre audit.
Nestačí mať zoznam všetkých operácií vykonaných v databáze.
Malo by byť možné nájsť aj konkrétne vyhlásenia, ktoré sú pre audítora zaujímavé.
Štandardné protokolovanie zobrazuje, čo používateľ požadoval, zatiaľ čo pgAudit sa zameriava na podrobnosti o tom, čo sa stalo, keď databáza vykonala dotaz.
Audítor môže napríklad chcieť overiť, či bola konkrétna tabuľka vytvorená v rámci zdokumentovaného okna údržby.
Môže sa to zdať ako jednoduchá úloha so základným auditom a grep, ale čo keby ste dostali niečo také (zámerne mätúce) príklad:
DO$$
ZAČAŤ
VYKONAŤ „CREATE TABLE import“ || 'ant_table(id int)';
KONIEC $$;
Štandardné protokolovanie vám poskytne toto:
LOG: výpis: DO $$
ZAČAŤ
VYKONAŤ „CREATE TABLE import“ || 'ant_table(id int)';
KONIEC $$;
Zdá sa, že nájdenie tabuľky záujmu môže vyžadovať určité znalosti kódu v prípadoch, keď sa tabuľky vytvárajú dynamicky.
Toto nie je ideálne, pretože by bolo vhodnejšie jednoducho vyhľadávať podľa názvu tabuľky.
Tu sa hodí pgAudit.
Pre rovnaký vstup vytvorí tento výstup v protokole:
AUDIT: SESSION,33,1,FUNCTION,DO,,,,DO $$
ZAČAŤ
VYKONAŤ „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)
Zaprotokoluje sa nielen blok DO, ale aj úplný text CREATE TABLE s typom príkazu, typom objektu a celým menom, čo uľahčuje vyhľadávanie.
Pri protokolovaní príkazov SELECT a DML možno pgAudit nakonfigurovať tak, aby zaznamenával samostatnú položku pre každý vzťah uvedený v príkaze.
Na nájdenie všetkých príkazov, ktoré sa dotýkajú konkrétnej tabuľky, nie je potrebná žiadna analýza () ».
Ako to ovplyvní výkon DBMS?
Poďme spustiť testy so zapnutým úplným auditom a uvidíme, čo sa stane s výkonom PostgreSQL. Povoľme maximálne protokolovanie databázy pre všetky parametre.
V konfiguračnom súbore nemeníme takmer nič, najdôležitejšie je zapnúť režim debug5, aby sme získali maximum informácií.
postgresql.conf
log_destination = 'stderr'
logging_collector = zapnuté
log_truncate_on_rotation = zapnuté
log_rotation_age = 1 d
log_rotation_size = 10 MB
log_min_messages = ladenie5
log_min_error_statement = ladenie5
log_min_duration_statement = 0
debug_print_parse = zapnuté
debug_print_rewritten = zapnuté
debug_print_plan = zapnuté
debug_pretty_print = zapnuté
log_checkpoints = zapnuté
log_connections = zapnuté
log_disconnections = zapnuté
log_duration = zapnuté
log_hostname = zapnuté
log_lock_wait = zapnuté
log_replication_commands = zapnuté
log_temp_files = 0
log_timezone = 'Európa/Moskva'
Na PostgreSQL DBMS s parametrami 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD vykonáme tri záťažové testy pomocou príkazov:
$ 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 benchmarkVýsledky testu:
Žiadne protokolovanie
S ťažbou dreva
Celkový čas naplnenia databázy
43,74 sek
53,23 sek
RAM
24%
40%
CPU
72%
91%
Test 1 (50 spojení)
Počet transakcií za 10 minút
74169
32445
Transakcie/sek
123
54
Priemerná latencia
405 ms
925 ms
Test 2 (150 spojení so 100 možnými)
Počet transakcií za 10 minút
81727
31429
Transakcie/sek
136
52
Priemerná latencia
550 ms
1432 ms
O veľkostiach
Veľkosť DB
2251 MB
2262 MB
Veľkosť denníka databázy
0 Мб
4587 Мб
Zrátané a podčiarknuté: úplný audit nie je veľmi dobrý. Údaje z auditu budú rovnako veľké ako údaje v samotnej databáze, prípadne aj viac. Množstvo protokolovania, ktoré sa generuje pri práci s DBMS, je bežným problémom vo výrobe.
Pozrime sa na ďalšie parametre:
- Rýchlosť sa príliš nemení: bez protokolovania - 43,74 sekundy, s protokolom - 53,23 sekundy.
- Utrpí tým výkon pamäte RAM a procesora, pretože musíte vygenerovať súbor auditu. Vidno to aj na produktivite.
So zvyšujúcim sa počtom pripojení sa výkon prirodzene mierne zhorší.
V korporáciách s auditom je to ešte ťažšie:
- existuje veľa údajov;
- auditovanie je potrebné nielen cez syslog v SIEM, ale aj v súboroch: ak sa niečo stane so syslogom, blízko databázy musí byť súbor, v ktorom sú dáta uložené;
- na audit je potrebná samostatná polica, aby sa neplytvali vstupno-výstupnými diskami, pretože zaberajú veľa miesta;
- Stáva sa, že zamestnanci informačnej bezpečnosti potrebujú normy GOST všade, vyžadujú štátnu identifikáciu.
Obmedzenie prístupu k údajom
Pozrime sa na technológie, ktoré sa používajú na ochranu údajov a prístup k nim v komerčných DBMS a open source.
Čo môžete vo všeobecnosti použiť:
- Šifrovanie a zahmlievanie procedúr a funkcií (Wrapping) – teda samostatné nástroje a utility, ktoré robia čitateľný kód nečitateľným. Pravda, potom sa to nedá zmeniť ani prefaktorovať späť. Tento prístup sa niekedy vyžaduje aspoň na strane DBMS - logika licenčných obmedzení alebo logika autorizácie je šifrovaná presne na úrovni procedúry a funkcie.
- Obmedzenie viditeľnosti údajov podľa riadkov (RLS) nastáva vtedy, keď rôzni používatelia vidia jednu tabuľku, ale iné zloženie riadkov v nej, to znamená, že na úrovni riadkov sa niekomu niečo nedá zobraziť.
- Úprava zobrazených údajov (Maskovanie) je, keď používatelia v jednom stĺpci tabuľky vidia buď údaje alebo iba hviezdičky, to znamená, že pre niektorých používateľov budú informácie zatvorené. Technológia určuje, ktorému používateľovi sa čo zobrazí na základe jeho úrovne prístupu.
- Zabezpečenie DBA/Aplikácia Riadenie prístupu DBA/DBA je skôr o obmedzení prístupu k samotnému DBMS, to znamená, že zamestnanci informačnej bezpečnosti môžu byť oddelení od správcov databáz a správcov aplikácií. Takýchto technológií je v open source málo, no v komerčných DBMS je ich dosť. Sú potrebné, keď je veľa používateľov s prístupom k samotným serverom.
- Obmedzenie prístupu k súborom na úrovni súborového systému. Adresárom môžete udeliť práva a prístupové oprávnenia, aby mal každý administrátor prístup len k potrebným údajom.
- Povinný prístup a vymazanie pamäte - tieto technológie sa používajú zriedka.
- End-to-end šifrovanie priamo z DBMS je šifrovanie na strane klienta so správou kľúčov na strane servera.
- Šifrovanie údajov. Napríklad stĺpcové šifrovanie je, keď používate mechanizmus, ktorý šifruje jeden stĺpec databázy.
Ako to ovplyvní výkon DBMS?
Pozrime sa na príklad stĺpcového šifrovania v PostgreSQL. Existuje modul pgcrypto, umožňuje ukladať vybrané polia v šifrovanej podobe. To je užitočné, keď sú cenné iba niektoré údaje. Na prečítanie zašifrovaných polí klient odošle dešifrovací kľúč, server dešifruje údaje a vráti ich klientovi. Bez kľúča nikto s vašimi údajmi nič neurobí.
Poďme otestovať s pgcrypto. Vytvorme tabuľku so zašifrovanými údajmi a bežnými údajmi. Nižšie sú uvedené príkazy na vytváranie tabuliek, hneď v prvom riadku je užitočný príkaz - vytvorenie samotného rozšírenia s registráciou 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'));Ďalej sa pokúsme vytvoriť vzorku údajov z každej tabuľky a pozrieť sa na načasovanie vykonania.
Výber z tabuľky bez funkcie šifrovania:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtStopky sú zapnuté.
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 riadkov)
Čas: 1,386 ms
Výber z tabuľky s funkciou šifrovania:
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.txtStopky sú zapnuté.
id | dešifrovať | dešifrovať
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 riadkov)
Čas: 50,203 ms
Výsledky testu:
Bez šifrovania
Pgcrypto (dešifrovať)
Ukážka 1000 riadkov
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Šifrovanie má veľký vplyv na výkon. Je vidieť, že načasovanie sa zvýšilo, pretože dešifrovacie operácie šifrovaných údajov (a dešifrovanie je zvyčajne stále zabalené vo vašej logike) vyžadujú značné zdroje. To znamená, že myšlienka šifrovania všetkých stĺpcov obsahujúcich nejaké údaje je spojená so znížením výkonu.
Šifrovanie však nie je strieborná guľka, ktorá vyrieši všetky problémy. Dešifrované údaje a dešifrovací kľúč počas procesu dešifrovania a prenosu údajov sa nachádzajú na serveri. Kľúče preto môže zachytiť niekto, kto má úplný prístup k databázovému serveru, napríklad správca systému.
Keď existuje jeden kľúč pre celý stĺpec pre všetkých používateľov (aj keď nie pre všetkých, ale pre klientov obmedzenej množiny), nie je to vždy dobré a správne. Preto začali robiť šifrovanie typu end-to-end, v DBMS začali zvažovať možnosti šifrovania údajov na strane klienta a servera a objavili sa tie isté úložiská kľúčov - samostatné produkty, ktoré poskytujú správu kľúčov na DBMS. strane.
Bezpečnostné funkcie v komerčných a open source DBMS
Funkcia
Typ
Zásady hesiel
Audit
Ochrana zdrojového kódu procedúr a funkcií
RLS
Šifrovanie
veštec
komerčný
+
+
+
+
+
MsSql
komerčný
+
+
+
+
+
komerčný
+
+
+
+
rozšírenie
PostgreSQL
zdarma
rozšírenie
rozšírenie
-
+
rozšírenie
MongoDb
zdarma
-
+
-
-
Dostupné iba v MongoDB Enterprise
Tabuľka nie je ani zďaleka úplná, ale situácia je takáto: v komerčných produktoch sa bezpečnostné problémy riešia už dlho, v open source sa na zabezpečenie spravidla používajú nejaké doplnky, veľa funkcií chýba , občas treba niečo pridať. Napríklad zásady hesiel – PostgreSQL má mnoho rôznych rozšírení (, , , , ), ktoré implementujú politiku hesiel, no ani jedna podľa mňa nepokrýva všetky potreby domáceho firemného segmentu.
Čo robiť, ak nikde nemáte to, čo potrebujete? Napríklad chcete použiť špecifický DBMS, ktorý nemá funkcie, ktoré požaduje zákazník.
Potom môžete použiť riešenia tretích strán, ktoré pracujú s rôznymi DBMS, napríklad Crypto DB alebo Garda DB. Ak hovoríme o riešeniach z domáceho segmentu, potom vedia o GOST lepšie ako v open source.
Druhou možnosťou je napísať si čo potrebujete sami, implementovať prístup k dátam a šifrovanie v aplikácii na úrovni procedúry. Je pravda, že s GOST to bude ťažšie. Vo všeobecnosti však môžete údaje podľa potreby skryť, vložiť ich do DBMS, potom ich načítať a dešifrovať podľa potreby priamo na úrovni aplikácie. Zároveň okamžite premýšľajte o tom, ako budete tieto algoritmy v aplikácii chrániť. Podľa nášho názoru by sa to malo robiť na úrovni DBMS, pretože to bude fungovať rýchlejšie.
Táto správa bola prvýkrát prezentovaná na od Mail.ru Cloud Solutions. Pozriiné predstavenia a prihláste sa na odber oznamov o udalostiach na Telegrame .
Čo si ešte prečítať k téme:
- .
- .
Zdroj: hab.com