Firebird 3 se draadversleuteling en die VPN is twee grense

Die VPN maak verbinding, die kli\ënt open \'n sessie, en almal aanvaar die databasisverbinding is beveilig. Drie verskillende dinge is pas deurmekaar gegooi. Of die luisteraar enigsins bereikbaar is, of die bediener die gebruiker aanvaar het, en of Firebird draadversleuteling beding het, is afsonderlike meganismes met afsonderlike bewyse. \'n Tonnel beantwoord net die eerste een, en net vir die bronne wat jy toegelaat het.

Twee grense wat mekaar nie oorvleuel nie

Die VPN-grens beskerm pakkette tussen \'n kli\ënt en \'n poort. Firebird se draadversleuteling beskerm die databasisprotokol tussen die kli\ëntbiblioteek en die bedienerproses. Albei kan teenwoordig wees, en nie een vervang die ander nie.

As die tonnel voor die databasishost eindig, word die verkeer anderkant dit net beskerm deur wat die databasis-sessie beding het. Dit is die gaping waar \'n oudit gewoonlik die verrassing vind. Die tonneldiagram eindig by \'n poort, en die verbinding wat jou navraag dra, gaan verby dit aan. Enigiemand wat daardie diagram later lees, erf die aanname.

Grens een: wie kan die luisteraar oopmaak

Identifiseer die werklike bedieneradres en die gekonfigureerde poort, wat 3050 is tensy dit verander is, en laat dan net die goedgekeurde VPN-bronne by die host- en netwerkfirewalls toe. Reken vir enige adresomsetting by die VPN-poort, en gee die databasishost \'n terugroete na die kli\ëntpoel as die poort apart is.

Bewys dan die negatiewe. \'n Eksterne pad wat geweier moet word, moet steeds geweier word, want die opening van die tonnel beperk nie die Firebird-luisteraar op sigself nie.

Grens twee: wat Firebird beding

Firebird 3 het \'n raamwerk vir draadversleuteling ingestel met \'n bedienerbeleid wat gedeaktiveer, geaktiveer of vereis kan word. Die beleid stel die vloer. Die werklike sessie hang steeds af van die kli\ëntbiblioteek wat die toepassing laai en die plugins wat beide kante ondersteun.

Die Firebird 3-vrystellingsnotas lys Arc4 as die verstek-draadversleutelingsplugin vir daardie vrystelling. Arc4 is \'n historiese verstek, nie \'n moderne syferaanbeveling nie, en dit is nie dieselfde ding as die buitenste VPN-beskerming nie.

Verifikasie is \'n derde veranderlike in dieselfde onderhandeling. Die bediener aanvaar \'n stel verifikasieplugins, die kli\ëntbiblioteek bied \'n subset daarvan, en die twee moet oorvleuel.

Die Legacy_Auth-lokval

Om Legacy_Auth te ondersteun, moet die bediener se verstek vereiste-versleutelingsbeleid verslap word. Dit is die gedokumenteerde verenigbaarheidskoste, en daarom is die verlaging van die beleid om \'n verbindingsfout stil te maak \'n sekuriteitsverandering eerder as \'n regstelling.

As \'n kli\ënt skielik faal n\á \'n bedieneropgradering, vergelyk pluginlyste voordat enigiets verswak word. Die faling is gewoonlik \'n onderhandelingswanverhouding, en die antwoord is \'n ondersteunde plugin aan beide kante.

Kontroleer die attachment wat saak maak

Op \'n bou wat die konteksveranderlike verskaf, rapporteer hierdie navraag die versleutelingstoestand van die huidige attachment:

SELECT RDB$GET_CONTEXT('SYSTEM', 'WIRE_ENCRYPTED')
FROM RDB$DATABASE;

Voer dit deur die toepassing se eie verbinding, nie deur \'n administrateursessie op dieselfde bediener nie. \'n Versleutelde admin-attachment s\ê niks oor \'n ander kli\ëntbiblioteek se sessie nie, en \'n ouer bou wat die veranderlike nie ondersteun nie, is nie bewys dat versleuteling af is nie.

Teken die kli\ëntbiblioteekweergawe, die bedienerbou en die resultaat saam aan, want enigeen daarvan alleen is onleesbaar.

Regte en die opgraderingspad

Om bronne te beperk en vervoer te versleutel vervang nie verifikasie of minste-privilege-regte nie. Kontroleer die gewone databasisgebruiker se regte op die objekte wat dit werklik raak.

Laastens, hanteer \'n langdurige ontplooiing as \'n onderhoudsvraag. \'n Tonnel maak nie \'n verouderde kli\ëntbiblioteek onbepaald veilig nie, en \'n ondersteunde opgraderingspad is goedkoper as om te ontdek dat die plugin wat dit nodig het, verwyder is.