Skip to main content
O comportamento de segurança do Matcher é configurado no deployment. Esta página descreve os controles implementados pelo Matcher e os limites que continuam sob responsabilidade das suas plataformas de identidade, rede e armazenamento. Ela não é uma certificação de conformidade.

​
Autenticação e autorização

O Matcher usa AUTH_PROVIDER para selecionar o comportamento de autenticação: Quando não definido, AUTH_PROVIDER é derivado de PLUGIN_AUTH_ENABLED: habilitado seleciona plugin-auth; desabilitado seleciona disabled. PLUGIN_AUTH_ADDRESS é obrigatório para plugin-auth. O provedor workos exige PLUGIN_AUTH_ENABLED=true e sua configuração WorkOS. Os aliases legados AUTH_ENABLED e AUTH_SERVICE_ADDRESS continuam válidos para as variáveis atuais PLUGIN_AUTH_*; aliases conflitantes impedem a inicialização. Quando a autenticação está habilitada, operações de API protegidas exigem um bearer token:
Não mantenha um inventário estático de permissões em runbooks de deployment. Os requisitos de permissão são definidos pela rota e pela política do provedor e podem evoluir com o produto. Use a referência da API e a configuração do provedor de autorização ao atribuir papéis.

​
Isolamento de tenants

Com a autenticação desabilitada, o Matcher usa DEFAULT_TENANT_ID e DEFAULT_TENANT_SLUG. Com AUTH_PROVIDER=plugin-auth no modo single-tenant, uma requisição autenticada usa um claim válido tenant_id ou tenantId quando ele está presente e recorre à identidade padrão somente quando esse claim está ausente; um tenant ID malformado ou inválido é rejeitado. No modo multi-tenant (MULTI_TENANT_ENABLED=true), PLUGIN_AUTH_ENABLED também deve ser true e a requisição autenticada precisa trazer um claim válido tenant_id ou tenantId; o Matcher rejeita a inicialização quando MULTI_TENANT_ENABLED=true e PLUGIN_AUTH_ENABLED=false. AUTH_PROVIDER=workos atualmente resolve requisições verificadas em DEFAULT_TENANT_ID; não o use para selecionar tenants. O Matcher não aceita um seletor de tenant controlado pelo chamador em parâmetros de consulta ou corpos de requisição. O Tenant Manager resolve um pool PostgreSQL dedicado para cada tenant. O tenant padrão usa o pool raiz; o Matcher não usa SET search_path do PostgreSQL para alternar o schema de tenant. Trate credenciais de banco de dados, limites de rede e configuração do Tenant Manager como parte do limite de isolamento e verifique-os no seu deployment.

​
Transporte e conexões de infraestrutura

O Matcher pode terminar TLS com SERVER_TLS_CERT_FILE e SERVER_TLS_KEY_FILE, ou operar atrás de um proxy confiável que termina TLS com TLS_TERMINATED_UPSTREAM=true. O certificado e a chave devem ser configurados juntos. A exigência de TLS para dependências é opt-in. Configure a flag aplicável para fazer a inicialização falhar quando sua conexão não declarar TLS:
  • POSTGRES_TLS_REQUIRED
  • POSTGRES_REPLICA_TLS_REQUIRED
  • REDIS_TLS_REQUIRED
  • RABBITMQ_TLS_REQUIRED
  • OBJECT_STORAGE_TLS_REQUIRED
Essas flags protegem as conexões de dependências configuradas; elas não substituem os controles de ingress, rede, certificados ou segurança de armazenamento do deployment.

​
Trilha de auditoria e mapeamentos de ator

O Matcher grava registros de auditoria para fluxos de mutação instrumentados. Os registros são somente-anexação e conectados por uma cadeia de hashes à prova de adulteração por tenant. O endpoint de verificação é somente leitura e informa o resultado para os registros que inspecionou.
Mapeamentos de ator podem associar um actor ID opaco a um nome de exibição e e-mail. Fora dos ambientes local, desenvolvimento e teste, defina ACTOR_PII_ENCRYPTION_KEY com uma chave de 32 bytes codificada em base64 antes de usá-los. Quando ela não estiver definida, operações de mapeamento retornam um erro de encryptor-required; o Matcher nunca armazena em texto aberto a PII dos mapeamentos de ator. Os registros de auditoria são tratados separadamente e podem manter o actorId bruto, inclusive quando ele é um endereço de e-mail. Com uma chave, o Matcher criptografa a PII armazenada nos mapeamentos e oferece operações de pseudonimização e exclusão. Determine separadamente obrigações de retenção, privacidade e legais do seu deployment.

​
Integrações de saída

Conectores de despacho de exceções usam controles SSRF que rejeitam, por padrão, destinos privados, loopback e link-local. Revise toda configuração que permita destinos privados antes de usá-la em produção. Fluxos de webhook e callback têm seus próprios mecanismos de verificação e idempotência. Configure segredos compartilhados ou faixas IP de origem confiáveis somente pelos ajustes do conector correspondente; não use esta página como contrato de protocolo. Use a referência da API para os headers e o contrato de payload de uma integração específica.

​
Checklist operacional

  • Selecione e teste o provedor de autenticação desejado antes de expor o Matcher.
  • Habilite a autenticação antes de habilitar o modo multi-tenant.
  • Exija TLS para cada dependência que não deve aceitar conexões em texto aberto.
  • Mantenha papéis de autorização com o menor privilégio e revise-os no provedor de identidade.
  • Monitore registros de auditoria e investigue de forma independente uma verificação de cadeia que falhar.
  • Proteja armazenamento, backups, certificados e segredos com controles do deployment.

​
Próximos passos

Configuração em tempo de execução

Revise quais valores de runtime podem mudar sem reiniciar o Matcher.

Governança

Gerencie mapeamentos de ator, logs de auditoria e arquivos.