Adım Denis Rozhkov, Gazinformservice şirketinin ürün ekibinde yazılım geliştirme sorumlusuyum. . Mevzuat ve kurumsal düzenlemeler, veri depolamanın güvenliği için belirli gereksinimler getirmektedir. Kimse üçüncü tarafların gizli bilgilere erişmesini istemez, bu nedenle aşağıdaki konular her proje için önemlidir: tanımlama ve kimlik doğrulama, verilere erişimi yönetme, sistemdeki bilgilerin bütünlüğünü sağlama, güvenlik olaylarını günlüğe kaydetme. Bu nedenle DBMS güvenliği ile ilgili bazı ilginç noktalara değinmek istiyorum.
Makale bir konuşmadan yola çıkılarak hazırlanmıştır. organize edilmiş . Okumak istemiyorsanız izleyebilirsiniz:
Makale üç bölümden oluşacak:
- Bağlantıların güvenliği nasıl sağlanır?
- Eylem denetimi nedir ve veritabanı tarafında olup bitenlerin nasıl kaydedileceği ve ona bağlanılacağı.
- Veritabanındaki verilerin nasıl korunacağı ve bunun için hangi teknolojilerin mevcut olduğu.
DBMS güvenliğinin üç bileşeni: bağlantı koruması, etkinlik denetimi ve veri koruması
Bağlantılarınızın güvenliğini sağlama
Veritabanına doğrudan veya dolaylı olarak web uygulamaları aracılığıyla bağlanabilirsiniz. Kural olarak iş kullanıcısı yani DBMS ile çalışan kişi onunla dolaylı olarak etkileşime girer.
Bağlantıların korunmasından bahsetmeden önce güvenlik önlemlerinin nasıl yapılandırılacağını belirleyen önemli soruları yanıtlamanız gerekiyor:
- Bir iş kullanıcısı bir DBMS kullanıcısına eşdeğer midir?
- DBMS verilerine erişimin yalnızca sizin kontrol ettiğiniz bir API aracılığıyla sağlanıp sağlanmadığı veya tablolara doğrudan erişilip erişilmediği;
- DBMS'nin ayrı bir korumalı bölüme tahsis edilip edilmediği, onunla kimin ve nasıl etkileşim kurduğu;
- Bağlantının nasıl kurulduğu ve veritabanını kimin kullandığı hakkındaki bilgileri değiştirebilecek havuz/proxy ve ara katmanların kullanılıp kullanılmadığı.
Şimdi bağlantıları güvenli hale getirmek için hangi araçların kullanılabileceğini görelim:
- Veritabanı güvenlik duvarı sınıfı çözümlerini kullanın. Ek bir koruma katmanı, en azından DBMS'de olup bitenlerin şeffaflığını artıracak ve maksimumda ek veri koruması sağlayabileceksiniz.
- Şifre politikalarını kullanın. Kullanımları mimarinizin nasıl inşa edildiğine bağlıdır. Her durumda, DBMS'ye bağlanan bir web uygulamasının konfigürasyon dosyasındaki tek bir şifre, koruma için yeterli değildir. Kullanıcının ve parolanın güncellenmesi gerektiğini kontrol etmenize olanak tanıyan bir dizi DBMS aracı vardır.
Kullanıcı derecelendirme işlevleri hakkında daha fazla bilgi edinebilirsiniz Ayrıca MS SQL Güvenlik Açığı Değerlendiricileri hakkında da bilgi edinebilirsiniz. .
- Oturumun içeriğini gerekli bilgilerle zenginleştirin. Oturum opaksa, DBMS'de kimin kendi çerçevesinde çalıştığını anlamıyorsunuz, gerçekleştirilen işlem çerçevesinde kimin neyi, neden yaptığına dair bilgiler ekleyebilirsiniz. Bu bilgi denetimde görülebilir.
- DBMS ile son kullanıcılar arasında ağ ayrımınız yoksa, ayrı bir VLAN'da değilse SSL'yi yapılandırın. Bu gibi durumlarda tüketici ile DBMS arasındaki kanalın korunması zorunludur. Güvenlik araçları açık kaynak olarak da mevcuttur.
Bu, DBMS'nin performansını nasıl etkileyecektir?
SSL'nin CPU yükünü nasıl etkilediğini, zamanlamaları nasıl artırdığını, TPS'yi nasıl azalttığını ve etkinleştirirseniz çok fazla kaynak tüketip tüketmeyeceğini görmek için PostgreSQL örneğine bakalım.
PostgreSQL'i pgbench kullanarak yüklemek, performans testlerini çalıştırmak için basit bir programdır. Muhtemelen paralel veritabanı oturumlarında tek bir komut dizisini tekrar tekrar yürütür ve ardından ortalama işlem oranını hesaplar.
1'i SSL olmadan ve SSL kullanarak test edin — her işlem için bağlantı kurulur:
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'i SSL olmadan ve SSL kullanarak test edin — tüm işlemler tek bir bağlantıda gerçekleştirilir:
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"Diğer ayarlar:
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/50000Test sonuçları:
SSL YOK
SSL
Her işlem için bir bağlantı kurulur
gecikme ortalaması
171.915 ms
187.695 ms
bağlantıların kurulması dahil tps
58.168112
53.278062
bağlantı kurma hariç tps
64.084546
58.725846
işlemci
%24
%28
Tüm işlemler tek bağlantıda gerçekleştirilir
gecikme ortalaması
6.722 ms
6.342 ms
bağlantıların kurulması dahil tps
1587.657278
1576.792883
bağlantı kurma hariç tps
1588.380574
1577.694766
işlemci
%17
%21
Hafif yüklerde SSL'nin etkisi ölçüm hatasıyla karşılaştırılabilir. Aktarılan veri miktarı çok büyükse durum farklı olabilir. İşlem başına bir bağlantı kurarsak (bu nadirdir, genellikle bağlantı kullanıcılar arasında paylaşılır), çok sayıda bağlantınız/bağlantı kopukluğunuz olur, etki biraz daha büyük olabilir. Yani performansın düşmesi riski olabilir ama aradaki fark koruma kullanılmayacak kadar büyük değil.
Çalışma modlarını karşılaştırdığınızda güçlü bir fark olduğunu lütfen unutmayın: aynı oturumda veya farklı oturumlarda çalışıyorsunuz. Bu anlaşılabilir bir durumdur: kaynaklar her bağlantının oluşturulmasına harcanır.
Zabbix'i güven modunda bağladığımızda, yani md5 kontrol edilmediğinde, kimlik doğrulamaya gerek olmadığında bir durum yaşadık. Daha sonra müşteri md5 kimlik doğrulama modunu etkinleştirmeyi istedi. Bu, CPU'ya ağır bir yük bindirdi ve performans düştü. Optimize etmenin yollarını aramaya başladık. Sorunun olası çözümlerinden biri ağ kısıtlaması uygulamak, DBMS için ayrı VLAN'lar yapmak, kimin nereden bağlandığını netleştirecek ayarlar eklemek ve kimlik doğrulamayı kaldırmaktır.Ayrıca kimlik doğrulamayı etkinleştirirken maliyetleri azaltmak için kimlik doğrulama ayarlarını da optimize edebilirsiniz. ancak genel olarak farklı kimlik doğrulama yöntemlerinin kullanılması performansı etkiler ve DBMS için sunucuların (donanım) bilgi işlem gücünü tasarlarken bu faktörlerin dikkate alınmasını gerektirir.
Sonuç: Bir dizi çözümde, kimlik doğrulamadaki küçük nüanslar bile projeyi büyük ölçüde etkileyebilir ve bunun yalnızca üretimde uygulandığında netleşmesi kötüdür.
Eylem denetimi
Denetim yalnızca DBMS olamaz. Denetim, farklı bölümlerde olup bitenler hakkında bilgi elde etmekle ilgilidir. Bu, bir veritabanı güvenlik duvarı veya DBMS'nin oluşturulduğu işletim sistemi olabilir.
Ticari Kurumsal düzeydeki DBMS'lerde denetim konusunda her şey yolundadır, ancak açık kaynakta - her zaman değil. İşte PostgreSQL'in özellikleri:
- varsayılan günlük - yerleşik günlük kaydı;
- extensions: pgaudit - varsayılan günlük kaydı sizin için yeterli değilse, bazı sorunları çözen ayrı ayarları kullanabilirsiniz.
Videodaki rapora ek:
"Temel bildirim günlüğü log_statement = all ile standart bir günlük kaydı özelliği tarafından sağlanabilir.
Bu, izleme ve diğer kullanımlar için kabul edilebilir ancak denetim için genellikle gerekli olan ayrıntı düzeyini sağlamaz.
Veritabanında gerçekleştirilen tüm işlemlerin bir listesinin olması yeterli değildir.
Denetçinin ilgisini çekecek spesifik ifadelerin bulunması da mümkün olmalıdır.
Standart günlük kaydı kullanıcının ne istediğini gösterirken pgAudit, veritabanı sorguyu yürüttüğünde ne olduğunun ayrıntılarına odaklanır.
Örneğin denetçi, belgelenmiş bir bakım penceresi içerisinde belirli bir tablonun oluşturulduğunu doğrulamak isteyebilir.
Bu, temel denetim ve grep ile basit bir görev gibi görünebilir, ancak size bunun gibi (kasıtlı olarak kafa karıştırıcı) bir örnek sunulsaydı ne olurdu:
$$ yap
BAŞLA
'CREATE TABLE içe aktarma' işlemini YÜRÜT || 'ant_table(id int)';
SON$$;
Standart günlük kaydı size şunu sağlayacaktır:
GÜNLÜK: bildirim: DO $$
BAŞLA
'CREATE TABLE içe aktarma' işlemini YÜRÜT || 'ant_table(id int)';
SON$$;
Tabloların dinamik olarak oluşturulduğu durumlarda ilgilenilen tabloyu bulmanın bazı kod bilgisi gerektirebileceği görülmektedir.
Sadece tablo adına göre arama yapmak tercih edileceğinden bu ideal değildir.
pgAudit'in kullanışlı olduğu yer burasıdır.
Aynı girdi için günlükte şu çıktıyı üretecektir:
DENETİM: OTURUM,33,1,FONKSİYON,YAP ,,,"YAP $$
BAŞLA
'CREATE TABLE içe aktarma' işlemini YÜRÜT || 'ant_table(id int)';
SON$$;"
DENETİM: OTURUM,33,2,DDL, TABLO OLUŞTUR, TABLO, public.önemli_tablo, TABLO OLUŞTUR önemli_tablo (id INT)
Yalnızca DO bloğu değil aynı zamanda CREATE TABLE'ın ifade türü, nesne türü ve tam adı içeren tam metni de günlüğe kaydedilir, böylece arama daha kolay hale gelir.
SELECT ve DML deyimlerini günlüğe kaydederken pgAudit, deyimde başvurulan her ilişki için ayrı bir giriş günlüğe kaydedecek şekilde yapılandırılabilir.
Belirli bir tabloya dokunan tüm ifadeleri bulmak için ayrıştırmaya gerek yoktur (). "
Bu, DBMS'nin performansını nasıl etkileyecektir?
Tam denetim etkinken testleri çalıştıralım ve PostgreSQL performansına ne olacağını görelim. Tüm parametreler için maksimum veritabanı günlük kaydını etkinleştirelim.
Yapılandırma dosyasında neredeyse hiçbir şeyi değiştirmiyoruz, en önemli şey maksimum bilgi almak için debug5 modunu açmaktır.
postgresql.conf
log_destination = 'stderr'
logging_collector = açık
log_truncate_on_rotation = açık
log_rotation_age = 1 gün
log_rotation_size = 10 MB
log_min_messages = hata ayıklama5
log_min_error_statement = hata ayıklama5
log_min_duration_deyimi = 0
debug_print_parse = açık
debug_print_rewrite = açık
debug_print_plan = açık
debug_pretty_print = açık
log_checkpoints = açık
log_connections = açık
log_disconnections = açık
log_duration = açık
log_anasistem adı = açık
log_lock_waits = açık
log_replication_commands = açık
log_temp_files = 0
log_timezone = 'Avrupa/Moskova'
1 CPU, 2,8 GHz, 2 GB RAM, 40 GB HDD parametrelerine sahip bir PostgreSQL DBMS'de şu komutları kullanarak üç yük testi gerçekleştiriyoruz:
$ 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 benchmarkTest Sonuçları:
Kayıt yok
Günlüğe kaydetme ile
Toplam veritabanı doldurma süresi
43,74 sn
53,23 sn
soygun
%24
%40
işlemci
%72
%91
Test 1 (50 bağlantı)
10 dakikadaki işlem sayısı
74169
32445
İşlem/sn
123
54
Ortalama Gecikme
405 ms
925 ms
Test 2 (150 mümkün olan 100 bağlantı)
10 dakikadaki işlem sayısı
81727
31429
İşlem/sn
136
52
Ortalama Gecikme
550 ms
1432 ms
Boyutlar hakkında
Veritabanı boyutu
2251 МБ
2262 МБ
Veritabanı günlük boyutu
0 MB
4587 MB
Sonuç olarak: tam bir denetim pek iyi değildir. Denetimden elde edilen veriler, veritabanındaki veriler kadar büyük, hatta daha fazla olacaktır. Bir DBMS ile çalışırken oluşturulan günlük kaydı miktarı, üretimde yaygın bir sorundur.
Gelelim diğer parametrelere:
- Hız pek değişmiyor: kayıt yapmadan - 43,74 saniye, kayıt yaparken - 53,23 saniye.
- Bir denetim dosyası oluşturmanız gerektiğinden RAM ve CPU performansı düşecektir. Bu durum verimlilikte de fark ediliyor.
Bağlantı sayısı arttıkça doğal olarak performans biraz düşecektir.
Denetimi olan şirketlerde durum daha da zordur:
- çok fazla veri var;
- Denetim yalnızca SIEM'deki sistem günlüğü aracılığıyla değil, aynı zamanda dosyalarda da gereklidir: sistem günlüğüne bir şey olursa, verilerin kaydedildiği veritabanına yakın bir dosya olmalıdır;
- denetim için, çok fazla yer kapladığından G/Ç disklerinde israf yapmamak için ayrı bir rafa ihtiyaç vardır;
- Bilgi güvenliği çalışanlarının her yerde GOST standartlarına ihtiyacı var, devlet kimliğine ihtiyaç duyuyorlar.
Verilere erişimi kısıtlama
Ticari DBMS'lerde ve açık kaynakta verileri korumak ve verilere erişmek için kullanılan teknolojilere bakalım.
Genel olarak ne kullanabilirsiniz:
- Prosedürlerin ve işlevlerin şifrelenmesi ve gizlenmesi (Sarmalama) - yani okunabilir kodu okunamaz hale getiren ayrı araçlar ve yardımcı programlar. Doğru, o zaman ne değiştirilemez ne de yeniden düzenlenemez. Bu yaklaşım bazen en azından DBMS tarafında gerekli olur; lisans kısıtlamalarının mantığı veya yetkilendirme mantığı, prosedür ve işlev düzeyinde tam olarak şifrelenir.
- Verilerin görünürlüğünü satırlara göre sınırlamak (RLS), farklı kullanıcıların bir tablo görmesi, ancak içindeki satırların farklı bir bileşimini görmesi, yani bir şeyin satır düzeyinde birine gösterilememesidir.
- Görüntülenen verileri düzenlemek (Maskeleme), tablonun bir sütunundaki kullanıcıların verileri veya yalnızca yıldız işaretlerini görmesidir, yani bazı kullanıcılar için bilgiler kapatılacaktır. Teknoloji, erişim düzeyine göre hangi kullanıcıya neyin gösterileceğini belirler.
- Güvenlik DBA/Uygulama DBA/DBA erişim kontrolü, daha ziyade, DBMS'nin kendisine erişimi kısıtlamakla ilgilidir, yani bilgi güvenliği çalışanları, veritabanı yöneticilerinden ve uygulama yöneticilerinden ayrılabilir. Açık kaynakta bu tür teknolojilerden çok az var, ancak ticari DBMS'lerde bunlardan çok sayıda var. Sunuculara erişimi olan çok sayıda kullanıcı olduğunda bunlara ihtiyaç vardır.
- Dosya sistemi düzeyinde dosyalara erişimi kısıtlama. Her yöneticinin yalnızca gerekli verilere erişebilmesi için dizinlere haklar ve erişim ayrıcalıkları atayabilirsiniz.
- Zorunlu erişim ve hafıza temizleme - bu teknolojiler nadiren kullanılır.
- Doğrudan DBMS'den uçtan uca şifreleme, sunucu tarafında anahtar yönetimi ile istemci tarafı şifrelemedir.
- Veri şifreleme. Örneğin sütunlu şifreleme, veritabanının tek bir sütununu şifreleyen bir mekanizma kullandığınız zamandır.
Bu, DBMS'nin performansını nasıl etkiler?
PostgreSQL'deki sütunlu şifreleme örneğine bakalım. Bir pgcrypto modülü vardır, seçilen alanları şifrelenmiş biçimde saklamanıza olanak tanır. Bu, yalnızca bazı verilerin değerli olduğu durumlarda kullanışlıdır. Şifrelenmiş alanları okumak için istemci bir şifre çözme anahtarı iletir, sunucu verilerin şifresini çözer ve istemciye geri gönderir. Anahtar olmadan hiç kimse verilerinizle hiçbir şey yapamaz.
Pgcrypto ile test edelim. Şifrelenmiş veriler ve normal verilerden oluşan bir tablo oluşturalım. Aşağıda tablo oluşturmaya yönelik komutlar verilmiştir, ilk satırda yararlı bir komut vardır - DBMS kaydıyla uzantının kendisini oluşturmak:
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'));Daha sonra her tablodan bir veri örneği oluşturmaya çalışalım ve yürütme zamanlamalarına bakalım.
Şifreleme işlevi olmayan bir tablodan seçim yapma:
psql -c "timing" -c "select * from t1 limit 1000;" "host=192.168.220.129 dbname=taskdb
user=postgres sslmode=disable" > 1.txtKronometre açık.
kimlik | metin1 | metin2
——+——-+——-
1 | 1 | 1
2 | 2 | 2
3 | 3 | 3
...
997 | 997 | 997
998 | 998 | 998
999 | 999 | 999
1000 | 1000 | 1000
(1000 satır)
Süre: 1,386 ms
Şifreleme fonksiyonlu bir tablodan seçim:
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.txtKronometre açık.
kimlik | şifresini çöz | şifresini çözmek
——+—————+————
1 | x31 | x31
2 | x32 | x32
3 | x33 | x33
...
999 | x393939 | x393939
1000 | x31303030 | x31303030
(1000 satır)
Süre: 50,203 ms
Test sonuçları:
şifreleme olmadan
Pgcrypto (şifre çözme)
Örnek 1000 satır
1,386 ms
50,203 ms
işlemci
%15
%35
soygun
+ 5%
Şifrelemenin performans üzerinde büyük etkisi vardır. Şifrelenmiş verilerin şifre çözme işlemleri (ve şifre çözme genellikle hala mantığınızın içinde yer alır) önemli miktarda kaynak gerektirdiğinden zamanlamanın arttığı görülebilir. Yani, bazı verileri içeren tüm sütunları şifreleme fikri, performansta bir düşüşle doludur.
Ancak şifreleme, tüm sorunları çözecek sihirli bir çözüm değildir. Şifrenin çözülmesi ve verinin iletilmesi işlemi sırasında şifresi çözülen veri ve şifre çözme anahtarı sunucuda bulunur. Bu nedenle anahtarlar, sistem yöneticisi gibi veritabanı sunucusuna tam erişimi olan biri tarafından ele geçirilebilir.
Tüm kullanıcılar için sütunun tamamı için bir anahtar olduğunda (hepsi için olmasa da sınırlı bir grup istemci için), bu her zaman iyi ve doğru değildir. Bu nedenle uçtan uca şifreleme yapmaya başladılar, DBMS'de istemci ve sunucu tarafındaki verileri şifreleme seçeneklerini değerlendirmeye başladılar ve aynı anahtar kasası depoları ortaya çıktı - DBMS'de anahtar yönetimi sağlayan ayrı ürünler taraf.
Ticari ve açık kaynaklı DBMS'deki güvenlik özellikleri
fonksiyonlar
Tip
Şifre politikası
Denetim
Prosedürlerin ve işlevlerin kaynak kodunun korunması
HBS
Şifreleme
Kehanet
ticari
+
+
+
+
+
MSSQL
ticari
+
+
+
+
+
ticari
+
+
+
+
uzantıları
PostgreSQL
Ücretsiz
uzantıları
uzantıları
-
+
uzantıları
MongoDb
Ücretsiz
-
+
-
-
Yalnızca MongoDB Enterprise'da mevcuttur
Tablo tam olmaktan uzak ama durum şu: Ticari ürünlerde güvenlik sorunları uzun süredir çözülüyor, açık kaynakta kural olarak güvenlik için bir tür eklenti kullanılıyor, birçok işlev eksik , bazen bir şeyler eklemeniz gerekir. Örneğin, şifre politikaları - PostgreSQL'in birçok farklı uzantısı vardır (, , , , ), şifre politikaları uygulayan, ancak bence hiçbiri yerli kurumsal segmentin tüm ihtiyaçlarını karşılamıyor.
İhtiyacınız olan şey hiçbir yerde yoksa ne yapmalısınız?? Örneğin, müşterinin ihtiyaç duyduğu işlevlere sahip olmayan belirli bir DBMS kullanmak istiyorsunuz.
Daha sonra farklı DBMS'lerle çalışan, örneğin Crypto DB veya Garda DB gibi üçüncü taraf çözümleri kullanabilirsiniz. Yerli segmentteki çözümlerden bahsediyorsak, GOST'ları açık kaynaktan daha iyi biliyorlar.
İkinci seçenek, ihtiyacınız olanı kendiniz yazmak, uygulamada veri erişimini ve şifrelemeyi prosedür düzeyinde uygulamaktır. Doğru, GOST ile daha zor olacak. Ancak genel olarak, verileri gerektiği gibi gizleyebilir, bir DBMS'ye koyabilir, daha sonra doğrudan uygulama düzeyinde geri alabilir ve gerektiğinde şifresini çözebilirsiniz. Aynı zamanda uygulamada bu algoritmaları nasıl koruyacağınızı hemen düşünün. Bize göre bu DBMS düzeyinde yapılmalıdır çünkü daha hızlı çalışacaktır.
Bu rapor ilk olarak şu tarihte sunuldu: Mail.ru Bulut Çözümleri tarafından. Bakmakdiğer performanslar ve Telegram'daki etkinlik duyurularına abone olun .
Konuyla ilgili başka ne okunmalı?:
- .
- .
Kaynak: habr.com