> ## Documentation Index > Fetch the complete documentation index at: https://docs.didit.me/llms.txt > Use this file to discover all available pages before exploring further. # Registros de auditoria: atividade da API e conformidade > O Didit registra toda a atividade da API em registros de auditoria pesquisáveis. Filtre por usuário, método, status e data para conformidade. Os registros de auditoria oferecem um histórico completo e pesquisável de toda a atividade da API na sua organização. Cada requisição feita à plataforma Didit, seja pelo Console, pela sua integração ou por membros da equipe, é registrada automaticamente para fins de segurança, conformidade e solução de problemas. ![Registros de auditoria no console da Didit](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14) *** ## Por que usar registros de auditoria | Desafio | Solução | | - | - | | Requisitos de conformidade regulatória | Trilha de auditoria completa de toda a atividade, pelo período de retenção do seu plano | | Investigação de incidentes de segurança | Rastreie exatamente quem fez o quê e quando | | Depuração de problemas de integração | Veja o caminho, o status e o corpo com dados ocultados de cada requisição | | Responsabilização da equipe | Acompanhe quais membros da equipe acessaram quais dados | | Monitoramento de uso | Entenda os padrões de consumo da API | *** ## Como acessar os registros de auditoria Abra **Settings > Organization > Audit log** no Didit Console. A interface exibe uma lista cronológica de todas as requisições de API feitas na sua organização. Cada entrada do registro inclui: | Campo | Descrição | | - | - | | **Carimbo de tempo** | Quando a requisição foi feita | | **Usuário** | Quem a fez: o e-mail do membro da equipe autenticado; o nome da chave de API que fez a requisição, marcado como **API key**; ou **O investigador**, para uma decisão que ele tomou por conta própria | | **Método** | Método HTTP (GET, POST, PUT, DELETE) | | **Caminho** | O endpoint da API que foi chamado | | **Status** | Código de status da resposta HTTP | | **Endereço IP** | IP de origem da requisição | | **Aplicação** | A aplicação à qual a requisição estava associada | ### Decisões tomadas pelo Investigator Cada decisão que o [Investigator](https://docs.didit.me/pt-br/console/investigator.md) toma por conta própria é registrada em **O investigador**, e não em um membro ou em uma chave de API: aprovar ou recusar uma sessão ou solicitar um reenvio, definir o status de uma transação, e resolver um caso, escalá-lo ou solicitar informações sobre ele. A entrada contém um link para o relatório do Investigator que embasa a decisão. Quando uma pessoa aceita ou substitui uma recomendação do Investigator, a entrada é registrada em nome dessa pessoa. *** ## Filtros e busca A interface de registros de auditoria oferece recursos avançados de filtragem para ajudar você a encontrar exatamente o que procura. ### Busca inteligente A barra de busca detecta automaticamente o que você está procurando: | Tipo de busca | Exemplo | Comportamento | | - | - | - | | **Caminho exato** | `/v1/organization/.../sessions/` | Encontra registros com exatamente este caminho de requisição | | **E-mail exato** | `admin@company.com` | Encontra registros deste usuário específico | | **IP exato** | `192.168.1.100` | Encontra registros deste endereço IP | | **Curinga** | `/v1/*/analytics/*` | Corresponde a padrões com curingas | | **Texto geral** | `sessions` | Busca aproximada em todos os campos | ### Filtros disponíveis | Filtro | Descrição | Exemplo | | - | - | - | | **Aplicação** | Filtra por uma aplicação específica | Selecione na lista suspensa | | **Membros e chaves de API** | Filtra pela chave de API que fez as requisições | Selecione uma chave da aplicação escolhida | | **Ator** | Mostra apenas o que membros, chaves de API ou o Investigator fizeram | **The Investigator** | | **Método** | Filtra por método HTTP | `GET`, `POST`, `PUT`, `DELETE` | | **Código de status** | Filtra pelo status da resposta | `200`, `401`, `500` | | **Intervalo de datas** | Filtra por período | Últimos 7 dias, intervalo personalizado | *** ## Retenção de dados O seu plano define até quando você pode consultar o registro de auditoria e se pode exportá-lo: | Plano | Até quando | Exportação | | - | - | - | | Free | 30 dias | Não | | Growth | 1 ano | Não | | Scale | 3 anos | Sim | | Enterprise | Definido pelo seu contrato | Sim | Uma exportação em um plano que não inclui esse recurso retorna `403` com `"code": "plan_limit_exceeded"`. *** ## Segurança e privacidade ### O que é registrado Os registros de auditoria capturam metadados sobre as requisições de API: * Carimbo de tempo e duração da requisição * Identidade do usuário (e-mail, ID do usuário) ou a chave de API que fez a requisição (o nome dela e os primeiros caracteres do segredo, nunca o segredo completo) * Caminho da requisição e parâmetros de consulta * Códigos de status da resposta * Endereço IP e user agent do cliente ### Corpos de requisição e de resposta de chamadas com chave de API Para uma chamada feita com uma chave de API, o registro de auditoria também mantém uma cópia com dados ocultados do corpo JSON da requisição de uma escrita e da resposta a uma escrita ou a um erro, para que você possa ver por que uma chamada falhou. A resposta a uma leitura bem-sucedida não é mantida. A ocultação segue uma política de negação por padrão: * A estrutura é mantida: nomes de campos, aninhamento, tipos de valor, tamanhos de arrays e tamanhos de strings. * Um valor só é mantido quando é um dos próprios identificadores, status, códigos, contagens ou carimbos de tempo da Didit, em um campo definido pela Didit, com o formato que esse campo espera. * Um booleano só é mantido em um campo definido pela Didit. * Todos os outros valores são substituídos por um marcador que indica o tipo e o tamanho, como `[redacted:string:12]`, `[redacted:number:5]` ou `[redacted:boolean]`, e `null` continua `null`. * Um nome de campo que não é 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 é JSON, como um formulário ou um upload de arquivo, é substituído por uma nota que indica o que ele era. * O que resta é cortado em 4.096 caracteres. Os parâmetros de consulta passam pela mesma ocultação. Apenas cabeçalhos padrão, como `content-type`, `user-agent` e os cabeçalhos de limite de requisições, são mantidos; todos os outros cabeçalhos são descartados junto com seus valores. Um valor enviado pelo seu próprio sistema, por exemplo em `metadata` ou `vendor_data`, nunca é mantido, mesmo quando o campo tem o nome de um dos campos da Didit. ### O que NÃO é registrado Para proteger dados sensíveis, os itens a seguir são excluídos automaticamente: * Tokens de autenticação e credenciais * Senhas e segredos * Dados pessoais das sessões de verificação ### Controle de acesso Visualizar o registro de auditoria exige as permissões de leitura e de listagem de `audit-logs`. As funções Reader, Compliance Officer, Developer, Admin e Owner têm essas permissões, e uma [função personalizada](https://docs.didit.me/pt-br/console/roles-permissions.md) as recebe ao selecionar Audit logs no editor de funções. *** ## Casos de uso comuns > [accordion] Auditoria de conformidade > > Demonstre aos auditores que você tem visibilidade completa sobre quem acessou os dados de verificação: > > 1. Filtre por um intervalo de datas que corresponda ao período da auditoria > 2. Filtre por aplicações ou usuários específicos, se necessário > 3. Exporte os resultados ou faça capturas de tela para a documentação > [accordion] Investigação de segurança > > Se você suspeitar de acesso não autorizado: > > 1. Pesquise o e-mail do usuário afetado ou endereços IP suspeitos > 2. Filtre por um intervalo de datas em torno do suposto incidente > 3. Procure padrões incomuns: tentativas de autenticação com falha, endpoints inesperados, horários atípicos > [accordion] Depuração da integração > > Ao investigar problemas na integração com a API: > > 1. Pesquise o caminho do endpoint específico > 2. Filtre pelos códigos de status `4xx` ou `5xx` para encontrar erros > 3. Anote os registros de data e hora para correlacioná-los com os logs da sua aplicação > [accordion] Revisão da atividade da equipe > > Acompanhe como sua equipe usa a plataforma: > > 1. Filtre pelos e-mails de membros específicos da equipe > 2. Verifique quais sessões e recursos eles acessaram > 3. Certifique-se de que os membros da equipe estão seguindo os procedimentos adequados *** ## Boas práticas 1. **Revisões regulares**: revise os registros de auditoria periodicamente para identificar anomalias cedo. 2. **Refine sua pesquisa**: use filtros específicos para reduzir o ruído e encontrar as entradas relevantes mais rápido. 3. **Intervalos de datas**: sempre especifique um intervalo de datas para obter melhor desempenho em grandes volumes de dados. 4. **Salve pesquisas nos favoritos**: salve as combinações de filtros mais usadas como favoritos no navegador para acessá-las rapidamente. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.