Configuración del Tenant

Para qué sirve esta pantalla

Esta pantalla, titulada Configuración del Tenant en la consola, es el registro propio de tu tenant: su nombre, identificador, estado y tamaño, las integraciones que ha declarado o que hereda, dónde viven sus controles de acceso y los cambios administrativos que se le han hecho. Se abre desde la entrada Configuración del menú lateral y tiene cuatro pestañas: General, Integraciones, Acceso y políticas y Actividad.

Es una pantalla del plano del tenant y no contiene ningún ajuste de plataforma. Los límites de tasa, la retención de auditoría, los valores predeterminados de entrega y cualquier otro valor declarado para toda la instalación pertenecen al operador de la plataforma y no se muestran aquí, ni siquiera en modo de solo lectura. El único valor de esta pantalla que puedes cambiar es el nombre del tenant; todo lo demás es un hecho que informa la plataforma o una puerta hacia otra pantalla.

Qué debe existir antes

Tanto los tenants SIMPLE como los STANDARD usan esta pantalla. Un operador de la plataforma que trabaja dentro de tu tenant también llega a ella, y ve el nombre de tu tenant, nunca el de la plataforma. Antes de trabajar aquí necesitas:

El permiso de lectura del registro de tu tenant, que es lo que emite la lectura. Sin él, la entrada del menú lateral puede seguir apareciendo si puedes actualizar el tenant, pero la pestaña General indica que leer el registro no forma parte de tu acceso y no solicita nada. El cambio de nombre requiere el permiso de actualización de tu tenant, del rol integrado de administrador del tenant. Sin él, el nombre se muestra como un hecho, no como un control deshabilitado.
Cada pestaña más allá de General se controla a sí misma: las filas de integraciones siguen sus propios permisos de lectura, la pestaña Actividad requiere un rol que pueda leer la pista de gobernanza, el estado del acceso de soporte en Acceso y políticas requiere el permiso de lectura del acceso de soporte, y sus requisitos de inicio de sesión requieren el permiso de lectura de la política de autenticación, que tienen todos los roles integrados del tenant; cambiarlos requiere el permiso de gestionarla, que tienen el administrador del tenant y el administrador de acceso.

Decisiones que tomas aquí

Cambiar el nombre del tenant

En General, la zona Identidad muestra Nombre del Tenant como un campo con un botón Guardar Cambios, que se habilita solo cuando el valor sin espacios sobrantes difiere del nombre actual y no está vacío. El nombre tiene de uno a 255 caracteres, con espacios simples entre palabras; el nombre de otro tenant, comparado sin distinguir mayúsculas, se rechaza, y el rechazo se muestra bajo el campo con lo que escribiste todavía ahí.

El cambio se aplica al pulsar Guardar Cambios y esta página vuelve a leer el registro de inmediato, así que el encabezado y la ruta de navegación muestran el nuevo nombre. El nombre que aparece en la cabecera de la consola se lee cuando empieza tu sesión y se actualiza en tu siguiente inicio de sesión o recarga de la página. El cambio se escribe en tu registro de auditoría. Los eventos de auditoría identifican tu tenant por su identificador; el nombre no está entre los campos que llevan.

El resto de la zona es de solo lectura: el ID del Tenant con un botón de copia que informa si la copia tuvo éxito, las fechas de creación y de Último cambio, y el Contacto administrativo, que es la dirección de tu usuario administrador o indica que no hay ninguno configurado. Un distintivo de estado junto al nombre informa PROVISIONING, ACTIVE, MAINTENANCE, SUSPENDED o CLOSED exactamente como lo hizo la plataforma, o indica que el registro no traía ninguno. Suspender o cerrar un tenant es una acción del operador de la plataforma y no se ofrece aquí.

Uso informa el número de claves criptográficas y de usuarios humanos que tiene tu tenant, sin contar los eliminados, con la hora en que se midió la cifra. Una cifra que la lectura no trajo se muestra como No disponible, con la nota de que no es cero.

Revisar las integraciones

Integraciones lista seis superficies — Federación de identidad, Emisores de confianza, Proveedores de entrega, Reenvío a SIEM/XDR, Exportación de observabilidad y Protección de claves — cada una con un veredicto leído de la plataforma: cuántos hay declarados aquí, que la configuración se hereda de la instalación, que no hay nada declarado, o que la superficie no se leyó. La acción de una fila, Gestionar, Declarar o Revisar, abre esa superficie en un panel sobre esta página, el mismo que tiene en otro lugar, que indica de qué tenant trata.

Una fila sobre la que no puedes actuar conserva su control e indica por qué: tu acceso no la incluye; la capacidad pertenece a una edición superior, o solo en parte, y lo declarado se puede revisar; la superficie no aplica a este tipo de instalación; o, solo en una instalación operada por el cliente, el operador de la plataforma no ha delegado esa familia a tu tenant. En SaaS nunca se pregunta la delegación: decide tu edición. Nada ya configurado se retira por estos motivos. Cada declaración, cambio y eliminación en estos paneles queda en tu registro de auditoría con su propio tipo de evento.

Reclamar tus dominios de correo

El panel Federación de identidad lista los Dominios de correo verificados de tu tenant, cada uno marcado Verificado o Sin verificar. Un dominio dirige un inicio de sesión a tu proveedor de identidad solo una vez verificado, y tu propio proveedor solo se puede habilitar cuando al menos un dominio lo está. Con el permiso de configurar la federación de identidad escribes un dominio, como example-bank.com, y pulsas Reclamar dominio, o eliminas una reclamación con Eliminar dominio tras confirmarlo.

Una reclamación se crea sin verificar y tu tenant no puede verificarla: en SaaS lo hace un administrador de la plataforma al confirmar que el dominio es tuyo. En una instalación operada por el cliente los dominios de un tenant no intervienen en el inicio de sesión, que usa los dominios verificados que declara el operador; tu proveedor se habilita cuando la instalación tiene uno. Allí el panel muestra Los dominios de correo no tienen efecto en este despliegue, no ofrece campo para reclamar y mantiene Eliminar dominio para los listados. Un rechazo aparece donde actuaste, sin perder lo escrito.

Decidir quién puede entrar a través de tu proveedor de identidad

Debajo de los dominios, Quién puede entrar a través de tu proveedor de identidad tiene tres bloques. Correo a rol asigna un rol a una dirección, Dominio a rol a todas las direcciones de un dominio, y Guardia de dominio no asigna nada. Cada bloque agrega una entrada con Agregar regla y la elimina tras una confirmación (Eliminar regla de correo, Eliminar regla de dominio, Eliminar dominio permitido).

Guardia de dominio es una lista de dominios permitidos por proveedor. Un proveedor sin ningún dominio permitido deja pasar la guardia a todos los dominios; su primer dominio permitido limita a ese dominio el inicio de sesión a través de él, cada uno que se agrega después admite también su propio dominio, y eliminar el último vuelve a dejar pasar todos los dominios que había excluido. Pasada la guardia, las reglas y los mapeos de grupos siguen decidiendo quién se admite.

La sección requiere leer tus proveedores y tus mapeos de federación. Las reglas requieren el permiso de gestionar los mapeos de federación, y los dominios permitidos el de configurar la federación de identidad; sin ellos, las listas no muestran controles. Solo asignas un rol cuyos permisos tienes todos, y una regla de dominio no ofrece roles con permisos de plataforma o comodín. Cada cambio rige desde el siguiente inicio de sesión federado. En SaaS, un operador en una sesión de acceso de soporte no puede agregar reglas ni agregar o eliminar dominios permitidos; lo hace tu administrador.

Cambiar lo que protege tus claves

Cuando tu tenant ya tiene claves, lo que las protege solo cambia mediante un traslado de custodia de claves, que se muestra en Custodia de claves dentro del panel Protección de claves: dónde se protegen tus claves, el traslado abierto y su progreso, cómo rota tu clave de cifrado de claves, las retiradas aún conservadas y el historial. Un traslado que espera por ti —elegir un destino tras un cambio de plan o dar tu consentimiento a una edición inferior— abre el panel con Revisar, aunque tu edición actual no incluya tu propio KMS.

En una instalación alojada por ANKA eliges entre el nivel ENTERPRISE gestionado por ANKATech y tu propio servicio de gestión de claves, aceptas un traslado fuera de tu propio KMS con Aceptar y programar…, o aportas o cambias tu propio KMS. Tu clave se declara con su servicio, su identificador y su credencial, que no vuelve a mostrarse, y se prueba antes de registrar el traslado. Nada se traslada hasta que programas la ventana, que puede empezar de inmediato. En una instalación operada por el cliente, estas acciones requieren la delegación del operador de la plataforma.

La credencial de tu propia clave debe poder leer el estado de la clave y sus versiones, además de envolver y desenvolver: la comprobación de custodia de claves los lee después de una restauración o una actualización, por lo que vincular el backend y rotar la credencial los comprueban contra la clave declarada. Concédele:

AWS KMS: kms:DescribeKey, más kms:ListKeyRotations para una clave con material importado (origen EXTERNAL).
Google Cloud KMS: cloudkms.cryptoKeys.get y cloudkms.cryptoKeyVersions.list. El rol roles/cloudkms.cryptoKeyEncrypterDecrypter no incluye ninguno de los dos.
Azure Key Vault y Managed HSM: nada nuevo; basta el permiso de clave get que ya se exige.

En AWS KMS la clave se declara con el ARN de la clave; un ARN de alias se rechaza. También se rechaza una clave que este despliegue creó o usa para su propia custodia de claves. La lista completa de permisos, con el motivo de cada uno, está en los requisitos previos del cliente por nube, en la documentación para clientes. Una credencial o una clave rechazada no cambia nada:

En una instalación alojada por ANKA también puedes Revertir… a una clave de cifrado de claves que dejaste mientras siga conservada, cuando la reversión afecta a tu propio KMS: volver a una clave propia que dejaste, o pasar de tu propia clave al nivel ENTERPRISE que dejaste. Una reversión entre niveles gestionados por ANKATech corresponde al operador de la plataforma.

Durante una ventana tu tenant está en MAINTENANCE: las operaciones con claves de tus aplicaciones reciben un 503 temporal con una indicación para reintentar, mientras puedes iniciar sesión y seguir el progreso. Una pantalla cuya lectura pausa la ventana muestra No disponible temporalmente en lugar de un error; las listas y los detalles de claves siguen legibles. Puedes cancelar un traslado antes de que empiece y anularlo hasta que las claves estén activas en el destino.

Encontrar tus controles de acceso

Acceso y políticas comienza con Cómo inician sesión los miembros, el único control de esta pestaña que cambia tu tenant (abajo). Debajo hay seis destinos enlazados: políticas criptográficas, aplicaciones, roles, concesiones de capacidad, acceso de soporte y registro de auditoría, cada uno con una línea sobre su uso. La lista nunca se acorta según tu acceso: un destino que no puedes leer sigue en ella con el motivo, para que sepas que existe y puedas pedirlo. La fila del acceso de soporte indica además, sin salir de la página, si hay una ventana de soporte abierta o que no se pudo leer.

Decidir cómo inician sesión los miembros

Cómo inician sesión los miembros establece qué métodos de inicio de sesión admiten a una persona en tu tenant (Clave de acceso, Contraseña y aplicación de autenticación, o ambos) y las Propiedades exigidas a la clave de acceso, como una clave respaldada por hardware o certificada por su fabricante. Se aplica a todos los miembros y a todos los roles, y solo después de verificar la contraseña o la clave de acceso de la persona, así que nunca revela a nadie a qué tenants pertenece una persona.

Dónde inician sesión los miembros decide qué autoridad los admite: Solo aquí (los métodos de abajo; un proveedor de identidad no deja entrar a nadie), Aquí o mediante el proveedor de identidad (los métodos de abajo, o el proveedor al que está vinculado el miembro) o Solo mediante el proveedor de identidad (un miembro vinculado al proveedor solo inicia sesión mediante él; los miembros que designaste para el acceso de emergencia entran mediante Acceso de emergencia con sus claves de seguridad). Si no eliges ninguno, tu tenant es Aquí o mediante el proveedor de identidad.

Solo mediante el proveedor de identidad necesita un proveedor OIDC o SAML activo, propio o heredado del despliegue, y una identidad de emergencia lista: un miembro designado activo con el mínimo del despliegue de claves de seguridad o passkeys vinculadas al dispositivo. Sin ellos se rechaza con el motivo.

Tus administradores, es decir, cualquier persona cuyos roles permiten un cambio, también llevan un segundo factor cuando entran mediante el proveedor de identidad. Entran solo con el inicio de sesión del proveedor cuando se confía en su MFA y ese inicio de sesión la prueba; si no, confirman además con una clave de acceso o un código de su aplicación de autenticación, o añaden uno. La confianza en tu propio proveedor se elige al declararlo y no se puede cambiar después; la de un proveedor heredado la decide el operador del despliegue.

Mientras la aprobación por quórum de tu tenant esté activa, una declaración confiable espera a tus aprobadores y no puede incluir el secreto del proveedor, así que un proveedor OIDC no se puede declarar confiable con su secreto de cliente: decláralo no confiable, con su secreto, y tus administradores confirmarán con una clave de acceso o un código después del proveedor. Los miembros que solo leen siguen iniciando sesión solo con el proveedor.

El panel Acceso de emergencia de abajo muestra si está listo, cada miembro designado con sus claves y su último inicio de sesión de emergencia, y recomienda una segunda clave para el miembro que tiene una. Solo aquí se rechaza mientras haya miembros restringidos al proveedor de identidad en la pantalla de usuarios.

Vigente en cada inicio de sesión muestra el resultado una vez aplicada la autorización del propio despliegue: tu tenant solo puede restringir lo que el despliegue permite. Si no seleccionas nada para tu tenant, sus miembros inician sesión como lo permite el despliegue. Proveedores de identidad de indica si los proveedores son propios de tu tenant, del despliegue (heredados) o ninguno. Si son heredados, el panel advierte que una caída del proveedor del despliegue detiene a la vez el inicio de sesión mediante él para la plataforma y para cada tenant que lo hereda.

A una persona cuyos autenticadores ya no cumplen los requisitos se le pide, en su próximo inicio de sesión, que agregue uno que los cumpla. Guardar reemplaza los requisitos. Una combinación que nadie podría cumplir (ningún método, una propiedad exigida sin admitir claves de acceso, o un método que el despliegue prohíbe) se rechaza con el motivo, y no se guarda nada. Cada cambio se registra en tu registro de auditoría con los valores anteriores y nuevos.

Leer la pista de gobernanza

Actividad muestra los cambios administrativos hechos en este tenant y desde qué plano: por tus administradores o por un operador de la plataforma. Usa los eventos firmados del registro de auditoría, limitada a las acciones de gobernanza que la plataforma divulga sobre un tenant, filtrable por plano. En una instalación alojada por ANKA no se muestran las acciones del operador desde la plataforma, salvo las hechas en tu tenant con acceso de soporte, marcadas Mediado por la plataforma, que nombran al operador por una referencia, no por su nombre. Sin un rol que pueda leerla, la pestaña lo indica.

Cómo se relaciona con otras pantallas

Los destinos de Acceso y políticas son pantallas propias, y la ventana de soporte que esta página informa se decide en una de ellas. Las personas contadas en Uso se gestionan en la pantalla de usuarios, y las claves en el inventario de claves.

Dónde leer más

Estas páginas están en inglés: