Wire-kryptering i Firebird 3 och VPN är två olika gränser

VPN:en ansluter, klienten öppnar en session och alla antar att databasanslutningen är skyddad. Tre olika saker blandades just ihop. Om lyssnaren alls är nåbar, om servern accepterade användaren och om Firebird förhandlade wire-kryptering är separata mekanismer med separata bevis. En tunnel svarar bara på det första, och bara för de källor du tillät.

Två gränser, och de överlappar inte

VPN-gränsen skyddar paket mellan en klient och en gateway. Firebirds wire-kryptering skyddar databasprotokollet mellan klientbiblioteket och serverprocessen. Båda kan finnas, och ingen av dem ersätter den andra.

Om tunneln slutar före databasvärden skyddas trafiken bakom den bara av det databassessionen förhandlade. Det är i den luckan en granskning vanligtvis hittar överraskningen. Tunneldiagrammet slutar vid en gateway, och anslutningen som bär din fråga fortsätter förbi den. Den som läser diagrammet senare ärver antagandet.

Gräns ett: vem som får öppna lyssnaren

Identifiera serverns verkliga adress och den konfigurerade porten, som är 3050 om den inte ändrats, tillåt sedan bara de godkända VPN-källorna i värdens och nätverkets brandvägg. Ta hänsyn till eventuell adressöversättning i VPN-gatewayen, och ge databasvärden en returväg till klientpoolen om gatewayen är separat.

Bevisa sedan det negativa. En extern väg som ska nekas måste fortfarande nekas, eftersom öppningen av tunneln inte begränsar Firebirds lyssnare i sig.

Gräns två: vad Firebird förhandlar

Firebird 3 införde ett ramverk för wire-kryptering med en serverpolicy som kan inaktiveras, aktiveras eller krävas. Policyn sätter golvet. Den faktiska sessionen beror fortfarande på klientbiblioteket som programmet laddar och de plugins som båda sidor stöder.

I utgivningsanteckningarna för Firebird 3 anges Arc4 som standardplugin för wire-kryptering för den utgåvan. Arc4 är en historisk standard, inte en rekommendation av en modern chiffer, och det är inte samma sak som det yttre VPN-skyddet.

Autentisering är en tredje variabel i samma förhandling. Servern accepterar en uppsättning autentiseringsplugins, klientbiblioteket erbjuder en delmängd, och de två måste överlappa.

Legacy_Auth-fällan

Stöd för Legacy_Auth kräver att serverns standardpolicy för obligatorisk kryptering luckras upp. Det är den dokumenterade kompatibilitetskostnaden, och därför är det en säkerhetsändring och inte en rättelse att sänka policyn för att tysta ett anslutningsfel.

Om en klient plötsligt misslyckas efter en serveruppgradering, jämför pluginlistorna innan du försvagar något. Felet är vanligtvis en förhandlingsdiskrepans, och svaret är en plugin som stöds på båda sidor.

Kontrollera anslutningen som spelar roll

På en build som tillhandahåller kontextvariabeln rapporterar den här frågan krypteringsstatusen för den aktuella anslutningen:

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

Kör den genom programmets egen anslutning, inte genom en administratörssession på samma server. En krypterad administratörsanslutning säger ingenting om en annan klientbibliotekssession, och en äldre build som inte stöder variabeln är inte bevis för att krypteringen är av.

Notera klientbibliotekets version, serverns build och resultatet tillsammans, eftersom ingen av dem ensam är läsbar.

Behörigheter och uppgraderingsvägen

Att begränsa källor och kryptera transport ersätter inte autentisering eller behörigheter enligt minsta privilegium. Kontrollera den vanliga databasanvändarens behörigheter på de objekt den faktiskt rör.

Behandla slutligen en långvarig driftsättning som en underhållsfråga. En tunnel gör inte ett föråldrat klientbibliotek säkert i oändlighet, och en stödd uppgraderingsväg är billigare än att upptäcka att plugin-programmet den behöver har tagits bort.