> ## 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. # Registos de auditoria: rastreio de atividade da API e conformidade > Acompanhe toda a atividade da API no Didit com registos pesquisáveis. Filtre por utilizador, método, estado e data para auditorias e depuração. 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](https://mintcdn.com/didit-0f962782/ibesJiSLVa9jZb5z/images/console-audit-logs.jpg?fit=max\&auto=format\&n=ibesJiSLVa9jZb5z\&q=85\&s=bcd436f764486143268f5c5ca67d9d14) *** ## Para que servem os registos de auditoria? | Desafio | Solução | | - | - | | Requisitos de conformidade regulamentar | Registo completo de toda a atividade, pelo período que o seu plano permite conservar | | Investigação de incidentes de segurança | Identificar com exatidão quem fez o quê e quando | | Depuração de problemas de integração | Ver o caminho, o estado e o corpo redigido de cada pedido | | Responsabilização da equipa | Acompanhar que membros da equipa acederam a que dados | | Monitorização de utilização | Perceber os padrões de consumo da API | *** ## 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: | Campo | Descrição | | - | - | | **Selo temporal** | Quando o pedido foi feito | | **Utilizador** | Quem o fez: o e-mail do membro da equipa autenticado; o nome da chave de API que fez o pedido, marcado como **Chave de API**; ou **O investigador**, para uma decisão que tomou por iniciativa própria | | **Método** | Método HTTP (GET, POST, PUT, DELETE) | | **Caminho** | O endpoint da API que foi chamado | | **Estado** | Código de estado HTTP da resposta | | **Endereço IP** | IP de origem do pedido | | **Aplicação** | Aplicação à qual o pedido estava associado | ### Decisões tomadas pelo investigador Cada decisão que o [Investigador](https://docs.didit.me/pt/console/investigator.md) 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: | Tipo de pesquisa | Exemplo | Comportamento | | - | - | - | | **Caminho exato** | `/v1/organization/.../sessions/` | Encontra os registos com este caminho de pedido exato | | **E-mail exato** | `admin@company.com` | Encontra os registos deste utilizador específico | | **IP exato** | `192.168.1.100` | Encontra os registos deste endereço IP | | **Curinga** | `/v1/*/analytics/*` | Corresponde a padrões com caracteres curinga | | **Texto geral** | `sessions` | Pesquisa aproximada em todos os campos | ### Filtros disponíveis | Filtro | Descrição | Exemplo | | - | - | - | | **Aplicação** | Filtrar por aplicação específica | Selecionar na lista pendente | | **Membros e chaves de API** | Filtrar pela chave de API que fez os pedidos | Selecionar uma chave da aplicação escolhida | | **Ator** | Mostrar apenas o que os membros, as chaves de API ou o Investigador fizeram | **O investigador** | | **Método** | Filtrar pelo método HTTP | `GET`, `POST`, `PUT`, `DELETE` | | **Código de estado** | Filtrar pelo estado da resposta | `200`, `401`, `500` | | **Intervalo de datas** | Filtrar por período | Últimos 7 dias, intervalo personalizado | *** ## Conservação de dados O seu plano define até onde pode consultar o registo de auditoria e se pode exportá-lo: | Plano | Até onde | 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 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](https://docs.didit.me/pt/console/roles-permissions.md) recebe-as ao selecionar Audit logs no editor de funções. *** ## Casos de utilização comuns > [accordion] Auditoria de conformidade > > 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 > [accordion] Investigação de segurança > > 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 > [accordion] Depuração de integrações > > 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 > [accordion] Revisão da atividade da equipa > > 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. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.