Nire izena Denis Rozhkov da, Gazinformservice konpainiako software garapenaren burua naiz, produktu taldean. Jatoba. Legeriak eta korporazio-araudiak baldintza batzuk ezartzen ditu datuak biltegiratzeko segurtasunerako. Inork ez du nahi hirugarrenek informazio konfidentziala eskuratzea, beraz, honako gai hauek garrantzitsuak dira edozein proiekturako: identifikazioa eta autentifikazioa, datuetarako sarbidea kudeatzea, sistemako informazioaren osotasuna bermatzea, segurtasun-gertaerak erregistratzea. Horregatik, DBMS segurtasunari buruzko puntu interesgarri batzuei buruz hitz egin nahi dut.

Artikulua hitzaldi batean oinarrituta prestatu zen @DatabasesMeetup, antolatuta Mail.ru Cloud Solutions. Irakurri nahi ez baduzu, ikus dezakezu:

Artikuluak hiru zati izango ditu:

• Nola babestu konexioak.
• Zer da ekintzen auditoria eta nola erregistratu datu-basean gertatzen dena eta harekin konektatzen dena.
• Nola babestu datuak datu-basean bertan eta zer teknologia dauden horretarako.

DBMS segurtasunaren hiru osagai: konexioaren babesa, jardueren auditoria eta datuen babesa

Zure konexioak ziurtatzea

Datu-basera zuzenean edo zeharka konekta zaitezke web aplikazioen bidez. Oro har, enpresa-erabiltzaileak, hau da, DBMSarekin lan egiten duen pertsonak, zeharka elkarreragiten du harekin.

Konexioak babesteari buruz hitz egin aurretik, segurtasun neurriak nola egituratuko diren zehazten duten galdera garrantzitsuei erantzun behar diezu:

• Enpresa erabiltzaile bat DBMS erabiltzaile baten baliokidea al da?
• DBMS datuetarako sarbidea zuk kontrolatzen duzun API baten bidez soilik ematen den edo tauletara zuzenean sartzen den;
• DBMS babestutako segmentu bereizi batera esleitzen den ala ez, nork eta nola elkarreragiten duen;
• bilketa/proxy eta tarteko geruzak erabiltzen diren ala ez, konexioa nola eraikitzen den eta datu-basea erabiltzen duenari buruzko informazioa alda dezake.

Orain ikus dezagun zer tresna erabil daitezkeen konexioak ziurtatzeko:

1. Erabili datu-baseen suebakien klase-soluzioak. Babes-geruza gehigarri batek, gutxienez, DBMSn gertatzen ari denaren gardentasuna areagotuko du, eta gehienez, datu-babes gehigarria eman ahal izango duzu.
2. Erabili pasahitzen politikak. Haien erabilera zure arkitektura nola eraikitzen denaren araberakoa da. Nolanahi ere, DBMSra konektatzen den web aplikazio baten konfigurazio fitxategiko pasahitz bat ez da nahikoa babesteko. Erabiltzaileak eta pasahitzak eguneratu behar direla kontrolatzeko aukera ematen duten DBMS tresna ugari daude.

   Erabiltzaileen balorazio funtzioei buruzko informazio gehiago irakur dezakezu Hemen, MS SQL Vulnerability Assessmen buruz ere jakin dezakezu Hemen. 

3. Aberastu saioaren testuingurua beharrezko informazioarekin. Saioa opakoa bada, ez duzu ulertzen nor ari den DBMSan lan egiten bere esparruan, egiten ari den eragiketaren esparruan, nork zer eta zergatik egiten duen informazioa gehi dezakezu. Informazio hori ikuskaritzan ikus daiteke.
4. Konfiguratu SSL ez baduzu DBMS eta azken erabiltzaileen arteko sare-bereizketarik; ez dago aparteko VLAN batean. Kasu horietan, ezinbestekoa da kontsumitzailearen eta DBMS beraren arteko kanala babestea. Segurtasun tresnak kode irekian ere eskuragarri daude.

Nola eragingo du horrek DBMSren errendimenduan?

Ikus dezagun PostgreSQL-ren adibidea ikusteko SSL-k PUZaren kargari nola eragiten dion, denborak areagotzen dituen eta TPS-a gutxitzen duen eta gaitzen baduzu baliabide gehiegi kontsumituko dituen ikusteko.

PostgreSQL pgbench erabiliz kargatzea errendimendu-probak egiteko programa sinple bat da. Komando-sekuentzia bakar bat exekutatzen du behin eta berriz, beharbada datu-baseko saio paraleloetan, eta ondoren batez besteko transakzio-tasa kalkulatzen du.

Proba 1 SSL gabe eta SSL erabiliz — transakzio bakoitzerako konexioa ezartzen da:

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"

Proba 2 SSL gabe eta SSL erabiliz — Transakzio guztiak konexio batean egiten dira:

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"

Beste ezarpen batzuk:

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

Proben emaitzak:

 
SSL EZ
SSL

Transakzio bakoitzeko konexio bat ezartzen da

latentziaren batez bestekoa
171.915 ms
187.695 ms

tps konexioak ezartzea barne
58.168112
53.278062

tps konexioak ezartzea kenduta
64.084546
58.725846

CPU
24%
28%

Transakzio guztiak konexio batean egiten dira

latentziaren batez bestekoa
6.722 ms
6.342 ms

tps konexioak ezartzea barne
1587.657278
1576.792883

tps konexioak ezartzea kenduta
1588.380574
1577.694766

CPU
17%
21%

Karga arinetan, SSL-ren eragina neurketa-errorearen parekoa da. Transferitutako datu kopurua oso handia bada, egoera ezberdina izan daiteke. Transakzio bakoitzeko konexio bat ezartzen badugu (hau arraroa da, normalean konexioa erabiltzaileen artean partekatzen da), konexio/deskonexio ugari dituzu, eragina apur bat handiagoa izan daiteke. Hau da, errendimendua gutxitzeko arriskuak egon daitezke, baina aldea ez da hain handia babesa ez erabiltzeko.

Kontuan izan funtzionamendu-moduak alderatzen badituzu alde handia dagoela: saio berean edo saio ezberdinetan ari zara lanean. Hau ulergarria da: baliabideak gastatzen dira konexio bakoitza sortzeko.

Zabbix konfiantza moduan konektatu genuenean kasu bat izan genuen, hau da, md5 ez zen egiaztatu, ez zegoen autentifikazio beharrik. Ondoren, bezeroak md5 autentifikazio modua gaitzeko eskatu zuen. Honek karga handia jarri zion CPUari, eta errendimendua jaitsi egin zen. Optimitzeko bideak bilatzen hasi ginen. Arazoaren irtenbide posibleetako bat sare-murrizketak ezartzea da, DBMSrako VLAN bereiziak egitea, ezarpenak gehitzea nondik konektatzen den argitzeko eta autentifikazioa kentzea. Autentifikazio-ezarpenak ere optimiza ditzakezu kostuak murrizteko autentifikazioa gaitzean, baina oro har, autentifikazio-metodo ezberdinen erabilerak errendimenduan eragiten du eta faktore horiek kontuan hartzea eskatzen du DBMSrako zerbitzarien (hardwarea) konputazio-ahalmena diseinatzerakoan.

Ondorioa: hainbat konponbidetan, autentifikazioan ñabardura txikiek ere asko eragin dezakete proiektuan eta txarra da hori produkzioan inplementatzen denean soilik argi geratzen denean.

Ekintza auditoretza

Ikuskaritza DBMS ez ezik izan daiteke. Auditoria bat segmentu ezberdinetan gertatzen denari buruzko informazioa lortzea da. Hau datu-baseen suebakia edo DBMSa eraikita dagoen sistema eragilea izan daiteke.

Enpresa mailako DBMS komertzialetan dena ondo dago ikuskaritzarekin, baina kode irekian, ez beti. Hona hemen PostgreSQL-k zer daukana:

• erregistro lehenetsia - erregistro integratua;
• luzapenak: pgaudit - lehenetsitako erregistroa zuretzako nahikoa ez bada, arazo batzuk konpontzen dituzten ezarpen bereiziak erabil ditzakezu.

Erreportajearen gehigarria bideoan:

"Oinarrizko adierazpenen erregistroa log_statement = all-rekin erregistratzeko instalazio estandar batek eman dezake.

Hau onargarria da monitorizaziorako eta beste erabilera batzuetarako, baina ez du ikuskaritzarako normalean behar den xehetasun maila ematen.

Ez da nahikoa datu-basean egindako eragiketa guztien zerrenda izatea.

Ikuskariarentzat interesgarriak diren adierazpen zehatzak ere aurkitzea posible izan beharko litzateke.

Erregistro estandarrak erabiltzaileak eskatutakoa erakusten du, eta pgAudit-ek datu-baseak kontsulta exekutatu zuenean gertatutakoaren xehetasunetan zentratzen du.

Esate baterako, ikuskariak egiaztatu nahi du taula jakin bat sortu dela dokumentatutako mantentze-leiho batean.

Oinarrizko auditoria eta grep-ekin zeregin sinplea dirudi, baina zer gertatzen da adibide hau (nahita nahasia) antzeko zerbait aurkeztuko bazenu:

DO$$
BEGIN
EXECUTE 'SORTU TAULA inportatzea' || 'ant_table (ID int)';
BUKAERA$$;

Erregistro estandarrak hau emango dizu:

LOG: adierazpena: DO $$
BEGIN
EXECUTE 'SORTU TAULA inportatzea' || 'ant_table (ID int)';
BUKAERA$$;

Badirudi interesgarria den taula aurkitzeko kode-ezagutza batzuk eska ditzakeela taulak dinamikoki sortzen diren kasuetan.

Hau ez da aproposa, hobe litzateke taularen izenaren arabera bilatzea besterik gabe.

Hau da pgAudit erabilgarria.

Sarrera berdinerako, irteera hau sortuko du erregistroan:

IKUSKARITZA: SAIOA,33,1,FUNTZIOA,EGIN,,,"EGIN $$
BEGIN
EXECUTE 'SORTU TAULA inportatzea' || 'ant_table (ID int)';
BUKAERA$$;"
IKUSKARITZA: SESSION,33,2,DDL,SORTU TAULA,TAULA,public.important_table,SORTU TAULA garrantzitsua_taula (ID INT)

DO blokea ez ezik, SORTU TAULAren testu osoa ere erregistratzen da adierazpen mota, objektu mota eta izen osoarekin, bilaketa erraztuz.

SELECT eta DML adierazpenak erregistratzean, pgAudit konfiguratu daiteke adierazpenean erreferentziatutako erlazio bakoitzeko sarrera bereizi bat erregistratzeko.

Ez da analisirik behar taula jakin bat ukitzen duten adierazpen guztiak aurkitzeko (*) ».

Nola eragingo du horrek DBMSren errendimenduan?

Egin ditzagun probak auditoretza osoa gaituta eta ikus ditzagun zer gertatzen den PostgreSQL-ren errendimenduarekin. Gaitu dezagun datu-basearen gehienezko erregistroa parametro guztientzat.

Ez dugu ia ezer aldatzen konfigurazio fitxategian, garrantzitsuena debug5 modua aktibatzea da informazio maximoa lortzeko.

postgresql.conf

log_destination = 'stderr'
logging_collector = aktibatuta
log_truncate_on_rotation = aktibatuta
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_messages = arazketa 5
log_min_error_statement = arazketa 5
log_min_duration_statement = 0
debug_print_parse = aktibatuta
debug_print_rewritten = aktibatuta
debug_print_plan = aktibatuta
debug_pretty_print = aktibatuta
log_checkpoints = aktibatuta
log_connections = aktibatuta
log_disconnections = aktibatuta
log_iraupena = aktibatuta
log_hostname = aktibatuta
log_lock_wait = aktibatuta
log_replication_commands = aktibatuta
log_temp_files = 0
log_timezone = 'Europa/Mosku'

PUZ 1, 2,8 GHz, 2 GB RAM, 40 GB HDD parametroak dituen PostgreSQL DBMS batean, hiru karga proba egiten ditugu komandoak erabiliz:

$ 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

Proben emaitzak:

Ez dago erregistrorik
Erregistroarekin

Datu-basea betetzeko denbora osoa
43,74 seg
53,23 seg

RAM
24%
40%

CPU
72%
91%

1. proba (50 konexio)

Transakzio kopurua 10 minututan
74169
32445

Eragiketak/seg
123
54

Batez besteko Latentzia
405 ms
925 ms

2. proba (150 konexio 100 posible)

Transakzio kopurua 10 minututan
81727
31429

Eragiketak/seg
136
52

Batez besteko Latentzia
550 ms
1432 ms

Tamainei buruz

DB tamaina
2251 MB
2262 MB

Datu-basearen erregistroaren tamaina
0 MB
4587 MB

Beheko lerroa: auditoria osoa ez da oso ona. Ikuskaritzako datuak datu-basean bertan dauden datuak bezain handiak izango dira, edo are gehiago. DBMS batekin lan egitean sortzen den erregistro kopurua ekoizpenean ohikoa den arazoa da.

Ikus ditzagun beste parametro batzuk:

• Abiadura ez da asko aldatzen: erregistratu gabe - 43,74 segundo, erregistroarekin - 53,23 segundo.
• RAM eta PUZaren errendimenduak kaltetuko ditu, auditoria fitxategi bat sortu behar duzulako. Hau produktibitatean ere nabaria da.

Konexio kopurua handitzen den heinean, jakina, errendimendua apur bat hondatuko da.

Auditoria duten korporazioetan are zailagoa da:

• datu asko dago;
• auditoria behar da SIEM-en syslog-en bidez ez ezik, fitxategietan ere: syslog-i zerbait gertatzen bazaio, datuak gordetzen diren datu-basetik hurbil dagoen fitxategi bat egon behar da;
• Ikuskaritza egiteko aparteko apal bat behar da, I/O diskoak ez xahutzeko, leku asko hartzen baitu;
• Gertatzen da informazioaren segurtasuneko langileek GOST estandarrak behar dituztela nonahi, estatuaren identifikazioa eskatzen dutela.

Datuetarako sarbidea mugatzea

Ikus ditzagun datuak babesteko eta haietara sartzeko DBMS komertzialetan eta kode irekietan erabiltzen diren teknologiak.

Zer erabil dezakezu orokorrean:

1. Prozedurak eta funtzioak enkriptatzea eta nahastea (Wrapping) - hau da, kode irakurgarria irakurgaitz bihurtzen duten tresna eta utilitate bereiziak. Egia da, orduan ezin da ez aldatu edo birfaktorizatu. Ikuspegi hau batzuetan beharrezkoa da DBMS aldetik behintzat - lizentzia-murrizketen logika edo baimen-logika prozedura eta funtzio mailan zifratzen da.
2. Datuen ikusgarritasuna errenkadaren arabera (RLS) mugatzea da erabiltzaile ezberdinek taula bat ikusten dutenean, baina bertan errenken konposizio ezberdina, hau da, ezin zaio zerbait erakutsi errenkada mailan norbaiti.
3. Bistaratzen diren datuak editatzea (Mascara) da taulako zutabe bateko erabiltzaileek datuak edo izartxoak soilik ikusten dituztenean, hau da, erabiltzaile batzuentzat informazioa itxi egingo da. Teknologiak zehazten du zein erabiltzaileri zer erakutsiko zaion bere sarbide-mailaren arabera.
4. Segurtasuna DBA/Aplikazioa DBA/DBA sarbide-kontrola, aitzitik, DBMSrako sarbidea mugatzea da, hau da, informazioaren segurtasuneko langileak datu-baseen administratzaileetatik eta aplikazioen administratzaileetatik bereiz daitezke. Kode irekian horrelako teknologia gutxi daude, baina DBMS komertzialetan asko daude. Beharrezkoak dira zerbitzarietarako sarbidea duten erabiltzaile asko daudenean.
5. Fitxategietarako sarbidea mugatzea fitxategi-sistemaren mailan. Direktorioei eskubideak eta sarbide-pribilegioak eman diezazkiekezu, administratzaile bakoitzak beharrezko datuetarako soilik atzitzeko.
6. Derrigorrezko sarbidea eta memoria garbitzea - ​​teknologia hauek oso gutxitan erabiltzen dira.
7. Muturreko enkriptatzea DBMStik zuzenean bezeroaren aldeko enkriptatzea da zerbitzariaren gakoen kudeaketarekin.
8. Datuen enkriptatzea. Adibidez, zutabe-enkriptatzea datu-baseko zutabe bakarra enkriptatzen duen mekanismoa erabiltzen duzunean gertatzen da.

Nola eragiten du horrek DBMSren errendimenduan?

Ikus dezagun PostgreSQL-en zutabe-zifraketaren adibidea. pgcrypto modulu bat dago, aukeratutako eremuak zifratuta gordetzeko aukera ematen du. Baliagarria da datu batzuk bakarrik balio dutenean. Zifratutako eremuak irakurtzeko, bezeroak deszifratze-gako bat transmititzen du, zerbitzariak datuak deszifratzen ditu eta bezeroari itzultzen dizkio. Gakorik gabe, inork ezin du ezer egin zure datuekin.

Proba dezagun pgcrypto-rekin. Sortu dezagun taula bat enkriptatutako datuekin eta datu arruntekin. Jarraian taulak sortzeko komandoak daude, lehen lerroan komando erabilgarria dago - luzapena bera sortzea DBMS erregistroarekin:

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

Ondoren, saia gaitezen taula bakoitzeko datu-lagin bat egiten eta exekuzio-denborak aztertzen.

Enkriptazio-funtziorik gabeko taula batetik hautatzea:

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

Kronometroa piztuta dago.

  id | testua1 | testua 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 lerro)

Denbora: 1,386 ms

Enkriptazio funtzioa duen taula batetik hautatzea:

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

Kronometroa piztuta dago.

  id | deszifratu | deszifratu
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 lerro)

Denbora: 50,203 ms

Proben emaitzak:

 
Zifratzerik gabe
Pgcrypto (deszifratu)

Lagina 1000 errenkada
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

Enkriptatzea eragin handia du errendimenduan. Denbora-denbora handitu egin dela ikus daiteke, enkriptatutako datuen desenkriptatze-eragiketak (eta deszifratzea normalean oraindik zure logikan bilduta) baliabide garrantzitsuak behar baititu. Hau da, datu batzuk dituzten zutabe guztiak enkriptatzeko ideia errendimenduaren murrizketaz beteta dago.

Hala ere, enkriptatzea ez da arazo guztiak konpontzen dituen zilarrezko bala bat. Deszifratutako datuak eta deszifratze-gakoa datuak deszifratzeko eta transmititzeko prozesuan zerbitzarian kokatzen dira. Hori dela eta, datu-basearen zerbitzarirako sarbide osoa duen norbaitek atzeman ditzake gakoak, hala nola sistema-administratzaileak.

Erabiltzaile guztientzat zutabe osorako gako bat dagoenean (nahiz eta guztientzat ez, baina multzo mugatuko bezeroentzat), hori ez da beti ona eta zuzena. Horregatik, end-to-end enkriptatzea egiten hasi ziren, DBMSan bezeroaren eta zerbitzariaren aldean datuak enkriptatzeko aukerak aztertzen hasi ziren, eta gako-ganga biltegiratze horiek agertu ziren - DBMSan gakoen kudeaketa eskaintzen duten produktu bereiziak. alde.

MongoDB-n zifratze horren adibide bat

Segurtasun-eginbideak DBMS komertzialetan eta kode irekian

funtzio
Mota
Pasahitzen politika
Ikuskaritza
Prozeduren eta funtzioen iturburu-kodea babestea
RLS
Encryption

Oracle
komertziala
+
+
+
+
+

MsSql
komertziala
+
+
+
+
+

Jatoba
komertziala
+
+
+
+
luzapenak

PostgreSQL
Free
luzapenak
luzapenak
-
+
luzapenak

MongoDb
Free
-
+
-
-
MongoDB Enterprise-n soilik eskuragarri

Taula oso urrun dago, baina egoera hau da: produktu komertzialetan segurtasun arazoak aspaldi konpondu dira, kode irekian, normalean, segurtasunerako gehigarri batzuk erabiltzen dira, funtzio asko falta dira. , batzuetan zerbait gehitu behar duzu. Adibidez, pasahitzen politikak - PostgreSQL-k hainbat luzapen ditu (1, 2, 3, 4, 5), pasahitzen politikak ezartzen dituztenak, baina, nire ustez, horietako batek ere ez ditu barneko enpresen segmentuaren behar guztiak estaltzen.

Zer egin behar duzuna inon ez baduzu? Adibidez, bezeroak eskatzen dituen funtzioak ez dituen DBMS zehatz bat erabili nahi duzu.

Ondoren, DBMS ezberdinekin lan egiten duten hirugarrenen soluzioak erabil ditzakezu, adibidez, Crypto DB edo Garda DB. Etxeko segmentuko soluzioei buruz ari bagara, orduan GOSTak kode irekian baino hobeto ezagutzen dituzte.

Bigarren aukera zuk zeuk behar duzuna idaztea da, datuen sarbidea eta enkriptatzea aplikazioan prozedura mailan ezartzea. Egia da, zailagoa izango da GOSTrekin. Baina, oro har, datuak behar bezala ezkutatu ditzakezu, DBMS batean sartu, gero berreskuratu eta behar den moduan deszifratu, aplikazio mailan bertan. Aldi berean, berehala pentsatu nola babestuko dituzun algoritmo hauek aplikazioan. Gure ustez, hori DBMS mailan egin beharko litzateke, azkarrago funtzionatuko duelako.

Txosten hau lehen aldiz aurkeztu zen @Databases Meetup Mail.ru Cloud Solutions-en eskutik. Begira video beste emanaldi batzuk eta harpidetu Telegram-en ekitaldien iragarpenetara Kubernetes inguruan Mail.ru Taldean.

Zer gehiago irakurri gaiari buruz:

1. Ceph baino gehiago: MCS hodeiko blokeen biltegiratzea.
2. Nola aukeratu proiektu baterako datu-base bat berriro aukeratu beharrik ez izateko.

Iturria: www.habr.com