Guia de evidência de auditoria para controlo de acesso ISO 27001
São 09:10 no dia da auditoria. Maria, CISO de uma fintech e plataforma em cloud em rápido crescimento, tem a política de controlo de acesso aberta. O responsável de TI está a exportar as definições de acesso condicional do fornecedor de identidade. Recursos Humanos procura o ticket de cessação de um analista financeiro que saiu há seis semanas. O auditor interno levanta o olhar e faz a pergunta que todos sabiam que iria chegar:
“Mostre-me como o acesso é solicitado, aprovado, aplicado, revisto e removido para um utilizador com acesso privilegiado a dados pessoais.”
Essa única frase pode revelar se um programa de controlo de acesso está preparado para auditoria ou apenas documentado em política.
A equipa de Maria tinha um Sistema de Gestão de Segurança da Informação maduro, um ciclo anual de recertificação ISO/IEC 27001:2022, autenticação multifator implementada, controlos de acesso baseados em funções nos sistemas centrais e folhas de cálculo trimestrais de revisão de acessos. Mas esta auditoria era diferente. A lista de pedidos do auditor incluía preparação para requisitos regulamentares emergentes. Para a organização de Maria, isso significava NIS2, DORA e RGPD da UE, todos analisados pela mesma ótica operacional: identidade, acesso, autenticação, privilégio e evidência.
O problema que muitos CISO enfrentam não é a inexistência de controlo de acesso. O problema é que a evidência existe de forma fragmentada. As aprovações de integração estão no Jira ou no ServiceNow. As definições de MFA estão no Microsoft Entra ID, no Okta ou noutro fornecedor de identidade. As permissões da AWS, Azure e Google Cloud estão em consolas separadas. As ações privilegiadas podem estar registadas numa ferramenta de PAM, ou podem não estar registadas de todo. O estado contratual está no BambooHR, Workday ou em folhas de cálculo. As revisões de acessos podem estar aprovadas por correio eletrónico.
Quando um auditor cruza IAM, MFA, PAM, eventos de admissão, alteração de função e cessação, dados pessoais, administração de cloud e expectativas regulamentares, a evidência fragmentada desagrega-se rapidamente.
As auditorias de controlo de acesso ISO/IEC 27001:2022 não são apenas revisões de configuração técnica. São testes ao sistema de gestão. Examinam se os riscos de identidade e acesso são compreendidos, tratados, implementados, monitorizados e melhorados. Quando NIS2, DORA e RGPD da UE também são relevantes, a mesma evidência deve demonstrar governação de acessos baseada no risco, autenticação robusta, aprovações rastreáveis, revogação atempada, restrição de privilégios, proteção de dados pessoais e responsabilização da gestão.
A resposta prática não é um dossier maior. É um modelo único de evidência de controlo de acesso que começa no âmbito do SGSI e no risco, passa pela política e pela conceção dos controlos, chega às ferramentas de IAM e PAM e mapeia de forma clara para ISO/IEC 27001:2022, NIS2, DORA, RGPD da UE, NIST e COBIT.
Porque o controlo de acesso é o eixo regulamentar
O controlo de acesso tornou-se um tema de nível executivo e relevante para reguladores porque o comprometimento de identidades é hoje um caminho comum para interrupção operacional, violação de dados, fraude e exposição da cadeia de fornecimento.
Nos termos da NIS2, os Articles 2 e 3, lidos em conjunto com o Anexo I e o Anexo II, colocam muitas entidades de média e grande dimensão, em setores listados, no âmbito de aplicação como entidades essenciais ou importantes. Isto inclui prestadores de infraestrutura digital e de gestão de serviços de TIC, como prestadores de serviços de computação em cloud, prestadores de serviços de centro de dados, prestadores de serviços geridos e prestadores de serviços de segurança geridos. Os Estados-Membros tinham de transpor a NIS2 até outubro de 2024 e aplicar medidas nacionais a partir de outubro de 2024, com listas de entidades previstas para abril de 2025. O Article 20 responsabiliza os órgãos de gestão pela aprovação das medidas de gestão de riscos de cibersegurança e pela supervisão da sua implementação. O Article 21 exige medidas técnicas, operacionais e organizativas, incluindo políticas de controlo de acesso, gestão de ativos, higiene de cibersegurança, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento e MFA ou autenticação contínua quando adequado.
A DORA acrescenta uma camada setorial de resiliência operacional para entidades financeiras e prestadores terceiros relevantes de serviços de TIC. Os Articles 1, 2 e 64 estabelecem a DORA como um quadro uniforme aplicável a partir de 17 de janeiro de 2025. Os Articles 5 e 6 exigem governação e um quadro documentado de gestão do risco das TIC. O Article 9 aborda proteção e prevenção, incluindo políticas, procedimentos, protocolos e ferramentas de segurança das TIC. Os Articles 24 a 30 acrescentam testes de resiliência operacional digital e gestão de riscos de terceiros de TIC. Para as entidades financeiras, a evidência de controlo de acesso torna-se evidência de resiliência, e não apenas evidência de administração de TI.
O RGPD da UE introduz a ótica dos dados pessoais. Os Articles 2 e 3 definem uma aplicabilidade ampla ao tratamento na UE e ao alcance do mercado da UE. O Article 5 exige integridade, confidencialidade e responsabilização demonstrável. O Article 25 exige proteção de dados desde a conceção e por defeito. O Article 32 exige medidas técnicas e organizativas adequadas. Na prática, isto significa acesso controlado, autenticação segura, registo, revisão e remoção atempada para sistemas que tratam dados pessoais.
A ISO/IEC 27001:2022 fornece às organizações o motor de sistema de gestão para unificar estas obrigações. As cláusulas 4.1 a 4.3 exigem que a organização compreenda o contexto, as partes interessadas, os requisitos legais e contratuais, as interfaces, as dependências e o âmbito do SGSI. As cláusulas 6.1.1 a 6.1.3 exigem avaliação de riscos de segurança da informação, tratamento, comparação com o Anexo A, uma Declaração de Aplicabilidade e aprovação dos planos de tratamento e do risco residual. A cláusula 8.1 exige controlo operacional, informação documentada que demonstre que os processos ocorreram conforme planeado, controlo de alterações e controlo sobre processos fornecidos externamente.
A pergunta de auditoria, portanto, não é “Têm MFA?” É “Conseguem provar, para identidades e sistemas dentro do âmbito, que o risco de acesso é governado, tratado, implementado, monitorizado e melhorado?”
Construir a espinha dorsal da evidência desde o âmbito do SGSI até à prova de IAM
A Clarysec inicia a preparação da auditoria de controlo de acesso tornando a evidência rastreável a partir do contexto de negócio. A ISO/IEC 27001:2022 espera que o SGSI esteja integrado nos processos organizacionais e dimensionado às necessidades da organização. Um fornecedor SaaS com 30 pessoas e um banco multinacional não terão a mesma arquitetura de acesso, mas ambos precisam de uma cadeia de evidência coerente.
| Camada de evidência | O que comprova | Sistemas de origem típicos | Valor para conformidade cruzada |
|---|---|---|---|
| Âmbito do SGSI e requisitos das partes interessadas | Que sistemas, dados, regulamentos e dependências de terceiros estão no âmbito | Âmbito do SGSI, registo de conformidade, inventário de dados, registo centralizado de fornecedores | Apoia as cláusulas 4.2 e 4.3 da ISO/IEC 27001:2022, a definição de âmbito NIS2, o mapeamento de dependências de TIC DORA e a responsabilização RGPD da UE |
| Avaliação de riscos de acesso | Porque são necessários IAM, MFA, PAM e revisões com base no risco | Registo de riscos, cenários de ameaça, plano de tratamento | Apoia a cláusula 6.1 da ISO/IEC 27001:2022, ISO/IEC 27005:2022, o quadro de risco das TIC DORA e as medidas de risco NIS2 |
| Políticas e normas | O que a organização exige | Política de controlo de acesso, política de privilégios, política de admissão e cessação | Converte expectativas regulamentares em regras internas aplicáveis |
| Configuração de IAM e PAM | Se os controlos estão tecnicamente implementados | IdP, Sistema de Informação de Recursos Humanos (SIRH), ITSM, PAM, IAM de cloud, consolas administrativas SaaS | Demonstra princípio do menor privilégio, MFA, RBAC, fluxos de trabalho de aprovação e controlos de sessões privilegiadas |
| Registos de revisão e monitorização | Se o acesso continua adequado ao longo do tempo | Campanhas de revisão de acessos, SIEM, logs de PAM, atestados de gestores | Demonstra operação contínua dos controlos, monitorização DORA, higiene de cibersegurança NIS2 e minimização RGPD da UE |
| Registos de cessação e exceções | Se o acesso é removido e as exceções são controladas | Lista de cessações de Recursos Humanos, logs de desativação, registo de exceções | Demonstra revogação atempada, aceitação do risco residual e prevenção de violações |
A ISO/IEC 27005:2022 é útil porque recomenda consolidar requisitos legais, regulamentares, contratuais, setoriais e internos num contexto de risco comum. As cláusulas 6.4 e 6.5 destacam critérios de risco que consideram objetivos organizacionais, leis, relações com fornecedores e restrições. As cláusulas 7.1 e 7.2 permitem cenários baseados em eventos e em ativos. Para o controlo de acesso, isto significa avaliar cenários estratégicos como “administrador SaaS privilegiado exporta dados de clientes da UE” em paralelo com cenários de ativos como “chave AWS IAM órfã associada a armazenamento de produção”.
No Zenith Blueprint: roteiro de 30 passos para auditores da Clarysec, esta espinha dorsal de evidência é construída durante a fase Controlos em ação. O passo 19 centra-se nos controlos tecnológicos para gestão de endpoints e de acessos, enquanto o passo 22 formaliza o ciclo de vida organizacional dos acessos.
O Zenith Blueprint orienta as equipas a verificar se o provisionamento e o desprovisionamento são estruturados, integrados com Recursos Humanos sempre que possível, suportados por fluxos de trabalho de pedidos de acesso e revistos trimestralmente. Também instrui as organizações a documentar tipos de identidade, aplicar controlos a identidades individuais, partilhadas e de serviço, aplicar políticas robustas de palavras-passe e MFA, eliminar contas inativas e manter um cofre seguro ou documentação segura para credenciais de serviço.
É exatamente assim que os auditores testam o controlo de acesso: uma identidade, um sistema, uma aprovação, um privilégio, uma revisão e uma revogação de cada vez.
O que recolher para evidência de controlo de acesso pronta para auditoria
O pacote de evidência de controlo de acesso deve permitir que um auditor selecione qualquer utilizador por amostragem e rastreie o ciclo de vida: pedido, aprovação, atribuição, autenticação, elevação privilegiada, monitorização, revisão e revogação.
Um pacote de evidência robusto inclui:
- Política de controlo de acesso e política de contas de utilizador
- Procedimento de admissão, alteração de função e cessação
- Matriz de funções ou matriz de controlo de acesso
- Lista de aplicações, plataformas e repositórios de dados dentro do âmbito
- Configuração de MFA do fornecedor de identidade
- Políticas de acesso condicional e lista de exceções
- Inventário de contas privilegiadas
- Evidência de fluxo de trabalho de PAM, incluindo aprovações e logs de sessões
- Resultado recente de campanha de revisão de acessos
- Amostras de atestados de gestores e ações de remediação
- Relatório de cessação de Recursos Humanos reconciliado com logs de desativação
- Inventário de contas de serviço, proprietários, registos de rotação e evidência de cofre
- Procedimento de conta de emergência (break-glass) e log de teste
- Evidência de incidentes ou alertas envolvendo autenticações falhadas, elevação de privilégios ou contas inativas
- Entradas da Declaração de Aplicabilidade para controlos do Anexo A relacionados com acesso
As políticas da Clarysec tornam esta expectativa explícita. Na Política de controlo de acesso para PME, o requisito é simples e focado na auditoria:
“Deve ser mantido um registo seguro de todo o provisionamento, modificação e remoção de acessos.”
Da secção “Requisitos de implementação da política”, cláusula 6.1.1.
A mesma política para PME também liga diretamente RBAC e MFA às responsabilidades da função:
“Implementa controlos de acesso baseados em funções (RBAC) e aplica autenticação forte (por exemplo, autenticação multifator (MFA)).”
Da secção “Papéis e responsabilidades”, cláusula 4.2.3.
Para organizações de maior dimensão, a Política de Admissão e Cessação empresarial exige que o sistema IAM registe a criação de contas, atribuições de funções e permissões e eventos de desativação, suporte modelos de acesso baseados em funções e se integre com sistemas de Recursos Humanos para desencadeadores de admissão, alteração de função e cessação. Essa cláusula ajuda a contar a história de auditoria num só lugar: integração normalizada, ciclo de vida da identidade desencadeado por Recursos Humanos e eventos IAM rastreáveis.
Mapear IAM, MFA, PAM e revisões para os controlos ISO/IEC 27001:2022
O Zenith Controls: guia de conformidade cruzada da Clarysec trata o controlo de acesso como uma família de controlos conectada, não como um item de lista de verificação. Para ISO/IEC 27001:2022, os controlos mais relevantes incluem:
- Control 5.15, Controlo de acesso
- Control 5.16, Gestão de identidades
- Control 5.17, Informação de autenticação
- Control 5.18, Direitos de acesso
- Control 8.2, Direitos de acesso privilegiado
- Control 8.3, Restrição de acesso à informação
- Control 8.5, Autenticação segura
- Control 8.15, Registo
- Control 8.16, Atividades de monitorização
Para Informação de autenticação, o Zenith Controls mapeia o control 5.17 como um controlo preventivo que apoia a confidencialidade, a integridade e a disponibilidade, com a capacidade operacional de Gestão de Identidades e Acessos. Liga-se diretamente à gestão de identidades, autenticação segura, papéis e responsabilidades, utilização aceitável e cumprimento das políticas. A segurança das credenciais inclui ciclo de vida dos autenticadores, emissão segura, armazenamento, reposição, revogação, tokens MFA, chaves privadas e credenciais de serviço.
Para Direitos de acesso, o Zenith Controls mapeia o control 5.18 para concessão, revisão, modificação e revogação formais. Liga-se ao controlo de acesso, gestão de identidades, segregação de funções, direitos de acesso privilegiado e monitorização da conformidade. Este é o controlo que transforma o princípio do menor privilégio em evidência.
Para Direitos de acesso privilegiado, o Zenith Controls mapeia o control 8.2 para o risco específico das contas elevadas, incluindo administradores de domínio, utilizadores root, administradores de tenant de cloud, superutilizadores de bases de dados e controladores de CI/CD. O guia liga o acesso privilegiado à gestão de identidades, direitos de acesso, restrição de acesso à informação, autenticação segura, trabalho remoto, registo e monitorização.
| Tópico de auditoria | Evidência de acesso ISO/IEC 27001:2022 | Mapeamento NIS2 | Mapeamento DORA | Mapeamento RGPD da UE |
|---|---|---|---|---|
| Ciclo de vida IAM | Fluxo de admissão, alteração de função e cessação, pedidos de acesso, aprovações, modelos de função, logs de desativação | Medidas de gestão de riscos do Article 21, políticas de controlo de acesso e gestão de ativos | Articles 5, 6 e 9 sobre governação, quadro de risco das TIC, segurança lógica e controlo de acesso | Articles 5, 25 e 32 sobre responsabilização, minimização e segurança |
| MFA | Política do IdP, capturas de ecrã de acesso condicional, estatísticas de inscrição em MFA, aprovações de exceções | Article 21(2)(j) MFA ou autenticação contínua quando adequado | Acesso seguro a sistemas críticos de TIC e controlos de risco das TIC | Medidas técnicas adequadas contra acesso não autorizado |
| PAM | Inventário de contas privilegiadas, aprovações, elevação JIT, logs de sessões, rotação em cofre | Article 21(2)(i) controlo de acesso baseado no risco e gestão de ativos | Proteção de sistemas de TIC, resiliência operacional e monitorização | Restrição e auditoria de acesso elevado a dados pessoais |
| Revisões de acessos | Registos de revisão trimestrais ou semestrais, atestados de gestores, tickets de remediação | Higiene de cibersegurança, políticas de controlo de acesso e gestão de ativos | Monitorização contínua, acesso baseado em funções e processos de revogação | Proteção de dados por defeito e responsabilização demonstrável |
| Cessação | Lista de cessações de Recursos Humanos, evidência de bloqueio ou eliminação de contas, revogação de tokens | Remoção atempada de acesso desnecessário | Controlo do acesso às TIC ao longo de todo o ciclo de vida | Prevenção de acesso não autorizado a dados pessoais |
Um único relatório de revisão de acessos bem concebido pode apoiar ISO/IEC 27001:2022, NIS2, DORA e RGPD da UE se incluir âmbito, proprietário do sistema, revisor, lista de contas, justificação da função, indicador de privilégio, decisões, remoções, exceções e data de conclusão.
A evidência de MFA é mais do que uma captura de ecrã
Um erro comum em auditoria é apresentar uma captura de ecrã que diz “MFA ativada”. Os auditores precisam de mais do que isso. Precisam de saber onde a MFA se aplica, quem está excluído, como as exceções são aprovadas, se as contas privilegiadas estão cobertas e se a configuração técnica corresponde à política.
A partir do Zenith Blueprint, fase Controlos em ação, passo 19, os auditores perguntarão como são aplicadas as políticas de palavras-passe e MFA, que sistemas estão protegidos, a quem se aplica a MFA e se aplicações críticas podem ser testadas com uma conta de amostra. A evidência pode incluir configuração do IdP, políticas de acesso condicional, estatísticas de inscrição em MFA e procedimentos de reposição de palavras-passe.
Para ambientes empresariais, a Política de Gestão de Contas de Utilizador e Privilégios da Clarysec estabelece:
“Sempre que tecnicamente viável, a autenticação multifator (MFA) é obrigatória para: 6.3.2.1 Contas administrativas e de nível root 6.3.2.2 Acesso remoto (VPN, plataformas cloud) 6.3.2.3 Acesso a dados sensíveis ou regulados”
Da secção “Requisitos de implementação da política”, cláusula 6.3.2.
Isto cria uma ponte direta para auditoria. Se a MFA é obrigatória para contas administrativas, acesso remoto e dados regulados, o pacote de evidência deve incluir listas de contas administrativas e de nível root, configuração de acesso remoto, políticas de acesso condicional de plataformas cloud, listas de aplicações com dados sensíveis, relatórios de inscrição em MFA, aprovações de exceções, controlos compensatórios e evidência recente de revisão de alertas para autenticações falhadas ou tentativas de contorno da MFA.
Para NIST SP 800-53 Rev. 5, isto alinha com IA-2 Identification and Authentication, IA-5 Authenticator Management, AC-17 Remote Access e AU-2 Event Logging. Para COBIT 2019, apoia DSS05.04 Manage user identity and logical access e práticas relacionadas de monitorização de segurança.
Normas ISO de suporte alargam a perspetiva. A ISO/IEC 27018:2020 estende as expectativas de autenticação para cloud pública que trata dados pessoais. A ISO/IEC 24760-1:2019 apoia a associação de autenticadores e a gestão do ciclo de vida. A ISO/IEC 29115:2013 introduz níveis de garantia de autenticação, úteis para decidir onde são necessários tokens de hardware ou MFA resistente a phishing. A ISO/IEC 27033-1:2015 apoia autenticação de rede forte para acesso remoto ou entre redes.
A evidência de PAM é o caminho mais rápido para uma constatação grave ou para uma auditoria sem constatações
O acesso privilegiado é onde os auditores se tornam mais céticos, porque as contas privilegiadas podem contornar controlos, extrair dados, criar persistência e alterar logs. No Zenith Blueprint, o passo 19 afirma:
“Em qualquer sistema de informação, o acesso privilegiado é poder , e esse poder traz risco.”
A orientação centra-se em quem tem acesso privilegiado, o que esse acesso permite, como é gerido e como é monitorizado ao longo do tempo. Recomenda um inventário atualizado, princípio do menor privilégio, RBAC, elevação baseada no tempo ou just-in-time, fluxos de trabalho de aprovação, contas nominativas únicas, evitação de contas partilhadas, registo de conta de emergência, sistemas PAM, rotação de credenciais, cofre, gravação de sessões, elevação temporária, monitorização e revisão regular.
A Política de controlo de acesso empresarial da Clarysec transforma isto num requisito de controlo:
“O acesso administrativo deve ser rigorosamente controlado através de: 5.4.1.1 Contas privilegiadas separadas 5.4.1.2 Monitorização e gravação de sessões 5.4.1.3 Autenticação multifator 5.4.1.4 Elevação temporária de privilégios ou desencadeada por fluxo de trabalho”
Da secção “Requisitos de governação”, cláusula 5.4.1.
Esta citação é quase um guião de teste de auditoria. Se a política diz contas administrativas separadas, apresente a lista de contas privilegiadas e prove que cada uma corresponde a uma pessoa nominativa. Se diz monitorização de sessões, apresente sessões gravadas ou logs de PAM. Se diz MFA, apresente a aplicação em todos os caminhos de acesso privilegiado. Se diz elevação temporária de privilégios, apresente carimbos temporais de expiração e tickets de aprovação.
A versão para PME é igualmente direta. A Política de Gestão de Contas de Utilizador e Privilégios para PME estabelece:
“Privilégios elevados ou administrativos exigem aprovação adicional pelo Diretor-Geral ou 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 6.2.2.
Para organizações mais pequenas, isto é muitas vezes a diferença entre “confiamos no nosso administrador” e “controlamos o risco privilegiado”. O auditor não exige ferramentas empresariais em todas as PME, mas exige evidência proporcional ao risco. Um ticket, uma aprovação, uma atribuição temporária a grupo, aplicação de MFA e um registo de revisão podem ser suficientes quando o âmbito é limitado e o risco é menor.
As revisões de acessos provam que o princípio do menor privilégio está operacional
As revisões de acessos mostram se as permissões se acumulam silenciosamente. Também mostram se os gestores compreendem o acesso que as suas equipas efetivamente detêm.
A Política de Gestão de Contas de Utilizador e Privilégios empresarial exige:
“Devem ser realizadas revisões trimestrais de todas as contas de utilizador e respetivos privilégios pela Segurança de TI em colaboração com os gestores de departamento.”
Da secção “Requisitos de implementação da política”, cláusula 6.5.1.
Para PME, a Política de Gestão de Contas de Utilizador e Privilégios para PME define uma cadência proporcional:
“Deve ser realizada uma revisão de todas as contas de utilizador e privilégios a cada seis meses.”
Da secção “Requisitos de implementação da política”, cláusula 6.4.1.
Uma revisão de acessos credível inclui nome do sistema, âmbito, nome do revisor, data de exportação, data de revisão, proprietário da identidade, departamento, gestor, estado contratual, função ou direito, indicador de privilégio, indicador de sensibilidade dos dados, decisão, ticket de remediação, data de encerramento, proprietário da exceção e data de expiração da exceção.
No Zenith Controls, os direitos de acesso 5.18 são o ponto onde isto se transforma em evidência de conformidade cruzada. O guia mapeia os direitos de acesso para o GDPR Article 25 porque o acesso deve ser limitado desde a conceção e por defeito. Mapeia para o NIS2 Article 21(2)(i) porque as políticas de controlo de acesso e a gestão de ativos exigem atribuição baseada no risco, remoção atempada de acesso desnecessário e revogação formal. Mapeia para a DORA porque os sistemas financeiros de TIC precisam de acesso baseado em funções, monitorização e processos de revogação.
Auditores orientados para NIST testam frequentemente isto através de AC-2 Account Management, AC-5 Separation of Duties e AC-6 Least Privilege. Auditores COBIT 2019 procuram DSS05.04 Manage user identity and logical access e DSS06.03 Manage roles, responsibilities, access privileges and levels of authority. Auditores ISACA ITAF concentram-se em saber se a evidência é suficiente, fiável e completa.
Cessação e revogação de tokens são fáceis de testar por amostragem
Os colaboradores cessantes são um dos pontos mais fáceis para provar se o ciclo de vida funciona. Os auditores selecionam frequentemente um trabalhador recentemente desligado e pedem o registo de cessação de Recursos Humanos, o ticket, o log de desativação da conta, evidência de desativação em SaaS, remoção da VPN, revogação de MFA, remoção de tokens de API e devolução de ativos.
Na Política de Admissão e Cessação para PME, a Clarysec estabelece:
“As contas cessadas devem ser bloqueadas ou eliminadas, e os tokens de acesso associados devem ser revogados, incluindo acesso remoto (VPN), associações a aplicações MFA e tokens de API.”
Da secção “Requisitos de implementação da política”, cláusula 6.3.3.
Isto é importante porque o acesso moderno não é apenas um nome de utilizador e uma palavra-passe. O acesso pode persistir através de refresh tokens, chaves de API, chaves SSH, concessões OAuth, contas de serviço, direitos de administrador local, sessões móveis e portais de terceiros. Um registo de Recursos Humanos desativado sem revogação de tokens é evidência incompleta.
O Zenith Blueprint, fase Controlos em ação, passo 16, orienta as organizações a estarem preparadas com uma lista de verificação de cessação documentada, evidência de um colaborador recentemente desligado, um log de desativação de conta de utilizador proveniente de AD ou MDM, um formulário de devolução de ativos assinado e documentação de saída que inclua obrigações de confidencialidade.
O auditor de Maria pediu um programador sénior cessante que tinha acesso privilegiado a bases de dados de produção. A equipa apresentou a Política de Admissão e Cessação para PME, a lista de verificação de cessação construída a partir do passo 16 do Zenith Blueprint, o ticket ITSM desencadeado por Recursos Humanos, o log de desativação do diretório, a revogação do certificado VPN, a remoção da organização GitHub, a eliminação da chave AWS IAM e o ticket de verificação fechado e assinado pelo Responsável de TI. A evidência estava completa, era atempada e estava diretamente ligada à política.
Execute um sprint de evidência com três amostras antes do auditor
Um exercício prático de preparação é escolher três amostras antes da auditoria:
- Um novo colaborador admitido nos últimos 90 dias
- Um utilizador privilegiado com acesso administrativo a cloud, base de dados, produção ou IAM
- Um colaborador cessante ou com mudança de função nos últimos 90 dias
| Amostra | Evidência a recolher | Condição de aprovação | Constatação comum |
|---|---|---|---|
| Novo colaborador | Registo de início de Recursos Humanos, pedido de acesso, aprovação, atribuição de função, inscrição em MFA, primeira autenticação | Acesso concedido apenas após aprovação e alinhado com a função | Acesso concedido antes da aprovação ou função demasiado ampla |
| Utilizador privilegiado | Justificação de negócio, conta administrativa separada, prova de MFA, aprovação PAM, log de sessão, revisão trimestral | O privilégio é nominativo, justificado, limitado no tempo quando possível, monitorizado e revisto | Conta administrativa partilhada, MFA em falta, ausência de evidência de sessão |
| Cessante ou movimentado | Evento de Recursos Humanos, ticket de cessação ou mudança de função, logs de desativação, remoção de VPN, revogação de token MFA ou API, encerramento da revisão | Acesso removido de forma célere e completa | Conta SaaS ainda ativa, token de API não revogado, pertença antiga a grupo mantida |
Depois, ligue cada amostra aos registos do SGSI: cenário de risco, decisão de tratamento, seleção de controlos na Declaração de Aplicabilidade, cláusula da política, configuração técnica, registo de revisão e ação corretiva se existir alguma lacuna.
Isto transforma a preparação de auditoria de recolha documental em verificação de controlos.
Prepare-se para diferentes perspetivas de auditoria
Diferentes experiências de auditoria geram perguntas diferentes, mesmo quando a evidência é a mesma.
| Perspetiva do auditor | Foco principal | Evidência esperada |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Processo do SGSI, tratamento do risco e operação dos controlos | Avaliação de riscos, SoA, políticas aprovadas, pedidos de acesso, registos de revisão, logs de desativação |
| Prática de auditoria ISO/IEC 19011:2018 | Amostragem, corroboração e consistência | Definições de palavras-passe, limiares de bloqueio, carimbos temporais de aprovação, registos de execução, entrevistas |
| Auditor de SGSI ISO/IEC 27007:2020 | Condução e eficácia da auditoria ao SGSI | Definições de funções comparadas com permissões reais, trilhos de aprovação privilegiada, logs de revogação |
| Avaliador orientado por NIST | Implementação técnica e teste de controlos | Evidência AC-2, AC-5, AC-6, AC-17, IA-2, IA-5 e AU-2 proveniente de ferramentas IAM, PAM e SIEM |
| Auditor COBIT 2019 ou ISACA | Governação, propriedade e fiabilidade da evidência | Evidência de processos DSS05.04 e DSS06.03, métricas, exceções, acompanhamento da remediação |
| Revisor DORA | Risco das TIC, resiliência e criticidade | Listas de acesso a sistemas críticos, monitorização privilegiada, controlos de administração de terceiros, ligações a testes de resiliência |
| Revisor NIS2 | Responsabilização da gestão e medidas de risco | Supervisão pelo Conselho de Administração, medidas de controlo de acesso do Article 21, cobertura de MFA, preparação para incidentes |
| Revisor RGPD da UE | Confidencialidade e responsabilização sobre dados pessoais | Restrições de acesso a dados pessoais, evidência de privacidade por defeito do Article 25, medidas de segurança do Article 32 |
Preparar evidência que satisfaça todas estas perspetivas demonstra um programa de conformidade maduro e reduz trabalho duplicado.
Constatações comuns e ações preventivas
As constatações de controlo de acesso são previsíveis. As ações preventivas também.
| Constatação | Porque importa | Prevenção |
|---|---|---|
| Existem revisões de acessos, mas as contas privilegiadas estão excluídas | Os direitos administrativos criam o risco de maior impacto | Incluir indicador de privilégio, registos PAM e grupos administrativos em todas as revisões |
| MFA ativada para colaboradores, mas não para service desks, contratados ou administradores de cloud | Os atacantes visam exceções | Manter relatório de cobertura de MFA e registo de exceções com datas de expiração |
| O processo de admissão está documentado, mas as alterações de função não são geridas | A acumulação de privilégios aumenta após mudanças de função | Desencadear revisão de acessos em cada mudança de departamento ou função |
| Existem contas administrativas partilhadas sem controlos compensatórios | A responsabilização é fraca | Substituir por contas administrativas nominativas ou aplicar checkout em cofre e registo de sessões |
| Colaboradores cessantes são desativados no diretório, mas continuam ativos em plataformas SaaS | O acesso persiste fora do IdP principal | Manter inventário de aplicações e lista de verificação de cessação para todos os sistemas |
| Palavras-passe de contas de serviço são desconhecidas ou nunca são rodadas | Identidades não humanas tornam-se backdoors ocultas | Atribuir proprietários, guardar segredos em cofre, rodar credenciais e rever logs de utilização |
| A política exige revisão trimestral, mas a evidência mostra revisão anual | Política e prática divergem | Ajustar a cadência com base no risco ou aplicar o requisito documentado |
| Aprovações de acesso estão em correio eletrónico sem regra de retenção | O trilho de auditoria é frágil | Utilizar fluxos de trabalho ITSM e retenção alinhada com a política |
A Política de controlo de acesso empresarial acrescenta um requisito de retenção que evita uma das falhas de evidência mais comuns:
“As decisões de aprovação devem ser registadas e retidas para fins de auditoria por um período mínimo de 2 anos.”
Da secção “Requisitos de governação”, cláusula 5.3.2.
Se as aprovações desaparecem após a limpeza do correio eletrónico, o controlo pode ter funcionado, mas a auditoria não pode confiar nele. A retenção faz parte da conceção do controlo.
A responsabilização da gestão exige métricas de acesso
O NIS2 Article 20 e os DORA Articles 5 e 6 tornam o controlo de acesso uma preocupação da gestão porque o comprometimento de identidades pode transformar-se em interrupção operacional, reporte regulamentar, violação de dados e dano para clientes. As cláusulas 5.1 a 5.3 da ISO/IEC 27001:2022 também exigem que a alta direção alinhe o SGSI com a estratégia de negócio, forneça recursos, comunique a importância, atribua responsabilidades e promova a melhoria contínua.
Métricas úteis de controlo de acesso incluem:
- Percentagem de sistemas críticos cobertos por SSO
- Percentagem de contas privilegiadas com MFA
- Número de contas privilegiadas permanentes versus contas JIT
- Taxa de conclusão das revisões de acessos
- Número de permissões excessivas revogadas
- Cumprimento do SLA de desativação de colaboradores cessantes
- Número de contas inativas
- Cobertura de proprietários de contas de serviço
- Cobertura de gravação de sessões PAM
- Número e antiguidade de exceções MFA
Estas métricas ajudam a gestão a aprovar o tratamento de riscos e a demonstrar supervisão. Também tornam as auditorias mais credíveis porque a organização consegue demonstrar que o controlo de acesso é monitorizado como um risco ativo, e não redescoberto antes de cada auditoria.
Transformar evidência dispersa em confiança na auditoria
Se a evidência de controlo de acesso ISO/IEC 27001:2022 estiver dispersa por Recursos Humanos, ITSM, IAM, PAM, consolas cloud e folhas de cálculo, o próximo passo não é reescrever mais uma política. O próximo passo é uma arquitetura de evidência.
Comece por esta sequência:
- Definir sistemas, identidades e dados dentro do âmbito.
- Mapear requisitos NIS2, DORA, RGPD da UE e contratuais para o contexto do SGSI.
- Utilizar cenários de risco ao estilo da ISO/IEC 27005:2022 para priorizar IAM, MFA, PAM e revisões de acessos.
- Atualizar a Declaração de Aplicabilidade e o plano de tratamento de riscos.
- Alinhar cláusulas de políticas com fluxos de trabalho reais de IAM e PAM.
- Executar o sprint de evidência com três amostras.
- Corrigir lacunas antes de o auditor as encontrar.
- Manter um pacote de evidência reutilizável para certificação, diligência prévia de clientes e revisões regulamentares.
A Clarysec pode ajudar a implementar isto através do Zenith Blueprint: roteiro de 30 passos para auditores, a mapear requisitos de forma cruzada com o Zenith Controls: guia de conformidade cruzada e a operacionalizar requisitos com o conjunto certo de políticas Clarysec, incluindo a Política de controlo de acesso, a Política de Gestão de Contas de Utilizador e Privilégios e a Política de Admissão e Cessação.
A preparação para auditoria de controlo de acesso não consiste em provar que comprou uma ferramenta IAM. Consiste em provar que os processos de identidade, autenticação, privilégio e revisão reduzem riscos reais de negócio e satisfazem as normas e regulamentos relevantes para a sua organização.
Descarregue os toolkits da Clarysec, execute o sprint de evidência com três amostras e transforme a sua evidência de controlo de acesso, de um conjunto disperso e desorganizado, num portefólio de auditoria claro, repetível e defensável.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
