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 nis2 identity security requirements, o primeiro erro a evitar é tratar a NIS2 como se fosse um guia de configuração da Microsoft. Não é. A Directive (EU) 2022/2555 define obrigações de gestão de risco e expectativas de governança no nível da UE. Ela não diz às equipes para implantar o Microsoft Entra Privileged Identity Management, aplicar um template específico de Conditional Access, ou definir um comprimento específico de senha no Active Directory.

Essa distinção importa porque as equipes de identidade ainda precisam provar algo concreto. Mesmo que a NIS2 não nomeie produtos Microsoft, as equipes de AD e Entra ainda precisam demonstrar que o acesso privilegiado é controlado, que a autenticação é forte o suficiente para o risco, que o controle de acesso é aplicado em produção, e que o monitoramento consegue comprovar violações de política ou desvio (drift).

Este artigo mantém quatro camadas deliberadamente separadas:

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
Implementing Regulation (EU) 2024/2690	Requisitos mais técnicos para tipos específicos de entidades cobertas	Um manual universal para toda entidade sujeita à 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 é a diferença entre uma revisão de identidade defensável e um artigo de compliance que extrapola o que o texto diz.

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

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

A identidade aparece de forma mais direta no Article 21(2). Para este tema, três pontos importam mais:

O Article 21(2)(f) inclui políticas e procedimentos para avaliar a eficácia das medidas de gestão de risco de cibersegurança.
O Article 21(2)(i) inclui segurança de recursos humanos, políticas de controle de acesso e gestão de ativos. Este é o único ponto da lista que nomeia diretamente o controle de acesso, e é a âncora que uma equipe de identidade deve citar.
O Article 21(2)(j) inclui o uso de autenticação multifator ou de soluções de autenticação contínua, comunicações de voz, vídeo e texto seguras, e sistemas seguros de comunicação de emergência dentro da entidade, quando apropriado.

A NIS2 também traz um contexto importante no considerando 89, que lista práticas básicas de cyber hygiene, como princípios zero-trust, atualizações de software, configuração de dispositivos, segmentação de rede, gestão de identidade e acesso, ou conscientização do usuário. Esse considerando não é uma baseline oculta da Microsoft. É um sinal forte de que a governança de identidade, a autenticação e a disciplina de acesso fazem parte do que os reguladores esperam que as entidades tratem como trabalho de segurança fundamental.

A leitura segura para as 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 a gestão de identidade e acesso se encaixa na NIS2

Para as 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 é a seguinte:

Objetivo NIS2	O que as equipes de segurança devem conseguir comprovar	Exemplo de evidência AD / Entra
O acesso é controlado	O acesso privilegiado e sensível é limitado e revisado	Exportações de grupos privilegiados, exportações de atribuições de papéis no Entra, registros de access review
A autenticação é adequada ao risco	O acesso sensível não é protegido apenas por senha	Estado das políticas de Conditional Access, estado do Security Defaults, evidência de MFA para admins
O privilégio é proporcional	O acesso administrativo permanente é minimizado e as exceções têm um responsável	Atribuições de papel permanentes versus elegíveis, revisão de admins obsoletos, governança de contas break-glass
O monitoramento funciona	As mudanças de identidade e de papéis podem ser revisadas posteriormente	Entra audit logs, política de auditoria do AD, evidência de visibilidade de mudanças em grupos e objetos
O acesso de terceiros e de aplicações é governado	Convidados, acesso externo e permissões de aplicações não sofrem desvio silenciosamente	Restrições de convidados, configurações cross-tenant, configurações de consentimento de apps, revisão de permissões de service principals

É também aqui que Conformidade AD e Azure: NIS2, ISO 27001, CIS Controls continua útil. Esse artigo mapeia diversos frameworks de forma ampla. O artigo que você está lendo agora reduz a questão a um problema mais difícil: o que uma equipe de identidade realmente consegue comprovar em uma revisão no estilo NIS2.

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

É no escopo que 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 por essa implementação nacional. Uma equipe que atua na França, na Alemanha, na Itália ou em outro Estado-Membro deve esperar a mesma base da UE, mas não necessariamente o mesmo empacotamento de supervisão, os mesmos materiais de referência ou o mesmo fluxo de implementação.

Segundo, nem todo detalhe técnico que as pessoas associam à NIS2 vem do próprio texto da diretiva. O Commission Implementing Regulation (EU) 2024/2690, adotado em 17 October 2024 nos termos do Article 21(5), primeiro parágrafo, estabelece requisitos técnicos e metodológicos para uma lista fechada de tipos de entidades cobertas: provedores de serviços DNS, registros de nomes de TLD, provedores de serviços de cloud computing, provedores de serviços de data center, provedores de content delivery network, managed service providers, managed security service providers, provedores de online marketplaces, de mecanismos de busca online e de plataformas de redes sociais, e trust service providers. Esse regulamento é altamente relevante, mas não é um atalho genérico que possa ser aplicado sem alterações a qualquer organização sujeita à NIS2.

Para as entidades que estão dentro desse escopo, o Anexo é muito mais prescritivo em relação à identidade do que a própria diretiva. Seu point 11 cobre o controle de acesso e é mapeado pela Comissão para o Article 21(2), points (i) and (j): o point 11.2.3 exige que os direitos de acesso sejam revisados em intervalos planejados, com os resultados documentados; o point 11.3 exige políticas para contas privilegiadas e contas de administração de sistemas, incluindo autenticação forte como a autenticação multifator; e o point 11.7 exige múltiplos fatores de autenticação ou mecanismos de autenticação contínua quando apropriado, com a força da autenticação compatível com a classificação do ativo acessado.

Terceiro, algumas entidades também estão sujeitas a conjuntos de regras setoriais ou nacionais específicas. Por isso, uma revisão séria de identidade sob a NIS2 precisa responder três verificações antes mesmo de começar:

A entidade está dentro do escopo da NIS2, e em qual categoria?
A entidade também está coberta por textos da União 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 orientações nacionais?

Isso importa porque, sem essa disciplina, equipes passam a fazer afirmações como "a NIS2 exige PIM" ou "a NIS2 exige senhas de 12 caracteres". Nenhuma das duas afirmações é defensável: a diretiva não nomeia nenhum produto, e mesmo o Implementing Regulation trata a autenticação multifator como um exemplo de autenticação forte, não como uma exigência nomeada de um produto específico.

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

A NIS2 não nomeia o Active Directory nem o Microsoft Entra. Mas, se o seu ambiente os utiliza, eles são pontos óbvios onde a evidência será buscada.

Acesso privilegiado

Uma revisão madura de identidade deve 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 é justificado.

Isso normalmente significa revisar:

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

É exatamente por isso que Desvio de Acesso Privilegiado no Active Directory e Acesso Privilegiado no Azure: Administradores Globais Demais são referências internas relevantes para este tema. Elas não provam, por si só, conformidade com a NIS2. Elas mostram os tipos de condições de identidade que uma equipe teria dificuldade de defender sob o escrutínio da NIS2.

Força da autenticação

A NIS2 claramente dá ao MFA ou à autenticação contínua um lugar no conjunto de controles, mas a expressão "where appropriate" ("quando apropriado") ainda importa. Por isso, um programa de identidade defensável deve conseguir explicar:

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

A própria documentação da Microsoft é útil aqui porque explica o que o Conditional Access realmente é: ele "brings signals together, to make decisions, and enforce organizational policies" ("reúne sinais para tomar decisões e aplicar políticas organizacionais"), e a Microsoft agora o descreve como seu Zero Trust policy engine. A mesma página acrescenta um detalhe que importa para fins de evidência: o Conditional Access é aplicado depois que a autenticação de primeiro fator é concluída. Isso o torna evidência de um caminho de controle, não prova de que a NIS2 tenha exigido especificamente o Conditional Access como produto.

Da mesma forma, Segurança de Identidade no Azure: Por Que o MFA Sozinho Não Basta ajuda a enquadrar corretamente essa limitação técnica: o MFA é importante, mas uma má governança de papéis, um acesso de convidados aberto demais ou um consentimento malicioso de aplicações ainda podem deixar uma exposição de identidade relevante.

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

O escopo de identidade sob a NIS2 é mais amplo do que o login de funcionários. O controle de acesso também envolve usuários externos, acesso de aplicações e autoridade delegada.

Uma equipe técnica deve conseguir mostrar:

como o acesso de convidados é restringido
quem tem permissão para convidar convidados
se a colaboração cross-tenant é rigidamente governada ou permanece amplamente aberta
como as permissões de aplicações e o consentimento são controlados
se aplicações corporativas com privilégios excessivos são revisadas periodicamente

Essas não são preocupações abstratas. A Microsoft documenta que as permissões de aplicação podem conceder acesso app-only, e que o consentimento de usuário ou de administrador governa como as aplicações obtêm acesso a recursos protegidos. A Microsoft também documenta como as configurações de consentimento do usuário podem ser restringidas para reduzir consentimentos maliciosos ou excessivamente amplos. É por isso que Registros de Aplicativo no Azure: Aplicações com Privilégios Excessivos no Tenant e OAuth Consent Phishing: Como Aplicações Maliciosas Contornam o Roubo de Senhas pertencem a uma leitura séria de identidade sob a NIS2, mesmo que a própria NIS2 nunca utilize esses nomes de produto.

Evidências que as equipes de segurança devem conseguir apresentar

Um programa fraco de identity compliance geralmente tem um conjunto de políticas, mas não um pacote de evidências. Em uma revisão orientada pela NIS2, as equipes de AD e Entra devem conseguir produzir evidências atuais e revisáveis para os controles que afirmam aplicar.

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

Tema de controle	Exemplo de evidência
Acesso privilegiado	Exportações atuais de grupos privilegiados do AD, exportações de atribuições de papéis no Entra, evidência de privilégio elegível versus permanente
Disciplina de revisão de acesso	Registros de revisão de papéis, resultados de revisão de membership de grupos, evidência de revisão de acesso de convidados
MFA e proteção de acesso	Estado do Conditional Access, estado do Security Defaults quando relevante, cobertura de MFA direcionada a papéis
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 aplicações, configurações de consentimento, registros de revisão de service principals de alto risco
Monitoramento	Entra audit logs, saídas da política de auditoria do AD, prova de que as mudanças de identidade relevantes são registradas e retidas
Exceções	Um registro documentado de exceções com responsável, justificativa e data de revisão

É também aqui que Como Auditar a Segurança do Microsoft Entra ID, Como Auditar a Segurança do Active Directory e Monitoramento do Active Directory: Event IDs de Segurança Que Importam ajudam a transformar a linguagem do framework em etapas operacionais de revisão.

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

As falhas de identidade de maior risco sob a NIS2 geralmente não vêm da falta de texto de política. Elas vêm da lacuna entre o que a política diz e o que o diretório e o tenant realmente aplicam.

Exemplos comuns incluem:

uma política escrita de least-privilege com admins permanentes demais no Entra ou grupos privilegiados permanentes demais no AD
uma política de MFA que ainda deixa fluxos administrativos sensíveis ou caminhos de autenticação legados fora de uma cobertura efetiva
uma política de acesso de terceiros que existe no papel, enquanto as configurações de convite de convidados ou o acesso cross-tenant permanecem abertos demais
um processo trimestral de revisão de acesso sem evidência atual de que as revisões de convidados, grupos ou papéis foram de fato concluídas
uma política de governança de aplicações que existe, mas ninguém consegue mostrar as permissões atuais dos service principals, os grants app-only ou as configurações de consentimento
uma política de auditoria e monitoramento que nomeia controles, mas ninguém consegue comprovar a auditoria atual do AD ou a cobertura atual dos audit logs do Entra

É por isso que um artigo sobre identidade e NIS2 não deve terminar em slogans de governança. Uma equipe técnica precisa conseguir mostrar o estado efetivamente aplicado, não apenas a intenção escrita.

Contexto de França e da ANSSI

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

A página oficial da ANSSI sobre a NIS2 afirma que a agência continuará se comunicando ao longo da transposição nacional, que as futuras entidades essenciais e importantes são incentivadas a iniciar já uma abordagem de segurança consistente com a NIS2, e que, desde 17 March 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 nesta fase, e corresponde ao framework de cibersegurança mencionado no Article 14 do projeto de lei francês Résilience.

A leitura segura é direta:

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

Isso faz de Guia ANSSI Active Directory: Aplicando as Recomendações de Segurança na Prática uma leitura complementar útil, mas não um substituto para a análise da NIS2.

Validação após a Remediation

Um programa de identidade pronto para a NIS2 precisa provar que as lacunas foram fechadas, não apenas que foram identificadas.

Após a remediation, as equipes devem conseguir mostrar:

inventários atualizados de acesso privilegiado, tanto no AD quanto no Entra
evidência atual de que os controles de autenticação forte se aplicam onde a organização afirma que deveriam se aplicar
configurações atualizadas de convidados, cross-tenant e governança de aplicações após as mudanças
evidência de auditoria atual mostrando que as mudanças de identidade continuam visíveis
uma lista de exceções atualizada que distingue risco residual de desvio (drift) ou negligência

Essa etapa de validação é o que separa um exercício pontual de framework de uma revisão que ainda vai sobreviver ao próximo ciclo de auditoria.

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

A EtcSec deve ser posicionada de forma restrita aqui.

O ponto não é que a EtcSec "prova conformidade com a NIS2". O ponto é que ela ajuda a medir lacunas técnicas de identidade que frequentemente importam quando uma equipe está tentando provar que o acesso, a autenticação, a governança de privilégios e o monitoramento estão realmente sendo aplicados.

Exemplos incluem:

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 uma presunção legal. Eles ajudam uma equipe de segurança a responder a uma pergunta mais difícil: se dizemos que nossos controles de identidade são baseados em risco e realmente aplicados, qual evidência atual sustenta essa afirmação?

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