Wire-Verschlüsselung in Firebird 3 und das VPN sind zwei Grenzen

Das VPN verbindet, der Client öffnet eine Sitzung, und alle gehen davon aus, dass die Datenbankverbindung gesichert ist. Da wurden gerade drei verschiedene Dinge vermischt. Ob der Listener überhaupt erreichbar ist, ob der Server den Benutzer akzeptiert hat und ob Firebird Wire-Verschlüsselung ausgehandelt hat, sind getrennte Mechanismen mit getrennten Nachweisen. Ein Tunnel beantwortet nur die erste Frage, und das nur für die Quellen, die Sie zugelassen haben.

Zwei Grenzen, die sich nicht überschneiden

Die VPN-Grenze schützt Pakete zwischen einem Client und einem Gateway. Firebirds Wire-Verschlüsselung schützt das Datenbankprotokoll zwischen der Clientbibliothek und dem Serverprozess. Beide können vorhanden sein, und keine ersetzt die andere.

Endet der Tunnel vor dem Datenbankhost, ist der Verkehr dahinter nur durch das geschützt, was die Datenbanksitzung ausgehandelt hat. Genau in dieser Lücke findet eine Prüfung meist die Überraschung. Das Tunneldiagramm endet an einem Gateway, und die Verbindung, die Ihre Abfrage trägt, läuft darüber hinaus weiter. Wer dieses Diagramm später liest, erbt die Annahme.

Grenze eins: Wer den Listener öffnen darf

Ermitteln Sie die echte Serveradresse und den konfigurierten Port, der 3050 ist, sofern er nicht geändert wurde, und erlauben Sie dann nur die freigegebenen VPN-Quellen an der Host- und der Netzwerkfirewall. Berücksichtigen Sie jede Adressübersetzung am VPN-Gateway, und geben Sie dem Datenbankhost eine Rückroute zum Client-Pool, wenn das Gateway getrennt ist.

Dann beweisen Sie das Negative. Ein externer Pfad, der abgelehnt werden soll, muss weiterhin abgelehnt werden, denn das Öffnen des Tunnels beschränkt den Firebird-Listener nicht von selbst.

Grenze zwei: Was Firebird aushandelt

Firebird 3 führte ein Framework für Wire-Verschlüsselung mit einer Serverrichtlinie ein, die deaktiviert, aktiviert oder erforderlich sein kann. Die Richtlinie setzt die Untergrenze. Die tatsächliche Sitzung hängt weiterhin von der Clientbibliothek ab, die die Anwendung lädt, und von den Plugins, die beide Seiten unterstützen.

In den Versionshinweisen zu Firebird 3 wird Arc4 als Standard-Plugin für die Wire-Verschlüsselung dieser Version genannt. Arc4 ist ein historischer Standard, keine Empfehlung für eine moderne Chiffre, und es ist nicht dasselbe wie der äußere VPN-Schutz.

Die Authentifizierung ist eine dritte Variable in derselben Aushandlung. Der Server akzeptiert eine Reihe von Authentifizierungs-Plugins, die Clientbibliothek bietet eine Teilmenge davon an, und beide müssen sich überschneiden.

Die Legacy_Auth-Falle

Die Unterstützung von Legacy_Auth erfordert, dass die standardmäßige Pflicht-Verschlüsselungsrichtlinie des Servers gelockert wird. Das sind die dokumentierten Kompatibilitätskosten, und deshalb ist das Herabsetzen der Richtlinie, um einen Verbindungsfehler stumm zu stellen, eine Sicherheitsänderung und keine Reparatur.

Wenn ein Client nach einem Server-Upgrade plötzlich scheitert, vergleichen Sie die Plugin-Listen, bevor Sie irgendetwas abschwächen. Der Fehler ist meist eine Aushandlungsdiskrepanz, und die Antwort ist ein unterstütztes Plugin auf beiden Seiten.

Prüfen Sie die Verbindung, auf die es ankommt

Auf einem Build, der die Kontextvariable bereitstellt, meldet diese Abfrage den Verschlüsselungszustand der aktuellen Verbindung:

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

Führen Sie sie über die eigene Verbindung der Anwendung aus, nicht über eine Administratorsitzung auf demselben Server. Eine verschlüsselte Admin-Verbindung sagt nichts über die Sitzung einer anderen Clientbibliothek aus, und ein älterer Build ohne Unterstützung der Variable ist kein Beweis dafür, dass die Verschlüsselung aus ist.

Halten Sie Clientbibliotheksversion, Server-Build und Ergebnis zusammen fest, denn jedes davon allein ist nicht lesbar.

Berechtigungen und der Upgrade-Pfad

Quellen zu beschränken und den Transport zu verschlüsseln ersetzt weder Authentifizierung noch Berechtigungen nach dem Least-Privilege-Prinzip. Prüfen Sie die Rechte des gewöhnlichen Datenbankbenutzers auf den Objekten, die er tatsächlich berührt.

Behandeln Sie zuletzt ein langlebiges Deployment als Wartungsfrage. Ein Tunnel macht eine veraltete Clientbibliothek nicht unbegrenzt sicher, und ein unterstützter Upgrade-Pfad ist billiger, als festzustellen, dass das benötigte Plugin entfernt wurde.