TLS, Netzzugang und SQL-Rechte beantworten unterschiedliche Fragen
Eine Verbindung verschlüsseln, eine Quelle zulassen und eine Tabelle freigeben sind drei Entscheidungen. Gehen Sie sie der Reihe nach durch, bevor Sie fragen, ob TLS ein VPN ersetzen kann.
Jemand schlägt vor, einem Kunden einen PostgreSQL-Zugang zu geben, damit eine Spesenabrechnung durchgehend verschlüsselt übertragen wird. Ein Datenbankadministrator braucht eine echte SQL-Sitzung, und jemand anderes schlägt stattdessen ein Webformular vor. Beide Vorschläge lösen das falsche Problem, weil keiner bei dem Vorgang begann, den der Client tatsächlich ausführt. Gehen Sie die drei Entscheidungen der Reihe nach durch, und die Frage, ob TLS ein VPN ersetzen kann, beantwortet sich selbst.
Beginnen Sie beim Vorgang, den der Client braucht
Schreiben Sie auf, was der Client erreichen muss. Eine Spesenabrechnung einreichen, eine Zeile eines Berichts lesen und eine Ad-hoc-Abfrage ausführen sind drei verschiedene Vorgänge mit drei verschiedenen Risikoprofilen.
Schreiben Sie dann auf, wer die Anfrage stellt. Ein Kunde, ein Supportmitarbeiter und ein Administrator sind nicht austauschbar, auch wenn sie dieselbe Tabelle berühren. Der Unterschied entscheidet, wie viel von der Abfragesprache der Client überhaupt sehen sollte.
Das Antwortpaar entscheidet über die Schnittstelle. Alles danach ist Umsetzung, und die meisten Diskussionen über Verschlüsselung sind eigentlich Diskussionen darüber, welche Schnittstelle gewählt wurde.
Drei Kontrollen, drei Entscheidungen
Authentifiziertes TLS schützt die Verbindung und entscheidet, welche TLS-Identitäten akzeptiert werden. Der Netzzugang entscheidet, welche Quellen den Listener überhaupt erreichen dürfen. Die Datenbankautorisierung entscheidet, welche Objekte und Aktionen eine Rolle verwenden darf.
Keine der drei ersetzt die anderen, was die Tabelle ausdrücklich zeigt.
| Control | What it decides | What it leaves open |
|---|---|---|
| Authenticated TLS | Connection protection and which TLS identities are accepted | Which tables a database user may touch |
| Restricted network entry | Which sources reach the listener | Whether an authenticated user should run a given statement |
| Database authorization | Which objects and actions a role may use | Whether the connection arrived by an approved path |
Lesen Sie die Zeile, auf die Sie sich verlassen, bevor Sie eine andere entfernen. Die meisten dieser Entwürfe scheitern, weil eine Kontrolle angenommen statt konfiguriert wurde.
Direktes SQL lässt die Datenbankrichtlinie das Sagen behalten
Bei einer genehmigten direkten Verbindung behalten Sie sowohl die Prüfung der Dienstidentität als auch die vorgesehene Zugriffsrichtlinie bei. TLS einzuschalten macht verschlüsselte Verbindungen verfügbar; es weist unverschlüsselte nicht ab, es sei denn, die Zugriffskonfiguration verlangt dies über hostssl-Einträge.
Dieser Unterschied sollte in der laufenden Konfiguration geprüft werden und nicht in einer Vorlage. Ein Server, der TLS anbietet und Klartext akzeptiert, ist nicht das Design, das die meisten glauben bereitgestellt zu haben. Lesen Sie die Zugriffsregeln und sehen Sie, welche Einträge es tatsächlich verlangen. Diese eine Prüfung trennt einen verschlüsselungsfähigen Server von einem nur verschlüsselten.
Verwenden Sie Rollen nur mit den Rechten, die die Aufgabe braucht, und prüfen Sie Eigentümerschaft, geerbte Mitgliedschaft und breit erteilte Berechtigungen. Das PostgreSQL-Berechtigungsmodell ist die Autoritätsgrenze für Datenbankobjekte.
Ein VPN kann einschränken, welche Geräte den Dienst erreichen, bevor die Datenbankauthentifizierung stattfindet, und ein Zugangsgateway kann etwas Ähnliches tun. Keines von beiden ersetzt die Pflege der exponierten Komponente, die Verwaltung von Anmeldedaten und die Begrenzung der Ressourcennutzung.
Clientzertifikate sind ein Nachweis, keine ACL
Ein Clientzertifikat kann beim Verbindungsaufbau eine Anforderung hinzufügen. Die Einstellung clientcert kann ein vertrauenswürdiges Zertifikat verlangen und im strengeren Modus eine Beziehung zwischen dem Zertifikatsnamen und dem Datenbankbenutzer.
Das ist ein stärkerer Nachweis. Es ist keine Autorisierungsliste, und es macht den Server nicht unsichtbar, weil die Komponente, die die Verbindung annimmt, weiterhin Netzwerkverkehr und einen Handshake verarbeitet. Ein Zertifikat als Zugriffsliste zu behandeln lässt die tatsächlichen Berechtigungen unberührt. Es neigt außerdem dazu, die Zertifikatsverteilung auszuweiten, was das nächste Problem schafft.
Ein starkes Zertifikat an einer überprivilegierten Rolle erzeugt einen gut authentifizierten Administrator. Prüfen Sie die Rolle, bevor Sie das Zertifikat feiern.
Wählen Sie die engere Schnittstelle, wenn sie passt
Für eine Spesenabrechnung stellt ein Anwendungsendpunkt, der die Abrechnung annimmt, die Geschäftsregeln durchsetzt und das zulässige Ergebnis dieses Nutzers zurückgibt, den Vorgang besser dar als ein allgemeines SQL-Konto.
Die Anwendung nutzt dann ihre eigene eingeschränkte Datenbankidentität, und der Kunde erhält nie eine Abfragesprache als Funktion. Das ist eine kleinere Oberfläche mit weniger Möglichkeiten, falsch zu liegen.
Dies ist eine Designoption und nicht die Behauptung, Anwendungscode sei automatisch sicherer. Dieser Code muss seine Aufrufer authentifizieren, jede Aktion autorisieren und seine Eingaben validieren, und seine eigenen Datenbankberechtigungen zählen weiterhin.
Direktes SQL bleibt richtig für Menschen und Werkzeuge, deren genehmigte Aufgabe es verlangt. Qualifizieren Sie dieses Design mit Rollen, Netzwerkumfang und Betriebsgrenzen, und lassen Sie die anderen Clients die engere Schnittstelle behalten. Die beiden Gruppen in einer Rolle zu mischen, ist der Punkt, an dem die Diskussionen beginnen.