Како функционише шифровање Firebird базе података

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

Članak je zasnovan na materijalima radionice „Enkripcija baze podataka” na Firebird konferenciji 2019. u Berlinu, Nemačka. Opisuje kako funkcioniše enkripcija Firebird baze podataka, na nivou servera, na klijentskoj strani, kako konfigurisati enkripciju baze podataka, kako je koristiti iz različitih tipova aplikacija (Delphi, Java, .NET). Primeri u članku su zasnovani na IBSurgeon Firebird Encryption Framework (FEPF), ali se mogu prilagoditi većini trenutno dostupnih implementacija enkripcionih dodataka.

Sadržaj:

1. Zašto nam je potrebna enkripcija baze podataka (a kada nije)?
2. Kako funkcioniše enkripcija Firebird baze podataka na strani servera
3. Koji deo baze podataka se enkriptuje?
4. Kada se stranice podataka enkriptuju?
5. Kako zaštititi prenos ključeva?
6. Kako funkcioniše Firebird enkripcija na klijentskoj strani
7. Nativne aplikacije
8. Java aplikacije
9. .NET aplikacije
10. Instalacija i konfiguracija
11. Kako pratiti napredak enkripcije
12. Sažetak

1. Zašto nam je potrebna enkripcija baze podataka (a kada nije)?

Enkripcija Firebird baze podataka uvedena je u izdanju Firebird 3.0 (zajedno sa enkripcijom transfer protokola, koja se često meša sa temom o kojoj govorimo) i značajno je povećala mogućnosti zaštite podataka od neovlašćenog pristupa. Međutim, ona nije univerzalno rešenje i neophodno je razumeti njene prednosti i slabosti da bi se pravilno koristila.

U ovom članku razmatramo unutrašnje detalje enkripcije baze podataka na osnovnom nivou, kako bismo programerima Firebird aplikacija pružili bolje razumevanje načina na koji funkcioniše enkripcija baze podataka.

Dakle, zašto nam je potrebna enkripcija baze podataka?

1. Da zaštiti baze podataka sa osetljivim/vrednim podacima od „fizičke” krađe. Ako uljez ukrade disk sa kopijom enkriptovane baze podataka ili na neki način dobije kopiju datoteke baze podataka, neće biti moguće čitati podatke iz nje bez odgovarajućeg ključa, kao što neće biti moguće koristiti softver za oporavak poput FirstAID za izdvajanje podataka. Naravno, to zavisi od algoritma enkripcije i računarske snage, ali razbijanje AES256 zahtevalo bi previše vremena ili preskupe računarske resurse.
2. Da zaštiti bazu podataka od pristupa neovlašćenim aplikacijama bez enkripcionih ključeva. Primeri su:
   • direktan pristup razvojnim alatom od strane neovlašćene osobe, radi izmene osetljivih informacija (npr. novčanih transakcija),
   • izmena ili krađa poslovne logike (tekstovi procedura i okidača).
3. Zaštita baza podataka sa unapred popunjenim podacima od izvoza ili pristupa neovlašćenim aplikacijama.
4. Vlade su nedavno uvele zakone o zaštiti podataka (GDPR/DSVGO u Evropi, LGPD u Brazilu, itd.) koji zahtevaju, između ostalog, viši nivo zaštite ličnih i drugih osetljivih podataka, a enkripcija se pominje kao jedna od adekvatnih mera zaštite.

Kada enkripcija baze podataka nije korisna?

U nekim slučajevima bolje je koristiti sigurnosne i konfiguracione mogućnosti Firebird-a umesto enkripcije baze podataka:

• Za zaštitu baze podataka od fizičkog pristupa preko mreže, neophodno je konfigurisati mrežni pristup: tj. zatvoriti mrežne deljene fascikle, jer Firebird ne zahteva mrežni deljeni pristup datotekama baze podataka, i pooštriti sigurnosne dozvole (za Linux, na primer, datoteke baze podataka moraju imati pristup za čitanje i pisanje samo za korisnika „firebird”).
• Za ograničavanje pristupa određenoj bazi podataka za određeni podskup korisnika, lakše rešenje biće konfigurisanje zasebne sigurnosne baze podataka.
• Za ograničavanje pristupa objektima baze podataka (tabele, procedure) neophodno je koristiti Firebird sigurnosne mehanizme: korisnike, uloge, itd.

Naravno, obe liste iznad su nepotpune, ali vam daju izvesnu predstavu o tome kada vam je potrebna, a kada nije, enkripcija baze podataka.

2. Kako funkcioniše enkripcija Firebird baze podataka na strani servera

Prođimo kroz unutrašnje detalje enkripcije Firebird baze podataka i počnimo sa serverskim delom.

2.1. Koji deo baze podataka se enkriptuje?

Prva stvar koju treba da razmotrimo jeste koji deo baze podataka se enkriptuje? Kao što verovatno znate, Firebird baza podataka sastoji se od delova jednake veličine, koji se nazivaju „stranice baze podataka”. Postoji nekoliko tipova takvih stranica, a svaki tip služi određenoj svrsi.

Ispod možete videti sliku sa glavnim tipovima podataka:

Slika 1. Tipovi stranica baze podataka

Neke stranice su dizajnirane za čuvanje korisničkih podataka, a neke druge su potrebne za čuvanje sistemskih informacija, poput transakcija i stranica inventara stranica (više detalja o stranicama baze podataka dostupno je ovde).

Kada se Firebird baza podataka enkriptuje, samo stranice sa korisničkim podacima se enkriptuju: stranice podataka, indeksi, generatori i BLOB-ovi:

Slika 2. Samo stranice baze podataka sa korisničkim podacima se enkriptuju

Imajte na umu da se metapodaci baze podataka (procedure, tabele, pogledi, okidači, imena generatora, itd.) ne razlikuju od „korisničkih podataka” unutar dela motora odgovornog za enkripciju, i oni se enkriptuju.

Zašto se sistemske stranice ne enkriptuju? Uglavnom zbog performansi i zbog činjenice da ne sadrže osetljive podatke koji zahtevaju zaštitu.

Zaglavlje baze podataka se ne enkriptuje, jer sadrži informacije potrebne za enkripciju (na primer, ime ključa).

2.2. Kada se stranice podataka enkriptuju?

Kada korisnik izvrši SELECT iz enkriptovane baze podataka, podaci se čitaju iz enkriptovane datoteke, ali stižu u aplikaciju sa rezultatima u neenkriptovanoj formi.

Razmotrimo detalje ovog procesa:

Slika 3. Kada se stranice baze podataka enkriptuju?

Obično proces počinje nizom čitanja stranica baze podataka iz datoteke baze podataka, i one se keširaju u kešu datoteka operativnog sistema.

Firebird se takođe može konfigurisati da zaobiđe keš datoteka i koristi samo sopstveni keš, ali podrazumevano se koristi keš datoteka.

Nakon toga, Firebird čita stranice i smešta ih u Firebird keš stranica (definisan je parametrom DefaultDBCachePages u firebird.conf i/ili databases.conf ili u zaglavlju baze podataka).

Zatim se stranice iz keša biraju u skup rezultata određene SQL izjave (SELECT u našem primeru).

Slika ispod prikazuje detalje:

Slika 4. Stranice se enkriptuju između Firebird keša i keša datoteka operativnog sistema

Dakle, stranice baze podataka se enkriptuju u kešu datoteka operativnog sistema, ali stižu u Firebird keš stranica neenkriptovane, i obrnuto.

Deo Firebird softvera odgovoran za enkripciju/dekripciju naziva se „enkripcioni dodatak”. Pošto se većina implementacija dodataka (poznatih autorima) naziva DbCrypt, mi ćemo ga zvati DbCrypt.

Na slici ispod možete videti varijante za Windows (DbCrypt.dll) i Linux (libDbCrypt.so):

Слика 5. Плугин за шифровање (DbCrypt) обавља шифровање/дешифровање

Ако довољно дуго гледате ову слику, следеће питање ће се појавити прилично брзо: како DbCrypt добија прави кључ за шифровање/дешифровање страница базе података?

Одговор - постоји још један плугин за управљање кључевима.

Типичан назив за управљање кључевима је KeyHolder, који служи као складиште/механизам за управљање кључевима за плугин за шифровање (DbCrypt). KeyHolder имплементира интерфејс за управљање кључевима који користи DbCrypt.

Слика 6. DbCrypt и KeyHolder

Шта значи „управљање кључевима“?

У најједноставнијем случају, DbCrypt може читати кључеве из датотеке на серверу. Датотека може бити обична текстуална датотека, која може бити скривена на „тајном“ месту или на USB стику, или може бити шифрована датотека (користећи Windows Crypto API, на пример, или са уграђеним интерним кључем).

Датотека са кључевима може садржати више кључева, ускладиштених ради погодности као именована листа, и може изгледати овако (пример испод је преузет из 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,

Када је база података шифрована, њене заглавне странице остају нешифроване да би чувале информације о плугину за шифровање и имену кључа, и ове информације можете видети командом “gstat -h databasename”:

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 може обрађивати странице за више база података и више кључева:

Слика 7. Више кључева за више база података на истом серверу (тј. Firebird инстанци)

Избор исправног кључа

Често програмери постављају питање „Како плугин препознаје који је кључ за коју базу података?“ Одговор је прилично једноставан: по имену кључа, које је ускладиштено на заглавној страници базе података.

Ређе, али и даље важно питање - шта ако је име кључа онако како је записано у заглављу, али је вредност кључа другачија? Да би се спречиле грешке при читању страница због погрешног кључа, DbCrypt плугин чува шифровану тест секвенцу (цифре 0…F) у заглављу, а затим када се кључ активира, плугин покушава да шифрује узорак података са кључем и упореди његов хеш са ускладиштеним резултатом, како би се уверио да је прослеђена вредност кључа заиста исправна за ову конкретну базу података.

Приступ када плугин за шифровање чита кључеве директно је једноставан и користан за отклањање грешака, тестове перформанси итд., јер имплементира шифровање на транспарентан начин: тј. клијентске апликације и алати за програмере не знају да је база података шифрована.

Међутим, у стварности, морамо ограничити приступ апликација бази података: само клијентска апликација која има кључ треба да може да се повеже на шифровану базу података.

За ово нам је потребан KeyHolder плугин, да добије кључ од клијентске апликације (која је обично на другом рачунару) преко Firebird мрежног протокола.

2.3. Како заштитити пренос кључа?

Могуће је да желимо заштитити базу података у ситуацији када купац одлучи да добије директан приступ шифрованој бази података, заобилазећи овлашћене апликације (многи произвођачи желе да ограниче податке од директног приступа, било само за читање или за читање и писање).

То је еквивалентно ситуацији када уљез има приступ серверу, али нема кључеве.

Размотримо следеће сценарије напада за пресретање кључева на серверској страни:

1. Када уљез креира лажни плугин за шифровање (DBCrypt.dll) и постави га на сервер, и када KeyHolder проследи кључ, лажни DbCrypt прави дамп кључа:

Слика 8. Напад са лажним DbCrypt.dll

2. Када уљез креира лажну firebird.exe датотеку и направи дамп са њом:

Слика 9. Напад са лажним firebird.exe

Да би се заштитили од таквих напада, добра имплементација плугина за шифровање и управљање кључевима мора заштитити размену кључева.

Размена кључева може бити заштићена асиметричним шифровањем са паром јавни/приватни кључева.

Ови кључеви се генеришу током процеса изградње и уграђени су за специфичан пар плугина за шифровање и управљање кључевима. За најбољу заштиту, неопходно је користити специјално изграђене парове DbCrypt/KeyHolder.

Када DbCrypt и KeyHolder размењују кључеве, користе следећи протокол (поједностављен је, али је идеја јасна, претпостављам):

DbCrypt → KeyHolder:
	Дај ми кључ базе података са овим соли
KeyHolder:
	Шифрује DbKey са јавним кључем користећи сол од DbCrypt-а
	Преноси шифровани DbKey до DbCrypt-а
DbCrypt:
	Дешифрује DbKey са приватним кључем
	Проверава исправност соли
	Спреман за рад

Више или мање исти протокол се користи за размену кључева између инстанци KeyHolder-а, и за размену кључева између клијентске апликације и KeyHolder-а.

Имајте на уму да шифровање и исправност пренетих кључева зависе од имплементације плугина, Firebird мотор пружа само основни нискоризински сервис преноса „пошаљи N бајтова са ове инстанце плугина на ону инстанцу плугина“.

Резиме за серверски део шифровања

• Шифровање/дешифровање обавља плугин за шифровање базе података (DbCrypt), страницу по страницу, током размене података између кеша датотека оперативног система и Firebird кеша страница
• Управљање кључевима може бити имплементирано на једноставан начин када DbCrypt чита кључеве директно, али обично се то ради са плугином за управљање кључевима (KeyHolder)

Сада да откријемо како клијентске апликације раде са шифрованим базама података.

3. Како Firebird шифровање ради на клијентској страни

3.1. Изворне апликације

Да бисмо разумели шта се дешава када се клијентска апликација повеже на шифровану базу података, размотримо уобичајени процес повезивања на нешифровану базу података за изворне апликације.

Имајте на уму: од овде и даље, „изворно“ значи да таква апликација успоставља мрежну везу са сервером користећи fbclient.dll, обично је таква апликација направљена у Delphi-ју, C++, PHP-у. За разлику од изворних апликација, Java и .NET имплементирају сопствену верзију протокола, они ће бити размотрени испод.

Процес повезивања:

1. Клијентска апликација учитава клијентску библиотеку
2. fbclient.dll - изворне Windows апликације
3. libfbclient.so - изворне Linux апликације
4. Клијентска апликација покреће повезивање, шаљући
5. Корисничко име, нпр. SYSDBA
6. Лозинку, нпр. masterkey
7. Путању/алијас базе података

У случају шифроване базе података, потребан је додатни корак: неопходно је проследити име кључа за шифровање и његову вредност.

Важно је напоменути да прослеђивање кључа треба обавити пре редовног повезивања, због чињенице да су странице података са метаподацима, укључујући име власника базе података, скуп знакова итд., шифроване.

Дакле, то нас доводи до следећег:

1. Додатни мрежни roundtrip је неопходан да се проследи кључ пре редовног повезивања
2. Пренос кључа са клијентске апликације на Firebird захтева кодирање са употребом асиметричног шифровања и имплементацију callback интерфејса, што може бити прилично сложено. Да би се поједноставио овај задатак, произвођачи плугина обезбеђују пример кода за повезивање, или, као у IBSurgeon оквиру за плугине, креирају додатну библиотеку fbcrypt.dll/libfbcrypt.so, која имплементира једноставан за употребу одговарајући интерфејс за пренос кључева са клијентске апликације.

Да бисте повезали изворну апликацију (која користи fbclient.dll) са шифрованом базом података, потребно је извршити 3 позива. Испод је Delphi пример (поједностављен, без обраде грешака):

У BeforeConnect догађају:

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

 // Затим се повежите као и обично
Database1.Active:=True;

На слици испод можете видети преглед процеса повезивања са шифрованом базом података у изворној апликацији:

Слика 10. Процес повезивања са шифрованом базом података за изворне апликације

Шта је са безбедношћу нити у случају више-нитних клијентских апликација?

Дозволите ми да вас подсетим на неке опште моменте имплементације више-нитних клијентских апликација.

Од Firebird 2.5, више нити унутар апликације може безбедно да користи једно повезивање са базом података, јер се сва потребна синхронизација обавља унутар fbclient.dll.

Међутим, у овом случају, нити ће моћи да раде са повезивањем само једна по једна.

Ово је у реду за апликације које не захтевају високе перформансе размене података са базом података - ако није проблем чекати да се изврши SQL упит из једне нити када друга нит извршава други SQL, лакше је користити једноставан модел када је 1 повезивање подељено између више нити.

Ако апликација захтева извршавање SQL упита паралелно (тј. то је пуноправна клијентска апликација), боље је користити посебну нит за свако повезивање.

Ситуација са разменом кључева за повезивања са шифрованим базама података је мало сложенија.

При сваком повезивању, клијентска библиотека преноси кључеве са клијента, али то није директно повезано са нитима у клијентској апликацији, ситуација зависи од коришћеног API-ја.

Као што знате, Firebird клијентска библиотека од 3.0 нуди 2 типа API-ја: нови објектно-оријентисани API, заснован на концепту провајдера, и стари isc_ API, имплементиран као привремено решење, ради одржавања компатибилности са старим Firebird драјверима.

Ако се користи нови објектно-оријентисани клијентски API, довољно је креирати провајдера, снабдети га потребним кључевима, а затим га користити за нова повезивања.

Ако се користи isc_ клијентски API, за свако повезивање клијентска библиотека ће креирати сопственог привременог провајдера, који није директно видљив или доступан крајњем кориснику.

У овом случају, кључ се преноси тачно из нити где се позива isc_attach_database, и локална меморија нити се користи за чување тог кључа.

У пракси, пошто скоро све клијентске библиотеке користе isc_ API (тренутно, међу популарним драјверима, само Python драјвер користи OO API), потребно је позвати fb_database_crypt_callback() у свакој нити која се повезује са шифрованом базом података.

Позиви за пренос кључева (fbcrypt.dll позиви у FEPF примеру) морају се извршити пре повезивања, у истој нити где ће се успоставити веза.

Када радимо са многим базама података (на пример, SaaS веб сервер са многим клијентским базама), важно је запамтити да сваки позив fbcrypt_key() додаје кључ у KeyHolder складиште, повезано са тренутном везом.

Вредности кључева морају бити постављене пре повезивања, након повезивања, вредност кључа се не може променити.

У случају одвајања, кључеви се не уклањају, они ће остати у меморији до уклањања fbcrypt.dll.

3.2. Java апликације

Java драјвер (JayBird) има сопствену имплементацију (у чистом Java) Firebird протокола повезивања. Jaybird 4 (и 3.0.4+) додаје подршку за Firebird 3 повратне позиве за шифровање базе података у чистој Java имплементацији верзије 13 протокола.

Из Jaybird 4 Readme:

“ Тренутна имплементација је једноставна и подржава само одговарање статичком вредношћу из својства везе. Имајте на уму да статички одговор вредности за шифровање базе података није веома сигуран јер лако може довести до напада понављањем или ненамерног излагања кључа.

Будуће верзије Jaybird-а (вероватно 5) ће увести подршку за додатке за шифровање базе података који захтевају сложенији повратни позив.”

Практично, то значи да треба да поставимо вредност за повратни позив шифровања (обично, то је име кључа и пар кључ-вредност) у својству везе dbCryptConfig.

На пример:

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

Такође је могуће навести низ у base64 - из readme-а:

“ Ниске са префиксом base64:: остатак ниске се декодира као base64 у бајтове.

Знакови = за попуњавање су опциони, али када су присутни морају бити валидни (тј. ако користите попуњавање, морате користити тачан број знакова попуњавања за дужину).

Када base64 кодирана вредност садржи +, мора бити ескепована као %2B у JDBC URL-у. Због повратне компатибилности са Jaybird 3, не можемо прећи на URL-безбедну варијанту base64.“

У IBSurgeon имплементацији додатка за управљање кључевима, таква трансмисија кључа се сматра мање или више небезбедном: ако шифровање мрежног протокола није омогућено ( узгред, да бисте га омогућили, поставите у firebird.conf WireCrypt=Required и не користите старију аутентификацију), кључ се лако може уочити анализатором мрежног саобраћаја као што је WireShark, па да бисте омогућили пренос кључева на овај начин, потребно је поставити UnsafeClient=true у KeyHolder.conf IBSurgeon додатка за управљање кључевима.

3.3 .NET апликације

Firebird.NET провајдер имплементира сличну шему размене кључева за шифроване базе података и такође захтева постављање параметра UnsafeClient=true у KeyHolder.conf у FEPF.

.NET пример ниске за повезивање за шифроване базе података:

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

Можете приметити да кључ за шифровање изгледа другачије него у примеру за изворне апликације и JayBird, то је зато што је то резултат Base64 трансформације, па да бисте добили кључ за .NET или Java апликацију, потребно је израчунати base64 из ниске:

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

и користити је као параметар за “cryptkey=xxx;” са “;” на крају ниске за повезивање.

4. Инсталација и конфигурација

Да бисте омогућили коришћење шифровања базе података и додатка за управљање кључевима, потребно је навести име додатка за шифровање у Firebird конфигурационом фајлу firebird.conf:

 KeyHolderPlugin = KeyHolder

Или, алтернативно, у databases.conf, за алиас шифроване базе података:

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

Затим, потребно је проверити да су сви фајлови потребни за додатак на серверу.

Пример испод је за IBSurgeon-ов FEPF, али други додаци су мање-више слични:

у %FirebirdFolder$\plugins

    • DbCrypt.dll
    • DbCrypt.conf
    • KeyHolder.dll
    • KeyHolder.conf - само за режим отклањања грешака!

**У %FirebirdFolder$**

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

Након тога, можемо извршити тест шифровања на серверу, за ово, у 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

Ако сте на Linux-у, запамтите да је величина слова важна, па ће команда бити:

alter database encrypt with “DbCrypt” key Red;

Сада можемо тестирати приступ клијента шифрованој бази података. За ово ћемо уклонити (или преименовати или изменити) конфигурациони фајл KeyHolder.conf, и покушати да се повежемо на шифровану базу података једноставном тест апликацијом.

За ово, морамо ставити у фолдер са клијентском апликацијом следеће фајлове:

- Demo апликација са [FEPF](/sr/download-demo-firebird-encryption-plugin)- CryptTest.exe (32bit)
- Обавезни фајлови:
  - fbclient.dll
  - fbcrypt.dll
  - libcrypto-1.1.dll
  - libssl-1.1-x64.dll
- Опциони фајлови:
  - firebird.conf
  - у plugins
  - ◦ KeyHolder.conf
  - ◦ keyhodler.dll

У неким имплементацијама додатака за управљање кључевима, могуће је [учитати кључеве у клијентску библиотеку](/sr/download-demo-firebird-encryption-plugin#Connect%20Firebird%20database%20with%20developer%20tools) (fbclient.dll), без модификације клијентског софтвера.

То омогућава транспарентан рад развојних алата за Firebird (као што су Firebird SQL Studio, DatabaseWorkbench, IBExpert, FlameRobin, RedExpert, итд.), и транспарентну употребу Firebird командних алата (gfix.exe, nbackup.exe, итд.).

## 5. Како пратити напредак шифровања

Firebird шифрује базу података само када има активне конекције. Процес шифровања се извршава у засебној паралелној нити, и за велике базе података, комплетно шифровање може потрајати значајно време.

Да бисте пратили процес шифровања, покрените SQL упит из MON$:

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

или извршите gstat алат са посебним прекидачем:

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

Имајте на уму да извршавање gstat-а може бити дуготрајан процес.

## 6. Резиме

1. Шифровање Firebird базе података је моћна функција за заштиту информација у базама података од неовлашћеног приступа.
2. Процес шифровања захтева серверску динамичку библиотеку - додатак за шифровање (обично назван DbCrypt), и, у великој већини ситуација, додатак за управљање кључевима (обично назван KeyHolder).
3. Сигурна и поуздана имплементација DbCrypt и KeyHolder додатака треба да буде урађена имајући у виду најпопуларније типове напада.
4. Да би радили са шифрованом базом података, клијентске апликације морају пренети кључ за шифровање.
5. Инсталација и конфигурација додатка за шифровање на серверској страни је тривијална, захтева 1 параметар у firebird.conf/databases.conf, и неколико фајлова.
6. Процес шифровања може бити дуготрајан, обавља се у засебној позадинској нити, напредак се може пратити са MON$ позивом или gstat-ом.

### Шта даље?

Радимо на детаљном тесту перформанси шифровања Firebird базе података. Уопштено, перформансе су 4-8% мање, али то зависи од хардвера и Firebird подешавања. Останите са нама!

### Контактирајте нас:

Молимо вас да пошаљете своје сугестије, грешке у куцању, грешке, итд, и сва питања на имејл: [[email protected]](mailto:[email protected]?subject=Firebird%20Db%20encryption%20article)