Wire-kryptering i Firebird 3 og VPN er to forskellige grænser

VPN'en opretter forbindelse, klienten åbner en session, og alle antager, at databaseforbindelsen er sikret. Tre forskellige ting blev netop blandet sammen. Om listeneren overhovedet kan nås, om serveren accepterede brugeren, og om Firebird forhandlede wire-kryptering, er adskilte mekanismer med adskilt dokumentation. En tunnel besvarer kun det første, og kun for de kilder, du tillod.

To grænser, og de overlapper ikke

VPN-grænsen beskytter pakker mellem en klient og en gateway. Firebirds wire-kryptering beskytter databaseprotokollen mellem klientbiblioteket og serverprocessen. Begge kan være til stede, og ingen af dem erstatter den anden.

Hvis tunnelen slutter før databaseserveren, beskyttes trafikken bag den kun af det, databasesessionen forhandlede. Det er i det gab, en gennemgang normalt finder overraskelsen. Tunneldiagrammet slutter ved en gateway, og forbindelsen, der bærer din forespørgsel, fortsætter forbi den. Enhver, der læser diagrammet senere, arver antagelsen.

Grænse et: hvem kan åbne listeneren

Identificér den rigtige serveradresse og den konfigurerede port, som er 3050, medmindre den er ændret, og tillad derefter kun de godkendte VPN-kilder i værts- og netværksfirewallen. Tag højde for eventuel adresseoversættelse på VPN-gatewayen, og giv databaseserveren en returrute til klientpuljen, hvis gatewayen er adskilt.

Bevis så det negative. En ekstern vej, der bør afvises, skal stadig afvises, fordi åbningen af tunnelen ikke i sig selv begrænser Firebirds listener.

Grænse to: hvad Firebird forhandler

Firebird 3 indførte en ramme for wire-kryptering med en serverpolitik, der kan deaktiveres, aktiveres eller kræves. Politikken sætter gulvet. Den faktiske session afhænger stadig af det klientbibliotek, applikationen indlæser, og de plugins, begge sider understøtter.

I udgivelsesnoterne til Firebird 3 er Arc4 angivet som standard-plugin til wire-kryptering for den udgivelse. Arc4 er en historisk standard, ikke en anbefaling af et moderne cipher, og det er ikke det samme som den ydre VPN-beskyttelse.

Godkendelse er en tredje variabel i samme forhandling. Serveren accepterer et sæt godkendelses-plugins, klientbiblioteket tilbyder en delmængde, og de to skal overlappe.

Legacy_Auth-fælden

Understøttelse af Legacy_Auth kræver, at serverens standardpolitik for krævet kryptering lempes. Det er den dokumenterede kompatibilitetsomkostning, og derfor er det en sikkerhedsændring og ikke en rettelse at sænke politikken for at tysse en forbindelsesfejl.

Hvis en klient pludselig fejler efter en serveropgradering, så sammenlign pluginlister, før du svækker noget. Fejlen er normalt en uoverensstemmelse i forhandlingen, og svaret er et understøttet plugin på begge sider.

Kontrollér den forbindelse, der betyder noget

På en build, der stiller kontekstvariablen til rådighed, rapporterer denne forespørgsel krypteringstilstanden for den aktuelle forbindelse:

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

Kør den gennem applikationens egen forbindelse, ikke gennem en administratorsession på samme server. En krypteret admin-forbindelse siger intet om en anden klientbiblioteks session, og en ældre build, der ikke understøtter variablen, er ikke bevis for, at krypteringen er slukket.

Notér klientbibliotekets version, serverens build og resultatet sammen, fordi hver af dem alene er ulæselig.

Rettigheder og opgraderingsvejen

At begrænse kilder og kryptere transport erstatter ikke godkendelse eller rettigheder efter mindst-privilegium-princippet. Kontrollér den almindelige databasebrugers tilladelser på de objekter, den faktisk rører.

Endelig bør du behandle en langvarig udrulning som et vedligeholdelsesspørgsmål. En tunnel gør ikke et forældet klientbibliotek sikkert på ubestemt tid, og en understøttet opgraderingsvej er billigere end at opdage, at det plugin, den har brug for, er blevet fjernet.