My naam is Denis Rozhkov, ek is die hoof van sagteware-ontwikkeling by die Gazinformservice-maatskappy, in die produkspan Jatoba. Wetgewing en korporatiewe regulasies stel sekere vereistes vir die sekuriteit van databerging. Niemand wil hê dat derde partye toegang tot vertroulike inligting moet kry nie, dus is die volgende kwessies belangrik vir enige projek: identifikasie en verifikasie, bestuur van toegang tot data, versekering van die integriteit van inligting in die stelsel, aanteken van sekuriteitsgebeurtenisse. Daarom wil ek praat oor 'n paar interessante punte rakende DBMS-sekuriteit.

Die artikel is voorberei op grond van 'n toespraak by @DatabasesMeetup, georganiseer Mail.ru Wolkoplossings. As jy nie wil lees nie, kan jy kyk:

Die artikel sal drie dele hê:

• Hoe om verbindings te beveilig.
• Wat is 'n oudit van aksies en hoe om aan te teken wat aan die databasiskant gebeur en daarby aansluit.
• Hoe om data in die databasis self te beskerm en watter tegnologieë hiervoor beskikbaar is.

Drie komponente van DBMS-sekuriteit: verbindingsbeskerming, aktiwiteitsouditering en databeskerming

Beveilig jou verbindings

U kan direk of indirek aan die databasis koppel deur webtoepassings. As 'n reël tree die besigheidsgebruiker, dit wil sê die persoon wat met die DBBS werk, indirek daarmee in interaksie.

Voordat jy praat oor die beskerming van verbindings, moet jy belangrike vrae beantwoord wat bepaal hoe sekuriteitsmaatreëls gestruktureer sal word:

• Is een besigheidsgebruiker gelykstaande aan een DBMS-gebruiker?
• of toegang tot DBMS-data slegs verskaf word deur 'n API wat jy beheer, en of daar direk toegang tot tabelle verkry word;
• of die DBBS aan 'n aparte beskermde segment toegewys is, wie daarmee interaksie het en hoe;
• of pooling/proxy en intermediêre lae gebruik word, wat inligting kan verander oor hoe die verbinding gebou word en wie die databasis gebruik.

Kom ons kyk nou watter gereedskap gebruik kan word om verbindings te beveilig:

1. Gebruik databasis firewall klas oplossings. 'n Addisionele laag beskerming sal op 'n minimum die deursigtigheid van wat in die DBBS gebeur, verhoog, en hoogstens sal jy bykomende databeskerming kan verskaf.
2. Gebruik wagwoordbeleide. Die gebruik daarvan hang af van hoe jou argitektuur gebou is. In elk geval, een wagwoord in die konfigurasielêer van 'n webtoepassing wat aan die DBMS koppel, is nie genoeg vir beskerming nie. Daar is 'n aantal DBMS-nutsgoed wat jou toelaat om te beheer dat die gebruiker en wagwoord bygewerk moet word.

   Jy kan meer lees oor gebruikersgraderingfunksies hier, kan jy ook uitvind oor MS SQL Vulnerability Assessmen hier. 

3. Verryk die konteks van die sessie met die nodige inligting. As die sessie ondeursigtig is, verstaan ​​jy nie wie in die DBBS werk binne sy raamwerk nie, jy kan, binne die raamwerk van die operasie wat uitgevoer word, inligting byvoeg oor wie wat doen en hoekom. Hierdie inligting kan in die oudit gesien word.
4. Stel SSL op as jy nie 'n netwerkskeiding tussen die DBMS en eindgebruikers het nie; dit is nie in 'n aparte VLAN nie. In sulke gevalle is dit noodsaaklik om die kanaal tussen die verbruiker en die DBBS self te beskerm. Sekuriteitsinstrumente is ook in oopbron beskikbaar.

Hoe sal dit die werkverrigting van die DBBS beïnvloed?

Kom ons kyk na die voorbeeld van PostgreSQL om te sien hoe SSL die SVE-lading beïnvloed, tydsberekeninge verhoog en TPS verlaag, en of dit te veel hulpbronne sal verbruik as jy dit aktiveer.

Die laai van PostgreSQL met behulp van pgbench is 'n eenvoudige program om prestasietoetse uit te voer. Dit voer 'n enkele reeks opdragte herhaaldelik uit, moontlik in parallelle databasissessies, en bereken dan die gemiddelde transaksiekoers.

Toets 1 sonder SSL en gebruik SSL — die verbinding word vir elke transaksie tot stand gebring:

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"

Toets 2 sonder SSL en gebruik SSL - alle transaksies word in een verband uitgevoer:

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"

Ander instellings:

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

Toets resultate:

 
GEEN SSL nie
SSL

'n Verbinding word vir elke transaksie tot stand gebring

latency gemiddelde
171.915 Me
187.695 Me

tps insluitend verbindings tot stand te bring
58.168112
53.278062

tps uitgesluit verbindings tot stand te bring
64.084546
58.725846

CPU
24%
28%

Alle transaksies word in een verband uitgevoer

latency gemiddelde
6.722 Me
6.342 Me

tps insluitend verbindings tot stand te bring
1587.657278
1576.792883

tps uitgesluit verbindings tot stand te bring
1588.380574
1577.694766

CPU
17%
21%

By ligte vragte is die invloed van SSL vergelykbaar met die meetfout. As die hoeveelheid data wat oorgedra word baie groot is, kan die situasie anders wees. As ons een verbinding per transaksie vestig (dit is skaars, gewoonlik word die verbinding tussen gebruikers gedeel), het jy 'n groot aantal verbindings/ontkoppelings, die impak kan 'n bietjie groter wees. Dit wil sê, daar kan risiko's van verminderde werkverrigting wees, maar die verskil is nie so groot om nie beskerming te gebruik nie.

Neem asseblief kennis dat daar 'n sterk verskil is as jy die bedryfsmodusse vergelyk: jy werk binne dieselfde sessie of in verskillende sessies. Dit is verstaanbaar: hulpbronne word spandeer om elke verbinding te skep.

Ons het 'n geval gehad toe ons Zabbix in vertrouemodus gekoppel het, dit wil sê, md5 is nie nagegaan nie, daar was geen behoefte aan verifikasie nie. Toe het die kliënt gevra om md5-verifikasiemodus te aktiveer. Dit het 'n swaar las op die SVE geplaas, en werkverrigting het gedaal. Ons het begin soek na maniere om te optimaliseer. Een van die moontlike oplossings vir die probleem is om netwerkbeperkings te implementeer, aparte VLAN's vir die DBBS te maak, instellings by te voeg om dit duidelik te maak wie van waar af koppel en stawing te verwyder.Jy kan ook stawinginstellings optimaliseer om koste te verminder wanneer stawing geaktiveer word, maar oor die algemeen beïnvloed die gebruik van verskillende metodes verifikasie prestasie en vereis dat hierdie faktore in ag geneem word wanneer die rekenaarkrag van bedieners (hardeware) vir die DBBS ontwerp word.

Gevolgtrekking: in 'n aantal oplossings kan selfs klein nuanses in verifikasie die projek grootliks beïnvloed en dit is sleg as dit eers duidelik word wanneer dit in produksie geïmplementeer word.

Aksie oudit

Oudit kan nie net DBBS wees nie. ’n Oudit gaan oor die verkryging van inligting oor wat in verskillende segmente gebeur. Dit kan óf 'n databasis-firewall wees óf die bedryfstelsel waarop die DBBS gebou is.

In kommersiële ondernemingsvlak DBBS'e is alles goed met ouditering, maar in oopbron - nie altyd nie. Hier is wat PostgreSQL het:

• verstek log - ingeboude aanteken;
• uitbreidings: pgaudit - as verstek aanteken nie vir jou genoeg is nie, kan jy aparte instellings gebruik wat sommige probleme oplos.

Byvoeging tot die berig in die video:

"Basiese stellingaantekening kan verskaf word deur 'n standaard aantekenfasiliteit met log_statement = all.

Dit is aanvaarbaar vir monitering en ander gebruike, maar verskaf nie die vlak van detail wat tipies vir ouditering vereis word nie.

Dit is nie genoeg om 'n lys te hê van al die bewerkings wat op die databasis uitgevoer word nie.

Dit moet ook moontlik wees om spesifieke verklarings te vind wat vir die ouditeur van belang is.

Standaard logboek wys wat die gebruiker versoek het, terwyl pgAudit fokus op die besonderhede van wat gebeur het toe die databasis die navraag uitgevoer het.

Byvoorbeeld, die ouditeur wil dalk verifieer dat 'n spesifieke tabel binne 'n gedokumenteerde instandhoudingsvenster geskep is.

Dit lyk dalk na 'n eenvoudige taak met basiese ouditering en grep, maar wat as jy met iets soos hierdie (opsetlik verwarrende) voorbeeld voorgehou word:

DOEN$$
Begin
VOER 'SKEP TABEL invoer' uit || 'ant_table(id int)';
EINDE$$;

Standaard aanteken sal jou dit gee:

LOG: stelling: DOEN $$
Begin
VOER 'SKEP TABEL invoer' uit || 'ant_table(id int)';
EINDE$$;

Dit blyk dat die vind van die tabel van belang dalk 'n mate van kodekennis vereis in gevalle waar tabelle dinamies geskep word.

Dit is nie ideaal nie, aangesien dit verkieslik sal wees om bloot volgens tabelnaam te soek.

Dit is waar pgAudit handig te pas kom.

Vir dieselfde invoer sal dit hierdie uitset in die log produseer:

OUDIT: SESSIE,33,1,FUNKSIE,DOEN,,,"DOEN $$
Begin
VOER 'SKEP TABEL invoer' uit || 'ant_table(id int)';
EINDE$$;"
OUDIT: SESSIE,33,2,DDL,SKEP TABEL,TABEL,publiek.belangrike_tabel,SKEP TABEL belangrike_tabel (id INT)

Nie net die DOEN-blok word aangeteken nie, maar ook die volledige teks van die SKEP TABEL met stellingtipe, objektipe en volle naam, wat soek makliker maak.

Wanneer SELECT- en DML-stellings aangeteken word, kan pgAudit gekonfigureer word om 'n aparte inskrywing aan te teken vir elke verhouding waarna in die stelling verwys word.

Geen ontleding is nodig om alle stellings te vind wat 'n spesifieke tabel raak nie (*) ».

Hoe sal dit die werkverrigting van die DBBS beïnvloed?

Kom ons voer toetse uit met volledige ouditering geaktiveer en kyk wat gebeur met PostgreSQL-prestasie. Kom ons aktiveer maksimum databasisregistrasie vir alle parameters.

Ons verander amper niks in die konfigurasielêer nie, die belangrikste ding is om die debug5-modus aan te skakel om maksimum inligting te kry.

postgresql.conf

log_destination = 'stderr'
logging_collector = aan
log_truncate_on_rotation = aan
log_rotation_age = 1d
log_rotation_size = 10MB
log_min_boodskappe = ontfout5
log_min_error_statement = ontfout5
log_min_duration_statement = 0
debug_print_parse = aan
debug_print_rewritten = aan
debug_print_plan = aan
debug_pretty_print = aan
log_checkpoints = aan
log_connections = aan
log_disconnections = aan
log_duration = aan
log_gasheernaam = aan
log_lock_wait = aan
log_replication_commands = aan
log_temp_files = 0
log_timezone = 'Europa/Moskou'

Op 'n PostgreSQL DBMS met parameters van 1 SVE, 2,8 GHz, 2 GB RAM, 40 GB HDD, voer ons drie lastoetse uit met die opdragte:

$ 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

Toets resultate:

Geen aanteken nie
Met logging

Totale databasisvultyd
43,74 sek
53,23 sek

RAM
24%
40%

CPU
72%
91%

Toets 1 (50 verbindings)

Aantal transaksies in 10 minute
74169
32445

Transaksies/sek
123
54

Gemiddelde Latency
405 ms
925 ms

Toets 2 (150 verbindings met 100 moontlike)

Aantal transaksies in 10 minute
81727
31429

Transaksies/sek
136
52

Gemiddelde Latency
550 ms
1432 ms

Oor groottes

DB grootte
2251 MB
2262 MB

Databasis log grootte
0 MB
4587 MB

Bottom line: 'n volledige oudit is nie baie goed nie. Die data van die oudit sal so groot soos die data in die databasis self wees, of selfs meer. Die hoeveelheid aantekening wat gegenereer word wanneer daar met 'n DBBS gewerk word, is 'n algemene probleem in produksie.

Kom ons kyk na ander parameters:

• Die spoed verander nie veel nie: sonder logging - 43,74 sekondes, met logging - 53,23 sekondes.
• RAM- en SVE-werkverrigting sal daaronder ly, aangesien jy 'n ouditlêer moet genereer. Dit is ook merkbaar in produktiwiteit.

Namate die aantal verbindings toeneem, sal die werkverrigting natuurlik effens versleg.

In korporasies met oudit is dit selfs moeiliker:

• daar is baie data;
• ouditering is nie net nodig deur syslog in SIEM nie, maar ook in lêers: as iets met syslog gebeur, moet daar 'n lêer naby die databasis wees waarin die data gestoor word;
• 'n aparte rak is nodig vir ouditering om nie I/O-skywe te mors nie, aangesien dit baie spasie opneem;
• Dit gebeur dat werknemers van inligtingsekuriteit oral GOST-standaarde benodig, hulle benodig staatsidentifikasie.

Beperk toegang tot data

Kom ons kyk na die tegnologieë wat gebruik word om data te beskerm en toegang daartoe te verkry in kommersiële DBBS'e en oopbron.

Wat kan jy oor die algemeen gebruik:

1. Enkripsie en verduistering van prosedures en funksies (Wrapping) - dit wil sê aparte gereedskap en nutsprogramme wat leesbare kode onleesbaar maak. Dit is waar, dan kan dit nie verander of teruggefaktor word nie. Hierdie benadering word soms vereis ten minste aan die DBMS-kant - die logika van lisensiebeperkings of magtigingslogika word presies op die prosedure- en funksievlak geïnkripteer.
2. Om die sigbaarheid van data volgens rye (RLS) te beperk, is wanneer verskillende gebruikers een tabel sien, maar 'n ander samestelling van rye daarin, dit wil sê, iets kan nie aan iemand op die ryvlak gewys word nie.
3. Die wysiging van die vertoonde data (maskering) is wanneer gebruikers in een kolom van die tabel óf data óf slegs sterretjies sien, dit wil sê, vir sommige gebruikers sal die inligting gesluit word. Die tegnologie bepaal watter gebruiker wat gewys word op grond van hul toegangsvlak.
4. Sekuriteit DBA/Toepassing DBA/DBA toegangsbeheer gaan eerder daaroor om toegang tot die DBBS self te beperk, dit wil sê, inligtingsekuriteitswerknemers kan geskei word van databasisadministrateurs en toepassingadministrateurs. Daar is min sulke tegnologieë in oopbron, maar daar is baie daarvan in kommersiële DBBS'e. Hulle is nodig wanneer daar baie gebruikers is met toegang tot die bedieners self.
5. Beperk toegang tot lêers op lêerstelselvlak. U kan regte en toegangsregte aan gidse toeken sodat elke administrateur slegs toegang tot die nodige data het.
6. Verpligte toegang en geheue skoonmaak - hierdie tegnologieë word selde gebruik.
7. End-tot-end enkripsie direk vanaf die DBBS is kliënt-kant enkripsie met sleutelbestuur aan die bedienerkant.
8. Data-enkripsie. Kolomenkripsie is byvoorbeeld wanneer jy 'n meganisme gebruik wat 'n enkele kolom van die databasis enkripteer.

Hoe beïnvloed dit die werkverrigting van die DBBS?

Kom ons kyk na die voorbeeld van kolomenkripsie in PostgreSQL. Daar is 'n pgcrypto-module, dit laat jou toe om geselekteerde velde in geënkripteerde vorm te stoor. Dit is nuttig wanneer slegs sommige data waardevol is. Om die geënkripteerde velde te lees, stuur die kliënt 'n dekripsiesleutel, die bediener dekripteer die data en stuur dit terug na die kliënt. Sonder die sleutel kan niemand iets met jou data doen nie.

Kom ons toets met pgcrypto. Kom ons skep 'n tabel met geënkripteerde data en gereelde data. Hieronder is die opdragte vir die skep van tabelle, in die heel eerste reël is daar 'n nuttige opdrag - skep die uitbreiding self met DBMS-registrasie:

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

Kom ons probeer dan om 'n datamonster uit elke tabel te maak en kyk na die uitvoeringstye.

Kies uit 'n tabel sonder enkripsiefunksie:

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

Die stophorlosie is aan.

  id | teks1 | teks 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 reëls)

Tyd: 1,386 ms

Seleksie uit 'n tabel met enkripsiefunksie:

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

Die stophorlosie is aan.

  id | dekripteer | dekripteer
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 reëls)

Tyd: 50,203 ms

Toets resultate:

 
Sonder enkripsie
Pgcrypto (dekripteer)

Monster 1000 rye
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

Enkripsie het 'n groot impak op prestasie. Dit kan gesien word dat die tydsberekening toegeneem het, aangesien dekripsiebewerkings van geënkripteerde data (en dekripsie is gewoonlik steeds in jou logika toegedraai) aansienlike hulpbronne vereis. Dit wil sê, die idee om alle kolomme wat sommige data bevat te enkripteer, is belaai met 'n afname in werkverrigting.

Enkripsie is egter nie 'n silwer koeël wat alle probleme oplos nie. Die gedekripteerde data en die dekripsiesleutel tydens die proses van dekripteer en oordrag van die data is op die bediener geleë. Daarom kan die sleutels onderskep word deur iemand wat volle toegang tot die databasisbediener het, soos 'n stelseladministrateur.

Wanneer daar een sleutel vir die hele kolom vir alle gebruikers is (al is dit nie vir almal nie, maar vir kliënte van 'n beperkte stel), is dit nie altyd goed en korrek nie. Daarom het hulle begin om end-tot-end enkripsie te doen, in die DBBS het hulle opsies begin oorweeg om data aan die kliënt- en bedienerkant te enkripteer, en daardie selfde sleutelkluisbergings het verskyn - aparte produkte wat sleutelbestuur op die DBBS verskaf kant.

'N Voorbeeld van sulke enkripsie in MongoDB

Sekuriteitskenmerke in kommersiële en oopbron-DBMS

Funksies
Tipe
Wagwoordbeleid
Oudit
Beskerming van die bronkode van prosedures en funksies
RLS
Enkripsie

Oracle
kommersieel
+
+
+
+
+

MsSql
kommersieel
+
+
+
+
+

Jatoba
kommersieel
+
+
+
+
uitbreidings

PostgreSQL
Verniet
uitbreidings
uitbreidings
-
+
uitbreidings

MongoDb
Verniet
-
+
-
-
Slegs beskikbaar in MongoDB Enterprise

Die tabel is nog lank nie volledig nie, maar die situasie is so: in kommersiële produkte is sekuriteitsprobleme lankal opgelos, in open source word as 'n reël 'n soort byvoegings vir sekuriteit gebruik, baie funksies ontbreek , soms moet jy iets byvoeg. Byvoorbeeld, wagwoordbeleide - PostgreSQL het baie verskillende uitbreidings (1, 2, 3, 4, 5), wat wagwoordbeleide implementeer, maar na my mening dek nie een van hulle al die behoeftes van die plaaslike korporatiewe segment nie.

Wat om te doen as jy nêrens het wat jy nodig het nie? Byvoorbeeld, jy wil 'n spesifieke DBBS gebruik wat nie die funksies het wat die kliënt vereis nie.

Dan kan jy derdeparty-oplossings gebruik wat met verskillende DBBS'e werk, byvoorbeeld Crypto DB of Garda DB. As ons praat oor oplossings uit die huishoudelike segment, dan weet hulle van GOST's beter as in oopbron.

Die tweede opsie is om self te skryf wat jy nodig het, datatoegang en enkripsie in die toepassing op prosedurevlak te implementeer. Dit sal weliswaar moeiliker wees met GOST. Maar oor die algemeen kan jy die data versteek soos nodig, dit in 'n DBMS plaas, dit dan ophaal en dekripteer soos nodig, reg op die toepassingsvlak. Dink terselfdertyd dadelik na oor hoe u hierdie algoritmes in die toepassing sal beskerm. Na ons mening moet dit op die DBMS-vlak gedoen word, want dit sal vinniger werk.

Hierdie verslag is die eerste keer aangebied by @Database Meetup deur Mail.ru Cloud Solutions. Sien video ander optredes en teken in op aankondigings van gebeure in Telegram Rondom Kubernetes in Mail.ru Group.

Wat anders om te lees oor die onderwerp:

1. Meer as Ceph: MCS wolkblokberging.
2. Hoe om 'n databasis vir 'n projek te kies sodat jy nie weer hoef te kies nie.

Bron: will.com