Nimeni on Denis Rozhkov, olen ohjelmistokehityspäällikkö Gazinformservice-yhtiössä tuotetiimissä . Lainsäädäntö ja yritysten määräykset asettavat tiettyjä vaatimuksia tietojen tallennuksen turvallisuudelle. Kukaan ei halua kolmansien osapuolten pääsevän käsiksi luottamuksellisiin tietoihin, joten seuraavat asiat ovat tärkeitä missä tahansa projektissa: tunnistaminen ja todennus, tietoihin pääsyn hallinta, järjestelmän tietojen eheyden varmistaminen, tietoturvatapahtumien kirjaaminen. Siksi haluan puhua joistakin mielenkiintoisista DBMS-turvallisuutta koskevista seikoista.
Artikkeli on laadittu klo järjestetty . Jos et halua lukea, voit katsoa:
Artikkelissa on kolme osaa:
- Kuinka suojata yhteydet.
- Mitä on toimintojen auditointi ja miten tallennetaan tietokantapuolella tapahtuva ja siihen liittyminen.
- Kuinka suojata itse tietokannassa olevia tietoja ja mitä tekniikoita tähän on saatavilla.
DBMS-tietoturvan kolme komponenttia: yhteyden suojaus, toiminnan tarkastus ja tietosuoja
Yhteyksien turvaaminen
Voit muodostaa yhteyden tietokantaan joko suoraan tai epäsuorasti verkkosovellusten kautta. Yleensä yrityskäyttäjä, eli henkilö, joka työskentelee DBMS:n kanssa, on vuorovaikutuksessa sen kanssa epäsuorasti.
Ennen kuin puhut yhteyksien suojaamisesta, sinun on vastattava tärkeisiin kysymyksiin, jotka määrittävät suojaustoimenpiteiden rakenteen:
- Vastaako yksi yrityskäyttäjä yhtä DBMS-käyttäjää?
- tarjotaanko pääsy DBMS-tietoihin vain hallitsemasi API:n kautta vai käytetäänkö taulukoita suoraan;
- onko DBMS allokoitu erilliselle suojatulle segmentille, kuka on vuorovaikutuksessa sen kanssa ja miten;
- käytetäänkö pooling/proxy- ja välikerroksia, mikä voi muuttaa tietoja siitä, miten yhteys rakennetaan ja kuka tietokantaa käyttää.
Katsotaan nyt, mitä työkaluja voidaan käyttää yhteyksien suojaamiseen:
- Käytä tietokannan palomuuriluokan ratkaisuja. Lisäsuojaus lisää vähintään DBMS:n tapahtumien läpinäkyvyyttä, ja maksimissaan pystyt tarjoamaan lisätietosuojaa.
- Käytä salasanakäytäntöjä. Niiden käyttö riippuu siitä, kuinka arkkitehtuurisi on rakennettu. Joka tapauksessa yksi salasana DBMS-järjestelmään kytkeytyvän verkkosovelluksen asetustiedostossa ei riitä suojaamiseen. On olemassa useita DBMS-työkaluja, joiden avulla voit hallita, että käyttäjä ja salasana on päivitettävä.
Voit lukea lisää käyttäjäluokitustoiminnoista , voit myös tutustua MS SQL:n haavoittuvuuden arvioijiin .
- Rikastuta istunnon kontekstia tarvittavilla tiedoilla. Jos istunto on läpinäkymätön, et ymmärrä, kuka työskentelee DBMS:ssä sen puitteissa, voit lisätä suoritettavan toiminnon puitteissa tietoja siitä, kuka tekee mitä ja miksi. Nämä tiedot voidaan nähdä tarkastuksessa.
- Määritä SSL, jos sinulla ei ole verkkoerotusta DBMS:n ja loppukäyttäjien välillä; se ei ole erillisessä VLANissa. Tällaisissa tapauksissa on välttämätöntä suojata kuluttajan ja itse DBMS:n välinen kanava. Tietoturvatyökalut ovat saatavilla myös avoimessa lähdekoodissa.
Miten tämä vaikuttaa DBMS:n suorituskykyyn?
Katsotaanpa esimerkkiä PostgreSQL:stä nähdäksesi kuinka SSL vaikuttaa suorittimen kuormitukseen, lisää ajoituksia ja vähentää TPS:ää ja kuluttaako se liikaa resursseja, jos otat sen käyttöön.
PostgreSQL:n lataaminen pgbenchin avulla on yksinkertainen ohjelma suorituskykytestien suorittamiseen. Se suorittaa yhden komentosarjan toistuvasti, mahdollisesti rinnakkaisissa tietokantaistunnoissa, ja laskee sitten keskimääräisen tapahtumanopeuden.
Testi 1 ilman SSL:ää ja SSL:ää käyttäen — yhteys muodostetaan jokaiselle tapahtumalle:
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"Testi 2 ilman SSL:ää ja SSL:ää käyttäen — kaikki tapahtumat suoritetaan yhdessä yhteydessä:
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"Muut asetukset:
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/50000Testitulokset:
EI SSL:ää
SSL
Yhteys muodostetaan jokaiselle tapahtumalle
latenssin keskiarvo
171.915 ms
187.695 ms
tps mukaan lukien yhteyksien luominen
58.168112
53.278062
tps pois lukien yhteyksien muodostaminen
64.084546
58.725846
prosessori
24%
28%
Kaikki tapahtumat suoritetaan yhdessä yhteydessä
latenssin keskiarvo
6.722 ms
6.342 ms
tps mukaan lukien yhteyksien luominen
1587.657278
1576.792883
tps pois lukien yhteyksien muodostaminen
1588.380574
1577.694766
prosessori
17%
21%
Kevyillä kuormilla SSL:n vaikutus on verrattavissa mittausvirheeseen. Jos siirrettävän tiedon määrä on erittäin suuri, tilanne voi olla toinen. Jos muodostamme yhden yhteyden per tapahtuma (tämä on harvinaista, yleensä yhteys jaetaan käyttäjien kesken), sinulla on suuri määrä yhteyksiä/katkoksia, vaikutus voi olla hieman suurempi. Toisin sanoen suorituskyvyn heikkenemisen riskit voivat olla, mutta ero ei ole niin suuri, ettei suojausta käytettäisi.
Huomaa, että toimintatilojen vertailussa on suuri ero: työskentelet samassa istunnossa tai eri tilanteissa. Tämä on ymmärrettävää: resursseja käytetään jokaisen yhteyden luomiseen.
Meillä oli tapaus, kun liitimme Zabbixin luottamustilassa, eli md5:tä ei tarkistettu, todennusta ei tarvittu. Sitten asiakas pyysi ottamaan käyttöön md5-todennustilan. Tämä kuormitti prosessoria voimakkaasti ja suorituskyky heikkeni. Aloimme etsiä tapoja optimoida. Yksi mahdollisista ratkaisuista ongelmaan on ottaa käyttöön verkkorajoituksia, tehdä erilliset VLAN-verkot DBMS:lle, lisätä asetuksia, jotka tekevät selväksi, kuka muodostaa yhteyden ja poistaa todennus.Voit myös optimoida todennusasetukset kulujen vähentämiseksi todennusta otettaessa, mutta Yleensä erilaisten autentikointimenetelmien käyttö vaikuttaa suorituskykyyn ja edellyttää näiden tekijöiden huomioon ottamista suunniteltaessa palvelimien (laitteiston) laskentatehoa DBMS:ää varten.
Johtopäätös: useissa ratkaisuissa pienetkin vivahteet autentikaatiossa voivat vaikuttaa projektiin suuresti ja on huonoa, kun tämä selviää vasta tuotannossa toteutettuina.
Toiminnan tarkastus
Tarkastus ei voi olla vain DBMS. Auditoinnin tarkoituksena on saada tietoa siitä, mitä eri segmenteissä tapahtuu. Tämä voi olla joko tietokannan palomuuri tai käyttöjärjestelmä, jolle DBMS on rakennettu.
Kaupallisissa yritystason DBMS-järjestelmissä kaikki on kunnossa auditoinnin kanssa, mutta avoimessa lähdekoodissa - ei aina. Tässä on mitä PostgreSQL:llä on:
- oletusloki - sisäänrakennettu kirjaus;
- laajennukset: pgaudit - jos oletusloki ei riitä sinulle, voit käyttää erillisiä asetuksia, jotka ratkaisevat joitain ongelmia.
Lisäys videolla olevaan raporttiin:
"Peruslausuntoloki voidaan tarjota tavallisella lokitoiminnolla, jossa log_statement = kaikki.
Tämä on hyväksyttävää seurantaan ja muihin käyttötarkoituksiin, mutta se ei tarjoa tarkastelussa tyypillisesti vaadittua yksityiskohtaista tasoa.
Ei riitä, että sinulla on luettelo kaikista tietokannassa suoritetuista toiminnoista.
On myös voitava löytää erityisiä tilintarkastajaa kiinnostavia lausuntoja.
Tavallinen kirjaus näyttää, mitä käyttäjä pyysi, kun taas pgAudit keskittyy yksityiskohtiin siitä, mitä tapahtui, kun tietokanta suoritti kyselyn.
Tarkastaja saattaa esimerkiksi haluta varmistaa, että tietty taulukko on luotu dokumentoidun ylläpitoikkunan aikana.
Tämä voi tuntua yksinkertaiselta tehtävältä perusauditoinnin ja grep:n kanssa, mutta entä jos sinulle esitetään jotain tämän kaltaista (tahallisesti hämmentävää) esimerkkiä:
DO$$
ALKAA
SUORITA "LUO TABLE-tuonti" || 'ant_table(id int)';
END$$;
Normaali kirjaus antaa sinulle tämän:
LOG: lausunto: DO $$
ALKAA
SUORITA "LUO TABLE-tuonti" || 'ant_table(id int)';
END$$;
Näyttää siltä, että kiinnostavan taulukon löytäminen saattaa vaatia jonkin verran koodituntemusta tapauksissa, joissa taulukot luodaan dynaamisesti.
Tämä ei ole ihanteellinen, koska olisi parempi etsiä yksinkertaisesti taulukon nimellä.
Tässä pgAudit on hyödyllinen.
Samalle syötteelle se tuottaa seuraavan tulosteen lokiin:
TARKASTUS: SESSION,33,1,FUNCTION,DO,,,"DO $$
ALKAA
SUORITA "LUO TABLE-tuonti" || 'ant_table(id int)';
END$$;"
TARKASTUS: SESSION,33,2,DDL,LUO TABLE,TAULUKKO,julkinen.tärkeä_taulukko,LUO TABLE tärkeä_taulukko (id INT)
Ei vain DO-lohko kirjaa lokiin, vaan myös CREATE TABLE:n koko teksti käskytyypin, objektityypin ja koko nimen kanssa, mikä helpottaa hakua.
Kun kirjataan SELECT- ja DML-käskyjä, pgAudit voidaan määrittää kirjaamaan erillinen merkintä jokaiselle käskyssä viitatulle suhteelle.
Jäsentämistä ei tarvita löytääksesi kaikki lauseet, jotka koskettavat tiettyä taulukkoa () ».
Miten tämä vaikuttaa DBMS:n suorituskykyyn?
Suoritetaan testit täydellä tarkastuksella ja katsotaan mitä tapahtuu PostgreSQL:n suorituskyvylle. Otetaan käyttöön suurin tietokantaloki kaikille parametreille.
Emme muuta melkein mitään asetustiedostossa, tärkeintä on ottaa debug5-tila käyttöön saadaksesi mahdollisimman paljon tietoa.
postgresql.conf
log_destination = 'stderr'
logging_collector = päällä
log_truncate_on_rotation = päällä
log_rotation_age = 1 pv
log_rotation_size = 10 Mt
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_lauseke = 0
debug_print_parse = päällä
debug_print_rewritten = päällä
debug_print_plan = päällä
debug_pretty_print = päällä
log_checkpoints = päällä
log_connections = päällä
log_disconnections = päällä
log_duration = päällä
log_isäntänimi = päällä
log_lock_wait = päällä
log_replication_commands = päällä
log_temp_files = 0
log_timezone = 'Eurooppa/Moskova'
PostgreSQL DBMS:ssä, jonka parametrit ovat 1 CPU, 2,8 GHz, 2 Gt RAM, 40 Gt HDD, suoritamme kolme kuormitustestiä komennoilla:
$ 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 benchmarkTestitulokset:
Ei kirjaamista
Hakkuiden kanssa
Tietokannan täyttöaika yhteensä
43,74 sek
53,23 sek
RAM
24%
40%
prosessori
72%
91%
Testi 1 (50 yhteyttä)
Tapahtumien määrä 10 minuutissa
74169
32445
Tapahtumat/s
123
54
Keskimääräinen latenssi
405 мс
925 мс
Testi 2 (150 yhteyttä ja 100 mahdollista)
Tapahtumien määrä 10 minuutissa
81727
31429
Tapahtumat/s
136
52
Keskimääräinen latenssi
550 мс
1432 мс
Tietoja kooista
DB koko
2251 MB
2262 MB
Tietokannan lokin koko
0 MB
4587 MB
Bottom line: täydellinen tarkastus ei ole kovin hyvä. Auditoinnin tiedot ovat yhtä suuria kuin itse tietokannan tiedot tai jopa enemmän. DBMS:n kanssa työskenneltäessä syntyvien lokien määrä on yleinen ongelma tuotannossa.
Katsotaanpa muita parametreja:
- Nopeus ei muutu paljon: ilman kirjaamista - 43,74 sekuntia, kirjaamalla - 53,23 sekuntia.
- RAM-muistin ja suorittimen suorituskyky kärsii, koska sinun on luotava tarkastustiedosto. Tämä näkyy myös tuottavuudessa.
Kun yhteyksien määrä kasvaa, suorituskyky luonnollisesti heikkenee hieman.
Yrityksissä, joissa on tilintarkastus, se on vielä vaikeampaa:
- dataa on paljon;
- auditointia tarvitaan paitsi syslogin kautta SIEM:ssä, myös tiedostoissa: jos syslogille tapahtuu jotain, tietokannan lähellä on oltava tiedosto, johon tiedot tallennetaan;
- auditointiin tarvitaan erillinen hylly, jotta I/O-levyjä ei tuhlata, sillä se vie paljon tilaa;
- Tapahtuu, että tietoturvatyöntekijät tarvitsevat GOST-standardeja kaikkialla, he vaativat valtion tunnistamisen.
Tietoihin pääsyn rajoittaminen
Katsotaanpa teknologioita, joita käytetään tietojen suojaamiseen ja pääsyyn kaupallisissa DBMS-järjestelmissä ja avoimessa lähdekoodissa.
Mitä voit yleensä käyttää:
- Proseduurien ja toimintojen salaus ja hämärtäminen (Wrapping) – toisin sanoen erilliset työkalut ja apuohjelmat, jotka tekevät luettavasta koodista lukukelvottoman. Totta, silloin sitä ei voida muuttaa eikä muuttaa takaisin. Tätä lähestymistapaa tarvitaan joskus ainakin DBMS-puolella - lisenssirajoitusten logiikka tai valtuutuslogiikka on salattu tarkasti menettely- ja toimintotasolla.
- Tietojen näkyvyyden rajoittaminen riveittäin (RLS) on sitä, kun eri käyttäjät näkevät yhden taulukon, mutta siinä eri rivikoostumus, eli jotain ei voida näyttää kenellekään rivitasolla.
- Näytettävien tietojen muokkaaminen (Masking) on sitä, että taulukon yhdessä sarakkeessa olevat käyttäjät näkevät joko tiedot tai vain tähtiä, eli joiltakin käyttäjiltä tiedot suljetaan. Tekniikka määrittää, kenelle käyttäjälle näytetään mitäkin hänen käyttöoikeustasonsa perusteella.
- Tietoturva DBA/Sovellus DBA/DBA pääsynhallinta on pikemminkin pääsyn rajoittamista itse DBMS:ään, eli tietoturvatyöntekijät voidaan erottaa tietokannan ylläpitäjistä ja sovellusten ylläpitäjistä. Avoimessa lähdekoodissa tällaisia teknologioita on vähän, mutta kaupallisissa DBMS-järjestelmissä niitä on paljon. Niitä tarvitaan, kun useilla käyttäjillä on pääsy palvelimiin.
- Tiedostojen käytön rajoittaminen tiedostojärjestelmätasolla. Voit myöntää oikeuksia ja käyttöoikeuksia hakemistoille niin, että jokaisella järjestelmänvalvojalla on pääsy vain tarpeellisiin tietoihin.
- Pakollinen pääsy ja muistin tyhjennys - näitä tekniikoita käytetään harvoin.
- Päästä päähän -salaus suoraan DBMS:stä on asiakaspuolen salausta avainten hallinnan kanssa palvelinpuolella.
- Tiedonsalaus. Esimerkiksi sarakesalaus on silloin, kun käytät mekanismia, joka salaa tietokannan yhden sarakkeen.
Miten tämä vaikuttaa DBMS:n suorituskykyyn?
Katsotaanpa esimerkkiä sarakesalauksesta PostgreSQL:ssä. Siellä on pgcrypto-moduuli, jonka avulla voit tallentaa valitut kentät salatussa muodossa. Tämä on hyödyllistä, kun vain osa tiedoista on arvokasta. Salattujen kenttien lukemista varten asiakas lähettää salauksen purkuavaimen, palvelin purkaa tiedot ja palauttaa ne asiakkaalle. Ilman avainta kukaan ei voi tehdä mitään tiedoillesi.
Testataan pgcryptolla. Luodaan taulukko salatuista tiedoista ja tavallisista tiedoista. Alla on komennot taulukoiden luomiseen, aivan ensimmäisellä rivillä on hyödyllinen komento - itse laajennuksen luominen DBMS-rekisteröinnillä:
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'));Seuraavaksi yritetään tehdä datanäyte kustakin taulukosta ja tarkastellaan suoritusajoja.
Valinta taulukosta ilman salaustoimintoa:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtSekuntikello on päällä.
id | teksti1 | teksti 2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 riviä)
Aika: 1,386 ms
Valinta taulukosta, jossa on salaustoiminto:
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.txtSekuntikello on päällä.
id | purkaa salaus | purkaa salaus
——+—————+—————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 riviä)
Aika: 50,203 ms
Testitulokset:
Ilman salausta
Pgcrypto (salauksen purku)
Näyte 1000 riviä
1,386 мс
50,203 мс
prosessori
15%
35%
RAM
+ 5%
Salauksella on suuri vaikutus suorituskykyyn. Voidaan nähdä, että ajoitus on kasvanut, koska salatun datan salauksen purkutoiminnot (ja salauksen purku on yleensä edelleen kietoutunut logiikkaasi) vaativat huomattavia resursseja. Toisin sanoen ajatus kaikkien tietoja sisältävien sarakkeiden salaamisesta on täynnä suorituskyvyn heikkenemistä.
Salaus ei kuitenkaan ole hopealuodi, joka ratkaisee kaikki ongelmat. Salauksen purkamisen ja siirron aikana puretut tiedot ja salauksen purkuavain sijaitsevat palvelimella. Siksi joku, jolla on täysi pääsy tietokantapalvelimeen, kuten järjestelmänvalvoja, voi siepata avaimet.
Kun koko sarakkeelle on yksi avain kaikille käyttäjille (vaikka ei kaikille, mutta rajoitetun joukon asiakkaille), tämä ei aina ole hyvä ja oikein. Siksi he alkoivat tehdä päästä päähän -salausta, DBMS:ssä he alkoivat pohtia vaihtoehtoja tietojen salaamiseksi asiakas- ja palvelinpuolella, ja samat avainvarastot ilmestyivät - erilliset tuotteet, jotka tarjoavat avainten hallinnan DBMS:ssä. puolella.
Suojausominaisuudet kaupallisissa ja avoimen lähdekoodin tietokantajärjestelmissä
Tehtävät
Tyyppi
Salasanapolitiikka
Tilintarkastus
Proseduurien ja toimintojen lähdekoodin suojaaminen
RLS
Salaus
oraakkeli
kaupallinen
+
+
+
+
+
MsSql
kaupallinen
+
+
+
+
+
kaupallinen
+
+
+
+
laajennukset
PostgreSQL
Ilmainen
laajennukset
laajennukset
-
+
laajennukset
MongoDb
Ilmainen
-
+
-
-
Saatavilla vain MongoDB Enterprisessa
Taulukko ei ole läheskään täydellinen, mutta tilanne on tämä: kaupallisissa tuotteissa tietoturvaongelmat on ratkaistu pitkään, avoimessa lähdekoodissa käytetään yleensä jonkinlaisia lisäosia turvallisuuteen, monet toiminnot puuttuvat , joskus sinun on lisättävä jotain. Esimerkiksi salasanakäytännöt - PostgreSQL:llä on monia erilaisia laajennuksia (, , , , ), jotka toteuttavat salasanapolitiikkaa, mutta mielestäni mikään niistä ei kata kaikkia kotimaisen yrityssegmentin tarpeita.
Mitä tehdä, jos sinulla ei ole tarvitsemaasi missään? Haluat esimerkiksi käyttää tiettyä tietokantajärjestelmää, jossa ei ole asiakkaan tarvitsemia toimintoja.
Sitten voit käyttää kolmannen osapuolen ratkaisuja, jotka toimivat erilaisten tietokantajärjestelmien kanssa, esimerkiksi Crypto DB tai Garda DB. Jos puhumme kotimaisen segmentin ratkaisuista, he tietävät GOST:ista paremmin kuin avoimessa lähdekoodissa.
Toinen vaihtoehto on kirjoittaa mitä tarvitset itse, toteuttaa tietojen käyttö ja salaus sovelluksessa menettelytasolla. Totta, se on vaikeampaa GOSTin kanssa. Mutta yleensä voit piilottaa tiedot tarpeen mukaan, laittaa ne DBMS:ään, sitten hakea ne ja purkaa sen tarvittaessa suoraan sovellustasolla. Samalla mieti heti, kuinka suojaat nämä algoritmit sovelluksessa. Mielestämme tämä tulisi tehdä DBMS-tasolla, koska se toimii nopeammin.
Tämä raportti esiteltiin ensimmäisen kerran klo kirjoittanut Mail.ru Cloud Solutions. Katsomuita esityksiä ja tilaa tapahtumatiedotteet Telegramissa .
Mitä muuta luettavaa aiheesta:
- .
- .
Lähde: will.com