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

Configuración en tiempo de ejecución

Revisa qué valores de tiempo de ejecución pueden cambiar sin reiniciar Matcher.

Gobernanza

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