Requisitos NIS2 para segurança de identidade

Requisitos NIS2 para segurança de identidade: comece pelo que o texto realmente diz

Se você está tentando entender os requisitos NIS2 para segurança de identidade, o primeiro erro a evitar é tratar a NIS2 como se fosse um guia de configuração da Microsoft. Não é. A Diretiva (UE) 2022/2555 define obrigações de gestão de risco e expectativas de governança no nível da União. Ela não diz para as equipes implantarem Microsoft Entra Privileged Identity Management, aplicarem um template específico de Conditional Access ou definirem um comprimento exato de senha no Active Directory.

Essa distinção importa porque equipes de identidade ainda precisam provar algo concreto. Mesmo que a NIS2 não nomeie produtos Microsoft, equipes de AD e Entra ainda precisam demonstrar que o acesso privilegiado está controlado, que a autenticação é forte o suficiente para o risco, que o controle de acesso é efetivamente aplicado em produção e que o monitoramento permite comprovar violações de política ou deriva de privilégios.

Este artigo separa deliberadamente quatro camadas:

Camada	O que ela entrega	O que ela não entrega
Texto da Diretiva NIS2	A base legal no nível da UE	Configurações específicas de produtos Microsoft
Considerandos e contexto oficial	Interpretação e intenção regulatória	Um substituto para os artigos operativos
Regulamento de Execução (UE) 2024/2690	Requisitos mais técnicos para certos tipos de entidades cobertas	Um manual universal para todas as entidades NIS2
Controles de AD / Entra	Implementações técnicas razoáveis e padrões de evidência	Prova de que um controle Microsoft específico é juridicamente obrigatório

Esse enquadramento é o que separa uma revisão defensável de um artigo de compliance que extrapola o texto.

O que a NIS2 realmente exige para a segurança de identidade?

No nível mais alto, o artigo 21(1) da NIS2 exige que os Estados-Membros assegurem que entidades essenciais e importantes adotem medidas técnicas, operacionais e organizacionais apropriadas e proporcionais para gerir riscos à segurança de redes e sistemas de informação. Trata-se de uma obrigação baseada em risco, não de uma checklist de produto.

A identidade aparece de forma mais direta no artigo 21(2). Para este tema, dois pontos importam mais:

O artigo 21(2)(i) inclui políticas e procedimentos para avaliar a eficácia das medidas de gestão de risco cibernético.
O artigo 21(2)(j) inclui o uso de autenticação multifator ou soluções de autenticação contínua, comunicações seguras e sistemas seguros de comunicação de emergência dentro da entidade, quando apropriado.

A NIS2 também traz contexto importante no considerando 89, que lista práticas básicas de cyber hygiene como princípios zero trust, atualizações de software, segmentação de rede, identity and access management e conscientização de usuários. Esse considerando não é uma baseline escondida da Microsoft. É um sinal forte de que governança de identidade, autenticação e disciplina de acesso fazem parte do trabalho básico de segurança que reguladores esperam ver.

A leitura prudente para equipes de identidade é esta: a NIS2 não prescreve um único padrão de fornecedor, mas espera claramente controles de identidade defensáveis, baseados em risco, revisados e capazes de reduzir o impacto de incidentes.

Onde identity and access management se encaixa na NIS2

Para equipes de AD e Entra, a pergunta prática não é “qual recurso Microsoft a NIS2 exige?”. A pergunta prática é “quais objetivos de segurança de identidade teríamos dificuldade de comprovar em uma revisão?”.

Uma leitura técnica útil se parece mais com isto:

Objetivo NIS2	O que equipes de segurança devem conseguir comprovar	Exemplo de evidência AD / Entra
O acesso é controlado	Acesso privilegiado e sensível é limitado e revisado	Exportações de grupos privilegiados, exportações de atribuições de papéis Entra, registros de access reviews
A autenticação é adequada ao risco	Acessos sensíveis não dependem apenas de senha	Estado de políticas de Conditional Access, estado de Security Defaults, evidência de MFA para contas admin
O privilégio é proporcional	Privilégios permanentes são minimizados e exceções têm governança	Evidência de atribuições permanentes versus elegíveis, revisão de admins obsoletos, governança de contas break-glass
O monitoramento funciona	Mudanças de identidade e de papéis podem ser revistas depois	Entra audit logs, política de auditoria AD, visibilidade de mudanças em grupos e objetos
Acesso de terceiros e de apps é governado	Convidados, acesso externo e permissões de apps não derivam silenciosamente	Restrições de convidado, configurações cross-tenant, configurações de consentimento, revisão de permissões de service principals

É por isso que Conformidade AD e Azure: NIS2, ISO 27001, CIS continua útil. Esse artigo faz um mapeamento mais amplo entre vários frameworks. O artigo que você está lendo agora reduz a discussão a um problema mais difícil: o que uma equipe de identidade realmente consegue provar em uma revisão orientada por NIS2.

Por que o escopo importa: NIS2, regras setoriais e transposição nacional

Escopo é onde muitos artigos de compliance erram.

Primeiro, a NIS2 é uma diretiva, não um padrão de produto diretamente autoexecutável. Os Estados-Membros a transpõem para o direito nacional, e as expectativas de supervisão são moldadas em parte por essa implementação nacional. Uma equipe que opera na França, Alemanha, Itália ou outro Estado-Membro verá a mesma base da UE, mas não necessariamente o mesmo empacotamento regulatório, os mesmos documentos de referência ou o mesmo fluxo de implementação.

Segundo, nem todo detalhe técnico que as pessoas associam à NIS2 vem do texto da diretiva em si. O Regulamento de Execução (UE) 2024/2690 define requisitos técnicos e metodológicos para determinadas categorias de entidades cobertas pelo artigo 21(5), como provedores de serviços DNS, provedores de cloud computing, provedores de data center, managed service providers, managed security service providers e trust service providers. Esse regulamento é altamente relevante, mas não é um atalho genérico que possa ser aplicado sem ajustes a qualquer organização sujeita à NIS2.

Terceiro, algumas entidades também estão sujeitas a normas setoriais ou nacionais mais específicas. Por isso, uma revisão séria de identidade em uma leitura NIS2 precisa responder três perguntas antes mesmo de começar:

A entidade está dentro do escopo da NIS2 e em qual categoria?
Ela também está coberta por textos europeus ou nacionais mais específicos?
Quais expectativas técnicas vêm da própria diretiva, quais vêm de atos de execução e quais vêm de guias nacionais?

Sem essa disciplina, equipes acabam afirmando coisas como “NIS2 exige PIM” ou “NIS2 exige senhas de 12 caracteres”. Essas afirmações não são tecnicamente defensáveis a partir do texto europeu isoladamente.

Controles de AD e Entra que costumam sustentar objetivos de identidade da NIS2

A NIS2 não nomeia Active Directory nem Microsoft Entra. Mas, se seu ambiente depende deles, são pontos óbvios onde evidência será procurada.

Acesso privilegiado

Uma revisão madura de identidade precisa conseguir mostrar quais usuários e grupos têm acesso administrativo efetivo on-premises e no Entra, como esse acesso foi concedido e se ele ainda está justificado.

Isso normalmente significa revisar:

associações diretas e aninhadas em grupos AD privilegiados
principals com direitos equivalentes a DCSync
direitos delegados sobre objetos AD sensíveis, especialmente quando GenericAll, WriteDACL ou WriteOwner criam caminhos de escalada
atribuições permanentes versus elegíveis de papéis Entra
contas que mantêm privilégios apesar de inatividade ou deriva de ownership

É exatamente por isso que Desvio acesso privilegiado Active Directory: como direitos admin voltam após auditorias e Gerenciamento de Acesso Privilegiado no Azure: Riscos sem PIM são leituras internas relevantes. Elas não provam conformidade com a NIS2 por si só. Elas mostram condições de identidade que uma equipe teria dificuldade de defender sob escrutínio.

Força da autenticação

A NIS2 dá lugar claro ao MFA ou à autenticação contínua, mas a expressão “quando apropriado” continua importante. Por isso, um programa de identidade defensável deve conseguir explicar:

quais contas privilegiadas estão sempre protegidas por MFA
quais fluxos administrativos e quais aplicações de alto risco estão sujeitos a controles de acesso reforçados
se caminhos de autenticação legacy ainda permanecem abertos
se o tenant ainda depende de um padrão de senha mais exceções

A documentação da Microsoft ajuda aqui porque explica o que Conditional Access realmente é: um motor de políticas que combina sinais e aplica decisões de acesso. Isso faz dele evidência de um caminho de controle, não prova de que a NIS2 teria imposto especificamente Conditional Access como produto.

Da mesma forma, Seguranca de Identidade Azure: Quando o MFA Nao Basta ajuda a enquadrar corretamente o limite técnico: MFA é importante, mas má governança de papéis, acesso de convidados muito aberto ou consentimento malicioso de apps ainda podem deixar exposição relevante de identidade.

Controle de acesso, convidados e permissões de aplicações

O escopo de identidade na NIS2 é mais amplo do que login de empregados. Controle de acesso também envolve usuários externos, acesso de aplicações e autoridade delegada.

Uma equipe técnica deve conseguir demonstrar:

como o acesso de convidados é restringido
quem está autorizado a convidar usuários externos
se a colaboração cross-tenant é rigidamente governada ou permanece aberta demais
como permissões de apps e consentimento são controlados
se enterprise apps com excesso de privilégios são revisados periodicamente

Esses não são temas abstratos. A Microsoft documenta que application permissions podem conceder acesso app-only e que consentimento de usuário ou admin governa como aplicações obtêm acesso a recursos protegidos. A Microsoft também documenta como restringir as configurações de user consent para reduzir consentimentos maliciosos ou excessivos. É por isso que Registros de Aplicativo Azure: Apps com Privilegios Excessivos e OAuth Consent Phishing: como apps maliciosos contornam o roubo de senhas fazem parte de uma leitura séria do tema, embora a NIS2 nunca use esses nomes de produto.

Quais evidências equipes de segurança devem conseguir apresentar

Um programa fraco de identity compliance normalmente tem uma boa política, mas nenhum pacote de evidências robusto. Em uma revisão orientada por NIS2, equipes de AD e Entra precisam conseguir apresentar evidências atuais, revisáveis e vinculadas diretamente aos controles que dizem aplicar.

Um pacote prático de evidências normalmente inclui:

Tema de controle	Exemplo de evidência
Acesso privilegiado	Exportações atuais de grupos AD privilegiados, exportações de atribuições de papéis Entra, evidência de privilégios permanentes versus elegíveis
Disciplina de revisão de acesso	Registros de revisão de papéis, saídas de revisão de memberships, evidências de revisão de convidados
MFA e proteção de acesso	Estado de Conditional Access, estado de Security Defaults quando aplicável, cobertura de MFA para papéis sensíveis
Convidados e acesso externo	Configurações de restrição de convidados, política de convite, configurações de colaboração cross-tenant
Governança de aplicações	Inventário de permissões de apps, configurações de consentimento, evidências de revisão de service principals de alto risco
Monitoramento	Entra audit logs, saídas de política de auditoria AD, prova de que mudanças relevantes de identidade são registradas e retidas
Exceções	Registro documentado de exceções com responsável, justificativa e data de revisão

É aqui que Como auditar a segurança do Microsoft Entra ID (Azure AD): guia prático, Auditar a segurança do Active Directory: checklist prática e Monitoramento de Seguranca AD: Os Eventos que Importam ajudam a transformar a linguagem do framework em etapas operacionais de revisão.

Lacunas comuns entre política escrita e controles de identidade realmente aplicados

As falhas de identidade mais sérias em uma leitura NIS2 geralmente não vêm da ausência de política escrita. Elas vêm da diferença entre o que a política diz e o que o tenant ou o diretório realmente aplicam.

Exemplos comuns:

existe uma política de least privilege, mas há admins permanentes demais no Entra ou grupos privilegiados permanentes demais no AD
existe uma política de MFA, mas ela ainda deixa fora da cobertura fluxos administrativos sensíveis ou caminhos de autenticação legacy
existe uma política de acesso de terceiros no papel, enquanto configurações de convite de convidados ou acesso cross-tenant continuam abertas demais
existe um processo trimestral de revisão de acesso, mas ninguém consegue mostrar evidência atual de que revisões de convidados, grupos ou papéis realmente aconteceram
existe uma política de governança de aplicações, mas ninguém consegue mostrar o estado atual de permissões de service principals, grants app-only ou configurações de consentimento
existe uma política de auditoria e monitoramento que menciona controles, mas ninguém consegue demonstrar o estado atual da auditoria AD ou a cobertura atual de Entra audit logs

É por isso que um artigo NIS2 voltado à identidade não deve terminar em slogans de governança. Uma equipe técnica precisa ser capaz de demonstrar estado aplicado, não apenas intenção escrita.

Contexto de França e ANSSI

Como este artigo é UE-first, a França entra aqui como contexto, não como núcleo normativo.

A página oficial da ANSSI sobre NIS2 informa que a agência continuará comunicando ao longo da transposição nacional, que futuras entidades essenciais e importantes são incentivadas a começar desde já uma abordagem de segurança coerente com a NIS2 e que, desde 17 de março de 2026, a ANSSI disponibiliza o Référentiel Cyber France (ReCyF) como documento de trabalho. A ANSSI também afirma que o ReCyF, por padrão, não é obrigatório neste estágio e corresponde ao framework de cibersegurança mencionado no artigo 14 do projeto de lei Résilience.

A leitura prudente é direta:

ReCyF não é a própria diretiva NIS2
ReCyF não substitui a leitura dos textos legais aplicáveis
entidades sediadas na França podem, ainda assim, usá-lo como ponto prático de referência perante a supervisão nacional
equipes devem tratar o estado da transposição francesa e as expectativas da ANSSI como uma camada nacional que se soma à diretiva da UE

Nesse sentido, Guia ANSSI Active Directory: como aplicar na prática as recomendações de segurança é uma leitura complementar útil, mas não substitui a análise da NIS2.

Remediation

Mesmo antes da validação formal, equipes devem iniciar remediação concreta para os pontos que não conseguiriam defender em uma revisão. Na prática, isso significa reduzir privilégios permanentes injustificados, fechar caminhos de autenticação legacy ainda abertos, endurecer a governança de convidados e do cross-tenant, revisar service principals sobreprivilegiados e documentar com precisão o estado corrigido.

Validação após a remediação

Um programa de identidade realmente defensável diante de uma revisão NIS2 precisa comprovar que as lacunas foram corrigidas, não apenas identificadas.

Após a remediação, equipes devem conseguir apresentar:

inventários atualizados de acesso privilegiado em AD e Entra
evidência atual de que controles de autenticação forte se aplicam onde a organização afirma que devem se aplicar
configurações atualizadas para convidados, cross-tenant e governança de aplicações após as mudanças
evidência de auditoria atual mostrando que mudanças de identidade continuam visíveis
uma lista revisada de exceções que separe risco residual de deriva ou negligência

Na prática, as ações que mais aumentam a defensabilidade de uma postura de identidade costumam ser as mesmas: remover privilégios permanentes desnecessários, fechar acessos legacy ainda abertos, revisar convidados e acesso cross-tenant, inventariar service principals sobreprivilegiados e então rerun as exportações e os logs usados como evidência. O objetivo não é produzir mais um slide. O objetivo é demonstrar que o controle declarado continua existindo depois da correção.

É esse passo de validação que separa um exercício pontual de framework de uma revisão capaz de sobreviver ao próximo ciclo de auditoria.

Como a EtcSec ajuda a medir lacunas de identidade relevantes para a NIS2

A EtcSec precisa ser posicionada de forma estreita aqui.

A questão não é dizer que a EtcSec “prova conformidade com a NIS2”. A questão é que ela ajuda a medir lacunas técnicas de identidade que costumam importar quando uma equipe precisa demonstrar que acesso, autenticação, governança de privilégios e monitoramento estão realmente aplicados.

Exemplos:

EXCESSIVE_PRIVILEGED_ACCOUNTS
PRIVILEGED_ACCOUNT_STALE
DANGEROUS_GROUP_NESTING
DCSYNC_CAPABLE
ACL_GENERICALL
CA_NO_MFA_REQUIREMENT
PA_PIM_NOT_ENABLED
GUEST_INVITATION_UNRESTRICTED
B2B_CROSS_TENANT_OPEN
AZ_SECURITY_DEFAULTS_DISABLED

Esses findings não criam presunção legal. Eles ajudam a equipe de segurança a responder uma pergunta mais difícil: se afirmamos que nossos controles de identidade são baseados em risco e realmente aplicados, qual evidência técnica atual sustenta essa afirmação?

Requisitos NIS2 para segurança de identidade: o que equipes de AD e Entra precisam comprovar