Usar os registos de auditoria
Todos os pedidos de API na tua organização são registados durante 365 dias - quem, o quê, quando, de onde, e sob que aplicação. É o primeiro sítio a consultar quando precisas de saber o que aconteceu.
Todos os pedidos de API na tua organização são registados automaticamente e mantidos durante 365 dias - a partir da consola, da tua integração, e dos teus colegas de equipa também. Encontra-os em Registos de Auditoria na barra lateral.
#O que é registado
- Filtra por membro, caminho, método ou data para responderes a 'quem alterou isto'.
- Method e status distinguem uma leitura de uma alteração que teve efeito real.
- O membro que fez a chamada.
- De onde veio - o detalhe que transforma um registo em prova.
Todos os pedidos feitos à plataforma Didit dentro da tua organização, seja qual for a sua origem. Cada entrada tem:
| Campo | Detalhe |
|---|---|
| Timestamp | Quando o pedido foi feito |
| User | O e-mail do utilizador autenticado. Vazio para pedidos feitos com chave de API, que são atribuídos à aplicação em vez disso |
| Method | GET, POST, PUT, DELETE |
| Path | O endpoint que foi chamado |
| Status | O código de estado da resposta HTTP |
| IP address | De onde veio o pedido |
| Application | A que aplicação pertencia |
Os registos são mantidos durante 365 dias e depois eliminados automaticamente.
#Para que serve na prática
Quatro situações em que é a ferramenta certa:
- "Quem alterou este fluxo de trabalho?" Um fluxo a comportar-se de forma diferente de ontem costuma ter uma edição por trás, e o registo diz quem a fez.
- Investigar um incidente. Traçar exatamente o que foi acedido, por quem, a partir de que endereço, e por que ordem.
- Depurar uma integração. Ver os pedidos que o teu próprio código realmente fez, em vez dos que julgas que fez - incluindo os que devolveram 4xx.
- Provar o controlo de acesso. Mostrar a um auditor que o acesso aos dados de verificação é atribuído e revisível.
#Filtrar
Filtra por utilizador, endpoint ou intervalo de datas para reduzir uma lista longa. Quando estás a investigar algo específico, começa pela marca temporal e vai alargando a partir daí - um pedido raramente acontece sozinho, e as chamadas imediatamente à sua volta costumam contar a história.
#Os pedidos com chave de API são atribuídos à aplicação, não a uma pessoa
Um pedido feito com chave de API não tem um utilizador a quem ser atribuído, por isso aparece contra a aplicação. É a representação honesta - a plataforma genuinamente não sabe qual dos teus serviços ou engenheiros fez a chamada.
A consequência prática: uma única chave partilhada entre vários serviços torna um incidente materialmente mais difícil de investigar. Se a atribuição te importa, dá a cada consumidor a sua própria aplicação e chave.
#O que está no registo, e o que não está
O registo regista atividade - quem chamou o quê, quando, de onde, e que código de estado voltou. É uma trilha de metadados, não uma cópia dos dados de verificação.
Se precisares de saber se aparecem dados pessoais de clientes nestas entradas - uma pergunta que surge durante as revisões de proteção de dados - obtém a resposta junto do teu contacto Didit e regista-a, em vez de a inferires a partir de uma página de ajuda. É exatamente o tipo de afirmação que a tua própria AIPD (avaliação de impacto sobre a proteção de dados) vai ter de comprovar.
#Quem pode ver isto
O acesso aos registos de auditoria segue a função de cada pessoa. Responsável de Conformidade inclui-o; Leitor não tem acesso alargado. Os proprietários podem concedê-lo a uma função personalizada. Consulta convidar membros da equipa e definir funções.
Remover um colega de equipa não remove o seu histórico do registo - e é exatamente esse o objetivo. Uma trilha que se pode editar não é uma trilha.
#As exportações e os relatórios também são registados
Gerar um PDF de sessão ou uma exportação CSV é uma chamada de API, por isso aparece aqui com quem a fez. Isso é útil quando precisas de mostrar que o acesso à evidência de verificação é controlado e não livre. Consulta descarregar um relatório de verificação.
#Se precisares de mais do que 365 dias
A retenção está fixada em 365 dias. Se a tua obrigação for mais longa, exporta o que precisares periodicamente e guarda-o no teu próprio sistema - o mesmo padrão que usarias para reteres tu próprio a evidência de sessão. Decidir o período exigido é uma decisão de conformidade da tua equipa; não planeies com base numa suposição.
A retenção dos registos de auditoria e a retenção dos dados de verificação são definições separadas. Configurar uma janela de retenção curta para os dados de sessão não encurta o registo de auditoria, e o inverso também é verdade. Consulta como a Didit protege os dados dos teus utilizadores.