> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # Seguridad > Configura la autenticación, el aislamiento de tenants, la postura de transporte, la pista de auditoría y los controles de integraciones salientes de Matcher. El comportamiento de seguridad de Matcher se configura en el despliegue. Esta página describe los controles implementados por Matcher y los límites que siguen siendo responsabilidad de tus plataformas de identidad, red y almacenamiento. No es una certificación de cumplimiento. ## Autenticación y autorización *** Matcher usa `AUTH_PROVIDER` para seleccionar el comportamiento de autenticación: | Proveedor | Comportamiento | | ------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | `plugin-auth` | Matcher delega la confianza del token y las decisiones de permisos al servicio `plugin-auth` configurado mediante `lib-auth`. Matcher no guarda un secreto local de firma JWT. | | `workos` | Matcher verifica las firmas de bearer tokens contra los JWKS de WorkOS y evalúa su política RBAC localmente. | | `disabled` | Matcher no aplica autenticación ni autorización por bearer token. | Cuando no se define, `AUTH_PROVIDER` se deriva de `PLUGIN_AUTH_ENABLED`: habilitado selecciona `plugin-auth`; deshabilitado selecciona `disabled`. `PLUGIN_AUTH_ADDRESS` es obligatorio para `plugin-auth`. El proveedor `workos` requiere `PLUGIN_AUTH_ENABLED=true` y su configuración de WorkOS. Los alias heredados `AUTH_ENABLED` y `AUTH_SERVICE_ADDRESS` siguen siendo válidos para las variables actuales `PLUGIN_AUTH_*`; los alias conflictivos impiden el arranque. Cuando la autenticación está habilitada, las operaciones de API protegidas requieren un bearer token: ```bash theme={null} curl -X GET "https://api.matcher.example.com/v1/contexts" \ -H "Authorization: Bearer $TOKEN" ``` No mantengas un inventario estático de permisos en runbooks de despliegue. Los requisitos de permisos se definen con la ruta y la política del proveedor, y pueden cambiar con el producto. Usa la referencia de API y la configuración del proveedor de autorización al asignar roles. ## Aislamiento de tenants *** Con la autenticación deshabilitada, Matcher usa `DEFAULT_TENANT_ID` y `DEFAULT_TENANT_SLUG`. Con `AUTH_PROVIDER=plugin-auth` en modo de tenant único, una solicitud autenticada usa un claim válido `tenant_id` o `tenantId` cuando está presente y recurre a la identidad predeterminada solo cuando ese claim no está; un tenant ID malformado o no válido se rechaza. En modo multi-tenant (`MULTI_TENANT_ENABLED=true`), `PLUGIN_AUTH_ENABLED` también debe ser true y la solicitud autenticada debe incluir un claim válido `tenant_id` o `tenantId`; Matcher rechaza el arranque cuando `MULTI_TENANT_ENABLED=true` y `PLUGIN_AUTH_ENABLED=false`. `AUTH_PROVIDER=workos` actualmente resuelve las solicitudes verificadas en `DEFAULT_TENANT_ID`; no lo uses para seleccionar tenants. Matcher no acepta un selector de tenant controlado por quien llama desde parámetros de consulta o cuerpos de solicitud. Tenant Manager resuelve un pool PostgreSQL dedicado para cada tenant. El tenant predeterminado usa el pool raíz; Matcher no usa `SET search_path` de PostgreSQL para cambiar de esquema de tenant. Trata las credenciales de base de datos, los límites de red y la configuración de Tenant Manager como parte del límite de aislamiento y verifícalos en tu despliegue. ## Transporte y conexiones de infraestructura *** Matcher puede terminar TLS con `SERVER_TLS_CERT_FILE` y `SERVER_TLS_KEY_FILE`, u operar detrás de un proxy de confianza que termina TLS con `TLS_TERMINATED_UPSTREAM=true`. El certificado y la clave deben configurarse juntos. La exigencia de TLS para dependencias es opcional. Configura el flag aplicable para que el arranque falle cuando su conexión no declare TLS: * `POSTGRES_TLS_REQUIRED` * `POSTGRES_REPLICA_TLS_REQUIRED` * `REDIS_TLS_REQUIRED` * `RABBITMQ_TLS_REQUIRED` * `OBJECT_STORAGE_TLS_REQUIRED` Estos flags protegen las conexiones de dependencias configuradas; no sustituyen los controles de ingress, red, certificados o seguridad de almacenamiento del despliegue. ## Pista de auditoría y mapeos de actor *** Matcher escribe registros de auditoría para flujos de mutación instrumentados. Los registros son de solo anexión y se conectan mediante una cadena de hashes a prueba de manipulaciones por tenant. El endpoint de verificación es de solo lectura e informa el resultado para los registros que inspeccionó. ```bash theme={null} curl -X GET "https://api.matcher.example.com/v1/governance/audit-logs/verify" \ -H "Authorization: Bearer $TOKEN" ``` Los mapeos de actor pueden asociar un actor ID opaco con un nombre para mostrar y correo electrónico. Fuera de los entornos local, desarrollo y prueba, define `ACTOR_PII_ENCRYPTION_KEY` con una clave de 32 bytes codificada en base64 antes de usarlos. Cuando no se define, las operaciones de mapeo devuelven un error de encryptor-required; Matcher nunca almacena en texto claro la PII de los mapeos de actor. Los registros de auditoría se tratan por separado y pueden conservar el `actorId` sin procesar, que puede ser una dirección de correo. Con una clave, Matcher cifra la PII almacenada en los mapeos y ofrece operaciones de seudonimización y eliminación. Determina por separado las obligaciones de retención, privacidad y legales de tu despliegue. ## Integraciones salientes *** Los conectores de despacho de excepciones usan controles SSRF que rechazan por defecto destinos privados, loopback y link-local. Revisa toda configuración que permita destinos privados antes de usarla en producción. Los flujos de webhooks y callbacks tienen sus propios mecanismos de verificación e idempotencia. Configura secretos compartidos o rangos IP de origen confiables únicamente mediante los ajustes del conector correspondiente; no uses esta página como contrato de protocolo. Usa la referencia de API para los headers y el contrato de payload de una integración específica. ## Checklist operativo *** * Selecciona y prueba el proveedor de autenticación deseado antes de exponer Matcher. * Habilita la autenticación antes de habilitar el modo multi-tenant. * Exige TLS para cada dependencia que no deba aceptar conexiones en texto plano. * Mantén los roles de autorización con el menor privilegio y revísalos en el proveedor de identidad. * Monitorea los registros de auditoría e investiga de forma independiente una verificación de cadena fallida. * Protege almacenamiento, backups, certificados y secretos mediante controles de despliegue. ## Próximos pasos *** Revisa qué valores de runtime pueden cambiar sin reiniciar Matcher. Gestiona mapeos de actores, logs de auditoría y archivos.