Cassandra über VPN: getrennter Zugang für Clients und Knoten

Eine Cassandra-Bereitstellung hat kein einheitliches Datenbanknetz. Anwendungen sprechen mit dem Clientdienst, Cluster-Mitglieder sprechen miteinander, und Operatoren nutzen administrative Schnittstellen, und diese drei Zielgruppen sollten die Erreichbarkeit der jeweils anderen nicht erben. Ein privater Pfad wie ein VPN ist ein guter Ausgangspunkt, aber er ist nicht die Benutzeridentität der Datenbank und nicht ihre Verschlüsselungsrichtlinie. Behandeln Sie die Entscheidung über die Konnektivität und die Entscheidung über die Autorisierung als zwei getrennte Prüfungen.

Jede der drei Zielgruppen bekommt ihre eigene Antwort, und die Abschnitte unten behandeln sie in der Reihenfolge ihrer Exposition.

Drei Zielgruppen, drei Entscheidungen

Ermitteln Sie, was jede Gruppe tatsächlich braucht, bevor Sie eine Regel anfassen. Clients brauchen den Client-Listener und genug Informationen, um jeden Knoten zu erreichen, der ihnen zugewiesen werden kann, Peerknoten brauchen einander auf dem Internode-Port, und Operatoren brauchen die Verwaltungsschnittstelle für das, was das Runbook tatsächlich verlangt. Drei Listen, drei Zielgruppen, drei Vertrauensstufen.

Der häufige Fehler ist, ein flaches privates Segment zu bauen und anzunehmen, die VPN-Grenze erledige den Rest. Darin kann eine Anwendung, die den Client-Port erreicht, meist auch den Internode-Port erreichen, und die administrativen Werkzeuge eines Operators sitzen oft auf demselben Jump-Host wie die Anwendung. Diese Ebenen zusammenzulegen bedeutet, dass eine kompromittierte Anwendungsidentität bereits mehr Reichweite hat als ihre eigenen Abfragen. Zeichnen Sie die drei Zielgruppen als drei Zeilen im Designdokument, jede mit der Regel, die sie erlaubt, und die Lücken werden sichtbar, bevor jemand sie baut.

Was Clients brauchen, und nichts mehr

Erlauben Sie den vorgesehenen Anwendungsquellen den Zugriff auf die Client-Endpunkte für die bereitgestellte Version und halten Sie unabhängige Cluster- und Verwaltungsdienste aus dieser Reichweite heraus. Prüfen Sie dann, wie der Treiber Knoten entdeckt. Ein erreichbarer erster Kontaktpunkt belegt nicht, dass jede Knotenadresse, die der Treiber danach auswählt, aus diesem Client-Kontext erreichbar ist, weil der Treiber den Cluster nach Peers fragt und sich dann mit den Adressen verbindet, die der Cluster bekannt gibt.

Deshalb erzeugt eine einzige Abweichung bei privaten Adressen das vertraute Muster: eine erfolgreiche erste Verbindung, gefolgt von Zeitüberschreitungen. Konfigurieren Sie bekannt gegebene Adressen und Client-Routing bewusst; den ganzen Cluster ins Internet zu veröffentlichen, um eine Abweichung zu reparieren, tauscht einen Routingfehler gegen eine Exposition, die Sie nicht zurücknehmen können.

Behalten Sie auch die Datenbankauthentifizierung der Anwendung und die Rollenberechtigungen bei. Eine gemeinsam genutzte übersetzte VPN-Adresse kann für viele Benutzer oder Dienste stehen, ist also nie ein Ersatz für getrennte Datenbankidentitäten.

Verschlüsseln Sie Client-zu-Knoten und Internode getrennt

Apaches Sicherheitsdokumentation behandelt Client-zu-Knoten- und Internode-Verschlüsselung als getrennte Konfigurationen, und das Aktivieren der einen aktiviert die andere nicht. Dieser Unterschied gilt auch innerhalb eines VPN, weil der Tunnel sein eigenes Segment schützt und sich nicht automatisch vom Anwendungsprozess zum Datenbankprozess oder zwischen jedem Paar von Cluster-Mitgliedern erstreckt.

Eine Konfiguration, die beide ausdrücklich einschaltet, statt eine Vorlagenvorgabe zu erben, sieht ungefähr so aus:

client_encryption_options:
  enabled: true
  optional: false
server_encryption_options:
  internode_encryption: all

Bei Serverkonfigurationen, die optionale Client-Verschlüsselung zulassen, kann das Akzeptieren von TLS neben dem Akzeptieren unverschlüsselter Verbindungen bestehen, lesen Sie also die wirksame Richtlinie statt die Absicht. Planen Sie Zertifikatsnamen, Vertrauensverteilung und Erneuerung für die Endpunkte, die jeder Client tatsächlich kontaktiert; einen Hostnamen durch eine IP-Adresse zu ersetzen ändert die Identitätsprüfung des Clients, nicht nur seine Route.

Halten Sie die Administration auf ihrem eigenen Pfad

Internode-Verkehr braucht die erlaubte Peermenge und eine eigene Schutzrichtlinie. Administrativer Zugriff, einschließlich JMX wo es verwendet wird, braucht eine getrennte Zielgruppe und eine eigene Authentifizierung. Eine Anwendung, die gewöhnliche Abfragen stellen darf, braucht dadurch nicht jede Verwaltungsfunktion, und das Umgekehrte ist schlimmer: ein administrativer Pfad, der dem Anwendungssegment ausgesetzt ist, ist der kürzeste Weg von einem Fehler zum Neuaufbau. Schreiben Sie diese beiden Zielgruppen getrennt auf und benennen Sie ihre Verantwortlichen, denn es sind meist verschiedene Teams, deren Regeln versehentlich zusammengelegt wurden.

Halten Sie wirksame Cloud-Regeln, Host-Regeln und Listener-Konfiguration im Einklang. Ein privater Listener kann weiterhin über eine unbeabsichtigte Übersetzung oder einen Proxy offen stehen, und eine breite öffentliche Regel kann still neben einer engen VPN-Regel stehen, bis jemand beide gleichzeitig prüft.

Wo Operatoren wirklich einen Verwaltungspfad brauchen, geben Sie ihm einen benannten Verantwortlichen und eine kürzere Lebensdauer der Anmeldedaten als die der Anwendung. Das hält die Delegation sichtbar, wenn die nächste Person den Cluster übernimmt.

Was das Design verspricht

Prüfen Sie alle drei Versprechen mit echten Rollen statt nur mit Konnektivitätstests. Eine genehmigte Anwendung sollte ihre erlaubte Arbeit erledigen und nichts weiter, eine ausgeschlossene Quelle sollte am Client-Eingang scheitern, und eine Anwendungsidentität sollte an den reservierten Administrationspfaden abgelehnt werden. Nehmen Sie Client-Wiederverbindung und Knotenauswahl in denselben Rollout-Test auf, denn dort treten Entdeckungsfehler zutage.

Schließen Sie mit drei Sätzen im Designdokument: welche Clients abfragen dürfen, welche Knoten kommunizieren dürfen und welche Operatoren administrieren dürfen. Hinter einem VPN zu stehen ist nützliche Topologieinformation, aber es ist keine Antwort auf eine dieser drei Fragen.