Skip to main content
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: 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:
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ó.
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

Configuración en tiempo de ejecución

Revisa qué valores de runtime pueden cambiar sin reiniciar Matcher.

Gobernanza

Gestiona mapeos de actores, logs de auditoría y archivos.