🥇Säkerhet och databashanteringssystem: vad man behöver tänka på när man väljer skyddsåtgärder

Jag heter Denis Rozhkov, jag är ansvarig för mjukvaruutveckling på företaget "Gazinformservice", i produktteamet. Jatoba. Lagstiftning och företagsnormer ställer vissa krav på säkerheten vid datalagring. Ingen vill att tredje part ska få tillgång till känslig information, därför är följande frågor viktiga för varje projekt: identifiering och autentisering, hantering av åtkomst till data, säkerställande av informationens integritet i systemet, registrering av säkerhetshändelser. Därför vill jag berätta om några intressanta aspekter av databasens säkerhet.

Artikeln är baserad på ett föredrag vid @Databases Meetup, organiserat Mail.ru Cloud Solutions. Om du inte vill läsa kan du titta:

Artikeln kommer att bestå av tre delar:

Hur man skyddar anslutningar.
Vad är aktivitetsgranskning och hur registrerar man vad som händer med databasen och anslutningen till den.
Hur man skyddar data i själva databasen och vilka teknologier som finns för detta.

Tre aspekter av databasens säkerhet: skydd av anslutningar, aktivitetsgranskning och dataskydd.

Skydd av anslutningar

Man kan ansluta till databasen antingen direkt eller indirekt via webbapplikationer. Vanligtvis interagerar en affärsanvändare, det vill säga en person som arbetar med databas, inte direkt med den.

Innan vi pratar om hur man skyddar anslutningar, måste vi svara på viktiga frågor som avgör hur säkerhetsåtgärderna kommer att utformas:

är en affärsanvändare motsvarande en användare i databasen;
ges åtkomst till databasen endast genom ett API som du kontrollerar, eller finns det direkt åtkomst till tabeller;
är databasen avgränsad till ett separat skyddat segment, vem och hur interagerar med den;
används det poolning/proxy och mellanliggande lager som kan ändra information om hur anslutningen är uppbyggd och vem som använder databasen.

Låt oss nu titta på vilka verktyg som kan användas för att skydda anslutningarna:

Använd lösningar av typen databasbrandvägg. Ett extra skyddslag kan åtminstone öka transparensen för vad som händer i databasen, och som högst kan du säkerställa ett extra skydd för data.
Använd lösenordspolicyer. Deras tillämpning beror på hur din arkitektur är uppbyggd. I vilket fall som helst, enbart ett lösenord i konfigurationsfilen för webbtjänsten som ansluter till databas hanteringssystemet (DBMS) är otillräckligt för skydd. Det finns flera verktyg för DBMS som gör det möjligt att kontrollera vilka användare och lösenord som behöver uppdateras.
Läs mer om funktionerna för utvärdering av användare. här, även hur man får information om MS SQL Vulnerability Assessment. ). Ett typiskt exempel på användning:.
Berika sessionens kontext med nödvändig information. Om sessionen är ogenomskinlig, kan du inte förstå vem som arbetar inom dess ram i DBMS. Du kan komplettera informationen om vem som gör vad och varför inom ramen för den genomförda operationen. Denna information kan ses i revisionen.
Konfigurera SSL om du inte har nätverksavgränsning mellan DBMS och slutanvändarna; den är inte i ett separat VLAN. I sådana fall är det avgörande att skydda kanalen mellan konsumenten och själva DBMS. Skyddsverktyg finns även bland open source-lösningar.

Hur påverkar detta DBMS-prestandan?

Låt oss titta på hur SSL påverkar CPU-belastningen, ökar latensen och minskar TPS i PostgreSQL. Kommer det att gå för mycket resurser om det aktiveras?

Vi belastar PostgreSQL med pgbench — ett enkelt program för att köra prestandatest. Det kör en sekvens av kommandon upprepade gånger, eventuellt i parallella databas-sessioner, och beräknar det genomsnittliga transaktionshastigheten.

Test 1 utan SSL och med användning av SSL. — anslutningen upprättas vid varje transaktion:

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"

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

Test 2 utan SSL och med användning av SSL. — alla transaktioner utförs i en anslutning:

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"

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

Övriga inställningar:

skaleringsfaktor: 1
frågemode: enkel
antal kunder: 10
antal trådar: 1
antal transaktioner per kund: 5000
antal transaktioner som faktiskt behandlades: 50000/50000

Testresultat:

INGA SSL
SSL

En anslutning upprättas vid varje transaktion.

latens genomsnitt
171.915 ms
187.695 ms

tps inklusive anslutningar som etableras
58.168112
53.278062

tps utan att inkludera anslutningar som etableras
64.084546
58.725846

CPU
24%
28%

Alla transaktioner utförs i en anslutning.

latens genomsnitt
6.722 ms
6.342 ms

tps inklusive anslutningar som etableras
1587.657278
1576.792883

tps utan att inkludera anslutningar som etableras
1588.380574
1577.694766

CPU
17%
21%

Vid små belastningar är påverkan av SSL jämförbar med mätfel. Om mängden överförda data är mycket stor kan situationen vara annorlunda. Om vi etablerar en anslutning för varje transaktion (vilket sällan sker, vanligtvis delas anslutningen mellan användare), får du ett stort antal anslutningar/diskonnekter, och påverkan kan vara något större. Det vill säga att det finns risker för prestandaförlust, men skillnaden är inte så stor att skyddet bör avstås från.

Observera att det finns en stor skillnad när man jämför driftslägen: inom en session arbetar du eller olika. Det är förståeligt: resurser används för att skapa varje anslutning.

Vi hade ett fall där vi kopplade samman Zabbix i trust-läge, vilket innebär att md5 inte kontrollerades, det fanns ingen anledning till autentisering. Därefter bad kunden att aktivera md5-autentisering. Detta gav en stor belastning på CPU:n, prestandan sjönk. Vi började leta efter sätt att optimera. En av de möjliga lösningarna på problemet är att implementera nätverksbegränsningar, skapa separata VLAN för DBMS, lägga till inställningar för att förstå vem som ansluter och varifrån och ta bort autentiseringen. Man kan också optimera autentiseringsinställningar för att minska kostnaderna vid aktivering av autentisering, men generellt påverkar användningen av olika autentiseringsmetoder prestandan och dessa faktorer måste beaktas vid designen av serverkapacitet (hårdvara) för DBMS.

Slutsats: i en rad lösningar kan även små detaljer kring autentisering få stor inverkan på projektet, och det är olyckligt när detta först blir tydligt vid implementering i produktion.

Aktivitetens granskning

Granskning behöver inte vara begränsad till DBMS. Granskning är att erhålla information om vad som händer på olika segment. Detta kan inkluderar både en databasbrandvägg och operativsystemet som DBMS byggs på.

I kommersiella DBMS av Enterprise-nivå fungerar granskning bra, men i öppen källkod är det inte alltid så. Här är vad som finns i PostgreSQL:

default log — inbyggd loggning;
extensions: pgaudit — om du behöver mer än standardloggningen kan du använda separata inställningar som löser en del uppgifter.

Tillägg till rapporten i videon:

Den grundläggande registreringen av operatörer kan säkerställas med hjälp av ett standardloggningsverktyg med log_statement = all.

Detta är acceptabelt för övervakning och andra användningsområden, men ger inte den detaljnivå som vanligtvis krävs för revision.

Det räcker inte med att ha en lista över alla operationer som utförs med databasen.

Det måste också finnas möjlighet att hitta specifika påståenden som är av intresse för revisorn.

Standardloggningsverktyget visar vad användaren har begärt, medan pgAudit fokuserar på detaljerna kring vad som hände när databasen utförde begäran.

Till exempel kan revisorn vilja försäkra sig om att en specifik tabell skapades under det dokumenterade underhållsfönstret.

Det kan verka vara en enkel uppgift för grundläggande revision och grep, men vad händer om du påträffar något som detta (medvetet otydliga) exempel:

DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;

Standardloggningen ger dig detta:

LOG: statement: DO $$
BEGIN
EXECUTE ‘CREATE TABLE import’ || ‘ant_table (id INT)’;
END $$;

Det verkar som om viss kodkunskap kan behövas för att hitta den tabell som är av intresse, när tabeller skapas dynamiskt.

Detta är inte perfekt, eftersom det skulle vara att föredra att bara söka på tabellnamn.

Här kommer pgAudit att vara användbart.

För samma inmatning kommer det att ge denna loggutgång:

AUDIT: SESSION,33,1,FUNCTION,DO,,,«DO $$
BEGIN
EXECUTE ‘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)

Inte bara blocket DO registreras, utan också den fullständiga texten för CREATE TABLE med typ av operation, objekttyp och fullständigt namn, vilket gör det lättare att söka.

Vid registrering av SELECT- och DML-operationer kan pgAudit konfigureras för att registrera en separat post för varje relation som refereras i operationen.

Ingen syntaktisk analys krävs för att hitta alla operationer som rör en specifik tabell (*)».

Hur påverkar detta DBMS-prestandan?

Låt oss göra tester med fullständig revision aktiverad och se hur det påverkar prestandan i PostgreSQL. Vi aktiverar maximal databasloggning för alla parametrar.

Vi ändrar nästan ingenting i konfigurationsfilen, det viktiga är att vi aktiverar debug5-läget för att få maximal information.

postgresql.conf

log_destination = ‘stderr’
logging_collector = on
log_truncate_on_rotation = on
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 = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = on
log_checkpoints = on
log_connections = on
log_disconnections = on
log_duration = on
log_hostname = on
log_lock_waits = on
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Europe/Moscow'

På PostgreSQL DB med parametrarna 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD genomför vi tre belastningstester med kommandon:

$ 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

Testresultat:

Utan loggning
Med loggning

Total tiden för att fylla databasen
43,74 sek
53,23 sek

RAM
24%
40%

CPU
72%
91%

Test 1 (50 anslutningar)

Antal transaktioner på 10 minuter
74169
32445

Transaktioner/sek
123
54

Genomsnittlig fördröjning
405 ms
925 ms

Test 2 (150 anslutningar av 100 möjliga)

Antal transaktioner på 10 minuter
81727
31429

Transaktioner/sek
136
52

Genomsnittlig fördröjning
550 ms
1432 ms

Om storlekar

Databasens storlek
2251 MB
2262 MB

Loggarnas storlek
0 MB
4587 MB

I slutändan: en fullständig revision är inte så bra. Mängden data som genereras från revisionen blir ungefär lika stor som datan i själva databasen, om inte mer. Den mängd loggning som genereras vid arbete med DBMS är ett vanligt problem i produktion.

Låt oss titta på andra parametrar:

Hastigheten förändras inte mycket: utan loggning — 43,74 sek, med loggning — 53,23 sek.
Prestandan för RAM och CPU kommer att sjunka, eftersom en fil med revision måste skapas. Detta är också tydligt i produktionen.

Vid en ökning av antalet anslutningar kommer givetvis värdena att försämras något.

I företag med revision är det ännu mer komplicerat:

det finns mycket data;
revision behövs inte bara via syslog i SIEM, utan också i filer: om något skulle hända med syslog, måste det finnas en fil nära databasen där uppgifterna sparas;
för revision behövs en separat hylla för att inte överbelasta I/O på diskarna, eftersom den tar mycket plats;
det kan hända att anställda inom IT-säkerhet kräver standarder, de kräver giltig identifikation.

Begränsning av tillgången till data

Låt oss se på teknologierna som används för att skydda data och begränsa åtkomst till dem i kommersiella DBMS och open source.

Vad som generellt kan användas:

Kryptering och obfuskering av procedurer och funktioner (Wrapping) — det vill säga specifika verktyg och hjälpmedel som gör läsbar kod oläslig. Tyvärr kan den inte ändras eller refaktoreras tillbaka. Denna metod behövs ibland åtminstone på DBMS-sidan — logiken för licensbegränsningar eller autentisering krypteras just på nivåerna för procedurer och funktioner.
Begränsning av datavisibilitet per rad (RLS) innebär att olika användare ser en tabell, men med olika innehåll per rad, vilket betyder att vissa användare inte kan se viss information på radsnivå.
Redigering av visade data (Masking) innebär att användare i en kolumn i tabellen antingen ser data eller bara stjärnor, vilket innebär att viss information är stängd för vissa användare. Tekniken avgör vilken information som visas för vilken användare baserat på åtkomstnivå.
Åtkomstkontroll Security DBA/Application DBA/DBA handlar snarare om att begränsa åtkomst till själva databashanteringssystemet, vilket betyder att säkerhetspersonal kan åtskiljas från databasadministratörer och applikationsadministratörer. Det finns få sådana teknologier i open source, men det finns gott om dem i kommersiella databashanteringssystem. De är nödvändiga när många användare har åtkomst till servrarna själva.
Åtkomstbegränsning på filsystemsnivå. Rättigheter och åtkomsträttigheter kan ges till kataloger så att varje administratör endast får åtkomst till nödvändig data.
Mandatåtkomst och minnesrensning är teknologier som sällan tillämpas.
End-to-end-kryptering direkt i databashanteringssystemet innebär klientbaserad kryptering med nyckelhantering på serversidan.
Kryptering av data. Till exempel kolumnkryptering – när du använder en mekanism som krypterar enskilda kolumner i databasen.

Hur påverkar detta prestandan hos databashanteringssystemet?

Låt oss titta på kolumnkryptering i PostgreSQL som exempel. Den har modulen pgcrypto, som gör det möjligt att lagra utvalda fält i krypterad form. Detta är användbart när endast vissa data är värdefulla. För att läsa krypterade fält skickar klienten den avkrypterande nyckeln, servern avkrypterar data och skickar dem till klienten. Utan nyckeln kan ingen göra något med dina data.

Vi genomför ett test med pgcrypto.. Vi skapar en tabell med krypterade data och en med vanliga data. Nedan är kommandon för att skapa tabeller, i den första raden finns ett användbart kommando - skapande av den aktuella extensionen med registrering av databashanteringssystemet:

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'));

Låt oss nu försöka göra dataval för varje tabell och titta på exekveringstiderna.

Dataval från tabellen utan krypteringsfunktion:

psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txt

Tidtagarur aktiverat.

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

Tid: 1,386 ms

Dataval från tabellen med krypteringsfunktion:

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

Tidtagarur aktiverat.

id | decrypt | decrypt
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
…
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 rader)

Tid: 50,203 ms

Testresultat:

Utan kryptering
Pgcrypto (decrypt)

Dataval 1000 rader
1,386 ms
50,203 ms

CPU
15%
35%

RAM

+5%

Kryptering påverkar prestandan avsevärt. Det är tydligt att tiden ökade eftersom avkrypteringsoperationer för krypterade data (och avkryptering är vanligtvis också inbäddad i din logik) kräver betydande resurser. Det vill säga, idén att kryptera alla kolumner som innehåller data kan leda till prestandanedsättning.

Samtidigt är kryptering inte en silverkula som löser alla problem. De avkrypterade data och avkrypteringsnyckeln finns på servern under processen av avkryptering och dataöverföring. Därför kan nycklar bli avlyssnade av dem som har fullständig åtkomst till databasservern, till exempel systemadministratörer.

När en nyckel används för hela kolumnen för alla användare (även om det bara är för en begränsad uppsättning kunder), är det inte alltid bra och korrekt. Det är därför end-to-end-kryptering började implementeras, och alternativ för kryptering av data från klientsidan och servern diskuterades inom databashanteringssystem, vilket ledde till framväxten av key-vault-lösningar — särskilda produkter som tillhandahåller nyckelhantering på databashanteringssystemets sida.

Exempel på sådan kryptering i MongoDB

Säkerhetsverktyg i kommersiella och open source databashanteringssystem

Funktioner
Typ
Lösenordspolicy
Revision
Skydd av källkoden för procedurer och funktioner
RLS
Kryptering

Oracle
Kommersiell
+
+
+
+
+

MsSql
Kommersiell
+
+
+
+
+

Jatoba
Kommersiell
+
+
+
+
tillägg

PostgreSQL
Gratis
tillägg
tillägg
—
+
tillägg

MongoDb
Gratis
—
+
—
—
Endast tillgänglig i MongoDB Enterprise

Tabellen är långt ifrån komplett, men situationen är följande: i kommersiella produkter har säkerhetsuppgifter länge lösts, i open source-produkter används vanligtvis överliggande lösningar för säkerhet, många funktioner saknas, ibland måste något skrivas till. Till exempel, lösenordspolicys — det finns många olika tillägg i PostgreSQL.1, 2, 3, 4, 5), som implementerar lösenordspolicys, men alla behov inom den inhemska företagssektorn, enligt min mening, täcker ingen av dem.

Vad ska man göra om det man behöver inte finns någonstans?? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Då kan man använda externa lösningar som fungerar med olika databashanteringssystem, till exempel «Krypto DB» eller «Garda DB». Om det handlar om lösningar från den inhemska sektorn, så känner de till GOST bättre än i open source.

Det andra alternativet är att själv skriva vad som behövs, implementera åtkomst till data och kryptering på applikationsnivå. Visserligen kan det bli mer komplicerat med GOST. Men allt som allt - du kan dölja data som behövs, lagra den i databashanteringssystemet, och sedan hämta och dekryptera den som behövs, direkt på applikationsnivå. Tänk också på hur du kommer att skydda dessa algoritmer på applikationen. Enligt vår åsikt bör detta göras på databashanteringssystemets nivå, eftersom det kommer att fungera snabbare.

Denna presentation hördes först på @Databases Meetup av Mail.ru Cloud Solutions. Se video andra föreläsningar och följ anmälningarna till evenemang på Telegram Runt Kubernetes i Mail.ru Group.

Vad mer att läsa om ämnet:

Källa: habr.com