A nevem Denis Rozhkov, a Gazinformservice cég szoftverfejlesztési vezetője vagyok, a termékcsapatban . A jogszabályok és a társasági szabályozás bizonyos követelményeket támaszt az adattárolás biztonságára vonatkozóan. Senki nem akarja, hogy harmadik felek hozzáférjenek bizalmas információkhoz, ezért minden projektnél fontosak a következő kérdések: azonosítás és hitelesítés, adatokhoz való hozzáférés kezelése, a rendszerben lévő információk sértetlenségének biztosítása, biztonsági események naplózása. Ezért szeretnék néhány érdekes pontról beszélni a DBMS biztonsággal kapcsolatban.
A cikk a címen elhangzott beszéd alapján készült szervezett . Ha nem akarsz olvasni, megnézheted:
A cikk három részből áll majd:
- Hogyan biztosítsuk a kapcsolatokat.
- Mi az a műveletek auditja, és hogyan kell rögzíteni, hogy mi történik az adatbázis-oldalon és csatlakozunk hozzá.
- Hogyan lehet megvédeni magában az adatbázisban lévő adatokat, és milyen technológiák állnak rendelkezésre ehhez.
A DBMS biztonság három összetevője: kapcsolatvédelem, tevékenység-auditálás és adatvédelem
A kapcsolatok biztosítása
Az adatbázishoz közvetlenül vagy közvetve webes alkalmazásokon keresztül csatlakozhat. Általános szabály, hogy az üzleti felhasználó, vagyis az a személy, aki a DBMS-sel dolgozik, közvetetten lép kapcsolatba vele.
Mielőtt a kapcsolatok védelméről beszélne, meg kell válaszolnia fontos kérdéseket, amelyek meghatározzák a biztonsági intézkedések felépítését:
- Egy üzleti felhasználó egyenértékű egy DBMS-felhasználóval?
- a DBMS-adatokhoz való hozzáférés csak az Ön által vezérelt API-n keresztül biztosított-e, vagy a táblákhoz közvetlenül hozzáférnek-e;
- hogy a DBMS külön védett szegmenshez van-e rendelve, ki és hogyan lép kapcsolatba vele;
- használnak-e pooling/proxy és köztes rétegeket, amelyek megváltoztathatják a kapcsolat felépítésével és az adatbázis használatával kapcsolatos információkat.
Most pedig nézzük meg, milyen eszközök használhatók a kapcsolatok biztonságossá tételére:
- Használjon adatbázis tűzfal osztályú megoldásokat. Egy további védelmi réteg legalább növeli a DBMS-ben történõ események átláthatóságát, és legfeljebb további adatvédelmet tud majd biztosítani.
- Használjon jelszószabályokat. Használatuk az architektúra felépítésétől függ. Mindenesetre egy jelszó a DBMS-hez csatlakozó webalkalmazás konfigurációs fájljában nem elegendő a védelemhez. Számos DBMS-eszköz létezik, amelyek lehetővé teszik annak vezérlését, hogy a felhasználót és a jelszót frissíteni kell-e.
A felhasználói értékelési funkciókról bővebben olvashat , tájékozódhat az MS SQL Vulnerability Assessmenről is .
- A szükséges információkkal gazdagítsa az ülés kontextusát. Ha a munkamenet átláthatatlan, nem érti, hogy ki dolgozik a DBMS-ben annak keretein belül, akkor az elvégzett művelet keretein belül információkat adhat hozzá arról, hogy ki mit és miért csinál. Ez az információ az auditon látható.
- Állítsa be az SSL-t, ha nincs hálózati elválasztása a DBMS és a végfelhasználók között; az nincs külön VLAN-ban. Ilyen esetekben elengedhetetlen a fogyasztó és maga a DBMS közötti csatorna védelme. A biztonsági eszközök nyílt forráskódban is elérhetők.
Hogyan befolyásolja ez a DBMS teljesítményét?
Nézzük meg a PostgreSQL példáját, hogy megtudjuk, hogyan befolyásolja az SSL a CPU terhelését, növeli az időzítéseket és csökkenti a TPS-t, és hogy túl sok erőforrást fog-e igénybe venni, ha engedélyezi.
A PostgreSQL betöltése a pgbench segítségével egy egyszerű program teljesítménytesztek futtatására. Egyetlen parancssorozatot hajt végre ismételten, esetleg párhuzamos adatbázis-munkamenetekben, majd kiszámítja az átlagos tranzakciós arányt.
1. teszt SSL nélkül és SSL használatával — a kapcsolat minden egyes tranzakcióhoz létrejön:
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"2. teszt SSL nélkül és SSL használatával — az összes tranzakciót egy kapcsolatban hajtják végre:
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"Egyéb beállitások:
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/50000Teszteredmények:
NINCS SSL
SSL
Minden tranzakcióhoz kapcsolat jön létre
latencia átlaga
171.915 ms
187.695 ms
tps, beleértve a kapcsolatok létrehozását
58.168112
53.278062
tps, kivéve a kapcsolatok létrehozását
64.084546
58.725846
CPU
24%
28%
Az összes tranzakció egy kapcsolatban történik
latencia átlaga
6.722 ms
6.342 ms
tps, beleértve a kapcsolatok létrehozását
1587.657278
1576.792883
tps, kivéve a kapcsolatok létrehozását
1588.380574
1577.694766
CPU
17%
21%
Kis terhelésnél az SSL hatása összemérhető a mérési hibával. Ha az átvitt adatmennyiség nagyon nagy, a helyzet más lehet. Ha tranzakciónként egy kapcsolatot hozunk létre (ez ritka, általában a felhasználók megosztják a kapcsolatot), akkor nagyszámú csatlakozása/lekapcsolása van, a hatás egy kicsit nagyobb lehet. Vagyis fennállhat a teljesítménycsökkenés kockázata, azonban a különbség nem akkora, hogy ne használjunk védelmet.
Kérjük, vegye figyelembe, hogy a működési módok összehasonlításakor jelentős különbségek vannak: ugyanazon a munkameneten belül vagy különböző munkamenetekben dolgozik. Ez érthető: az egyes kapcsolatok létrehozására erőforrásokat költenek.
Volt olyan esetünk, amikor a Zabbixot bizalmi módban kötöttük, vagyis az md5-öt nem ellenőrizték, nem kellett hitelesítés. Ezután az ügyfél kérte az md5 hitelesítési mód engedélyezését. Ez nagy terhelést rótt a CPU-ra, és csökkent a teljesítmény. Elkezdtük keresni az optimalizálási módokat. A probléma egyik lehetséges megoldása a hálózati korlátozások bevezetése, külön VLAN-ok készítése a DBMS-hez, olyan beállítások hozzáadása, amelyek egyértelművé teszik, hogy ki honnan csatlakozik, valamint a hitelesítés eltávolítása A hitelesítés engedélyezése során a költségek csökkentése érdekében optimalizálni is lehet a hitelesítési beállításokat, de Általánosságban elmondható, hogy a különböző hitelesítési módszerek alkalmazása befolyásolja a teljesítményt, és ezeket a tényezőket figyelembe kell venni a szerverek (hardverek) számítási teljesítményének tervezésekor a DBMS-hez.
Következtetés: számos megoldásnál a hitelesítés apró árnyalatai is nagymértékben befolyásolhatják a projektet, és rossz, ha ez csak a termelésben való bevezetéskor válik világossá.
Cselekvési audit
Az audit nem csak DBMS lehet. Az audit arról szól, hogy információt szerezzünk arról, hogy mi történik a különböző szegmensekben. Ez lehet adatbázistűzfal vagy az az operációs rendszer, amelyre a DBMS épül.
A kereskedelmi vállalati szintű DBMS-ekben minden rendben van az auditálással, de a nyílt forráskódú rendszerekben nem mindig. A PostgreSQL tartalma a következő:
- alapértelmezett napló - beépített naplózás;
- kiterjesztések: pgaudit - ha az alapértelmezett naplózás nem elegendő Önnek, használhat külön beállításokat, amelyek megoldanak bizonyos problémákat.
Kiegészítés a riporthoz a videóban:
"Az alapvető kimutatásnaplózást egy szabványos naplózási lehetőség biztosíthatja a log_statement = all értékkel.
Ez monitorozási és egyéb felhasználási célokra elfogadható, de nem biztosítja az auditáláshoz jellemzően szükséges részletességet.
Nem elég az adatbázison végrehajtott összes művelet listája.
Lehetővé kell tenni a könyvvizsgáló számára érdekes konkrét kijelentések megtalálását is.
A szabványos naplózás megmutatja, hogy a felhasználó mit kért, míg a pgAudit arra összpontosít, hogy mi történt, amikor az adatbázis végrehajtotta a lekérdezést.
Például az ellenőr ellenőrizheti, hogy egy adott tábla egy dokumentált karbantartási időszakon belül jött-e létre.
Ez egyszerű feladatnak tűnhet az alapvető auditálás és grep segítségével, de mi van, ha valami ehhez hasonló (szándékosan zavaró) példát mutatnak be:
DO$$
KEZDŐDIK
VÉGREHAJTÁS 'CREATE TABLE import' || 'ant_table(id int)';
END$$;
A normál naplózás a következőt adja:
LOG: utasítás: DO $$
KEZDŐDIK
VÉGREHAJTÁS 'CREATE TABLE import' || 'ant_table(id int)';
END$$;
Úgy tűnik, hogy a kívánt táblázat megtalálásához szükség lehet bizonyos kódismeretekre olyan esetekben, amikor a táblák dinamikusan jönnek létre.
Ez nem ideális, mivel jobb lenne egyszerűen a tábla neve alapján keresni.
Itt jön jól a pgAudit.
Ugyanerre a bemenetre a következő kimenetet állítja elő a naplóban:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
KEZDŐDIK
VÉGREHAJTÁS 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION,33,2,DDL,TÁBLÁZAT LÉTREHOZÁSA,TÁBLÁZAT,nyilvános.fontos_tábla,TÁBLÁZAT LÉTREHOZÁSA fontos_tábla (azonosító INT)
Nem csak a DO blokk kerül naplózásra, hanem a CREATE TABLE teljes szövege is utasítástípussal, objektumtípussal és teljes névvel, ami megkönnyíti a keresést.
A SELECT és DML utasítások naplózásakor a pgAudit beállítható úgy, hogy az utasításban hivatkozott minden kapcsolathoz külön bejegyzést naplózzon.
Nincs szükség elemzésre az összes olyan utasítás megtalálásához, amelyek egy adott táblát érintenek () ».
Hogyan befolyásolja ez a DBMS teljesítményét?
Futtassunk teszteket a teljes auditálás engedélyezésével, és nézzük meg, mi történik a PostgreSQL teljesítménnyel. Engedélyezzük a maximális adatbázis-naplózást minden paraméternél.
A konfigurációs fájlban szinte semmit nem változtatunk, a legfontosabb a debug5 mód bekapcsolása, hogy maximális információhoz jussunk.
postgresql.conf
log_destination = 'stderr'
logging_collector = be
log_truncate_on_rotation = be
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = be
debug_print_rewritten = be
debug_print_plan = be
debug_pretty_print = be
log_checkpoints = be
log_connections = be
log_disconnections = be
log_duration = be
log_hostname = be
log_lock_wait = be
log_replication_commands = be
log_temp_files = 0
log_timezone = 'Európa/Moszkva'
1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD paraméterekkel rendelkező PostgreSQL DBMS-en három terhelési tesztet hajtunk végre a parancsok segítségével:
$ 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 benchmarkVizsgálati eredmények:
Nincs naplózás
Fakitermeléssel
Az adatbázis teljes kitöltési ideje
43,74 másodperc
53,23 másodperc
RAM
24%
40%
CPU
72%
91%
1. teszt (50 csatlakozás)
Tranzakciók száma 10 perc alatt
74169
32445
Tranzakciók/mp
123
54
Átlagos késleltetés
405 ms
925 ms
2. teszt (150 csatlakozás, 100 lehetséges)
Tranzakciók száma 10 perc alatt
81727
31429
Tranzakciók/mp
136
52
Átlagos késleltetés
550 ms
1432 ms
A méretekről
DB méret
2251 MB
2262 MB
Adatbázis napló mérete
0 MB
4587 MB
A lényeg: a teljes körű audit nem túl jó. Az auditból származó adatok akkora méretűek lesznek, mint az adatbázisban lévő adatok, vagy még nagyobbak is. A DBMS-sel végzett munka során generált naplózás mennyisége gyakori probléma a termelésben.
Nézzük a többi paramétert:
- A sebesség nem sokat változik: naplózás nélkül - 43,74 másodperc, naplózással - 53,23 másodperc.
- A RAM és a CPU teljesítménye csökken, mert auditfájlt kell generálnia. Ez a termelékenységben is észrevehető.
A csatlakozások számának növekedésével természetesen a teljesítmény enyhén romlik.
A könyvvizsgálattal rendelkező vállalatoknál ez még nehezebb:
- sok adat van;
- auditálásra nem csak a SIEM-ben lévő syslogon keresztül van szükség, hanem fájlokban is: ha valami történik a sysloggal, akkor az adatbázis közelében kell lennie egy fájlnak, amelybe az adatokat menti;
- külön polc szükséges az auditáláshoz, hogy ne pazaroljuk az I/O lemezeket, mivel sok helyet foglal;
- Előfordul, hogy az információbiztonsági alkalmazottaknak mindenhol szükségük van GOST szabványokra, állami azonosítást igényelnek.
Az adatokhoz való hozzáférés korlátozása
Nézzük meg azokat a technológiákat, amelyeket az adatok védelmére és a kereskedelmi DBMS-ekben és a nyílt forráskódú hozzáférésükre használnak.
Mit használhat általában:
- Eljárások és funkciók titkosítása és elhomályosítása (Wrapping) – vagyis különálló eszközök és segédprogramok, amelyek olvashatatlanná teszik az olvasható kódot. Igaz, akkor nem lehet sem változtatni, sem visszaállítani. Ez a megközelítés néha szükséges legalább a DBMS oldalon – a licenckorlátozások logikája vagy az engedélyezési logika pontosan az eljárás és a funkció szintjén titkosítva van.
- Az adatok soronkénti láthatóságának korlátozása (RLS) az, amikor a különböző felhasználók egy táblázatot látnak, de abban eltérő a sorok összetétele, vagyis valamit nem lehet sorszinten megmutatni valakinek.
- A megjelenített adatok szerkesztése (Maszkolás) az, amikor a felhasználók a táblázat egyik oszlopában vagy adatokat vagy csak csillagokat látnak, vagyis egyes felhasználóknál az információ bezárul. A technológia a hozzáférési szintje alapján határozza meg, hogy melyik felhasználónak mit jelenítsen meg.
- Biztonsági DBA/Alkalmazás A DBA/DBA hozzáférés-vezérlés inkább magához a DBMS-hez való hozzáférés korlátozásáról szól, vagyis az információbiztonsági alkalmazottak elválaszthatók az adatbázis- és alkalmazás-adminisztrátoroktól. Kevés ilyen technológia létezik a nyílt forráskódban, de a kereskedelmi DBMS-ekben rengeteg van. Ezekre akkor van szükség, ha sok felhasználó fér hozzá a szerverekhez.
- Fájlokhoz való hozzáférés korlátozása fájlrendszer szinten. A címtárak számára jogokat és hozzáférési jogosultságokat adhat, így minden rendszergazda csak a szükséges adatokhoz férhet hozzá.
- Kötelező hozzáférés és memória törlése - ezeket a technológiákat ritkán használják.
- A végpontok közötti titkosítás közvetlenül a DBMS-ből ügyféloldali titkosítás, kulcskezeléssel a szerver oldalon.
- Adat titkosítás. Például oszlopos titkosításról van szó, ha olyan mechanizmust használ, amely az adatbázis egyetlen oszlopát titkosítja.
Hogyan befolyásolja ez a DBMS teljesítményét?
Nézzük meg az oszlopos titkosítás példáját a PostgreSQL-ben. Van egy pgcrypto modul, amely lehetővé teszi a kiválasztott mezők titkosított formában történő tárolását. Ez akkor hasznos, ha csak néhány adat értékes. A titkosított mezők beolvasásához a kliens visszafejtő kulcsot küld, a szerver dekódolja az adatokat és visszaküldi a kliensnek. Kulcs nélkül senki nem tud semmit kezdeni az adataival.
Teszteljük a pgcrypto-val. Hozzunk létre egy táblázatot titkosított adatokkal és normál adatokkal. Az alábbiakban a táblák létrehozására szolgáló parancsok találhatók, a legelső sorban van egy hasznos parancs - maga a kiterjesztés létrehozása DBMS regisztrációval:
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'));Ezután próbáljunk meg adatmintát készíteni minden táblából, és nézzük meg a végrehajtási időzítéseket.
Kiválasztás titkosítási funkció nélküli táblázatból:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtA stopper be van kapcsolva.
azonosító | szöveg1 | szöveg2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 sor)
Idő: 1,386 ms
Kiválasztás titkosítási funkcióval rendelkező táblázatból:
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.txtA stopper be van kapcsolva.
azonosító | visszafejteni | visszafejteni
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 sor)
Idő: 50,203 ms
Teszteredmények:
Titkosítás nélkül
Pgcrypto (dekódolás)
1000 sor minta
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
A titkosítás nagy hatással van a teljesítményre. Látható, hogy az időzítés megnőtt, mivel a titkosított adatok visszafejtési műveletei (és a visszafejtés általában még mindig az Ön logikájába van csomagolva) jelentős erőforrásokat igényel. Vagyis az összes adatot tartalmazó oszlop titkosításának ötlete tele van a teljesítmény csökkenésével.
A titkosítás azonban nem egy ezüstgolyó, amely minden problémát megold. A visszafejtési és továbbítási folyamat során a dekódolt adatok és a visszafejtési kulcs a szerveren találhatók. Ezért a kulcsokat olyanok is elkaphatják, akik teljes hozzáféréssel rendelkeznek az adatbázis-kiszolgálóhoz, például egy rendszergazda.
Ha van egy kulcs a teljes oszlophoz minden felhasználóhoz (még ha nem is az összeshez, de korlátozott számú klienshez), ez nem mindig jó és helyes. Ezért kezdtek el végpontok közötti titkosítást végezni, a DBMS-ben elkezdték fontolóra venni az adatok kliens- és szerveroldali titkosításának lehetőségeit, és megjelentek ugyanazok a kulcstárolók - külön termékek, amelyek kulcskezelést biztosítanak a DBMS-en. oldal.
Biztonsági funkciók a kereskedelmi és nyílt forráskódú DBMS-ekben
függvények
Type
Jelszóházirend
Könyvvizsgálat
Az eljárások és függvények forráskódjának védelme
RLS
Titkosítás
Jóslat
kereskedelmi
+
+
+
+
+
MsSql
kereskedelmi
+
+
+
+
+
kereskedelmi
+
+
+
+
kiterjesztések
PostgreSQL
Ingyenes
kiterjesztések
kiterjesztések
-
+
kiterjesztések
MongoDb
Ingyenes
-
+
-
-
Csak a MongoDB Enterprise-ban érhető el
A táblázat még korántsem teljes, de a helyzet a következő: a kereskedelmi termékekben a biztonsági problémákat régóta megoldották, nyílt forráskódban általában valamilyen kiegészítőt használnak a biztonság érdekében, sok funkció hiányzik , néha hozzá kell tenni valamit. Például a jelszóházirendek – a PostgreSQL-nek számos különböző kiterjesztése van (, , , , ), amelyek jelszópolitikákat valósítanak meg, de véleményem szerint egyik sem fedi le a hazai vállalati szegmens minden igényét.
Mi a teendő, ha sehol nincs meg, amire szüksége van? Például egy adott DBMS-t szeretne használni, amely nem rendelkezik az ügyfél által igényelt funkciókkal.
Ezután használhat harmadik féltől származó megoldásokat, amelyek különböző DBMS-ekkel működnek, például Crypto DB vagy Garda DB. Ha a hazai szegmens megoldásairól beszélünk, akkor jobban ismerik a GOST-okat, mint a nyílt forráskódban.
A második lehetőség az, hogy saját maga írja meg, amire szüksége van, és eljárási szinten valósítja meg az adathozzáférést és a titkosítást az alkalmazásban. Igaz, a GOST-tal nehezebb lesz. Általában azonban szükség szerint elrejtheti az adatokat, elhelyezheti őket egy DBMS-ben, majd lekérheti és szükség szerint visszafejtheti, közvetlenül az alkalmazás szintjén. Ugyanakkor azonnal gondolja át, hogyan fogja megvédeni ezeket az algoritmusokat az alkalmazásban. Véleményünk szerint ezt DBMS szinten kell megtenni, mert az gyorsabban fog működni.
Ezt a jelentést először a a Mail.ru Cloud Solutions által. Nézegyéb előadásokat, és iratkozzon fel a Telegram eseményhirdetéseire .
Mit kell még olvasni a témában:
- .
- .
Forrás: will.com