Jmenuji se Denis Rozhkov, jsem vedoucím vývoje softwaru ve společnosti Gazinformservice v produktovém týmu . Legislativa a podnikové předpisy kladou určité požadavky na bezpečnost ukládání dat. Nikdo nechce, aby třetí strany získaly přístup k důvěrným informacím, proto jsou pro jakýkoli projekt důležité následující otázky: identifikace a autentizace, správa přístupu k datům, zajištění integrity informací v systému, protokolování bezpečnostních událostí. Proto chci mluvit o některých zajímavých bodech týkajících se bezpečnosti DBMS.
Článek byl připraven na základě projevu v organizovaný . Pokud se vám nechce číst, můžete se podívat:
Článek bude mít tři části:
- Jak zabezpečit spojení.
- Co je audit akcí a jak zaznamenávat, co se děje na straně databáze a připojování k ní.
- Jak chránit data v samotné databázi a jaké technologie jsou k tomu k dispozici.
Tři součásti zabezpečení DBMS: ochrana připojení, auditování činnosti a ochrana dat
Zabezpečení vašich spojení
K databázi se můžete připojit buď přímo, nebo nepřímo prostřednictvím webových aplikací. Firemní uživatel, tedy osoba, která pracuje s DBMS, s ním zpravidla nepřímo interaguje.
Než začnete mluvit o ochraně připojení, musíte si odpovědět na důležité otázky, které určují, jak budou bezpečnostní opatření strukturována:
- Je jeden podnikový uživatel ekvivalentní jednomu uživateli DBMS?
- zda je přístup k datům DBMS poskytován pouze prostřednictvím rozhraní API, které řídíte, nebo zda je k tabulkám přistupováno přímo;
- zda je DBMS přiřazen k samostatnému chráněnému segmentu, kdo a jak s ním interaguje;
- zda se používají sdružovací/proxy a mezivrstvy, což může změnit informace o tom, jak je spojení vytvořeno a kdo používá databázi.
Nyní se podívejme, jaké nástroje lze použít k zabezpečení připojení:
- Použijte řešení třídy databázového firewallu. Další vrstva ochrany minimálně zvýší transparentnost toho, co se děje v DBMS, a maximálně budete moci poskytnout další ochranu dat.
- Používejte zásady hesel. Jejich použití závisí na tom, jak je vaše architektura postavena. V každém případě jedno heslo v konfiguračním souboru webové aplikace, která se připojuje k DBMS, k ochraně nestačí. Existuje řada nástrojů DBMS, které vám umožňují kontrolovat, že uživatel a heslo vyžadují aktualizaci.
Můžete si přečíst více o funkcích hodnocení uživatelů , můžete se také dozvědět o MS SQL Vulnerability Assessmen .
- Obohaťte kontext sezení o potřebné informace. Pokud je relace neprůhledná, nerozumíte, kdo v rámci DBMS pracuje, můžete v rámci prováděné operace doplnit informace o tom, kdo co dělá a proč. Tyto informace lze vidět v auditu.
- Nakonfigurujte SSL, pokud nemáte síťové oddělení mezi DBMS a koncovými uživateli; není v samostatné VLAN. V takových případech je nutné chránit kanál mezi spotřebitelem a samotným DBMS. Bezpečnostní nástroje jsou k dispozici také v open source.
Jak to ovlivní výkon DBMS?
Podívejme se na příklad PostgreSQL, abychom viděli, jak SSL ovlivňuje zatížení CPU, zvyšuje časování a snižuje TPS a zda nebude spotřebovávat příliš mnoho zdrojů, pokud jej povolíte.
Načítání PostgreSQL pomocí pgbench je jednoduchý program pro spouštění výkonnostních testů. Opakovaně provádí jedinou sekvenci příkazů, případně v paralelních databázových relacích, a poté vypočítává průměrnou rychlost transakce.
Test 1 bez SSL a pomocí SSL — spojení je navázáno pro každou transakci:
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 pomocí SSL — všechny transakce se provádějí 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"Další nastavení:
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 zkoušek:
ŽÁDNÉ SSL
SSL
Pro každou transakci je navázáno spojení
průměr latence
171.915 ms
187.695 ms
tps včetně navazování spojení
58.168112
53.278062
tps s výjimkou navazování spojení
64.084546
58.725846
procesor
24%
28%
Všechny transakce probíhají v jednom spojení
průměr latence
6.722 ms
6.342 ms
tps včetně navazování spojení
1587.657278
1576.792883
tps s výjimkou navazování spojení
1588.380574
1577.694766
procesor
17%
21%
Při malé zátěži je vliv SSL srovnatelný s chybou měření. Pokud je objem přenesených dat velmi velký, situace může být jiná. Pokud navážeme jedno připojení na transakci (toto je vzácné, obvykle je připojení sdíleno mezi uživateli), máte velký počet připojení/odpojení, dopad může být o něco větší. To znamená, že mohou existovat rizika snížení výkonu, ale rozdíl není tak velký, aby se nepoužila ochrana.
Vezměte prosím na vědomí, že existuje velký rozdíl, pokud porovnáte provozní režimy: pracujete ve stejné relaci nebo v různých režimech. To je pochopitelné: zdroje jsou vynakládány na vytvoření každého připojení.
Měli jsme případ, kdy jsme připojili Zabbix v režimu důvěry, to znamená, že md5 nebylo zkontrolováno, nebylo potřeba autentizace. Poté zákazník požádal o povolení režimu ověřování md5. To způsobilo velké zatížení CPU a výkon klesl. Začali jsme hledat cesty k optimalizaci. Jedním z možných řešení problému je implementace síťových omezení, vytvoření samostatných VLAN pro DBMS, přidání nastavení, aby bylo jasné, kdo se odkud připojuje a odebrání autentizace. Můžete také optimalizovat nastavení autentizace, abyste snížili náklady při povolení autentizace, ale obecně použití různých metod autentizace ovlivňuje výkon a vyžaduje zohlednění těchto faktorů při navrhování výpočetního výkonu serverů (hardwaru) pro DBMS.
Závěr: v řadě řešení mohou i malé nuance v autentizaci výrazně ovlivnit projekt a je špatné, když se to ukáže až při implementaci ve výrobě.
Akční audit
Audit může být nejen DBMS. Audit je o získávání informací o tom, co se děje v různých segmentech. Může to být buď databázový firewall, nebo operační systém, na kterém je DBMS postaven.
V komerčních DBMS na podnikové úrovni je vše v pořádku s auditováním, ale v open source - ne vždy. Zde je to, co PostgreSQL má:
- výchozí protokol - vestavěné protokolování;
- rozšíření: pgaudit - pokud vám výchozí protokolování nestačí, můžete použít samostatné nastavení, které řeší některé problémy.
Dodatek k reportáži ve videu:
"Základní protokolování příkazů lze zajistit standardním protokolovacím zařízením s log_statement = all.
To je přijatelné pro monitorování a další použití, ale neposkytuje úroveň podrobností, která se obvykle vyžaduje pro audit.
Nestačí mít seznam všech operací provedených v databázi.
Mělo by být také možné najít konkrétní prohlášení, která jsou pro auditora zajímavá.
Standardní protokolování ukazuje, co uživatel požadoval, zatímco pgAudit se zaměřuje na podrobnosti o tom, co se stalo, když databáze provedla dotaz.
Auditor může například chtít ověřit, že konkrétní tabulka byla vytvořena v rámci zdokumentovaného okna údržby.
Se základním auditováním a grep se to může zdát jako jednoduchý úkol, ale co kdybyste dostali něco takového (záměrně matoucí) příklad:
DO$$
ZAČÍT
PROVEĎTE 'CREATE TABLE import' || 'ant_table(id int)';
KONEC $$;
Standardní protokolování vám poskytne toto:
LOG: výpis: DO $$
ZAČÍT
PROVEĎTE 'CREATE TABLE import' || 'ant_table(id int)';
KONEC $$;
Zdá se, že nalezení požadované tabulky může vyžadovat určité znalosti kódu v případech, kdy jsou tabulky vytvářeny dynamicky.
To není ideální, protože by bylo vhodnější jednoduše hledat podle názvu tabulky.
Zde se hodí pgAudit.
Pro stejný vstup vytvoří tento výstup v protokolu:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
ZAČÍT
PROVEĎTE 'CREATE TABLE import' || 'ant_table(id int)';
KONEC$$;"
AUDIT: SESSION,33,2,DDL,CREATE TABLE,TABLE,public.important_table,CREATE TABLE important_table (id INT)
Protokoluje se nejen blok DO, ale také plný text CREATE TABLE s typem příkazu, typem objektu a celým jménem, což usnadňuje vyhledávání.
Při protokolování příkazů SELECT a DML lze pgAudit nakonfigurovat tak, aby protokoloval samostatnou položku pro každý vztah odkazovaný v příkazu.
K nalezení všech příkazů, které se dotýkají konkrétní tabulky, není nutná žádná analýza () ».
Jak to ovlivní výkon DBMS?
Pojďme spustit testy s povoleným úplným auditováním a uvidíme, co se stane s výkonem PostgreSQL. Povolme maximální protokolování databáze pro všechny parametry.
V konfiguračním souboru neměníme téměř nic, nejdůležitější je zapnout režim debug5, abychom získali maximum informací.
postgresql.conf
log_destination = 'stderr'
logging_collector = zapnuto
log_truncate_on_rotation = zapnuto
log_rotation_age = 1 d
log_rotation_size = 10 MB
log_min_messages = ladění5
log_min_error_statement = ladění5
log_min_duration_statement = 0
debug_print_parse = zapnuto
debug_print_rewritten = zapnuto
debug_print_plan = zapnuto
debug_pretty_print = zapnuto
log_checkpoints = zapnuto
log_connections = zapnuto
log_disconnections = zapnuto
log_duration = zapnuto
log_hostname = on
log_lock_wait = zapnuto
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Evropa/Moskva'
Na PostgreSQL DBMS s parametry 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD provádíme tři zátěžové testy pomocí příkazů:
$ 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 testů:
Žádné protokolování
S logováním
Celková doba naplnění databáze
43,74 sec
53,23 sec
RAM
24%
40%
procesor
72%
91%
Test 1 (50 připojení)
Počet transakcí za 10 minut
74169
32445
Transakce/sec
123
54
Průměrná latence
405 ms
925 ms
Test 2 (150 připojení se 100 možnými)
Počet transakcí za 10 minut
81727
31429
Transakce/sec
136
52
Průměrná latence
550 ms
1432 ms
O velikostech
Velikost DB
2251 MB
2262 MB
Velikost protokolu databáze
0 MB
4587 MB
Sečteno a podtrženo: úplný audit není příliš dobrý. Data z auditu budou stejně velká jako data v samotné databázi, nebo i více. Množství protokolování, které se generuje při práci s DBMS, je běžným problémem ve výrobě.
Podívejme se na další parametry:
- Rychlost se příliš nemění: bez protokolování - 43,74 sekund, s protokolováním - 53,23 sekund.
- Utrpí tím výkon RAM a CPU, protože je potřeba vygenerovat auditní soubor. Je to znát i na produktivitě.
S rostoucím počtem připojení se výkon přirozeně mírně zhorší.
V korporacích s auditem je to ještě obtížnější:
- existuje mnoho údajů;
- auditování je potřeba nejen přes syslog v SIEM, ale také v souborech: pokud se syslogu něco stane, blízko databáze musí být soubor, ve kterém jsou data uložena;
- pro audit je potřeba samostatná police, aby se neplýtvaly I/O disky, protože zabírají hodně místa;
- Stává se, že zaměstnanci informační bezpečnosti všude potřebují normy GOST, vyžadují státní identifikaci.
Omezení přístupu k datům
Podívejme se na technologie, které se používají k ochraně dat a přístupu k nim v komerčních DBMS a open source.
Co můžete obecně použít:
- Šifrování a obfuskace procedur a funkcí (Wrapping) – tedy samostatné nástroje a utility, díky kterým je čitelný kód nečitelný. Pravda, pak to nelze ani změnit, ani refaktorovat zpět. Tento přístup je někdy vyžadován alespoň na straně DBMS - logika licenčních omezení nebo logika autorizace je šifrována přesně na úrovni procedury a funkce.
- Omezení viditelnosti dat podle řádků (RLS) je, když různí uživatelé vidí jednu tabulku, ale jiné složení řádků v ní, to znamená, že na úrovni řádku nelze někomu něco ukázat.
- Editace zobrazených dat (Maskování) je, když uživatelé v jednom sloupci tabulky vidí buď data nebo pouze hvězdičky, to znamená, že pro některé uživatele budou informace uzavřeny. Technologie určuje, kterému uživateli se co zobrazí, na základě jeho úrovně přístupu.
- Zabezpečení DBA/Aplikace Řízení přístupu DBA/DBA je spíše o omezení přístupu k samotnému DBMS, to znamená, že zaměstnanci zabezpečení informací mohou být odděleni od administrátorů databází a administrátorů aplikací. V open source je takových technologií málo, ale v komerčních DBMS je jich spousta. Jsou potřeba, když je mnoho uživatelů s přístupem k samotným serverům.
- Omezení přístupu k souborům na úrovni systému souborů. Adresářům můžete udělit práva a přístupová oprávnění, takže každý administrátor má přístup pouze k nezbytným údajům.
- Povinný přístup a mazání paměti – tyto technologie se používají zřídka.
- End-to-end šifrování přímo z DBMS je šifrování na straně klienta se správou klíčů na straně serveru.
- Šifrování dat. Například sloupcové šifrování je, když používáte mechanismus, který šifruje jeden sloupec databáze.
Jak to ovlivní výkon DBMS?
Podívejme se na příklad sloupcového šifrování v PostgreSQL. Existuje modul pgcrypto, umožňuje ukládat vybraná pole v zašifrované podobě. To je užitečné, když jsou cenná pouze některá data. Pro čtení zašifrovaných polí klient odešle dešifrovací klíč, server dešifruje data a vrátí je klientovi. Bez klíče s vašimi daty nikdo nic neudělá.
Pojďme otestovat s pgcrypto. Vytvořme tabulku se zašifrovanými daty a běžnými daty. Níže jsou uvedeny příkazy pro vytváření tabulek, hned v prvním řádku je užitečný příkaz - vytvoření samotného rozšíření s registrací 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'));Dále zkusme vytvořit vzorek dat z každé tabulky a podívat se na časování provedení.
Výběr z tabulky bez funkce šifrování:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtStopky jsou 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 řádků)
Čas: 1,386 ms
Výběr z tabulky s funkcí šifrování:
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 jsou zapnuté.
id | dešifrovat | dešifrovat
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 řádků)
Čas: 50,203 ms
Výsledky zkoušek:
Bez šifrování
Pgcrypto (dešifrovat)
Ukázka 1000 řádků
1,386 ms
50,203 ms
procesor
15%
35%
RAM
+ 5%
Šifrování má velký vliv na výkon. Je vidět, že načasování se prodloužilo, protože dešifrovací operace zašifrovaných dat (a dešifrování je obvykle stále zabaleno do vaší logiky) vyžadují značné zdroje. To znamená, že myšlenka šifrování všech sloupců obsahujících některá data je plná poklesu výkonu.
Šifrování však není stříbrná kulka, která vyřeší všechny problémy. Dešifrovaná data a dešifrovací klíč během procesu dešifrování a přenosu dat jsou umístěny na serveru. Klíče tedy může zachytit někdo, kdo má plný přístup k databázovému serveru, jako je například správce systému.
Když existuje jeden klíč pro celý sloupec pro všechny uživatele (i když ne pro všechny, ale pro klienty omezené množiny), není to vždy dobré a správné. Proto začali dělat end-to-end šifrování, v DBMS začali zvažovat možnosti šifrování dat na straně klienta a serveru a objevila se stejná úložiště klíčů - samostatné produkty, které poskytují správu klíčů na DBMS boční.
Bezpečnostní funkce v komerčních a open source DBMS
funkce
Typ
Zásady hesla
Audit
Ochrana zdrojového kódu procedur a funkcí
RLS
Šifrování
Věštec
komerční
+
+
+
+
+
MsSql
komerční
+
+
+
+
+
komerční
+
+
+
+
rozšíření
PostgreSQL
Zdarma
rozšíření
rozšíření
-
+
rozšíření
MongoDb
Zdarma
-
+
-
-
K dispozici pouze v MongoDB Enterprise
Tabulka není zdaleka úplná, ale situace je taková: v komerčních produktech jsou problémy s bezpečností vyřešeny již dlouho, v open source se zpravidla používají nějaké doplňky pro zabezpečení, mnoho funkcí chybí , občas je potřeba něco přidat. Například zásady hesel – PostgreSQL má mnoho různých rozšíření (, , , , ), které implementují politiku hesel, ale žádná z nich podle mého názoru nepokrývá všechny potřeby tuzemského firemního segmentu.
Co dělat, když nikde nemáte to, co potřebujete? Chcete například použít konkrétní DBMS, která nemá funkce, které zákazník vyžaduje.
Pak můžete použít řešení třetích stran, která pracují s různými DBMS, například Crypto DB nebo Garda DB. Pokud mluvíme o řešeních z domácího segmentu, pak vědí o GOST lépe než v open source.
Druhou možností je napsat si sami, co potřebujete, implementovat přístup k datům a šifrování v aplikaci na úrovni procedury. Je pravda, že s GOST to bude obtížnější. Obecně ale můžete data podle potřeby skrýt, vložit je do DBMS, poté je načíst a dešifrovat podle potřeby přímo na úrovni aplikace. Zároveň okamžitě přemýšlejte o tom, jak budete tyto algoritmy v aplikaci chránit. Podle našeho názoru by to mělo být provedeno na úrovni DBMS, protože to bude fungovat rychleji.
Tato zpráva byla poprvé prezentována na od Mail.ru Cloud Solutions. Dívej sedalší představení a přihlaste se k odběru oznámení o událostech na Telegramu .
Co si k tématu ještě přečíst:
- .
- .
Zdroj: www.habr.com