🥇Turvalisus ja andmebaasid: mida peab meeles pidama kaitsevahendite valimisel

Minu nimi on Denis Rozhkov, olen tarkvaraarenduse direktor Gasinformservice'is, meie toote meeskonnas. Jatoba. Seadusandlus ja ettevõtte normid kehtestavad teatud nõuded andmete turvalisusele. Keegi ei soovi, et kolmandad isikud saaksid juurdepääsu konfidentsiaalsele teabele, seetõttu on igasuguste projektide puhul olulised järgmised küsimused: tuvastamine ja autentimine, juurdepääsude haldamine andmetele, süsteemi teabe terviklikkuse tagamine ning turvaettevõtete registreerimine. Seetõttu soovin rääkida mõningatest huvitavatest aspektidest, mis on seotud andmebaaside turvalisusega.

Artikkel on valmistatud ette ettekande põhjal @Databases Meetup, mille korraldas Mail.ru Pilve Lahendused. Kui te ei soovi lugeda, saate vaadata:

Artiklis on kolm osa:

Kuidas kaitsta ühendusi.
Mis on tehingu audit ja kuidas fikseerida, mis toimub andmebaasi ning selle ühenduste poolelt.
Kuidas kaitsta andmeid andmebaasis ja milliseid tehnoloogiaid selleks on olemas.

Kolm komponenti andmebaasi turvalisuses: ühenduste kaitsmine, tegevuste audit ja andmete kaitsmine

Ühenduste kaitsmine

Andmebaasi saab ühendada nii otse kui ka kaudselt veebirakenduste kaudu. Reeglina suhtleb ärikasutaja, see tähendab, et inimene, kes töötab andmebaasiga, ei suhtle sellega otse.

Enne kui räägime ühenduste kaitsmisest, tuleb vastata olulistele küsimustele, millest sõltub, kuidas turvameetmeid korraldatakse:

kas üks ärikasutaja vastab ühele andmebaasi kasutajale;
kas andmebaasi andmetele pääseb juurde ainult teie kontrollitud API kaudu või on otse juurdepääs tabelitele;
kas andmebaas on eraldatud kaitstud segmenti, kes ja kuidas sellega suhtleb;
kas kasutatakse pooling/proxy ja vahekihte, mis võivad muuta teavet selle kohta, kuidas ühendus on üles ehitatud ja kes kasutab andmebaasi.

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

Kasutage andmebaasi tulemüüri klassi lahendusi. Lisakaitsekiht tõstab vähemalt läbipaistvust selle osas, mis toimub andmebaasis, maksimaalselt — võimaldab teil tagada andmete lisakaitse.
Kasutage paroolipoliitikat. Nende rakendamine sõltub sellest, kuidas teie arhitektuur on üles ehitatud. Igatahes — ühes konfiguratsioonifailis olevast paroolist, mis on seotud andmebaasi, ei piisa kaitseks. On mitmeid andmebaasi tööriistu, mis võimaldavad jälgida, milliseid kasutajaid ja paroole on vaja ajakohastada.
Rohkem teavet kasutajate hindamise funktsioonide kohta saab lugeda siin, samuti saab teada MS SQL Vulnerability Assessmeni kohta siit.
Rikkaga ssessioni konteksti vajalike andmetega. Kui sessioon on läbipaistmatu, ei saa te aru, kes seal andmebaasis töötab; konkreetses operatsioonis on võimalik lisada teavet selle kohta, kes, mida ja miks teeb. Selle teabe näeb auditis.
Seadistage SSL, kui andmebaasil puudub võrgulise eraldatuse, ja see ei ole eraldi VLAN-is. Sellistes olukordades on oluline kaitsta kanalit tarbija ja andmebaasi vahel. Kaitsetööriistu leidub ka avatud allikates.

Kuidas see mõjutab andmebaasi jõudlust?

Vaadake näitel PostgreSQL, kuidas SSL mõjutab CPU koormust, ajakulu ja TPS-i, kas ressursse ei kulu liiga palju, kui see on sisse lülitatud.

Koormame PostgreSQL-i, kasutades pgbench'i — see on lihtne programm jõudlustestide läbiviimiseks. See kordab sama käsu järjestikku, võimalusel andmebaasi paralleelsetes sessioonides, ja seejärel arvutab tehingute keskmise kiirus.

Test 1 ilma SSL-i ja SSL-iga. — ühendus luuakse igas tehingus:

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 toimub ü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:

skaleerimise faktor: 1
päringu režiim: lihtne
klientide arv: 10
niidide arv: 1
tehingute arv kliendi kohta: 5000
töödeldud tehingute arv: 50000/50000

Testimise tulemused:

ILMA SSL-ita
SSL

Ühendus luuakse igas tehingus.

latentsuse keskmine
171.915 ms
187.695 ms

tps, sealhulgas ühenduste loomine
58.168112
53.278062

tps, välja arvatud ühenduste loomine
64.084546
58.725846

CPU
24%
28%

Kõik tehingud toimub ühes ühenduses.

latentsuse keskmine
6.722 ms
6.342 ms

tps, sealhulgas ühenduste loomine
1587.657278
1576.792883

tps, välja arvatud ühenduste loomine
1588.380574
1577.694766

CPU
17%
21%

Madala koormuse korral on SSL-i mõju võrreldav mõõtmise vea suurusega. Kui edastatava teabe maht on väga suur, võib olukord olla erinev. Kui me seome iga tehingu jaoks ühe ühenduse (see juhtub harva, tavaliselt jagavad kasutajad ühte ühendust), on ühenduste/eraldamiste arv suur ja mõju võib olla veidi suurem. See tähendab, et jõudluse vähenemise riskid võivad olla olemas, kuid erinevus ei ole piisavalt suur, et mitte kasutada kaitset.

Pange tähele — suur erinevus on olemas, kui võrrelda töörežiime: töötamine ühe sessiooni raames või erinevates sessioonides. See on selge: iga ühenduse loomisele kulub ressursse.

Meil oli juhtum, kui me ühendasime Zabbixi trust-režiimis, st md5 ei olnud kontrollitud, autentimise vajadust ei olnud. Hiljem palus tellija sisse lülitada md5-autentimise režiim. See tõi kaasa suure koormuse CPU-le, jõudlus langes. Hakkasime otsima optimeerimisvõimalusi. Üks võimalik lahendus probleemile on rakendada võrgupiirangut, luua andmebaasi jaoks eraldi VLAN, lisada seadeid, et oleks selge, kes ja kust ühendub, ning eemaldada autentimine. Samuti võib autentimise seadistusi optimeerida, et vähendada autentimise kaasnevaid kulusid, kuid üldiselt mõjutavad erinevad autentimismeetodid jõudlust ning need tegurid tuleb arvesse võtta serverite (rauda) arvutusvõimsuse kavandamisel andmebaasi jaoks.

Kokkuvõte: mitmes lahenduses võivad isegi väikesed autentimise nüansid projekti märkimisväärselt mõjutada ja on halb, kui see selgub alles tootmisse viimise käigus.

Tegevuste audit

Audit ei pea olema ainult andmebaasi. Audit on teave selle kohta, mis toimub erinevates segmentides. See võib hõlmata nii andmebaasi tulemüüri kui ka operatsioonisüsteemi, millele andmebaas toetub.

Kommertseandmebaasides, mis kuuluvad Enterprise tasemele, on auditiga kõik hästi, avatud lähtekoodiga lahendustes — mitte alati. Siin on, mis on saadaval PostgreSQL-is:

default log — sisseehitatud logimine;
extensions: pgaudit — kui vaikimisi logimine ei ole piisav, saab kasutada eraldi seadistusi, mis lahendavad osa probleeme.

Täiendamine aruandele videos:

Baastava registraatorite väljakutseid saab tagada standardse logimise tööriistaga, mille log_statement on seatud väärtusele 'all'.

See on vastuvõetav jälgimiseks ja muuks kasutamiseks, kuid ei paku tavaliselt vajalikku üksikasjalikkust auditi jaoks.

Lihtsalt kõigi andmebaasi toimingute loetelu ei ole piisav.

Samuti peab olema võimalik leida spetsiifilisi väiteid, mis huvitavad audiitoreid.

Standardne logimise tööriist näitab seda, mida kasutaja soovis, samas kui pgAudit keskendub sellele, mis tegelikult juhtus, kui andmebaas sooritas päringu.

Näiteks võib auditor soovida veenduda, et konkreetne tabel loodi dokumenteeritud hooldusaegadel.

See võib tunduda lihtsa ülesandena baasauditi ja grep'iga, kuid mis siis, kui sul on midagi sellist (intentionally confusing) näidist:

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

Standardne logimine annab teile selle:

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

Paistab, et huvitava tabeli leidmiseks võib osutuda vajalikuks teatud koodi tundmine, kui tabelid luuakse dünaamiliselt.

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

Siin tuleb kasuks pgAudit.

Sama sisendi jaoks annab see logis järgmise väljundi:

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)

Registreeritakse mitte ainult DO plokk, vaid ka täielik CREATE TABLE tekst koos toimingu tüübiga, objekti tüübiga ja täieliku nimega, mis lihtsustab otsingut.

SELECT ja DML toimingute logimise puhul saab pgAudit olla seadistatud registreerima eraldi kirje iga suhete kohta, millele viidatakse toimingus.

Süntaktilist analüüsi pole vaja, et leida kõik toimingud, mis puudutavad konkreetset tabelit (*)».

Kuidas see mõjutab andmebaasi jõudlust?

Tehkem teste täis auditi aktiviseerimisega ja vaatame, mis juhtub PostgreSQL tegevusega. Lülitame sisse maksimaalse DB logimise kõigi parameetrite jaoks.

Konfiguratsioonifailis ei muuda me peaaegu midagi, kuid oluline on, et lülitame sisse debug5 režiimi, et saada maksimaalselt 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'

PostgreSQL andmed 1 CPU, 2.8 GHz, 2 GB RAM, 40 GB HDD kohta teeme kolm koormustesti, kasutades 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

Kokkuvõtte täitmise aeg DBs
43,74 s
53,23 s

RAM
24%
40%

CPU
72%
91%

Test 1 (50 ühendust)

Tehingute arv 10 minuti jooksul
74169
32445

Tehingud/s
123
54

Keskmine latentsus
405 ms
925 ms

Test 2 (150 ühendust 100 võimalikust)

Tehingute arv 10 minuti jooksul
81727
31429

Tehingud/s
136
52

Keskmine latentsus
550 ms
1432 ms

Suuruste kohta

DB suurus
2251 MB
2262 MB

DB logide suurus
0 MB
4587 MB

Kokku: täielik audit ei ole eriti hea. Auditist saadav teave on mahult võrdne andmetega, mis on andmebaasis, või isegi suurem. Selline logimise maht, mis genereeritakse andmebasest töötades, on tavaline probleem tootmises.

Vaatame teisi parameetreid:

Kiirus ei muutu oluliselt: ilma logimiseta — 43,74 s, logimisega — 53,23 s.
Mäluse ja CPU jõudlus langeb, kuna tuleb luua auditifail. See on samuti silmatorkav tootmises.

Ühenduste arvu suurenedes on loogiliselt, et näitajad veidi halvenevad.

Korporatsioonides on audit veelgi keerulisem:

andmeid on palju;
audit on vajalik mitte ainult syslog kaudu SIEM-is, vaid ka failides: juhuks, kui syslogiga juhtub midagi, peab samas asuma fail, kuhu andmed salvestatakse;
auditi jaoks on vajalik eraldi riiul, et mitte kannatada I/O ketaste osas, kuna see võtab palju ruumi;
on juhtumeid, kus IT töötajatel on kõikjal vajalikud GOST-id, nad nõuavad riigi identifitseerimist.

Ligipääsu piiramine andmetele

Vaatame tehnoloogiaid, mida kasutatakse andmete ja nendele juurdepääsu kaitsmiseks äriklassi andmebaasides ning avatud lähtekoodiga lahendustes.

Mida üldiselt kasutada:

Krüpteerimine ja funktsioonide ja protseduuride obfuskatsioon (Wrapping) — need on eraldi tööriistad ja utiliidid, mis muudavad loetava koodi loetamatuks. Tõsi, hiljem ei saa seda muuta ega tagasi refaktoreerida. Selline lähenemine on mõnikord vajalik vähemalt andmebaasi tasemel — litsentsi piirangute või autoriseerimise loogika krüpteeritakse täpselt protseduuride ja funktsioonide tasemel.
Ridade nähtavuse andmete järgi (RLS) tähendab, et erinevad kasutajad näevad ühte tabelit, kuid erinevat ridade koosseisu, st kellelegi ei ole teatud andmed tasemel ridade näitamine lubatud.
Andmete redigeerimine (Masking) tähendab, et tabeli ühes veerus näevad kasutajad kas andmeid või ainult tärne, st teatud kasutajate jaoks on teave suletud. Tehnoloogia määrab, millist teavet kuvada vastavalt juurdepääsu tasemele.
Juurdepääsu piiramine Security DBA/Application DBA/DBA — see rääkib pigem juurdepääsu piiramisest enda DBMS-ile, st infoturbe töötajaid saab eristada andmebaasi administraatoritest ja rakenduse administraatoritest. Open source'is on selliseid tehnoloogiaid vähe, kuid kommerts DBMS-des on neid piisavalt. Need on vajalikud, kui palju kasutajaid saavad juurdepääsu serveritele.
Failide juurdepääsu piiramine failisüsteemi tasemel. Saame määrata õigusi ja juurdepääsu õigusi kataloogidele, et iga administraator saaks juurde ainult vajalikule teabele.
Mandaatne juurdepääs ja mäluhaldus — neid tehnoloogiaid rakendatakse harva.
Lõpust lõpuni krüptimine DBMS-is — see on kliendipoolselt krüptimine, kus võtmehaldus toimub serveripoolsel küljel.
Andmete krüptimine. Näiteks veeru krüptimine — kui kasutate mehhanismi, mis krüptib eraldi andmeveeru.

Kuidas see mõjutab DBMS-i jõudlust?

Vaadake PostgreSQL-i veeru krüptimise näitel. Seal on moodul pgcrypto, mis võimaldab salvestada valitud väljad krüptitud kujul. See on kasulik, kui väärtus esindavad ainult teatud andmed. Krüptitud väli lugemiseks edastab klient dekrüpteerimise võtme, server teeb andmed lahti ja väljastab need kliendile. Ilma võtmeta ei saa keegi teie andmetega midagi teha.

Teeme testi pgcrypto abil.. Loome tabeli, kus on krüptitud andmed ja tavalised andmed. Allpool on käsud tabelite loomiseks, esimene käsk on kasulik — haiguse loomiseks ja DBMS-i registreerimiseks:

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

Jätkame proovimist, et teha igast tabelist andmete valik ja vaatame täitmise ajad.

Tabeli valik ilma krüptimise funktsioonita:

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

Taimer on käivitatud.

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

Aeg: 1,386 ms

Tabeli valik krüptimise funktsiooniga:

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

Taimer 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 tootlikkust. On näha, et aeg on suurenenud, kuna krüpteeritud andmete dekrüpteerimise operatsioonid (ja dekrüpteerimine on tavaliselt veel ka teie loogikas) nõuavad märkimisväärseid ressursse. See tähendab, et idee krüptida kõik veerud, mis sisaldavad andmeid, on seotud tootlikkuse vähenemisega.

Samas ei ole krüptimine hõbedane kuul, mis lahendab kõik probleemid. Dekrüpteeritud andmed ja dekrüpteerimise võti asuvad dekrüpteerimise ja andmete edastamise protsessis serveris. Seetõttu võivad võtmed sattuda kätte kellelegi, kellel on juurdepääs andmebaasi serverile, näiteks süsteemiadministraatorile.

Kui kogu veeru jaoks on kõigile kasutajatele üks võtme (isegi kui see ei ole kõigi, vaid piiratud hulgale klientidele), pole see alati hea ja õige. Just seepärast hakati tegema lõpp-lõpuni krüptimist, andmebaasides hakati kaaluma andmete krüptimise variante kliendi ja serveri poolel, ilmusid need võtmehoidla - eraldi tooted, mis pakuvad võtmete haldamist andmebaasi poolel.

Näide sellisest krüptimisest MongoDB-s

Turvavahendid kaubanduslikes ja avatud lähtekoodiga andmebaasides

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

Oracle
Kaubanduslik
+
+
+
+
+

MsSql
Kaubanduslik
+
+
+
+
+

Jatoba
Kaubanduslik
+
+
+
+
laiendused

PostgreSQL
Tasuta
laiendused
laiendused
—
+
laiendused

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

Tabel ei ole sugugi täielik, kuid olukord on selline: kaubanduslikes toodetes on turvalisuse ülesandeid juba ammu lahendatud, avatud lähtekoodiga, tavaliselt kasutatakse turvalisuse jaoks mingeid lisandeid, paljusid funktsioone jääb puudu, mõnikord tuleb midagi lisaks kirjutada. Näiteks paroolipoliitikad - PostgreSQL-is on palju erinevaid laiendusi.1, 2, 3, 4, 5), mis tagavad paroolipoliitikad, kuid minu arvates ei kata ükski neist kõikide kodumaiste ettevõtete vajadusi.

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

Siis on võimalik kasutada kolmanda osapoole lahendusi, mis töötavad erinevate andmebaasidega, näiteks „Kripto DB” või „Garda DB”. Kui rääkida kodumaistest lahendustest, siis seal teavad nad GOSTide kohta paremini kui avatud lähtekoodiga.

Teine variant on kirjutada ise, mida on vaja, rakendada andmete juurdepääsu ja krüpteerimise protseduure rakenduse tasemel. Tõsi, GOSTiga on keerulisem. Kuid üldiselt - saate andmed peita, nagu vaja, salvestada andmebaasi, pärast seda välja võtta ja õigesti dekrüpteerida, otse rakenduse tasemel. Samuti mõelge kohe, kuidas te neid algoritme rakenduses kaitsete. Meie arvates tuleks see teha andmebaasi tasemel, kuna nii töötab see kiiremini.

See ettekande kuulutati esmakordselt @Andmebaasid Meetup Mail.ru Cloud Solutions poolt. Näe video teisi ettekandeid ja jälgi ürituste teadaandeid Telegramis Kubernetesest Mail.ru Groupis.

Mida veel selle kohta lugeda:

Allikas: habr.com