PAM e contas break-glass para ISO 27001 em 2026

Às 02:14 de uma manhã de domingo, o responsável pela gestão do incidente recebe a mensagem que qualquer Diretor de Segurança da Informação teme: “A autenticação de produção está a falhar. A consola administrativa está inacessível. O failover da base de dados está bloqueado.”

O engenheiro de cloud de prevenção consegue ver o problema, mas não consegue corrigi-lo. A sua função privilegiada normal depende do mesmo fornecedor de identidade que está agora degradado. O responsável de operações pede a credencial de administrador de emergência. O gestor de conformidade pergunta se a conta break-glass alguma vez foi testada. O Encarregado da Proteção de Dados pergunta se o acesso à base de dados de produção pode expor dados pessoais. O Diretor de Segurança da Informação coloca a pergunta que determina se isto se transforma numa recuperação controlada ou num pesadelo de auditoria:

“Conseguimos provar quem usou o acesso de emergência, porquê, o que fez e que a conta foi reposta depois?”

Outra organização pode enfrentar o mesmo problema numa sala mais silenciosa. O Diretor de Segurança da Informação de uma FinTech está sentado perante auditores externos após uma configuração incorreta de uma base de dados na cloud. O incidente foi corrigido rapidamente, mas a causa raiz não era tranquilizadora. Um programador de um terceiro tinha privilégios administrativos permanentes. Quando o administrador principal ficou indisponível, o programador utilizou uma conta break-glass baseada numa palavra-passe partilhada, guardada numa nota “segura” disponível para a equipa de DevOps.

Os auditores não se focaram apenas na configuração incorreta. Perguntaram se o acesso era limitado no tempo, se existia responsabilização individual, se os comandos eram registados em logs, se os dados pessoais estavam protegidos ao abrigo do GDPR Article 32, se as obrigações de gestão do risco das TIC do DORA tinham sido cumpridas e se as expectativas de higiene de cibersegurança da NIS2 eram demonstráveis.

Este é o ponto de pressão real da gestão de acessos privilegiados e das contas break-glass em 2026. A PAM já não é um projeto de segurança de identidade de nicho. É o ponto onde ransomware, comprometimento de cloud, risco de fornecedores, proteção de dados, resiliência operacional e evidência de auditoria convergem.

O acesso privilegiado é onde os atacantes tentam vencer. O acesso break-glass é onde os defensores tentam recuperar. Ambos dependem da mesma capacidade perigosa: acesso elevado que pode contornar controlos, alterar configurações, ler dados sensíveis, rodar chaves, desativar o registo em logs, restaurar cópias de segurança, implementar código ou destruir evidência.

A posição prática da Clarysec é simples: o acesso de emergência é necessário, mas o acesso de emergência não gerido é risco não gerido. A resposta correta não é “sem contas break-glass”. A resposta correta é um modelo governado de gestão de acessos privilegiados, com inventário, aprovação, limites temporais, autenticação forte, registo de sessões, revisão pós-utilização, reposição de credenciais e evidência de auditoria.

Porque o acesso privilegiado é uma questão de conformidade ao nível do conselho de administração

Em ambientes com menor maturidade, o acesso privilegiado é frequentemente tratado como uma tarefa de administração de TI. Alguém precisa de direitos de administrador, abre-se um ticket, concede-se uma função e a atividade prossegue. Esse modelo não resiste ao ransomware moderno, à infraestrutura nativa da cloud, à responsabilização da NIS2, à resiliência operacional do DORA ou ao escrutínio de violações no âmbito do GDPR da UE.

A Diretiva NIS2 coloca a governação da cibersegurança na sala do conselho. Article 20 exige que os órgãos de gestão de entidades essenciais e importantes aprovem medidas de gestão de riscos de cibersegurança, supervisionem a sua implementação e recebam formação em cibersegurança. Article 21 exige medidas técnicas, operacionais e organizacionais adequadas e proporcionadas, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, eficácia dos controlos, higiene de cibersegurança, segurança de recursos humanos, controlo de acesso, gestão de ativos e MFA ou autenticação contínua quando adequado.

Para prestadores SaaS, prestadores de serviços geridos, prestadores de segurança gerida, serviços de cloud, centros de dados e outras organizações de infraestrutura digital, a aplicabilidade da NIS2 depende do setor, dimensão, papel, impacto transfronteiriço e estabelecimento na UE. A lição operacional é direta: o controlo de acesso já não está escondido num anexo técnico. Faz parte da linha de base de higiene de cibersegurança que a gestão deve aprovar, monitorizar e corrigir.

Para entidades financeiras, o Digital Operational Resilience Act muda a linguagem, mas não o risco subjacente. O DORA aplica-se desde 17 de janeiro de 2025 e estabelece um quadro uniforme para gestão do risco das TIC, reporte de incidentes graves relacionados com TIC, testes de resiliência operacional digital e gestão do risco de terceiros de TIC. Article 5 exige mecanismos de governação e controlo para o risco das TIC, com o órgão de gestão a definir, aprovar, supervisionar e assumir responsabilidade pelos mecanismos de risco das TIC. Article 6 exige um quadro documentado de gestão do risco das TIC, com políticas, procedimentos, protocolos e ferramentas para proteger ativos de TIC. Article 17 exige um processo de gestão de incidentes relacionados com TIC que detete, registe, classifique, escale e restaure operações seguras.

O GDPR da UE acrescenta a perspetiva da privacidade e da responsabilização. Article 5(1)(f) exige que os dados pessoais sejam tratados com integridade e confidencialidade. Article 5(2) exige responsabilização. Article 25 exige Proteção de Dados desde a Conceção e por Defeito. Article 32 exige medidas técnicas e organizativas adequadas para a segurança do tratamento. Se um utilizador privilegiado consegue exportar registos de clientes, aceder a dados de categorias especiais, desativar logs de auditoria ou alterar definições de retenção sem revisão, a organização não cometeu apenas um erro de IAM. Pode ficar incapaz de demonstrar segurança adequada.

A ISO/IEC 27001:2022 é a espinha dorsal do sistema de gestão que permite tratar estas obrigações num programa integrado. Cláusula 4.2 exige que a organização compreenda as partes interessadas e os seus requisitos, incluindo obrigações legais, regulamentares e contratuais. Cláusula 5.1 exige liderança e compromisso. Cláusula 6.1.2 exige avaliação de riscos de segurança da informação. Cláusula 6.1.3 exige tratamento de riscos. Cláusula 8 exige planeamento e controlo operacional.

Para o acesso privilegiado, isto desloca a conversa de “que ferramenta PAM devemos comprar?” para “que riscos estamos a tratar, que controlos foram selecionados, quem é responsável por eles, como são operados e que evidência prova que funcionam?”

PAM não é um único controlo; é uma cadeia de evidência

Uma ferramenta PAM pode guardar palavras-passe em cofre, intermediar sessões, registar teclas premidas, rodar credenciais e aplicar acesso just-in-time. Essas capacidades são importantes. Mas, se a organização não definiu funções privilegiadas, não aprovou o acesso de emergência, não mapeou o acesso aos ativos, não reviu direitos, não protegeu logs e não formou administradores, a ferramenta torna-se um controlo parcial com fraca defensabilidade em auditoria.

A forma mais útil de governar o acesso privilegiado é pensar em resultados de controlo, não em nomes de ferramentas.

O Zenith Controls: The Cross-Compliance Guide Zenith Controls trata o controlo ISO/IEC 27002:2022 8.2, Privilégios de acesso, como o centro de gravidade da PAM. Classifica este controlo como preventivo, com suporte à confidencialidade, integridade e disponibilidade, alinhado com o conceito de cibersegurança Protect, a capacidade operacional Gestão de identidades e acessos e o domínio de segurança Proteção.

O controlo 8.2 é poderoso porque se liga aos controlos envolventes que tornam o acesso privilegiado auditável:

É por isso que um auditor raramente fica pela pergunta: “Têm um sistema PAM?” As perguntas de auditoria mais fortes são: existe um inventário de contas privilegiadas? As funções privilegiadas estão aprovadas? Os direitos são limitados no tempo? As credenciais de emergência estão protegidas? Conseguem provar quem as utilizou? Os comandos são registados em logs? Os administradores de fornecedores estão incluídos? Os direitos de acesso são revistos? As credenciais foram repostas? As exceções foram aceites com base no risco?

O mapeamento de direitos de acesso do Zenith Controls mostra isto diretamente: a gestão de direitos de acesso operacionaliza princípios de controlo de acesso como o princípio do menor privilégio, o princípio da necessidade de conhecer e a autorização, enquanto as contas privilegiadas exigem escrutínio especial e revogação imediata quando deixam de ser necessárias.

Requisitos de política para acesso break-glass fiável

Uma conta break-glass não é uma palavra-passe de administrador partilhada num envelope selado. Em 2026, esse modelo é demasiado fraco para cloud, fintech, SaaS, saúde, serviços geridos e operações digitais reguladas.

Um modelo break-glass defensável precisa de sete regras mínimas de política:

1. A conta deve estar documentada.
2. A conta deve estar aprovada.
3. A utilização deve ser atribuível de forma única sempre que tecnicamente possível.
4. A utilização deve limitar-se a emergências reais.
5. A utilização deve ser registada em logs e revista.
6. As credenciais ou fatores de autenticação devem ser repostos ou rodados após a utilização.
7. A conta deve ser testada e incluída no âmbito da auditoria.

A biblioteca de políticas da Clarysec transforma estes princípios em linguagem de governação utilizável.

A User Account and Privilege Management Policy-sme Política de Gestão de Contas de Utilizador e Privilégios - PME afirma:

“O acesso de emergência (por exemplo, contas de administrador “break glass”) deve ser claramente documentado, protegido e utilizado apenas quando absolutamente necessário.”

Da secção “Tratamento do risco e exceções”, cláusula de política 7.3.1.

A mesma política PME continua:

“Essas contas devem ser registadas em logs, revistas após a utilização e repostas após cada evento de emergência.”

Da secção “Tratamento do risco e exceções”, cláusula de política 7.3.2.

Para a elevação de privilégios no dia a dia, a política PME também exige:

“Privilégios elevados ou administrativos exigem aprovação adicional pelo Diretor-Geral ou pelo Responsável de TI e devem ser documentados, limitados no tempo e sujeitos a revisão periódica.”

Da secção “Requisitos de implementação da política”, cláusula de política 6.2.2.

Para organizações de maior dimensão, o conjunto de políticas empresariais aprofunda os requisitos. A User Account and Privilege Management Policy Política de Gestão de Contas de Utilizador e Privilégios exige que:

“As sessões privilegiadas devem ser integralmente registadas em logs, incluindo comandos emitidos e ações executadas. Os logs devem ser revistos periodicamente por revisores designados.”

Da secção “Requisitos de implementação da política”, cláusula de política 6.4.2.

A mesma política exige que contas temporárias ou de emergência com acesso privilegiado sigam um procedimento break-glass documentado na cláusula 6.2.5, enquanto a cláusula 7.4 define os requisitos desse procedimento.

A Access Control Policy Política de controlo de acesso reforça a retenção para auditoria:

“As decisões de aprovação devem ser registadas em logs e retidas para efeitos de auditoria por um período mínimo de 2 anos.”

Da secção “Requisitos de governação”, cláusula de política 5.3.2.

A Logging and Monitoring Policy-sme Política de registo em logs e monitorização - PME identifica as expectativas de registo de autenticação:

“Logs de autenticação: tentativas de autenticação bem-sucedidas e falhadas, duração das sessões, utilização de MFA”

Da secção “Requisitos de governação”, cláusula de política 5.4.2.

Em conjunto, estas cláusulas transformam o acesso de emergência de uma solução heroica de contingência num evento controlado. A conta é excecional, mas a governação não é.

A abordagem do Zenith Blueprint à implementação de PAM

O Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint trata o acesso privilegiado como um problema prático de implementação, não como uma declaração teórica de controlo. Na fase Controlos em Ação, Passo 19, Controlos Tecnológicos I, afirma:

“Em qualquer sistema de informação, o acesso privilegiado é poder e, com esse poder, vem o risco.”

Da fase Controlos em Ação, Passo 19: Controlos Tecnológicos I.

O Passo 19 exige que as organizações identifiquem contas privilegiadas em ambientes on-premises, cloud, SaaS, de desenvolvimento e de infraestrutura. Inclui administradores de domínio, utilizadores root, administradores de tenant de cloud, superutilizadores de bases de dados e controladores de pipelines de CI/CD. Também enfatiza a minimização do acesso privilegiado através de controlo de acesso baseado em funções, elevação just-in-time e fluxos de trabalho de aprovação.

Isto é importante porque muitos incidentes graves não começam com a conta break-glass formal. Começam com privilégios permanentes. Um engenheiro de cloud mantém direitos de proprietário “só para o caso”. Um administrador de bases de dados mantém acesso à produção depois de mudar de equipa. Uma conta de serviço de CI/CD tem permissões amplas entre ambientes. Uma conta de prestador de serviços geridos fica isenta de MFA porque “precisam de acesso rápido”.

O Passo 20 do Zenith Blueprint estende o mesmo raciocínio aos utilitários privilegiados. Instrui as organizações a criar ou atualizar um inventário de utilitários privilegiados, restringir a execução a administradores autorizados, verificar que a utilização é registada em logs e gera alertas, e considerar o registo de scripts, como o logging de PowerShell através de políticas de grupo. Isto é crítico porque uma conta privilegiada é muitas vezes apenas o ponto de entrada. O dano ocorre quando o atacante executa ferramentas que desativam controlos, extraem credenciais ou se movem lateralmente.

O Passo 22 formaliza o ciclo de vida do controlo de acesso. Exige aprovisionamento e desaprovisionamento estruturados, idealmente integrados com Recursos Humanos e suportados por fluxos de pedidos de acesso, com revisões de acessos trimestrais documentadas. O Passo 16 liga o ciclo de vida ao processo de saída, exigindo uma lista de verificação de cessação de colaborador utilizada conjuntamente por Recursos Humanos e TI, incluindo desativação de contas, devolução de ativos e lembretes de NDA.

O Zenith Blueprint transforma a PAM num modelo operacional conectado: identidade, Recursos Humanos, utilitários privilegiados, logging, resposta a incidentes, revisão de acessos e evidência de auditoria reforçam-se mutuamente.

Um modelo prático de governação break-glass para 2026

Um processo break-glass bem desenhado deve funcionar durante a falha. Se depender do mesmo fornecedor de identidade, plataforma de tickets e serviço de chat que estão indisponíveis durante a interrupção, é apenas teatro.

Ao mesmo tempo, o acesso de emergência não pode tornar-se um canal de contorno por conveniência. A Clarysec normalmente desenha a governação break-glass em quatro camadas: prevenção, ativação, observação e recuperação.

Para ambientes cloud, inclua administradores ao nível do tenant, contas root de cloud, administradores de emergência do fornecedor de identidade, contas de serviço privilegiadas, contas mestre de bases de dados, funções Kubernetes cluster-admin, chaves de implementação de CI/CD, administradores de cofres de segredos e contas de suporte de terceiros.

Para ambientes híbridos, inclua administradores de domínio, administradores de cópias de segurança, administradores de hipervisores, administradores de firewall, administradores de consola EDR e utilizadores de utilitários privilegiados.

Para ambientes sensíveis à privacidade, inclua administradores que possam aceder a bases de dados com dados pessoais, logs com identificadores, registos de Recursos Humanos, dados biométricos de verificação de identidade, sistemas de monitorização de fraude ou ferramentas de apoio ao cliente.

O estado-alvo é simples de descrever e difícil de simular: cada caminho de emergência é conhecido, aprovado, protegido, observável, reversível e revisto.

Um exercício de evidência break-glass de 60 minutos

Um Diretor de Segurança da Informação ou gestor de conformidade pode executar esta semana um exercício break-glass útil sem comprar uma nova ferramenta. O objetivo não é apenas confirmar que a conta funciona. O objetivo é provar que o controlo produz evidência.

Cenário

Assuma que o fornecedor de identidade principal está degradado. A elevação just-in-time normal está indisponível. Um cluster de bases de dados de produção precisa de alterações de configuração de emergência para restaurar o serviço. A conta de administrador de cloud break-glass deve ser ativada.

Passo 1: Confirmar que a conta está no inventário privilegiado

Use o Zenith Blueprint, fase Controlos em Ação, Passo 19, para validar que a conta consta do inventário de contas privilegiadas. Registe o nome e o ambiente da conta, o proprietário de negócio, o proprietário técnico, os sistemas alcançáveis, o impacto sobre dados pessoais, o método de autenticação, a localização do cofre, o método de rotação e a data do último teste.

Se a conta estiver em falta, trate isso como uma lacuna de controlo e adicione-a ao registo de riscos.

Passo 2: Verificar o alinhamento com a política

Mapeie o evento para os requisitos da User Account and Privilege Management Policy relativos a procedimentos break-glass documentados e registo de sessões privilegiadas. Se for uma PME, use as cláusulas 7.3.1 e 7.3.2 da User Account and Privilege Management Policy-sme como linha de base mínima: documentado, protegido, necessário, registado em logs, revisto e reposto.

Mapeie a retenção das aprovações para a cláusula 5.3.2 da Access Control Policy, que exige que as decisões de aprovação sejam registadas em logs e retidas por pelo menos 2 anos.

Passo 3: Abrir um registo de acesso de emergência

Crie um ticket ou registo de incidente antes da ativação ou no momento da ativação. Inclua:

• Motivo da emergência
• Serviço afetado
• Conta solicitada
• Solicitante
• Aprovador
• Hora de início
• Hora de fim prevista
• Impacto no cliente ou impacto regulamentar
• Impacto em dados pessoais no âmbito do GDPR da UE
• Indicador de acompanhamento de reporte NIS2 ou DORA

Não espere pelo fim para reconstruir a história. O valor de auditoria é mais forte quando o registo começa antes de o acesso ser utilizado.

Passo 4: Ativar e observar

Ative a conta break-glass. Confirme que é utilizada MFA ou autenticação compensatória, que a sessão é gravada, que os comandos ou ações administrativas são registados em logs, que os logs são encaminhados para registo centralizado, que a sincronização horária suporta a reconstrução da cronologia e que é gerado um alerta para a utilização da conta de emergência.

Isto alinha-se com o Zenith Controls para 8.15 Registo, que descreve o logging como a camada de dados fundamental para a monitorização e observa que os utilizadores privilegiados e a execução de utilitários privilegiados devem ser registados em logs de forma abrangente.

Passo 5: Fechar, repor e rever

Após a tarefa de emergência, desative a conta ou devolva-a ao estado selado, rode as credenciais ou reponha o fator de autenticação, reveja os logs de sessão, documente comandos e alterações de configuração, confirme que não ocorreu acesso desnecessário a dados, atualize o registo do incidente, registe lições aprendidas e decida se foram acionados limiares de notificação NIS2, DORA ou GDPR da UE.

Se foram acedidos dados pessoais, envolva o Encarregado da Proteção de Dados. Se o evento causou interrupção do serviço ou puder causar impacto material, envolva o responsável pelo reporte NIS2 ou DORA. Se a conta break-glass falhou, documente-o como uma constatação de resiliência operacional, não apenas como um problema de IAM.

Mapeamento de conformidade cruzada para PAM e controlos break-glass

O modelo de governação mais forte não duplica controlos para cada regulamento. Constrói uma cadeia de evidência única que suporta múltiplas obrigações.

O NIST CSF 2.0 é especialmente útil ao traduzir PAM para um Perfil Atual e um Perfil Alvo. O seu método de perfil começa pelo âmbito, depois recolhe políticas, prioridades de risco, registos, requisitos, práticas e papéis de trabalho, antes de criar um plano de ação priorizado. Para acesso privilegiado, isso significa delimitar o perfil em torno da segurança de identidade, administração de cloud, resiliência a ransomware, sistemas financeiros críticos ou acesso de fornecedores.

Para entidades financeiras abrangidas pelo DORA, o DORA funciona como o regime setorial específico de ciber-resiliência da UE para obrigações equivalentes de risco e incidentes da NIS2. Isto não torna a NIS2 irrelevante. Significa que a entidade financeira deve usar o DORA como regime orientador para os requisitos de risco das TIC e incidentes, mantendo coordenação com estratégias nacionais de cibersegurança, autoridades competentes e CSIRTs quando aplicável.

Como os auditores testam a evidência de acesso privilegiado

Os auditores não avaliam a PAM apenas pela leitura da política. Triangulam política, configuração, logs, tickets, entrevistas e prática observada.

A metodologia de auditoria do Zenith Controls para privilégios de acesso referencia as práticas de auditoria da ISO/IEC 19011:2018. Os auditores revêm políticas que definem direitos elevados, procedimentos de aprovisionamento, monitorização e revogação. Examinam inventários de contas de utilizador, registos de atribuição de privilégios e logs. Corroboram a evidência através de entrevistas, ferramentas PAM, serviços de diretório e amostras de logs.

Para direitos de acesso, o Zenith Controls observa que os auditores amostram pedidos de acesso de utilizadores, verificam aprovações documentadas e confirmam que a TI concedeu apenas o acesso aprovado. Também comparam funções de utilizador com direitos efetivos, verificando se o princípio do menor privilégio é aplicado. Para logging, os auditores inspecionam o âmbito do registo, tipos de eventos, períodos de retenção, proteções e entradas reais de logs. Avaliam se autenticações falhadas, acesso a dados sensíveis e alterações de configuração são capturados e revistos.

Um bom pacote de evidência break-glass inclui:

• Pedido de acesso de emergência aprovado
• Contexto do incidente ou indisponibilidade
• Identidade do utilizador que ativou o acesso
• Identidade do aprovador
• Hora de início e fim
• Evidência de MFA ou autenticação
• Gravação de sessão ou log de comandos
• Logs de sistema e alerta SIEM
• Alterações efetuadas
• Confirmação de reposição da credencial
• Revisão pós-utilização
• Avaliação de acesso a dados
• Avaliação de notificação regulamentar
• Ações corretivas se algo falhou

Se o seu exercício não consegue produzir este pacote, o controlo não está preparado para auditoria.

A falha oculta: acesso privilegiado de terceiros

Muitas organizações governam melhor os administradores internos do que os administradores de fornecedores. Para ambientes cloud, SaaS, fintech e de serviços geridos, isso está invertido.

NIS2 Article 21 inclui segurança da cadeia de fornecimento e relações com fornecedores diretos e prestadores de serviços. DORA Articles 28 a 30 vão mais longe para entidades financeiras, exigindo estratégia de risco de terceiros de TIC, registos de contratos de serviços de TIC, diligência prévia, avaliação do risco de concentração, direitos de auditoria, direitos de cessação, estratégias de saída e medidas de segurança contratuais.

O acesso privilegiado de fornecedores deve estar no âmbito da PAM se o fornecedor puder administrar produção, suportar funções críticas ou importantes, aceder a dados pessoais, modificar configurações de segurança, gerir cópias de segurança, implementar código ou operar ferramentas de monitorização.

A Clarysec normalmente espera que os controlos de acesso privilegiado de fornecedores incluam:

• Utilizadores nominativos do fornecedor, não contas partilhadas do fornecedor
• Requisitos contratuais de segurança para acesso privilegiado
• MFA e acesso remoto seguro
• Janelas de acesso limitadas no tempo
• Aprovação do cliente para acesso de emergência
• Registo de sessões ou trilhos de auditoria equivalentes
• Revogação imediata quando há alteração de pessoal
• Obrigações de cooperação em incidentes
• Retenção de evidência alinhada com as necessidades de auditoria do cliente
• Plano de saída para remoção do acesso do fornecedor

Os resultados de cadeia de fornecimento do NIST CSF 2.0 alinham-se fortemente aqui. Exigem papéis e responsabilidades de fornecedores, priorização de fornecedores por criticidade, requisitos em contratos, diligência prévia, monitorização contínua, envolvimento de fornecedores no planeamento de incidentes e planos de risco pós-contrato.

Se uma conta de prestador de serviços geridos está isenta do seu fluxo interno de PAM, isso não é conveniência. É uma exceção de alto risco que pertence ao registo de riscos, ao registo centralizado de fornecedores e à revisão de acessos.

Constatações comuns de PAM e break-glass em 2026

Nos trabalhos da Clarysec, as constatações raramente são surpreendentes. Normalmente são combinações de boas intenções, pressão operacional e evidência incompleta.

As constatações mais comuns são:

• Existem contas break-glass, mas não estão listadas no inventário de contas privilegiadas.
• As contas de emergência estão excluídas das revisões de acessos normais.
• A organização não consegue provar quem utilizou uma conta de emergência.
• A conta não foi reposta após a utilização.
• As sessões privilegiadas são registadas em logs, mas os comandos não.
• Os logs existem localmente, mas não estão protegidos contra utilizadores privilegiados.
• As contas root de cloud não são testadas.
• Os processos de recuperação de MFA não estão documentados.
• O acesso privilegiado para pipelines de CI/CD e contas de serviço é ignorado.
• O acesso de suporte de terceiros contorna a aprovação interna.
• A aprovação de acesso existe em mensagens de chat, mas não é retida como evidência de auditoria.
• O processo de saída remove correio eletrónico e VPN, mas não direitos de administrador SaaS.
• O Encarregado da Proteção de Dados não é envolvido quando o acesso privilegiado pode expor dados pessoais.
• Os playbooks de incidentes não incluem pontos de decisão de notificação NIS2, DORA ou GDPR da UE.

Cada constatação pode ser tratada através do tratamento de riscos da ISO/IEC 27001:2022. Identifique o risco, atribua um proprietário, selecione controlos, atualize a Declaração de Aplicabilidade, implemente o plano de tratamento de riscos e retenha evidência documentada. Esse é o poder de usar um SGSI em vez de um conjunto disperso de tarefas de segurança.

Como se apresenta uma boa prática

Um modelo operacional maduro de PAM e break-glass tem cinco rotinas recorrentes.

Primeiro, inventariar o acesso privilegiado mensalmente ou de forma contínua. Inclua administradores humanos, contas de serviço, contas de emergência, funções cloud, identidades de CI/CD, utilizadores de bases de dados, utilitários privilegiados e administradores terceiros.

Segundo, aplicar o princípio do menor privilégio através de funções, elevação just-in-time e aprovações. Privilégios permanentes devem ser raros, justificados e revistos com maior frequência do que o acesso de utilizador padrão.

Terceiro, monitorizar o comportamento privilegiado. Registe em logs autenticação, duração das sessões, utilização de MFA, comandos, alterações de configuração, exportações de dados, tentativas falhadas, elevação de privilégios e execução de utilitários privilegiados.

Quarto, testar contas break-glass antes da emergência. Uma conta break-glass que nunca foi testada é uma suposição, não um controlo.

Quinto, reportar à gestão. Tanto a NIS2 como o DORA elevam a cibersegurança e o risco das TIC à responsabilidade do órgão de gestão. O conselho de administração não precisa de todos os logs de comandos, mas precisa de métricas: número de contas privilegiadas, revisões em atraso, ativações de emergência, contas administrativas de fornecedores, testes falhados, exceções críticas e estado da remediação.

É aqui que o conjunto de ferramentas da Clarysec se torna prático. A biblioteca de políticas fornece a linguagem de governação. O Zenith Blueprint fornece a sequência de implementação. O Zenith Controls fornece o mapeamento de conformidade cruzada, as relações entre controlos, as normas de suporte e a metodologia de auditoria.

Próximos passos: transformar o acesso de emergência em resiliência preparada para auditoria

Se a sua organização não testou o acesso break-glass nos últimos 90 dias, comece por aí. Não comece por um workshop de seleção de ferramentas. Comece pela evidência.

1. Crie ou atualize o seu inventário de contas privilegiadas.
2. Identifique todas as contas break-glass e todos os caminhos de administração de emergência.
3. Mapeie cada conta para o proprietário de negócio, o proprietário do sistema e o impacto nos dados.
4. Confirme a cobertura da política com a User Account and Privilege Management Policy Política de Gestão de Contas de Utilizador e Privilégios da Clarysec ou a User Account and Privilege Management Policy-sme Política de Gestão de Contas de Utilizador e Privilégios - PME.
5. Use o Zenith Blueprint Zenith Blueprint, fase Controlos em Ação, Passos 19, 20, 22 e 16, para ligar acesso privilegiado, utilitários privilegiados, revisões de ciclo de vida e processo de saída.
6. Use o Zenith Controls Zenith Controls para mapear os controlos ISO/IEC 27002:2022 8.2, 5.18 e 8.15 para as expectativas de evidência da NIS2, DORA, GDPR da UE e NIST.
7. Execute um exercício de evidência break-glass e registe os resultados.
8. Adicione lacunas ao plano de tratamento de riscos e acompanhe a remediação até ao encerramento.

O acesso privilegiado é poder. O acesso break-glass é poder de emergência. Em 2026, as organizações que recuperarem de forma controlada de ransomware, indisponibilidades de cloud e falhas de identidade serão as que conseguirem provar que o acesso de emergência foi controlado antes, durante e depois da crise.

A Clarysec pode ajudá-lo a construir essa prova, da política ao mapeamento de controlos e à evidência preparada para auditoria. Comece pelo Zenith Blueprint, combine-o com a User Account and Privilege Management Policy e a Access Control Policy, e depois use o Zenith Controls para mostrar como o seu programa PAM suporta ISO/IEC 27001:2022, NIS2, DORA, GDPR da UE, NIST CSF 2.0 e COBIT 2019.