Gestión de Tenants
Para qué sirve esta pantalla
Un tenant es una organización, una unidad de negocio o un propósito que posee sus propias claves, personas, aplicaciones y políticas, aislado de todos los demás tenants de la instalación. Esta pantalla, que se abre desde la entrada Tenants del menú lateral, muestra los tenants de tu despliegue y es donde creas uno, le entregas su primer administrador, decides qué políticas hereda y cuáles puede cambiar, lo mueves por su ciclo de vida — activar, suspender, reactivar —, entras en él como su administrador y lo cierras.
Los cuatro indicadores cuentan los tenants listados, los ACTIVE, los SUSPENDED y los que siguen en PROVISIONING. Tu propio tenant de plataforma no aparece en la lista, y un tenant cerrado sale de ella.
Qué debe existir antes
Es una pantalla de plataforma: se alcanza en el contexto de plataforma, y abrirla dentro de un tenant te envía al panel de ese tenant. Antes de trabajar aquí necesitas el permiso de leer tenants, que muestra la entrada del menú lateral, y el de listarlos, que llena la tabla; los roles integrados de superadministrador, operador, auditor y visor de la plataforma tienen ambos. Y una plataforma con la configuración inicial completa: hasta que el backend de protección de claves se configure, Crear Tenant está deshabilitado y lo indica, y una solicitud que llegue igualmente se rechaza.
Necesitas permisos separados para cada acto: crear un tenant, activarlo, suspenderlo y reactivarlo, alternar su excepción de políticas, renombrarlo y cerrarlo. Solo el superadministrador de plataforma los tiene. Crear Tenant se muestra tengas o no su permiso y la solicitud se rechaza sin él; los controles de ciclo de vida y de cierre se ocultan cuando no lo tienes, y el interruptor de excepción se muestra deshabilitado e indica el motivo.
Decisiones que tomas aquí
Leer la lista
Cada fila muestra el nombre del tenant, su identificador, cuántas claves y usuarios tiene, sus políticas, su tipo, su estado y su fecha de creación. La búsqueda compara el nombre y el identificador; el filtro acota por estado, Mantenimiento incluido. La columna Type es Simple o Standard; un tenant creado antes de que existieran los tipos muestra un guion. La columna Policies (A/R) muestra abreviadas las plantillas de algoritmo y de rotación vigentes, con un lápiz cuando el administrador del tenant puede cambiarlas y un candado cuando solo puedes hacerlo tú.
Una fila muestra Locked en lugar de los nombres de las plantillas solo cuando las políticas del despliegue están bloqueadas y ese tenant no tiene una política propia; un tenant al que se le ha dado una propia lee ahí sus propias plantillas, tanto en un despliegue bloqueado como en cualquier otro. Cuando las políticas del despliegue están bloqueadas, un aviso sobre la lista lo indica. Al pulsar la insignia se abren los nombres completos de las plantillas y un enlace al detalle del tenant.
Crear un tenant
Crear Tenant abre el diálogo Provision Tenant, con dos elecciones permanentes: el nombre (Tenant Name), que podrás cambiar luego, y el tipo (Tenant Type), que no. Standard le da todo el plano de control: aplicaciones, actores criptográficos, contextos de intercambio, concesiones de capacidad, políticas de restricción, tipos de contraparte e inventario de claves. Simple le da aplicaciones, casos de uso internos, inventario de claves, registro de auditoría y configuración, y la plataforma compone el resto. Para cambiar el tipo, creas otro tenant y mueves la carga de trabajo; el diálogo lo dice.
Nombras al primer administrador por su correo (Admin Email), con un nombre visible opcional (Admin Display Name). El administrador siempre se invita: nunca eliges su contraseña. Para una dirección nueva, la cuenta se crea sin ninguna credencial, y no se envía nada hasta que el tenant esté activo: al activarlo, el administrador recibe por correo un enlace de activación de un solo uso, que abre para registrar sus propios autenticadores. El diálogo te avisa antes si la entrega de correo de tu despliegue no está lista.
A una dirección que ya tiene cuenta (la persona pertenece a otro tenant) no se le da una nueva: la persona se convierte en el administrador pendiente de este tenant, recibe una invitación por correo cuando el tenant está activo y acepta iniciando sesión con los autenticadores que ya tiene. Una persona que pertenece a otro tenant pero nunca activó su cuenta no tiene ninguno, así que recibe por correo un enlace de activación. No se muestra ningún enlace de activación. La dirección de un administrador de la plataforma se rechaza: un administrador de la plataforma nunca es miembro de un tenant.
Cuando las políticas del despliegue no están bloqueadas, el diálogo también pregunta con qué plantillas de Algorithm Policy y Rotation Policy empieza el tenant. Cada selector se abre en Follow deployment policy: si lo dejas ahí, el tenant queda vinculado a la política del despliegue de ese tipo — a su plantilla cuando el despliegue está en una, o a una instantánea de su política efectiva cuando se escribió a mano — y la sigue desde su primera operación; si eliges una plantilla, DEFAULT incluida, el tenant lleva esa plantilla, comprobada contra la política del despliegue como techo.
El diálogo también lleva la casilla Permitir que el administrador del tenant modifique estas políticas después de la creación, desmarcada de forma predeterminada. La casilla se ofrece estén o no bloqueadas las políticas del despliegue. Cuando están bloqueadas, el diálogo muestra las plantillas del despliegue en solo lectura y no se usa ninguna plantilla que pudieras enviar — pero la casilla sí: marcarla registra la concesión que permite al tenant tener una política propia, y el tenant se aprovisiona igualmente sobre la política del despliegue.
En una instalación operada por el cliente, el diálogo también lleva Integraciones que este tenant puede configurar: las familias de integración que los propios administradores del tenant podrán declarar, cambiar y eliminar. Al principio no hay ninguna marcada, y una familia que dejes sin marcar sigue siendo tuya para configurar. El selector de edición de protección de claves no se ofrece en una instalación operada por el cliente: aquí todos los tenants usan el backend que declara el entorno.
Provision Tenant confirma lo siguiente, en una sola transacción: el registro del tenant, su primer administrador con el rol integrado TENANT_ADMINISTRATOR, las filas de políticas cuando el despliegue no está bloqueado y el conjunto delegado. No aprovisiona una clave de cifrado de claves: esa se crea en la primera operación de claves del tenant, así que crear un tenant nunca toca el backend de protección de claves.
El resultado indica entonces Tenant creado, aún no activo. Con el permiso para activar tenants ofrece Activar y enviar invitación, que activa el tenant de inmediato, y Mantener en aprovisionamiento, que cierra el diálogo y lo deja como está. Antes te avisa si la entrega de correo de este tenant no está lista. En un despliegue que activa los tenants al crearlos, el tenant queda ACTIVE de inmediato: el correo sale y el diálogo muestra el enlace de activación de un solo uso de un administrador nuevo, con su vencimiento.
Activar un tenant
Un tenant que crea este diálogo queda en PROVISIONING, salvo que tu despliegue active los tenants al crearlos. En ese estado nadie del tenant puede iniciar sesión, no se autoriza ninguna operación criptográfica para él y no existe ninguna invitación ni enlace para sus miembros, así que su administrador aún no tiene nada que abrir. Aun así, puedes entrar para configurar aplicaciones, actores, claves y políticas.
Abre el detalle del tenant y, bajo Ciclo de vida, pulsa Activar tenant. Desde ese momento sus usuarios pueden iniciar sesión y sus actores pueden operar, y quienes esperan una invitación la reciben por correo; la validez de cada enlace empieza en ese momento, sin importar cuándo se creó el tenant. Hasta que lo hagas, el indicador Provisioning lo cuenta y la fila indica Invitación en espera de la activación del tenant.
El resultado indica qué se envió. Cuando el primer administrador es nuevo en la plataforma y no pertenece a ningún otro tenant, también se te muestra su enlace de activación de un solo uso con su vencimiento, para que puedas entregárselo si el correo no llega; nunca se muestra el enlace de otro miembro. Si no hay enlace que mostrar, indica que se envió la invitación, y si nadie estaba en espera, solo que el tenant está activo. Una activación rechazada no cambia nada: el tenant sigue en PROVISIONING, no se envió nada a nadie y el mensaje indica el motivo.
Suspender y reactivar un tenant
Suspender tenant, que se ofrece en un tenant ACTIVE, pide un Motivo de la suspensión, que es obligatorio, se registra en la pista de auditoría a nombre de tu cuenta y se muestra a quien revise la suspensión más adelante. Impide que el tenant use la plataforma sin congelar lo que posee: nadie del tenant puede iniciar sesión ni renovar una sesión, y toda operación criptográfica — cifrar, descifrar, firmar, verificar, recifrar, refirmar — se rechaza en la siguiente solicitud, incluso con un token que todavía es válido.
Las sesiones no se terminan y las lecturas administrativas siguen hasta que expire el token. La custodia de claves sigue administrable: las claves de un tenant suspendido aún se pueden rotar, revocar y archivar, así que un compromiso no espera a la reactivación. Durante la suspensión no se envía ninguna invitación ni enlace de activación nuevo: quien se agregue entonces, o cuyo enlace venza entonces, espera a la reactivación. Un enlace enviado antes sigue válido; abierto durante ella, indica a la persona que la organización no está disponible ahora y que la invitación sigue siendo válida.
Reactivar tenant, que se ofrece en un tenant SUSPENDED, no pide motivo y restaura todo lo que la suspensión retiró. También envía un enlace a cada miembro que sigue esperando, y la confirmación indica cuántas invitaciones se enviaron. Ambas transiciones llegan de inmediato a los servicios que las aplican. Una transición que el estado del tenant no admite se rechaza, y el rechazo, a propósito, no dice en qué estado está el tenant.
Un tenant en MAINTENANCE está en una ventana de custodia de claves: sus claves se están moviendo a otro backend de protección de claves. Las solicitudes criptográficas de sus aplicaciones reciben una indicación para reintentar, mientras que sus administradores todavía pueden iniciar sesión. Solo la ventana entra y sale de ese estado, así que no se ofrece suspender, reactivar ni cerrar hasta que termine; suspender un tenant cuya ventana está programada pero no ha empezado cancela la ventana. Suspender un tenant por falta de pago nunca mueve sus claves.
Seguir y planificar la custodia de claves de un tenant
En el detalle del tenant, Protección de claves termina con Custodia de claves: dónde se protegen sus claves, el traslado abierto y su progreso, la rotación de su clave de cifrado de claves, las retiradas aún conservadas y el historial. En una instalación alojada por ANKA, cambiar la edición de un tenant con claves registra un traslado pendiente que planificas aquí; iniciar antes del aviso requiere un motivo. La ventana se cancela antes de empezar y se anula hasta que las claves están en el destino. Si la instalación la opera el cliente, se cambia en HSM / KMS en la Nube › Por tenant.
Una clave de cifrado de claves retirada, pasada su retención y sin nada envuelto con ella, ofrece Destruir…. La plataforma retiene toda destrucción durante el período de espera del despliegue (30 días por defecto) sin llamar al proveedor ni al HSM de la clave: la lista muestra Destrucción prevista para el con la fecha en que termina el período, y hasta entonces Cancelar la destrucción… devuelve la clave a retirada.
Cuando termina el período, la plataforma vuelve a comprobar la clave. Si envuelve otra vez material de claves, comparte su objeto de clave con una clave en uso, pertenece a un tenant cuya custodia se está trasladando, o el objeto con su nombre no es el registrado, no se destruye nada, la clave vuelve a estar retirada y se genera una alerta de plataforma; destruirla entonces requiere una nueva solicitud y, si el objeto no era el registrado, solo después de investigar el token o el servicio de claves.
Si no, la plataforma envía la destrucción al proveedor de la clave. Hasta que se registra la respuesta del proveedor, la lista muestra Enviada al proveedor y Cancelar la destrucción… queda deshabilitado. Después, un HSM destruye el objeto de clave: la lista muestra Destruida en el HSM, pendiente de confirmación, sin cancelación.
Un Cloud KMS inicia su propio período de espera, que se suma al de la plataforma: la lista muestra En su proveedor con la fecha del proveedor, y Cancelar la destrucción… la cancela en el proveedor hasta entonces. En ambos casos figura como Destruida cuando el proveedor lo confirma. Después, nada de lo que siga envuelto con la clave, incluso en copias de seguridad anteriores, se puede descifrar. La clave propia de un tenant nunca se destruye.
Permitir que el tenant cambie sus políticas
En el detalle del tenant, Políticas muestra las plantillas de algoritmo y de rotación vigentes y de dónde viene cada una, con el interruptor Permitir que el administrador del tenant cambie estas políticas. Activado, el administrador del tenant puede elegir otras plantillas del catálogo o volver a la política del despliegue; desactivado, solo puedes hacer cualquiera de las dos cosas tú.
Un despliegue con políticas bloqueadas no cambia esta sección: muestra las mismas plantillas y sus procedencias, y el interruptor también se ofrece ahí — el bloqueo congela las políticas del propio despliegue, no si a un tenant se le puede dar una propia. El mismo detalle te permite renombrar el tenant y, en una instalación operada por el cliente, cambiar las familias de integración delegadas.
En una instalación que opera ANKATech, la pestaña Detalles de ese mismo detalle lista los dominios que reclamó el tenant en Dominios de correo verificados. Solo uno verificado dirige un inicio de sesión a su proveedor de identidad, y el tenant no puede verificar los suyos. Con el permiso de gestionar los proveedores de identidad de la plataforma, Reclamar dominio agrega una reclamación, Verificar abre ¿Verificar este dominio? y Eliminar dominio pide confirmación. Un dominio verificado para un tenant no se puede verificar para otro.
Una instalación operada por el cliente no tiene esta sección: allí la plataforma no reclama, verifica ni elimina los dominios de un tenant, y el inicio de sesión federado se admite contra los dominios verificados de la propia instalación, que se gestionan en la pestaña Dominios verificados de Configuración de Plataforma.
Entrar en un tenant
El icono de persona de una fila ACTIVE o PROVISIONING abre Confirmar acceso al tenant, y confirmar te pone dentro del tenant con el rol de tenant que refleja tu rol de plataforma: PLATFORM_SUPER_ADMIN actúa como TENANT_ADMINISTRATOR, PLATFORM_OPERATOR como TENANT_ACCESS_ADMINISTRATOR, PLATFORM_AUDITOR como TENANT_AUDITOR y PLATFORM_VIEWER como TENANT_VIEWER. Un rol de plataforma personalizado no puede entrar en ningún tenant: el icono no se ofrece, y el diálogo lo dice si llegas a él.
Cada acción dentro se escribe en la pista de auditoría de ese tenant a tu nombre, el token de sesión vive como máximo 15 minutos y puedes salir en cualquier momento. En una instalación operada por el cliente no interviene ninguna autorización del tenant: entras con tus propios roles. El icono no se ofrece en un tenant suspendido.
Cerrar un tenant
Con el permiso de cierre de tenants, el icono de papelera abre Cerrar Tenant. Léelo literalmente: el cierre es permanente, nadie puede revertirlo, y no es una supresión de datos. El acceso se revoca en el momento en que confirmas — sus usuarios no pueden iniciar sesión, sus actores no pueden obtener tokens, sus claves no se pueden usar — y sus claves, aplicaciones, actores, credenciales y clave de cifrado de claves se conservan para auditoría.
Antes de confirmar, el diálogo lee y te muestra qué afecta el cierre: qué se elimina (concesiones de capacidad, contextos de intercambio, intercambios criptográficos, vínculos actor–emisor, emisores de confianza, dominios de correo, el consentimiento de acceso de soporte), qué se deshabilita pero se conserva (usuarios, aplicaciones, actores criptográficos), qué se retiene (alias de clave, por propósito y exportabilidad, y registros de custodia) y cuánta actividad criptográfica hay registrada. Una cifra que no se pudo leer dice Sin medir, nunca cero, y el botón de confirmar espera a la lectura.
El material de claves que no se puede exportar se señala, porque después no hay forma de extraerlo. Das un motivo, que es obligatorio y queda registrado en la auditoría, escribes el nombre del tenant exactamente como se muestra, pulsas Cerrar Tenant, y un segundo diálogo vuelve a preguntar — Sí, cerrarlo permanentemente — sin ningún campo que llenar. La plataforma deja primero de autorizar al tenant en todas partes, y después dispone de sus dependientes paso a paso; un paso que falla se registra y no deshace el cierre. El propio tenant de plataforma no se puede cerrar, y el diálogo lo dice.
Cómo se relaciona con otras pantallas
Las personas y los roles de un tenant se administran desde dentro de él. Lo que añade el plano de plataforma — sus propios operadores, nombrar un administrador adicional del tenant, corregir una identidad de inicio de sesión — está en la pantalla de usuarios de la plataforma:
Las plantillas que hereda un tenant, y si el despliegue las bloquea, se deciden en la pantalla de políticas de la plataforma. Lo que un tenant ve de sus propias políticas es su pantalla de políticas:
Dentro de un tenant estás en las pantallas del tenant con el rol reflejado, y la configuración, los usuarios y el registro de auditoría del propio tenant describen lo que ves allí:
Dónde leer más
Estas páginas están en inglés: