Skip to main content
O comportamento de segurança do Matcher é definido no deploy. Esta página descreve os controles implementados pelo Matcher e as fronteiras 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 escolher o comportamento de autenticação: Quando AUTH_PROVIDER não está definida, o Matcher a deriva de PLUGIN_AUTH_ENABLED. Habilitada, ela escolhe plugin-auth. Desabilitada, ela escolhe disabled. O provedor plugin-auth precisa de PLUGIN_AUTH_ADDRESS. O Matcher rejeita qualquer outro valor de provedor, incluindo o provedor workos, já aposentado. As variáveis antigas AUTH_ENABLED e AUTH_SERVICE_ADDRESS continuam sendo apelidos das variáveis PLUGIN_AUTH_* atuais. Apelidos em conflito impedem a inicialização. Quando você habilita a autenticação, as operações de API protegidas exigem um bearer token:
Não mantenha um inventário estático de permissões nos runbooks de deploy. A política da rota e do provedor define as exigências de permissão, e ela pode evoluir junto 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

Em configurações com autenticação desabilitada e de tenant único, o Matcher usa DEFAULT_TENANT_ID e DEFAULT_TENANT_SLUG. No modo multi-tenant (MULTI_TENANT_ENABLED=true), o provedor resolvido deve ser plugin-auth, e a requisição autenticada deve trazer uma claim tenant_id ou tenantId válida. O Matcher rejeita a inicialização quando o provedor resolvido é disabled. O Matcher não aceita um seletor de tenant controlado pelo chamador vindo de query string ou de corpo de requisição. O Tenant Manager resolve um pool dedicado do PostgreSQL para cada tenant. O tenant padrão usa o pool raiz. O Matcher não usa o SET search_path do PostgreSQL para trocar o schema do tenant. Trate as credenciais de banco, as fronteiras de rede e a configuração do Tenant Manager como parte da fronteira de isolamento e verifique-as no seu deploy.

​
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 o TLS, com TLS_TERMINATED_UPSTREAM=true. Configure o certificado e a chave juntos. A exigência de TLS nas dependências precisa ser ativada. Defina a flag aplicável para que a inicialização falhe quando a configuração de conexão dela 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ência configuradas. Elas não substituem os controles de ingress, rede, certificado ou segurança de armazenamento fornecidos pelo deploy.

​
Trilha de auditoria e mapeamentos de atores

O Matcher grava registros de auditoria para os workflows de mutação instrumentados. Os registros de auditoria são somente-anexação e ficam ligados por uma cadeia de hash por tenant que evidencia adulteração. O endpoint de verificação continua somente leitura e informa o resultado dos registros que inspecionou.
Os mapeamentos de atores podem associar um ID de ator opaco a um nome de exibição e a um e-mail. Fora dos ambientes local, de desenvolvimento e de teste, defina ACTOR_PII_ENCRYPTION_KEY com uma chave de 32 bytes codificada em base64 antes de usá-los. Quando ela não está definida, as operações de mapeamento de ator retornam um erro de criptografador obrigatório, e o Matcher nunca guarda em texto puro os dados pessoais dos mapeamentos de atores. O Matcher trata os registros de auditoria à parte, e eles podem reter o actorId bruto, que pode ser um endereço de e-mail. Com uma chave, o Matcher criptografa os dados pessoais armazenados dos mapeamentos de atores e oferece suporte às operações de pseudonimização e exclusão. Determine à parte as obrigações de retenção, privacidade e legais do seu deploy.

​
Integrações de saída

Os conectores de despacho de exceções usam controles de SSRF que rejeitam destinos privados, de loopback e link-local por padrão. Revise qualquer configuração que permita destinos privados antes de usá-la em produção. Os fluxos de webhook e de callback têm seus próprios mecanismos de verificação e idempotência. Configure segredos compartilhados ou faixas de IP de origem confiáveis apenas nas configurações do conector correspondente. Não trate esta página como um 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

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

​
Próximos passos

Configuração de runtime

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

Governança

Gerencie mapeamentos de atores, logs de auditoria e arquivos.