Registo de Auditoria de Acessos

A plataforma Mirox mantém um trilho de auditoria contínuo e à prova de adulteração de cada acesso remoto aos dispositivos de rede de uma central — cada sessão de túnel VPN (Camada 3/4) e cada pedido de Proxy (Camada 7, HTTP). Esta página descreve exatamente o que é capturado, até que nível de detalhe se chega, quem tem permissão para aceder e durante quanto tempo os dados são conservados.

O trilho de auditoria é o que torna o acesso aos dispositivos da central na plataforma conforme com as regras alemãs KRITIS e a diretiva NIS2 da UE. Essas regulamentações ditam a janela mínima de retenção e as categorias de provas que o operador tem de ser capaz de apresentar — mas o registo de auditoria é, antes de mais, uma ferramenta de rastreio de acessos para o operador da central.

Porque Existe Este Registo de Auditoria

A KRITIS e a NIS2 obrigam os operadores de infraestruturas críticas (no nosso caso, as redes das centrais de parques solares, parques eólicos e instalações de armazenamento em baterias) a serem capazes de responder, de forma completa e mesmo meses depois, às seguintes perguntas para cada acesso remoto:

Quem alcançou a rede interna desta central?
Quando foi estabelecida a ligação — e, para cada ligação: quando foi tocada pela primeira e pela última vez determinada subrede / determinado dispositivo?
Quanto tráfego foi transferido durante a ligação?
Que dispositivo específico e que serviço foi tocado?
O que foi feito ali (ao nível HTTP: que URLs, que métodos)?

O trilho de auditoria da Mirox cobre todas estas perguntas e foi concebido para o operador da central enquanto parte com a obrigação de reporte — não para o utilizador que acede.

Dois Caminhos de Acesso, Uma Auditoria Partilhada

Ambos os mecanismos de acesso da plataforma são fundidos numa visão geral unificada de acessos por central:

Caminho	Camada capturada	Que pergunta responde?
VPN	Camada 3/4 (tráfego IP)	"Quem alcançou que subrede e que dispositivo específico, a partir de onde — quando pela primeira vez, quando pela última, que volume?"
Proxy	Camada 7 (HTTP)	"O que fez o utilizador especificamente no dispositivo — que URLs, que pedidos, quantos pedidos, que duração?"

Ambos os caminhos partilham a mesma base de identidade (a conta Mirox do utilizador) e a mesma lógica legal de retenção e acesso. Da perspetiva do operador da central existe uma lista cronológica de acessos por central, na qual ambos os canais aparecem lado a lado e podem ser filtrados conforme necessário.

Profundidade de Captura

O trilho de auditoria está organizado em várias camadas de detalhe. Quanto mais fundo se aprofunda na hierarquia, mais granular se torna a informação:

Camada 1: Certificado / Identidade

A camada superior captura, por cada certificado VPN, um instantâneo da identidade do utilizador no momento da emissão e da rotação:

Nome de conta anonimizado
Endereço de e-mail
Identificador único do certificado

Mesmo que o utilizador seja posteriormente renomeado, eliminado, ou o certificado seja revogado, esta identidade é preservada.

Camada 2: Sessão

Cada ligação é rastreada como uma sessão. Uma sessão é uma série contígua de atividade a partir do mesmo certificado a partir da mesma origem. Interrupções breves inferiores a dez minutos continuam a contar como a mesma sessão; pausas mais longas criam uma nova sessão.

Por sessão, capturamos:

Quem está ligado (instantâneo da conta e do e-mail no momento da ligação — preservado mesmo que a conta seja eliminada mais tarde)
Hora da ligação
Endereço IP de origem e atribuição geográfica (cidade, país)
Região e nó que terminaram a ligação (para análise de latência)
Volume total de dados (entrada e saída)

Camada 3: Volume por Subrede (Apenas VPN)

Dentro de uma sessão, capturamos, por cada subrede da central tocada:

Que parque e que subrede foi tocada
Volume de dados transferido e contagem de pacotes por sessão e subrede
Hora do primeiro e do último toque
Instantâneos do nome do parque e da organização, caso a central seja posteriormente renomeada ou eliminada

O ruído como consultas DNS, multicast mDNS, pings ICMP e comportamento semelhante a varrimento de portas é filtrado e/ou limitado por taxa, para que o trilho de auditoria contenha apenas eventos de utilização reais.

Camada 4: Toques de Dispositivo (Apenas VPN)

A camada VPN mais fina captura, por cada dispositivo-alvo específico:

IP do dispositivo, protocolo (TCP, UDP, ICMP, ICMPv6, SCTP) e porta
O dispositivo correspondente do inventário da central (nome, tipo) — quando registado
Hora do primeiro toque dentro da sessão
Número de eventos de ligação nesta sessão
Instantâneos de todos os identificadores no momento do primeiro toque

As interações abaixo do limiar (p. ex. resets TCP isolados resultantes de cliques errados) são capturadas de forma conservadora, mas reconhecíveis como tal.

Camada 4': Sessões HTTP (Apenas Proxy)

Em paralelo, o Proxy captura, por cada sessão ao nível HTTP:

Conta e e-mail do utilizador que acede
Que alvo web ou acesso a dispositivo predefinido foi utilizado
Dispositivo-alvo (nome, IP) — com instantâneo para casos posteriores de eliminação ou renomeação
Navegador, sistema operativo, endereço IP público, localização geográfica
Início e fim da sessão (fim da sessão: 10 minutos de inatividade)
Número de pedidos e os seus métodos HTTP (p. ex. {"GET": 42, "POST": 3, "PUT": 1})
Volume de dados de entrada e de saída
Um rasto de atividade da sessão baseado em URLs (as query strings são redigidas, limitadas à atividade mais recente dentro de uma margem fixa)
Uma breve descrição da atividade da sessão gerada por IA, para uma triagem rápida. Se a IA estiver indisponível no fecho da sessão, a descrição é preenchida mais tarde — não é opcional, mas sim uma parte fixa de cada sessão de proxy fechada.

Profundidade Máxima de Detalhe Possível

A profundidade máxima de detalhe é, portanto:

Exemplo de acesso VPN:

"O utilizador X ligou-se via VPN a 2026-05-13 às 13:44 a partir do IP público 198.51.100.7 (região eu-central, Munique, DE), endereçou a subrede 10.90.69.0/24 do parque 'Solar Park Annaburg' durante esta sessão (12 MB transferidos, primeiro toque 13:45, último 13:54), tocando especificamente o dispositivo 'Inverter Block 3' (10.90.69.12, TCP/443) (primeiro toque 13:45, 41 ligações)."

Exemplo de acesso Proxy:

"O utilizador Y acedeu ao alvo web 'Inverter Block 3 – Service UI' através do Proxy a 2026-05-13 entre as 13:46 e as 13:55 a partir do IP público 203.0.113.42 (região eu-central, Frankfurt, DE) em Mobile Safari 26.4 / iOS 18.7 (87 pedidos, dos quais 84 GET, 3 POST; 2,3 MB de volume de resposta, resumo da IA: 'Alteração de configuração nas definições do seguidor MPP')."

Tanto a VPN como o Proxy capturam o IP público de origem, a região terminadora e a atribuição geográfica (cidade, país) da ligação. No caso do Proxy, a informação de navegador e sistema operativo entra adicionalmente no trilho de auditoria (através do User-Agent enviado pelo navegador), uma vez que esta viaja de qualquer forma ao nível HTTP. Para o acesso baseado apenas em VPN (Camada 3/4), esta informação do cliente da aplicação está intrinsecamente indisponível — aí a plataforma vê apenas o fluxo de pacotes IP, não o cliente ao nível da aplicação.

Um nível de detalhe mais profundo (conteúdo dos pacotes, corpos HTTP completos) não é capturado deliberadamente, pois seria simultaneamente problemático para a privacidade e operacionalmente inútil.

Quem Tem Permissão Para Ver a Auditoria?

O acesso ao trilho de auditoria é delimitado pela função de trabalho que um utilizador tem na central:

Um Technical Manager ou superior na central pode ver o trilho de auditoria dessa central. Na prática, isto significa um Operador, Technical Manager ou Asset Manager na central. Os Administradores e Moderadores qualificam-se automaticamente, porque a sua função de organização mapeia para uma função de trabalho qualificada em cada central da sua organização (consulte o Sistema de Permissões para o mapeamento completo de função para trabalho).
Os cooperantes estão incluídos: um técnico que alcança uma central através de uma cooperação com a função de trabalho exigida também pode ver o trilho de auditoria dessa central. O acesso à auditoria segue o mesmo controlo por função de trabalho que o resto dos comandos da central.
Os Visualizadores são recusados. Um Visualizador (e qualquer pessoa abaixo do nível de Technical Manager) não vê qualquer trilho de auditoria. O frontend oculta completamente o separador de registo de acessos para utilizadores abaixo do limiar.

A plataforma expõe a visão de auditoria através de um endpoint de API dedicado ao registo de acessos e de uma vista de UI correspondente. A edição ou eliminação de registos de auditoria não é suportada.

Período de Retenção e Resistência à Adulteração

Pelo menos 730 dias de retenção para todas as camadas de auditoria (certificado, sessão, volume por subrede, toques de dispositivo, sessões HTTP). O período de retenção está alinhado entre camadas, para que as referências cruzadas entre elas se resolvam sempre dentro de toda a janela de auditoria.
Os campos de instantâneo em cada registo de auditoria (p. ex. nome do parque, nome do dispositivo, nome da organização, conta, e-mail) são de escrita única: são carimbados na primeira inserção e nunca atualizados. Isto garante a identidade forense mesmo que o registo original (utilizador, central, dispositivo) seja posteriormente eliminado ou renomeado.
Resolução em tempo real com recurso a alternativa: enquanto as entidades referenciadas (utilizador, parque, organização, dispositivo) ainda existirem, a visão de auditoria mostra o seu nome atual (p. ex. depois de a central ter sido renomeada). Assim que a entidade for eliminada, a visão recorre automaticamente ao instantâneo carimbado. O trilho de auditoria mantém-se assim legível — mesmo meses ou anos depois, após mudanças de pessoal ou venda da central.
Sem caminhos de eliminação ou edição expostos ao utilizador: as tabelas de auditoria não podem ser modificadas através de operações normais de UI ou API. Apenas são tocadas por eventos de auditoria automatizados e pela varredura noturna de retenção depois de expirarem os 730 dias.

Comportamento Perante Eliminações

Evento	Efeito no trilho de auditoria
O utilizador é eliminado	Os registos de auditoria são preservados. A visão mostra o instantâneo da conta e do e-mail do certificado ou da sessão.
O certificado é revogado	Os registos de auditoria são preservados. O certificado é revogado de forma suave e permanece disponível como fonte de resolução durante 730 dias.
A central é eliminada	Os registos de auditoria são preservados. A visão mostra o instantâneo do nome do parque do registo de auditoria.
O dispositivo é eliminado / renomeado / muda de IP	Os registos de auditoria são preservados. A visão mostra o instantâneo do nome do dispositivo; o IP no registo é o identificador forense durável.
A organização é eliminada	Os registos de auditoria são preservados. A visão mostra o instantâneo do nome da organização.

Proteção Contra a Adulteração dos Dados de Auditoria

As sessões que não podem ser atribuídas (p. ex. porque um cabeçalho foi removido) continuam a ser capturadas com identidade vazia, em vez de serem descartadas. Uma análise posterior pode então investigar especificamente estes casos.
As sessões HTTP não são fechadas apenas por componentes do SaaS, mas sim fechadas e reportadas pelo próprio agente da central, de modo que a plataforma SaaS não possa subreportar silenciosamente a contagem de pedidos ou o volume.
As condições de corrida ao nível do submilissegundo na leitura de cadeias de contadores são aceites como "com perdas por design" e documentadas como conformes com KRITIS; podem, no pior caso, afetar um único ciclo de contador, nunca sessões inteiras ou toques de dispositivo.

Filtragem e Pesquisa na Visão de Auditoria

A visão de auditoria permite a um utilizador autorizado restringir o conjunto de resultados:

Por conta de utilizador
Por subrede ou IP de dispositivo
Por protocolo ou porta (caminho VPN)
Por alvo web ou dispositivo específico (caminho proxy)
Por intervalo de tempo (de … até …)
Ordenação predefinida por "visto pela última vez"

A ordenação predefinida agrupa naturalmente por sessão, pelo que a pergunta "O utilizador X tocou os dispositivos A e B nesta sessão 18:43–19:00 e o dispositivo C numa segunda sessão 13:44–14:30" é diretamente visível sem agrupamento adicional do lado do cliente.

Privacidade e Divulgação

O que o trilho de auditoria contém:

Campos de identidade derivados da conta Mirox normal (conta, e-mail)
Endereços IP de origem da ligação (exigidos legalmente pela KRITIS)
Atribuição geográfica da origem (cidade, país)
Volume de dados, contagem de pedidos, distribuição de métodos, marcações temporais

O que o trilho de auditoria não contém:

Conteúdo de corpos HTTP individuais
Conteúdo de pacotes VPN
Teclas premidas ou gravações de ecrã
Dados não necessários para o reporte KRITIS / NIS2

O Que Fazer Perante um Pedido Regulatório

Para pedidos de informação motivados por incidentes dirigidos à autoridade responsável (p. ex. o BSI ao abrigo da KRITIS), todos os dados necessários estão disponíveis dentro da janela de 730 dias através da visão de auditoria. Está planeada uma função de exportação (p. ex. CSV) como uma ação separada e individualmente auditada, fornecida mediante pedido — tal exportação é, ela própria, uma operação digna de auditoria, de modo que fique documentado quem exportou que dados de auditoria e quando ("auditoria da auditoria").

Funcionalidades Relacionadas

VPN — túnel pessoal com captura de auditoria completa na Camada 3/4
Proxy — acesso baseado no navegador com captura de auditoria completa na Camada 7
Sistema de Permissões — o mapeamento de função para trabalho que decide quem pode abrir a visão de auditoria
Cooperações — como um técnico cooperante recebe (e é auditado por) acesso à central
Restrições de Cooperação — os limites que mantêm o acesso partilhado dentro do âmbito escolhido pelo proprietário