Gestão de acessos NIS2: O que cinco peritos corrigiriam primeiro

Da política à prática: quem teve acesso a quê, com a aprovação de quem, durante quanto tempo, e é possível prová-lo?

Cinco líderes de cibersegurança sobre a gestão de acessos NIS2: os controlos mais difíceis de pôr em prática e as provas de que as organizações precisam para demonstrar que funcionam.

Resumo executivo

A NIS2 mudou aquilo que as organizações têm de demonstrar em matéria de gestão de acessos. Já não basta implementar controlos de cibersegurança. As organizações precisam também de provas de que esses controlos funcionam, de quem é responsável por eles e do que aconteceu quando alguém (ou algo) acedeu a um sistema crítico. Para os órgãos de gestão, a responsabilidade de provar que os controlos de gestão de acessos existem e funcionam pode agora implicar responsabilidade pessoal.

Essas provas também têm de abranger mais do que os colaboradores. Contas de serviço, chaves de API, fornecedores e agentes de IA podem ter acesso a sistemas críticos. Saber que essas identidades existem, a que podem aceder e se esse acesso ainda se justifica passou a fazer parte do mesmo problema.

Os cinco líderes de cibersegurança entrevistados para este relatório abordaram esse problema a partir de ângulos diferentes. Debateram qual o requisito do artigo 21.º da NIS2 mais difícil de pôr em prática e onde as organizações continuam mais expostas. No fim, as respostas regressaram repetidamente à diferença entre ter um controlo de gestão de acessos (ou qualquer outro controlo de segurança) e demonstrar que funciona.

Participantes

Gabriel Dinu

Deputy Director, National Cyber Security Directorate of Romania
ENISA Management Board representative

Jane Frankland MBE

CEO and Founder of KnewStart

Ioannis Ntokos

IT Governance Risk & Compliance Expert (former FedEx, PwC, and Randstad)

Dr. Yiannis Pavlosoglou

Vice Governor, National Cybersecurity Authority of Greece

Alex Muntyan

CEO of Passwork

Aviso legal: Os quatro participantes externos neste relatório colaboraram como especialistas independentes. Nenhum deles tem uma relação comercial com o Passwork nem recomenda os seus produtos. As opiniões expressas são suas e não representam as posições dos seus empregadores atuais ou anteriores.

O teste que torna a NIS2 real

A gestão de acessos ao abrigo da NIS2 pode ser definida por uma pergunta fundamental: 

O resto deste relatório aplica essa pergunta às pessoas, fornecedores, contas de serviço, chaves de API e agentes de IA que conseguem chegar a sistemas críticos. Pergunta também se as provas deixadas são suficientemente boas para mostrar o que aconteceu.

O artigo 21.º exige que as entidades essenciais e importantes giram o risco de cibersegurança através de medidas que reflitam os riscos que enfrentam. O artigo 23.º estabelece regras rigorosas e obrigatórias de notificação de incidentes para as entidades essenciais e importantes afetadas por um incidente cibernético significativo. Esses requisitos aplicam-se tanto às entidades essenciais como às importantes, embora a forma como essas organizações são supervisionadas seja diferente.

Os órgãos de gestão devem aprovar as medidas de gestão dos riscos de cibersegurança e supervisionar a sua aplicação. Cada Estado-Membro deve designar uma autoridade competente para supervisionar e fazer cumprir a diretiva.

A NIS2 atribui essa responsabilidade ao órgão de gestão por uma razão prática. Seja qual for a forma como um atacante entra, as credenciais roubadas ou utilizadas indevidamente tendem a surgir algures pelo caminho. 

• O Data Breach Investigations Report 2026 da Verizon identificou abuso de credenciais em 39 % das violações de dados analisadas, uma proporção superior à de qualquer outra técnica. 
• O ENISA Threat Landscape 2026, que analisou 8257 incidentes registados ao longo de 2025, concluiu que o phishing representou 77,8 % da atividade de engenharia social, na maior parte dirigida a uma palavra-passe ou a uma sessão ativa, enquanto a exploração de vulnerabilidades esteve na origem de seis em cada dez incidentes de acesso não autorizado. As entidades essenciais ao abrigo da NIS2 foram o alvo em 72,9 % dos incidentes registados.

Um conselho de administração que aprova medidas de cibersegurança sem perguntar como é controlado o acesso está a aprovar um plano que deixa de fora a sua fragilidade mais explorada.

Essa escolha, intencional ou não, tem consequências. Para as entidades essenciais, as infrações aos artigos 21.º e 23.º podem dar origem a coimas máximas de pelo menos 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, consoante o montante que for mais elevado. 

A aplicação também está a avançar. O prazo inicial terminou em outubro de 2024, mas muito poucos países o cumpriram. Em julho de 2026, a Comissão Europeia instaurou ações contra a Irlanda, a Espanha, a França e os Países Baixos no Tribunal de Justiça da União Europeia por não terem notificado medidas de transposição integral da NIS2 para o direito nacional.

O artigo 21.º abrange um vasto leque de medidas de cibersegurança, e os desafios práticos variam de umas para as outras. Quando lhes foi perguntado qual é a mais difícil de pôr em prática, cada especialista apontou para um ponto diferente. 

• Pavlosoglou destacou a MFA, referindo os sistemas legados que não a permitem, as contas técnicas que deixam de funcionar quando é ativada e as exceções que as pessoas começam a pedir quase de imediato.
• Para Dinu, é a segurança da cadeia de abastecimento, que considera difícil tanto de implementar para as organizações como de avaliar para os reguladores.
• Frankland afirmou que é avaliar se as medidas de cibersegurança são eficazes: ter um controlo é uma coisa, provar que funciona é uma conversa completamente diferente.
• Muntyan centrou-se no controlo de acesso e na gestão de credenciais, em particular na capacidade de uma organização mostrar quem teve acesso e o que fez.
• Ntokos escolheu o tratamento de incidentes, porque há muitos processos e pessoas envolvidos quando ocorre um incidente.

O cumprimento dessas medidas também exige mais do que controlos técnicos e depende muitas vezes da cultura organizacional e das pessoas que os utilizam.

Dinu compara a regulamentação às leis sobre o cinto de segurança. As pessoas devem usar o cinto porque as protege, e não apenas porque a lei o impõe, e defende que a cibersegurança deve funcionar da mesma forma. Na prática, demasiadas vezes as organizações tratam a segurança como um custo até que a regulamentação ou um incidente as obrigue a agir.

Pavlosoglou aborda o problema da cultura a partir de outro ângulo. Questionado sobre os obstáculos à conformidade, aponta a disponibilidade das organizações para divulgar o que aconteceu quando ocorre um incidente. 

A rede de CSIRT dá às autoridades nacionais de toda a UE um meio de partilhar informações sobre ataques, o que torna a cooperação com as autoridades parte da resposta, em vez de uma conversa que só começa quando chega a fiscalização.

A cultura é mais difícil de mudar do que uma política. A NIS2 acrescenta outra alavanca ao colocar a responsabilidade por essas medidas de cibersegurança ao nível da gestão.

A responsabilidade pessoal mudou a conversa no conselho de administração

Com o órgão de gestão responsável por aprovar e supervisionar a aplicação da NIS2, a posição do CISO sai reforçada, sobretudo quando as fragilidades na gestão de acessos exigem orçamento adicional ou mudanças noutras áreas da empresa.

Dinu viu o efeito em primeira mão. Os consultores com quem falou descreveram administrações que mostravam pouco interesse pelas apresentações sobre cibersegurança até se falar de responsabilidade pessoal. Nessa altura, disse, «Mudou todo o ambiente na sala.» Quando os membros do conselho de administração podem ser responsabilizados, torna-se muito mais difícil desvalorizar um problema de segurança como algo que cabe ao CISO resolver.

Muntyan observa uma mudança semelhante do lado do fornecedor. Antes, a segurança talvez chegasse ao conselho de administração uma vez por ano. Nas conversas do Passwork com as organizações, vê agora os executivos de topo cada vez mais envolvidos, quando antes as discussões ficavam pelos gestores e arquitetos de TI.

Ntokos também vê a responsabilização da gestão de topo como uma mudança positiva. Quando o risco de cibersegurança passa a ser uma responsabilidade empresarial e financeira, defende, torna-se mais difícil para a liderança deixá-lo inteiramente nas mãos da equipa de segurança.

Pavlosoglou refere a transposição da Diretiva NIS2 para o direito grego, segundo a qual o responsável pela segurança da informação (CISO) tem de ser um membro interno do pessoal que reporta ao conselho de administração. Isso coloca no CISO o trabalho de «traduzir para a linguagem do conselho de administração». Dá o exemplo de uma organização sem cobertura suficiente das identidades de utilizador com autenticação multifator (MFA) ativada. Segundo defende, isto tem de chegar ao conselho de administração como um risco de exposição do negócio, acompanhado de um custo e de um plano, caso contrário não haverá ação.

Coimas e responsabilidade da gestão

Responsáveis, mas sem autoridade

Jane Frankland MBE defende há anos que os CISO respondem pelo risco cibernético sem terem autoridade para o reduzir. A responsabilidade pela segurança e pela resiliência cabe ao CISO, a aplicação de correções (patching) cabe às equipas de TI e de infraestrutura, e o orçamento para resolver qualquer uma delas está, mais uma vez, noutro lado. Quando o risco persiste, é o CISO que continua a responder por ele.

O conselho de administração tem estado do outro lado desse arranjo, e o mesmo hábito manifesta-se aí.

Para Frankland, esta é a mudança mais importante e também aquela em relação à qual é mais cautelosa. A responsabilidade existe no papel. Se vai levar os membros do conselho de administração a fazer perguntas mais difíceis depende da fiscalização, e, segundo diz, ainda é cedo para saber.

Frankland descreve o objetivo mais amplo como «capacidade de sobrevivência cibernética» (cyber survivability). O objetivo é reduzir o impacto de um incidente, manter as operações críticas em funcionamento e preservar um caminho para a recuperação.

No caso do conselho de administração, as provas têm de mostrar mais do que o facto de lhe ter sido entregue um relatório de segurança. O conselho tem de compreender o risco material, aprovar as medidas destinadas a geri-lo e supervisionar os passos seguintes.

A MFA complica-se assim que chega à organização

O artigo 21.º exige que as organizações utilizem MFA quando adequado, mas a parte mais difícil é pô-la a funcionar em toda a organização.

Pavlosoglou descreve a rapidez com que as exceções se acumulam quando a MFA obrigatória é ativada. Num exemplo, a equipa de TI ativa a MFA na segunda-feira de manhã. Às 10h00 desse mesmo dia, o gabinete do diretor pede para ficar excluído. Ao aproximar-se a tarde, chega o primeiro pedido de exclusão para contas técnicas não pessoais (NPTA). Como foram utilizadas contas de utilizador como identidades de serviço (por exemplo, para ligar a sistemas de pagamento), ativar a MFA interrompe o serviço.

Dinu vê a mesma resistência dos utilizadores como parte do problema de implementação. A MFA muda a forma como as pessoas trabalham, pelo que implementá-la significa também lidar com a resistência que surge quando um controlo de segurança acrescenta mais um passo a um processo habitual.

Frankland alerta contra a utilização da expressão «quando adequado» da diretiva como via de escape. Nas suas palavras, não deve ser interpretada como «quando for conveniente». A robustez da autenticação deve estar alinhada com a sensibilidade do ativo e com o risco associado ao acesso. Ter MFA implementada não significa que todos os métodos de autenticação ofereçam o mesmo nível de proteção. Frankland defende a MFA resistente a phishing, como a FIDO2, para os acessos de maior risco.

Ntokos defende um ponto semelhante numa perspetiva operacional. As organizações precisam, primeiro, de um inventário da sua infraestrutura e de perceber onde residem os dados críticos. Depois, têm de ter em conta os diferentes ambientes de trabalho. Um operário fabril pode não estar autorizado a ter consigo um telemóvel. Um colaborador de escritório e um administrador têm requisitos de acesso diferentes.

A tecnologia legada torna isso ainda mais difícil. Uma aplicação antiga pode não ser compatível de raiz com MFA moderna. Pavlosoglou alerta que as organizações podem deixar zonas cinzentas nas suas políticas para acomodar esses sistemas, obter a aprovação da política e parecer conformes sem corrigir a fragilidade de fundo.

Frankland chega à mesma conclusão pelo lado da conceção. A questão deixa de ser como acoplar a MFA a um sistema antigo e passa a ser como impedir que esse sistema seja sequer acessível com uma única credencial.

Uma opção é deslocar o controlo de autenticação para fora da aplicação. Muntyan descreve a colocação da MFA na camada de gestão de credenciais, utilizada para intermediar o acesso a aplicações legadas. A aplicação em si não adquire subitamente autenticação moderna, mas o caminho até às suas credenciais pode ficar sujeito a controlos mais fortes.

Não é possível impor um único método de autenticação a todos os utilizadores e sistemas. É preferível saber onde é necessária uma autenticação mais forte e ter uma forma defensável de lidar com os sistemas que não a conseguem oferecer por si próprios.

As identidades não humanas estão a tornar-se parte do problema de acesso

Os inventários de acessos começavam tradicionalmente pelos colaboradores, mas isso já não é suficiente. Chaves de API, contas de serviço, scripts e agentes de IA podem levar autoridade para dentro de sistemas críticos. Alguns continuam ativos muito depois de ter desaparecido a razão pela qual foram criados.

Muntyan vê outro problema na forma como os segredos são armazenados. Se o sistema aprovado for pouco prático, as equipas encontram outro sítio onde guardar chaves de API, tokens e outras credenciais. Esses «esconderijos» criam dispersão de segredos (secrets sprawl) e tornam mais difícil saber que credenciais existem ou quem as pode utilizar.

É esta assimetria que hoje preocupa Muntyan. As palavras-passe estão rodeadas de controlos que existem porque se parte do princípio de que as pessoas vão falhar, e as credenciais de máquina não herdaram quase nenhum deles. Olhando para o futuro, prevê que os agentes de IA venham agravar a situação, porque conseguem criar e utilizar credenciais à velocidade da máquina, enquanto os processos de revisão de acessos foram concebidos em função das pessoas.

Pavlosoglou considera que o custo do consumo de tokens pode acabar por travar a utilização descontrolada de agentes de IA. A título de episódio, cita histórias deste verão de CISO que tiveram de acompanhar colaboradores de organizações com controlos regulatórios rigorosos que estavam a criar agentes para obter palpites sobre jogos do Campeonato do Mundo.

À medida que essa utilização se torna mais cara, as organizações têm mais uma razão para acompanhar que agentes estão em execução e com que finalidade. O custo é, no entanto, um instrumento pouco preciso. Apanha os agentes cuja fatura alguém está a vigiar, não aqueles que ninguém se lembra de ter criado.

Frankland leva a questão para lá da autenticação. «A autenticação diz-nos quem ou o que está a agir, mas não nos diz se a ação é sensata.»

Um agente pode autenticar-se corretamente e operar dentro das permissões que lhe foram legitimamente concedidas e, ainda assim, executar uma ação que a organização não desejaria.

Ntokos vê nisto um problema de gestão de identidades ao qual os sistemas existentes terão de se adaptar. As organizações precisam de conseguir identificar os agentes, monitorizar as suas ações, restringir o seu âmbito e revogar ou fazer expirar o seu acesso.

A responsabilização não desaparece pelo facto de o agente ser software. Dinu defende que utilizar um agente não transfere a responsabilização para o software e que a responsabilidade continua a ser da pessoa ou organização que detém ou gere o sistema.

As equipas responsáveis pelos acessos devem deixar de tratar as identidades não humanas como exceções. O lugar delas é no inventário, a par dos colaboradores, administradores e fornecedores.

O acesso de fornecedores precisa do seu próprio ciclo de vida

O acesso de terceiros alimenta um problema de responsabilização semelhante. Pavlosoglou já esteve do lado da segurança em longas negociações de contratos e não pede desculpa pelo tempo que podem exigir. «A negociação demorou dez meses», disse. «O negócio queria saber onde estava o contrato. Mas, se não chegássemos a acordo sobre a forma de tratar os fornecedores em termos de cláusulas de indemnização, responsabilidades e KPI menos tangíveis, mas igualmente importantes, não fazia sentido avançar com o retorno do investimento em segurança (ROSI) que o terceiro iria proporcionar.»

Isso incluía saber se o fornecedor tinha de comunicar uma violação e quando, se o cliente tinha o direito de o auditar e quem pagaria a auditoria. Alguns desses pormenores podem estar escondidos nas cláusulas de indemnização ou nas condições do seguro cibernético. Nas palavras de Pavlosoglou, «até palavras isoladas e vírgulas podem fazer uma grande diferença».

O seu conselho é começar pelos fornecedores com acesso a sistemas críticos e rever o que já está no papel. A NIS2 dá às equipas de segurança um motivo para voltar ao departamento jurídico e garantir que os contratos cobrem o acesso que esses fornecedores têm.

Dinu vê a mesma dificuldade do outro lado da mesa. A segurança da cadeia de abastecimento é a medida do artigo 21.º sobre a qual as partes interessadas da DNSC mais perguntam, e as perguntas podem parecer básicas: que fornecedores, que medidas, impostas por quem. Dinu interpreta isso como um sinal da dificuldade de avaliar o requisito, e a própria autoridade enfrenta a sua versão do problema ao redigir regras que têm de servir mais de uma dúzia de setores e entidades de todas as dimensões.

Frankland defende que o acesso de fornecedores deve ser atribuível, limitado e revogável. Mostra-se também cética quanto a depender demasiado de questionários. Um questionário preenchido não prova que os controlos declarados estão a funcionar. As organizações têm também de olhar para lá dos seus fornecedores diretos e perceber onde é que quartas partes podem introduzir acessos ou dependências mais abaixo na cadeia.

Ntokos afirma que o acesso de fornecedores tem de ser gerido ao longo de toda a relação, desde a integração até à saída. O nível de acesso deve depender do trabalho que o fornecedor está a realizar, com acessos separados ou limitados no tempo quando necessário.

Muntyan recomenda evitar palavras-passe permanentes para fornecedores, registar a sua atividade e rodar as credenciais quando o contrato termina. Esses controlos produzem também algo que a organização pode mais tarde ter de mostrar: provas de que o acesso do fornecedor foi limitado e retirado quando deixou de ser necessário.

As provas têm de sobreviver ao incidente

A NIS2 não prescreve um prazo único de conservação para os logs de acesso. Os especialistas reconheceram o equívoco generalizado de que os logs de acesso têm de ser conservados durante 10 meses, mas defenderam que cabe às próprias organizações determinar um prazo adequado com base nos requisitos legais aplicáveis, nas necessidades do negócio e na sua avaliação de riscos. As orientações técnicas de implementação da ENISA preveem igualmente que os prazos de conservação sejam definidos nesta base.

A conservação é apenas uma parte do problema. As organizações têm também de decidir que registos de acesso são relevantes, protegê-los e garantir que podem ser apresentados quando um auditor ou uma equipa de resposta a incidentes precisar deles.

Os logs de acesso são muitas vezes discutidos neste tema, mas os profissionais sugerem que a questão mais pertinente é saber se esses registos são fiáveis e utilizáveis.

Pavlosoglou descreve o cenário de falha do lado do regulador. Ao abrigo da NIS2, as autoridades nacionais competentes supervisionam a conformidade e, na Grécia, são obrigadas a intervir quando uma entidade abrangida pede ajuda durante um incidente. O estado dos sistemas de informação que encontram à chegada determina o que podem fazer.

A resposta deve começar pelo serviço crítico, defende. As organizações têm de determinar que registos são necessários para compreender a atividade em torno desse serviço, em vez de tratarem a NIS2 como uma instrução para registar tudo de forma indiscriminada.

Não há forma de recuperar dessa posição depois do facto. Quando a autoridade já está no edifício, a organização ou tem os registos ou não tem, e o dinheiro poupado ao deixar o registo de logs desligado já foi gasto muitas vezes.

Para Frankland, há outro problema. Guardar logs serve de pouco se puderem ser alterados ou se não for possível reconstituir a atividade nos diferentes sistemas.

Ntokos centra-se na forma como essas provas são geridas. As organizações precisam de políticas de conservação e de registo de logs, armazenamento adequado, carimbos temporais, sincronização e cadeia de custódia. Antes de se preocuparem com a rapidez com que as provas podem ser obtidas, têm de garantir que foram conservadas corretamente.

Muntyan também sublinha a obtenção das provas. Se um regulador ou uma equipa de resposta a incidentes pedir provas, defende que as equipas devem conseguir apresentá-las em minutos ou numa hora, em vez de passarem dias a reunir registos de diferentes sistemas.

A conformidade deve expor as fragilidades, não escondê-las

Uma pontuação de conformidade perfeita pode ser menos tranquilizadora do que parece.

Dinu refere o Cyber Fundamentals, ou modelo de autoavaliação CyFun, desenvolvido pela autoridade belga de cibersegurança, no qual as organizações se autoavaliam todos os anos e as entidades essenciais apresentam um plano para corrigir as áreas de não conformidade. Não se espera que todos os controlos obtenham uma pontuação perfeita. Se isso acontecesse, disse, os reguladores ficariam «bastante preocupados».

A tolerância de Dinu a pontuações imperfeitas vem de ter observado o que acontece quando os reguladores exigem pontuações imaculadas.

Dinu afirma que um incidente pode mudar rapidamente essa atitude. Já viu organizações deixarem de tratar a cibersegurança como um exercício de conformidade e passarem a levar o risco a sério depois de terem sofrido elas próprias um ataque.

Muntyan afirma que, historicamente, os incidentes têm sido o gatilho para as organizações melhorarem a gestão de acessos, mas isso está a mudar. Os clientes empresariais perguntam cada vez mais aos fornecedores como gerem as credenciais antes de assinarem um contrato. Para um fornecedor, essa pergunta chega antes de qualquer regulador, e quem a faz é o cliente.

Para Pavlosoglou, as credenciais expostas podem ser um gatilho mais pessoal. Refere o conhecido efeito «name and shame» (exposição pública): a prova de que alguém pode reivindicar a sua identidade digital torna o risco muito mais difícil de ignorar.

Ntokos defende que as melhorias devem acompanhar o risco, em vez de esperarem por um prazo de conformidade ou por um incidente. Frankland também agiria mais cedo. O seu gatilho é o momento em que o número de sistemas de identidade e de credenciais se torna excessivo para as pessoas gerirem manualmente de forma fiável. Esperar por um incidente, uma auditoria ou um prazo de conformidade significa esperar até a fragilidade já se ter tornado um problema.

Lista de verificação da gestão de acessos NIS2

O que os cinco peritos corrigiriam primeiro

Passwork, concebido para a questão das provas

O Passwork é um gestor de palavras-passe e de segredos desenvolvido na UE para organizações que têm de mostrar, e não apenas afirmar, como as credenciais são controladas. 

As suas capacidades de conformidade com a NIS2 abrangem o controlo de acesso baseado em funções, tipos de cofre personalizáveis, a aplicação obrigatória da MFA em todo o sistema, a integração com AD/LDAP/SSO e registos de auditoria que podem ser exportados para um SIEM.

O Passwork não decide que serviços são críticos nem quem deve ter acesso a eles. Essas decisões continuam a caber à organização. O que pode fazer é ajudar a pôr essas decisões em prática e guardar os registos necessários para mostrar o que aconteceu.

Perguntas frequentes