Toda requisição de API da sua organização fica registrada por 365 dias, com quem, o quê, quando, de onde e sob qual aplicação. É o primeiro lugar a olhar.
Toda requisição de API na sua organização é registrada automaticamente e mantida por 365 dias - do console, da sua integração e dos seus colegas de equipe. Encontre em Configurações → Registro de auditoria. Cada decisão que o Investigador toma por conta própria também fica registrada ali, identificada como O investigador.
#O que é registrado
Toda requisição feita à plataforma Didit dentro da sua organização, seja qual for a origem. Cada entrada traz:
| Campo | Detalhe |
|---|---|
| Carimbo de data/hora | Quando a requisição foi feita |
| User | Quem fez: o membro que fez a requisição; para uma requisição com chave de API, o nome da chave com uma tag Chave de API; Didit para o que a Didit faz por conta própria; e O investigador para uma decisão que ele toma por conta própria |
| Method | GET, POST, PUT, DELETE |
| Path | O endpoint chamado |
| Status | O código de status HTTP da resposta |
| Endereço IP | De onde veio a requisição |
| Application | A qual aplicação ela pertencia |
Os registros são mantidos por 365 dias e depois excluídos automaticamente.
Um registro de auditoria redesenhado, que descreve cada alteração em palavras e pode exportar o que você está vendo, está sendo liberado aos poucos. Até ele chegar à sua organização, a página mostra o registro de requisições descrito aqui.
#Para que ele realmente serve
Quatro situações em que é a ferramenta certa:
- "Quem alterou este fluxo de trabalho?" Um fluxo se comportando de forma diferente de ontem geralmente tem uma edição por trás, e o registro mostra quem a fez.
- Investigando um incidente. Rastrear exatamente o que foi acessado, por quem, a partir de qual endereço, em qual ordem.
- Depurando uma integração. Ver as requisições que o seu próprio código realmente fez, em vez das que você acredita que fez - inclusive as que retornaram 4xx.
- Evidenciando o controle de acesso. Mostrar a um auditor que o acesso a dados de verificação é atribuído e revisável.
#Filtrando
Filtre por usuário (um membro, uma chave de API, Didit ou O investigador), endpoint ou intervalo de datas para reduzir uma lista longa. Ao investigar algo específico, comece pelo carimbo de data/hora e vá se afastando dali - uma requisição raramente acontece sozinha, e as chamadas ao redor dela geralmente contam a história.
#Requisições com chave de API são atribuídas à chave, não a uma pessoa
Uma requisição com chave de API não tem uma pessoa a quem atribuí-la, então ela mostra o nome da chave. Essa é a representação honesta - a plataforma genuinamente não sabe qual dos seus serviços ou engenheiros fez a chamada.
A consequência prática: uma única chave compartilhada entre vários serviços torna um incidente consideravelmente mais difícil de investigar. Se a atribuição importa para você, dê a cada serviço sua própria chave. Veja como gerenciar suas chaves de API.
#As decisões próprias do Investigador são atribuídas ao Investigador
Quando o Investigador decide por conta própria, dentro da autonomia que você deu a ele, a entrada mostra O investigador, e não uma pessoa ou uma chave. Isso vale para cada decisão que ele toma: aprovar ou recusar uma sessão ou pedir ao usuário que a reenvie, definir o status de uma transação e resolver um caso, encaminhá-lo ou pedir informações sobre ele. Cada uma dessas entradas leva ao relatório do Investigador por trás da decisão, para que você veja o que ele encontrou e qual regra da sua política aplicou.
Quando uma pessoa decide sobre um relatório do Investigador, aceitando a recomendação ou alterando-a, a entrada é atribuída a essa pessoa, como qualquer outra alteração que ela faça. A trilha completa do Investigador, com seus relatórios, perguntas e regras de segurança, continua no próprio registro de Atividade dele. Veja Controlar e supervisionar o Investigador.
#O que está no registro, e o que não está
O registro guarda atividade - quem chamou o quê, quando, de onde e qual status voltou. É uma trilha de metadados, não uma cópia dos dados de verificação.
Se você precisa saber se dados pessoais de clientes aparecem nessas entradas - uma pergunta comum durante revisões de proteção de dados - obtenha a resposta com o seu contato na Didit e registre-a, em vez de deduzi-la de uma página de ajuda. É exatamente o tipo de afirmação que a sua própria AIPD (avaliação de impacto à proteção de dados) vai precisar comprovar.
#Quem pode ver
O acesso aos registros de auditoria segue a função de cada pessoa. Responsável pela Conformidade inclui esse acesso; Leitor não tem acesso amplo. Proprietários podem concedê-lo a uma função personalizada. Veja como convidar membros da equipe e definir funções.
Remover um colega não remove o histórico dele do registro - e esse é o objetivo. Uma trilha que você pode editar não é uma trilha.
#Exportações e relatórios também são registrados
Gerar um PDF de sessão ou uma exportação CSV é uma chamada de API, então ela aparece aqui com quem a fez. Isso é útil quando você precisa mostrar que o acesso a evidências de verificação é controlado, e não livre. Veja como baixar um relatório de verificação.
#Se você precisa de mais de 365 dias
A retenção é fixa em 365 dias. Se a sua obrigação exige um período maior, exporte o que você precisa periodicamente e guarde no seu próprio sistema - o mesmo padrão de reter evidências de sessão por conta própria. Decidir o período exigido é uma decisão de conformidade da sua equipe; não planeje em cima de uma suposição.
A retenção dos registros de auditoria e a retenção dos dados de verificação são configurações separadas. Definir uma janela de retenção curta para os dados de sessão não encurta o registro de auditoria, e o contrário também é verdade. Veja como a Didit protege os dados dos seus usuários.
Ainda com dúvida? Fale com uma pessoa.
Inclua o ID da sua organização e o ID da sessão sobre a qual você está perguntando.