Jenengku Denis Rozhkov, aku dadi kepala pangembangan piranti lunak ing perusahaan Gazinformservice, ing tim produk . Legislasi lan peraturan perusahaan ngetrapake syarat tartamtu kanggo keamanan panyimpenan data. Ora ana sing pengin pihak katelu entuk akses menyang informasi rahasia, mula masalah ing ngisor iki penting kanggo proyek apa wae: identifikasi lan otentikasi, ngatur akses menyang data, njamin integritas informasi ing sistem, logging acara keamanan. Mulane, aku pengin ngomong babagan sawetara poin sing menarik babagan keamanan DBMS.
Artikel disiapake adhedhasar pidato ing diatur . Yen sampeyan ora pengin maca, sampeyan bisa nonton:
Artikel kasebut bakal duwe telung bagean:
- Carane ngamanake sambungan.
- Apa audit tumindak lan cara ngrekam apa sing kedadeyan ing sisih database lan nyambungake.
- Cara nglindhungi data ing database dhewe lan teknologi apa sing kasedhiya kanggo iki.
Telung komponen keamanan DBMS: proteksi sambungan, audit kegiatan lan proteksi data
Ngamanake sambungan sampeyan
Sampeyan bisa nyambung menyang database kanthi langsung utawa ora langsung liwat aplikasi web. Minangka aturan, pangguna bisnis, yaiku, wong sing nggarap DBMS, sesambungan kanthi ora langsung.
Sadurunge ngomong babagan nglindhungi sambungan, sampeyan kudu mangsuli pitakon penting sing nemtokake cara langkah-langkah keamanan bakal kabentuk:
- Apa siji pangguna bisnis padha karo siji pangguna DBMS?
- apa akses menyang data DBMS diwenehake mung liwat API sing sampeyan kontrol, utawa apa tabel diakses langsung;
- apa DBMS diparengake menyang bagean sing dilindhungi kapisah, sing sesambungan karo lan carane;
- apa pooling / proxy lan lapisan penengah digunakake, kang bisa ngganti informasi bab carane sambungan dibangun lan sing nggunakake database.
Saiki ayo ndeleng alat apa sing bisa digunakake kanggo ngamanake sambungan:
- Gunakake solusi kelas firewall database. Lapisan proteksi tambahan bakal, minimal, nambah transparansi apa sing kedadeyan ing DBMS, lan kanthi maksimal, sampeyan bakal bisa menehi perlindungan data tambahan.
- Gunakake kabijakan sandi. Panganggone gumantung carane arsitektur sampeyan dibangun. Ing kasus apa wae, siji sandhi ing file konfigurasi aplikasi web sing nyambung menyang DBMS ora cukup kanggo proteksi. Ana sawetara alat DBMS sing ngidini sampeyan ngontrol manawa pangguna lan sandhi mbutuhake nganyari.
Sampeyan bisa maca liyane babagan fungsi rating pangguna , sampeyan uga bisa ngerteni babagan MS SQL Vulnerability Assessmen .
- Enrich konteks sesi karo informasi sing perlu. Yen sesi iku opaque, sampeyan ora ngerti sapa sing makarya ing DBMS ing framework sawijining, sampeyan bisa, ing framework saka operasi dileksanakake, nambah informasi bab sing nindakake apa lan apa. Informasi iki bisa dideleng ing audit.
- Konfigurasi SSL yen sampeyan ora duwe pemisahan jaringan antarane DBMS lan pangguna pungkasan; ora ana ing VLAN sing kapisah. Ing kasus kaya mengkono, iku penting kanggo nglindhungi saluran antarane konsumen lan DBMS dhewe. Piranti keamanan uga kasedhiya ing open source.
Kepiye carane iki bakal mengaruhi kinerja DBMS?
Ayo katon ing conto PostgreSQL kanggo ndeleng carane SSL mengaruhi beban CPU, nambah wektu lan nyuda TPS, lan apa bakal nggunakake akeh banget sumber daya yen sampeyan ngaktifake.
Loading PostgreSQL nggunakake pgbench iku program prasaja kanggo mbukak tes kinerja. Iku nglakokaké urutan siji saka printah bola-bali, bisa ing sesi database podo, lan banjur ngetung tingkat transaksi rata-rata.
Tes 1 tanpa SSL lan nggunakake SSL - sambungan ditetepake kanggo saben 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"Tes 2 tanpa SSL lan nggunakake SSL - kabeh transaksi dileksanakake ing siji 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"Setelan liyane:
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/50000Asil tes:
Ora SSL
SSL
Sambungan ditetepake kanggo saben transaksi
rata-rata latensi
171.915 ms
187.695 ms
tps kalebu sambungan madegaken
58.168112
53.278062
tps ora kalebu sambungan madegaken
64.084546
58.725846
CPU
24%
28%
Kabeh transaksi dileksanakake ing siji sambungan
rata-rata latensi
6.722 ms
6.342 ms
tps kalebu sambungan madegaken
1587.657278
1576.792883
tps ora kalebu sambungan madegaken
1588.380574
1577.694766
CPU
17%
21%
Ing beban entheng, pengaruh SSL bisa dibandhingake karo kesalahan pangukuran. Yen jumlah data sing ditransfer akeh banget, kahanan bisa uga beda. Yen kita netepake siji sambungan saben transaksi (iki arang, biasane sambungan dienggo bareng antarane kedhaftar), sampeyan duwe nomer akeh sambungan / pedhot, impact bisa dadi sethitik luwih gedhe. Yaiku, bisa uga ana risiko nyuda kinerja, nanging bedane ora dadi gedhe amarga ora nggunakake proteksi.
Wigati dimangerteni manawa ana bedane sing kuat yen sampeyan mbandhingake mode operasi: sampeyan nggarap sesi sing padha utawa ing macem-macem. Iki bisa dingerteni: sumber daya digunakake kanggo nggawe saben sambungan.
Kita duwe kasus nalika nyambungake Zabbix ing mode kepercayaan, yaiku, md5 ora dicenthang, ora perlu otentikasi. Banjur pelanggan takon kanggo ngaktifake mode otentikasi md5. Iki ndadekake beban abot ing CPU, lan kinerja mudhun. Kita wiwit golek cara kanggo ngoptimalake. Salah sawijining solusi sing bisa ditindakake kanggo masalah kasebut yaiku ngleksanakake watesan jaringan, nggawe VLAN sing kapisah kanggo DBMS, nambah setelan supaya jelas sapa sing nyambung saka ngendi lan mbusak otentikasi. Sampeyan uga bisa ngoptimalake setelan otentikasi kanggo nyuda biaya nalika ngaktifake otentikasi, nanging umume nggunakake macem-macem cara otentikasi mengaruhi kinerja lan mbutuhake njupuk faktor kasebut nalika ngrancang daya komputerisasi server (hardware) kanggo DBMS.
Kesimpulan: ing sawetara solusi, malah nuansa cilik ing otentikasi bisa banget mengaruhi project lan iku ala nalika iki dadi cetha mung nalika dipun ginakaken ing produksi.
Audit tindakan
Audit bisa ora mung DBMS. Audit yaiku babagan njupuk informasi babagan kedadeyan ing macem-macem segmen. Iki bisa dadi firewall basis data utawa sistem operasi sing dibangun DBMS.
Ing DBMS tingkat Enterprise komersial kabeh apik karo audit, nanging ing open source - ora mesthi. Mangkene apa sing diduweni PostgreSQL:
- log standar - log sing dibangun;
- ekstensi: pgaudit - yen logging standar ora cukup kanggo sampeyan, sampeyan bisa nggunakake setelan kapisah sing ngatasi sawetara masalah.
Tambahan kanggo laporan ing video:
"Log statement dhasar bisa diwenehake dening fasilitas logging standar kanthi log_statement = kabeh.
Iki ditrima kanggo ngawasi lan panggunaan liyane, nanging ora nyedhiyakake tingkat rinci sing biasane dibutuhake kanggo audit.
Ora cukup nduwe dhaptar kabeh operasi sing ditindakake ing database.
Sampeyan uga kudu bisa nemokake statement tartamtu sing menarik kanggo auditor.
Log standar nuduhake apa sing dijaluk pangguna, dene pgAudit fokus ing rincian apa sing kedadeyan nalika database nglakokake pitakon.
Contone, auditor bisa uga pengin verifikasi sing tabel tartamtu digawe ing jendhela pangopènan nyathet.
Iki bisa uga katon kaya tugas sing gampang karo audit dhasar lan grep, nanging kepiye yen sampeyan diwenehi conto kaya iki (sengaja mbingungake):
DO$$
BEGIN
LAKUKAN 'Impor TABEL' || 'ant_table(id int)';
END$$;
Log standar bakal menehi sampeyan iki:
LOG: statement: DO $$
BEGIN
LAKUKAN 'Impor TABEL' || 'ant_table(id int)';
END$$;
Katon yen nemokake tabel kapentingan mbutuhake sawetara kawruh kode ing kasus ing ngendi tabel digawe kanthi dinamis.
Iki ora becik, amarga luwih becik nelusuri kanthi jeneng tabel.
Iki ngendi pgAudit kasedhiya.
Kanggo input sing padha, bakal ngasilake output iki ing log:
AUDIT: SESI,33,1,FUNCTION,DO,,,"DO $$
BEGIN
LAKUKAN 'Impor TABEL' || 'ant_table(id int)';
END$$;"
AUDIT: SESI,33,2,DDL,Gawe TABLE,TABLE,public.important_table,GIP TABLE important_table (id INT)
Ora mung pamblokiran DO sing dicathet, nanging uga teks lengkap CREATE TABLE kanthi jinis statement, jinis obyek, lan jeneng lengkap, nggawe panelusuran luwih gampang.
Nalika logging SELECT lan DML statements, pgAudit bisa diatur kanggo log entri kapisah kanggo saben hubungan referensi ing statement.
Ora ana parsing sing dibutuhake kanggo nemokake kabeh pernyataan sing ndemek tabel tartamtu () ».
Kepiye carane iki bakal mengaruhi kinerja DBMS?
Ayo mbukak tes kanthi audit lengkap lan ndeleng apa sing kedadeyan ing kinerja PostgreSQL. Ayo ngaktifake logging database maksimal kanggo kabeh parameter.
Kita ngganti meh ora ana ing file konfigurasi, sing paling penting yaiku ngaktifake mode debug5 kanggo entuk informasi maksimal.
postgresql.conf
log_destination = 'stderr'
logging_collector = ing
log_truncate_on_rotation = on
umur_rotasi_log = 1d
log_rotation_size = 10 MB
log_min_pesen = debug5
log_min_error_statement = debug5
log_min_duration_statement = 0
debug_print_parse = aktif
debug_print_rewritten = on
debug_print_plan = on
debug_pretty_print = aktif
log_checkpoints = ing
log_connections = ing
log_disconnections = on
log_duration = ing
log_hostname = on
log_lock_wait = on
log_replication_commands = on
log_temp_files = 0
log_timezone = 'Eropa/Moscow'
Ing DBMS PostgreSQL kanthi paramèter 1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD, kita nindakake telung tes muatan kanthi nggunakake printah:
$ 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 benchmarkAsil tes:
Ora logging
Kanthi logging
Total wektu ngisi database
43,74 detik
53,23 detik
RAM
24%
40%
CPU
72%
91%
Tes 1 (50 sambungan)
Jumlah transaksi ing 10 menit
74169
32445
Transaksi / sec
123
54
Latency Rata-rata
405 ms
925 ms
Tes 2 (150 sambungan karo 100 bisa)
Jumlah transaksi ing 10 menit
81727
31429
Transaksi / sec
136
52
Latency Rata-rata
550 ms
1432 ms
Babagan ukuran
ukuran DB
2251 MB
2262 MB
Ukuran log database
0 MB
4587 MB
Bottom line: audit lengkap ora apik banget. Data saka audit bakal dadi gedhe minangka data ing database dhewe, utawa malah luwih. Jumlah logging sing digawe nalika nggarap DBMS minangka masalah umum ing produksi.
Ayo ndeleng paramèter liyane:
- Kacepetan ora owah akeh: tanpa logging - 43,74 detik, kanthi logging - 53,23 detik.
- Kinerja RAM lan CPU bakal nandhang sangsara, amarga sampeyan kudu ngasilake file audit. Iki uga katon ing produktivitas.
Minangka jumlah sambungan mundhak, mesthi, kinerja bakal deteriorate rada.
Ing perusahaan kanthi audit, luwih angel:
- ana akeh data;
- audit dibutuhake ora mung liwat syslog ing SIEM, nanging uga ing file: yen ana kedadeyan ing syslog, kudu ana file sing cedhak karo database sing data disimpen;
- rak kapisah dibutuhake kanggo audit supaya ora sampah I / O disk, amarga njupuk akeh papan;
- Mengkono manawa karyawan keamanan informasi mbutuhake standar GOST ing endi wae, mbutuhake identifikasi negara.
Watesan akses menyang data
Ayo goleki teknologi sing digunakake kanggo nglindhungi data lan ngakses ing DBMS komersial lan open source.
Apa sing umume bisa digunakake:
- Enkripsi lan obfuscation prosedur lan fungsi (Wrapping) - yaiku, alat lan keperluan sing kapisah sing nggawe kode sing bisa diwaca ora bisa diwaca. Bener, banjur ora bisa diowahi utawa diuripake maneh. Pendekatan iki kadhangkala dibutuhake paling ora ing sisih DBMS - logika watesan lisensi utawa logika wewenang dienkripsi kanthi tepat ing tingkat prosedur lan fungsi.
- Watesan visibilitas data kanthi baris (RLS) yaiku nalika pangguna sing beda ndeleng siji tabel, nanging komposisi baris sing beda, yaiku, ana sing ora bisa dituduhake menyang wong ing tingkat baris.
- Ngowahi data sing ditampilake (Masking) yaiku nalika pangguna ing salah sawijining kolom tabel ndeleng data utawa mung tanda bintang, yaiku, kanggo sawetara pangguna, informasi kasebut bakal ditutup. Teknologi nemtokake pangguna sing ditampilake apa adhedhasar tingkat akses.
- Keamanan DBA / Aplikasi DBA / DBA kontrol akses, rodo, bab matesi akses kanggo DBMS dhewe, sing, karyawan keamanan informasi bisa dipisahake saka administrator database lan administrator aplikasi. Ana sawetara teknologi kasebut ing open source, nanging ana akeh ing DBMS komersial. Iki dibutuhake nalika ana akeh pangguna sing duwe akses menyang server dhewe.
- Watesan akses menyang file ing tingkat sistem file. Sampeyan bisa menehi hak lan hak istimewa akses menyang direktori supaya saben administrator mung nduweni akses menyang data sing dibutuhake.
- Akses wajib lan ngresiki memori - teknologi kasebut arang digunakake.
- Enkripsi end-to-end langsung saka DBMS yaiku enkripsi sisih klien kanthi manajemen kunci ing sisih server.
- Enkripsi data. Contone, enkripsi columnar nalika sampeyan nggunakake mekanisme sing encrypts kolom siji saka database.
Kepiye carane iki mengaruhi kinerja DBMS?
Ayo goleki conto enkripsi kolom ing PostgreSQL. Ana modul pgcrypto, ngidini sampeyan nyimpen lapangan sing dipilih ing wangun ndhelik. Iki migunani nalika mung sawetara data sing penting. Kanggo maca kolom sing dienkripsi, klien ngirim kunci dekripsi, server dekripsi data lan bali menyang klien. Tanpa kunci, ora ana sing bisa nindakake apa-apa karo data sampeyan.
Ayo nyoba karo pgcrypto. Ayo nggawe tabel kanthi data sing dienkripsi lan data biasa. Ing ngisor iki ana perintah kanggo nggawe tabel, ing baris pisanan ana prentah sing migunani - nggawe ekstensi dhewe kanthi registrasi 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'));Sabanjure, ayo nyoba nggawe conto data saka saben tabel lan ndeleng wektu eksekusi.
Milih saka 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.txtStopwatch urip.
id | teks 1 | teks2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 baris)
Wektu: 1,386 ms
Pilihan saka tabel kanthi fungsi enkripsi:
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.txtStopwatch urip.
id | dekripsi | dekripsi
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 baris)
Wektu: 50,203 ms
Asil tes:
Ora ana enkripsi
Pgcrypto (dekripsi)
Sampel 1000 baris
1,386 ms
50,203 ms
CPU
15%
35%
RAM
+ 5%
Enkripsi nduwe pengaruh gedhe ing kinerja. Bisa dideleng manawa wektune saya tambah, amarga operasi dekripsi data sing dienkripsi (lan dekripsi biasane isih ana ing logika sampeyan) mbutuhake sumber daya sing signifikan. Yaiku, ide kanggo ndhelik kabeh kolom sing ngemot sawetara data kebak karo penurunan kinerja.
Nanging, enkripsi dudu peluru perak sing ngrampungake kabeh masalah. Data sing didekripsi lan kunci dekripsi sajrone proses dekripsi lan ngirim data ana ing server. Mulane, tombol bisa dicegat dening wong sing nduweni akses lengkap menyang server database, kayata administrator sistem.
Nalika ana siji tombol kanggo kabeh kolom kanggo kabeh pangguna (sanajan ora kanggo kabeh, nanging kanggo klien saka pesawat winates), iki ora tansah apik lan bener. Mulane dheweke wiwit nindakake enkripsi end-to-end, ing DBMS wiwit nimbang opsi kanggo enkripsi data ing sisih klien lan server, lan panyimpenan kunci-kubah sing padha katon - produk kapisah sing nyedhiyakake manajemen kunci ing DBMS. sisih.
Fitur keamanan ing DBMS komersial lan open source
Fungsi
Gaya
Kebijakan Sandi
audit
Nglindhungi kode sumber prosedur lan fungsi
RLS
enkripsi
Oracle
komersial
+
+
+
+
+
MsSql
komersial
+
+
+
+
+
komersial
+
+
+
+
ekstensi
PostgreSQL
free
ekstensi
ekstensi
-
+
ekstensi
MonggoDb
free
-
+
-
-
Kasedhiya mung ing MongoDB Enterprise
Tabel kasebut adoh saka lengkap, nanging kahanan iki: ing produk komersial, masalah keamanan wis ditanggulangi suwe, ing open source, minangka aturan, sawetara jinis tambahan digunakake kanggo keamanan, akeh fungsi sing ilang. , kadhangkala sampeyan kudu nambah soko. Contone, kabijakan sandhi - PostgreSQL duwe macem-macem ekstensi (, , , , ), sing ngetrapake kabijakan sandi, nanging, miturut pendapatku, ora ana sing nyakup kabeh kabutuhan segmen perusahaan domestik.
Apa sing kudu ditindakake yen sampeyan ora duwe apa sing dibutuhake ing ngendi wae? Contone, sampeyan pengin nggunakake DBMS tartamtu sing ora duwe fungsi sing dibutuhake pelanggan.
Banjur sampeyan bisa nggunakake solusi pihak katelu sing bisa digunakake karo DBMS beda, contone, Crypto DB utawa Garda DB. Yen kita ngomong babagan solusi saka segmen domestik, mula luwih ngerti babagan GOST tinimbang ing open source.
Pilihan kapindho yaiku nulis apa sing sampeyan butuhake dhewe, ngetrapake akses data lan enkripsi ing aplikasi ing tingkat prosedur. Bener, bakal luwih angel karo GOST. Nanging ing umum, sampeyan bisa ndhelikake data kaya sing dibutuhake, dilebokake ing DBMS, banjur njupuk lan dekripsi yen perlu, langsung ing tingkat aplikasi. Ing wektu sing padha, langsung mikir babagan carane sampeyan bakal nglindhungi algoritma kasebut ing aplikasi kasebut. Miturut pendapat kita, iki kudu ditindakake ing tingkat DBMS, amarga bakal luwih cepet.
Laporan iki pisanan ditampilake ing dening Mail.ru Cloud Solutions. Delengenpagelaran liyane lan langganan pengumuman acara ing Telegram .
Apa maneh kanggo maca babagan topik kasebut:
- .
- .
Source: www.habr.com