Sicherheitsüberblick

Zaris sichert einen Cluster mit drei voneinander unabhängigen Schichten ab: Verschlüsselung bei der Übertragung, Authentifizierung und Autorisierung. Sie aktivieren jede Schicht einzeln, sodass Sie mit einem unverschlüsselten Entwicklungscluster beginnen und die Sicherheit mit wachsenden Anforderungen ergänzen können.

Jede Schicht beantwortet eine andere Frage.

Schicht	Beantwortete Frage	Mechanismus
Verschlüsselung	Kann jemand im Netzwerk den Datenverkehr lesen oder manipulieren?	Transport Layer Security (TLS) auf der Datenebene und der Steuerungsebene.
Authentifizierung	Wer ist dieser Aufrufer?	Signierte Bearer-Tokens, ausgestellt von der Sicherheitsschicht und von jedem Node offline verifiziert.
Autorisierung	Darf dieser Aufrufer dies hier tun?	Rollenbasierte Zugriffskontrolle (RBAC), standardmäßig verweigernd.

Die Schichten bauen aufeinander auf. Die Verschlüsselung schützt die Leitung, die Authentifizierung stellt über diese Leitung eine Identität fest, und die Autorisierung entscheidet, was diese Identität tun darf. Ein Entwicklungscluster kann mit allen drei Schichten deaktiviert laufen. Ein Produktionscluster läuft in der Regel mit allen dreien aktiviert.

Zwei Ebenen, zwei Arten von Schlüsseln

Vor den Schichten hilft eine Unterscheidung, alles Weitere einzuordnen: Zaris hat zwei Ebenen, und sie authentifizieren unterschiedlich, weil sie unterschiedliche Aufrufer bedienen.

Ebene	Wer sie nutzt	Wie sie handeln	Wie sie sich authentifizieren
Steuerungsebene	Menschen und Operatoren	Die Web Console und die Admin-Cmdlets (Clustron.Zaris.AdminShell) — Stores erstellen, Konfiguration ändern, Sicherheitsstatus lesen	Zugangsdaten — ein Benutzername und ein Passwort. Sie melden sich einmal an; die Anmeldung wird gegen ein Session-Token eingetauscht.
Datenebene	Anwendungen und Dienste	Ihre App verbindet sich mit einem Store, um Schlüssel zu lesen und zu schreiben	Ein Token — passwortlos und in sich geschlossen, auf einen Store und eine Rolle beschränkt. Legen Sie es in einer Umgebungsvariable oder einem Kubernetes-Secret ab.

Die Faustregel: Zugangsdaten sind für Menschen, Tokens für Apps. Ein Operator meldet sich mit einem Passwort an (Connect-ZrManager -Credential oder die Anmeldeseite der Console); eine Anwendung legt ein Token vor (Connect-ZrStore -Token oder ein Token in ihrer Connection String). Es gibt auch eine Komfortanmeldung für Apps — Connect-ZrStore -Credential tauscht beim Verbinden einen Benutzernamen und ein Passwort gegen ein Datenebenen-Token ein —, aber das zu merkende Denkmodell lautet: Menschen→Passwort, App→Token.

Console und Cmdlets sind gleichwertig

Fast jede Aktion in diesem Abschnitt lässt sich in der Web Console oder mit einem gleichwertigen AdminShell-Cmdlet ausführen — die Console kommuniziert mit dem Cluster über dieselbe Management-API der Steuerungsebene wie die CLI. Jeder Schritt unten zeigt beide Wege; wählen Sie, was zu Ihrem Workflow passt.

Verschlüsselung mit TLS

TLS ist das Protokoll, das eine Netzwerkverbindung verschlüsselt und es einer Seite erlaubt, sich gegenüber der anderen mit einem Zertifikat auszuweisen. Zaris wendet TLS auf zwei getrennte Ebenen an, die Sie unabhängig voneinander aktivieren und betrachten.

Die Datenebene transportiert den Store-Verkehr — zwischen Clients und Nodes sowie zwischen den Nodes selbst.

• Client zu Node nutzt serverauthentifiziertes TLS. Der Client validiert das Zertifikat jedes Nodes gegen die Cluster-Zertifizierungsstelle (CA, Certificate Authority). Eine CA ist die Instanz, deren Zertifikat die Node-Zertifikate signiert und damit für sie bürgt. Der Client selbst wird dann über sein Token identifiziert, nicht über ein Client-Zertifikat.
• Node zu Node nutzt Mutual TLS (mTLS), wenn der TLS-Mode des Stores MutualTls ist. Bei Mutual TLS legt jede Seite ein Zertifikat vor und validiert das ihres Gegenübers, sodass nur registrierte Mitglieder der Datenebene beitreten. MutualTls ist der Modus, den Zaris standardmäßig anwendet, wenn Sie TLS für einen Store aktivieren.

Die Steuerungsebene ist das HTTPS von Management Service und Web Console. Sie ist von der TLS-Verschlüsselung der Datenebene getrennt und wird unabhängig davon mit Enable-ZrManagementHttps aktiviert. Sie können die Console absichern, ohne den Store-Verkehr zu verschlüsseln, oder umgekehrt.

hinweis

„Mutual TLS“ bezieht sich in Zaris auf die Node-zu-Node-Authentifizierung. Externe Clients legen kein Client-Zertifikat vor. Sie authentifizieren sich mit einem Token über einen serverauthentifizierten TLS-Kanal. Das ist das übliche, skalierbare Muster: Sie stellen pro Client ein Token aus, statt pro Client ein Zertifikat bereitzustellen.

Die Mechanik zum Aktivieren von TLS und dazu, wie jeder Node sein Zertifikat erhält, wird unter TLS-Verschlüsselung behandelt.

Vertrauen: Woher Zertifikate kommen

Der schwierige Teil von TLS ist nicht die Verschlüsselung. Es ist das Vertrauen — welche CA die Node-Zertifikate signiert und wie Clients dieser CA vertrauen lernen. Ein Trust Anchor ist das Zertifikat, dem ein Client als Wurzel der Validierung zu vertrauen konfiguriert ist; jedes Node-Zertifikat muss sich auf ihn zurückführen lassen.

Zaris unterstützt vier Trust-Modelle, damit Sie den Cluster an die bestehende Public-Key-Infrastruktur (PKI) Ihrer Organisation anpassen können, statt sie zu umgehen. Alle vier führen zum selben Endzustand — Nodes legen Zertifikate vor, die Peers und Clients gegen einen Trust Anchor validieren —, unterscheiden sich aber darin, wer den privaten CA-Schlüssel hält und ob Clustron die Node-Zertifikate signiert.

Modus	Wer den privaten CA-Schlüssel hält	Clustron signiert Node-Zertifikate	An Clients verteilter Trust Anchor
Automatisch generiert (Modus 0)	Der Cluster erzeugt eine selbstsignierte CA	Ja	Die generierte Cluster-CA (cluster-ca.crt)
Eigene CA mitbringen (Modus 1)	Sie, und Sie geben den CA-Schlüssel an den Cluster	Ja	Ihre CA-Wurzel
Eigene Intermediate-CA mitbringen (Modus 2)	Sie; Sie geben nur ein Intermediate an den Cluster	Ja	Ihre Enterprise-Wurzel
Vorab ausgestellte Leaf-Zertifikate (Modus 3)	Sie; der Schlüssel wird nie an den Cluster gegeben	Nein	Ihre Wurzel, als Trust Anchor konfiguriert

Die Wahl zwischen ihnen und die genaue Konfiguration für jeden Modus sind Thema von CA- und Trust-Modi. Wenn Sie mit möglichst wenig Aufwand einen sicheren Cluster möchten, verwenden Sie den Default, Automatisch generiert: Der Cluster erzeugt seine eigene CA, stellt jedem Node automatisch ein Zertifikat aus, und Sie verteilen eine öffentliche Datei an die Clients.

Authentifizierung mit Tokens

Ist die Authentifizierung aktiviert, legt jede Client-Verbindung beim Verbindungs-Handshake (dem „Hello“) ein Bearer-Token vor. Ein Bearer-Token ist ein signierter Berechtigungsnachweis, den der Inhaber vorlegt, um seine Identität zu belegen. Das Token ist ein signiertes JSON Web Token (JWT), ausgestellt von der Sicherheitsschicht, der im Management Service eingebetteten Identitätskomponente. Nodes verifizieren das Token offline gegen den öffentlichen Schlüssel des Ausstellers. Auf dem Hot Path gibt es keinen Aufruf pro Request an einen zentralen Auth-Server — die Verifizierung erfolgt einmal pro Verbindung.

Ein Operator meldet sich mit Zugangsdaten an der Steuerungsebene an (Connect-ZrManager -Credential oder die Anmeldeseite der Console). Eine Anwendung erhält ihr Datenebenen-Token entweder durch Anmeldung mit Zugangsdaten beim Verbinden (Connect-ZrStore -Credential, das einen Benutzernamen und ein Passwort gegen ein Token eintauscht) oder — das übliche Muster — indem ein Operator vorab eines ausstellt (New-ZrToken, New-ZrServiceAccount) und es in einem Secret ablegt. Siehe Authentifizierung und Tokens.

Autorisierung mit RBAC

Die Authentifizierung stellt fest, wer. Die Autorisierung entscheidet, was. Zaris delegiert die Autorisierung an die Sicherheitsschicht, die ein rollenbasiertes Modell auswertet, das standardmäßig verweigert — eine Operation wird abgelehnt, sofern nicht eine dem Aufrufer gewährte Rolle sie im jeweiligen Scope ausdrücklich erlaubt.

• Operationen werden Berechtigungen zugeordnet, etwa data.read, data.write sowie Berechtigungen der Steuerungsebene wie store.create.
• Berechtigungen werden über Rollen (zum Beispiel DataReader, DataWriter, ClusterAdmin) gewährt, die an einen Principal in einem Scope gebunden sind — etwa ein einzelner Store versus der gesamte Cluster.
• Scopes sind hierarchische Strings (zaris:cluster, zaris:store:orders). Eine Gewährung auf einem höheren Scope umfasst die darunterliegenden Scopes.

Den Berechtigungskatalog, die vordefinierten Rollen und die Art, sie zu gewähren, finden Sie unter Autorisierung und RBAC.

Wie die Schichten dem Deployment zugeordnet sind

Zaris läuft in zwei Deployment-Modellen, und jedes eignet sich für andere Trust-Modi.

• Supervisor-Modell — der Management Service erstellt und besitzt die Nodes. Jeder Node meldet sich per Enrollment an: Er erzeugt sein Schlüsselpaar lokal und sendet eine Certificate Signing Request (CSR) an den Manager, abgesichert durch ein Einmal-Token. Dies ist die natürliche Heimat der Modi Automatisch generiert, BYO-CA und BYO-Intermediate, in denen Clustron die Signierung übernimmt.
• Attach-Modell — ein externer Orchestrator (zum Beispiel Docker Compose oder Kubernetes) betreibt die Nodes, und der Manager beobachtet nur. Zertifikate werden in jeden Node eingebunden. Dies ist die natürliche Heimat des Modus Vorab ausgestellte Leaf-Zertifikate.

Sie sind nicht festgelegt — die Modi sind Konfiguration —, aber diese Paarungen sind die Wege des geringsten Widerstands. Details zum Deployment finden Sie im Abschnitt Deployment.

Sicherheit aktivieren: die Kurzfassung

Ein vollständig abgesicherter Cluster im Supervisor-Modell besteht aus wenigen Schritten. Beachten Sie die Struktur: Sie sichern die Steuerungsebene einmal ab und danach die Datenebene für jeden Store.

# 1. CONTROL PLANE — bootstrap security and create the first admin login (username + password).
#    Enforcement turns on across all managers; the console and admin cmdlets now require sign-in.
Initialize-ZrSecurity -AdminSubject admin -AdminPassword (Read-Host -AsSecureString)

# 2. DATA PLANE — require a token to connect to the store, and encrypt its traffic. Per store.
Enable-ZrStoreSecurity -Store orders -Restart   # nodes now verify caller tokens
Enable-ZrStoreTls      -Store orders -Restart   # MutualTls node-to-node; clients use CA + token

# 3. Issue a token for an application (passwordless, scoped to the store and a data role).
New-ZrToken -Subject orders-app -Role DataWriter -Scope zaris:store:orders

# 4. Export the public cluster CA for clients (optional — clients can auto-fetch it at sign-in).
Get-ZrClusterCaCert -OutFile cluster-ca.crt

# 5. The application connects over TLS, presenting its token.
Connect-ZrStore -ConnectionString "zariss://10.0.0.10:7861/orders?token=env:ORDERS_TOKEN&ca=file:cluster-ca.crt"

Cluster-Sicherheit aktiv ≠ Ihr Store ist abgesichert

Schritt 1 sichert nur die Steuerungsebene ab — die Console und die Admin-Cmdlets. Solange Sie Enable-ZrStoreSecurity nicht für einen Store ausgeführt haben (Schritt 2), bleibt die Datenebene dieses Stores offen: Eine Anwendung kann sich weiterhin ohne Token verbinden und jeden Schlüssel lesen. Ebenso ergibt das Aktivieren von TLS allein einen verschlüsselten, aber nicht authentifizierten Store — Verschlüsselung ist keine Authentifizierung. Sichern Sie jeden Store ab, der Ihnen wichtig ist: zuerst das Token, dann TLS.

Jeder der obigen Schritte hat auch ein Web-Console-Pendant — der Bereich Security & TLS aktiviert die Cluster-Sicherheit, die Token-Pflicht pro Store und TLS pro Store und stellt Tokens auf den Tabs People/Applications aus. Die vollständige Klick-für-Klick- und Cmdlet-Anleitung finden Sie unter Einen Store durchgängig absichern. Jedes Konzept wird auf den folgenden Seiten ausführlich erklärt.

Nächste Schritte

• Einen Store durchgängig absichern — der vollständige Happy Path (Console und Cmdlets): Sicherheit aktivieren, ein Token verlangen, TLS aktivieren, ein Token ausstellen, eine App verbinden.
• TLS-Verschlüsselung — TLS und Mutual TLS aktivieren und sehen, wie Nodes Zertifikate erhalten.
• CA- und Trust-Modi — die vier Trust-Modelle im Detail, mit der Konfiguration für jedes.
• Authentifizierung und Tokens — Authentifizierung aktivieren, sich als Operator anmelden und Tokens ausstellen.
• Autorisierung und RBAC — Berechtigungen, Rollen und Scopes.