Todos os pedidos de API da tua organização ficam registados durante 365 dias - quem, o quê, quando, de onde e sob que aplicação. É o primeiro sítio a consultar.
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 Definições → Registo de auditoria. Cada decisão que o Investigador toma por si próprio também fica registada aí, identificada como O investigador.
#O que é registado
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 | Quem o fez: o membro que fez o pedido; num pedido feito com chave de API, o nome da chave com uma etiqueta Chave de API; Didit para o que a Didit faz por si própria; e O investigador para uma decisão que toma por si próprio |
| 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.
Um registo de auditoria redesenhado, que descreve cada alteração por palavras e pode exportar o que estás a ver, está a ser disponibilizado gradualmente. Até chegar à tua organização, a página mostra o registo de pedidos descrito aqui.
#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 (um membro, uma chave de API, Didit ou O investigador), 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 à chave, não a uma pessoa
Um pedido feito com chave de API não tem uma pessoa a quem ser atribuído, por isso mostra antes o nome da chave. É 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 serviço a sua própria chave. Consulta gerir as tuas chaves de API.
#As decisões próprias do Investigador são atribuídas ao Investigador
Quando o Investigador decide por si próprio, dentro da autonomia que lhe deste, a entrada indica O investigador, e não uma pessoa ou uma chave. Isto abrange cada decisão que toma: aprovar ou recusar uma sessão ou pedir ao utilizador que a volte a enviar, definir o estado de uma transação, e resolver um caso, escalá-lo ou pedir informações sobre ele. Cada uma destas entradas tem uma ligação para o relatório do Investigador por trás da decisão, para que vejas o que encontrou e que regra da tua 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 faça. O registo completo do Investigador, com os seus relatórios, perguntas e regras de segurança, continua no seu próprio registo de Atividade. Consulta Controlar e supervisionar o Investigador.
#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.
Continua com dúvidas? Fale com uma pessoa.
Inclua o ID da sua organização e o ID da sessão sobre a qual pergunta.