> ## 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 de Matcher, el aislamiento de tenants, la postura de transporte, el registro de auditoría y los controles de integraciones salientes.

El comportamiento de seguridad de Matcher se configura en el despliegue. Esta página describe los controles que implementa 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 en los tokens y las decisiones de permisos al servicio `plugin-auth` configurado, a través de `lib-auth`. Matcher no guarda ningún secreto local de firma de JWT. |
| `disabled`    | Matcher no exige autenticación por token bearer ni autorización.                                                                                                                              |

Cuando `AUTH_PROVIDER` no está configurada, Matcher la deriva de `PLUGIN_AUTH_ENABLED`. Habilitada selecciona `plugin-auth`. Deshabilitada selecciona `disabled`. El proveedor `plugin-auth` necesita `PLUGIN_AUTH_ADDRESS`. Matcher rechaza cualquier otro valor de proveedor, incluido el proveedor `workos` retirado. Las variables heredadas `AUTH_ENABLED` y `AUTH_SERVICE_ADDRESS` siguen siendo alias de las variables `PLUGIN_AUTH_*` actuales. Los alias en conflicto impiden el arranque.

Cuando habilitas la autenticación, las operaciones de API protegidas requieren un token bearer:

```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 los runbooks de despliegue. La política de rutas y del proveedor definen los requisitos de permisos, y pueden evolucionar con el producto. Usa la referencia de API y la configuración del proveedor de autorización al asignar roles.

## Aislamiento de tenants

***

En configuraciones con autenticación deshabilitada y de un solo tenant, Matcher usa `DEFAULT_TENANT_ID` y `DEFAULT_TENANT_SLUG`. En modo multi-tenant (`MULTI_TENANT_ENABLED=true`), el proveedor resuelto debe ser `plugin-auth`, y la solicitud autenticada debe llevar un claim `tenant_id` o `tenantId` válido. Matcher rechaza el arranque cuando el proveedor resuelto es `disabled`. Matcher no acepta un selector de tenant controlado por el llamador desde parámetros de query string ni desde cuerpos de solicitud.

Tenant Manager resuelve un pool de 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.

## Conexiones de transporte y 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`. Configura el certificado y la clave juntos.

La exigencia de TLS para las dependencias se activa de forma explícita. Configura el flag correspondiente para que el arranque falle cuando su configuración de 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 dependencia configuradas. No reemplazan los controles de ingress, red, certificados o seguridad de almacenamiento que aporta el despliegue.

## Registro de auditoría y mapeos de actores

***

Matcher escribe registros de auditoría para los workflows de mutación instrumentados. Los registros de auditoría son de solo anexado y se conectan mediante una cadena de hash por tenant con detección de manipulación. El endpoint de verificación permanece 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 actores pueden asociar un ID de actor opaco con un nombre visible y un correo electrónico. Fuera de los entornos local, de desarrollo y de prueba, configura `ACTOR_PII_ENCRYPTION_KEY` con una clave de 32 bytes codificada en base64 antes de usarlos. Cuando no está configurada, las operaciones de mapeo de actores devuelven un error que indica que se requiere un cifrador, y Matcher nunca almacena la PII de los mapeos de actores en texto plano. Matcher trata los registros de auditoría por separado, y estos pueden conservar el `actorId` sin procesar, que puede ser una dirección de correo electrónico. Con una clave, Matcher cifra la PII almacenada de los mapeos de actores y admite 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 de SSRF que rechazan destinos privados, loopback y link-local de forma predeterminada. Revisa cualquier configuración que permita destinos privados antes de usarla en producción.

Los flujos de webhook y de callback tienen sus propios mecanismos de verificación e idempotencia. Configura los secretos compartidos o los rangos de IP de origen de confianza solo a través de los ajustes del conector correspondiente. No tomes esta página como un contrato de protocolo. Usa la referencia de API para conocer los headers y el contrato de payload de una integración específica.

## Lista de verificación operativa

***

* Selecciona y prueba el proveedor de autenticación previsto antes de exponer Matcher.
* Habilita la autenticación antes de habilitar el modo multi-tenant.
* Exige TLS para cada dependencia que no debe aceptar conexiones en texto plano.
* Mantén los roles de autorización con el mínimo 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.
* Mantén el almacenamiento, los backups, los certificados y los secretos protegidos por controles del despliegue.

## Próximos pasos

***

<Card title="Configuración en tiempo de ejecución" icon="sliders" href="/es/products/matcher/configuration/matcher-systemplane" horizontal>
  Revisa qué valores de tiempo de ejecución pueden cambiar sin reiniciar Matcher.
</Card>

<Card title="Gobernanza" icon="shield-halved" href="/es/products/matcher/reference/matcher-governance" horizontal>
  Gestiona mapeos de actores, logs de auditoría y archivos.
</Card>
