Myn namme is Denis Rozhkov, ik bin it haad fan softwareûntwikkeling by it bedriuw Gazinformservice, yn it produktteam . Wetjouwing en bedriuwsregels stelle bepaalde easken op foar de feiligens fan gegevensopslach. Nimmen wol dat tredden tagong krije ta fertroulike ynformaasje, dus de folgjende problemen binne wichtich foar elk projekt: identifikaasje en autentikaasje, behear fan tagong ta gegevens, garandearjen fan de yntegriteit fan ynformaasje yn it systeem, logging fan feiligenseveneminten. Dêrom wol ik prate oer wat nijsgjirrige punten oangeande DBMS-feiligens.
It artikel waard taret basearre op in taspraak by organisearre . As jo net lêze wolle, kinne jo besjen:
It artikel sil trije dielen hawwe:
- Hoe kinne jo ferbiningen befeiligje.
- Wat is in kontrôle fan aksjes en hoe kinne jo opnimme wat der bart oan 'e databankkant en dêrmei ferbine.
- Hoe kinne jo gegevens yn 'e databank sels beskermje en hokker technologyen hjirfoar beskikber binne.
Trije komponinten fan DBMS-feiligens: ferbiningsbeskerming, aktiviteitskontrôle en gegevensbeskerming
Jo ferbiningen befeiligje
Jo kinne direkt of yndirekt ferbine mei de databank fia webapplikaasjes. As regel, de saaklike brûker, dat is de persoan dy't wurket mei de DBMS, ynteraksje mei it yndirekt.
Foardat jo prate oer it beskermjen fan ferbiningen, moatte jo wichtige fragen beantwurdzje dy't bepale hoe't befeiligingsmaatregels sille wurde strukturearre:
- Is ien saaklike brûker lykweardich oan ien DBMS-brûker?
- oft tagong ta DBMS-gegevens allinich wurdt levere fia in API dy't jo kontrolearje, of oft tabellen direkt tagonklik wurde;
- oft it DBMS wurdt tawiisd oan in apart beskerme segmint, wa't ynteraksje mei it en hoe;
- oft pooling / proxy en tuskenlizzende lagen wurde brûkt, dat kin feroarje ynformaasje oer hoe't de ferbining wurdt boud en wa't brûkt de databank.
Litte wy no sjen hokker ark kinne wurde brûkt om ferbiningen te befeiligjen:
- Brûk database firewall klasse oplossings. In ekstra laach fan beskerming sil op syn minst de transparânsje fan wat der bart yn 'e DBMS ferheegje, en op' e maksimum kinne jo ekstra gegevensbeskerming leverje.
- Brûk wachtwurdbelied. Har gebrûk hinget ôf fan hoe't jo arsjitektuer is boud. Yn alle gefallen is ien wachtwurd yn it konfiguraasjetriem fan in webapplikaasje dy't ferbynt mei de DBMS net genôch foar beskerming. D'r binne in oantal DBMS-ark wêrmei jo kinne kontrolearje dat de brûker en wachtwurd bywurkje moatte.
Jo kinne mear lêze oer funksjes foar brûkersbeoardieling , Jo kinne ek útfine oer MS SQL Vulnerability Assessmen .
- Ferrykje de kontekst fan 'e sesje mei de nedige ynformaasje. As de sesje ûntrochsichtich is, begripe jo net wa't yn 'e DBMS wurket yn har ramt, jo kinne, yn' t ramt fan 'e operaasje dy't wurdt útfierd, ynformaasje tafoegje oer wa't wat docht en wêrom. Dizze ynformaasje is te sjen yn 'e kontrôle.
- Konfigurearje SSL as jo gjin netwurkskieding hawwe tusken de DBMS en ein brûkers; it is net yn in aparte VLAN. Yn sokke gefallen is it ymperatyf om it kanaal te beskermjen tusken de konsumint en de DBMS sels. Feiligens ark binne ek beskikber yn iepen boarne.
Hoe sil dit de prestaasjes fan 'e DBMS beynfloedzje?
Litte wy nei it foarbyld fan PostgreSQL sjen om te sjen hoe't SSL de CPU-lading beynfloedet, timings fergruttet en TPS fermindert, en oft it tefolle boarnen sil konsumearje as jo it ynskeakelje.
It laden fan PostgreSQL mei pgbench is in ienfâldich programma foar it útfieren fan prestaasjestests. It fiert in inkele folchoarder fan kommando's werhelle, mooglik yn parallelle databank sesjes, en dan berekkene de gemiddelde transaksje taryf.
Test 1 sûnder SSL en mei SSL - de ferbining wurdt makke foar elke transaksje:
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 sûnder SSL en mei SSL - alle transaksjes wurde útfierd yn ien ferbining:
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"Oare ynstellings:
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/50000Testresultaten:
NO SSL
SSL
In ferbining wurdt makke foar elke transaksje
latency gemiddelde
171.915 ms
187.695 ms
tps ynklusyf ferbinings oprjochting
58.168112
53.278062
tps útsein ferbinings oprjochting
64.084546
58.725846
CPU
24%
28%
Alle transaksjes wurde útfierd yn ien ferbining
latency gemiddelde
6.722 ms
6.342 ms
tps ynklusyf ferbinings oprjochting
1587.657278
1576.792883
tps útsein ferbinings oprjochting
1588.380574
1577.694766
CPU
17%
21%
By lichte loads is de ynfloed fan SSL te fergelykjen mei de mjitflater. As de hoemannichte oerdroegen gegevens heul grut is, kin de situaasje oars wêze. As wy ien ferbining per transaksje fêstigje (dit is seldsum, meastentiids wurdt de ferbining dield tusken brûkers), jo hawwe in grut oantal ferbinings / ôfbrekken, de ynfloed kin in bytsje grutter wêze. Dat is, d'r kinne risiko's wêze fan fermindere prestaasjes, lykwols, it ferskil is net sa grut om gjin beskerming te brûken.
Tink derom dat d'r in sterk ferskil is as jo de bestjoeringsmodi fergelykje: jo wurkje binnen deselde sesje as yn ferskate. Dit is begryplik: boarnen wurde bestege oan it meitsjen fan elke ferbining.
Wy hiene in saak doe't wy ferbûn Zabbix yn fertrouwen modus, dat is, md5 waard net kontrolearre, der wie gjin ferlet fan autentikaasje. Doe frege de klant om md5-ferifikaasjemodus yn te skeakeljen. Dit sette in swiere lêst op 'e CPU, en prestaasjes sakke. Wy begûnen te sykjen nei manieren om te optimalisearjen. Ien fan 'e mooglike oplossingen foar it probleem is it ymplementearjen fan netwurkbeperkingen, it meitsjen fan aparte VLAN's foar de DBMS, tafoegje ynstellings om dúdlik te meitsjen wa't wêr't ferbining is en autentikaasje fuortsmite. yn it algemien it brûken fan ferskate metoaden ferifikaasje beynfloedet prestaasjes en fereasket nimme dizze faktoaren rekken by it ûntwerpen fan de kompjûter krêft fan tsjinners (hardware) foar de DBMS.
Konklúzje: yn in oantal oplossingen kinne sels lytse nuânses yn 'e autentikaasje in protte ynfloed hawwe op it projekt en it is min as dit allinich dúdlik wurdt as it yn produksje útfierd wurdt.
Aksje audit
Audit kin net allinich DBMS wêze. In kontrôle giet oer it krijen fan ynformaasje oer wat der bart yn ferskate segminten. Dit kin of in database-firewall wêze as it bestjoeringssysteem wêrop de DBMS is boud.
Yn kommersjele Enterprise-nivo DBMS's is alles goed mei auditing, mar yn iepen boarne - net altyd. Hjir is wat PostgreSQL hat:
- standert log - ynboude logging;
- tafoegings: pgaudit - as standert logging net genôch is foar jo, kinne jo aparte ynstellings brûke dy't guon problemen oplosse.
Tafoeging oan it rapport yn 'e fideo:
"Basisoanmeldingslogging kin wurde levere troch in standert loggingfoarsjenning mei log_statement = all.
Dit is akseptabel foar tafersjoch en oare gebrûk, mar jout net it nivo fan detail dat typysk nedich is foar kontrôle.
It is net genôch om in list te hawwen fan alle operaasjes útfierd op 'e databank.
It moat ek mooglik wêze om spesifike útspraken te finen dy't fan belang binne foar de rekkenkeamer.
Standert logging lit sjen wat de brûker frege, wylst pgAudit him rjochtet op de details fan wat barde doe't de databank útfierd de query.
Bygelyks, de auditor kin ferifiearje dat in bepaalde tabel is makke binnen in dokumintearre ûnderhâld finster.
Dit kin lykje as in ienfâldige taak mei basis auditing en grep, mar wat as jo waarden presintearre mei wat as dit (opsetsin betiizjend) foarbyld:
DO$$
BEGJINNE
EXECUTE 'CREATE TABLE ymportearje' || 'ant_table(id int)';
END$$;
Standert logging sil jo dit jaan:
LOG: statement: DO $$
BEGJINNE
EXECUTE 'CREATE TABLE ymportearje' || 'ant_table(id int)';
END$$;
It docht bliken dat it finen fan de tabel fan belang kin wat koade kennis fereaskje yn gefallen dêr't tabellen wurde makke dynamysk.
Dit is net ideaal, om't it de foarkar is om gewoan op tabelnamme te sykjen.
Dit is wêr pgAudit fan pas komt.
Foar deselde ynfier sil it dizze útfier produsearje yn it log:
AUDIT: SESSION,33,1,FUNCTION,DO,,,"DO $$
BEGJINNE
EXECUTE 'CREATE TABLE ymportearje' || 'ant_table(id int)';
END$$;"
AUDIT: SESSION, 33,2, XNUMX, DDL, CREATE TABLE, TABLE, public.important_table, CREATE TABEL wichtich_tabel (id INT)
Net allinich it DO-blok wurdt oanmeld, mar ek de folsleine tekst fan 'e CREATE TABLE mei statementtype, objekttype en folsleine namme, wêrtroch it sykjen makliker wurdt.
By it oanmelden fan SELECT- en DML-útspraken, kin pgAudit wurde ynsteld om in aparte yngong te loggen foar elke relaasje dy't yn 'e ferklearring ferwiisd wurdt.
Gjin parsing is nedich om alle útspraken te finen dy't in bepaalde tabel oanreitsje () ».
Hoe sil dit de prestaasjes fan 'e DBMS beynfloedzje?
Litte wy tests útfiere mei folsleine auditing ynskeakele en sjen wat der bart mei PostgreSQL-prestaasjes. Litte wy maksimale databanklogging ynskeakelje foar alle parameters.
Wy feroarje hast neat yn 'e konfiguraasjetriem, it wichtichste is om de debug5-modus yn te skeakeljen om maksimale ynformaasje te krijen.
postgresql.conf
log_destination = 'stderr'
logging_collector = oan
log_truncate_on_rotation = oan
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_berjochten = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = oan
debug_print_rewritten = oan
debug_print_plan = oan
debug_pretty_print = oan
log_checkpoints = oan
log_connections = oan
log_disconnections = oan
log_duration = oan
log_hostname = oan
log_lock_wait = oan
log_replication_commands = oan
log_temp_files = 0
log_timezone = 'Europa/Moskou'
Op in PostgreSQL DBMS mei parameters fan 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, fiere wy trije loadtests út mei de kommando's:
$ 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 benchmarkTestresultaten:
Gjin logging
Mei logging
Totale databankfollingtiid
43,74 sek
53,23 sek
RAM
24%
40%
CPU
72%
91%
Test 1 (50 ferbiningen)
Oantal transaksjes yn 10 minuten
74169
32445
Transaksjes / sek
123
54
Gemiddelde latency
405 ms
925 ms
Test 2 (150 ferbiningen mei 100 mooglik)
Oantal transaksjes yn 10 minuten
81727
31429
Transaksjes / sek
136
52
Gemiddelde latency
550 ms
1432 ms
Oer maten
DB grutte
2251 MB
2262 MB
Databank log grutte
0 MB
4587 MB
Bottom line: in folsleine kontrôle is net hiel goed. De gegevens fan 'e kontrôle sille sa grut wêze as de gegevens yn' e databank sels, of sels mear. De hoemannichte logging dat wurdt generearre by it wurkjen mei in DBMS is in mienskiplik probleem yn produksje.
Litte wy nei oare parameters sjen:
- De snelheid feroaret net folle: sûnder logging - 43,74 sekonden, mei logging - 53,23 sekonden.
- RAM- en CPU-prestaasjes sille lije, om't jo in kontrôletriem moatte generearje. Dit is ek te merken yn produktiviteit.
As it oantal ferbiningen tanimt, sil de prestaasjes fansels wat minder wurde.
Yn korporaasjes mei kontrôle is it noch dreger:
- der is in protte gegevens;
- auditing is net allinnich nedich fia syslog yn SIEM, mar ek yn triemmen: as der wat mei syslog bart, moat der in triem tichtby de databank wêze wêryn de gegevens bewarre wurde;
- foar auditing is in aparte planke nedich om net te fergriemen op I/O-skiven, om't it in soad romte nimt;
- It bart dat meiwurkers fan ynformaasjefeiligens oeral GOST-standerts nedich binne, se fereaskje steatidentifikaasje.
Beheine tagong ta gegevens
Litte wy nei de technologyen sjen dy't wurde brûkt om gegevens te beskermjen en tagong te krijen yn kommersjele DBMS's en iepen boarne.
Wat kinne jo algemien brûke:
- Fersifering en obfuscation fan prosedueres en funksjes (Wrapping) - dat is, aparte ark en nutsbedriuwen dy't lêsbere koade ûnlêsber meitsje. Wier, dan kin it noch net feroare wurde, noch werombetelle. Dizze oanpak is soms fereaske op syn minst oan 'e DBMS-kant - de logika fan lisinsjebeperkingen of autorisaasjelogika is krekt fersifere op it proseduere- en funksjenivo.
- It beheinen fan de sichtberens fan gegevens troch rigen (RLS) is as ferskate brûkers ien tabel sjogge, mar in oare gearstalling fan rigen dêryn, dat is, iets kin net oan ien op it rigelnivo sjen litten wurde.
- It bewurkjen fan de werjûn gegevens (maskering) is wannear't brûkers yn ien kolom fan 'e tabel òf gegevens as allinnich asterisken sjogge, dat is, foar guon brûkers sil de ynformaasje sluten wurde. De technology bepaalt hokker brûker wat wurdt sjen litten op basis fan har tagongsnivo.
- Feiligens DBA / Applikaasje DBA / DBA tagongskontrôle is, leaver, oer it beheinen fan tagong ta de DBMS sels, dat is, meiwurkers fan ynformaasjefeiligens kinne wurde skieden fan databankbehearders en applikaasjebehearders. D'r binne in pear sokke technologyen yn iepen boarne, mar d'r binne genôch fan har yn kommersjele DBMS's. Se binne nedich as d'r in protte brûkers binne mei tagong ta de servers sels.
- Beheine tagong ta bestannen op it nivo fan bestânsysteem. Jo kinne rjochten en tagongsrjochten jaan oan mappen, sadat elke behearder allinich tagong hat ta de nedige gegevens.
- Ferplichte tagong en ûnthâld wiskjen - dizze technologyen wurde komselden brûkt.
- End-to-end fersifering direkt fan de DBMS is client-side fersifering mei kaai behear oan de server kant.
- Data fersifering. Kolumnêre fersifering is bygelyks as jo in meganisme brûke dat in inkele kolom fan 'e databank fersiferet.
Hoe hat dit ynfloed op de prestaasjes fan 'e DBMS?
Litte wy nei it foarbyld sjen fan kolomêre fersifering yn PostgreSQL. D'r is in pgcrypto-module, it lit jo selektearre fjilden yn fersifere foarm opslaan. Dit is handich as mar guon gegevens weardefol binne. Om de fersifere fjilden te lêzen, stjoert de kliïnt in dekodearringskaai oer, de tsjinner ûntsiferet de gegevens en jout it werom nei de kliïnt. Sûnder de kaai kin gjinien wat dwaan mei jo gegevens.
Litte wy testen mei pgcrypto. Litte wy in tabel meitsje mei fersifere gegevens en reguliere gegevens. Hjirûnder binne de kommando's foar it meitsjen fan tabellen, yn 'e earste rigel is d'r in nuttich kommando - it meitsjen fan de tafoeging sels mei DBMS-registraasje:
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'));Litte wy dan besykje in gegevensmonster te meitsjen fan elke tabel en sjoch nei de útfieringstiid.
Selektearje út in tabel sûnder fersiferingsfunksje:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtDe stopwatch stiet oan.
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 rigels)
Tiid: 1,386 ms
Seleksje út in tabel mei fersiferingsfunksje:
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.txtDe stopwatch stiet oan.
id | ûntsiferje | ûntsiferje
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 rigels)
Tiid: 50,203 ms
Testresultaten:
Sûnder fersifering
Pgcrypto (ûntsiferje)
Sample 1000 rigen
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Fersifering hat in grutte ynfloed op prestaasjes. It kin sjoen wurde dat de timing is ferhege, om't ûntsiferingsoperaasjes fan fersifere gegevens (en ûntsiferjen meastentiids noch yn jo logika ferpakt) wichtige boarnen fereaskje. Dat is, it idee om alle kolommen te fersiferjen dy't wat gegevens befetsje, is fol mei in fermindering fan prestaasjes.
Fersifering is lykwols gjin sulveren kûgel dy't alle problemen oplost. De ûntsifere gegevens en de dekodearringskaai tidens it proses fan it ûntsiferjen en ferstjoeren fan de gegevens lizze op de tsjinner. Dêrom kinne de kaaien ûnderskept wurde troch ien dy't folsleine tagong hat ta de databanktsjinner, lykas in systeembehearder.
As d'r ien kaai is foar de hiele kolom foar alle brûkers (sels as net foar allegear, mar foar kliïnten fan in beheinde set), is dit net altyd goed en korrekt. Dêrom begûnen se ein-oan-ein fersifering te dwaan, yn 'e DBMS begûnen se opsjes te beskôgjen foar it fersiferjen fan gegevens oan' e kant fan 'e client en server, en dy deselde kaai-ferwulf-opslach ferskynden - aparte produkten dy't kaaibehear leverje op' e DBMS side.
Feiligensfunksjes yn kommersjele en iepen boarne DBMS
Funksjes
Typ
Wachtwurdbelied
Audit
Beskermjen fan de boarnekoade fan prosedueres en funksjes
RLS
fersifering
Oracle
kommersjeel
+
+
+
+
+
MsSql
kommersjeel
+
+
+
+
+
kommersjeel
+
+
+
+
Tafoegings
PostgreSQL
Frij
Tafoegings
Tafoegings
-
+
Tafoegings
MongoDb
Frij
-
+
-
-
Allinich beskikber yn MongoDB Enterprise
De tabel is fier fan folslein, mar de situaasje is dit: yn kommersjele produkten binne feiligensproblemen foar in lange tiid oplost, yn iepen boarne wurde yn 'e regel in soarte fan tafoegings brûkt foar feiligens, in protte funksjes ûntbrekke , soms moatte jo wat tafoegje. Bygelyks, wachtwurdbelied - PostgreSQL hat in protte ferskillende útwreidingen (, , , , ), dy't wachtwurdbelied ymplementearje, mar, nei myn miening, net ien fan har dekt alle behoeften fan it ynlânske bedriuwssegment.
Wat te dwaan as jo net hawwe wat jo nedich hawwe oeral? Jo wolle bygelyks in spesifike DBMS brûke dy't net de funksjes hat dy't de klant fereasket.
Dan kinne jo gebrûk meitsje fan tredden oplossings dy't wurkje mei ferskate DBMSs, Bygelyks, Crypto DB of Garda DB. As wy it hawwe oer oplossingen út it ynlânske segmint, dan witte se better oer GOSTs as yn iepen boarne.
De twadde opsje is om te skriuwen wat jo sels nedich hawwe, tagong ta gegevens en fersifering yn 'e applikaasje op proseduerenivo te ymplementearjen. Wier, it sil dreger wêze mei GOST. Mar yn 't algemien kinne jo de gegevens ferbergje as nedich, it yn in DBMS pleatse, it dan ophelje en it as nedich ûntsiferje, direkt op it applikaasjenivo. Tink tagelyk oer hoe't jo dizze algoritmen sille beskermje yn 'e applikaasje. Neffens ús moat dat op DBMS-nivo, om't it flugger wurket.
Dit rapport waard foar it earst presintearre by troch Mail.ru Cloud Solutions. Sjenoare optredens en abonnearje op oankundigings fan eveneminten op Telegram .
Wat oars te lêzen oer it ûnderwerp:
- .
- .
Boarne: www.habr.com