Firebird Veritabanı Şifrelemesi Nasıl Çalışır
(c) Alexey Kovyazin, IBSurgeon, Alex Peshkoff, Firebird Project, 2021
Makale, Berlin, Almanya’da Firebird Konferansı 2019’da düzenlenen “Veritabanı Şifreleme” çalıştayının materyallerine dayanmaktadır. Firebird veritabanı şifrelemesinin sunucu düzeyinde ve istemci tarafında nasıl çalıştığını, veritabanı şifrelemesinin nasıl yapılandırılacağını ve çeşitli uygulama türlerinden (Delphi, Java, .NET) nasıl kullanılacağını açıklar. Makaledeki örnekler IBSurgeon Firebird Encryption Framework (FEPF) tabanlıdır ancak mevcut şifreleme eklentisi uygulamalarının çoğuna uyarlanabilir.
İçindekiler:
- Neden veritabanı şifrelemeye ihtiyacımız var (ve ne zaman gerekmez)?
- Firebird veritabanı şifrelemesi sunucu tarafında nasıl çalışır
- Veritabanının hangi kısmı şifrelenir?
- Veri sayfaları ne zaman şifrelenir?
- Anahtar aktarımı nasıl korunur?
- Firebird şifrelemesi istemci tarafında nasıl çalışır
- Yerel uygulamalar
- Java uygulamaları
- .NET uygulamaları
- Kurulum ve Yapılandırma
- Şifreleme ilerlemesi nasıl takip edilir
- Özet
1. Neden veritabanı şifrelemeye ihtiyacımız var (ve ne zaman gerekmez)?
Firebird veritabanı şifrelemesi, Firebird 3.0 sürümünde (genellikle ele alınan konuyla karıştırılan aktarım protokolü şifrelemesiyle birlikte) tanıtılmıştır ve verileri yetkisiz erişimden koruma yeteneklerini büyük ölçüde artırmıştır. Ancak bu her derde deva değildir ve doğru kullanmak için güçlü ve zayıf yönlerini anlamak gerekir.
Bu makalede, Firebird uygulama geliştiricilerine veritabanı şifrelemesinin nasıl çalıştığı hakkında daha iyi bir anlayış kazandırmak için veritabanı şifrelemesinin iç işleyişini temel düzeyde ele alıyoruz.
Peki, neden veritabanı şifrelemeye ihtiyacımız var?
- Hassas/değerli verilere sahip veritabanlarını “fiziksel” hırsızlıktan korumak için. Bir saldırgan, şifrelenmiş veritabanının bir kopyasını içeren diski çalarsa veya bir şekilde veritabanı dosyasının bir kopyasını elde ederse, uygun bir anahtar olmadan verileri okumak mümkün olmayacaktır; ayrıca verileri çıkarmak için FirstAID gibi kurtarma yazılımlarını kullanmak da mümkün olmayacaktır. Elbette bu, şifreleme algoritmasına ve hesaplama gücüne bağlıdır, ancak AES256’yı kırmak çok uzun zaman veya çok pahalı hesaplama kaynakları gerektirecektir.
- Veritabanını, şifreleme anahtarları olmayan yetkisiz uygulamaların erişiminden korumak için. Örnekler:
- yetkisiz bir kişinin hassas bilgileri (örneğin, para işlemlerini) değiştirmek için bir geliştirici aracıyla doğrudan erişimi,
- iş mantığının (saklı prosedürlerin ve tetikleyicilerin metinleri) değiştirilmesi veya çalınması.
- Önceden doldurulmuş verilere sahip veritabanlarını, yetkisiz uygulamalara dışa aktarılmaktan veya bunlara erişilmekten korumak.
- Hükümetler yakın zamanda (Avrupa’da GDPR/DSVGO, Brezilya’da LGPD vb.) kişisel ve diğer hassas veriler için daha yüksek düzeyde koruma gerektiren veri koruma yasaları çıkarmıştır ve şifreleme, yeterli koruma önlemlerinden biri olarak belirtilmektedir.
Veritabanı şifrelemesi ne zaman yararlı değildir?
Bazı durumlarda veritabanı şifrelemesi yerine Firebird’ün güvenlik ve yapılandırma yeteneklerini kullanmak daha iyidir:
- Veritabanını ağ üzerinden fiziksel erişime karşı korumak için ağ erişimini yapılandırmak gerekir: yani, ağ paylaşımlı klasörleri kapatın, çünkü Firebird veritabanı dosyalarına ağ paylaşımlı erişim gerektirmez ve güvenlik izinlerini sıkılaştırın (örneğin Linux için veritabanı dosyaları yalnızca “firebird” kullanıcısı için okuma-yazma erişimine sahip olmalıdır).
- Belirli bir kullanıcı alt kümesi için belirli veritabanına erişimi kısıtlamak için daha kolay çözüm, ayrı bir güvenlik veritabanı yapılandırmak olacaktır.
- Veritabanı nesnelerine (tablolar, saklı prosedürler) erişimi kısıtlamak için Firebird güvenlik mekanizmalarını kullanmak gerekir: kullanıcılar, roller vb.
Elbette, yukarıdaki listelerin her ikisi de eksiktir, ancak veritabanı şifrelemesine ne zaman ihtiyacınız olduğu veya olmadığı konusunda size bir fikir verirler.
2. Firebird veritabanı şifrelemesi sunucu tarafında nasıl çalışır
Firebird veritabanı şifrelemesinin iç ayrıntılarına göz atalım ve sunucu kısmıyla başlayalım.
2.1. Veritabanının hangi kısmı şifrelenir?
Ele almamız gereken ilk şey, veritabanının hangi kısmının şifrelendiğidir? Muhtemelen bildiğiniz gibi, Firebird veritabanı “veritabanı sayfaları” adı verilen eşit boyutlu parçalardan oluşur. Her biri belirli bir amaca hizmet eden birkaç tür sayfa vardır.
Aşağıda ana veri türlerini gösteren şekli görebilirsiniz:

Şekil 1. Veritabanı sayfa türleri
Bazı sayfalar kullanıcı verilerini depolamak için tasarlanmıştır ve diğerleri işlemler ve sayfa envanter sayfaları gibi sistem bilgilerini depolamak için gereklidir (veritabanı sayfaları hakkında daha fazla ayrıntı burada mevcuttur).
Firebird veritabanı şifrelendiğinde, yalnızca kullanıcı verilerini içeren sayfalar şifrelenir: veri sayfaları, dizinler, üreteçler ve BLOB’lar:

Şekil 2. Yalnızca kullanıcı verilerini içeren veritabanı sayfaları şifrelenir
Lütfen, veritabanı meta verilerinin (saklı prosedürler, tablolar, görünümler, tetikleyiciler, üreteç adları vb.) şifrelemeden sorumlu motorun içinde “kullanıcı verilerinden” farklı olmadığını ve şifrelendiğini unutmayın.
Sistem sayfaları neden şifrelenmiyor? Çoğunlukla performans nedeniyle ve koruma gerektiren hassas veriler içermemeleri gerçeğinden dolayı.
Veritabanı başlık sayfası şifrelenmez, çünkü şifreleme için gereken bilgileri (örneğin, anahtar adı) içerir.
2.2. Veri sayfaları ne zaman şifrelenir?
Bir kullanıcı şifrelenmiş veritabanından SELECT yürüttüğünde, veriler şifrelenmiş dosyadan okunur ancak uygulamanın sonuç kümesi ızgarasına şifrelenmemiş biçimde ulaşır.
Bu sürecin ayrıntılarını ele alalım:

Şekil 3. Veritabanı sayfaları ne zaman şifrelenir?
Genellikle süreç, bir veritabanı dosyasından veritabanı sayfalarının bir dizi okumasıyla başlar ve bunlar İşletim Sistemi dosya önbelleğinde önbelleğe alınır.
Firebird ayrıca dosya önbelleğini atlayıp yalnızca kendi önbelleğini kullanacak şekilde yapılandırılabilir, ancak varsayılan olarak dosya önbelleği kullanılır.
Bundan sonra Firebird sayfaları okur ve bunları Firebird Sayfa önbelleğine koyar (bu, firebird.conf ve/veya databases.conf dosyasındaki DefaultDBCachePages parametresiyle veya veritabanı başlık sayfasında tanımlanır).
Ardından, önbellekteki sayfalar belirli SQL ifadesinin (örneğimizde SELECT) sonuç kümesine seçilir.
Aşağıdaki şekil ayrıntıları gösterir:

Şekil 4. Sayfalar Firebird Önbelleği ile OS dosya önbelleği arasında şifrelenir
Yani, veritabanı sayfaları OS dosya önbelleğinde şifrelenir ancak Firebird sayfa önbelleğine şifrelenmemiş olarak ulaşır ve bunun tersi de geçerlidir.
Şifreleme/şifre çözmeden sorumlu Firebird yazılımının parçası “şifreleme eklentisi” olarak adlandırılır. Eklenti uygulamalarının çoğunluğu (yazarlar tarafından bilinen) DbCrypt olarak adlandırıldığından, ona DbCrypt olarak atıfta bulunacağız.
Aşağıdaki şekilde Windows (DbCrypt.dll) ve Linux (libDbCrypt.so) için varyantları görebilirsiniz:


Şekil 5. Şifreleme eklentisi (DbCrypt) şifreleme/şifre çözme işlemini yapar
Bu resme yeterince uzun bakarsanız, bir sonraki soru oldukça hızlı ortaya çıkacaktır: DbCrypt, veritabanı sayfalarını şifrelemek/şifresini çözmek için doğru anahtarı nasıl alır?
Cevap - anahtar yönetimi için başka bir eklenti vardır.
Anahtar yönetimi için tipik ad, şifreleme eklentisi (DbCrypt) için anahtar depolama/yönetim tesisi olarak hizmet veren KeyHolder’dır. KeyHolder, DbCrypt tarafından kullanılan anahtar yönetimi için arayüzü uygular.

Şekil 6. DbCrypt ve KeyHolder
“Anahtar yönetimi” ne anlama gelir?
En basit durumda, DbCrypt anahtarları sunucudaki dosyadan okuyabilir. Dosya, “gizli” bir yerde veya bir USB bellekte saklanabilen basit bir düz metin dosyası olabilir veya şifrelenmiş bir dosya olabilir (örneğin, Windows Crypto API veya yerleşik dahili anahtarla).
Anahtar dosyası, kolaylık olması için adlandırılmış liste olarak saklanan birkaç anahtar içerebilir ve şöyle görünebilir (aşağıdaki örnek IBSurgeon Encryption Frameworknden alınmıştır):
Key=Red 0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,
Key=Green 0xab,0xd7,0x34,0x63,0xae,0x19,0x52,0x00,0xb8,0x84,0xa3,0x44,0xbd,0x11,0x9f,0x72,0xe0,0x04,0x68,0x4f,0xc4,0x89,0x3b,0x20,0x8d,0x2a,0xa7,0x07,0x32,0x3b,0x5e,0x74,
Veritabanı şifrelendiğinde, başlık sayfaları şifreleme eklentisi ve anahtarın adı hakkındaki bilgileri saklamak için şifrelenmemiş kalır ve bu bilgiyi “gstat -h veritabanıadı” komutuyla görebilirsiniz:
Database header page information:
....
Creation date Jan 11, 2017 15:12:20
Attributes force write, encrypted, plugin DBCRYPT
Variable header data:
Crypt checksum: MUB2NTJqchh9RshmP6xFAiIc2iI=
Key hash: ask88tfWbinvC6b1JvS9Mfuh47c=
Encryption key name: RED
Sweep interval: 0
*END*
DbCrypt, birkaç veritabanı ve birkaç anahtar için sayfaları işleyebilir:

Şekil 7. Aynı sunucuda (yani Firebird örneğinde) birden çok veritabanı için birden çok anahtar
Doğru anahtarı seçme
Geliştiriciler sıklıkla “Eklenti hangi anahtarın hangi veritabanı için olduğunu nasıl tanır?” sorusunu sorarlar. Cevap oldukça basittir: veritabanının başlık sayfasında saklanan anahtar adıyla.
Daha az sıklıkla, ancak yine de önemli bir soru - başlıkta kaydedildiği gibi anahtar adı aynıysa ancak anahtar değeri farklıysa ne olur? Yanlış anahtar nedeniyle sayfa okuma hatalarını önlemek için, DbCrypt eklentisi başlıkta şifrelenmiş test dizisini (0…F rakamları) saklar ve ardından anahtar etkinleştirildiğinde, eklenti örnek verileri bir anahtarla şifrelemeye çalışır ve karmasını saklanan sonuçla karşılaştırarak iletilen anahtar değerinin bu belirli veritabanı için gerçekten doğru olduğundan emin olur.
Şifreleme eklentisinin anahtarları doğrudan okuduğu yaklaşım, şifrelemeyi şeffaf bir şekilde uyguladığı için hata ayıklama, performans testleri vb. için basit ve faydalıdır: yani istemci uygulamaları ve geliştirici araçları veritabanının şifrelendiğini bilmez.
Ancak gerçekte, uygulamaların veritabanına erişimini kısıtlamamız gerekir: yalnızca anahtara sahip istemci uygulaması şifrelenmiş veritabanına bağlanabilmelidir.
Bunun için, anahtarı istemci uygulamasından (genellikle başka bir bilgisayarda bulunan) Firebird ağ protokolü aracılığıyla almak için KeyHolder eklentisine ihtiyacımız var.
2.3. Anahtar aktarımı nasıl korunur?
Müşterinin yetkili uygulamaları atlayarak şifrelenmiş veritabanına doğrudan erişim elde etmeye karar verdiği durumda veritabanını korumak isteyebiliriz (birçok satıcı, verilere doğrudan erişimi, salt okunur veya okuma-yazma, kısıtlamak ister).
Bu, bir saldırganın sunucuya erişimi olduğu ancak anahtarlara sahip olmadığı duruma eşdeğerdir.
Sunucu tarafında anahtarları ele geçirmek için şu saldırı senaryolarını ele alalım:
- Saldırgan sahte şifreleme eklentisini (DBCrypt.dll) oluşturup sunucuya yerleştirdiğinde ve KeyHolder anahtarı ilettiğinde, sahte DbCrypt anahtarın dökümünü alır:

Şekil 8. Sahte DbCrypt.dll ile saldırı
- Saldırgan sahte firebird.exe dosyası oluşturup onunla döküm aldığında:

Şekil 9. Sahte firebird.exe ile saldırı
Bu tür saldırılardan korunmak için, şifreleme ve anahtar yönetimi eklentilerinin iyi bir uygulamasının anahtar değişimini koruması gerekir.
Anahtar değişimi, açık/gizli anahtar çifti ile asimetrik şifreleme kullanılarak korunabilir.
Bu anahtarlar, derleme süreci sırasında üretilir ve belirli şifreleme ve anahtar yönetimi eklentisi çifti için yerleşik olarak gelir. En iyi koruma için, özel olarak oluşturulmuş DbCrypt/KeyHolder çiftlerinin kullanılması gerekir.

DbCrypt ve KeyHolder anahtarları değiş tokuş ederken şu protokolü kullanır (basitleştirilmiştir, ancak fikir açıktır, sanırım):
DbCrypt → KeyHolder:
Bu Tuz ile Veritabanı Anahtarını Bana Ver
KeyHolder:
DbKey'i, DbCrypt'ten gelen tuzu kullanarak Açık Anahtar ile Şifreler
Şifrelenmiş DbKey'i DbCrypt'e Aktarır
DbCrypt:
DbKey'i Gizli Anahtar ile Çözer
Tuz doğruluğunu doğrular
Çalışmaya Hazır
Aşağı yukarı aynı protokol, KeyHolder örnekleri arasında anahtar değişimi ve istemci uygulama ile KeyHolder arasındaki anahtar değişimi için de kullanılır.
Aktarılan anahtarların şifrelenmesi ve doğruluğunun eklenti uygulamasına bağlı olduğunu lütfen unutmayın; Firebird motoru yalnızca temel düşük seviyeli aktarım hizmeti sağlar: “bu eklenti örneğinden şu eklenti örneğine N bayt gönder”.
Şifrelemenin sunucu tarafı bölümü için özet
- Şifreleme/şifre çözme, veritabanı şifreleme eklentisi (DbCrypt) tarafından, İşletim Sistemi dosya önbelleği ile Firebird sayfa önbelleği arasındaki veri alışverişi sırasında sayfa sayfa yapılır
- Anahtar yönetimi, DbCrypt anahtarları doğrudan okuduğunda basit bir şekilde uygulanabilir, ancak genellikle anahtar yönetimi eklentisi (KeyHolder) ile yapılır
Şimdi istemci uygulamaların şifrelenmiş veritabanlarıyla nasıl çalıştığını keşfedelim.
3. Firebird şifrelemesi istemci tarafında nasıl çalışır
3.1. Yerel uygulamalar
Bir istemci uygulamanın şifrelenmiş veritabanına bağlandığında ne olduğunu anlamak için, yerel uygulamalar için şifrelenmemiş veritabanına normal bağlantı sürecini ele alalım.
Lütfen not edin: buradan itibaren “yerel”, böyle bir uygulamanın fbclient.dll kullanarak sunucuyla ağ bağlantısı kurduğu anlamına gelir; genellikle böyle bir uygulama Delphi, C++, PHP ile oluşturulur. Yerel uygulamaların aksine, Java ve .NET protokolün kendi sürümlerini uygular, bunlar aşağıda ele alınacaktır.
Bağlantı süreci:
- İstemci uygulama istemci kütüphanesini yükler
- fbclient.dll - yerel Windows uygulamaları
- libfbclient.so - yerel Linux uygulamaları
- İstemci uygulama bir bağlantı başlatır, gönderir
- Kullanıcı adı, örn. SYSDBA
- Parola, örn. masterkey
- Veritabanının yolu/takma adı
Şifrelenmiş bir veritabanı durumunda, ek bir adım gerekir: şifreleme anahtarının adını ve değerini iletmek gerekir.
Anahtarın geçişinin normal bağlantıdan önce yapılması gerektiğini söylemek önemlidir; çünkü veritabanı sahibi adı, karakter seti vb. dahil olmak üzere meta veri içeren veri sayfaları şifrelenmiştir.
Bu bizi şu sonuçlara götürür:
- Normal bağlantıdan önce anahtarı iletmek için ek bir ağ turu gerekir
- Anahtarın istemci uygulamadan Firebird’e aktarılması, asimetrik şifreleme kullanımı ve geri çağırma arayüzünün uygulanmasıyla kodlama gerektirir; bu oldukça karmaşık olabilir. Bu görevi basitleştirmek için, eklenti satıcıları bağlantı için örnek kod sağlar veya IBSurgeon eklenti çerçevesinde olduğu gibi, anahtarları istemci uygulamadan aktarmak için kullanımı kolay uygun bir arayüz uygulayan ek fbcrypt.dll/libfbcrypt.so kütüphanesini oluşturur.
Şifrelenmiş veritabanına yerel bir uygulamayı (fbclient.dll kullanan) bağlamak için 3 çağrı yapılmalıdır. Aşağıda bir Delphi örneği verilmiştir (basitleştirilmiş, hata işleme olmadan):
BeforeConnect olay işleyicisinde:
fbcrypt_init(PAnsiChar(‘C:\Firebird30.bclient.dll’));
fbcrypt_key(‘RED’, ‘0xec,0xa1,0x52,0xf6,...’));
fbcrypt_callback(nil);
// Sonra her zamanki gibi bağlan
Database1.Active:=True;
Aşağıdaki şekilde, yerel uygulamada şifrelenmiş bir veritabanına bağlantı sürecinin genel görünümünü görebilirsiniz:

Şekil 10. Yerel uygulamalar için şifrelenmiş veritabanına bağlantı süreci
Çok iş parçacıklı istemci uygulamaları durumunda iş parçacığı güvenliği ne olacak?
Çok iş parçacıklı istemci uygulamalarının uygulanmasının bazı genel noktalarını hatırlatayım.
Firebird 2.5’ten bu yana, uygulama içindeki birden fazla iş parçacığı, veritabanına tek bir bağlantıyı güvenle kullanabilir, çünkü gerekli tüm senkronizasyon fbclient.dll içinde yapılır.
Ancak, bu durumda iş parçacıkları bağlantıyla yalnızca tek tek çalışabilir.
Bu, veritabanıyla yüksek performanslı veri alışverişi gerektirmeyen uygulamalar için uygundur - bir iş parçacığı başka bir SQL yürütürken diğer iş parçacığından SQL sorgusu yürütmek için beklemek sorun değilse, 1 bağlantının birden fazla iş parçacığı arasında paylaşıldığı basit modeli kullanmak daha kolaydır.
Uygulama SQL sorgularını paralel olarak yürütmeyi gerektiriyorsa (yani tam ölçekli bir istemci uygulamasıysa), her bağlantı için ayrı bir iş parçacığı kullanmak daha iyidir.
Şifrelenmiş veritabanlarına bağlantılar için anahtar değişimi durumu biraz daha karmaşıktır.
Her bağlantıda, istemci kütüphanesi anahtarları istemciden aktarır, ancak bu doğrudan istemci uygulamasındaki iş parçacıklarıyla ilgili değildir; durum kullanılan API’ye bağlıdır.
Bildiğiniz gibi, Firebird istemci kütüphanesi 3.0’dan bu yana 2 tür API sunar: sağlayıcı kavramına dayalı yeni Nesne Yönelimli API ve eski Firebird sürücüleriyle uyumluluğu korumak için bir geçici çözüm olarak uygulanan eski isc_ API.
Yeni nesne yönelimli istemci API kullanılıyorsa, sağlayıcıyı oluşturmak, gerekli anahtarlarla beslemek ve ardından yeni bağlantılar için kullanmak yeterlidir.
isc_ istemci API kullanılıyorsa, her bağlantı için istemci kütüphanesi, son kullanıcı tarafından doğrudan görülemeyen veya erişilemeyen kendi geçici sağlayıcısını oluşturur.
Bu durumda, anahtar tam olarak isc_attach_database çağrısının yapıldığı iş parçacığından aktarılır ve bu anahtarı saklamak için iş parçacığı yerel depolaması kullanılır.
Pratikte, neredeyse tüm istemci kütüphaneleri isc_ API kullandığından (şu anda popüler sürücüler arasında yalnızca Python sürücüsü OO API kullanır), şifrelenmiş veritabanına bağlanan her iş parçacığında fb_database_crypt_callback() çağrısını yapmak gerekir.
Anahtar aktarım çağrıları (FEPF örneğindeki fbcrypt.dll çağrıları) bağlantıdan önce, bağlantının kurulacağı aynı iş parçacığında yapılmalıdır.
Birçok veritabanıyla çalışırken (örneğin, birçok istemci veritabanına sahip SaaS web sunucusu), her fbcrypt_key() çağrısının, geçerli bağlantıyla ilişkili KeyHolder deposuna bir anahtar eklediğini hatırlamak önemlidir.
Anahtar değerleri bağlantıdan önce ayarlanmalıdır; bağlantıdan sonra anahtar değeri değiştirilemez.
Bağlantı kesme durumunda, anahtarlar kaldırılmaz; fbcrypt.dll kaldırılana kadar bellekte tutulurlar.
3.2. Java uygulamaları
Java sürücüsü (JayBird), Firebird bağlantı protokolünün kendi uygulamasına (saf Java’da) sahiptir. Jaybird 4 (ve 3.0.4+), sürüm 13 protokolünün saf Java uygulamasına Firebird 3 veritabanı şifreleme geri çağrıları için destek ekler.
Jaybird 4 Readme dosyasından:
" Mevcut uygulama basittir ve yalnızca bir bağlantı özelliğinden statik bir değerle yanıt vermeyi destekler. Veritabanı şifrelemesi için statik bir değer yanıtının çok güvenli olmadığını unutmayın; bu kolayca tekrar saldırılarına veya istenmeyen anahtar ifşasına yol açabilir.
Jaybird’in gelecek sürümleri (muhtemelen 5), daha karmaşık bir geri çağrı gerektiren veritabanı şifreleme eklentileri için eklenti desteği sunacaktır."
Pratikte bu, şifreleme geri çağrısı için değeri (normalde bir anahtar adı ve anahtar-değer çiftidir) dbCryptConfig bağlantı özelliğinde ayarlamamız gerektiği anlamına gelir.
Örneğin:
edConnectionString.setText("jdbc:firebirdsql://localhost/g:/Databases/ODS12/crypt.fdb?lc_ctype=utf8&dbCryptConfig=MyKey:0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,");
Ayrıca base64’te dize belirtmek de mümkündür - readme dosyasından:
" base64:: önekli dizeler, dizenin geri kalanı baytlara base64 olarak çözülür.
= dolgu karakterleri isteğe bağlıdır, ancak mevcut olduklarında geçerli olmalıdırlar (yani dolgu kullanıyorsanız, uzunluk için doğru sayıda dolgu karakteri kullanmalısınız).
Base64 kodlu değer + içerdiğinde, JDBC URL’sinde %2B olarak kaçış yapılmalıdır. Jaybird 3 ile geriye dönük uyumluluk için, base64’ün URL-güvenli varyantına geçemeyiz."
IBSurgeon anahtar yönetimi eklentisinin uygulamasında, anahtarın bu şekilde iletilmesi az çok güvensiz olarak kabul edilir: ağ protokolü şifrelemesi etkin değilse ( bu arada, etkinleştirmek için firebird.conf dosyasında WireCrypt=Required ayarlayın ve eski kimlik doğrulamayı kullanmayın), anahtar WireShark gibi bir ağ trafiği analizörüyle kolayca tespit edilebilir; bu nedenle, anahtarların bu şekilde iletilmesini etkinleştirmek için, IBSurgeon anahtar yönetimi eklentisinin KeyHolder.conf dosyasında UnsafeClient=true ayarlamak gerekir.
3.3 .NET uygulamaları
Firebird.NET sağlayıcısı, şifrelenmiş veritabanları için benzer bir anahtar değişimi şeması uygular ve ayrıca FEPF’de KeyHolder.conf dosyasında UnsafeClient=true parametresinin ayarlanmasını gerektirir.
Şifrelenmiş veritabanları için .NET bağlantı dizesi örneği:
string connectionString =
"User=SYSDBA;" +
"Password=masterkey;" +
"Database=G:\\Databases\\ODS12.RYPT.FDB;" +
"DataSource=localhost;" +
"Port=3053;" +
"Dialect=3;" +
"Charset=NONE;" +
"Role=;" +
"Connection lifetime=15;" +
"Pooling=true;" +
"MinPoolSize=0;" +
"MaxPoolSize=50;" +
"Packet Size=8192;" +
"ServerType=0;" +
"cryptkey = TXlLZXk6MHhlYywweG…...;";
Şifreleme anahtarının yerel uygulamalar ve JayBird örneğinden farklı göründüğünü fark edebilirsiniz; bunun nedeni Base64 dönüşümünün sonucu olmasıdır; bu nedenle .NET veya Java uygulaması için anahtar elde etmek için şu dizeden base64 hesaplamak gerekir:
“MyKey:0xec,0xa1,0x52,0xf6,0x4d,0x27,0xda,0x93,0x53,0xe5,0x48,0x86,0xb9,0x7d,0xe2,0x8f,0x3b,0xfa,0xb7,0x91,0x22,0x5b,0x59,0x15,0x82,0x35,0xf5,0x30,0x1f,0x04,0xdc,0x75,”
ve bağlantı dizesinin sonunda “;” ile “cryptkey=xxx;” parametresi olarak kullanın.
4. Kurulum ve Yapılandırma
Veritabanı şifreleme ve anahtar yönetimi eklentisinin kullanılmasını etkinleştirmek için, Firebird yapılandırma dosyası firebird.conf içinde şifreleme eklentisinin adını belirtmek gerekir:
KeyHolderPlugin = KeyHolder
Veya alternatif olarak, databases.conf içinde, şifrelenmiş veritabanının takma adı için:
myencrypted = C:\Temp\EMPLOYEE30.MPLOYEE30.FDB { KeyHolderPlugin = KeyHolder }
Ardından, eklenti için gereken tüm dosyaların sunucuda olduğunu kontrol etmek gerekir.
Aşağıdaki örnek IBSurgeon’un FEPF’i içindir, ancak diğer eklentiler az çok benzerdir:
%FirebirdFolder$\plugins klasöründe
• DbCrypt.dll
• DbCrypt.conf
• KeyHolder.dll
• KeyHolder.conf - yalnızca hata ayıklama modu için!
%FirebirdFolder$ klasöründe
• fbcrypt.dll
• libcrypto-1_1-x64.dll
• libssl-1_1-x64.dll
• firebird.msg
Bunun ardından, sunucuda test şifrelemesini gerçekleştirebiliriz. Bunun için isql’de:
isql.exe localhost:C:\Temp\EMPLOYEE30.MPLOYEE30.FDB -user SYSDBA -pass masterkey
SQL>alter database encrypt with dbcrypt key red;
SQL> show database;
Database: localhost:C:\Temp\EMPLOYEE30.MPLOYEE30.FDB
….
ODS = 12.0
Database encrypted
Default Character set: NONE
Linux kullanıyorsanız, büyük/küçük harf duyarlılığının önemli olduğunu unutmayın; bu nedenle komut şu şekilde olacaktır:
alter database encrypt with "DbCrypt" key Red;
Şimdi, şifrelenmiş veritabanına istemci erişimini test edebiliriz. Bunun için KeyHolder.conf yapılandırma dosyasını kaldıracak (veya yeniden adlandıracak ya da düzenleyeceğiz) ve basit test uygulamasıyla şifrelenmiş veritabanına bağlanmayı deneyeceğiz.
Bunun için, istemci uygulamasının bulunduğu klasöre aşağıdaki dosyaları koymalıyız:
- FEPF adresindeki demo uygulaması - CryptTest.exe (32bit)
- Zorunlu dosyalar:
- fbclient.dll
- fbcrypt.dll
- libcrypto-1.1.dll
- libssl-1.1-x64.dll
- İsteğe bağlı dosyalar:
- firebird.conf
- plugins klasöründe
- ◦ KeyHolder.conf
- ◦ keyhodler.dll
Anahtar yönetimi eklentilerinin bazı uygulamalarında, istemci yazılımında değişiklik yapmadan anahtarları istemci kütüphanesine (fbclient.dll) yüklemek mümkündür.
Bu, Firebird geliştirici araçlarının (Firebird SQL Studio, DatabaseWorkbench, IBExpert, FlameRobin, RedExpert vb. gibi) şeffaf çalışmasını ve Firebird komut satırı araçlarının (gfix.exe, nbackup.exe vb.) şeffaf kullanımını sağlar.
5. Şifreleme ilerlemesi nasıl takip edilir
Firebird, veritabanını yalnızca aktif bağlantılar olduğunda şifreler. Şifreleme işlemi ayrı bir paralel iş parçacığında çalışır ve büyük veritabanları için tam şifreleme önemli zaman alabilir.
Şifreleme sürecini takip etmek için MON$ üzerinden SQL sorgusu çalıştırın:
select mon$crypt_page * 100.0 / mon$pages as Percent from mon$database;
commit;
veya özel anahtarla gstat aracını çalıştırın:
gstat -e dbname
Database "D:\ENCDB\TESTENCRYPT.FDB"
Gstat execution time Tue Mar 16 11:45:11 2021
Database header page information:
Flags 0
Generation 10697
System Change Number 3
Page size 8192
ODS version 12.0
Oldest transaction 7053
Oldest active 7054
Oldest snapshot 7054
Next transaction 7054
Sequence number 0
Next attachment ID 17834
Implementation HW=Intel/i386 little-endian OS=Windows CC=MSVC
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Oct 9, 2019 6:42:31
Attributes encrypted, plugin DBCRYPT
Variable header data:
Database backup GUID: {866B4967-ED58-427E-A481-DB9206CEA2ED}
Crypt checksum: MUB2NTJqchh9RshmP6xFAiIc2iI=
Key hash: ask88tfWbinvC6b1JvS9Mfuh47c=
Encryption key name: RED
Database GUID: {323FE494-1771-4608-E99D-C1B69C84578B}
*END*
Data pages: total 105, encrypted 105, non-crypted 0
Index pages: total 95, encrypted 95, non-crypted 0
Blob pages: total 0, encrypted 0, non-crypted 0
Generator pages: total 1, encrypted 1, non-crypted 0
Gstat completion time Tue Mar 16 11:45:11 2021
Lütfen gstat çalıştırmanın uzun sürebileceğini unutmayın.
6. Özet
- Firebird veritabanı şifrelemesi, veritabanlarındaki bilgileri yetkisiz erişime karşı korumak için güçlü bir özelliktir.
- Şifreleme işlemi, sunucu tarafında dinamik bir kütüphane gerektirir - şifreleme eklentisi (genellikle DbCrypt olarak adlandırılır) ve çoğu durumda anahtar yönetimi eklentisi (genellikle KeyHolder olarak adlandırılır).
- DbCrypt ve KeyHolder eklentilerinin güvenli ve güvenilir bir şekilde uygulanması, en yaygın saldırı türleri göz önünde bulundurularak yapılmalıdır.
- Şifrelenmiş veritabanıyla çalışmak için istemci uygulamalarının şifreleme anahtarını aktarması gerekir.
- Şifreleme eklentisinin sunucu tarafında kurulumu ve yapılandırılması basittir; firebird.conf/databases.conf dosyasında 1 parametre ve birkaç dosya gerektirir.
- Şifreleme işlemi uzun sürebilir, ayrı bir arka plan iş parçacığında yapılır; ilerleme MON$ çağrısı veya gstat ile takip edilebilir.
Sırada ne var?
Firebird veritabanı şifrelemesinin ayrıntılı performans testi üzerinde çalışıyoruz. Genel olarak performans %4-8 daha düşüktür, ancak bu donanıma ve Firebird ayarlarına bağlıdır. Bizi izlemeye devam edin!
Bize ulaşın:
Önerilerinizi, yazım hatalarını, hataları vb. ve tüm sorularınızı e-posta ile gönderin: [email protected]