Evidência de hardening do Active Directory para auditorias de 2026

O alerta chegou às 2:17. Uma conta com privilégios elevados, inativa há seis meses, tinha acabado de modificar um Objeto de Política de Grupo crítico. Quase em simultâneo, o SOC observou múltiplas falhas de pré-autenticação Kerberos a partir de uma sub-rede de postos de trabalho. Cinco minutos depois, foi emitido um certificado pelos Active Directory Certificate Services para uma conta que nunca deveria tê-lo solicitado.

Maria, a Diretora de Segurança da Informação (CISO) de uma empresa fintech de média dimensão, percebeu o significado. A organização não tinha apenas detetado atividade suspeita. Tinha detetado um possível ataque ao plano de controlo de identidades.

A investigação revelou um percurso conhecido. Um agente de ameaça comprometeu um servidor aplicacional legado, encontrou credenciais em texto claro de uma conta de serviço antiga e descobriu que a conta ainda tinha privilégios excessivos. A alteração à GPO foi bloqueada antes de se propagar, mas a discussão na sala do conselho de administração, na manhã seguinte, foi direta.

“Como é que isto aconteceu?”, perguntou o Diretor Executivo. “Conseguimos demonstrar aos nossos reguladores e clientes que as nossas chaves do reino estão efetivamente controladas?”

Esta pergunta define o hardening do Active Directory em 2026. Para muitas organizações, o Active Directory local ou híbrido continua a suportar o acesso a ficheiros, sistemas ERP, VPN, plataformas de cópia de segurança, servidores Windows, administração privilegiada, aplicações legadas, autenticação Kerberos e sincronização com Entra ID. Se o AD falhar, a organização não perde apenas a autenticação. Perde o controlo.

Reguladores e auditores já compreendem esta realidade. Ao abrigo da NIS2, os órgãos de gestão devem aprovar medidas de gestão de riscos de cibersegurança e podem ser responsabilizados por infrações. Ao abrigo do DORA, as entidades financeiras devem gerir o risco das TIC através de governação, proteção, deteção, resposta e capacidades de recuperação documentadas. Ao abrigo do GDPR, as organizações devem proteger dados pessoais por meio de medidas técnicas e organizativas adequadas e devem conseguir demonstrar responsabilização. Ao abrigo da ISO/IEC 27001:2022, os riscos do Active Directory devem ser incluídos no âmbito, avaliados, tratados, monitorizados e suportados por evidência.

A resposta não é mais uma lista de verificação sem governação. A resposta é um modelo de evidência defensável que liga controladores de domínio, Kerberos, Política de Grupo, AD CS, acesso privilegiado, registo de eventos e recuperação ao SGSI, ao registo de riscos, à Declaração de Aplicabilidade, ao quadro de políticas e ao trilho de auditoria.

Porque o Active Directory continua a ser um risco ao nível do conselho de administração

A maioria dos comprometimentos do Active Directory não é exótica. Normalmente combina privilégios excessivos, contas obsoletas, fraca higiene de contas de serviço, Política de Grupo demasiado permissiva, delegação insegura, configuração Kerberos deficiente, modelos de certificados arriscados, controladores de domínio sem patches, monitorização incompleta e cópias de segurança que nunca foram restauradas.

O impacto na conformidade é direto. Se um atacante obtiver direitos de administrador de domínio, pode aceder a dados pessoais, distribuir GPOs maliciosas, desativar ferramentas de segurança, modificar registos de eventos, adulterar cópias de segurança, emitir certificados para persistência, mover-se lateralmente para caminhos de identidade na nuvem e interromper serviços críticos.

A ISO/IEC 27001:2022 transforma isto numa questão de governação antes de ser uma questão técnica. As cláusulas 4.1 a 4.4 exigem que a organização defina o contexto, as partes interessadas, os requisitos, o âmbito e os processos do SGSI. Para um ambiente de identidade híbrido, o âmbito deve incluir explicitamente controladores de domínio, AD CS, estações de trabalho administrativas privilegiadas, sistemas de cópia de segurança, servidores de sincronização de identidades, prestadores de serviços geridos e dependências de identidade na nuvem.

As cláusulas 5.1 a 5.3 tornam a liderança responsável por política, recursos, papéis e reporte. A limpeza de Domain Admins não é apenas uma tarefa de infraestrutura. É uma decisão de tratamento do risco apoiada pela gestão.

As cláusulas 6.1.1 a 6.1.3 exigem um processo repetível de avaliação de riscos e tratamento de riscos, incluindo a Declaração de Aplicabilidade. É aqui que o hardening do Active Directory se torna auditável.

[ZB] Zenith Blueprint: roteiro de 30 passos para auditores Zenith Blueprint enquadra isto na fase de Gestão de Riscos, passo 13, Planeamento do Tratamento do Risco e Declaração de Aplicabilidade:

A SoA é, na prática, um documento de ligação: liga a sua avaliação/tratamento de riscos aos controlos concretos que possui. Ao preenchê-la, também confirma se deixou algum controlo por considerar.

Para o Active Directory, essa ponte é crítica. Um risco como “comprometimento de contas privilegiadas de AD levando à implantação de ransomware e a acesso não autorizado a dados pessoais” pode ser mapeado para acesso privilegiado, autenticação segura, gestão da configuração, registo de eventos, monitorização, cópias de segurança, resposta a incidentes e controlos criptográficos. A SoA pode então explicar por que motivo cada controlo é aplicável, que obrigações regulamentares apoia e que evidência comprova a sua operação.

A pilha de evidência do Active Directory que os auditores esperam

Um ambiente AD reforçado não está pronto para auditoria apenas porque existem definições. Capturas de ecrã, isoladamente, são fracas. Políticas, isoladamente, são incompletas. Uma exportação de GPO sem histórico de aprovação é arriscada. Evidência robusta demonstra governação, implementação, monitorização e melhoria.

A lacuna de maturidade normalmente não é a ausência de todos os controlos. É a ausência de propriedade, periodicidade de revisão, tratamento de exceções e mapeamento. Um auditor perguntará não apenas se existe um grupo privilegiado, mas quem é o seu proprietário, quem aprovou a adesão, quando foi revisto pela última vez, que registos de eventos são recolhidos e como expiram as exceções.

Acesso privilegiado: o primeiro controlo de AD a evidenciar

O caminho mais rápido para o comprometimento do Active Directory é o privilégio excessivo. Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Backup Operators, administradores locais, administradores delegados de OU e administradores de autoridades de certificação exigem todos governação explícita.

[P11] Política de Gestão de Contas de Utilizador e Privilégios Política de Gestão de Contas de Utilizador e Privilégios define a expectativa empresarial:

Os repositórios de contas (por exemplo, Active Directory (AD), plataformas de Gestão de Identidades e Acessos) devem ser protegidos por controlos adequados para prevenir acesso não autorizado ou adulteração.

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

[P11S] Política de Gestão de Contas de Utilizador e Privilégios - PME Política de Gestão de Contas de Utilizador e Privilégios - PME fornece uma regra prática de aprovação:

Privilégios elevados ou administrativos exigem aprovação adicional pelo Diretor-Geral (GM) 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 6.2.2 da política.

Em [ZC] Zenith Controls: o guia de conformidade cruzada Zenith Controls, o controlo ISO/IEC 27002:2022 8.2, Direitos de acesso privilegiado, é mapeado como controlo preventivo que apoia confidencialidade, integridade e disponibilidade. O guia liga o 8.2 à gestão de identidades, direitos de acesso, restrição de acesso à informação, autenticação segura, trabalho remoto, registo de eventos e monitorização. Também mapeia o controlo para os Artigos 5(1)(f), 25 e 32 do GDPR, para as expectativas de gestão de riscos do NIS2 Article 21 e para a governação do risco das TIC do DORA aplicável a entidades financeiras.

Zenith Blueprint, fase Controlos em Ação, passo 19, explica a expectativa operacional:

A.8.2 – Direitos de acesso privilegiado: “A atribuição e utilização de direitos de acesso privilegiado devem ser restringidas e geridas.”

Controle os direitos de superutilizador das contas administrativas apenas para quem deles necessita estritamente e faça a respetiva gestão com cuidado. Por exemplo, utilize uma conta administrativa separada (não use direitos administrativos no trabalho diário), aprove e acompanhe regularmente quem recebe privilégios de administrador de domínio ou root. Utilize também controlos mais robustos para essas contas (como MFA e registo em logs das respetivas ações).

Para AD, um auditor deve conseguir selecionar um utilizador privilegiado e rastrear a história completa: pedido, aprovação, justificação de negócio, atribuição técnica, monitorização, revisão, remoção e tratamento de exceções.

Um pacote prático de evidência de acesso privilegiado deve incluir:

1. Exportação de grupos privilegiados de AD, incluindo grupos aninhados.
2. Proprietário do negócio nomeado para cada grupo privilegiado.
3. Evidência de revisão trimestral de acessos.
4. Contas administrativas separadas para tarefas privilegiadas.
5. Ausência de correio eletrónico ou navegação de utilização diária a partir de contas privilegiadas.
6. MFA ou autenticação resistente a phishing para caminhos de acesso privilegiado, quando aplicável.
7. Modelo de posto de trabalho privilegiado ou servidor de salto administrativo seguro.
8. Registo de eventos de alterações de membros de grupos e de operações privilegiadas.
9. Inventário de contas de emergência com controlos compensatórios.
10. Aceitação do risco para exceções, com datas de expiração.

Foi assim que Maria encerrou a constatação imediata sobre a conta de serviço. A conta foi documentada como item de alto risco, a Política de Gestão de Contas de Utilizador e Privilégios - PME foi usada para questionar o privilégio permanente, o proprietário da aplicação identificou o acesso mínimo necessário, a adesão ao grupo Domain Admins foi removida e a alteração foi documentada através da gestão de alterações. A entrada da SoA para o controlo ISO/IEC 27002:2022 8.2 foi atualizada para demonstrar a redução do risco e o mapeamento para o GDPR Article 32 e o NIS2 Article 21.

Kerberos e informação de autenticação

O Kerberos permite autenticação escalável em ambientes Windows, mas uma configuração fraca ou uma higiene deficiente das contas de serviço pode permitir Kerberoasting, abuso de tickets, ataques de repetição e persistência de longo prazo. A evidência deve abranger a informação de autenticação ao longo de todo o seu ciclo de vida: palavras-passe, chaves, tickets, segredos de contas de serviço, certificados, processos de reposição e fatores MFA.

Em Zenith Controls, o controlo ISO/IEC 27002:2022 5.17, Informação de autenticação, é mapeado como controlo preventivo que apoia confidencialidade, integridade e disponibilidade. Liga-se à gestão de identidades, autenticação segura, papéis e responsabilidades, utilização aceitável e cumprimento de políticas e normas. O mapeamento cruzado liga-o à proteção adequada ao risco contra acesso não autorizado no GDPR, ao NIS2 Article 21(2)(j) sobre MFA ou autenticação contínua quando adequado, e aos requisitos DORA para mecanismos de autenticação robustos no âmbito da gestão do risco das TIC.

O GDPR Article 5(1)(f) exige que os dados pessoais sejam protegidos contra tratamento não autorizado ou ilícito e contra perda, destruição ou dano acidentais. O Article 5(2) acrescenta a responsabilização. Se as credenciais de AD concedem acesso a registos de Recursos Humanos, ficheiros de clientes ou caixas de correio, os controlos Kerberos e de autenticação tornam-se evidência GDPR.

O NIS2 Article 21 exige medidas técnicas, operacionais e organizativas adequadas e proporcionais, incluindo análise de riscos, tratamento de incidentes, continuidade de negócio, segurança da cadeia de fornecimento, manutenção segura, avaliação de eficácia, higiene de cibersegurança, criptografia, segurança de Recursos Humanos, controlo de acesso, gestão de ativos e MFA ou autenticação contínua quando adequado.

Para entidades financeiras abrangidas pelo DORA, as dependências de autenticação devem ser consideradas dentro do quadro de gestão do risco das TIC. Se o AD autentica colaboradores em sistemas de pagamentos, negociação, seguros, clientes ou risco, a evidência Kerberos apoia a resiliência operacional.

Governação de Política de Grupo e gestão da configuração

A Política de Grupo é um dos mecanismos de segurança mais poderosos no Active Directory. Pode aplicar firewalls, restrições de administradores locais, política de auditoria, definições de proteção de endpoint, regras de execução de scripts e referenciais seguros em milhares de sistemas. Também pode enfraquecer esses mesmos controlos se for mal utilizada.

Em Zenith Controls, o controlo ISO/IEC 27002:2022 8.9, Gestão da configuração, é mapeado como controlo preventivo para configuração segura. Liga-se à gestão de vulnerabilidades, gestão de alterações, inventário de ativos, dispositivos endpoint, acesso privilegiado, autenticação segura, registo de eventos e monitorização. O guia liga a gestão da configuração aos Artigos 5(1)(f), 25 e 32 do GDPR, às expectativas do NIS2 Article 21 sobre configuração segura e gestão de riscos, e à fiabilidade, segurança e resiliência dos sistemas de TIC no âmbito do DORA.

[P05S] Política de Gestão de Alterações - PME Política de Gestão de Alterações - PME estabelece:

Se uma alteração envolver dados sensíveis, direitos de acesso ao sistema ou integrações externas, é necessária uma revisão do impacto na segurança. O contacto designado de segurança ou conformidade deve avaliar se a alteração introduz riscos adicionais e recomendar salvaguardas adicionais.

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

[P05] Política de Gestão de Alterações Política de Gestão de Alterações exige:

Todos os pedidos de alteração, revisões, aprovações e evidência de suporte devem ser registados no Sistema de Gestão de Alterações centralizado.

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

Um pacote de evidência de GPO deve responder a quatro perguntas:

1. Quem é o proprietário de cada GPO relevante para a segurança?
2. Que referencial de segurança é aplicado por essa GPO?
3. Quem aprovou as respetivas alterações?
4. Como são detetados desvios não autorizados?

Zenith Blueprint, fase Controlos em Ação, passo 19, apresenta a abordagem de referência:

Comece por estabelecer listas de verificação de configuração para todos os principais tipos de sistemas: servidores Windows, hosts Linux, dispositivos de rede, bases de dados e serviços na nuvem. Estas referências devem refletir tanto melhores práticas da indústria (como CIS Benchmarks) como a sua postura de risco interna.

Para AD, isto significa que as GPOs devem aplicar referenciais documentados, e não preferências não documentadas. A evidência deve incluir exportações mensais de GPOs, mapeamento para requisitos de referência, tickets de alteração para modificações, revisões de permissões delegadas, registos de cópia de segurança de GPOs e alertas para alterações a GPOs de alto impacto.

AD CS e PKI: o caminho de ataque esquecido

Os Active Directory Certificate Services escapam frequentemente às revisões de conformidade porque funcionam discretamente em segundo plano. Os atacantes valorizam-nos pela mesma razão. Modelos de certificados mal configurados, permissões de inscrição excessivas, controlos de emissão fracos ou definições perigosas de Extended Key Usage podem permitir escalada de privilégios, personificação indevida e persistência.

O AD CS pertence aos controlos criptográficos, à gestão de identidades, ao acesso privilegiado e à gestão de alterações. Não basta dizer “temos PKI”. A organização deve saber que CAs existem, que certificados podem ser emitidos, quem pode solicitá-los, que modelos permitem autenticação de cliente, quem administra a CA e se a emissão é monitorizada.

[P18S] Política de Controlos Criptográficos - PME Política de Controlos Criptográficos - PME estabelece:

O Prestador de Suporte de TI deve manter um inventário atualizado das ferramentas criptográficas e certificados em utilização

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

[P18] Política de Controlos Criptográficos Política de Controlos Criptográficos inclui explicitamente:

Infraestrutura de Chave Pública (PKI)

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

O NIS2 Article 21 inclui políticas e procedimentos de criptografia e cifragem. O GDPR Article 32 exige segurança do tratamento, incluindo confidencialidade, integridade, disponibilidade e resiliência. O DORA exige que os ativos de TIC que suportam processos financeiros sejam protegidos e recuperáveis. O AD CS pode apoiar todos estes objetivos ou fragilizá-los.

Registo de eventos, cópias de segurança e recuperação de controladores de domínio

Os controladores de domínio não são servidores comuns. São sistemas de autenticação, réplicas de diretório, pontos de distribuição de políticas e ativos críticos para a recuperação. Se o ransomware comprometer o AD, a recuperação depende de cópias de segurança limpas dos controladores de domínio, restauro do estado do sistema, registos de eventos preservados, GPOs conhecidas como seguras, cópias de segurança de AD CS, chaves privadas protegidas e procedimentos de recuperação documentados.

[P22S] Política de Registo de Eventos e Monitorização - PME Política de Registo de Eventos e Monitorização - PME define expectativas para registos 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 5.4.2 da política.

[P22] Política de Registo de Eventos e Monitorização Política de Registo de Eventos e Monitorização exige:

Todos os sistemas abrangidos devem gerar logs que capturem:

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

Num ambiente dependente de AD, os sistemas abrangidos devem incluir controladores de domínio, servidores AD CS, sistemas de acesso privilegiado, postos de trabalho administrativos, servidores de sincronização de identidades e consolas de cópias de segurança.

Zenith Blueprint, fase Controlos em Ação, passo 19, é explícito:

Assegure que todos os sistemas críticos (servidores, controladores de domínio, firewalls) encaminham logs para o seu SIEM ou coletor de logs. Valide que a retenção de logs está alinhada com a sua política de registo em logs (por exemplo, 90 dias em modo ativo, 1 ano em arquivo). Selecione um incidente ou evento recente e demonstre como o rastreou usando os seus logs.

Também destaca a sincronização temporal, que mapeia para o controlo ISO/IEC 27002:2022 8.17, Sincronização temporal. Sem tempo fiável, a correlação de registos de eventos durante um incidente torna-se frágil.

[P15S] Política de Cópias de Segurança e Restauro - PME Política de Cópias de Segurança e Restauro - PME define uma expectativa mínima de evidência:

Os testes de restauro são realizados pelo menos trimestralmente, e os resultados são documentados para verificar a recuperabilidade

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

Os controlos ISO/IEC 27002:2022 relevantes incluem 8.13 Cópia de segurança da informação, 8.15 Registo de eventos, 8.16 Atividades de monitorização, 8.17 Sincronização temporal, 5.24 planeamento e preparação da gestão de incidentes de segurança da informação, 5.29 segurança da informação durante interrupções e 5.30 preparação das TIC para a continuidade de negócio.

Um pacote prático de evidência de recuperação deve incluir:

1. Inventário de controladores de domínio e propriedade das funções FSMO.
2. Âmbito, frequência e evidência de imutabilidade das cópias de segurança.
3. Validação da cópia de segurança do estado do sistema.
4. Resultados trimestrais dos testes de restauro.
5. Procedimento de cópia de segurança e restauro de GPOs.
6. Evidência de cópia de segurança de AD CS e proteção de chaves privadas.
7. Procedimento de autenticação para contas de emergência.
8. Configuração de sincronização temporal.
9. Playbook de incidente para comprometimento de AD.
10. Lições aprendidas de exercícios de mesa ou de recuperação técnica.

O NIS2 Article 23 também é relevante. Incidentes significativos podem exigir alerta precoce no prazo de 24 horas após tomada de conhecimento, notificação do incidente no prazo de 72 horas e relatório final no prazo máximo de um mês após a notificação do incidente. Se uma indisponibilidade de AD interromper serviços essenciais ou importantes, a evidência de recuperação e as cronologias de incidentes tornam-se evidência regulatória.

Mapa de conformidade cruzada para hardening do Active Directory

O hardening do Active Directory é um exemplo claro de um conjunto de controlos que apoia múltiplas obrigações.

Para a NIS2, isto deixou de ser teórico. As medidas nacionais aplicam-se a muitas entidades essenciais ou importantes de média e grande dimensão nos setores dos Anexos I e II, bem como a determinadas entidades independentemente da dimensão, incluindo prestadores de serviços de confiança, registos TLD, prestadores de serviços DNS e serviços críticos selecionados.

Para o DORA, o calendário também é real. O DORA aplica-se a partir de 17 de janeiro de 2025 e abrange diretamente muitas entidades financeiras. Se um MSP externalizado gerir o AD, os requisitos DORA de risco de terceiros nas TIC tornam-se relevantes, incluindo registos de contratos, diligência prévia, direitos de auditoria, assistência a incidentes, expectativas de segurança e estratégias de saída ao abrigo dos Artigos 28 e 30.

Para o GDPR, a ponte é a responsabilização. Se o AD controla o acesso a dados pessoais, as revisões de acessos privilegiados, a evidência de autenticação, o registo de eventos, as configurações de referência, os controlos de certificados e os testes de recuperação ajudam a demonstrar medidas técnicas e organizativas adequadas.

Criar um pacote de evidência de hardening de AD num sprint

Um sprint prático de duas semanas pode transformar o hardening fragmentado do AD num pacote de evidência pronto para auditoria.

Dias 1 a 2: incluir o AD no âmbito do SGSI. Use as cláusulas 4.1 a 4.4 da ISO/IEC 27001:2022 para confirmar se AD, Entra Connect, controladores de domínio, AD CS, estações de trabalho administrativas privilegiadas, sistemas de cópia de segurança e prestadores de serviços geridos estão dentro do âmbito. Registe as partes interessadas, incluindo reguladores, clientes, auditores, titulares dos dados, proprietários do negócio e operações de TI.

Dias 3 a 4: adicionar riscos de AD ao registo de riscos. Inclua comprometimento de controladores de domínio, acesso privilegiado excessivo, abuso de Kerberos, adulteração de GPOs, configuração incorreta de AD CS, comprometimento da sincronização de identidades, falha de cópia de segurança e registo de eventos insuficiente. Atribua proprietários, probabilidade, impacto e decisões de tratamento.

Dias 5 a 6: atualizar a SoA. Seguindo o passo 13 do Zenith Blueprint, marque como aplicáveis controlos como direitos de acesso privilegiado, informação de autenticação, gestão da configuração, registo de eventos, monitorização, cópia de segurança da informação, gestão de incidentes, controlos criptográficos e gestão de alterações. Acrescente notas que os liguem ao GDPR Article 32, NIS2 Article 21 e à gestão do risco das TIC do DORA, quando relevante.

Dias 7 a 9: recolher evidência técnica. Exporte grupos privilegiados, definições Kerberos, inventário de GPOs, referenciais dos controladores de domínio, modelos de CA, registos de emissão de certificados, estado das tarefas de cópia de segurança e estado de ingestão no SIEM. Acrescente proprietário, data, revisor, constatação e estado da remediação.

Dias 10 a 11: realizar um workshop de revisão de controlos. TI, segurança, conformidade e proprietários do negócio reveem exceções. Porque é que esta conta de serviço precisa de um SPN? Porque é que este grupo pode editar GPOs? Porque é que este modelo pode emitir certificados de autenticação de cliente? Porque é que este controlador de domínio não encaminha registos de eventos?

Dias 12 a 14: preparar a narrativa de auditoria. Crie um Pacote de Evidência de Hardening de AD com resumo executivo, âmbito, riscos, mapeamento da SoA, evidência de controlos, constatações em aberto, plano de remediação e calendário de testes.

O resultado é uma narrativa defensável: conhecemos o risco, selecionámos controlos, implementámo-los, monitorizamo-los, testamos a recuperação e a gestão tem visibilidade.

Constatações comuns de auditoria ao Active Directory e ações de encerramento

O padrão de encerramento é consistente: requisito da política, implementação técnica, captura de evidência, periodicidade de revisão, tratamento de exceções e reporte à gestão.

Transformar o hardening do Active Directory em evidência pronta para auditoria

O hardening do Active Directory em 2026 não é uma limpeza pontual. É um sistema de controlo vivo que deve ser governado, comprovado por evidência e melhorado. Controladores de domínio, Kerberos, Política de Grupo, AD CS, acesso privilegiado, registo de eventos e recuperação situam-se todos na interseção entre operações de segurança e responsabilização regulatória.

A Clarysec ajuda CISO, responsáveis de TI e equipas de conformidade a construir essa ponte. Use Zenith Blueprint para mapear riscos de AD para o SGSI, o registo de riscos e a Declaração de Aplicabilidade. Use Zenith Controls para cruzar controlos ISO/IEC 27002:2022 com GDPR, NIS2, DORA, NIST CSF 2.0 e expectativas de auditoria. Use os modelos de políticas da Clarysec, incluindo Política de Gestão de Contas de Utilizador e Privilégios, Política de Gestão de Alterações, Política de Controlos Criptográficos, Política de Registo de Eventos e Monitorização e Política de Cópias de Segurança e Restauro - PME, para transformar o hardening técnico em evidência repetível.

Se a sua próxima auditoria, pedido de regulador ou questionário de garantia de cliente perguntar como o Active Directory é controlado, não responda apenas com capturas de ecrã. Crie o pacote de evidência, ligue-o ao risco e demonstre que a gestão pode confiar no plano de controlo de identidades.

Comece com um sprint: acesso privilegiado, governação de GPOs, revisão de AD CS, registo de eventos de controladores de domínio e testes de restauro. A Clarysec pode ajudar a estruturar, evidenciar e defender esse trabalho.