Registo e monitorização na NIS 2 ao abrigo do Artigo 21(2)(b)
O registo é a camada de visibilidade do tratamento de incidentes. O artigo 21.o, n.o 2, alínea b), é onde reside o dever, e a Alemanha transpõe-o no §30(2)(2) BSIG. Para os prestadores digitais que abrange, o ponto 3.2 do CIR nomeia os doze tipos de eventos e as regras operacionais.
A versão curta
O registo e a monitorização não são um dever separado na NIS 2. Inserem-se na medida de tratamento de incidentes do Artigo 21(2)(b). A lógica é simples: se não consegue ver o que se passa na sua rede, não consegue detetar um incidente de segurança, nem consegue contê-lo.
O ponto 3.2 do CIR (UE) 2024/2690 acrescenta o detalhe para os prestadores digitais enumerados no artigo 1.o do CIR (DNS, TLD, computação em nuvem, centros de dados, CDN, MSP, MSSP, mercados em linha, motores de pesquisa, redes sociais, serviços de confiança). Quando apropriado, os registos cobrem doze tipos de eventos; a entidade define os limiares de alarme e o seu próprio período de retenção, mantém as fontes de tempo sincronizadas e executa a monitorização de forma redundante. Para as outras entidades este detalhe não é um dever legal; na Alemanha, só os operadores de instalações críticas têm de operar sistemas de deteção de ataques (§ 31 Abs. 2 BSIG).
A Alemanha transpõe a medida no §30(2)(2) BSIG. O IT-Grundschutz oferece o OPS.1.1.5 'Protokollierung' e o DER.1 'Detektion' como blocos de construção; são recomendações, não uma base legal. Esta página percorre a diretiva, o regulamento de execução da UE e a transposição alemã por essa ordem.
Artigo 21(2)(b) da Diretiva NIS 2 (2022/2555)
Tratamento de incidentes.
Este é o ponto (b) na lista de dez medidas de cibersegurança que cada entidade essencial e importante tem de implementar. O CIR §3 operacionaliza-o em seguida. O registo e a monitorização inserem-se no §3.2.
CIR (UE) 2024/2690, Anexo §3.2.1
As entidades pertinentes estabelecem procedimentos e utilizam ferramentas para monitorizar e registar as atividades nos seus sistemas de rede e informação, de modo a detetar eventos suscetíveis de ser considerados incidentes e a responder-lhes em conformidade para atenuar o seu impacto.
Como se trata de um regulamento (e não de uma diretiva), é legislação da UE diretamente vinculativa para os tipos de entidade enumerados no seu artigo 1.o (DNS, TLD, computação em nuvem, centros de dados, CDN, MSP, MSSP, mercados em linha, motores de pesquisa, redes sociais, serviços de confiança). O ponto 3.2 desdobra-se depois em sete subpontos que cobrem os tipos de eventos a registar, os alertas, a retenção, a sincronização horária e a redundância. Não é necessária transposição nacional.
§30(2)(2) BSIG (Alemanha)
Tratamento de incidentes.
A Alemanha copia o texto da UE palavra por palavra. O IT-Grundschutz oferece o OPS.1.1.5 'Protokollierung' e o DER.1 'Detektion von sicherheitsrelevanten Ereignissen' como blocos de construção; são recomendações, não uma base legal.
Registar os doze tipos de eventos
Construa a lista de ativos a registar a partir da sua avaliação de riscos. Quando apropriado, capture: tráfego de rede de entrada e de saída, alterações de utilizadores e de privilégios, acesso a sistemas e aplicações, eventos de autenticação, toda a atividade privilegiada e de administração, acesso a ficheiros críticos de configuração ou de cópias de segurança, registos de ferramentas de segurança (antivírus, IDS, firewall), uso de recursos do sistema, acesso físico, uso de equipamento de rede, ativação ou pausa dos próprios registos, e eventos ambientais.
Revisão, alarme, resposta qualificada
Recolher registos não basta. Verifique-os com uma cadência regular em busca de tendências invulgares ou indesejadas. Quando apropriado, defina limiares. Quando um limiar é ultrapassado, dispare um alarme automático. E garanta que alguém qualificado responde realmente a tempo. Armazenamento sem revisão não é registo nos termos do §3.2.
Proteger, reter, sincronizar a hora, redundância
Os próprios registos são prova. Guarde-os durante um período de retenção definido, proteja-os de acesso e alterações não autorizados, sincronize a hora de todos os sistemas para que os eventos possam ser correlacionados, e opere o sistema de monitorização de forma redundante. A monitorização do sistema de monitorização é, ela própria, independente dos sistemas que monitoriza.
Os registos são um ativo, não um subproduto
O ponto 3.2.5 trata os registos como dados críticos. Período de retenção definido, proteção contra adulteração, proteção contra acesso não autorizado. Se um atacante puder apagar os registos que mostram o que fez, o dever de registo não está cumprido. É também por isso que o ponto 3.2.3, alínea k), indica a 'ativação, paragem e pausa dos vários registos' como algo a registar.
Rever os registos é o objetivo, não um extra
Para os prestadores digitais que o CIR abrange, o ponto 3.2.4 exige verificações regulares de tendências invulgares, limiares quando apropriado, alarmes automáticos em caso de ultrapassagem de limiar, e uma resposta qualificada atempada. Um SIEM que ninguém consulta não cumpre isto. Mantenha um registo de quem reviu quais alertas, quando, e o que fez a respeito deles.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
O IT-Grundschutz oferece o OPS.1.1.5 'Protokollierung' (o que registar, retenção, proteção) e o DER.1 'Detektion von sicherheitsrelevanten Ereignissen' (alertas e resposta) como blocos de construção; são recomendações, não uma base legal.
Orientação Técnica de Implementação da ENISA
A TIG da ENISA dá orientações e exemplos de prova para o ponto 3.2, incluindo exemplos de limiares de alarme, e indica que o período de retenção é definido a partir das necessidades do negócio, da avaliação de riscos e dos requisitos legais. A sua tabela de mapeamento liga o ponto 3.2 aos controlos A.5.28, A.8.15, A.8.16 e A.8.17 da ISO/IEC 27001:2022; a ENISA afirma que o mapeamento não é uma medida de equivalência.
Leis de transposição nacionais
Cada Estado-Membro tem a sua própria transposição (Países Baixos: Cyberbeveiligingswet; Áustria: NISG 2026; Bélgica: a sua lei NIS2). O ponto 3.2 do CIR aplica-se diretamente em todos os Estados-Membros, mas apenas aos prestadores digitais enumerados no artigo 1.o do CIR. O que difere: com que autoridade nacional fala, e como são geridas localmente a comunicação e a supervisão.
Guardamos todos os registos para sempre, por isso estamos cobertos.
Para os prestadores digitais que o CIR abrange, o ponto 3.2.5 exige um período de retenção predefinido, não infinito. Para todos, guardar tudo para sempre é um problema de proteção de dados (artigo 5.o, n.o 1, alínea e), do RGPD, limitação da conservação) e um problema de custos. Decida uma janela de retenção por tipo de registo, escreva-a, justifique-a face ao seu quadro de risco, e cumpra-a.
O SIEM trata disso, por isso estamos bem.
Quase, mas não totalmente. Para os prestadores digitais que o CIR abrange, o ponto 3.2.4 não exige apenas armazenamento. Exige revisão regular, limiares quando apropriado, alarmes automáticos em caso de ultrapassagem, e uma pessoa qualificada que responda de facto. Um SIEM que corre sem regras, ou com regras que ninguém afina, falha o ponto 3.2.4.
Registamos a atividade dos utilizadores, mas não a atividade de administração.
Para os prestadores digitais que o CIR abrange, o ponto 3.2.3, alínea e), é explícito: todo o acesso privilegiado a sistemas e aplicações, mais as atividades das contas de administração. Os administradores são os utilizadores de maior impacto na sua rede, por isso a sua atividade pertence aos registos.
O começo mais barato: construa a lista de ativos a registar a partir da sua avaliação de riscos, encaminhe os registos para um único sítio (um repositório central de registos ou um pequeno SIEM), defina limiares nos eventos que mais importam e reveja-os com regularidade. Não precisa de um SOC gerido logo no primeiro dia. Precisa de alguém que olhe para os alertas e saiba o que fazer.
- Diretiva (UE) 2022/2555 (NIS 2), Artigo 21(2)(b). eur-lex.europa.eu/eli/dir/2022/2555/oj
- Regulamento de Execução (UE) 2024/2690 da Comissão (CIR), Anexo §3.2. eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Lei do BSI (BSIG), §30(2)(2), conforme alterada pela Lei de Implementação da NIS2 e de Reforço da Cibersegurança
- Compêndio IT-Grundschutz, OPS.1.1.5 'Protokollierung' e DER.1 'Detektion'. bsi.bund.de/grundschutz
- Orientação Técnica de Implementação da ENISA para o CIR (UE) 2024/2690 (versão 1.0, junho de 2025)
Tem de tratar da NIS2?
Acompanhamos passo a passo. Preenche, nós explicamos cada ponto em palavras simples e, no fim, a direção assina.
