🥇Turvalisus ja DBMS: mida silmas pidada kaitsevahendeid valides

Minu nimi on Denis Rõžkov, olen tarkvaraarenduse juht ettevõttes «Gazinformservice», toote meeskonnas. JatobaSeadusandlus ja korporatiivsed normid dikteerivad teatud nõudmisi andmete turvalisusele. Keegi ei soovi, et kolmandad isikud pääseksid ligi konfidentsiaalsele teabele, seega on iga projekti puhul olulised järgmised küsimused: identifitseerimine ja autentimine, juurdepääsuhaldus, andmete terviklikkuse tagamine süsteemis, turvasündmuste registreerimine. Seetõttu soovin rääkida mõningatest huvitavatest detailidest, mis puudutavad andmebaaside turvalisust.

Artikkel on koostatud ettekande põhjal @Databases Meetup, mille korraldas Mail.ru Cloud Solutions. Kui te ei soovi lugeda, siis võite vaadata:

Artiklis on kolm osa:

Kuidas kaitsta ühendusi.
Mis on tegevuste audit ja kuidas fikseerida, mis toimub andmebaasi ja sellele ühenduse poolelt.
Kuidas kaitsta andmeid andmebaasis ja millised tehnoloogiad selleks on olemas.

Kolm andmebaaside turvalisuse komponenti: ühenduste kaitse, tegevuste audit ja andmete kaitsmine.

Ühenduste kaitse

Andmebaasi ühendamine on võimalik nii otse kui ka veebi rakenduste kaudu. Üldiselt suhtleb ärikasutaja, see tähendab inimene, kes töötab andmebaasihaldussüsteemiga (AHS), selle otseselt.

Enne ühenduste kaitsmisest rääkimist tuleb vastata olulistele küsimustele, mis mõjutavad, kuidas turvameetmed paika pannakse:

kas üks ärikasutaja on ekvivalentne ühe andmebaasi kasutajaga;
kas juurdepääs andmebaasi andmetele on tagatud ainult API kaudu, mida te kontrollite, või on otsene juurdepääs tabelitele;
kas andmebaas on eraldatud kaitstud segmenti ning kes ja kuidas sellega suhtleb;
kas kasutatakse andmebaasi ühenduste haldamist/puhverdamist ja vahekihte, mis võivad muuta teavet selle kohta, kuidas ühendus on loodud ja kes kasutab andmebaasi.

Nüüd vaatame, milliseid tööriistu saab kasutada ühenduste kaitsmiseks:

Kasutage andmebaasi tulemüürilahendusi. Lisa kaitse kiht tõstab vähemalt läbipaistvust selles, mis andmebaasis toimub, ja maksimaalselt võimaldab teil tagada täiendava andmekaitse.
Kasutage paroolipoliitikaid. Nende rakendamine sõltub teie arhitektuuri ülesehitusest. Igatahes ei piisa veebirakenduse konfigureerimisfailis olevast ühest paroolist, mis ühendub andmebaasihaldussüsteemiga. On mitmeid andmebaasihaldustööriistu, mis võimaldavad kontrollida, et kasutaja ja parool vajavad uuendamist.
Lisainfot kasutajate hindamise funktsioonide kohta leiate siit siit, samuti saate teada MS SQL Vulnerability Assessment'i kohta siin.
Rikkastage seansi konteksti vajaliku teabega. Kui seanss on läbipaistmatu ja te ei mõista, kes andmebaasihaldussüsteemis töötab, on võimalik, et olemasoleva toimingu raames täiendate teavet selle kohta, kes, mida ja miks teeb. Seda teavet on võimalik näha auditites.
Konfigureerige SSL, kui teil pole andmebaasi ja lõppkasutajate vahel võrgu eraldatust, see ei ole eraldi VLAN-is. Sellistel juhtudel on vajalik kaitsta kanaleid tarbija ja andmebaasihaldussüsteemi vahel. Kaitsemeetmeid on saadaval ka avatud lähtekoodiga lahendustes.

Kuidas see mõjutab andmebaasi jõudlust?

Vaata näite põhjal PostgreSQL-st, kuidas SSL mõjutab CPU koormust, ajakulu suurenemist ja TPS-i vähenemist – kas selle lubamine ei kuluta liiga palju ressursse.

Laadime PostgreSQL-d pgbench'i abil – see on lihtne programm jõudluse testimiseks. See kordab ühe käsu järjestust, võimalusel paralleelsetes andmebaaside seanssides, ja seejärel arvutab keskmise tehingute määra.

Test 1 ilma SSL-i ja SSL-iga – ühendus luuakse iga tehingu korral:

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 ilma SSL-i ja SSL-iga – kõik tehingud täidetakse ühes ühenduses:

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"

Ülejäänud seaded:

skaalama: 1
küsimuse režiim: lihtne
klientide arv: 10
niiditöötluste arv: 1
klientide kohta tehingute arv: 5000
tehingute arv, mis tegelikult töötati üles: 50000/50000

Testimise tulemused:

ILMA SSL-ita
SSL

Ühendus loodakse iga tehingu puhul

latentsuse keskmine
171.915 ms
187.695 ms

tps sealhulgas ühenduste loomine
58.168112
53.278062

tps ilma ühenduste loomise arvesse võtmata
64.084546
58.725846

CPU
24%
28%

Kõik tehingud toimub ühes seoses

latentsuse keskmine
6.722 ms
6.342 ms

tps, sealhulgas ühenduste loomine
1587.657278
1576.792883

tps ilma ühenduste loomise arvesse võtmata
1588.380574
1577.694766

CPU
17%
21%

Mugavate koormuste korral on SSL-i mõju võrreldav mõõtmisvigadega. Kui edastatavate andmete maht on väga suur, võib olukord olla erinev. Kui me loome iga tehingu puhul ühe ühenduse (see on haruldane, tavaliselt jagavad ühendust kasutajad), on teil suur hulk ühendumisi/lähtestamisi, mõju võib olla veidi suurem. Seega võib esineda jõudluse vähenemise riske, kuid erinevus ei ole piisavalt suur, et kaitset mitte kasutada.

Pange tähele, et suurem erinevus on, kui võrrelda töörežiime: ühes sessioonis töötades või erinevates. See on arusaadav: iga ühenduse loomine nõuab ressursse.

Meil oli juhtum, kus ühendasime Zabbixi trust-režiimis, mis tähendab, et md5-d ei kontrollitud, nö autentimist ei olnud vaja. Siis palus klient aktiveerida md5-autentimise režiimi. See tõi kaasa suure koormuse CPU-le ning jõudlus langes. Hakkasime otsima optimeerimisvõimalusi. Üks võimalik lahendus probleemile on rakendada võrgu piiranguid, luua andmebaasi jaoks eraldi VLAN-e, lisada seadeid, et oleks selge, kes, kust ja kuidas ühendub, ning eemaldada autentimine. Samuti võib optimeerida autentimise seadistusi, et vähendada kulusid autentimise aktiveerimisel, kuid erinevate autentimismeetodite kasutamine mõjutab üldiselt jõudlust ning tuleb arvestada neid tegureid serverite (raudi) arvutusvõimsuse projekteerimisel.

Kokkuvõte: mitmetes lahendustes võivad isegi väiksed nüansid autentimises projekti tugevalt mõjutada ning halb on, kui see selgub alles tootmises rakendamisel.

Tegevuste audit

Audit võib hõlmata mitte ainult andmebaase. Audit tähendab teabe saamist selle kohta, mis toimub erinevates segmentides. See võib olla nii andmebaasi tulemüür kui ka operatsioonisüsteem, millel andmebaas põhineb.

Kommertslike ettevõtte taseme andmebaaside audit on hea, avatud lähtekoodiga - mitte alati. Siin on, mis on PostgreSQL-is:

default log - sisseehitatud logimine;
laiendused: pgaudit - kui vaikimisi logimine ei ole piisav, saate kasutada eriseadeid, mis lahendavad osa ülesannetest.

Täitmine video ettekandele:

„Operaatorite põhiregistreerimist saab tagada standardse logimisvahendi kaudu, seadistades log_statement = all.

See sobib jälgimiseks ja muuks kasutamiseks, kuid ei taga tavaliselt auditi jaoks vajalikku detailsuse taset.

Pole piisav, et omada nimekirja kõigist andmebaasiga tehtud toimingutest.

Peab olema ka võimalus leida konkreetseid väiteid, mis on auditi jaoks huvitavad.

Standardne logimisvahend näitab seda, mida kasutaja soovis, samas kui pgAudit keskendub detailidele, mis toimusid, kui andmebaas tegi päringu.

Näiteks võib audiitor soovida veenduda, et konkreetne tabel loodi dokumenteeritud hooldustöös.

See võib tunduda lihtsa ülesandena põhjauditiks ja grepiks, kuid mis juhtub, kui kohtate midagi sellist (tahtlikult keerulist) näidet:

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

Standardne logimine annab teile järgmise:

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

Tundub, et huvipakkuva tabeli leidmiseks võib olla vajalik mõningane teadmiste põhjalik analoog, kui tabelid luuakse dünaamiliselt.

See ei ole ideaalne, kuna oleks parem lihtsalt otsida tabeli nime järgi.

Siinkohal on pgAudit kasulik.

Sama sisendi korral andis ta selle väljundi logis:

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)

Logitakse mitte ainult DO plokk, vaid ka täisteksti CREATE TABLE koos operaatori tüübi, objekti tüübiga ja täisnimega, mis lihtsustab otsimist.

SELECT ja DML operaatorite logimise korral saab pgAudit seadistada, et registreerida eraldi kirje iga suhte kohta, millele viidatakse operaatoris.

Süntaksianalüüsi pole vajalik, et leida kõik operaatorid, mis puudutavad konkreetset tabelit,*)».

Kuidas see mõjutab andmebaasi jõudlust?

Tehke testid, lülitades sisse täieliku auditi, ja vaatame, kuidas see mõjutab PostgreSQLi jõudlust. Lülitame sisse maksimaalse andmebaasi logimise kõigi parameetrite kohaselt.

Konfiguratsioonifailis muudame peaaegu mitte midagi, oluline on – lülitame sisse debug5 režiimi, et saada maksimaalset teavet.

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'

Teostame kolme koormustesti PostgreSQL andmebaasis, mille parameetrid on 1 CPU, 2,8 GHz, 2 GB RAM ja 40 GB HDD, kasutades järgmisi käsku:

$ 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

Testimise tulemused:

Ilma logimiseta
Logimisega

Andmebaasi täitmise lõpptulemus
43,74 sek
53,23 sek

RAM
24%
40%

CPU
72%
91%

Test 1 (50 ühendust)

Tehingute arv 10 minuti jooksul
74169
32445

Tehingud/sek
123
54

Keskmine latentsus
405 ms
925 ms

Test 2 (150 ühendust 100 võimaliku puhul)

Tehingute arv 10 minuti jooksul
81727
31429

Tehingud/sek
136
52

Keskmine latentsus
550 ms
1432 ms

Mõõtmed

Andmebaasi suurus
2251 MB
2262 MB

Andmebaasi logide suurus
0 MB
4587 MB

Kokkuvõttes: täielik auditi läbiviimine ei ole väga hea. Auditi andmete maht võib olla sama suur kui andmebaasi enda andmete maht või isegi suurem. Selline logimise maht, mida andmebaasi haldamise süsteem genereerib, on toote arenduses tüüpiline probleem.

Vaatame teisi parameetreid:

Kiirus ei muutu oluliselt: ilma logita — 43,74 sekundit, logiga — 53,23 sekundit.
Jõudlus RAM-i ja CPU osas halveneb, kuna tuleb genereerida auditi fail. See on tootmises ka silmatorkav.

Ühenduste arvu suurenemise korral halvenevad tulemused loomulikult veidi.

Suurettevõtetes on auditi tegemine veelgi keerulisem:

andmeid on palju;
auditi läbiviimine ei tohi piirduda ainult syslogiga SIEM-is, vaid peab olema ka failides: äkki juhtub syslogiga midagi, peab olema andmebaasi lähedal fail, kuhu andmed salvestatakse;
audiitoriks on vajalik eraldi ketas, et mitte põrgu I/O-diskide peal, kuna see võtab palju ruumi;
juhtub, et infotehnoloogia töötajad nõuavad alati standardeid, nad nõuavad riiklikku identifitseerimist.

Juurdepääsu piiramine andmetele

Vaatame tehnoloogiaid, mida kasutatakse andmete kaitsmiseks ja neile juurdepääsuks kaubanduslikes andmebaasides ja avatud lähtekoodiga lahendustes.

Mida üldiselt kasutada:

Andmete krüpteerimine ja funktsioonide obfuskeerimine (Wrapping) — see tähendab, et eraldi tööriistad ja utiliidid muudavad loetava koodi loetamatuks. Tõsi, hiljem ei saa seda muuta ega tagasi refaktoreerida. Selline lähenemine on mõnikord vajalik vähemalt andmebaasi poolel — litsentsipiirangute või autoriseerimise loogika krüpteeritakse just protseduuride ja funktsioonide tasemel.
Andmete nähtavuse piiramine ridade kaupa (RLS) — see on siis, kui erinevad kasutajad näevad ühte tabelit, kuid erinevat ridade koosseisu, st mõnele ei saa midagi näidata ridade tasemel.
Kuvatud andmete redigeerimine (Masking) — see on siis, kui kasutajad näevad ühes tabeli veerus kas andmeid või ainult tärne, st teatud kasutajate jaoks on teave suletud. Tehnoloogia määrab, millist teavet näidata, sõltuvalt juurdepääsutasemest.
Juhtimise, Security DBA/Application DBA/DBA - see tähendab peamiselt juurdepääsu piiramist andmebaasi enda juurde. Seega on infosüsteemide töötajad eraldatud andmebaasi- ja rakenduseadministraatoritest. Avatud lähtekoodiga tehnoloogiaid on selles osas vähe, kuid kaubanduslikes andmebaasides leidub neid piisavalt. Need on vajalikud, kui palju kasutajaid pääseb juurde serveritele.
Failisüsteemi tasemel juurdepääsu piiramine. Saame anda õigusi ja juurdepääsu privileege kataloogides, et iga administraator pääseks ligi ainult vajalikele andmetele.
Volitatud juurdepääs ja mälu puhastamine - neid tehnoloogiaid kasutatakse harva.
Lõpp-otsas krüpteerimine otse andmebaasis - see on kliendi poolel toimuv krüpteerimine, mille võtmehaldus on serveripoolne.
Andmete krüpteerimine. Näiteks veeru krüpteerimine - kui kasutate mehhanismi, mis krüpteerib eraldi andmebaasi veeru.

Kuidas see mõjutab andmebaasi jõudlust?

Vaatame PostgreSQL veergude krüpteerimise näidet. Seal on moodul pgcrypto, mis võimaldab salvestada valitud väljad krüpteeritud kujul. See on kasulik, kui väärtuslikud on ainult mõned andmed. Krüpteeritud väljade lugemiseks edastab klient dekodeerimisvõtme, server dekodeerib andmed ja edastab need kliendile. Ilma võtmeta ei saa keegi teie andmetega midagi teha.

Teeme katse pgcrypto'ga. Loome tabeli krüpteeritud andmetega ja tavaliste andmetega. Allpool on käsud tabelite loomiseks; esimeses reas on kasulik käsk – pikenduse loomine koos andmebaasi registreerimisega:

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

Edasi proovime teha igast tabelist andmete valiku ja vaatame täitmise aega.

Valik tabelist ilma krüpteerimise funktsioonita:

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

Ajastamine on käivitatud.

id | tekst1 | tekst2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
…
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 rida)

Aeg: 1,386 ms

Andmete valik krüptimise funktsiooni abil:

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

Ajastamine on käivitatud.

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

Aeg: 50,203 ms

Testimise tulemused:

Ilma krüptimiseta
Pgcrypto (dekrüpteerimine)

Valik 1000 rida
1,386 ms
50,203 ms

CPU
15%
35%

RAM

+5%

Krüptimine mõjutab oluliselt jõudlust. Näha on, et ajastus on suurenenud, kuna krüptitud andmete dekrüpteerimise operatsioonid (ja dekrüpteerimine on tavaliselt veel teie loogikasse mähitud) nõuavad märkimisväärseid ressursse. Seega, idee krüpteerida kõik veerud, mis sisaldavad mingeid andmeid, toob kaasa jõudluse languse.

Sellegipoolest ei ole krüptimine hõbedane kuuli, mis lahendab kõik probleemid. Dekrüpteeritud andmed ja dekrüpteerimise võti asuvad dekrüpteerimise ja andmete edastamise protsessis serveris. Seega võivad võtmed olla kinni püütud inimeselt, kellel on täielik juurdepääs andmebaasi serverile, näiteks süsteemiadministraatorilt.

Kui kogu veeru jaoks on kõikide kasutajate jaoks üks võti (isegi kui mitte kõikidele, vaid piiratud hulga klientidele), siis see ei ole alati hea ja õige. Just seetõttu hakati juurutama lõpp-to-lõpp krüptimist, andmebaasides hakati kaaluma andmete krüptimise võimalusi kliendi ja serveri poolel ning ilmusid need samad key-vault salvestused – eraldi tooted, mis tagavad võtmete haldamise andmebaasi poolel.

Selle krüptimise näide MongoDB-s

Turvavahendid kommerts- ja avatud lähtekoodiga andmebaasides

Funktsioonid
Tüüp
Parooli poliitika
Audit
Protseduuride ja funktsioonide lähtekoodi kaitse
RLS
Krüptimine

Oracle
Kommerts
+
+
+
+
+

MsSql
Kommerts
+
+
+
+
+

Jatoba
Kommerts
+
+
+
+
liidendid

PostgreSQL
Tasuta
liidendid
liidendid
—
+
liidendid

MongoDb
Tasuta
—
+
—
—
Saadaval ainult MongoDB Enterprise'is

Tabel ei ole sugugi täielik, kuid olukord on selline: kommertstooteid on pikka aega turvafaile lahendatud, avatud lähtekoodi puhul kasutatakse reeglina mingisuguseid lisandeid, paljudest funktsioonidest jääb puudu, vahel tuleb midagi juurde kirjutada. Näiteks paroolipoliitikad - PostgreSQL-is on palju erinevaid laiendusi (1, 2, 3, 4, 5), mis rakendavad paroolipoliitikaid, kuid kõikide kohalike ettevõtlussektori vajaduste katmine, minu arvates, ei kata ükski neist.

Mis teha, kui vajalikku kohta pole? Например, хочется использовать определенную СУБД, в которой нет функций, которые требует заказчик.

Siis saab kasutada kolmanda osapoole lahendusi, mis töötavad erinevate andmebaasidega, näiteks "Krypto DB" või "Garda DB". Kohalike lahenduste puhul tuntakse GOST-e paremini kui avatud lähtekoodiga variantides.

Teine variant on ise kirjutada vajalikud lahendused, rakendada andmete juurdepääsu ja krüpteerimise protseduure rakenduses. Tõsi, GOST-iga on keerulisem, kuid üldiselt on võimalik andmeid varjata ja salvestada andmebaasi ning hiljem neid õigesti dekrüpteerida otse rakenduse tasandil. Samuti mõelge, kuidas kavatsete neid algoritme rakenduses kaitsta. Meie arvates tuleks seda teha andmebaasi tasemel, kuna nii töötab see kiiremini.

See ettekannet kõlas esmakordselt @Databases Meetup Mail.ru Cloud Solutions esitlus. Vaadake video teisi ettekandeid ja tellige ürituste teateid Telegramis Kubernetesest Mail.ru Grupis.

Mida veel teemast lugeda:

Allikas: habr.com