Wire-kryptering i Firebird 3 og VPN er to ulike grenser

VPN-en koplar til, klienten opnar ein sesjon, og alle går ut frå at databasekoplinga er sikra. Tre ulike ting vart nettopp blanda saman. Om lyttaren i det heile er tilgjengeleg, om serveren godtok brukaren, og om Firebird forhandla wire-kryptering er skilde mekanismar med skilde prov. Ein tunnel svarar berre på det første, og berre for kjeldene du tillét.

To grenser, og dei overlappar ikkje

VPN-grensa vernar pakkar mellom ein klient og ein gateway. Wire-krypteringa til Firebird vernar databaseprotokollen mellom klientbiblioteket og serverprosessen. Begge kan vere til stades, og ingen av dei erstattar den andre.

Viss tunnelen sluttar før databaseverten, er trafikken bak han berre verna av det databasesesjonen forhandla. Det er i dette gapet ein gjennomgang vanlegvis finn overraskinga. Tunneldiagrammet sluttar ved ein gateway, og sambandet som ber spørjinga di held fram forbi han. Den som les diagrammet seinare, arvar føresetnaden.

Grense éin: kven som kan opne lyttaren

Identifiser den verkelege serveradressa og den konfigurerte porten, som er 3050 med mindre han er endra, og tillat deretter berre dei godkjende VPN-kjeldene i verts- og nettverksbrannmuren. Ta høgd for eventuell adresseomsetjing i VPN-gatewayen, og gje databaseverten ei returrute til klientbassenget viss gatewayen er skild.

Prov så det negative. Ein ekstern veg som skal avvisast, må framleis avvisast, fordi opninga av tunnelen ikkje avgrensar Firebird-lyttaren i seg sjølv.

Grense to: kva Firebird forhandlar

Firebird 3 innførte eit rammeverk for wire-kryptering med ein serverpolicy som kan deaktiverast, aktiverast eller krevjast. Policyen set golvet. Den faktiske sesjonen er framleis avhengig av klientbiblioteket som applikasjonen lastar, og plugina begge sider støttar.

I utgjevingsnotata til Firebird 3 er Arc4 ført opp som standard-plugin for wire-kryptering for den utgjevinga. Arc4 er ein historisk standard, ikkje ei tilråding om ein moderne cipher, og det er ikkje det same som den ytre VPN-vernet.

Autentisering er ein tredje variabel i same forhandling. Serveren godtek eit sett med autentiserings-plugin, klientbiblioteket tilbyr ei delmengd, og dei to må overlappe.

Legacy_Auth-fella

Støtte for Legacy_Auth krev at standardpolicyen til serveren for påkravd kryptering vert lempa. Det er den dokumenterte kompatibilitetskostnaden, og difor er det ei tryggingsendring og ikkje ei retting å senke policyen for å tysse på ein tilkoplingfeil.

Viss ein klient plutseleg feilar etter ein serveroppgradering, samanlikn pluginlistene før du svekkjer noko. Feilen er vanlegvis eit forhandlingsavvik, og svaret er ein støtta plugin på begge sider.

Kontroller sambandet som betyr noko

På ein build som tilbyr kontekstvariabelen, rapporterer denne spørjinga krypteringstilstanden til det gjeldande sambandet:

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

Køyr han gjennom applikasjonen sitt eige samband, ikkje gjennom ein administratorøkt på same server. Eit kryptert administratortilkopling seier ingenting om sesjonen til eit anna klientbibliotek, og ein eldre build som ikkje støttar variabelen er ikkje prov for at kryptering er av.

Noter versjonen til klientbiblioteket, builden til serveren og resultatet saman, fordi ingen av dei åleine er lesbare.

Rettar og oppgraderingsvegen

Å avgrense kjelder og kryptere transport erstattar ikkje autentisering eller rettar etter minst privilegium. Kontroller løyva til den vanlege databasebrukaren på objekta han faktisk rører.

Til slutt, handsam ein langvarig utrulling som eit vedlikehaldsspørsmål. Ein tunnel gjer ikkje eit utdatert klientbibliotek trygt på ubestemd tid, og ein støtta oppgraderingsveg er billegare enn å oppdage at pluginen han treng er fjerna.