Como projetar logs de controle de acesso: histórico, registros, eventos, auditoria, retenção, LGPD, sincronização de tempo e testes.
Confira!
Um log de acesso é o registro estruturado de eventos produzidos pelo sistema de controle de acesso para permitir rastreabilidade operacional e investigação posterior. Em um sistema físico, esse histórico não deve registrar apenas “entrou” ou “saiu”: precisa relacionar identidade ou credencial, ponto de acesso, data e hora, decisão de autorização, motivo da negação quando disponível, estado da porta, alarmes, comandos administrativos e alterações de configuração relevantes. O histórico de acesso e o registro de acesso tornam-se, portanto, parte da evidência técnica do sistema.
Esse registro também envolve governança de dados. Eventos de acesso podem conter dados pessoais e revelar presença, horários e circulação de pessoas. A retenção não deve ser escolhida por um número arbitrário ou por uma capacidade máxima do software. A LGPD não estabelece um prazo único para tratamento de dados pessoais; finalidade, necessidade, obrigações legais ou regulatórias e demais bases aplicáveis precisam orientar a política de conservação e eliminação. Em engenharia, isso significa que capacidade de armazenamento, integridade, sincronização de tempo, exportação, perfis de consulta e retenção precisam ser requisitos explícitos do projeto.
Log de acesso, histórico de acesso e auditoria não são exatamente a mesma coisa
Os termos aparecem juntos, mas cumprem funções distintas. O log é o registro técnico de um evento. O histórico de acesso é a sequência consultável desses eventos ao longo do tempo. A auditoria usa registros para reconstruir ações, verificar conformidade, investigar incidentes ou demonstrar que uma política foi aplicada.
| Camada | Função | Exemplo |
| Evento | fato produzido pelo sistema | acesso concedido, acesso negado, porta forçada |
| Log | registro persistido do evento | data/hora, ponto, credencial, resultado |
| Histórico | conjunto ordenado de registros | eventos de uma pessoa, porta ou período |
| Auditoria | análise e evidência | quem alterou uma regra e qual efeito ocorreu |
| Retenção | política de conservação | período, finalidade, descarte e exceções |
Um relatório é apenas uma forma de visualização ou exportação. Se o sistema não registra dados suficientes, nenhum relatório posterior consegue reconstruir o que não foi gravado.
O sistema deve registrar mais do que acessos concedidos
Uma base útil precisa representar diferentes classes de evento. A IEC 60839-11-1 inclui requisitos relacionados a logging, identificação e controle de informações em sistemas eletrônicos de controle de acesso. Na prática de projeto, isso exige pensar em eventos de credencial, porta, controlador, integração e administração.
Entre os registros relevantes estão:
- acesso concedido e negado;
- credencial desconhecida, expirada, suspensa ou fora do perfil;
- tentativa fora de horário ou zona autorizada;
- porta forçada e porta mantida aberta;
- acionamentos e alterações de estado de entrada/saída;
- perda e retorno de comunicação com controladoras;
- falha de alimentação, bateria ou dispositivo supervisionado;
- ativação de modos excepcionais quando aplicáveis;
- criação, alteração e revogação de credenciais;
- mudanças de perfil, horários e permissões;
- ações administrativas e comandos manuais;
- eventos recebidos ou enviados por integrações.
O conjunto efetivo depende da arquitetura, do risco e das funções contratadas. O erro é deixar a política de registro ser definida apenas pelos padrões de fábrica do software.
Cada evento precisa de contexto suficiente para ser interpretado
O histórico deve nascer da matriz funcional: eventos, campos, tempo, capacidade e retenção precisam ser definidos como requisitos, não deixados no padrão do software.
Um log tecnicamente útil combina o evento com contexto. Registrar apenas “Access denied” sem indicar porta, horário, origem e credencial reduz drasticamente o valor investigativo.
Uma estrutura de registro pode incluir:
| Campo | Por que é importante |
| timestamp | posiciona o evento na sequência temporal |
| origem | identifica controladora, leitor, integração ou operador |
| ponto de acesso | relaciona o evento à barreira física |
| identidade/credencial | associa o evento ao sujeito quando aplicável |
| tipo de evento | distingue acesso, porta, sistema e administração |
| resultado | concedido, negado, falha, reconhecido etc. |
| motivo/código | explica a decisão quando o sistema fornece esse dado |
| operador | registra ação humana administrativa |
| correlação | permite ligar eventos relacionados |
| estado anterior/novo | útil para mudanças de configuração ou status |
Não é necessário expor todos esses campos a todo usuário. O projeto deve separar o que é registrado de quem pode consultar cada informação.
Sincronização de tempo é requisito de evidência
Um histórico de acesso só é confiável se os componentes compartilham uma referência de tempo coerente. Controladoras, servidores, VMS, sistemas de visitantes e demais integrações podem registrar o mesmo incidente em plataformas diferentes. Se os relógios divergem, a reconstrução da sequência fica comprometida.
O projeto deve definir fonte de tempo, sincronização, timezone, horário de verão quando aplicável e comportamento diante da perda temporária da referência. Também deve verificar como o sistema trata eventos gerados offline e sincronizados posteriormente.
Em controladoras distribuídas, o timestamp pode ser criado no dispositivo de campo e enviado depois ao servidor. Se a plataforma substitui a hora de geração pela hora de recebimento, a interpretação pode mudar. Essa característica precisa ser conhecida no FAT e SAT.
Eventos offline precisam preservar a sequência real
Sistemas de acesso frequentemente continuam funcionando de forma distribuída quando a comunicação com o servidor é interrompida. Nessa condição, a controladora pode manter decisões locais e armazenar eventos para sincronização posterior.
O requisito de projeto deve definir capacidade local, comportamento quando o buffer se aproxima do limite, ordem de sincronização e tratamento de duplicidade. Uma controladora que continua autorizando acessos, mas perde eventos durante uma indisponibilidade prolongada, atende parcialmente à operação e falha na rastreabilidade.
Também é importante diferenciar horário do evento, horário de recepção e horário de processamento quando a plataforma expõe essas informações. Esse detalhe ajuda a entender atrasos de comunicação sem distorcer o histórico físico.
Acesso negado deve registrar o motivo quando possível
Do ponto de vista operacional, “negado” não é uma causa única. Uma credencial pode ser válida, mas estar fora de horário; pode não ter permissão para aquela zona; pode estar expirada; pode violar uma regra de anti-passback; ou pode ter sido revogada.
Quando o sistema disponibiliza códigos de motivo, registrá-los melhora suporte, investigação e análise de política. Isso permite separar tentativa indevida de simples problema de cadastro ou de uma regra temporária mal configurada.
O projeto não deve exigir texto idêntico entre fabricantes, mas precisa exigir capacidade de diferenciar condições relevantes e expor essas informações de forma consultável.
Eventos de porta completam o histórico da decisão
A autorização é apenas uma etapa. Depois de um acesso concedido, a porta pode não abrir, pode permanecer aberta, pode ser forçada posteriormente ou pode gerar um estado incoerente.
Por isso, o histórico precisa correlacionar eventos lógicos de autorização com eventos físicos da barreira. Em investigação, a sequência “acesso concedido → porta aberta → porta fechada” é diferente de “acesso concedido → nenhuma abertura” ou “porta aberta sem liberação válida”.
Essa correlação é particularmente importante quando o sistema também aciona CFTV/VMS, porque a busca de vídeo pode partir do timestamp e do ponto de acesso registrados.
Logs administrativos são tão importantes quanto logs de passagem
Uma mudança de configuração pode ser a causa de um incidente. Alteração de horário, inclusão de permissão, criação de credencial, desbloqueio manual ou mudança de parâmetro precisa ser rastreável em sistemas compatíveis com o nível de governança requerido.
O log administrativo deveria permitir identificar quem realizou a ação, quando, em qual objeto e, quando suportado, qual era a condição anterior e qual passou a ser a nova condição. Esse requisito é diferente do histórico de passagem de pessoas e pode exigir permissões de consulta mais restritas.
A segregação de funções também importa: o mesmo usuário que altera uma política não deveria necessariamente ter capacidade irrestrita de apagar ou alterar a evidência dessa ação.
Integridade do registro precisa ser tratada como requisito
Um arquivo exportado pode ser copiado e alterado; uma captura de tela não é uma trilha de auditoria. O projeto deve analisar como o sistema protege a base de eventos, quem pode excluir registros, quais operações são auditadas e como backups e exportações preservam rastreabilidade.
Nem toda plataforma oferece mecanismos criptográficos de imutabilidade, e não é correto pressupor que ofereça. O requisito deve ser proporcional ao risco: controle de acesso corporativo comum, infraestrutura crítica, ambiente regulado e investigação forense podem exigir níveis diferentes de proteção.
Quando houver integração com SIEM, data lake ou outra plataforma de observabilidade, a exportação pode criar uma segunda camada de retenção e correlação. Isso precisa ser governado para não gerar cópias indefinidas de dados pessoais sem finalidade definida.
Retenção de logs não possui um prazo universal na LGPD
A LGPD estabelece hipóteses para término do tratamento e condições específicas que autorizam conservação após esse término. A própria ANPD esclarece que a Lei não especifica um prazo único durante o qual dados pessoais podem ser tratados; a duração depende da circunstância e da finalidade.
Portanto, dizer que “logs de controle de acesso devem ser guardados por X meses” sem conhecer finalidade, contexto jurídico e requisitos da organização é uma simplificação inadequada. A política de retenção deve considerar, entre outros fatores:
- finalidade do registro;
- necessidade operacional e de segurança;
- obrigações legais ou regulatórias aplicáveis à organização;
- prazos de investigação e resposta a incidentes;
- requisitos contratuais legítimos;
- direitos dos titulares e minimização;
- capacidade técnica de eliminação e anonimização;
- cópias em backup, exportações e sistemas integrados.
A engenharia não substitui a definição jurídica da base e do prazo, mas precisa transformar essa política em requisitos técnicos de armazenamento, expurgo, backup e acesso.
Capacidade de armazenamento deve derivar da política de retenção
O banco de eventos precisa comportar o volume esperado pelo período definido. A estimativa pode considerar número de pontos, usuários, eventos diários por porta, eventos administrativos, alarmes, integrações e margem para picos.
Um edifício com 20 portas e uso moderado produz uma ordem de grandeza muito diferente de um campus com centenas de pontos e integração com visitantes, elevadores e CFTV. Além disso, registrar mudanças administrativas e telemetria aumenta o volume além das simples passagens.
O projeto deve evitar dimensionar pela frase “o sistema guarda milhões de eventos”. A pergunta correta é: quantos eventos o sistema produzirá no cenário esperado e por quanto tempo cada classe precisa permanecer disponível?
Pesquisa e relatórios precisam responder perguntas operacionais reais
A interface de histórico deve permitir filtros coerentes com a operação: período, pessoa ou credencial, porta, zona, tipo de evento, resultado e operador, conforme as capacidades previstas.
Exportação em formato estruturado pode ser necessária para auditoria, investigação ou integração. O projeto deve avaliar paginação, limites de consulta, timezone, codificação, campos exportados e permissões. Em sistemas de grande porte, consultas extensas não podem degradar a operação de controle de acesso.
Relatórios agendados podem ser úteis, mas não substituem a capacidade de pesquisa ad hoc. O requisito deve nascer das perguntas que a organização precisa responder, e não apenas da lista de relatórios padrão de um fabricante.
Integração por API precisa preservar significado e contexto
Integrações com VMS, SIEM e aplicações corporativas ampliam a rastreabilidade, mas também ampliam a superfície de dados e precisam de governança.
Quando eventos são enviados a VMS, PSIM, SIEM, BMS ou aplicações corporativas, o mapeamento precisa preservar identificadores, timestamps, tipo de evento, ponto e resultado. Uma integração que converte todos os eventos em uma mensagem genérica perde valor operacional.
Também é necessário definir comportamento em indisponibilidade do destino: fila, retry, descarte, duplicidade e confirmação. Webhooks sem controle de entrega podem criar lacunas silenciosas no histórico externo.
A integração deve ainda respeitar a política de dados. Replicar logs para vários sistemas amplia superfície de acesso e torna retenção e eliminação mais complexas.
Controle de acesso ao próprio histórico precisa ser projetado
Quem administra credenciais não necessariamente precisa consultar toda movimentação histórica. Quem investiga incidentes pode precisar de histórico, mas não de alterar políticas. Um operador de portaria pode precisar visualizar eventos recentes sem exportar bases completas.
Perfis administrativos devem refletir essas diferenças. Princípio de menor privilégio, autenticação adequada e registro das próprias ações administrativas ajudam a proteger a evidência e reduzir exposição indevida de dados pessoais.
Backup e recuperação precisam incluir a base de eventos
Se o histórico é requisito contratual, a estratégia de backup precisa incluir banco de eventos, configuração necessária para interpretá-los e procedimento de restauração. Um backup que recupera usuários e portas, mas perde meses de histórico, não restaura todo o sistema.
O projeto deve definir RPO/RTO quando aplicável, frequência de backup, retenção das cópias, criptografia, testes de restauração e tratamento de dados antigos. A política de backup deve ser coerente com a de retenção: cópias não podem perpetuar indefinidamente informações que deveriam ser eliminadas sem que isso seja tratado pelo processo de governança.
Como especificar logs e auditoria sem amarrar fabricante
Uma especificação por desempenho pode exigir:
- registro de eventos de acesso, porta, sistema e administração definidos na matriz funcional;
- timestamp consistente e sincronização de tempo;
- identificação de ponto, origem e resultado;
- motivo de negação quando tecnicamente disponível;
- histórico consultável por filtros relevantes;
- trilha de ações administrativas;
- capacidade local durante perda de comunicação quando necessária;
- exportação estruturada e/ou integração por API;
- controle de acesso aos registros;
- capacidade para a política de retenção definida;
- backup e restauração do histórico;
- evidências de integridade e rastreabilidade compatíveis com o risco;
- mecanismos de expurgo ou gestão do ciclo de vida dos registros.
A especificação deve definir o resultado que precisa ser comprovado. Nomes de menus, formatos proprietários e limites copiados de um produto de referência não deveriam substituir o requisito funcional.
FAT e SAT devem comprovar a rastreabilidade de ponta a ponta
O FAT pode validar geração de eventos, campos, filtros, permissões, exportação e logs administrativos em ambiente controlado. O SAT deve executar eventos físicos reais e confirmar que o histórico representa corretamente o que ocorreu em campo.
Um roteiro consistente inclui acesso concedido, negação por diferentes causas, abertura e fechamento, porta forçada, porta mantida aberta, perda de comunicação, alteração administrativa, sincronização posterior e integração com VMS quando prevista.
A evidência deve comparar evento provocado, registro esperado e registro observado. Isso transforma “o sistema possui log” em um requisito verificável.
Quando logs, auditoria e retenção precisam entrar no Projeto de Controle de Acesso
Sempre. A profundidade varia com o risco, mas qualquer sistema que controla acesso físico precisa registrar informação suficiente para operação e investigação. Em instalações críticas, multinacionais, data centers, indústria ou ambientes regulados, a governança tende a exigir requisitos muito mais detalhados.
O Projeto de Controle de Acesso deve definir eventos, campos essenciais, sincronização, capacidade, retenção, perfis de consulta, integrações e critérios de teste. A política jurídica de retenção é uma entrada para a engenharia; o projeto traduz essa decisão em arquitetura e capacidade técnica.
Considerações finais
Log de acesso, histórico de acesso e registro de acesso são elementos centrais da rastreabilidade de um sistema físico. O valor do registro depende de contexto, tempo confiável, integridade, capacidade de pesquisa, governança e correlação com o estado real da porta.
Retenção também não deve ser confundida com “guardar o máximo possível”. A política precisa ter finalidade e base apropriadas, e o sistema precisa ser tecnicamente capaz de cumprir conservação, acesso, backup e descarte. Quando esses pontos são projetados e testados, o histórico deixa de ser apenas uma tela de eventos e passa a ser evidência operacional confiável.
FAT e SAT devem provar que o evento físico gera o registro correto, com contexto, timestamp e persistência suficientes para auditoria.
Referências técnicas
[1] IEC. IEC 60839-11-1:2013 — Alarm and electronic security systems — Part 11-1: Electronic access control systems — System and components requirements. Disponível em: https://webstore.iec.ch/en/publication/3662
[2] BRASIL. Lei nº 13.709, de 14 de agosto de 2018 — Lei Geral de Proteção de Dados Pessoais (LGPD), arts. 15 e 16. Disponível em: https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709compilado.htm
[3] AGÊNCIA NACIONAL DE PROTEÇÃO DE DADOS. Perguntas Frequentes — prazo de tratamento e eliminação de dados pessoais. Disponível em: https://www.gov.br/anpd/pt-br/acesso-a-informacao/perguntas-frequentes/perguntas-frequentes
[4] AXIS COMMUNICATIONS. Event logger service — Physical Access Control API. Disponível em: https://developer.axis.com/vapix/physical-access-control/event-logger-service/
[5] ONVIF. Profile C — door control and event management. Disponível em: https://www.onvif.org/profiles/onvif-profile-c/
Perguntas frequentes
É um registro estruturado de eventos do sistema de controle de acesso, como acessos concedidos ou negados, eventos de porta, alarmes, falhas e ações administrativas, com contexto suficiente para rastreabilidade.
O log é o registro individual de um evento. O histórico é o conjunto ordenado e consultável desses registros ao longo do tempo. Auditoria utiliza esse histórico para reconstruir ações e verificar políticas.
Não existe um prazo universal na LGPD. A retenção depende da finalidade, necessidade, obrigações legais ou regulatórias, contexto de segurança e demais bases aplicáveis. A política deve ser definida pela organização e traduzida em requisito técnico.
Sim, quando essa função estiver no escopo. É útil registrar a negação e, quando tecnicamente disponível, o motivo, como horário, permissão, credencial expirada ou regra de anti-passback.
Sim. FAT e SAT devem provocar eventos previstos e confirmar timestamp, ponto, resultado, motivo quando aplicável, persistência, consulta, integração e rastreabilidade.
Materiais técnicos complementares
Serviços relacionados
Conteúdos principais sobre o tema
Conteúdos técnicos correlatos
- Ciclo de vida de credenciais no controle de acesso
- Controle de entrada e saída de pessoas: horários, turnos e perfis de acesso
- Alarme de porta no controle de acesso
- API, webhooks e middleware em controle de acesso
- CFTV e controle de acesso: integração, VMS e critérios de projeto
- Comissionamento de sistemas de controle de acesso conforme IEC 60839
