Firebird 3 wire-kryptering og VPN er to forskjellige grenser

VPN-en kobler til, klienten åpner en sesjon, og alle antar at databaseforbindelsen er sikret. Tre forskjellige ting ble nettopp blandet sammen. Om lytteren i det hele tatt er tilgjengelig, om serveren godtok brukeren, og om Firebird forhandlet wire-kryptering er separate mekanismer med separate bevis. En tunnel svarer bare på det første, og bare for kildene du tillot.

To grenser, og de overlapper ikke

VPN-grensen beskytter pakker mellom en klient og en gateway. Firebirds wire-kryptering beskytter databaseprotokollen mellom klientbiblioteket og serverprosessen. Begge kan være til stede, og ingen av dem erstatter den andre.

Hvis tunnelen slutter før databaseverten, beskyttes trafikken bak den bare av det databasesesjonen forhandlet. Det er i dette gapet en gjennomgang vanligvis finner overraskelsen. Tunneldiagrammet slutter ved en gateway, og forbindelsen som bærer spørringen din fortsetter forbi den. Den som leser diagrammet senere, arver antakelsen.

Grense én: hvem som kan åpne lytteren

Identifiser den virkelige serveradressen og den konfigurerte porten, som er 3050 med mindre den er endret, og tillat deretter bare de godkjente VPN-kildene i verts- og nettverksbrannmuren. Ta høyde for eventuell adresseoversettelse i VPN-gatewayen, og gi databaseverten en returrute til klientpoolen hvis gatewayen er separat.

Bevis så det negative. En ekstern vei som skal avvises, må fortsatt avvises, fordi åpningen av tunnelen ikke begrenser Firebird-lytteren i seg selv.

Grense to: hva Firebird forhandler

Firebird 3 innførte et rammeverk for wire-kryptering med en serverpolicy som kan deaktiveres, aktiveres eller kreves. Policyen setter gulvet. Den faktiske sesjonen avhenger fortsatt av klientbiblioteket som applikasjonen laster, og pluginene begge sider støtter.

I utgivelsesnotatene til Firebird 3 er Arc4 oppført som standard-plugin for wire-kryptering for den utgivelsen. Arc4 er en historisk standard, ikke en anbefaling av en moderne cipher, og det er ikke det samme som den ytre VPN-beskyttelsen.

Autentisering er en tredje variabel i samme forhandling. Serveren godtar et sett med autentiserings-plugins, klientbiblioteket tilbyr en delmengde, og de to må overlappe.

Legacy_Auth-fellen

Støtte for Legacy_Auth krever at serverens standardpolicy for påkrevd kryptering lempes. Det er den dokumenterte kompatibilitetskostnaden, og derfor er det en sikkerhetsendring og ikke en retting å senke policyen for å tysse på en tilkoblingsfeil.

Hvis en klient plutselig feiler etter en serveroppgradering, sammenlign pluginlistene før du svekker noe. Feilen er vanligvis et forhandlingsavvik, og svaret er en støttet plugin på begge sider.

Kontroller forbindelsen som betyr noe

På en build som tilbyr kontekstvariabelen, rapporterer denne spørringen krypteringstilstanden til den gjeldende forbindelsen:

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

Kjør den gjennom applikasjonens egen forbindelse, ikke gjennom en administratorøkt på samme server. En kryptert administratortilkobling sier ingenting om en annen klientbiblioteks sesjon, og en eldre build som ikke støtter variabelen er ikke bevis for at kryptering er av.

Noter klientbibliotekets versjon, serverens build og resultatet sammen, fordi ingen av dem alene er lesbare.

Rettigheter og oppgraderingsveien

Å begrense kilder og kryptere transport erstatter ikke autentisering eller rettigheter etter minst privilegium. Kontroller den vanlige databasebrukerens tillatelser på objektene den faktisk berører.

Til slutt, behandle en langvarig utrulling som et vedlikeholdsspørsmål. En tunnel gjør ikke et utdatert klientbibliotek trygt på ubestemt tid, og en støttet oppgraderingsvei er billigere enn å oppdage at plugin-en den trenger er fjernet.