Ég heiti Denis Rozhkov, ég er yfirmaður hugbúnaðarþróunar hjá Gazinformservice fyrirtækinu, í vöruteyminu Jatoba. Lög og reglugerðir fyrirtækja setja ákveðnar kröfur um öryggi gagnageymslu. Enginn vill að þriðju aðilar fái aðgang að trúnaðarupplýsingum og því eru eftirfarandi atriði mikilvæg fyrir hvaða verkefni sem er: auðkenning og auðkenning, umsjón með aðgangi að gögnum, að tryggja heilleika upplýsinga í kerfinu, skráningu öryggisatburða. Þess vegna vil ég tala um nokkur áhugaverð atriði varðandi DBMS öryggi.

Greinin var unnin út frá erindi kl @DatabasesMeetup, skipulagt Mail.ru skýjalausnir. Ef þú vilt ekki lesa geturðu horft á:

Greinin verður í þremur hlutum:

• Hvernig á að tryggja tengingar.
• Hvað er úttekt á aðgerðum og hvernig á að skrá það sem er að gerast gagnagrunnsmegin og tengjast honum.
• Hvernig á að vernda gögn í gagnagrunninum sjálfum og hvaða tækni er tiltæk til þess.

Þrír þættir DBMS öryggis: tengingarvernd, athafnaskoðun og gagnavernd

Að tryggja tengingar þínar

Þú getur tengst gagnagrunninum annað hvort beint eða óbeint í gegnum vefforrit. Að jafnaði hefur viðskiptanotandinn, það er sá sem vinnur með DBMS, óbeint samskipti við það.

Áður en þú talar um að vernda tengingar þarftu að svara mikilvægum spurningum sem ákvarða hvernig öryggisráðstöfunum verður háttað:

• Er einn viðskiptanotandi jafngildur einum DBMS notanda?
• hvort aðgangur að DBMS gögnum sé aðeins veittur í gegnum API sem þú stjórnar, eða hvort töflur séu opnaðar beint;
• hvort DBMS sé úthlutað til aðskilins verndar hluta, hver hefur samskipti við það og hvernig;
• hvort notuð séu sameining/proxy og millilög sem geta breytt upplýsingum um hvernig tengingin er byggð upp og hverjir eru að nota gagnagrunninn.

Nú skulum við sjá hvaða verkfæri er hægt að nota til að tryggja tengingar:

1. Notaðu gagnagrunnseldveggslausnir. Viðbótarlag af vernd mun að minnsta kosti auka gagnsæi þess sem er að gerast í DBMS og að hámarki muntu geta veitt frekari gagnavernd.
2. Notaðu lykilorðastefnur. Notkun þeirra fer eftir því hvernig arkitektúr þinn er byggður. Í öllum tilvikum er eitt lykilorð í stillingarskrá vefforrits sem tengist DBMS ekki nóg til verndar. Það eru nokkur DBMS verkfæri sem gera þér kleift að stjórna því að notandi og lykilorð þurfi að uppfæra.

   Þú getur lesið meira um notendamatsaðgerðir hér, þú getur líka fundið út um MS SQL Vulnerability Assessmen hér. 

3. Auðgaðu samhengi fundarins með nauðsynlegum upplýsingum. Ef lotan er ógagnsæ, þú skilur ekki hver er að vinna í DBMS innan ramma þess, þú getur, innan ramma aðgerðarinnar, bætt við upplýsingum um hver er að gera hvað og hvers vegna. Þessar upplýsingar má sjá í úttektinni.
4. Stilltu SSL ef þú ert ekki með netaðskilnað milli DBMS og endanotenda; það er ekki í sérstöku VLAN. Í slíkum tilvikum er brýnt að vernda rásina milli neytenda og DBMS sjálfs. Öryggisverkfæri eru einnig fáanleg í opnum hugbúnaði.

Hvernig mun þetta hafa áhrif á frammistöðu DBMS?

Við skulum skoða dæmið um PostgreSQL til að sjá hvernig SSL hefur áhrif á CPU hleðsluna, eykur tímasetningar og lækkar TPS og hvort það muni eyða of mörgum auðlindum ef þú gerir það virkt.

Að hlaða PostgreSQL með pgbench er einfalt forrit til að keyra frammistöðupróf. Það framkvæmir eina röð skipana ítrekað, hugsanlega samhliða gagnagrunnslotum, og reiknar síðan út meðaltal viðskiptahlutfallsins.

Próf 1 án SSL og með SSL — tengingunni er komið á fyrir hverja færslu:

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"

Próf 2 án SSL og með SSL — öll viðskipti fara fram í einni tengingu:

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"

Aðrar stillingar:

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/50000

Niðurstöður prófa:

 
EKKERT SSL
SSL

Tenging er komið á fyrir hverja færslu

meðaltal biðtíma
171.915 MS
187.695 MS

tps þar á meðal að koma á tengingum
58.168112
53.278062

tps að undanskildum tengingum
64.084546
58.725846

CPU
24%
28%

Öll viðskipti fara fram í einni tengingu

meðaltal biðtíma
6.722 MS
6.342 MS

tps þar á meðal að koma á tengingum
1587.657278
1576.792883

tps að undanskildum tengingum
1588.380574
1577.694766

CPU
17%
21%

Við létt álag eru áhrif SSL sambærileg við mæliskekkjuna. Ef gagnamagnið er mjög mikið getur staðan verið önnur. Ef við komum á einni tengingu fyrir hverja færslu (þetta er sjaldgæft, venjulega er tengingunni deilt á milli notenda), þú hefur mikinn fjölda tenginga/rofa, áhrifin gætu verið aðeins meiri. Það er, það getur verið hætta á minni afköstum, hins vegar er munurinn ekki svo mikill að ekki sé notað vörn.

Vinsamlegast athugaðu að það er mikill munur ef þú berð saman rekstrarhamana: þú ert að vinna í sömu lotunni eða í mismunandi. Þetta er skiljanlegt: fjármagni er varið í að búa til hverja tengingu.

Við höfðum mál þegar við tengdum Zabbix í traustham, það er, md5 var ekki athugað, það var engin þörf á auðkenningu. Þá bað viðskiptavinurinn um að virkja md5 auðkenningarham. Þetta lagði mikið álag á örgjörvann og afköst féllu. Við fórum að leita leiða til að hagræða. Ein af mögulegum lausnum vandans er að innleiða nettakmarkanir, búa til aðskilin VLAN fyrir DBMS, bæta við stillingum til að gera það ljóst hver er að tengjast hvaðan og fjarlægja auðkenningu. Einnig er hægt að fínstilla auðkenningarstillingar til að draga úr kostnaði þegar auðkenning er virkjað, en almennt hefur notkun mismunandi aðferða auðkenningar áhrif á frammistöðu og krefst þess að taka tillit til þessara þátta þegar hannað er tölvukraftur netþjóna (vélbúnaðar) fyrir DBMS.

Ályktun: Í mörgum lausnum geta jafnvel lítil blæbrigði í auðkenningu haft mikil áhrif á verkefnið og það er slæmt þegar þetta kemur í ljós aðeins þegar það er innleitt í framleiðslu.

Aðgerðarúttekt

Endurskoðun getur ekki aðeins verið DBMS. Endurskoðun snýst um að afla upplýsinga um hvað er að gerast í mismunandi hlutum. Þetta getur annað hvort verið gagnagrunnseldveggur eða stýrikerfið sem DBMS er byggt á.

Í viðskiptalegum Enterprise Level DBMSs er allt í lagi með endurskoðun, en í opnum hugbúnaði - ekki alltaf. Hér er það sem PostgreSQL hefur:

• sjálfgefna skráningarskrá - innbyggð skráning;
• viðbætur: pgaudit - ef sjálfgefna skráning er ekki nóg fyrir þig geturðu notað aðskildar stillingar sem leysa sum vandamál.

Viðbót við skýrsluna í myndbandinu:

„Grunnskýrsluskráning er hægt að veita með venjulegri skráningaraðstöðu með log_statement = allt.

Þetta er ásættanlegt fyrir vöktun og aðra notkun, en veitir ekki það smáatriði sem venjulega er krafist fyrir endurskoðun.

Það er ekki nóg að hafa lista yfir allar aðgerðir sem gerðar eru á gagnagrunninum.

Einnig ætti að vera hægt að finna sérstakar yfirlýsingar sem vekur áhuga endurskoðanda.

Hefðbundin skráning sýnir hvað notandinn bað um, en pgAudit einbeitir sér að smáatriðum um hvað gerðist þegar gagnagrunnurinn framkvæmdi fyrirspurnina.

Til dæmis gæti endurskoðandinn viljað staðfesta að tiltekin tafla hafi verið búin til í skjalfestum viðhaldsglugga.

Þetta kann að virðast vera einfalt verkefni með grunnendurskoðun og grep, en hvað ef þér væri kynnt eitthvað eins og þetta (viljandi ruglingslegt) dæmi:

DO$$
Byrjaðu
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

Venjuleg skráning gefur þér þetta:

LOG: yfirlýsing: DO $$
Byrjaðu
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;

Svo virðist sem að finna áhugatöfluna gæti þurft einhverja kóðaþekkingu í þeim tilvikum þar sem töflur eru búnar til á kraftmikinn hátt.

Þetta er ekki tilvalið, þar sem æskilegra væri að leita einfaldlega eftir töfluheiti.

Þetta er þar sem pgAudit kemur sér vel.

Fyrir sama inntak mun það framleiða þetta úttak í log:

Endurskoðun: SESSION,33,1,FUNCTION,DO,,,"DO $$
Byrjaðu
EXECUTE 'CREATE TABLE import' || 'ant_table(id int)';
END$$;"
ENDURSKOÐUN: SESSION,33,2,DDL,BÚA TIL TÖFLU,TAFLA,public.important_table,BÚA TIL TÖFLU mikilvæg_töflu (id INT)

Ekki aðeins DO kubburinn er skráður, heldur einnig allur texti CREATE TABLE með yfirlýsingugerð, hlutgerð og fullu nafni, sem gerir leitina auðveldari.

Þegar SELECT og DML staðhæfingar eru skráðar er hægt að stilla pgAudit til að skrá sérstaka færslu fyrir hvert samband sem vísað er til í yfirlýsingunni.

Engin þáttun er nauðsynleg til að finna allar fullyrðingar sem snerta tiltekna töflu(*) ».

Hvernig mun þetta hafa áhrif á frammistöðu DBMS?

Við skulum keyra próf með fulla endurskoðun virka og sjá hvað verður um PostgreSQL árangur. Við skulum virkja hámarks gagnagrunnsskráningu fyrir allar breytur.

Við breytum nánast engu í stillingarskránni, mikilvægast er að kveikja á debug5 ham til að fá hámarksupplýsingar.

postgresql.conf

log_destination = 'stderr'
logging_collector = á
log_truncate_on_rotation = á
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = kemba5
log_min_error_statement = kemba5
log_min_duration_statement = 0
debug_print_parse = á
debug_print_rewritten = á
debug_print_plan = á
debug_pretty_print = á
log_checkpoints = á
log_connections = á
log_disconnections = á
log_duration = á
log_hostname = á
log_lock_wait = á
log_replication_commands = á
log_temp_files = 0
log_timezone = 'Evrópa/Moskva'

Á PostgreSQL DBMS með breytum upp á 1 CPU, 2,8 GHz, 2 GB vinnsluminni, 40 GB HDD, gerum við þrjú hleðslupróf með skipunum:

$ 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

Niðurstöður prófs:

Engin skráning
Með skógarhöggi

Heildarfyllingartími gagnagrunns
43,74 sek
53,23 sek

Vinnsluminni
24%
40%

CPU
72%
91%

Próf 1 (50 tengingar)

Fjöldi viðskipta á 10 mínútum
74169
32445

Viðskipti/sek
123
54

Meðallengd
405 ms
925 ms

Próf 2 (150 tengingar með 100 mögulegum)

Fjöldi viðskipta á 10 mínútum
81727
31429

Viðskipti/sek
136
52

Meðallengd
550 ms
1432 ms

Um stærðir

DB stærð
2251 MB
2262 MB

Stærð gagnagrunnsskrár
0 MB
4587 MB

Niðurstaða: heildarendurskoðun er ekki mjög góð. Gögnin úr úttektinni verða jafn stór og gögnin í gagnagrunninum sjálfum, eða jafnvel fleiri. Magn skógarhöggs sem myndast þegar unnið er með DBMS er algengt vandamál í framleiðslu.

Við skulum skoða aðrar breytur:

• Hraðinn breytist ekki mikið: án skráningar - 43,74 sekúndur, með skráningu - 53,23 sekúndur.
• Afköst vinnsluminni og örgjörva munu þjást, þar sem þú þarft að búa til endurskoðunarskrá. Þetta er líka áberandi í framleiðni.

Eftir því sem tengingum fjölgar mun frammistaðan að sjálfsögðu versna lítillega.

Í fyrirtækjum með endurskoðun er það enn erfiðara:

• það er mikið af gögnum;
• endurskoðunar er ekki aðeins þörf í gegnum syslog í SIEM, heldur einnig í skrám: ef eitthvað kemur fyrir syslog verður að vera skrá nálægt gagnagrunninum þar sem gögnin eru vistuð;
• þarf sérstaka hillu fyrir úttektina til að sóa ekki I/O diskum, þar sem hún tekur mikið pláss;
• Það kemur fyrir að starfsmenn upplýsingaöryggis þurfa GOST staðla alls staðar, þeir þurfa ríkisauðkenni.

Að takmarka aðgang að gögnum

Við skulum skoða tæknina sem er notuð til að vernda gögn og fá aðgang að þeim í viðskiptalegum DBMS og opnum uppspretta.

Hvað getur þú almennt notað:

1. Dulkóðun og óskýrun verklagsreglna og aðgerða (Wrapping) - það er aðskilin verkfæri og tól sem gera læsilegan kóða ólæsanlegan. Að vísu er því hvorki hægt að breyta né endurgera það aftur. Stundum er þörf á þessari nálgun að minnsta kosti á DBMS hliðinni - rökfræði leyfistakmarkana eða heimildarrökfræði er dulkóðuð nákvæmlega á verklags- og virknistigi.
2. Að takmarka sýnileika gagna eftir röðum (RLS) er þegar mismunandi notendur sjá eina töflu, en mismunandi samsetningu raða í henni, það er að segja að eitthvað er ekki hægt að sýna einhverjum á línustigi.
3. Breyting á birtum gögnum (gríma) er þegar notendur í einum dálki töflunnar sjá annað hvort gögn eða aðeins stjörnur, það er að segja fyrir suma notendur verða upplýsingarnar lokaðar. Tæknin ákvarðar hvaða notanda er sýnt hvað út frá aðgangsstigi þeirra.
4. Öryggi DBA/Application DBA/DBA aðgangsstýring snýst frekar um að takmarka aðgang að DBMS sjálfu, það er að segja að starfsmenn upplýsingaöryggis geta verið aðskildir frá gagnagrunnsstjórnendum og forritastjórnendum. Það er fá slík tækni í opnum hugbúnaði, en það er nóg af þeim í viðskiptalegum DBMS. Þeir eru nauðsynlegir þegar margir notendur hafa aðgang að netþjónunum sjálfum.
5. Að takmarka aðgang að skrám á skráarkerfisstigi. Þú getur veitt möppum réttindi og aðgangsréttindi þannig að hver stjórnandi hafi aðeins aðgang að nauðsynlegum gögnum.
6. Lögboðinn aðgangur og minnishreinsun - þessi tækni er sjaldan notuð.
7. Dulkóðun frá enda til enda beint frá DBMS er dulkóðun viðskiptavinar með lykilstjórnun á netþjóninum.
8. Gagna dulkóðun. Til dæmis er dálka dulkóðun þegar þú notar kerfi sem dulkóðar einn dálk gagnagrunnsins.

Hvernig hefur þetta áhrif á frammistöðu DBMS?

Við skulum skoða dæmið um dálka dulkóðun í PostgreSQL. Það er pgcrypto eining, það gerir þér kleift að geyma valda reiti á dulkóðuðu formi. Þetta er gagnlegt þegar aðeins sum gögn eru verðmæt. Til að lesa dulkóðuðu reitina sendir viðskiptavinurinn afkóðunarlykil, þjónninn afkóðar gögnin og skilar þeim til viðskiptavinarins. Án lykilsins getur enginn gert neitt við gögnin þín.

Við skulum prófa með pgcrypto. Búum til töflu með dulkóðuðum gögnum og venjulegum gögnum. Hér að neðan eru skipanirnar til að búa til töflur, í fyrstu línu er gagnleg skipun - að búa til viðbótina sjálfa með DBMS skráningu:

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

Næst skulum við reyna að gera gagnasýni úr hverri töflu og skoða framkvæmdartímana.

Val úr töflu án dulkóðunaraðgerðar:

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

Kveikt er á skeiðklukkunni.

  auðkenni | texti1 | texti 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 línur)

Tími: 1,386 ms

Val úr töflu með dulkóðunaraðgerð:

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

Kveikt er á skeiðklukkunni.

  auðkenni | afkóða | afkóða
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 línur)

Tími: 50,203 ms

Niðurstöður prófa:

 
Án dulkóðunar
Pgcrypto (afkóða)

Sýnishorn 1000 raðir
1,386 ms
50,203 ms

CPU
15%
35%

Vinnsluminni
 
+ 5%

Dulkóðun hefur mikil áhrif á frammistöðu. Það má sjá að tímasetningin hefur aukist, þar sem afkóðunaraðgerðir dulkóðaðra gagna (og afkóðun er venjulega enn umvafin rökfræði þinni) krefjast mikils fjármagns. Það er að segja, hugmyndin um að dulkóða alla dálka sem innihalda einhver gögn er full af lækkun á frammistöðu.

Hins vegar er dulkóðun ekki silfurkúla sem leysir öll vandamál. Afkóðuðu gögnin og afkóðunarlykillinn meðan á afkóðun og sendingu gagna stendur eru staðsett á þjóninum. Þess vegna getur einhver sem hefur fullan aðgang að gagnagrunnsþjóninum, eins og kerfisstjóri, hlerað lyklana.

Þegar það er einn lykill fyrir allan dálkinn fyrir alla notendur (jafnvel þó ekki fyrir alla, heldur fyrir viðskiptavini af takmörkuðu setti), þá er þetta ekki alltaf gott og rétt. Þess vegna byrjuðu þeir að gera end-to-end dulkóðun, í DBMS fóru þeir að íhuga valkosti fyrir dulkóðun gagna á biðlara- og netþjónahlið, og sömu lyklageymslur birtust - aðskildar vörur sem veita lyklastjórnun á DBMS hlið.

Dæmi um slíka dulkóðun í MongoDB

Öryggiseiginleikar í viðskiptalegum og opnum DBMS

Aðgerðir
Tegund
Lykilorðsstefna
Endurskoðun
Að vernda frumkóða verklagsreglna og aðgerða
RLS
dulkóðun

Oracle
auglýsing
+
+
+
+
+

MsSql
auglýsing
+
+
+
+
+

Jatoba
auglýsing
+
+
+
+
eftirnafn

PostgreSQL
Frjáls
eftirnafn
eftirnafn
-
+
eftirnafn

MongoDb
Frjáls
-
+
-
-
Aðeins í boði í MongoDB Enterprise

Taflan er langt frá því að vera tæmandi, en staðan er þessi: í viðskiptavörum hafa öryggisvandamál verið leyst í langan tíma, í opnum hugbúnaði eru að jafnaði notaðar einhvers konar viðbætur til öryggis, margar aðgerðir vantar , stundum þarf að bæta einhverju við. Til dæmis, lykilorðastefnur - PostgreSQL hefur margar mismunandi viðbætur (1, 2, 3, 4, 5), sem innleiða lykilorðastefnur, en að mínu mati nær engin þeirra til allra þarfa innlendra fyrirtækjahluta.

Hvað á að gera ef þú átt ekki það sem þú þarft einhvers staðar? Til dæmis viltu nota tiltekið DBMS sem hefur ekki þær aðgerðir sem viðskiptavinurinn krefst.

Þá er hægt að nota þriðja aðila lausnir sem vinna með mismunandi DBMS, til dæmis, Crypto DB eða Garda DB. Ef við erum að tala um lausnir frá innlendum hluta, þá vita þeir um GOSTs betur en í opnum uppspretta.

Annar kosturinn er að skrifa það sem þú þarft sjálfur, innleiða gagnaaðgang og dulkóðun í forritinu á aðferðarstigi. Að vísu verður það erfiðara með GOST. En almennt er hægt að fela gögnin eftir þörfum, setja þau í DBMS, síðan sækja þau og afkóða þau eftir þörfum, alveg á umsóknarstigi. Á sama tíma skaltu strax hugsa um hvernig þú munt vernda þessi forritalgrím. Að okkar mati ætti þetta að vera gert á DBMS stigi, því það mun virka hraðar.

Skýrsla þessi var fyrst kynnt kl @Databases Meetup frá Mail.ru Cloud Solutions. Sjáðu vídeó aðrar sýningar og gerast áskrifandi að viðburðatilkynningum á Telegram Í kringum Kubernetes hjá Mail.ru Group.

Hvað annað að lesa um efnið:

1. Meira en Ceph: MCS skýjablokkageymsla.
2. Hvernig á að velja gagnagrunn fyrir verkefni svo þú þurfir ekki að velja aftur.

Heimild: www.habr.com