Segurança

Isolamento por empresa

Toda leitura é filtrada pela empresa que está no token de acesso. A empresa vem da claim do token, nunca de um parâmetro da requisição, então não existe entrada capaz de ampliar o escopo de uma credencial.

Os recursos são endereçados por identificadores opacos com prefixo (mtg_, call_, usr_, tpl_), alocados por empresa. Ids internos sequenciais nunca são expostos, então não dá para inferir volume nem enumerar ids.

Um identificador que não é da sua empresa devolve 404, nunca 403 — a API não confirma que o recurso existe em outro lugar.

A posse é resolvida na leitura

Um registro pertence à empresa padrão do usuário dono dele, avaliada no momento da consulta, e não congelada quando o registro foi criado.

Vale dizer a consequência com todas as letras: se a empresa padrão de um usuário muda, o histórico dele vai junto. Um vendedor que troca de empresa dentro do mesmo grupo leva o histórico de reuniões para a API da empresa nova.

É um trade-off deliberado de não desnormalizar a posse no registro. Se esse comportamento não couber no seu acordo de dados, levante isso com seu contato na Salesbud antes de construir em cima.

Transcrições têm portão próprio

transcriptions.read é um escopo distinto de meetings.read e calls.read, e uma credencial pode ter os escopos de coleção sem ele. A transcrição é o dado mais sensível que a API serve — a fala literal do cliente — então acessar o metadado de uma reunião não implica acessar o que foi dito nela.

O portão soma em vez de substituir o escopo da coleção: a requisição de transcrição é checada contra os dois, então uma credencial restrita a ligações não alcança transcrição de reunião por ter transcriptions.read.

O texto da transcrição é sanitizado antes de sair do serviço.

Tudo é auditado

Toda leitura de negócio é registrada: qual credencial, qual empresa, qual rota, quais ids de recurso e qual identidade chamou.

A gravação da auditoria é fail closed. Se a trilha não puder ser escrita, a leitura não é devolvida — você recebe 503 AUDIT_UNAVAILABLE. Uma resposta bem-sucedida, portanto, significa que o acesso ficou registrado.

Higiene de credencial

• Os secrets são guardados apenas como hash HMAC-SHA256 com pepper do serviço. Não podem ser lidos de volta, só rotacionados.
• A rotação mantém o secret anterior válido por sete dias para você fazer deploy sem downtime; revogue assim que o novo estiver no ar.
• Em suspeita de vazamento, revogue o client — isso invalida os tokens emitidos na hora. A rotação não, porque o secret antigo continua valendo.
• Configure allowlist de IP quando a integração roda de endereços fixos. Ela vale na emissão e em toda requisição, então um token vazado não serve de fora.

O que nunca sai do serviço

Stack trace, caminho de arquivo, id interno, token, secret e corpo de requisição nunca são devolvidos numa resposta, nem escritos em log.