Descripción general

AgileTrust Tokenization reemplaza datos sensibles con tokens que preservan el formato: valores que lucen idénticos al original (misma longitud, misma estructura, mismo conjunto de caracteres) pero son sustituciones criptográficamente seguras.

A diferencia del enmascaramiento tradicional o el hashing, la tokenización es completamente reversible. Con la misma clave, el valor original puede recuperarse en cualquier momento sin necesidad de almacenar una tabla de correspondencias.

Propiedades clave

• Preserva el formato: un número de tarjeta de 16 dígitos tokeniza en otro de 16 dígitos; un RUT chileno como 13301430-6 tokeniza en 35240589-5.
• Determinista: la misma entrada + misma clave + misma codificación + mismo tweak siempre produce el mismo token.
• Reversible: /detokenize recupera el valor original con 100% de fidelidad.
• Preserva símbolos: espacios, guiones, @, ., () y todos los caracteres no alfanuméricos permanecen en sus posiciones exactas.
• Transparente al esquema: no requiere cambios en la base de datos, ni actualizar reglas de validación, ni reescribir expresiones regulares.

Cómo funciona

Cada solicitud de tokenización pasa por tres etapas:

1. Normalizar — La entrada se normaliza a NFC (Forma de Normalización C de Unicode) para garantizar una representación de bytes consistente entre plataformas y locales.
2. Dividir — La cadena se separa en dos listas: caracteres tokenizables (letras y dígitos del alfabeto de la codificación elegida) y caracteres de paso (todo lo demás: espacios, guiones, puntuación, símbolos). Las posiciones de paso se registran.
3. Cifrar — Los caracteres tokenizables se cifran con FF3-1/AES. Para entradas más cortas que el mínimo de FF3 (6 para numérico, 3 para texto), se usa una sustitución con SHA-256 basada en la clave. Para entradas muy largas, los caracteres tokenizables se procesan en segmentos. Los caracteres de paso se reinsertan en sus posiciones originales.

La destokenización ejecuta exactamente el mismo proceso en sentido inverso — el cifrado opera de forma idéntica en ambas direcciones.

Modos de codificación

El parámetro encoding controla qué caracteres se consideran "tokenizables" y establece el alfabeto de cifrado.

Cómo elegir el modo correcto

• Use numeric para cualquier valor compuesto principalmente de dígitos, incluso si contiene separadores como guiones o paréntesis (estos se preservan, no se cifran).
• Use utf8 (por defecto) para nombres, texto libre, correos electrónicos y cualquier cadena con caracteres no latinos.
• Use latin1 para nombres en Europa occidental cuando necesite tokens que permanezcan dentro de la página de códigos Latin-1 (sistemas legados que no soportan caracteres por encima de U+00FF).

Inicio rápido

1. Ejecutar el contenedor

export TOKENIZATION_KEY="$(python3 -c 'import os,base64; print(base64.b64encode(os.urandom(32)).decode())')"
export API_KEY="$(openssl rand -hex 24)"

docker run -d \
  --name tokenizer \
  -p 8000:8000 \
  -e TOKENIZATION_KEY="$TOKENIZATION_KEY" \
  -e API_KEY="$API_KEY" \
  agiletrust/tokenization:0.3

El contenedor inicia un servidor FastAPI en el puerto 8000. TOKENIZATION_KEY debe ser una clave AES en base64 — 16, 24 o 32 bytes (AES-128/192/256). API_KEY es el secreto compartido requerido en el header X-API-Key.

2. Tokenizar un valor

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "13301430-6", "encoding": "numeric"}' | jq .

{
  "token": "35240589-5",
  "algorithm": "FF3-1/AES",
  "encoding": "numeric"
}

3. Destokenizar para recuperar el original

curl -s -X POST http://localhost:8000/detokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"token": "35240589-5", "encoding": "numeric"}' | jq .

{
  "plaintext": "13301430-6"
}

Autenticación

Todas las solicitudes a /tokenize y /detokenize requieren el encabezado X-API-Key con la clave API compartida. El endpoint /health es abierto (requerido para sondas de liveness).

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "13301430-6", "encoding": "numeric"}' | jq .

En modo single-tenant, la clave API se configura mediante la variable de entorno API_KEY y es compartida por todos los llamantes. La clave AES se configura mediante TOKENIZATION_KEY. Ninguna de las dos aparece en registros ni en respuestas — los clientes nunca envían material de clave en los cuerpos de solicitud.

En modo multi-tenant (MULTI_TENANT=true), las API keys se generan por aplicación desde la consola de administración. Cada clave se almacena como hash SHA-256 y resuelve su propia clave AES desde la base de datos en cada solicitud. Consulte la sección Multi-Tenant y Consola para los detalles de configuración.

GET /health

Devuelve el estado del servicio y la versión actual. Utilice este endpoint para sondas de liveness y monitoreo de disponibilidad.

Respuesta — 200 OK

{
  "status": "ok",
  "version": "0.3"
}

POST /tokenize

Convierte una cadena de texto en claro en un token que preserva el formato.

Cuerpo de la solicitud

Respuesta — 200 OK

Respuesta — 422 Unprocessable Entity

Se devuelve cuando hay errores de validación. El campo error describe el problema:

POST /detokenize

Invierte un token producido por /tokenize, recuperando el texto original.

Cuerpo de la solicitud

Respuesta — 200 OK

RUT y valores numéricos

Use "encoding": "numeric" para cualquier identificador con dígitos. Los separadores se preservan automáticamente.

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "13301430-6", "encoding": "numeric"}' | jq .

{
  "token": "35240589-5",
  "algorithm": "FF3-1/AES",
  "encoding": "numeric"
}

curl -s -X POST http://localhost:8000/detokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"token": "35240589-5", "encoding": "numeric"}' | jq .

{
  "plaintext": "13301430-6"
}

# Teléfono chileno
curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "+56 9 8765 4321", "encoding": "numeric"}' | jq .

{
  "token": "+56 9 2341 8907",
  "algorithm": "FF3-1/AES",
  "encoding": "numeric"
}

Nombres y texto libre

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "Juan Pérez-García"}' | jq .

{
  "token": "Ñkrp Çmevq-Ĥapcw",
  "algorithm": "FF3-1/AES",
  "encoding": "utf8"
}

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "Juan Pérez-García", "encoding": "latin1"}' | jq .

{
  "token": "YrfãröxÍ-Ý",
  "algorithm": "FF3-1/AES",
  "encoding": "latin1"
}

Correo electrónico

El símbolo @ y el punto . siempre se preservan, haciendo que los correos tokenizados sean sintácticamente válidos en la mayoría de los validadores.

curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "juan.perez@empresa.cl"}' | jq .

{
  "token": "ĭğĬħ.ŋĕĮĕž@ĩźĝŋĪĮĩ.ĕĝ",
  "algorithm": "FF3-1/AES",
  "encoding": "utf8"
}

Uso del Tweak

Un tweak es una cadena hexadecimal de 14 caracteres (7 bytes) que aporta contexto a nivel de campo. El mismo texto en claro tokenizado con tweaks diferentes produce tokens completamente distintos, impidiendo que un atacante correlacione tokens entre campos.

# Tokenizar como campo "nombre"
curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "Maria Lopez", "tweak": "6e6f6d62726500"}' | jq .token

# Tokenizar como campo "alias"
curl -s -X POST http://localhost:8000/tokenize \
  -H "Content-Type: application/json" \
  -H "X-API-Key: su-clave-api-aqui" \
  -d '{"plaintext": "Maria Lopez", "tweak": "616c6961730000"}' | jq .token

Ejemplo completo en Python

import requests

BASE_URL = "http://localhost:8000"

ENCABEZADOS = {"X-API-Key": "su-clave-api-aqui"}

def tokenizar(texto, codificacion="utf8", tweak=None):
    """Convierte un texto en un token que preserva el formato."""
    payload = {"plaintext": texto, "encoding": codificacion}
    if tweak:
        payload["tweak"] = tweak
    respuesta = requests.post(f"{BASE_URL}/tokenize", json=payload, headers=ENCABEZADOS)
    respuesta.raise_for_status()
    return respuesta.json()["token"]

def destokenizar(token, codificacion="utf8", tweak=None):
    """Recupera el texto original a partir de un token."""
    payload = {"token": token, "encoding": codificacion}
    if tweak:
        payload["tweak"] = tweak
    respuesta = requests.post(f"{BASE_URL}/detokenize", json=payload, headers=ENCABEZADOS)
    respuesta.raise_for_status()
    return respuesta.json()["plaintext"]

# ── Ejemplos de uso ───────────────────────────────────────

# RUT chileno
token_rut = tokenizar("13301430-6", codificacion="numeric")
print(f"RUT token: {token_rut}")           # 35240589-5
print(f"RUT original: {destokenizar(token_rut, 'numeric')}")  # 13301430-6

# Nombre completo
token_nombre = tokenizar("María González López")
print(f"Nombre token: {token_nombre}")
print(f"Nombre original: {destokenizar(token_nombre)}")

# Email
token_email = tokenizar("maria@empresa.cl")
print(f"Email token: {token_email}")

# Con tweak por campo
tweak_rut   = "72757400000000"
tweak_email = "656d61696c0000"

t1 = tokenizar("maria@empresa.cl", tweak=tweak_email)
t2 = tokenizar("maria@empresa.cl", tweak=tweak_rut)
print(f"Con tweak email: {t1}")
print(f"Con tweak rut:   {t2}")
print(f"Son distintos: {t1 != t2}")   # True

Límites y restricciones

• Las cadenas vacías son aceptadas y devuelven un token vacío.
• La entrada se normaliza a NFC antes de verificar la longitud. Pre-normalice si los límites exactos son críticos.
• El tweak debe tener exactamente 14 caracteres hexadecimales (sin distinción entre mayúsculas y minúsculas). Por defecto: 00000000000000.

Respuestas de error

Todos los errores devuelven JSON con un único campo error:

{ "error": "plaintext: Value error, 'plaintext' exceeds maximum length of 16 characters." }

Preguntas frecuentes

¿Dos textos distintos pueden producir el mismo token?

No. FF3-1 es una permutación pseudoaleatoria (PRP), por lo que la tokenización es una biyección: cada texto en claro corresponde a un token único y viceversa, para una misma clave + tweak + codificación.

¿La longitud del token siempre iguala la del texto original?

Sí. La longitud del token iguala la longitud de la entrada normalizada NFC. Si la entrada ya está en NFC, las longitudes son idénticas.

¿Qué ocurre si tokenizo el mismo valor dos veces?

Obtendrá el mismo token. La tokenización es determinista. Si necesita tokens distintos para el mismo valor en contextos diferentes, use tweaks distintos.

¿Puedo usar el modo numérico para números de tarjeta de crédito?

Sí. Un PAN de 16 dígitos como 4532015112830366 tokenizará en otro número de 16 dígitos. El número tokenizado no pasará la verificación Luhn — esto es esperado e intencional.

¿Cómo sé si la destokenización fue exitosa?

No hay indicador criptográfico. Si necesita verificar la corrección, almacene un hash del texto original y compárelo después de destokenizar.

¿El servicio guarda estado?

La lógica de tokenización es sin estado — no se almacena ninguna tabla de búsqueda y el valor original se deriva matemáticamente del token + clave + tweak + codificación. En modo multi-tenant, el servicio se conecta a PostgreSQL para resolver API keys y configuraciones de aplicaciones, pero cada solicitud sigue siendo independiente sin estado de sesión.

¿Es compatible con la normativa PCI DSS o HIPAA?

AgileTrust Tokenization implementa FPE estándar NIST, que es un componente técnico reconocido en esquemas de tokenización PCI DSS y HIPAA. Consulte a su equipo de cumplimiento para determinar si satisface los requisitos específicos de su organización.

Modo Single-Tenant

El modo de operación por defecto. Una única clave AES se carga al inicio y se comparte entre todas las solicitudes. Adecuado para una sola aplicación o cuando la aislación se gestiona a nivel de infraestructura.

Variables de entorno requeridas

export TOKENIZATION_KEY="$(python3 -c 'import os,base64; print(base64.b64encode(os.urandom(32)).decode())')"
export API_KEY="$(openssl rand -hex 24)"

docker run -d -p 8000:8000 \
  -e TOKENIZATION_KEY="$TOKENIZATION_KEY" \
  -e API_KEY="$API_KEY" \
  tokenizer:0.3

Modo Multi-Tenant y Consola de Administración

Con MULTI_TENANT=true, el tokenizer resuelve las claves desde PostgreSQL en cada solicitud. Cada aplicación tiene su propia clave AES, configurada a través de la Consola AgileTrust — una interfaz de administración Next.js con autenticación SSO.

Arquitectura

• Consola (Next.js, puerto 3000): crear tenants, aplicaciones y API keys. Acceso con Google, Microsoft u Okta.
• Tokenizer (FastAPI, puerto 8000): resuelve la API key desde la base de datos, descifra el provider_config de la aplicación y cachea la clave por KEY_CACHE_TTL segundos.
• PostgreSQL: base de datos compartida. La consola tiene acceso lectura-escritura; el tokenizer usa una conexión de solo lectura.

Variables de entorno multi-tenant (tokenizer)

Inicio rápido (Docker Compose)

export POSTGRES_PASSWORD="$(openssl rand -hex 16)"
export NEXTAUTH_SECRET="$(openssl rand -base64 32)"
export MASTER_ENCRYPTION_KEY="$(python3 -c 'import os,base64; print(base64.b64encode(os.urandom(32)).decode())')"
export GOOGLE_CLIENT_ID="your-client-id"
export GOOGLE_CLIENT_SECRET="your-client-secret"

# Ejecutar migración Prisma (solo la primera vez)
cd console && npm install && npx prisma migrate deploy && cd ..

# Levantar los 3 servicios
docker compose -f docker-compose.full.yml up -d

Flujo del primer inicio de sesión

1. Abrir http://localhost:3000 e iniciar sesión con su proveedor OAuth.
2. El primer usuario del dominio de email se convierte en owner de un nuevo tenant. Los usuarios siguientes del mismo dominio se añaden como viewers.
3. Ir a Applications → New Application. Elegir un proveedor de clave (System Vault es el predeterminado — no necesita vault externo).
4. Abrir la aplicación y hacer clic en New Key. Copiar la API key — se muestra una única vez.
5. Usar la API key en el header X-API-Key al llamar al tokenizer.

Rotación de API key vs. rotación de clave de cifrado

• Rotación de API key: genera una nueva clave tok_… para la misma aplicación. La clave de cifrado y todos los tokens permanecen válidos.
• Rotación de clave de cifrado (solo System Vault): genera una nueva clave AES. Todos los tokens existentes se vuelven irrecuperables — FPE con una clave incorrecta devuelve un valor plausible pero erróneo, sin ninguna señal de error.

Proveedores de clave

En modo single-tenant, seleccione el proveedor con la variable KEY_PROVIDER en el tokenizer. En modo multi-tenant, cada aplicación selecciona su propio proveedor en la consola — no se necesitan variables de entorno adicionales en el tokenizer.

env — Variable de entorno (por defecto)

La clave AES se suministra directamente como variable de entorno en base64. Adecuado para despliegues single-tenant o desarrollo local.

system_vault — Clave almacenada en base de datos (predeterminado multi-tenant)

La consola genera una clave AES-256 aleatoria al crear la aplicación, la cifra con MASTER_ENCRYPTION_KEY usando AES-256-GCM, y almacena el texto cifrado en la columna applications.provider_config. No se requieren credenciales de vault externo ni cloud.

Es el punto de partida recomendado para la mayoría de los despliegues. La clave nunca sale de la base de datos sin cifrar.

aws_secretsmanager — AWS Secrets Manager

El tokenizer llama a GetSecretValue al inicio (single-tenant) o en fallo de caché (multi-tenant) para obtener la clave AES en base64 almacenada como secreto de texto plano.

KEY=$(python3 -c 'import os,base64; print(base64.b64encode(os.urandom(32)).decode())')
aws secretsmanager create-secret \
  --name agiletrust/tokenization-key \
  --secret-string "$KEY" \
  --region us-east-1

aws_kms — AWS KMS

La clave AES se cifra con una Customer Managed Key (CMK) de AWS KMS y se almacena como blob en base64. El tokenizer llama a kms:Decrypt para recuperar la clave en texto plano en tiempo de ejecución.

KEY=$(python3 -c 'import os,base64; print(base64.b64encode(os.urandom(32)).decode())')
CIPHERTEXT=$(aws kms encrypt \
  --key-id alias/my-cmk \
  --plaintext "$KEY" \
  --query CiphertextBlob \
  --output text \
  --region us-east-1)
# Almacenar CIPHERTEXT como AWS_KMS_KEY_REF

azure_keyvault — Azure Key Vault

La clave AES se almacena como secreto en Azure Key Vault. La autenticación usa DefaultAzureCredential de azure-identity, que soporta managed identity, service principal y credenciales de desarrollador automáticamente.

gcp_secretmanager — GCP Secret Manager

La clave AES se almacena como versión de secreto en GCP Secret Manager. La autenticación usa Application Default Credentials (ADC) — se otorga acceso a la cuenta de servicio que ejecuta el contenedor.

oci_vault — OCI Vault

La clave AES se almacena como secreto en Oracle Cloud Infrastructure Vault. La autenticación usa el archivo de configuración OCI o instance principal al ejecutarse en OCI Compute.

Variables de entorno de la consola

La consola de administración es una aplicación Next.js configurada completamente mediante variables de entorno. Establézcalas en un archivo .env en la raíz de console/, o páselas directamente a Docker.

* Debe configurarse al menos un proveedor OAuth.

SSO / Proveedores de identidad

La consola autentica usuarios mediante OAuth 2.0 / OIDC a través de NextAuth.js v5. Configure al menos uno de los cuatro proveedores soportados. Todos los proveedores activados aparecen simultáneamente en la página de inicio de sesión.

Google

1. Abra Google Cloud Console → APIs y servicios → Credenciales.
2. Haga clic en Crear credenciales → ID de cliente OAuth 2.0.
3. Establezca el tipo de aplicación como Aplicación web.
4. En URIs de redireccionamiento autorizados, agregue:
   {NEXTAUTH_URL}/api/auth/callback/google
5. Copie el Client ID y el Client Secret en sus variables de entorno.

Microsoft Entra ID (Azure AD)

1. Abra el portal de Azure → Microsoft Entra ID → Registros de aplicaciones.
2. Haga clic en Nuevo registro. Asigne un nombre; en Tipos de cuenta admitidos elija el ámbito deseado.
3. En URI de redireccionamiento, seleccione Web e ingrese:
   {NEXTAUTH_URL}/api/auth/callback/azure-ad
4. Tras la creación, anote el ID de aplicación (client) y el ID de directorio (tenant).
5. Vaya a Certificados y secretos → Nuevo secreto de cliente. Copie el valor del secreto (no el ID).

Okta

1. Abra la Consola de administración de Okta → Applications → Create App Integration.
2. Seleccione OIDC – OpenID Connect como método de inicio de sesión y Web Application como tipo de aplicación.
3. En Sign-in redirect URIs, agregue:
   {NEXTAUTH_URL}/api/auth/callback/okta
4. Copie el Client ID y el Client Secret de la configuración de la aplicación.
5. La URL del Issuer se encuentra en Security → API → Authorization Servers. Por defecto: https://su-org.okta.com/oauth2/default.

Keycloak

1. Abra la Consola de administración de Keycloak → seleccione su realm → Clients → Create client.
2. Establezca el Client type como OpenID Connect e ingrese un Client ID.
3. Active Client authentication (tipo de acceso confidencial).
4. En Valid redirect URIs, agregue:
   {NEXTAUTH_URL}/api/auth/callback/keycloak
5. Guarde. Vaya a la pestaña Credentials y copie el Client Secret.
6. La URL del issuer es la URL de su realm: https://<host>/realms/<nombre-realm>.

Roles y permisos

La consola aplica una jerarquía de tres niveles de roles. Un usuario con un rol de rango superior hereda todos los permisos de los roles de rango inferior.

• El primer usuario en iniciar sesión para un dominio de correo determinado se convierte en owner.
• Los usuarios siguientes del mismo dominio se unen como viewer.
• Un owner puede promover un viewer a admin, un admin a owner, o degradar a cualquier usuario.
• Un owner no puede eliminarse ni degradarse a sí mismo si es el último owner del tenant.

Gestionar aplicaciones

Una aplicación representa un servicio lógico que llamará a la API del tokenizer. Cada aplicación tiene su propia clave AES de cifrado y genera sus propias API keys. Requiere el rol admin u owner.

Crear una aplicación

1. Navegue a Applications en la barra lateral.
2. Haga clic en New Application.
3. Ingrese un Nombre (obligatorio) y una Descripción opcional.
4. Seleccione un Proveedor de clave. system_vault es el predeterminado — la consola genera y almacena la clave AES automáticamente; no se necesitan credenciales de vault externo.
5. Para proveedores cloud, complete los campos de configuración requeridos (p.ej., secret_id y region para AWS Secrets Manager).
6. Haga clic en Create. La aplicación se crea y su clave se aprovisiona inmediatamente.

Campos de configuración por proveedor

Editar o eliminar una aplicación

Abra la página de detalle de la aplicación y use los botones Edit o Delete. Eliminar una aplicación revoca inmediatamente todas sus API keys — cualquier solicitud en curso que use esas claves recibirá 403 Forbidden.

Gestionar API keys

Las API keys autentican las llamadas al tokenizer. Cada clave está asociada a una sola aplicación y resuelve la clave AES de esa aplicación. Requiere el rol admin u owner.

Crear una clave

1. Abra la página de detalle de una aplicación.
2. Haga clic en New Key.
3. Opcionalmente ingrese una Etiqueta (p.ej., producción, staging) y una fecha de expiración.
4. Haga clic en Generate. La clave completa se muestra exactamente una vez — cópiela inmediatamente.

Formato de la clave: tok_{tenant_slug}_{32 caracteres aleatorios}
Ejemplo: tok_acmecorp_K7mP2xQnRvW9jLdF8bTsZeYhAcGiNuXo

Revocar una clave

Haga clic en Revoke junto a la clave. La clave deja de funcionar inmediatamente — el tokenizer la rechaza con 403 Forbidden en la siguiente solicitud.

Rotar una clave

Haga clic en Rotate. Esto genera atómicamente una nueva clave y revoca la anterior. El nuevo texto en claro se muestra una vez. Use la rotación para reemplazar una clave que pueda haber sido expuesta sin interrumpir el servicio entre la generación y el despliegue.

Gestionar usuarios

Los usuarios se unen automáticamente — cualquier persona que inicie sesión con una dirección de correo electrónico perteneciente al dominio del tenant se añade como viewer. No se requiere ningún paso de invitación.

Ver usuarios

Navegue a Users en la barra lateral para ver todos los usuarios, sus roles, la fecha del último inicio de sesión y el proveedor OAuth.

Cambiar el rol de un usuario

Haga clic en el badge de rol junto a un usuario para abrir el selector de rol. Requiere el rol owner. Transiciones disponibles:

• viewer → admin o owner
• admin → viewer o owner
• owner → admin o viewer (solo si existe al menos otro owner)

Eliminar un usuario

Haga clic en Remove junto al usuario. Requiere el rol owner. La sesión del usuario se invalida y no puede volver a iniciar sesión a menos que se reautentique (en cuyo caso se uniría nuevamente como viewer).

Registro de auditoría

Cada acción de mutación realizada a través de la consola se registra en el log de auditoría. Navegue a Audit Log en la barra lateral para ver y paginar las entradas.

Cada entrada registra: fecha/hora, actor (nombre y correo del usuario), dirección IP, tipo de acción, recurso objetivo y un blob JSON de detalles opcional.