Saltar para o conteúdo principal
Os registos de auditoria oferecem um registo completo e pesquisável de toda a atividade da API na sua organização. Cada pedido feito à plataforma Didit, quer a partir da Console, da sua integração ou dos membros da equipa, é registado automaticamente para efeitos de segurança, conformidade e resolução de problemas.
Registos de auditoria na Console da Didit

​
Para que servem os registos de auditoria?

​
Como aceder aos registos de auditoria

Abra Settings > Organization > Audit log na Console da Didit. A interface apresenta uma lista cronológica de todos os pedidos à API feitos na sua organização. Cada entrada do registo inclui:

​
Decisões tomadas pelo investigador

Cada decisão que o Investigador toma por iniciativa própria é registada em O investigador, e não num membro nem numa chave de API: aprovar ou recusar uma sessão ou pedir uma nova submissão, definir o estado de uma transação, e resolver um caso, escalá-lo ou pedir informações sobre ele. A entrada contém uma ligação para o relatório do Investigador subjacente à decisão. Quando uma pessoa aceita ou substitui uma recomendação do Investigador, a entrada fica registada em nome dessa pessoa.

​
Filtragem e pesquisa

A interface de Registos de auditoria disponibiliza capacidades de filtragem avançadas, para ajudar a encontrar exatamente o que procura.

​
Pesquisa inteligente

A barra de pesquisa deteta automaticamente o que procura:

​
Filtros disponíveis

​
Conservação de dados

O seu plano define até onde pode consultar o registo de auditoria e se pode exportá-lo: Uma exportação num plano que não a inclui devolve 403 com "code": "plan_limit_exceeded".

​
Segurança e privacidade

​
O que é registado

Os registos de auditoria capturam metadados sobre os pedidos à API:
  • Selo temporal e duração do pedido
  • Identidade do utilizador (e-mail, ID de utilizador), ou a chave de API que fez o pedido (o nome e os primeiros caracteres do seu segredo, nunca o segredo completo)
  • Caminho do pedido e parâmetros de consulta
  • Códigos de estado das respostas
  • Endereço IP do cliente e agente do utilizador

​
Corpos de pedidos e respostas de chamadas com chave de API

Para uma chamada feita com uma chave de API, o registo de auditoria guarda também uma cópia com os dados ocultados do corpo JSON de uma operação de escrita e da resposta a uma operação de escrita ou a um erro, para que possa ver porque é que uma chamada falhou. A resposta a uma leitura bem-sucedida não é guardada. A ocultação segue uma regra de recusa por defeito:
  • A estrutura mantém-se: nomes dos campos, aninhamento, tipos de valores, tamanhos das matrizes e comprimentos das cadeias de caracteres.
  • Um valor só se mantém quando é um identificador, estado, código, contagem ou selo temporal da própria Didit, num campo definido pela Didit, com o formato esperado pelo campo.
  • Um booleano só se mantém num campo definido pela Didit.
  • Todos os outros valores são substituídos por uma marca que indica o tipo e o comprimento, como [redacted:string:12], [redacted:number:5] ou [redacted:boolean], e null mantém-se como null.
  • Um nome de campo que não seja um identificador simples, como um endereço de e-mail ou um número de telefone usado como chave, é substituído por [redacted:key:23].
  • Um corpo que não seja JSON, como um formulário ou um carregamento de ficheiro, é substituído por uma nota que indica o que era.
  • O resultado é cortado aos 4,096 caracteres.
Os parâmetros de consulta passam pela mesma ocultação. Só os cabeçalhos padrão, como content-type, user-agent e os cabeçalhos de limite de pedidos, são mantidos; todos os outros cabeçalhos são eliminados com o respetivo valor. Um valor enviado pelo seu próprio sistema, por exemplo em metadata ou vendor_data, nunca é mantido, mesmo quando o campo tem um nome semelhante a um dos campos da Didit.

​
O que NÃO é registado

Para proteger os dados sensíveis, são excluídos automaticamente:
  • Tokens e credenciais de autenticação
  • Palavras-passe e segredos
  • Dados pessoais de sessões de verificação

​
Controlo de acesso

Consultar o registo de auditoria requer as permissões de leitura e listagem de audit-logs. As funções Reader, Compliance Officer, Developer, Admin e Owner têm ambas, e uma função personalizada recebe-as ao selecionar Audit logs no editor de funções.

​
Casos de utilização comuns

Demonstre aos auditores que tem visibilidade total sobre quem acedeu aos dados de verificação:
  1. Filtre pelo intervalo de datas correspondente ao período de auditoria
  2. Filtre por aplicações ou utilizadores específicos, se necessário
  3. Exporte os resultados ou faça uma captura de ecrã para documentação
Se suspeitar de acesso não autorizado:
  1. Pesquise o e-mail do utilizador afetado ou os endereços IP suspeitos
  2. Filtre pelo intervalo de datas em torno do incidente suspeito
  3. Procure padrões invulgares: tentativas de autenticação falhadas, endpoints inesperados, horas invulgares
Ao resolver problemas de integração da API:
  1. Pesquise o caminho do endpoint específico
  2. Filtre pelos códigos de estado 4xx ou 5xx para encontrar erros
  3. Anote os carimbos de data/hora para os correlacionar com os registos da sua aplicação
Acompanhe a forma como a sua equipa utiliza a plataforma:
  1. Filtre pelos e-mails de membros específicos da equipa
  2. Reveja as sessões e funcionalidades a que acederam
  3. Certifique-se de que os membros da equipa seguem os procedimentos adequados

​
Boas práticas

  1. Revisões regulares: reveja periodicamente os registos de auditoria para detetar anomalias numa fase inicial.
  2. Restrinja a pesquisa: use filtros específicos para reduzir o ruído e encontrar as entradas relevantes mais depressa.
  3. Intervalos de datas: indique sempre um intervalo de datas para obter melhor desempenho em conjuntos de dados grandes.
  4. Guarde pesquisas: guarde as combinações de filtros mais usadas como marcadores do navegador para aceder a elas rapidamente.
Última modificação em 7 de novembro de 2026