Présentation de la sécurité

Zaris sécurise un cluster avec trois couches indépendantes : chiffrement en transit, authentification et autorisation. Vous activez chaque couche indépendamment, de sorte que vous pouvez démarrer avec un cluster de développement en clair et ajouter de la sécurité à mesure que vos exigences grandissent.

Chaque couche répond à une question différente.

Couche	Question à laquelle elle répond	Mécanisme
Chiffrement	N'importe qui sur le réseau peut-il lire ou altérer le trafic ?	Transport Layer Security (TLS) sur le plan de données et le plan de contrôle.
Authentification	Qui est cet appelant ?	Tokens porteurs (bearer) signés, émis par la couche de sécurité et vérifiés hors ligne par chaque nœud.
Autorisation	Cet appelant est-il autorisé à faire ceci, ici ?	Contrôle d'accès basé sur les rôles (RBAC), refus par défaut.

Les couches s'appuient les unes sur les autres. Le chiffrement protège le tuyau, l'authentification établit une identité sur ce tuyau, et l'autorisation décide ce que cette identité peut faire. Un cluster de développement peut fonctionner avec les trois désactivées. Un cluster de production exécute généralement les trois activées.

Deux plans, deux types de clé

Avant les couches, une distinction fait tout le reste tomber en place : Zaris possède deux plans, et ils s'authentifient différemment parce qu'ils servent des appelants différents.

Plan	Qui l'utilise	Comment ils agissent	Comment ils s'authentifient
Plan de contrôle	Personnes et opérateurs	La console web et les cmdlets d'administration (Clustron.Zaris.AdminShell) — créer des stores, modifier la configuration, lire l'état de sécurité	Identifiants — un nom d'utilisateur et un mot de passe. Vous vous connectez une fois ; la connexion est échangée contre un token de session.
Plan de données	Applications et services	Votre application se connectant à un store pour lire et écrire des clés	Un token — sans mot de passe et autonome, limité à un store et un rôle. Déposez-le dans une variable d'environnement ou un secret Kubernetes.

La règle empirique : les identifiants sont pour les personnes, les tokens pour les applications. Un opérateur se connecte avec un mot de passe (Connect-ZrManager -Credential, ou la page de connexion de la console) ; une application présente un token (Connect-ZrStore -Token, ou un token dans sa chaîne de connexion). Une connexion de commodité pour les applications existe également — Connect-ZrStore -Credential échange un nom d'utilisateur/mot de passe contre un token de plan de données lors de la connexion — mais le modèle mental à retenir est personnes→mot de passe, application→token.

La console et les cmdlets sont à parité

Presque chaque action de cette section peut être effectuée dans la console web ou avec une cmdlet AdminShell équivalente — la console parle au cluster à travers la même API de gestion du plan de contrôle que la CLI utilise. Chaque étape ci-dessous montre les deux chemins ; choisissez celui qui convient à votre flux de travail.

Chiffrement avec TLS

TLS est le protocole qui chiffre une connexion réseau et permet à une partie de prouver son identité à l'autre au moyen d'un certificat. Zaris applique TLS à deux plans distincts, que vous activez et raisonnez indépendamment.

Le plan de données transporte le trafic du store — entre les clients et les nœuds, et entre les nœuds eux-mêmes.

• Client vers nœud utilise un TLS à authentification serveur. Le client valide le certificat de chaque nœud par rapport à l'autorité de certification (CA) du cluster. Une CA est l'entité dont le certificat signe — et donc cautionne — les certificats des nœuds. Le client lui-même est alors identifié par son token, et non par un certificat client.
• Nœud vers nœud utilise un TLS mutuel (mTLS) lorsque le Mode TLS du store est MutualTls. En TLS mutuel, chaque partie présente un certificat et valide celui de son pair, de sorte que seuls les membres enrôlés rejoignent le plan de données. MutualTls est le mode que Zaris applique par défaut lorsque vous activez TLS sur un store.

Le plan de contrôle est le HTTPS du service de gestion et de la console web. Il est distinct du TLS du plan de données et s'active indépendamment avec Enable-ZrManagementHttps. Vous pouvez sécuriser la console sans chiffrer le trafic du store, ou l'inverse.

remarque

Le « TLS mutuel » dans Zaris fait référence à l'authentification nœud-à-nœud. Les clients externes ne présentent pas de certificat client. Ils s'authentifient avec un token sur un canal TLS à authentification serveur. C'est le modèle standard et scalable : vous émettez un token par client au lieu de provisionner un certificat par client.

Les mécanismes d'activation de TLS, et la façon dont chaque nœud obtient son certificat, sont traités dans Chiffrement TLS.

Confiance : d'où viennent les certificats

La partie difficile de TLS n'est pas le chiffrement. C'est la confiance — quelle CA signe les certificats des nœuds, et comment les clients en viennent à faire confiance à cette CA. Une ancre de confiance est le certificat qu'un client est configuré pour approuver comme racine de la validation ; chaque certificat de nœud doit remonter jusqu'à elle.

Zaris prend en charge quatre modèles de confiance afin que vous puissiez aligner le cluster sur l'infrastructure à clé publique (PKI) existante de votre organisation plutôt que de la contourner. Les quatre produisent le même état final — les nœuds présentent des certificats que les pairs et les clients valident par rapport à une ancre de confiance — mais ils diffèrent par qui détient la clé privée de la CA et par le fait que Clustron signe ou non les certificats des nœuds.

Mode	Qui détient la clé privée de la CA	Clustron signe les certificats des nœuds	Ancre de confiance distribuée aux clients
Auto-générée (Mode 0)	Le cluster génère une CA auto-signée	Oui	La CA de cluster générée (cluster-ca.crt)
Apportez votre propre CA (Mode 1)	Vous, et vous donnez la clé de la CA au cluster	Oui	La racine de votre CA
Apportez votre propre intermédiaire (Mode 2)	Vous ; vous ne donnez qu'un intermédiaire au cluster	Oui	La racine de votre entreprise
Feuilles pré-émises (Mode 3)	Vous ; la clé n'est jamais donnée au cluster	Non	Votre racine, configurée comme ancre de confiance

Choisir entre eux, et la configuration exacte de chacun, fait l'objet de CA et modes de confiance. Si vous voulez un cluster sécurisé avec le moindre effort, utilisez le mode par défaut, Auto-générée : le cluster frappe sa propre CA, émet automatiquement un certificat à chaque nœud, et vous distribuez un seul fichier public aux clients.

Authentification avec des tokens

Lorsque l'authentification est activée, chaque connexion client présente un token porteur lors du handshake de connexion (le « Hello »). Un token porteur est un identifiant signé que le détenteur présente pour prouver son identité. Le token est un JSON Web Token (JWT) signé, émis par la couche de sécurité, le composant d'identité intégré au service de gestion. Les nœuds vérifient le token hors ligne par rapport à la clé publique de l'émetteur. Il n'y a pas d'appel par requête vers un serveur d'authentification central sur le chemin critique — la vérification a lieu une fois par connexion.

Un opérateur se connecte au plan de contrôle avec un identifiant (Connect-ZrManager -Credential, ou la page de connexion de la console). Une application obtient son token de plan de données soit en se connectant avec un identifiant lors de la connexion (Connect-ZrStore -Credential, qui échange un nom d'utilisateur et un mot de passe contre un token), soit — le modèle habituel — en faisant émettre un token à l'avance par un opérateur (New-ZrToken, New-ZrServiceAccount) et en le déposant dans un secret. Voir Authentification et tokens.

Autorisation avec RBAC

L'authentification établit le qui. L'autorisation décide le quoi. Zaris délègue l'autorisation à la couche de sécurité, qui évalue un modèle basé sur les rôles en refus par défaut — une opération est refusée à moins qu'un rôle accordé à l'appelant ne l'autorise explicitement à la portée pertinente.

• Les opérations correspondent à des permissions telles que data.read, data.write et des permissions de plan de contrôle comme store.create.
• Les permissions sont accordées via des rôles (par exemple DataReader, DataWriter, ClusterAdmin) liés à un principal à une portée — par exemple, un seul store par opposition à l'ensemble du cluster.
• Les portées sont des chaînes hiérarchiques (zaris:cluster, zaris:store:orders). Un octroi à une portée supérieure couvre les portées qui lui sont subordonnées.

Voir Autorisation et RBAC pour le catalogue de permissions, les rôles prédéfinis et comment les accorder.

Comment les couches se mappent au déploiement

Zaris s'exécute selon deux modèles de déploiement, et chacun se prête à des modes de confiance différents.

• Modèle superviseur — le service de gestion crée et possède les nœuds. Chaque nœud s'enrôle : il génère sa paire de clés localement et envoie une demande de signature de certificat (CSR) au manager, conditionnée par un token à usage unique. C'est le foyer naturel des modes Auto-générée, BYO-CA et BYO-intermédiaire, où Clustron effectue la signature.
• Modèle attach — un orchestrateur externe (par exemple Docker Compose ou Kubernetes) exécute les nœuds, et le manager se contente d'observer. Les certificats sont montés dans chaque nœud. C'est le foyer naturel du mode Feuilles pré-émises.

Vous n'êtes pas verrouillé — les modes sont de la configuration — mais ces appariements sont les chemins de moindre résistance. Les spécificités de déploiement se trouvent dans la section Déploiement.

Activer la sécurité : la version courte

Un cluster de modèle superviseur entièrement sécurisé tient en une poignée d'étapes. Notez la forme : vous sécurisez le plan de contrôle une fois, puis vous sécurisez le plan de données sur chaque 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"

Sécurité du cluster activée ≠ votre store est sécurisé

L'étape 1 ne sécurise que le plan de contrôle — la console et les cmdlets d'administration. Tant que vous n'exécutez pas Enable-ZrStoreSecurity sur un store (étape 2), le plan de données de ce store reste ouvert : une application peut toujours se connecter et lire chaque clé sans token. De même, activer TLS seul vous donne un store chiffré mais non authentifié — le chiffrement n'est pas l'authentification. Sécurisez chaque store qui vous importe : le token d'abord, puis TLS.

Chaque étape ci-dessus a également un équivalent dans la console web — la zone Security & TLS active la sécurité du cluster, l'exigence de token par store et le TLS par store, et frappe des tokens dans les onglets People/Applications. Pour la procédure complète clic par clic et par cmdlet, voir Sécuriser un store de bout en bout. Chaque concept est expliqué en profondeur dans les pages qui suivent.

Étapes suivantes

• Sécuriser un store de bout en bout — le chemin heureux complet (console et cmdlets) : activer la sécurité, exiger un token, activer TLS, émettre un token, connecter une application.
• Chiffrement TLS — activer TLS et le TLS mutuel, et voir comment les nœuds obtiennent des certificats.
• CA et modes de confiance — les quatre modèles de confiance en détail, avec la configuration de chacun.
• Authentification et tokens — activer l'authentification, se connecter en tant qu'opérateur et émettre des tokens.
• Autorisation et RBAC — permissions, rôles et portées.