Mano vardas Denisas Rožkovas, esu programinės įrangos kūrimo vadovas įmonėje „Gazinformservice“, produktų komandoje . Teisės aktai ir įmonių reglamentai nustato tam tikrus duomenų saugojimo saugumo reikalavimus. Niekas nenori, kad trečiosios šalys gautų prieigą prie konfidencialios informacijos, todėl bet kuriam projektui svarbūs šie klausimai: identifikavimas ir autentifikavimas, prieigos prie duomenų valdymas, informacijos vientisumo užtikrinimas sistemoje, saugos įvykių registravimas. Todėl noriu pakalbėti apie keletą įdomių dalykų, susijusių su DBVS saugumu.
Straipsnis parengtas remiantis kalba adresu organizuotas . Jei nenorite skaityti, galite žiūrėti:
Straipsnį sudarys trys dalys:
- Kaip apsaugoti ryšius.
- Kas yra veiksmų auditas ir kaip fiksuoti kas vyksta duomenų bazės pusėje ir prie jos prisijungiant.
- Kaip apsaugoti duomenis pačioje duomenų bazėje ir kokios technologijos tam yra prieinamos.
Trys DBVS saugos komponentai: ryšio apsauga, veiklos auditas ir duomenų apsauga
Jūsų ryšių apsauga
Prie duomenų bazės galite prisijungti tiesiogiai arba netiesiogiai naudodami žiniatinklio programas. Paprastai verslo vartotojas, ty asmuo, dirbantis su DBVS, su ja sąveikauja netiesiogiai.
Prieš kalbėdami apie jungčių apsaugą, turite atsakyti į svarbius klausimus, kurie lemia, kaip bus struktūrizuotos saugos priemonės:
- Ar vienas verslo vartotojas prilygsta vienam DBVS vartotojui?
- ar prieiga prie DBVS duomenų suteikiama tik per jūsų valdomą API, ar lentelės pasiekiamos tiesiogiai;
- ar DBVS priskirta atskiram apsaugotam segmentui, kas ir kaip su juo sąveikauja;
- ar naudojamas telkimas / tarpinis serveris ir tarpiniai sluoksniai, kurie gali pakeisti informaciją apie tai, kaip kuriamas ryšys ir kas naudojasi duomenų baze.
Dabar pažiūrėkime, kokius įrankius galima naudoti ryšiams apsaugoti:
- Naudokite duomenų bazės ugniasienės klasės sprendimus. Papildomas apsaugos sluoksnis bent jau padidins to, kas vyksta DBVS, skaidrumą, o maksimaliai galėsite užtikrinti papildomą duomenų apsaugą.
- Naudokite slaptažodžių politiką. Jų naudojimas priklauso nuo to, kaip sukurta jūsų architektūra. Bet kokiu atveju, vieno slaptažodžio žiniatinklio programos, jungiančios prie DBVS, konfigūracijos faile apsaugai nepakanka. Yra keletas DBVS įrankių, leidžiančių kontroliuoti, ar reikia atnaujinti vartotoją ir slaptažodį.
Galite perskaityti daugiau apie vartotojų įvertinimo funkcijas , taip pat galite sužinoti apie MS SQL pažeidžiamumo vertintojus .
- Praturtinkite sesijos kontekstą reikalinga informacija. Jei seansas yra neskaidrus, nesuprantate, kas dirba DBVS jos rėmuose, galite, atlikdami operaciją, pridėti informacijos apie tai, kas ką daro ir kodėl. Šią informaciją galima pamatyti audite.
- Konfigūruokite SSL, jei neturite tinklo atskyrimo tarp DBVS ir galutinių vartotojų; jis nėra atskirame VLAN. Tokiais atvejais būtina apsaugoti kanalą tarp vartotojo ir pačios DBVS. Saugos įrankiai taip pat yra atvirojo kodo.
Kaip tai paveiks DBVS veikimą?
Pažiūrėkime į PostgreSQL pavyzdį, kad pamatytume, kaip SSL veikia procesoriaus apkrovą, padidina laiką ir sumažina TPS bei ar sunaudos per daug išteklių, jei jį įjungsite.
„PostgreSQL“ įkėlimas naudojant „pgbench“ yra paprasta programa, skirta atlikti našumo testus. Jis pakartotinai vykdo vieną komandų seką, galbūt lygiagrečių duomenų bazės seansų metu, ir tada apskaičiuoja vidutinį operacijų greitį.
1 bandymas be SSL ir naudojant SSL — ryšys nustatomas kiekvienai operacijai:
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"2 bandymas be SSL ir naudojant SSL — visos operacijos atliekamos vienu ryšiu:
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"Kiti nustatymai:
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/50000Testo rezultatai:
NĖRA SSL
SSL
Kiekvienai operacijai užmezgamas ryšys
delsos vidurkis
171.915 ms
187.695 ms
tps, įskaitant ryšių užmezgimą
58.168112
53.278062
tps, išskyrus ryšių užmezgimą
64.084546
58.725846
CPU
24%
28%
Visos operacijos atliekamos vienu ryšiu
delsos vidurkis
6.722 ms
6.342 ms
tps, įskaitant ryšių užmezgimą
1587.657278
1576.792883
tps, išskyrus ryšių užmezgimą
1588.380574
1577.694766
CPU
17%
21%
Esant nedidelėms apkrovoms, SSL įtaka yra panaši į matavimo paklaidą. Jei perduodamų duomenų kiekis yra labai didelis, situacija gali būti kitokia. Jei užmezgame vieną ryšį vienai operacijai (tai reta, dažniausiai ryšys yra dalijamas tarp vartotojų), turite daug prisijungimų/atsijungimų, poveikis gali būti šiek tiek didesnis. Tai yra, gali kilti sumažėjusio našumo rizika, tačiau skirtumas nėra toks didelis, kad nereikėtų naudoti apsaugos.
Atkreipkite dėmesį, kad yra didelis skirtumas, jei lyginate darbo režimus: dirbate toje pačioje sesijoje arba skirtinguose. Tai suprantama: kiekvienam ryšiui sukurti išleidžiami ištekliai.
Turėjome atvejį, kai Zabbix prijungėme pasitikėjimo režimu, tai yra, md5 nebuvo patikrintas, autentifikavimo nereikėjo. Tada klientas paprašė įjungti md5 autentifikavimo režimą. Tai labai apkrovė centrinį procesorių, o našumas sumažėjo. Pradėjome ieškoti optimizavimo būdų. Vienas iš galimų problemos sprendimo būdų – įdiegti tinklo apribojimus, padaryti atskirus VLAN DBVS, pridėti nustatymus, kad būtų aišku, kas iš kur jungiasi ir panaikinti autentifikavimą. Apskritai skirtingų autentifikavimo metodų naudojimas turi įtakos našumui ir į šiuos veiksnius reikia atsižvelgti projektuojant DBVS serverių (aparatinės įrangos) skaičiavimo galią.
Išvada: daugelyje sprendimų net ir nedideli autentifikavimo niuansai gali labai paveikti projektą ir blogai, kai tai paaiškėja tik įdiegus gamyboje.
Veiksmų auditas
Auditas gali būti ne tik DBVS. Auditas yra informacijos apie tai, kas vyksta skirtinguose segmentuose, gavimas. Tai gali būti duomenų bazės ugniasienė arba operacinė sistema, ant kurios sukurta DBVS.
Komercinėse įmonės lygio DBVS su auditu viskas gerai, tačiau atvirojo kodo – ne visada. Štai ką turi PostgreSQL:
- numatytasis žurnalas – integruotas registravimas;
- plėtiniai: pgaudit – jei numatytojo registravimo jums nepakanka, galite naudoti atskirus nustatymus, kurie išsprendžia kai kurias problemas.
Pranešimo papildymas vaizdo įraše:
„Pagrindinį ataskaitų registravimą gali teikti standartinė registravimo priemonė su log_statement = viskas.
Tai priimtina stebėjimui ir kitiems tikslams, tačiau neužtikrina tokio išsamumo lygio, kuris paprastai reikalingas auditui.
Nepakanka turėti visų duomenų bazėje atliktų operacijų sąrašą.
Taip pat turėtų būti įmanoma rasti konkrečius teiginius, kurie domina auditorių.
Standartinis registravimas rodo, ko paprašė vartotojas, o pgAudit sutelkia dėmesį į detales, kas atsitiko, kai duomenų bazė vykdė užklausą.
Pavyzdžiui, auditorius gali norėti patikrinti, ar tam tikra lentelė buvo sukurta per dokumentuotą priežiūros laikotarpį.
Tai gali atrodyti kaip paprasta užduotis naudojant pagrindinį auditą ir grep, bet kas būtų, jei jums būtų pateiktas kažkas panašaus į šį (tyčia klaidinantį) pavyzdį:
DO $$
BEGIN
VYKDYTI „KURTI LENTELĘ importuoti“ || 'ant_table(id int)';
END$$;
Standartinis registravimas suteiks jums tai:
LOG: pareiškimas: DO $$
BEGIN
VYKDYTI „KURTI LENTELĘ importuoti“ || 'ant_table(id int)';
END$$;
Atrodo, kad norint rasti dominančią lentelę, gali prireikti šiek tiek kodo žinių tais atvejais, kai lentelės kuriamos dinamiškai.
Tai nėra idealu, nes būtų geriau ieškoti tiesiog pagal lentelės pavadinimą.
Čia pgAudit praverčia.
Naudojant tą pačią įvestį, žurnale bus pateikta ši išvestis:
AUDITAS: SESIJA,33,1,FUNKCIJA,DO,,,"DO $$
BEGIN
VYKDYTI „KURTI LENTELĘ importuoti“ || 'ant_table(id int)';
END$$;"
AUDITAS: SESIJA,33,2,DDL,KURTI LENTELĘ,LENTELĖ,vieša.svarbi_lentelė,KURTI LENTELĘ svarbi_lentelė (id INT)
Užregistruojamas ne tik DO blokas, bet ir visas CREATE TABLE tekstas su teiginio tipu, objekto tipu ir visu pavadinimu, todėl paieška tampa lengviau.
Registruojant SELECT ir DML teiginius, pgAudit galima sukonfigūruoti taip, kad kiekvienam sakinyje nurodytam ryšiui būtų įrašytas atskiras įrašas.
Norint rasti visus teiginius, kurie liečia tam tikrą lentelę, analizuoti nereikia) ».
Kaip tai paveiks DBVS veikimą?
Atlikime testus įjungę visą auditą ir pažiūrėkime, kas atsitiks su PostgreSQL našumu. Įgalinkime maksimalų visų parametrų duomenų bazės registravimą.
Konfigūracijos faile beveik nieko nekeičiame, svarbiausia įjungti debug5 režimą, kad gautume maksimalią informaciją.
postgresql.conf
log_destination = 'stderr'
logging_collector = įjungta
log_truncate_on_rotation = įjungta
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages = derinimas5
log_min_error_statement = derinimas5
log_min_duration_statement = 0
debug_print_parse = įjungta
debug_print_rewritten = įjungta
debug_print_plan = įjungta
debug_pretty_print = įjungta
log_checkpoints = įjungta
log_connections = įjungta
log_disconnections = įjungta
log_duration = įjungta
log_hostname = įjungta
log_lock_wait = įjungta
log_replication_commands = įjungta
log_temp_files = 0
log_timezone = 'Europa/Maskva'
„PostgreSQL“ DBVS, kurios parametrai yra 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, atliekame tris apkrovos testus naudodami komandas:
$ 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 benchmarkTesto rezultatai:
Jokio kirtimo
Su medienos ruoša
Bendras duomenų bazės užpildymo laikas
43,74 sek
53,23 sek
RAM
24%
40%
CPU
72%
91%
1 bandymas (50 jungčių)
Operacijų skaičius per 10 minučių
74169
32445
Sandoriai/sek
123
54
Vidutinis delsos laikas
405 ms
925 ms
2 bandymas (150 jungčių ir 100 galimų)
Operacijų skaičius per 10 minučių
81727
31429
Sandoriai/sek
136
52
Vidutinis delsos laikas
550 ms
1432 ms
Apie dydžius
DB dydis
2251 МБ
2262 МБ
Duomenų bazės žurnalo dydis
0 MB
4587 MB
Esmė: pilnas auditas nėra labai geras. Duomenys iš audito bus tiek pat, kiek yra pačioje duomenų bazėje, ar net daugiau. Žurnalų kiekis, generuojamas dirbant su DBVS, yra dažna gamybos problema.
Pažvelkime į kitus parametrus:
- Greitis labai nesikeičia: be registravimo - 43,74 sekundės, su registravimu - 53,23 sekundės.
- Nukentės RAM ir procesoriaus našumas, nes reikės sugeneruoti audito failą. Tai pastebima ir produktyvumui.
Natūralu, kad padidėjus jungčių skaičiui, veikimas šiek tiek pablogės.
Įmonėse, kuriose atliekamas auditas, yra dar sunkiau:
- yra daug duomenų;
- auditas reikalingas ne tik per syslog SIEM, bet ir failuose: jei kas nors atsitiktų su syslog, šalia duomenų bazės turi būti failas, kuriame saugomi duomenys;
- auditui reikalinga atskira lentyna, kad nebūtų švaistomi I/O diskai, nes užima daug vietos;
- Pasitaiko, kad informacijos saugumo darbuotojams visur reikia GOST standartų, reikalauja valstybinio identifikavimo.
Prieigos prie duomenų ribojimas
Pažvelkime į technologijas, kurios naudojamos duomenims apsaugoti ir prieigai prie jų komercinėse DBVS ir atvirojo kodo.
Ką paprastai galite naudoti:
- Procedūrų ir funkcijų šifravimas ir užmaskavimas (Wrapping) – tai yra atskiri įrankiai ir priemonės, dėl kurių nuskaitomas kodas tampa neįskaitomas. Tiesa, tada jo negalima nei pakeisti, nei grąžinti atgal. Toks požiūris kartais reikalingas bent jau DBVS pusėje – licencijų apribojimų logika arba autorizavimo logika yra užšifruota tiksliai procedūrų ir funkcijų lygmenyje.
- Duomenų matomumo ribojimas pagal eilutes (RLS) yra tada, kai skirtingi vartotojai mato vieną lentelę, bet joje skirtingą eilučių sudėtį, tai yra, kažko negalima parodyti kam nors eilutės lygiu.
- Rodomų duomenų redagavimas (maskavimas) yra tada, kai vartotojai viename lentelės stulpelyje mato arba duomenis, arba tik žvaigždutes, tai yra, kai kuriems vartotojams informacija bus uždaryta. Ši technologija nustato, kuriam vartotojui kas rodoma pagal jo prieigos lygį.
- Saugumo DBA/Application DBA/DBA prieigos kontrolė veikiau yra prieigos prie pačios DBVS ribojimas, ty informacijos saugos darbuotojai gali būti atskirti nuo duomenų bazių administratorių ir programų administratorių. Tokių atvirojo kodo technologijų yra nedaug, tačiau komercinėse DBVS jų yra daug. Jie reikalingi, kai yra daug vartotojų, turinčių prieigą prie pačių serverių.
- Prieigos prie failų ribojimas failų sistemos lygiu. Katalogams galite suteikti teises ir prieigos privilegijas, kad kiekvienas administratorius turėtų prieigą tik prie būtinų duomenų.
- Privaloma prieiga ir atminties išvalymas – šios technologijos naudojamos retai.
- Visiškas šifravimas tiesiai iš DBVS yra kliento pusės šifravimas su raktų valdymu serverio pusėje.
- Duomenų šifravimas. Pavyzdžiui, stulpelių šifravimas yra tada, kai naudojate mechanizmą, kuris užšifruoja vieną duomenų bazės stulpelį.
Kaip tai veikia DBVS našumą?
Pažvelkime į stulpelių šifravimo PostgreSQL pavyzdį. Yra pgcrypto modulis, leidžiantis išsaugoti pasirinktus laukus šifruota forma. Tai naudinga, kai vertingi tik kai kurie duomenys. Norėdami nuskaityti užšifruotus laukus, klientas perduoda iššifravimo raktą, serveris iššifruoja duomenis ir grąžina juos klientui. Be rakto niekas nieko negali padaryti su jūsų duomenimis.
Išbandykime su pgcrypto. Sukurkime lentelę su užšifruotais ir įprastais duomenimis. Žemiau yra lentelių kūrimo komandos, pačioje pirmoje eilutėje yra naudinga komanda - sukurti patį plėtinį su DBMS registracija:
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'));Tada pabandykime sudaryti duomenų pavyzdį iš kiekvienos lentelės ir pažvelgti į vykdymo laiką.
Pasirinkimas iš lentelės be šifravimo funkcijos:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtChronometras įjungtas.
id | tekstas1 | tekstas2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 eilučių)
Laikas: 1,386 ms
Pasirinkimas iš lentelės su šifravimo funkcija:
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.txtChronometras įjungtas.
id | iššifruoti | iššifruoti
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 eilučių)
Laikas: 50,203 ms
Testo rezultatai:
Be šifravimo
Pgcrypto (iššifruoti)
1000 eilučių pavyzdys
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Šifravimas turi didelę įtaką našumui. Matyti, kad laikas pailgėjo, nes užšifruotų duomenų iššifravimo operacijos (o iššifravimas dažniausiai vis dar yra įtrauktos į jūsų logiką) reikalauja didelių išteklių. Tai reiškia, kad idėja šifruoti visus stulpelius, kuriuose yra tam tikrų duomenų, yra kupinas našumo sumažėjimo.
Tačiau šifravimas nėra sidabrinė kulka, kuri išsprendžia visas problemas. Iššifruoti duomenys ir iššifravimo raktas duomenų iššifravimo ir perdavimo proceso metu yra serveryje. Todėl raktus gali perimti asmuo, turintis visišką prieigą prie duomenų bazės serverio, pavyzdžiui, sistemos administratorius.
Kai yra vienas raktas visam stulpeliui visiems vartotojams (net jei ne visiems, bet riboto rinkinio klientams), tai ne visada gerai ir teisingai. Štai kodėl jie pradėjo šifruoti nuo galo iki galo, DBVS pradėjo svarstyti galimybes šifruoti duomenis kliento ir serverio pusėje, ir atsirado tos pačios raktų saugyklos - atskiri produktai, teikiantys raktų valdymą DBVS. pusėje.
Saugos funkcijos komercinėse ir atvirojo kodo DBVS
Funkcijos
Tipas
Slaptažodžio politika
Auditas
Procedūrų ir funkcijų šaltinio kodo apsauga
RLS "
Šifravimas
orakulas
komercinis
+
+
+
+
+
MsSql
komercinis
+
+
+
+
+
komercinis
+
+
+
+
plėtiniai
PostgreSQL
Nemokamas
plėtiniai
plėtiniai
-
+
plėtiniai
MongoDb
Nemokamas
-
+
-
-
Galima tik MongoDB Enterprise
Lentelė toli gražu nebaigta, bet situacija tokia: komerciniuose produktuose saugumo problemos jau seniai sprendžiamos, atvirajame kode, kaip taisyklė, saugumui naudojami kažkokie priedai, trūksta daugelio funkcijų , kartais reikia ką nors pridėti. Pavyzdžiui, slaptažodžių politika – PostgreSQL turi daug skirtingų plėtinių (, , , , ), kurios įgyvendina slaptažodžių politiką, tačiau, mano nuomone, nė viena iš jų neapima visų šalies įmonių segmento poreikių.
Ką daryti, jei niekur neturite to, ko jums reikia? Pavyzdžiui, norite naudoti konkrečią DBVS, kuri neturi klientui reikalingų funkcijų.
Tada galite naudoti trečiųjų šalių sprendimus, kurie veikia su skirtingomis DBVS, pavyzdžiui, Crypto DB arba Garda DB. Jei mes kalbame apie sprendimus iš vidaus segmento, jie geriau žino apie GOST nei atvirojo kodo.
Antrasis variantas yra parašyti tai, ko jums reikia, įdiegti prieigą prie duomenų ir programoje šifravimą procedūros lygiu. Tiesa, su GOST bus sunkiau. Tačiau apskritai galite paslėpti duomenis, jei reikia, įdėti juos į DBVS, tada nuskaityti ir, jei reikia, iššifruoti, tiesiog programos lygiu. Tuo pačiu metu nedelsdami pagalvokite, kaip apsaugosite šiuos algoritmus programoje. Mūsų nuomone, tai turėtų būti daroma DBVS lygiu, nes jis veiks greičiau.
Ši ataskaita pirmą kartą buvo pristatyta pateikė Mail.ru Cloud Solutions. Žiūrėkkitus pasirodymus ir užsiprenumeruokite renginių pranešimus Telegramoje .
Ką dar skaityti šia tema:
- .
- .
Šaltinis: www.habr.com