Jak funguje šifrování databáze Firebird

(c) Alexey Kovyazin, IBSurgeon, Alex Peshkoff, Firebird Project, 2021

Článek je založen na materiálech z workshopu „Šifrování databází“ na konferenci Firebird Conference 2019 v Berlíně v Německu. Popisuje, jak funguje šifrování databází Firebird na úrovni serveru, na straně klienta, jak nakonfigurovat šifrování databáze a jak jej používat z různých typů aplikací (Delphi, Java, .NET). Příklady v článku jsou založeny na IBSurgeon Firebird Encryption Framework (FEPF), ale lze je přizpůsobit většině v současnosti dostupných implementací šifrovacích pluginů.

Obsah:

1. Proč potřebujeme šifrování databází (a kdy ne)?
2. Jak funguje šifrování databází Firebird na straně serveru
3. Která část databáze je šifrována?
4. Kdy jsou datové stránky šifrovány?
5. Jak chránit přenos klíčů?
6. Jak funguje šifrování Firebird na straně klienta
7. Nativní aplikace
8. Java aplikace
9. .NET aplikace
10. Instalace a konfigurace
11. Jak sledovat průběh šifrování
12. Shrnutí

1. Proč potřebujeme šifrování databází (a kdy ne)?

Šifrování databází Firebird bylo představeno ve verzi Firebird 3.0 (spolu se šifrováním přenosového protokolu, které je často zaměňováno s diskutovaným tématem) a výrazně rozšířilo možnosti ochrany dat před neoprávněným přístupem. Není to však všelék a je nutné pochopit jeho silné a slabé stránky, abychom jej mohli správně používat.

V tomto článku se zabýváme vnitřními mechanismy šifrování databází na základní úrovni, abychom vývojářům aplikací Firebird poskytli lepší pochopení toho, jak šifrování databází funguje.

Takže, proč potřebujeme šifrování databází?

1. K ochraně databází s citlivými/cennými daty před „fyzickou“ krádeží. Pokud vetřelec ukradne disk s kopií šifrované databáze nebo jinak získá kopii databázového souboru, nebude možné z ní bez příslušného klíče číst data, stejně jako nebude možné použít software pro obnovu, jako je FirstAID, k extrakci dat. Samozřejmě záleží na šifrovacím algoritmu a výpočetním výkonu, ale prolomení AES256 bude vyžadovat příliš dlouhou dobu nebo příliš drahé výpočetní zdroje.
2. K ochraně databáze před přístupem z neautorizovaných aplikací bez šifrovacích klíčů. Příklady zahrnují:
   • přímý přístup vývojářským nástrojem neoprávněnou osobou ke změně citlivých informací (např. finančních transakcí),
   • změnu nebo krádež business logiky (textů uložených procedur a triggerů).
3. Ochrana databází s předvyplněnými daty před exportem do neautorizovaných aplikací nebo přístupem z nich.
4. Vlády nedávno zavedly zákony na ochranu dat (GDPR/DSVGO v Evropě, LGPD v Brazílii atd.), které mimo jiné vyžadují vyšší úroveň ochrany osobních a jiných citlivých údajů, a šifrování je zmíněno jako jedno z adekvátních ochranných opatření.

Kdy šifrování databází není užitečné?

V některých případech je lepší použít bezpečnostní a konfigurační možnosti Firebirdu místo šifrování databáze:

• K ochraně databáze před fyzickým přístupem přes síť je nutné nakonfigurovat síťový přístup: tj. zavřít síťové sdílené složky, protože Firebird nevyžaduje síťový sdílený přístup k databázovým souborům, a zpřísnit bezpečnostní oprávnění (např. pro Linux musí mít databázové soubory oprávnění čtení/zápis pouze pro uživatele „firebird“).
• K omezení přístupu ke konkrétní databázi pro konkrétní podmnožinu uživatelů bude jednodušším řešením nakonfigurovat samostatnou bezpečnostní databázi.
• K omezení přístupu k databázovým objektům (tabulky, uložené procedury) je nutné použít bezpečnostní mechanismy Firebirdu: uživatele, role atd.

Samozřejmě oba výše uvedené seznamy jsou neúplné, ale dávají vám určitou představu o tom, kdy šifrování databáze potřebujete nebo nepotřebujete.

2. Jak funguje šifrování databází Firebird na straně serveru

Projděme si vnitřní detaily šifrování databází Firebird a začněme částí serveru.

2.1. Která část databáze je šifrována?

První věc, kterou musíme zvážit, je, která část databáze je šifrována? Jak pravděpodobně víte, databáze Firebird se skládá z částí stejné velikosti, nazývaných „databázové stránky“. Existuje několik typů takových stránek, přičemž každý typ slouží specifickému účelu.

Níže vidíte obrázek s hlavními typy dat:

Obrázek 1. Typy databázových stránek

Některé stránky jsou navrženy pro ukládání uživatelských dat a jiné jsou potřebné pro ukládání systémových informací, jako jsou transakce a stránky inventáře stránek (více podrobností o databázových stránkách je k dispozici zde).

Když je databáze Firebird šifrována, šifrují se pouze stránky s uživatelskými daty: datové stránky, indexy, generátory a BLOBy:

Obrázek 2. Šifrují se pouze databázové stránky s uživatelskými daty

Vezměte prosím na vědomí, že databázová metadata (uložené procedury, tabulky, pohledy, triggery, názvy generátorů atd.) se neliší od „uživatelských dat“ v rámci části enginu odpovědné za šifrování a jsou šifrována.

Proč nejsou systémové stránky šifrovány? Především z důvodu výkonu a kvůli skutečnosti, že neobsahují citlivá data vyžadující ochranu.

Hlavičková stránka databáze není šifrována, protože obsahuje informace potřebné pro šifrování (například název klíče).

2.2. Kdy jsou datové stránky šifrovány?

Když uživatel provede SELECT ze šifrované databáze, data jsou čtena ze šifrovaného souboru, ale do mřížky aplikace s výsledkovou sadou dorazí v nešifrované podobě.

Podívejme se na podrobnosti tohoto procesu:

Obrázek 3. Kdy jsou databázové stránky šifrovány?

Obvykle proces začíná sérií čtení databázových stránek z databázového souboru a ty jsou ukládány do mezipaměti souborů operačního systému.

Firebird lze také nakonfigurovat tak, aby obcházel mezipaměť souborů a používal pouze vlastní mezipaměť, ale ve výchozím nastavení se mezipaměť souborů používá.

Poté Firebird čte stránky a ukládá je do mezipaměti stránek Firebirdu (je definována parametrem DefaultDBCachePages v firebird.conf a/nebo databases.conf nebo na hlavičkové stránce databáze).

Poté jsou stránky z mezipaměti vybírány do výsledkové sady konkrétního příkazu SQL (SELECT v našem příkladu).

Obrázek níže ukazuje podrobnosti:

Obrázek 4. Stránky jsou šifrovány mezi mezipamětí Firebirdu a mezipamětí souborů OS

Takže databázové stránky jsou šifrovány v mezipaměti souborů OS, ale do mezipaměti stránek Firebirdu dorazí nešifrované a naopak.

Část softwaru Firebird odpovědná za šifrování/dešifrování se nazývá „šifrovací plugin“. Protože většina implementací pluginů (známých autorům) se nazývá DbCrypt, budeme se na něj odkazovat jako na DbCrypt.

Na obrázku níže vidíte varianty pro Windows (DbCrypt.dll) a Linux (libDbCrypt.so):

Obrázek 5. Šifrovací plugin (DbCrypt) provádí šifrování/dešifrování

Pokud se na tento obrázek podíváte dostatečně dlouho, další otázka se objeví poměrně rychle: jak DbCrypt získá správný klíč k šifrování/dešifrování databázových stránek?

Odpověď - existuje další plugin pro správu klíčů.

Typický název pro správu klíčů je KeyHolder, který slouží jako úložiště/správa klíčů pro šifrovací plugin (DbCrypt). KeyHolder implementuje rozhraní pro správu klíčů, které používá DbCrypt.

Obrázek 6. DbCrypt a KeyHolder

Co znamená „správa klíčů“?

V nejjednodušším případě může DbCrypt číst klíče ze souboru na serveru. Soubor může být jednoduchý textový soubor, který může být skryt na „tajném“ místě nebo na USB flash disku, nebo může být šifrovaný soubor (např. pomocí Windows Crypto API nebo s vestavěným interním klíčem).

Soubor klíčů může obsahovat několik klíčů, uložených pro pohodlí jako pojmenovaný seznam, a může vypadat takto (příklad níže je převzat z rámce šifrovacího pluginu IBSurgeon):

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,

Když je databáze šifrována, její hlavičkové stránky zůstávají nešifrované, aby ukládaly informace o šifrovacím pluginu a názvu klíče, a tyto informace můžete vidět příkazem „gstat -h název_databáze“:

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 může zpracovávat stránky pro několik databází a několik klíčů:

Obrázek 7. Více klíčů pro více databází na stejném serveru (tj. instanci Firebirdu)

Výběr správného klíče

Vývojáři se často ptají: „Jak plugin pozná, který klíč patří které databázi?“ Odpověď je poměrně jednoduchá: podle názvu klíče, který je uložen na hlavičkové stránce databáze.

Méně častá, ale stále důležitá otázka - co když bude název klíče tak, jak je zaznamenán v hlavičce, ale hodnota klíče bude jiná? Aby se zabránilo chybám čtení stránek kvůli nesprávnému klíči, ukládá plugin DbCrypt na hlavičku šifrovanou testovací sekvenci (číslice 0…F), a když je klíč aktivován, plugin se pokusí zašifrovat vzorová data tímto klíčem a porovnat jejich hash s uloženým výsledkem, aby zajistil, že předaná hodnota klíče je skutečně správná pro tuto konkrétní databázi.

Přístup, kdy šifrovací plugin čte klíče přímo, je jednoduchý a výhodný pro ladění, testy výkonu atd., protože implementuje šifrování transparentním způsobem: tj. klientské aplikace a vývojářské nástroje nevědí, že je databáze šifrována.

Ve skutečnosti však potřebujeme omezit přístup aplikací k databázi: pouze klientská aplikace, která má klíč, by se měla být schopna připojit k šifrované databázi.

K tomu potřebujeme plugin KeyHolder, abychom získali klíč od klientské aplikace (která je obvykle na jiném počítači) prostřednictvím síťového protokolu Firebirdu.

2.3. Jak chránit přenos klíčů?

Je možné, že chceme chránit databázi v situaci, kdy se zákazník rozhodne získat přímý přístup k šifrované databázi, obcházeje autorizované aplikace (mnoho dodavatelů chce omezit data před přímým přístupem, ať už pouze pro čtení nebo pro čtení a zápis).

To je ekvivalentní situaci, kdy má vetřelec přístup k serveru, ale nemá klíče.

Zvažme následující scénáře útoku za účelem zachycení klíčů na straně serveru:

1. Když vetřelec vytvoří falešný šifrovací plugin (DBCrypt.dll) a umístí jej na server, a když KeyHolder předá klíč, falešný DbCrypt provede dump klíče:

Obrázek 8. Útok s falešným DbCrypt.dll

2. Když vetřelec vytvoří falešný soubor firebird.exe a provede s ním dump:

Obrázek 9. Útok s falešným firebird.exe

Abychom se proti takovým útokům ochránili, musí dobrá implementace šifrovacích pluginů a pluginů pro správu klíčů chránit výměnu klíčů.

Výměna klíčů může být chráněna asymetrickým šifrováním s párem veřejného/soukromého klíče.

Tyto klíče jsou generovány během procesu sestavení a jsou vestavěné pro konkrétní pár šifrovacích pluginů a pluginů pro správu klíčů. Pro nejlepší ochranu je nutné použít speciálně sestavené páry DbCrypt/KeyHolder.

Když si DbCrypt a KeyHolder vyměňují klíče, používají následující protokol (je zjednodušený, ale myšlenka je jasná):

DbCrypt → KeyHolder:
	Dej mi databázový klíč s touto solí
KeyHolder:
	Zašifruje DbKey veřejným klíčem pomocí soli z DbCrypt
	Přenese zašifrovaný DbKey do DbCrypt
DbCrypt:
	Dešifruje DbKey soukromým klíčem
	Ověří správnost soli
	Připraven k práci

Více či méně stejný protokol se používá pro výměnu klíčů mezi instancemi KeyHolder a pro výměnu klíčů mezi klientskou aplikací a KeyHolder.

Upozorňujeme, že šifrování a správnost přenášených klíčů závisí na implementaci pluginu, engine Firebird poskytuje pouze základní službu přenosu na nízké úrovni „pošli N bajtů z této instance pluginu do této instance pluginu“.

Shrnutí pro serverovou část šifrování

• Šifrování/dešifrování provádí databázový šifrovací plugin (DbCrypt), stránku po stránce, během výměny dat mezi souborovou cache operačního systému a cache stránek Firebirdu
• Správa klíčů může být implementována jednoduchým způsobem, když DbCrypt čte klíče přímo, ale obvykle se to provádí pomocí pluginu pro správu klíčů (KeyHolder)

Nyní zjistíme, jak klientské aplikace pracují se šifrovanými databázemi.

3. Jak funguje šifrování Firebirdu na straně klienta

3.1. Nativní aplikace

Abychom pochopili, co se děje, když se klientská aplikace připojí k šifrované databázi, zvažme běžný proces připojení k nešifrované databázi pro nativní aplikace.

Upozorňujeme: od tohoto místa dále „nativní“ znamená, že taková aplikace navazuje síťové spojení se serverem pomocí fbclient.dll, obvykle je taková aplikace postavena v Delphi, C++, PHP. Na rozdíl od nativních aplikací implementují Java a .NET vlastní verzi protokolu, budou zváženy níže.

Proces připojení:

1. Klientská aplikace načte klientskou knihovnu
2. fbclient.dll - nativní Windows aplikace
3. libfbclient.so - nativní Linux aplikace
4. Klientská aplikace zahájí připojení, odesláním
5. Uživatelského jména, např. SYSDBA
6. Hesla, např. masterkey
7. Cesty/aliasu databáze

V případě šifrované databáze je vyžadován další krok: je nutné předat název šifrovacího klíče a jeho hodnotu.

Je důležité říci, že předání klíče by mělo být provedeno před běžným připojením, kvůli skutečnosti, že datové stránky s metadaty, včetně jména vlastníka databáze, znakové sady atd., jsou šifrované.

Takže nás to vede k následujícímu:

1. Je nutný další síťový roundtrip pro předání klíče před běžným připojením
2. Přenos klíče z klientské aplikace do Firebirdu vyžaduje kódování s použitím asymetrického šifrování a implementaci callback rozhraní, což může být poměrně složité. Pro zjednodušení tohoto úkolu poskytují výrobci pluginů příklad kódu pro připojení, nebo, jako v rámci pluginů IBSurgeon, vytvářejí další knihovnu fbcrypt.dll/libfbcrypt.so, která implementuje snadno použitelné vhodné rozhraní pro přenos klíčů z klientské aplikace.

Pro připojení nativní aplikace (která používá fbclient.dll) k šifrované databázi je třeba provést 3 volání. Níže je příklad v Delphi (zjednodušený, bez zpracování chyb):

V obslužné rutině události BeforeConnect:

fbcrypt_init(PAnsiChar(‘C:\Firebird30.bclient.dll’));
fbcrypt_key(‘RED’, ‘0xec,0xa1,0x52,0xf6,...’));
fbcrypt_callback(nil);

 // Poté se připojte jako obvykle
Database1.Active:=True;

Na obrázku níže vidíte přehled procesu připojení k šifrované databázi v nativní aplikaci:

Obrázek 10. Proces připojení k šifrované databázi pro nativní aplikace

Co bezpečnost vláken v případě vícevláknových klientských aplikací?

Dovolte mi připomenout některé obecné momenty implementace vícevláknových klientských aplikací.

Od Firebirdu 2.5 může několik vláken uvnitř aplikace bezpečně používat jediné připojení k databázi, protože veškerá potřebná synchronizace je provedena uvnitř fbclient.dll.

Nicméně v tomto případě budou vlákna schopna pracovat s připojením pouze jedno po druhém.

To je v pořádku pro aplikace, které nevyžadují vysoce výkonnou výměnu dat s databází - pokud není problém počkat na provedení SQL dotazu z jednoho vlákna, když jiné vlákno provádí jiný SQL, je jednodušší použít jednoduchý model, kdy je 1 připojení sdíleno mezi několika vlákny.

Pokud aplikace vyžaduje provádění SQL dotazů paralelně (tj. je to plnohodnotná klientská aplikace), je lepší použít samostatné vlákno pro každé připojení.

Situace s výměnou klíčů pro připojení k šifrovaným databázím je o něco složitější.

Při každém připojení přenáší klientská knihovna klíče z klienta, ale to přímo nesouvisí s vlákny v klientské aplikaci, situace závisí na použitém API.

Jak víte, klientská knihovna Firebirdu od verze 3.0 nabízí 2 typy API: nové objektově orientované API, založené na konceptu poskytovatelů, a starší isc_ API, implementované jako náhradní řešení pro zachování kompatibility se starými ovladači Firebirdu.

Pokud se používá nové objektově orientované klientské API, stačí vytvořit poskytovatele, dodat mu potřebné klíče a poté jej použít pro nová připojení.

Pokud se používá isc_ klientské API, pro každé připojení vytvoří klientská knihovna vlastní dočasný poskytovatel, který není přímo viditelný ani přístupný koncovému uživateli.

V tomto případě je klíč přenesen přesně z vlákna, kde je vyvoláno isc_attach_database, a pro uložení tohoto klíče se používá úložiště lokální pro vlákno.

V praxi, protože téměř všechny klientské knihovny používají isc_ API (v současnosti mezi populárními ovladači používá OO API pouze Python ovladač), je nutné vyvolat fb_database_crypt_callback() v každém vlákně, které se připojuje k šifrované databázi.

Volání pro přenos klíčů (volání fbcrypt.dll v příkladu FEPF) musí být provedena před připojením, ve stejném vlákně, kde bude připojení navázáno.

Když pracujeme s mnoha databázemi (například SaaS webový server s mnoha klientskými databázemi), je důležité si pamatovat, že každé vyvolání fbcrypt_key() přidá klíč do úložiště KeyHolder, spojeného s aktuálním připojením.

Hodnoty klíčů musí být nastaveny před připojením, po připojení nelze hodnotu klíče změnit.

V případě odpojení se klíče neuvolňují, zůstanou v paměti až do uvolnění fbcrypt.dll.

3.2. Java aplikace

Java ovladač (JayBird) má vlastní implementaci (v čisté Javě) protokolu připojení Firebirdu. Jaybird 4 (a 3.0.4+) přidává podporu pro callbacky šifrování databáze Firebirdu 3 v čisté Java implementaci protokolu verze 13.

Z poznámek k vydání Jaybird 4:

“ Současná implementace je jednoduchá a podporuje pouze odpověď statickou hodnotou z připojovací vlastnosti. Mějte na paměti, že statická hodnota odpovědi pro šifrování databáze není příliš bezpečná, protože může snadno vést k replay útokům nebo neúmyslnému odhalení klíče.

Budoucí verze Jaybirdu (pravděpodobně 5) představí podporu pluginů pro šifrovací pluginy databáze, které vyžadují složitější callback.“

Prakticky to znamená, že musíme nastavit hodnotu pro šifrovací callback (obvykle je to název klíče a pár klíč-hodnota) v připojovací vlastnosti dbCryptConfig.

Například:

 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,");

Je také možné zadat řetězec v base64 - z poznámek k vydání:

“ Řetězce s předponou base64:: zbytek řetězce je dekódován jako base64 na bajty.

Znaky = pro doplnění jsou volitelné, ale pokud jsou přítomny, musí být platné (to znamená: pokud používáte doplnění, musíte použít správný počet doplňovacích znaků pro délku).

Když hodnota zakódovaná v base64 obsahuje +, musí být escapována jako %2B v JDBC URL. Kvůli zpětné kompatibilitě s Jaybirdem 3 nemůžeme přejít na URL-bezpečnou variantu base64.“

V implementaci pluginu pro správu klíčů IBSurgeon je takový přenos klíče považován za více či méně nebezpečný: pokud není povoleno šifrování síťového protokolu ( mimochodem, pro jeho povolení nastavte v firebird.conf WireCrypt=Required a nepoužívejte starší autentizaci), klíč může být snadno zachycen analyzátorem síťového provozu jako WireShark, takže pro povolení přenosu klíčů tímto způsobem je nutné nastavit UnsafeClient=true v KeyHolder.conf pluginu pro správu klíčů IBSurgeon.

3.3 .NET aplikace

Poskytovatel Firebird.NET implementuje podobné schéma výměny klíčů pro šifrované databáze a také vyžaduje nastavení parametru UnsafeClient=true v KeyHolder.conf v FEPF.

Příklad .NET připojovacího řetězce pro šifrované databáze:

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…...;";

Můžete si všimnout, že šifrovací klíč vypadá jinak než v příkladu pro nativní aplikace a JayBird, je to proto, že je výsledkem transformace Base64, takže pro získání klíče pro .NET nebo Java aplikaci je nutné vypočítat base64 z řetězce:

“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,”

a použít jej jako parametr pro “cryptkey=xxx;” s “;” na konci připojovacího řetězce.

4. Instalace a konfigurace

Pro povolení použití databázového šifrování a pluginu pro správu klíčů je nutné zadat název šifrovacího pluginu v konfiguračním souboru Firebirdu firebird.conf:

 KeyHolderPlugin = KeyHolder

Nebo alternativně v databases.conf pro alias šifrované databáze:

myencrypted = C:\Temp\EMPLOYEE30.MPLOYEE30.FDB { KeyHolderPlugin = KeyHolder }

Poté je nutné zkontrolovat, že všechny soubory potřebné pro plugin jsou na serveru.

Níže uvedený příklad je pro FEPF od IBSurgeon, ale ostatní pluginy jsou více či méně podobné:

V %FirebirdFolder$\plugins

    • DbCrypt.dll
    • DbCrypt.conf
    • KeyHolder.dll
    • KeyHolder.conf - pouze pro debug režim!

V %FirebirdFolder$

    • fbcrypt.dll
    • libcrypto-1_1-x64.dll
    • libssl-1_1-x64.dll
    • firebird.msg

Poté můžeme provést testovací šifrování na serveru, a to v isql:

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

Pokud jste na Linuxu, pamatujte, že záleží na velikosti písmen, takže příkaz bude:

alter database encrypt with "DbCrypt" key Red;

Nyní můžeme otestovat klientský přístup k šifrované databázi. Za tímto účelem odstraníme (nebo přejmenujeme či upravíme) konfigurační soubor KeyHolder.conf a pokusíme se připojit k šifrované databázi pomocí jednoduché testovací aplikace.

K tomu musíme do složky s klientskou aplikací umístit následující soubory:

• Demo aplikace z FEPF- CryptTest.exe (32bit)
• Povinné soubory:
  • fbclient.dll
  • fbcrypt.dll
  • libcrypto-1.1.dll
  • libssl-1.1-x64.dll
• Volitelné soubory:
  • firebird.conf
  • v plugins
  • ◦ KeyHolder.conf
  • ◦ keyhodler.dll

V některých implementacích pluginů pro správu klíčů je možné načíst klíče do klientské knihovny (fbclient.dll) bez úpravy klientského softwaru.

To umožňuje transparentní práci vývojářských nástrojů Firebird (jako Firebird SQL Studio, DatabaseWorkbench, IBExpert, FlameRobin, RedExpert atd.) a transparentní používání příkazových nástrojů Firebird (gfix.exe, nbackup.exe atd.).

5. Jak sledovat průběh šifrování

Firebird šifruje databázi pouze tehdy, když má aktivní připojení. Proces šifrování běží v samostatném paralelním vlákně a u velkých databází může kompletní šifrování zabrat značný čas.

Pro sledování procesu šifrování spusťte buď SQL dotaz z MON$:

select mon$crypt_page * 100.0 / mon$pages as Percent from mon$database;
commit;

nebo spusťte nástroj gstat se speciálním přepínačem:

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

Upozorňujeme, že spuštění gstat může být zdlouhavý proces.

6. Shrnutí

1. Šifrování databáze Firebird je výkonná funkce pro ochranu informací v databázích před neoprávněným přístupem.
2. Proces šifrování vyžaduje serverovou dynamickou knihovnu - šifrovací plugin (obvykle nazývaný DbCrypt) a v naprosté většině případů také plugin pro správu klíčů (obvykle nazývaný KeyHolder).
3. Bezpečná a spolehlivá implementace pluginů DbCrypt a KeyHolder by měla být provedena s ohledem na nejčastější typy útoků.
4. Pro práci se šifrovanou databází musí klientské aplikace přenést šifrovací klíč.
5. Instalace a konfigurace šifrovacího pluginu na serverové straně je triviální, vyžaduje 1 parametr v firebird.conf/databases.conf a několik souborů.
6. Proces šifrování může být zdlouhavý, probíhá v samostatném vlákně na pozadí, průběh lze sledovat pomocí volání MON$ nebo gstat.

Co dál?

Pracujeme na podrobném testu výkonu šifrování databáze Firebird. Obecně je výkon o 4-8 % nižší, ale záleží na hardwaru a nastavení Firebird. Zůstaňte naladěni!

Kontaktujte nás:

Pošlete prosím své návrhy, překlepy, chyby atd. a jakékoli dotazy e-mailem: [email protected]