Minu nimi on Denis Rožkov, olen tarkvaraarenduse juht ettevõttes Gazinformservice tootemeeskonnas . Õigusaktid ja ettevõtte määrused seavad andmete salvestamise turvalisusele teatud nõuded. Keegi ei taha, et kolmandad osapooled pääseksid ligi konfidentsiaalsele teabele, mistõttu on iga projekti puhul olulised järgmised küsimused: tuvastamine ja autentimine, andmetele juurdepääsu haldamine, info terviklikkuse tagamine süsteemis, turvasündmuste logimine. Seetõttu tahan rääkida mõnest huvitavast punktist seoses DBMS-i turvalisusega.
Artikkel on koostatud aadressil peetud kõne põhjal organiseeritud . Kui sa lugeda ei taha, saad vaadata:
Artikkel koosneb kolmest osast:
- Kuidas ühendusi kaitsta.
- Mis on toimingute audit ja kuidas salvestada andmebaasi poolel toimuvat ja sellega ühendumist.
- Kuidas kaitsta andmeid andmebaasis endas ja millised tehnoloogiad on selleks saadaval.
DBMS-i turvalisuse kolm komponenti: ühenduse kaitse, tegevuste auditeerimine ja andmekaitse
Ühenduste turvamine
Andmebaasiga saab ühenduse luua kas otse või kaudselt läbi veebirakenduste. Reeglina suhtleb ärikasutaja, st isik, kes DBMS-iga töötab, sellega kaudselt.
Enne ühenduste kaitsmisest rääkimist peate vastama olulistele küsimustele, mis määravad turvameetmete ülesehituse:
- Kas üks ärikasutaja on samaväärne ühe DBMS-i kasutajaga?
- kas juurdepääs DBMS-i andmetele on tagatud ainult teie juhitava API kaudu või pääseb tabelitele juurde otse;
- kas DBMS on eraldatud eraldi kaitstud segmendile, kes ja kuidas sellega suhtleb;
- kas kasutatakse kogumist/puhverserverit ja vahekihte, mis võivad muuta teavet selle kohta, kuidas ühendus on üles ehitatud ja kes andmebaasi kasutab.
Nüüd vaatame, milliseid tööriistu saab ühenduste turvamiseks kasutada:
- Kasutage andmebaasi tulemüüri klassi lahendusi. Täiendav kaitsekiht suurendab vähemalt DBMS-is toimuva läbipaistvust ja maksimaalselt saate pakkuda täiendavat andmekaitset.
- Kasutage paroolipoliitikat. Nende kasutamine sõltub sellest, kuidas teie arhitektuur on üles ehitatud. Igal juhul ei piisa kaitseks ühest paroolist DBMS-iga ühenduse loova veebirakenduse konfiguratsioonifailis. On mitmeid DBMS-i tööriistu, mis võimaldavad teil kontrollida, kas kasutaja ja parool vajavad värskendamist.
Lisateavet kasutajate hindamise funktsioonide kohta saate lugeda , saate tutvuda ka MS SQL-i haavatavuse hindajatega .
- Rikastage seansi konteksti vajaliku teabega. Kui seanss on läbipaistmatu, te ei saa aru, kes selle raamistikus DBMS-is töötavad, saate teostatava toimingu raames lisada teavet selle kohta, kes mida ja miks teeb. Seda teavet saab auditis näha.
- Konfigureerige SSL, kui teil pole DBMS-i ja lõppkasutajate vahel võrgueraldust; see pole eraldi VLAN-is. Sellistel juhtudel on hädavajalik kaitsta kanalit tarbija ja DBMS-i enda vahel. Turvatööriistad on saadaval ka avatud lähtekoodiga.
Kuidas see mõjutab DBMS-i jõudlust?
Vaatame PostgreSQL-i näidet, et näha, kuidas SSL mõjutab protsessori koormust, suurendab ajastust ja vähendab TPS-i ning kas see tarbib selle lubamisel liiga palju ressursse.
PostgreSQL-i laadimine pgbenchi abil on lihtne programm jõudlustestide käitamiseks. See täidab ühte käskude jada korduvalt, võimalusel paralleelsete andmebaasi seansside ajal, ja arvutab seejärel keskmise tehingumäära.
Test 1 ilma SSL-ita ja kasutades SSL-i — ühendus luuakse iga tehingu jaoks:
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 ilma SSL-ita ja kasutades SSL-i — kõik tehingud tehakse ü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"vs
pgbench.exe -c 10 -t 5000 "host=192.168.220.129 dbname=taskdb user=postgres"Muud seaded:
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/50000Katsetulemused:
SSL-i EI OLE
SSL
Iga tehingu jaoks luuakse ühendus
latentsusaeg 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
Protsessor
24%
28%
Kõik tehingud sooritatakse ühes ühenduses
latentsusaeg 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
Protsessor
17%
21%
Väikese koormuse korral on SSL-i mõju võrreldav mõõtmisveaga. Kui edastatavate andmete hulk on väga suur, võib olukord olla erinev. Kui loome ühe tehingu kohta ühe ühenduse (see on haruldane, tavaliselt on ühendus kasutajate vahel jagatud), on teil palju ühendusi/katkestusi, võib mõju olla veidi suurem. See tähendab, et võib esineda vähenenud jõudluse oht, kuid erinevus pole nii suur, et kaitset mitte kasutada.
Pange tähele, et töörežiimide võrdlemisel on suur erinevus: töötate sama seansi jooksul või erinevates. See on arusaadav: iga ühenduse loomiseks kulutatakse ressursse.
Meil oli juhus, kui ühendasime Zabbixi usaldusrežiimis ehk md5 ei kontrollitud, autentimist polnud vaja. Seejärel palus klient lubada md5 autentimisrežiimi. See pani protsessorile suure koormuse ja jõudlus langes. Hakkasime otsima võimalusi optimeerimiseks. Probleemi üheks võimalikuks lahenduseks on võrgupiirangute juurutamine, DBMS-i jaoks eraldi VLAN-ide tegemine, sätete lisamine, et oleks selge, kes kust ühendust võtab ja autentimise eemaldamine.Autentimise lubamisel saab kulude vähendamiseks optimeerida ka autentimisseadeid, kuid Üldiselt mõjutab erinevate autentimismeetodite kasutamine jõudlust ja nõuab nende tegurite arvestamist DBMS-i serverite (riistvara) arvutusvõimsuse kavandamisel.
Järeldus: paljude lahenduste puhul võivad isegi väikesed autentimise nüansid projekti oluliselt mõjutada ja on halb, kui see selgub alles tootmises.
Tegevuse audit
Audit võib olla mitte ainult DBMS. Auditi eesmärk on saada teavet erinevates segmentides toimuva kohta. See võib olla kas andmebaasi tulemüür või operatsioonisüsteem, millele DBMS on ehitatud.
Ärilise ettevõtte taseme DBMS-ides on auditeerimisega kõik korras, kuid avatud lähtekoodiga mitte alati. PostgreSQL-il on järgmine:
- vaikimisi logi - sisseehitatud logimine;
- laiendused: pgaudit - kui teie jaoks vaikelogimisest ei piisa, võite kasutada eraldi sätteid, mis lahendavad mõned probleemid.
Lisa reportaažile videos:
"Põhilausete logimise saab pakkuda standardse logimisvõimalusega, mille log_statement = kõik.
See on seireks ja muudeks kasutusteks vastuvõetav, kuid ei anna auditeerimiseks tavaliselt nõutavat üksikasjalikkuse taset.
Kõigi andmebaasis tehtud toimingute loendist ei piisa.
Samuti peaks olema võimalik leida konkreetseid väiteid, mis audiitorile huvi pakuvad.
Tavaline logimine näitab, mida kasutaja taotles, samas kui pgAudit keskendub üksikasjadele, mis juhtus, kui andmebaas päringu täitis.
Näiteks võib audiitor soovida kontrollida, kas konkreetne tabel loodi dokumenteeritud hooldusaknas.
See võib tunduda lihtsa ülesandena koos põhilise auditeerimise ja grepiga, kuid mis juhtuks, kui teile esitataks midagi sellist (tahtlikult segadust tekitav) näide:
TEE $$
BEGIN
KÄIVITA 'LOO TABELI import' || 'ant_table(id int)';
END$$;
Standardne logimine annab teile järgmise:
LOG: avaldus: DO $$
BEGIN
KÄIVITA 'LOO TABELI import' || 'ant_table(id int)';
END$$;
Näib, et huvipakkuva tabeli leidmine võib nõuda teatud kooditeadmisi juhtudel, kui tabelid luuakse dünaamiliselt.
See pole ideaalne, sest eelistatav oleks otsida lihtsalt tabeli nime järgi.
Siin on pgAudit kasulik.
Sama sisendi puhul loob see logis järgmise väljundi:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGIN
KÄIVITA 'LOO TABELI import' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION,33,2,DDL,LOO TABEL,TABEL,avalik.tähtis_tabel,LOO TABEL oluline_tabel (id INT)
Logitakse mitte ainult DO-plokki, vaid ka CREATE TABLE'i täisteksti koos avalduse tüübi, objekti tüübi ja täisnimega, muutes otsingu lihtsamaks.
SELECT- ja DML-lausete logimisel saab pgAuditi konfigureerida logima eraldi kirjet iga lauses viidatud seose kohta.
Kõigi konkreetset tabelit puudutavate lausete leidmiseks pole parsimist vaja () ».
Kuidas see mõjutab DBMS-i jõudlust?
Käivitame testid täieliku auditeerimisega ja vaatame, mis juhtub PostgreSQL-i jõudlusega. Lubame kõigi parameetrite jaoks maksimaalse andmebaasi logimise.
Me ei muuda konfiguratsioonifailis peaaegu midagi, kõige olulisem on maksimaalse teabe saamiseks sisse lülitada debug5 režiim.
postgresql.conf
log_destination = 'stderr'
logimine_koguja = sees
log_truncate_on_rotation = sees
logi_rotatsiooni_vanus = 1 p
log_rotation_size = 10 MB
log_min_messages = silumine5
log_min_error_statement = silumine5
log_min_duration_statement = 0
debug_print_parse = sees
debug_print_rewritten = sees
debug_print_plan = sees
debug_pretty_print = sees
log_checkpoints = sees
log_connections = sees
log_disconnections = sees
log_duration = sees
logi_hostinimi = sees
log_lock_wait = sees
log_replication_commands = sees
log_temp_files = 0
log_timezone = 'Euroopa/Moskva'
PostgreSQL DBMS-is, mille parameetrid on 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, viime läbi kolm koormustesti, kasutades käske:
$ 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 benchmarkTesti tulemused:
Ei mingit metsaraiet
Koos metsaraietega
Andmebaasi täitmise koguaeg
43,74 sek
53,23 sek
RAM
24%
40%
Protsessor
72%
91%
Test 1 (50 ühendust)
Tehingute arv 10 minuti jooksul
74169
32445
Tehingud/s
123
54
Keskmine latentsusaeg
405 ms
925 ms
Test 2 (150 ühendust ja 100 võimalikku)
Tehingute arv 10 minuti jooksul
81727
31429
Tehingud/s
136
52
Keskmine latentsusaeg
550 ms
1432 ms
Suuruste kohta
DB suurus
2251 MB
2262 MB
Andmebaasi logi suurus
0 MB
4587 MB
Kokkuvõte: täielik audit ei ole kuigi hea. Auditi andmed on sama suured kui andmebaasis olevad andmed või isegi rohkem. DBMS-iga töötamisel genereeritavate logide hulk on tootmises tavaline probleem.
Vaatame teisi parameetreid:
- Kiirus palju ei muutu: ilma logimiseta - 43,74 sekundit, logimisega - 53,23 sekundit.
- RAM ja CPU jõudlus kannatavad, kuna peate looma auditifaili. Seda on märgata ka tootlikkuses.
Kui ühenduste arv suureneb, siis loomulikult halveneb jõudlus veidi.
Auditiga ettevõtetes on see veelgi keerulisem:
- andmeid on palju;
- auditeerimist on vaja mitte ainult SIEM-is syslogi kaudu, vaid ka failides: kui syslogiga midagi juhtub, peab andmebaasi lähedal olema fail, kuhu andmed salvestatakse;
- auditeerimiseks on vaja eraldi riiulit, et mitte raisata I/O-ketastele, kuna see võtab palju ruumi;
- Juhtub, et infoturbe töötajad vajavad kõikjal GOST-i standardeid, nad nõuavad riiklikku identifitseerimist.
Andmetele juurdepääsu piiramine
Vaatame tehnoloogiaid, mida kasutatakse andmete kaitsmiseks ja neile juurdepääsuks kaubanduslikes DBMS-ides ja avatud lähtekoodiga.
Mida saate üldiselt kasutada:
- Protseduuride ja funktsioonide krüptimine ja hägustamine (Wrapping) – see tähendab eraldi tööriistad ja utiliidid, mis muudavad loetava koodi loetamatuks. Tõsi, siis ei saa seda ei muuta ega tagasi teha. Selline lähenemine on mõnikord vajalik vähemalt DBMS-i poolel – litsentsipiirangute või autoriseerimisloogika on krüpteeritud täpselt protseduuride ja funktsioonide tasemel.
- Andmete nähtavuse piiramine ridade kaupa (RLS) on see, kui erinevad kasutajad näevad ühte tabelit, kuid selles on ridade koostis erinev, ehk siis midagi ei saa rea tasemel kellelegi näidata.
- Kuvatavate andmete redigeerimine (maskimine) on see, kui kasutajad tabeli ühes veerus näevad kas andmeid või ainult tärnisid, st mõne kasutaja puhul suletakse teave. Tehnoloogia määrab, millisele kasutajale mida näidatakse, lähtudes nende juurdepääsutasemest.
- Turvalisus DBA/rakenduse DBA/DBA juurdepääsukontroll on pigem juurdepääsu piiramine DBMS-ile endale, st infoturbe töötajad saab eraldada andmebaasi administraatoritest ja rakenduste administraatoritest. Avatud lähtekoodiga tehnoloogiaid on vähe, kuid kaubanduslikes DBMS-ides on neid palju. Neid on vaja siis, kui on palju kasutajaid, kellel on juurdepääs serveritele.
- Failidele juurdepääsu piiramine failisüsteemi tasemel. Saate anda kataloogidele õigusi ja juurdepääsuõigusi, et igal administraatoril oleks juurdepääs ainult vajalikele andmetele.
- Kohustuslik juurdepääs ja mälu tühjendamine – neid tehnoloogiaid kasutatakse harva.
- Otsest lõpuni krüptimine otse DBMS-ist on kliendipoolne krüptimine võtmehaldusega serveri poolel.
- Andmete krüpteerimine. Näiteks veergude krüpteerimine on siis, kui kasutate mehhanismi, mis krüpteerib andmebaasi ühe veeru.
Kuidas see mõjutab DBMS-i jõudlust?
Vaatame PostgreSQL-i kolonnkrüptimise näidet. Seal on pgcrypto moodul, mis võimaldab salvestada valitud väljad krüpteeritud kujul. See on kasulik, kui ainult osa andmetest on väärtuslikud. Krüpteeritud väljade lugemiseks edastab klient dekrüpteerimisvõtme, server dekrüpteerib andmed ja tagastab need kliendile. Ilma võtmeta ei saa keegi teie andmetega midagi peale hakata.
Testime pgcryptoga. Koostame krüpteeritud andmete ja tavaandmetega tabeli. Allpool on käsud tabelite loomiseks, kõige esimesel real on kasulik käsk - laienduse loomine DBMS-i 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'));Järgmiseks proovime teha igast tabelist andmenäidise ja vaatame täitmise ajastusi.
Tabelist valimine ilma krüpteerimisfunktsioonita:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtStopper on sisse lülitatud.
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
Valik krüpteerimisfunktsiooniga tabelist:
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.txtStopper on sisse lülitatud.
id | dekrüpteerida | dekrüpteerida
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 rida)
Aeg: 50,203 ms
Katsetulemused:
Ilma krüptimiseta
Pgcrypto (dekrüpteerimine)
Näidis 1000 rida
1,386 ms
50,203 ms
Protsessor
15%
35%
RAM
+ 5%
Krüpteerimisel on jõudlusele suur mõju. On näha, et ajastus on suurenenud, kuna krüptitud andmete dekrüpteerimistoimingud (ja dekrüpteerimine on tavaliselt endiselt teie loogikasse mähitud) nõuavad märkimisväärseid ressursse. See tähendab, et kõigi andmeid sisaldavate veergude krüpteerimise idee on tulvil jõudluse vähenemisega.
Kuid krüpteerimine ei ole hõbekuul, mis lahendab kõik probleemid. Dekrüpteeritud andmed ja dekrüpteerimisvõti andmete dekrüpteerimise ja edastamise käigus asuvad serveris. Seetõttu võib võtmeid pealt kuulata keegi, kellel on täielik juurdepääs andmebaasiserverile, näiteks süsteemiadministraator.
Kui kogu veeru jaoks on kõigi kasutajate jaoks üks võti (isegi kui mitte kõigi, vaid piiratud hulga klientide jaoks), pole see alati hea ja õige. Sellepärast hakkasid nad tegema otsast lõpuni krüptimist, DBMS-is hakkasid nad kaaluma võimalusi andmete krüpteerimiseks kliendi ja serveri poolel ning ilmusid samad võtmehoidlad - eraldi tooted, mis pakuvad DBMS-is võtmehaldust. pool.
Turbefunktsioonid kommerts- ja avatud lähtekoodiga DBMS-is
Funktsioonid
Tüüp
Paroolipoliitika
Audit
Protseduuride ja funktsioonide lähtekoodi kaitsmine
RLS
Krüpteerimine
Oraakel
kaubanduslikud
+
+
+
+
+
MsSql
kaubanduslikud
+
+
+
+
+
kaubanduslikud
+
+
+
+
laiendused
PostgreSQL
tasuta
laiendused
laiendused
-
+
laiendused
MongoDb
tasuta
-
+
-
-
Saadaval ainult MongoDB Enterprise'is
Tabel pole kaugeltki täielik, kuid olukord on järgmine: kommertstoodetes on turvaprobleemid juba pikka aega lahendatud, avatud lähtekoodiga kasutatakse reeglina turvalisuse tagamiseks mingeid lisandmooduleid, paljud funktsioonid puuduvad , vahel tuleb midagi lisada. Näiteks paroolipoliitikad – PostgreSQL-il on palju erinevaid laiendusi (, , , , ), mis rakendavad paroolipoliitikaid, kuid minu arvates ei kata ükski neist kõiki kodumaise ettevõtete segmendi vajadusi.
Mida teha, kui teil pole kuskil seda, mida vajate? Näiteks soovite kasutada konkreetset DBMS-i, millel pole kliendi soovitud funktsioone.
Seejärel saate kasutada kolmanda osapoole lahendusi, mis töötavad erinevate DBMS-idega, näiteks Crypto DB või Garda DB. Kui me räägime kodumaise segmendi lahendustest, siis teavad nad GOST-idest paremini kui avatud lähtekoodiga.
Teine võimalus on kirjutada ise, mida vajate, rakendada andmetele juurdepääsu ja krüptimise protseduuri tasemel rakenduses. Tõsi, GOSTiga on see keerulisem. Kuid üldiselt saate andmed vajaduse korral peita, panna need DBMS-i, seejärel need alla laadida ja vajadusel dekrüpteerida otse rakenduse tasemel. Samal ajal mõelge kohe, kuidas neid algoritme rakenduses kaitsta. Meie arvates tuleks seda teha DBMS-i tasemel, sest see töötab kiiremini.
Seda aruannet esitleti esmakordselt kl Mail.ru pilvelahendused. Vaatateisi esinemisi ja tellige Telegramis sündmuste teated .
Mida muud selle teema kohta lugeda:
- .
- .
Allikas: www.habr.com