Nami abdi Denis Rozhkov, abdi kapala pamekaran parangkat lunak di perusahaan Gazinformservice, dina tim produk Jatoba. Panerapan jeung peraturan perusahaan maksakeun sarat nu tangtu pikeun kaamanan gudang data. Taya sahijieun hayang pihak katilu meunang aksés ka informasi rahasia, jadi isu di handap ieu penting pikeun proyék naon: idéntifikasi jeung auténtikasi, ngatur aksés ka data, mastikeun integritas informasi dina sistem, logging acara kaamanan. Ku alatan éta, abdi hoyong ngobrol ngeunaan sababaraha titik metot ngeunaan kaamanan DBMS.

Artikel disusun dumasar kana pidato di @DatabasesMeetup, dikelompokeun Mail.ru Cloud Solutions. Upami anjeun henteu hoyong maca, anjeun tiasa nonton:

Artikel bakal mibanda tilu bagian:

• Kumaha ngamankeun sambungan.
• Naon Inok lampah sareng kumaha ngarékam naon anu lumangsung dina sisi database sareng nyambungkeunana.
• Kumaha ngajaga data dina pangkalan data sorangan sareng téknologi naon anu sayogi pikeun ieu.

Tilu komponén kaamanan DBMS: panyalindungan sambungan, auditing aktivitas sarta panyalindungan data

Ngamankeun sambungan anjeun

Anjeun tiasa nyambung ka pangkalan data sacara langsung atanapi henteu langsung ngalangkungan aplikasi wéb. Sakumaha aturan, pangguna bisnis, nyaéta, jalma anu damel sareng DBMS, henteu langsung berinteraksi sareng éta.

Sateuacan ngawangkong ngeunaan ngajagi sambungan, anjeun kedah ngajawab patarosan penting anu nangtukeun kumaha ukuran kaamanan bakal terstruktur:

• Naha hiji pamaké bisnis sarua jeung hiji pamaké DBMS?
• naha aksés ka data DBMS disadiakeun ngan ngaliwatan hiji API nu Anjeun ngadalikeun, atawa naha tabel diaksés langsung;
• naha DBMS dialokasikeun ka bagéan anu ditangtayungan anu misah, anu berinteraksi sareng éta sareng kumaha;
• naha pooling / proxy jeung lapisan panengah dipaké, nu bisa ngarobah informasi ngeunaan kumaha sambungan nu diwangun jeung anu ngagunakeun database.

Ayeuna hayu urang tingali alat naon anu tiasa dianggo pikeun ngamankeun sambungan:

1. Paké solusi kelas firewall database. Lapisan panyalindungan tambahan bakal, sahenteuna, ningkatkeun transparansi naon anu lumangsung dina DBMS, sareng maksimal, anjeun bakal tiasa masihan panyalindungan data tambahan.
2. Paké kawijakan sandi. Pamakéanna gumantung kana kumaha arsitéktur anjeun diwangun. Dina naon waé, hiji kecap akses dina file konfigurasi aplikasi wéb anu nyambung ka DBMS henteu cekap pikeun panyalindungan. Aya sababaraha parabot DBMS nu ngidinan Anjeun pikeun ngadalikeun yén pamaké sarta sandi merlukeun apdet.

   Anjeun tiasa maca langkung seueur ngeunaan fungsi rating pangguna di dieu, Anjeun oge bisa manggihan ngeunaan MS SQL Kerentanan Assessmen di dieu. 

3. Ngabeungharan kontéks sési kalayan inpormasi anu diperyogikeun. Upami sési opak, anjeun henteu ngartos saha anu damel di DBMS dina kerangka na, anjeun tiasa, dina kerangka operasi anu dilaksanakeun, nambihan inpormasi ngeunaan saha anu ngalakukeun naon sareng kunaon. Inpormasi ieu tiasa ditingali dina pamariksaan.
4. Konpigurasikeun SSL upami anjeun teu gaduh pamisahan jaringan antara DBMS sareng pangguna akhir; éta henteu aya dina VLAN anu misah. Dina kasus sapertos kitu, penting pikeun ngajaga saluran antara konsumen sareng DBMS sorangan. Alat kaamanan ogé sayogi dina sumber terbuka.

Kumaha ieu bakal mangaruhan kinerja DBMS?

Hayu urang tingali conto PostgreSQL pikeun ningali kumaha SSL mangaruhan beban CPU, ningkatkeun waktos sareng ngirangan TPS, sareng naha éta bakal meakeun seueur teuing sumber upami anjeun ngaktipkeun.

Loading PostgreSQL maké pgbench mangrupakeun program basajan pikeun ngajalankeun tés kinerja. Ieu executes runtuyan tunggal paréntah sababaraha kali, jigana dina sési database paralel, lajeng ngitung laju urus rata.

Uji 1 tanpa SSL sareng nganggo SSL - sambungan didirikeun pikeun tiap transaksi:

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"

Uji 2 tanpa SSL sareng nganggo SSL - sadaya transaksi dilaksanakeun dina hiji sambungan:

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"

Setélan séjén:

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

Hasil tés:

 
NO SSL
SSL

Sambungan diadegkeun pikeun unggal transaksi

rata latency
mdet 171.915
mdet 187.695

tps kaasup sambungan ngadegkeun
58.168112
53.278062

tps kaasup sambungan ngadegkeun
64.084546
58.725846

CPU
24%
28%

Sadaya transaksi dilaksanakeun dina hiji sambungan

rata latency
mdet 6.722
mdet 6.342

tps kaasup sambungan ngadegkeun
1587.657278
1576.792883

tps kaasup sambungan ngadegkeun
1588.380574
1577.694766

CPU
17%
21%

Dina beban anu hampang, pangaruh SSL tiasa dibandingkeun sareng kasalahan pangukuran. Upami jumlah data anu ditransfer ageung pisan, kaayaan tiasa béda. Lamun urang ngadegkeun hiji sambungan per urus (ieu jarang, biasana sambungan dibagikeun antara pamaké), anjeun boga angka nu gede ngarupakeun sambungan / disconnections, dampak bisa jadi saeutik leuwih gede. Hartina, meureun aya résiko tina turunna kinerja, tapi bédana teu jadi badag salaku teu make panyalindungan.

Punten dicatet yén aya béda anu kuat upami anjeun ngabandingkeun modeu operasi: anjeun damel dina sési anu sami atanapi dina sési anu béda. Ieu kaharti: sumberdaya anu spent dina nyieun unggal sambungan.

Kami ngagaduhan pasualan nalika kami nyambungkeun Zabbix dina modeu amanah, nyaéta, md5 henteu dipariksa, henteu peryogi auténtikasi. Lajeng nasabah nanya pikeun ngaktipkeun mode auténtikasi md5. Ieu nempatkeun beban beurat dina CPU, sareng kinerja turun. Urang mimitian néangan cara pikeun ngaoptimalkeun. Salah sahiji solusi anu mungkin pikeun masalah nyaéta ngalaksanakeun larangan jaringan, ngadamel VLAN anu misah pikeun DBMS, tambahkeun setélan supados jelas saha anu nyambungkeun ti mana sareng ngahapus auténtikasi. sacara umum pamakéan métode béda auténtikasi mangaruhan kinerja sarta merlukeun nyokot faktor ieu kana akun nalika ngarancang kakuatan komputasi server (hardware) pikeun DBMS.

Kacindekan: dina sajumlah solusi, bahkan nuansa leutik dina auténtikasi tiasa mangaruhan pisan kana proyék sareng éta goréng nalika ieu janten jelas ngan ukur dilaksanakeun dina produksi.

Audit tindakan

Audit tiasa henteu ngan ukur DBMS. Inok nyaéta ngeunaan meunangkeun inpormasi ngeunaan naon anu lumangsung dina bagéan anu béda. Ieu tiasa janten firewall database atanapi sistem operasi dimana DBMS diwangun.

Dina komérsial tingkat Perusahaan DBMSs sagalana rupa kalawan auditing, tapi dina open source - teu salawasna. Ieu naon anu PostgreSQL gaduh:

• log standar - logging diwangun;
• ekstensi: pgaudit - lamun logging standar teu cukup pikeun anjeun, anjeun tiasa nganggo setélan misah nu ngajawab sababaraha masalah.

Tambahan kana laporan dina video:

"Log pernyataan dasar tiasa disayogikeun ku fasilitas logging standar sareng log_statement = sadayana.

Ieu bisa ditarima keur monitoring sarta kagunaan séjén, tapi teu nyadiakeun tingkat jéntré ilaharna diperlukeun pikeun auditing.

Henteu cekap gaduh daptar sadaya operasi anu dilakukeun dina pangkalan data.

Éta ogé kedah tiasa mendakan pernyataan khusus anu dipikaresep ku auditor.

Log standar nunjukkeun naon anu dipénta ku pangguna, sedengkeun pgAudit museurkeun kana detil naon anu kajantenan nalika pangkalan data ngalaksanakeun pamundut.

Contona, auditor publik meureun hoyong pariksa yen tabel husus dijieun dina jandela pangropéa documented.

Ieu sigana sapertos tugas saderhana sareng pamariksaan dasar sareng grep, tapi kumaha upami anjeun dibere conto sapertos kieu (ngahaja ngabingungkeun):

DO$$
ngamimitian
laksanakeun 'Jieun tabel impor' || 'ant_table(id int)';
TAMAT$$;

logging standar bakal masihan anjeun ieu:

LOG: pernyataan: DO $$
ngamimitian
laksanakeun 'Jieun tabel impor' || 'ant_table(id int)';
TAMAT$$;

Nembongan yen manggihan tabel dipikaresep bisa merlukeun sababaraha pangaweruh kode dina kasus dimana tabel dijieun dinamis.

Ieu teu idéal, sabab bakal leuwih hade mun saukur neangan ku ngaran tabel.

Ieu dimana pgAudit asalna gunana.

Pikeun input anu sami, éta bakal ngahasilkeun kaluaran ieu dina log:

AUDIT: SESI,33,1,FUNGSI,DO,,,"DO $$
ngamimitian
laksanakeun 'Jieun tabel impor' || 'ant_table(id int)';
TAMAT$$;"
AUDIT: SESI,33,2,DDL,JIEUN TABEL,TABEL,public.penting_tabél,Jieun tabél important_table (id INT)

Henteu ngan ukur blok DO anu asup, tapi ogé téks lengkep CREATE TABLE kalayan jinis pernyataan, jinis obyék, sareng nami lengkep, ngajantenkeun milarian langkung gampang.

Nalika asup kana pernyataan PILIH sareng DML, pgAudit tiasa dikonpigurasi pikeun log éntri anu misah pikeun unggal hubungan anu dirujuk dina pernyataan éta.

Taya parsing diperlukeun pikeun manggihan sakabeh pernyataan nu noel tabel nu tangtu (*) ».

Kumaha ieu bakal mangaruhan kinerja DBMS?

Hayu urang ngajalankeun tés kalawan auditing pinuh diaktipkeun tur tingal kumaha kajadian ka kinerja PostgreSQL. Hayu urang ngaktifkeun logging database maksimum pikeun sakabéh parameter.

Urang ngarobah ampir euweuh dina file konfigurasi, hal pangpentingna nyaéta ngaktipkeun mode debug5 pikeun meunangkeun informasi maksimum.

postgresql.conf

log_destination = 'stderr'
logging_collector = asup
log_truncate_on_rotation = on
log_rotation_age = 1d
log_rotation_size = 10 MB
log_min_messages = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = on
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = on
log_checkpoints = on
log_connections = asup
log_disconnections = on
log_duration = on
log_hostname = on
log_lock_wait = on
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Éropa/Moskow'

Dina DBMS PostgreSQL kalayan parameter 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, urang ngalaksanakeun tilu tés beban nganggo paréntah:

$ 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

Hasil tés:

Taya logging
Kalawan logging

Total waktu ngeusian database
43,74 detik
53,23 detik

RAM
24%
40%

CPU
72%
91%

Tés 1 (50 sambungan)

Jumlah transaksi dina 10 menit
74169
32445

Transaksi/detik
123
54

Rata Latency
405 ms
925 ms

Uji 2 (150 sambungan sareng 100 kamungkinan)

Jumlah transaksi dina 10 menit
81727
31429

Transaksi/detik
136
52

Rata Latency
550 ms
1432 ms

Ngeunaan ukuran

Ukuran DB
2251 MB
2262 MB

Ukuran log database
0 MB
4587 MB

Bottom line: a Inok pinuh teu pisan alus. Data tina Inok bakal jadi badag salaku data dina database sorangan, atawa malah leuwih. Jumlah logging anu dihasilkeun nalika damel sareng DBMS mangrupikeun masalah umum dina produksi.

Hayu urang nempo parameter séjén:

• Laju teu robah teuing: tanpa logging - 43,74 detik, kalawan logging - 53,23 detik.
• Kinerja RAM sareng CPU bakal sangsara, sabab anjeun kedah ngahasilkeun file Inok. Ieu ogé katingali dina produktivitas.

Salaku jumlah sambungan naek, sacara alami, kinerja bakal deteriorate rada.

Dina korporasi kalawan audit malah leuwih hese:

• aya loba data;
• auditing diperlukeun henteu ngan ngaliwatan syslog di SIEM, tapi ogé dina file: lamun aya kajadian ka syslog, kudu aya file deukeut database nu data disimpen;
• rak misah diperlukeun pikeun auditing ku kituna teu runtah I / O disk, sabab butuh nepi loba spasi;
• Éta kajadian yén karyawan kaamanan inpormasi peryogi standar GOST di mana waé, aranjeunna peryogi idéntifikasi nagara.

Ngawatesan aksés ka data

Hayu urang tingali téknologi anu dianggo pikeun ngajagi data sareng ngaksésna dina DBMS komérsial sareng open source.

Naon anu anjeun umumna tiasa dianggo:

1. Enkripsi sareng obfuscation tina prosedur sareng fungsi (Wrapping) - nyaéta, alat sareng utilitas anu misah anu ngajantenkeun kode anu tiasa dibaca teu tiasa dibaca. Leres, teras éta henteu tiasa dirobih atanapi diréfaktor deui. Pendekatan ieu kadang diperyogikeun sahenteuna dina sisi DBMS - logika larangan lisénsi atanapi logika otorisasi énkripsi tepat dina tingkat prosedur sareng fungsi.
2. Ngawatesan pisibilitas data ku jajar (RLS) nyaéta nalika pangguna anu béda ningali hiji méja, tapi komposisi baris anu béda di jerona, nyaéta, hiji hal henteu tiasa ditingalikeun ka batur dina tingkat jajar.
3. Ngédit data anu ditampilkeun (Masking) nyaéta nalika pangguna dina hiji kolom tabel ningali data atanapi ngan ukur tanda bintang, nyaéta, pikeun sababaraha pangguna inpormasi bakal ditutup. Téknologi nangtukeun pamaké mana anu ditingalikeun dumasar kana tingkat aksésna.
4. Kaamanan DBA / Aplikasi DBA / kontrol aksés DBA téh, rada, ngeunaan ngawatesan aksés ka DBMS sorangan, nyaeta, karyawan kaamanan informasi bisa dipisahkeun ti pangurus database jeung pangurus aplikasi. Aya sababaraha téknologi sapertos di open source, tapi aya seueur di DBMS komérsial. Éta diperyogikeun nalika seueur pangguna anu gaduh aksés kana server sorangan.
5. Ngawatesan aksés kana file dina tingkat sistem file. Anjeun tiasa masihan hak sareng hak istimewa aksés ka diréktori supados unggal administrator gaduh aksés ngan kana data anu diperyogikeun.
6. Aksés wajib sareng ngabersihan mémori - téknologi ieu jarang dianggo.
7. Énkripsi tungtung-ka-tungtung langsung ti DBMS nyaéta énkripsi sisi klien sareng manajemén konci dina sisi server.
8. Énkripsi data. Contona, enkripsi columnar nyaeta mun anjeun migunakeun mékanisme nu encrypts kolom tunggal database.

Kumaha ieu mangaruhan kinerja DBMS?

Hayu urang tingali conto enkripsi columnar dina PostgreSQL. Aya modul pgcrypto, éta ngamungkinkeun anjeun pikeun nyimpen widang anu dipilih dina bentuk énkripsi. Ieu mangpaat lamun ngan sababaraha data anu berharga. Pikeun maca widang énkripsi, klien ngirimkeun konci dekripsi, server ngadekrip data sareng mulangkeunana ka klien. Tanpa konci, teu aya anu tiasa ngalakukeun nanaon sareng data anjeun.

Hayu urang nguji jeung pgcrypto. Hayu urang nyieun tabel kalawan data énkripsi sarta data biasa. Di handap ieu paréntah pikeun nyieun tabel, dina baris kahiji aya paréntah mangpaat - nyieun extension sorangan kalawan pendaptaran DBMS:

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

Salajengna, hayu urang cobian ngadamel conto data tina unggal méja sareng tingali waktos palaksanaan.

Milih tina tabel tanpa fungsi enkripsi:

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

Stopwatch hurung.

  id | téks1 | téks2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 garis)

Waktos: 1,386 ms

Pilihan tina méja kalayan fungsi énkripsi:

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

Stopwatch hurung.

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

Waktos: 50,203 ms

Hasil tés:

 
Tanpa énkripsi
Pgcrypto (ngadékripsi)

Sampel 1000 jajar
1,386 ms
50,203 ms

CPU
15%
35%

RAM
 
+ 5%

Énkripsi boga dampak badag dina kinerja. Ieu bisa ditempo yén timing geus ngaronjat, saprak operasi dekripsi data énkripsi (jeung dekripsi biasana masih dibungkus dina logika anjeun) merlukeun sumberdaya signifikan. Nyaéta, ideu pikeun énkripsi sadaya kolom anu ngandung sababaraha data mangrupikeun panurunan dina pagelaran.

Nanging, énkripsi sanés pélor pérak anu ngabéréskeun sadaya masalah. Data anu didekripsi sareng konci dekripsi salami prosés ngadekrip sareng ngirimkeun data aya dina server. Ku alatan éta, konci bisa dicegat ku batur anu boga aksés pinuh ka server database, kayaning administrator sistem.

Lamun aya hiji konci pikeun sakabéh kolom pikeun sakabéh pamaké (sanajan henteu pikeun sakabéh, tapi pikeun klien tina set kawates), ieu teu salawasna alus tur bener. Éta sababna aranjeunna mimiti ngalakukeun enkripsi tungtung-ka-tungtung, dina DBMS aranjeunna mimiti mertimbangkeun pilihan pikeun énkripsi data dina sisi klien sareng server, sareng panyimpen konci-kolong anu sami muncul - produk anu misah anu nyayogikeun manajemén konci dina DBMS. sisi.

Conto énkripsi sapertos di MongoDB

Fitur kaamanan dina DBMS komérsial sareng open source

fungsi
ngetik
Kawijakan Sandi
Inok
Ngajagi kode sumber tina prosedur sareng fungsi
RLS
enkripsi

Oracle
komérsial
+
+
+
+
+

MsSql
komérsial
+
+
+
+
+

Jatoba
komérsial
+
+
+
+
ekstensi

PostgreSQL
bebas
ekstensi
ekstensi
-
+
ekstensi

MongoDb
bebas
-
+
-
-
Sadia dina MongoDB Enterprise wungkul

Méja tebih ti lengkep, tapi kaayaan ieu: dina produk komérsial, masalah kaamanan parantos direngsekeun pikeun waktos anu lami, dina open source, sakumaha aturan, sababaraha jinis tambihan dianggo pikeun kaamanan, seueur fungsi anu leungit. , sakapeung anjeun kudu nambahan hiji hal. Contona, kawijakan sandi - PostgreSQL boga loba ekstensi béda (1, 2, 3, 4, 5), anu ngalaksanakeun kabijakan sandi, tapi, dina pamanggih kuring, teu aya anu nyertakeun sadaya kabutuhan segmen perusahaan domestik.

Naon anu kudu dipigawé lamun teu boga naon nu peryogi mana? Salaku conto, anjeun hoyong nganggo DBMS khusus anu henteu ngagaduhan fungsi anu diperyogikeun ku nasabah.

Teras anjeun tiasa nganggo solusi pihak katilu anu tiasa dianggo sareng DBMS anu béda, contona, Crypto DB atanapi Garda DB. Lamun urang ngobrol ngeunaan solusi tina bagean domestik, maranéhna terang ngeunaan GOSTs leuwih hade tinimbang di open source.

Pilihan kadua nyaéta nyerat naon anu anjeun peryogikeun, ngalaksanakeun aksés data sareng enkripsi dina aplikasi dina tingkat prosedur. Leres, éta bakal langkung hese sareng GOST. Tapi sacara umum, anjeun tiasa nyumputkeun data upami diperyogikeun, nempatkeun kana DBMS, teras nimba sareng ngadekrip upami diperyogikeun, langsung dina tingkat aplikasi. Dina waktos anu sami, langsung pikirkeun kumaha anjeun bakal ngajagaan algoritma ieu dina aplikasi. Dina pamadegan urang, ieu kudu dipigawé dina tingkat DBMS, sabab bakal dianggo gancang.

laporan ieu munggaran dibere di @Databases Meetup ku Mail.ru Cloud Solutions. Neuteup видео pintonan séjén sarta ngalanggan announcements acara on Telegram Sabudeureun Kubernetes di Mail.ru Grup.

Naon deui maca dina topik:

1. Leuwih ti Ceph: MCS awan block gudang.
2. Kumaha carana milih pangkalan data pikeun proyék supados anjeun henteu kedah milih deui.

sumber: www.habr.com