Visión general de seguridad

Zaris asegura un clúster con tres capas independientes: cifrado en tránsito, autenticación y autorización. Habilitas cada capa por su cuenta, de modo que puedes empezar con un clúster de desarrollo en texto plano y añadir seguridad a medida que crecen tus requisitos.

Cada capa responde a una pregunta distinta.

Capa	Pregunta que responde	Mecanismo
Cifrado	¿Puede alguien en la red leer o manipular el tráfico?	Transport Layer Security (TLS) en el plano de datos y el plano de control.
Autenticación	¿Quién es este llamante?	Tokens bearer firmados, emitidos por la capa de seguridad y verificados offline por cada nodo.
Autorización	¿Se permite a este llamante hacer esto, aquí?	Control de acceso basado en roles (RBAC), denegar por defecto.

Las capas se apoyan unas en otras. El cifrado protege la tubería, la autenticación establece una identidad sobre esa tubería, y la autorización decide qué puede hacer esa identidad. Un clúster de desarrollo puede ejecutarse con las tres desactivadas. Un clúster de producción normalmente se ejecuta con las tres activadas.

Dos planos, dos tipos de clave

Antes de las capas, una distinción hace que todo lo demás encaje: Zaris tiene dos planos, y se autentican de forma distinta porque sirven a llamantes distintos.

Plano	Quién lo usa	Cómo actúan	Cómo se autentican
Plano de control	Personas y operadores	La consola web y los cmdlets de administración (Clustron.Zaris.AdminShell) — crear almacenes, cambiar la configuración, leer el estado de seguridad	Credenciales — un nombre de usuario y una contraseña. Inicias sesión una vez; el login se intercambia por un token de sesión.
Plano de datos	Aplicaciones y servicios	Tu aplicación conectándose a un almacén para leer y escribir claves	Un token — sin contraseña y autocontenido, acotado a un almacén y un rol. Colócalo en una variable de entorno o un secreto de Kubernetes.

La regla práctica: las credenciales son para personas, los tokens son para aplicaciones. Un operador inicia sesión con una contraseña (Connect-ZrManager -Credential, o la página de inicio de sesión de la consola); una aplicación presenta un token (Connect-ZrStore -Token, o un token en su cadena de conexión). También existe un login de conveniencia para aplicaciones — Connect-ZrStore -Credential intercambia un usuario/contraseña por un token del plano de datos en la conexión — pero el modelo mental que conviene conservar es personas→contraseña, aplicación→token.

La consola y los cmdlets están a la par

Casi toda acción en esta sección puede hacerse en la consola web o con un cmdlet de AdminShell equivalente — la consola habla con el clúster a través de la misma API de gestión del plano de control que usa la CLI. Cada paso de abajo muestra ambas rutas; elige la que encaje con tu flujo de trabajo.

Cifrado con TLS

TLS es el protocolo que cifra una conexión de red y permite que un lado pruebe su identidad al otro con un certificado. Zaris aplica TLS a dos planos separados, que habilitas y razonas de forma independiente.

El plano de datos transporta el tráfico del almacén — entre clientes y nodos, y entre los propios nodos.

• Cliente a nodo usa TLS con autenticación de servidor. El cliente valida el certificado de cada nodo contra la autoridad de certificación (CA) del clúster. Una CA es la entidad cuyo certificado firma — y así avala — los certificados de los nodos. El cliente, a su vez, se identifica mediante su token, no mediante un certificado de cliente.
• Nodo a nodo usa TLS mutuo (mTLS) cuando el Mode de TLS del almacén es MutualTls. En TLS mutuo, cada lado presenta un certificado y valida el de su par, de modo que solo los miembros inscritos se unen al plano de datos. MutualTls es el modo que Zaris aplica de forma predeterminada cuando habilitas TLS en un almacén.

El plano de control es el HTTPS del Servicio de Gestión y la Consola Web. Está separado del TLS del plano de datos y se habilita de forma independiente con Enable-ZrManagementHttps. Puedes asegurar la consola sin cifrar el tráfico del almacén, o al revés.

nota

El "TLS mutuo" en Zaris se refiere a la autenticación nodo a nodo. Los clientes externos no presentan un certificado de cliente. Se autentican con un token sobre un canal TLS con autenticación de servidor. Este es el patrón estándar y escalable: emites un token por cliente en lugar de aprovisionar un certificado por cliente.

Los mecanismos para habilitar TLS, y cómo cada nodo obtiene su certificado, se cubren en Cifrado TLS.

Confianza: de dónde vienen los certificados

La parte difícil de TLS no es el cifrado. Es la confianza — qué CA firma los certificados de los nodos, y cómo los clientes llegan a confiar en esa CA. Un anchor de confianza es el certificado que un cliente está configurado para confiar como raíz de la validación; cada certificado de nodo debe encadenar de vuelta hasta él.

Zaris admite cuatro modelos de confianza para que puedas alinear el clúster con la infraestructura de clave pública (PKI) existente de tu organización en lugar de rodearla. Los cuatro producen el mismo estado final — los nodos presentan certificados que los pares y los clientes validan contra un anchor de confianza — pero difieren en quién tiene la clave privada de la CA y en si Clustron firma los certificados de los nodos.

Modo	Quién tiene la clave privada de la CA	Clustron firma los certificados de los nodos	Anchor de confianza distribuido a los clientes
Autogenerado (Modo 0)	El clúster genera una CA autofirmada	Sí	La CA del clúster generada (cluster-ca.crt)
Trae tu propia CA (Modo 1)	Tú, y le das la clave de la CA al clúster	Sí	Tu raíz de CA
Trae tu propio intermedio (Modo 2)	Tú; le das solo un intermedio al clúster	Sí	Tu raíz empresarial
Hojas pre-emitidas (Modo 3)	Tú; la clave nunca se le da al clúster	No	Tu raíz, configurada como anchor de confianza

Elegir entre ellos, y la configuración exacta de cada uno, es el tema de CA y modos de confianza. Si quieres un clúster seguro con el mínimo esfuerzo, usa el predeterminado, Autogenerado: el clúster acuña su propia CA, emite a cada nodo un certificado automáticamente, y tú distribuyes un archivo público a los clientes.

Autenticación con tokens

Cuando la autenticación está habilitada, cada conexión de cliente presenta un token bearer en el handshake de conexión (el "Hello"). Un token bearer es una credencial firmada que el portador presenta para probar su identidad. El token es un JSON Web Token (JWT) firmado, emitido por la capa de seguridad, el componente de identidad embebido en el Servicio de Gestión. Los nodos verifican el token offline contra la clave pública del emisor. No hay una llamada por solicitud a un servidor de autenticación central en la ruta caliente — la verificación ocurre una vez por conexión.

Un operador inicia sesión en el plano de control con una credencial (Connect-ZrManager -Credential, o la página de inicio de sesión de la consola). Una aplicación obtiene su token del plano de datos o bien iniciando sesión con una credencial en la conexión (Connect-ZrStore -Credential, que intercambia un nombre de usuario y una contraseña por un token) o bien — el patrón habitual — haciendo que un operador emita uno de antemano (New-ZrToken, New-ZrServiceAccount) y lo coloque en un secreto. Consulta Autenticación y tokens.

Autorización con RBAC

La autenticación establece quién. La autorización decide qué. Zaris delega la autorización a la capa de seguridad, que evalúa un modelo basado en roles que deniega por defecto — una operación se rechaza a menos que un rol otorgado al llamante lo permita explícitamente en el ámbito pertinente.

• Las operaciones se mapean a permisos como data.read, data.write, y permisos del plano de control como store.create.
• Los permisos se otorgan a través de roles (por ejemplo DataReader, DataWriter, ClusterAdmin) vinculados a un principal en un ámbito — por ejemplo, un almacén frente al clúster completo.
• Los ámbitos son cadenas jerárquicas (zaris:cluster, zaris:store:orders). Una concesión en un ámbito superior cubre los ámbitos por debajo de él.

Consulta Autorización y RBAC para el catálogo de permisos, los roles predefinidos, y cómo otorgarlos.

Cómo se mapean las capas al despliegue

Zaris se ejecuta en dos modelos de despliegue, y cada uno se presta a modos de confianza distintos.

• Modelo supervisor — el Servicio de Gestión crea y posee los nodos. Cada nodo se inscribe: genera su par de claves localmente y envía una solicitud de firma de certificado (CSR) al manager, condicionada por un token de un solo uso. Este es el hogar natural de los modos Autogenerado, BYO-CA, y BYO-intermedio, donde Clustron hace la firma.
• Modelo attach — un orquestador externo (por ejemplo Docker Compose o Kubernetes) ejecuta los nodos, y el manager solo observa. Los certificados se montan en cada nodo. Este es el hogar natural del modo Hojas pre-emitidas.

No quedas bloqueado — los modos son configuración — pero estos emparejamientos son las rutas de menor resistencia. Los detalles del despliegue están en la sección Despliegue.

Habilitar la seguridad: la versión corta

Un clúster de modelo supervisor totalmente asegurado son un puñado de pasos. Fíjate en la forma: aseguras el plano de control una vez, luego aseguras el plano de datos en cada almacén.

# 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"

Seguridad del clúster activada ≠ tu almacén está asegurado

El paso 1 asegura solo el plano de control — la consola y los cmdlets de administración. Hasta que ejecutes Enable-ZrStoreSecurity en un almacén (paso 2), el plano de datos de ese almacén permanece abierto: una aplicación todavía puede conectarse y leer todas las claves sin token. Del mismo modo, habilitar TLS por sí solo te da un almacén cifrado pero no autenticado — el cifrado no es autenticación. Asegura cada almacén que te importe: primero el token, luego el TLS.

Cada paso de arriba tiene también un equivalente en la consola web — el área de Seguridad y TLS habilita la seguridad del clúster, el requisito de token por almacén, y el TLS por almacén, y acuña tokens en las pestañas de Personas/Aplicaciones. Para el recorrido completo clic a clic y con cmdlets, consulta Asegurar un almacén de principio a fin. Cada concepto se explica en profundidad en las páginas que siguen.

Próximos pasos

• Asegurar un almacén de principio a fin — la ruta feliz completa (consola y cmdlets): activar la seguridad, exigir un token, habilitar TLS, emitir un token, conectar una aplicación.
• Cifrado TLS — habilitar TLS y TLS mutuo, y ver cómo los nodos obtienen sus certificados.
• CA y modos de confianza — los cuatro modelos de confianza en detalle, con la configuración de cada uno.
• Autenticación y tokens — habilitar la autenticación, iniciar sesión como operador, y emitir tokens.
• Autorización y RBAC — permisos, roles y ámbitos.