Recuperação da floresta AD: validar backups

O que significa validar backups para a recuperação da floresta AD

A recuperação da floresta AD com validação dos backups exige responder a duas perguntas: o backup pode ser restaurado e a organização consegue justificar a confiança na floresta recuperada a partir dele? Uma restauração bem-sucedida responde à primeira. A segunda exige um ponto de recuperação investigado, um procedimento ensaiado e evidências de que o diretório restaurado cumpre os critérios de recuperação.

O Guia de Recuperação de Florestas do Active Directory da Microsoft fornece um modelo a adaptar ao ambiente. As suas orientações para avaliar o incidente excluem explicitamente recomendações completas de segurança para recuperar uma floresta invadida ou comprometida. Use o procedimento de recuperação em conjunto com o trabalho de resposta a incidentes necessário para estabelecer confiança.

Aqui, recuperação validada significa um exercício ou uma recuperação documentados, com verificações de aceitação registadas e limites explicitamente declarados. É uma definição editorial, não uma certificação da Microsoft. “O DC arrancou” e “a replicação funciona” são observações úteis, mas nenhuma demonstra que o estado do diretório selecionado é seguro.

Trate o tempo decorrido na recuperação como mais um resultado a registar. Um exercício rápido com credenciais desconhecidas, dados não revistos ou falhas de validação por resolver não deve ser descrito como uma recuperação validada.

Escolher um estado fiável antes de restaurar

As orientações da Microsoft para selecionar backups alertam que um backup mais recente pode reintroduzir dados perigosos. Se o momento da falha for desconhecido, investigue o último estado seguro. A recuperação perde os objetos, atualizações e alterações de configuração ou de esquema posteriores.

A mesma página recomenda fazer regularmente backups de pelo menos dois DCs graváveis por domínio. Exige credenciais de Domain Admin para cada domínio e a palavra-passe DSRM. Um backup de RODC não pode restaurar um DC gravável; a restauração do estado do sistema numa nova instalação do Windows não é suportada. Planeie o percurso adequado de recuperação completa do servidor. O Dsamain e um navegador LDAP como o Ldp podem ajudar a inspecionar os dados do diretório guardados no backup.

Com a Reciclagem ativada, a validade do backup é limitada pelo menor valor de deletedObjectLifetime e tombstoneLifetime. Estas condições tornam “temos um ficheiro recente” um argumento incompleto para a recuperação.

Para decidir a recuperação, registe qual foi o backup escolhido, que domínio representa, por que razão o seu estado é aceitável e que alterações serão perdidas. Se a investigação não sustentar um ponto fiável, registe essa incerteza em vez de classificar o backup mais recente como limpo.

As afirmações sobre persistência devem permanecer condicionais

A inferência do lado da recuperação é condicional: se uma alteração maliciosa do diretório estiver presente no backup selecionado e fizer parte do estado restaurado, a restauração desse estado pode reintroduzir a alteração. Esta é uma dedução a partir do comportamento documentado de reversão, não uma afirmação da Microsoft de que todas as backdoors regressam necessariamente intactas.

Esta distinção é importante para as ACLs e o AdminSDHolder. O nosso artigo sobre AdminSDHolder e SDProp explica a persistência através de um modelo de ACL alterado e por que corrigir apenas a ACL de um objeto protegido pode deixar o problema do modelo por resolver. Na recuperação, pergunte se o modelo guardado e as permissões relevantes correspondem a uma referência aceite. As páginas de Forest Recovery aqui citadas não descrevem explicitamente a restauração de uma backdoor no AdminSDHolder.

A documentação da Microsoft sobre modelos de certificado afirma que os modelos de CAs empresariais residem no AD DS. Distingue a alteração de um modelo, a ativação da emissão numa CA e a publicação de um certificado emitido. Um modelo alterado incluído no estado restaurado do diretório poderia, portanto, reaparecer: trata-se de uma inferência condicional. Isto não estabelece o estado restaurado de todas as CAs, certificados emitidos ou segredos de PKI. Defina separadamente a revisão complementar da PKI.

O nosso artigo sobre Golden Ticket descreve a preocupação com a persistência associada a um segredo krbtgt comprometido. As instruções de recuperação e os intervalos de redefinição abaixo provêm do Microsoft Learn. O link explica por que o segredo é importante; não é a fonte de autoridade para este procedimento de recuperação.

Seguir a sequência de recuperação com pontos de validação

Os pré-requisitos da Microsoft pressupõem que a causa e as possíveis soluções foram avaliadas com o Suporte da Microsoft e que a restauração da floresta foi a solução escolhida, frequentemente como última opção. Exigem também um plano documentado e testado em laboratório com backups de produção.

Prepare essa decisão antes de iniciar passos destrutivos de recuperação. Registe o âmbito do incidente, as credenciais de recuperação, as informações de acesso de emergência e os backups escolhidos. Um runbook deve tornar clara a decisão seguinte mesmo quando os serviços habituais de diretório não estão disponíveis.

O que se segue é uma visão geral da sequência inicial de recuperação da Microsoft, não um substituto executável do procedimento completo:

1. Restaurar em isolamento. Comece por um DC gravável no domínio raiz da floresta e depois recupere os restantes domínios, os domínios superiores antes dos subordinados.
2. Usar o modo correto de restauração para o primeiro DC restaurado em cada domínio. Restaure o AD DS de forma não autoritativa e o SYSVOL de forma autoritativa, seguindo o método documentado. Os DCs posteriores desse domínio devem voltar a sincronizar o SYSVOL a partir da cópia autoritativa.
3. Verificar os dados restaurados antes da ligação à produção. Conclua os passos documentados de FSMO, metadados, DNS, RID, palavras-passe de contas e hora. A suspeita de intrusão exige redefinir palavras-passe administrativas e trabalhar para substituir todas as palavras-passe de gMSA. A suspeita de comprometimento de contas de utilizador também exige planear a redefinição de palavras-passe de todos os utilizadores do domínio.
4. Validar em conjunto os DCs recuperados. Use uma rede isolada comum antes da transição para produção.
5. Fazer backups dos DCs restaurados antes de voltar a implementar os restantes DCs.

A página também documenta estas verificações operacionais na secção de integridade da replicação da floresta, após a transição para a rede de produção:

repadmin /replsum
DCDiag /v

Estas verificações avaliam a replicação e a integridade dos DCs e do DNS. Uma saída bem-sucedida não certifica a ausência de persistência. Mantenha distinguíveis as evidências operacionais e as conclusões da revisão de segurança no registo da recuperação.

Redefinir krbtgt duas vezes com o intervalo documentado

O procedimento da Microsoft para redefinir krbtgt aplica-se a DCs graváveis, não a RODCs. Em Utilizadores e Computadores do Active Directory, ative as Funcionalidades Avançadas, abra o contentor Users do domínio e use a ação de redefinição de palavra-passe em krbtgt.

Execute a operação duas vezes. A conta conserva as duas palavras-passe mais recentes; duas redefinições removem a palavra-passe antiga desse histórico. O Learn exige 10 horas entre redefinições com as durações máximas predefinidas dos tickets de utilizador e de serviço. Se a duração máxima tiver sido alterada, o período de espera deve ser superior ao valor configurado. Não assuma que a primeira redefinição invalida universalmente todos os tickets falsificados.

Numa recuperação que envolva RODCs, o Learn indica que não se devem eliminar as suas contas krbtgt_number. Não lhes aplique o procedimento destinado a DCs graváveis.

Deteção: medir a idade dos backups e a falta de evidências

O sucesso de uma tarefa de backup, uma marca temporal do diretório e um exercício de restauração descrevem evidências diferentes. Analise cada uma segundo o seu próprio significado.

As orientações da Microsoft sobre a latência dos backups documentam:

Repadmin.exe /showbackup

Recolha as datas de backup apresentadas para os DCs e contextos de nomenclatura visados e registe o âmbito real do comando. O Repadmin necessita de credenciais administrativas em cada DC visado. A Microsoft explica que a marca temporal do backup é escrita por backups que usam as APIs padrão de backup; uma cópia ao nível dos ficheiros da base de dados do AD não oferece essa proteção.

Investigue quando os backups forem mais antigos do que metade da duração dos tombstones da floresta. O Learn afirma que os backups mais antigos do que a duração dos tombstones são inválidos e recomenda backups pelo menos diários em quase todos os cenários. Leia as definições reais de duração da floresta. Não as substitua por um valor universal de 180 dias nem pelo limiar independente de 60 dias do coletor.

Uma marca temporal recente continua a não demonstrar a integridade do suporte nem uma restauração bem-sucedida.

Estes são motivos para investigar, não observações de um ambiente de cliente. Peça os artefactos que sustentam “testado” ou “recuperável”: qual backup, qual domínio, qual revisão do procedimento e quais verificações foram aprovadas?

Correção: documentar, ensaiar e preparar a recuperação de objetos (Remediation)

1. Tornar o runbook específico da floresta

As orientações de planeamento da Microsoft exigem um mapa da topologia que cubra os DCs, funções, estado dos backups e relações de confiança. Recomendam praticar a recuperação da floresta pelo menos anualmente e sugerem também exercícios quando muda a composição dos grupos Domain Admins ou Enterprise Admins.

Transforme o mapa num registo de decisão utilizável: identifique o DC de recuperação de cada domínio, os critérios de seleção dos backups, o acesso necessário e os pontos de validação. Atribua a responsabilidade por manter essas entradas atualizadas. Uma lacuna sem explicação deve permanecer visível em vez de ser ocultada por uma lista de verificação concluída.

2. Repetir a restauração e preservar os resultados

Os pré-requisitos exigem backups e restaurações regulares de AD DS e SYSVOL em laboratório, revisão rotineira dos procedimentos e atualizações após alterações do sistema operativo ou da arquitetura. Ensaie o percurso real de recuperação com backups de produção.

Um registo de ensaio útil identifica a revisão do runbook, os backups selecionados, os operadores, as verificações realizadas, as saídas e os desvios. Inclua o tempo decorrido, mas indique também o que o exercício validou e o que não validou. Se um backup arrancar com sucesso mas a revisão dos dados falhar, conserve ambos os resultados. Se o acesso necessário não estava disponível, registe-o como uma dependência da recuperação a corrigir.

Separe “o procedimento foi executado” de “os critérios de aceitação foram cumpridos”. Repetir um procedimento sem examinar os seus resultados não encerra a questão da confiança.

3. Ativar a Reciclagem antes de ser necessária

As orientações da Microsoft sobre a Reciclagem afirmam que a funcionalidade está desativada por predefinição e que a ativação é irreversível. Preserva os atributos e ligações dos objetos eliminados, incluindo a pertença a grupos. Só pode recuperar objetos eliminados após a ativação.

Verifique os pré-requisitos documentados: níveis funcionais da floresta e dos domínios de Windows Server 2008 R2 ou superior, as permissões administrativas indicadas e o ADAC ou o módulo PowerShell do Active Directory.

Para o percurso documentado no ADAC, selecione o domínio de destino adequado, escolha Enable Recycle Bin no painel de tarefas, confirme as mensagens e atualize o ADAC. Após uma eliminação de teste controlada, use o contentor Deleted Objects para restaurar o objeto selecionado e verificar a sua localização.

Registe a decisão de ativação e um teste controlado de restauração de objetos. A Reciclagem trata da recuperação de objetos; não valida uma floresta comprometida. Mantenha esse teste separado do exercício de restauração da floresta.

4. Fechar as lacunas de evidência antes de declarar a recuperação validada

Use um registo breve de aceitação que associe cada conclusão a uma evidência. “Backup disponível” deve identificar o backup. “Recuperação ensaiada” deve identificar o exercício. “Estado fiável” deve identificar a investigação e a revisão da referência. “Verificações operacionais aprovadas” deve identificar as saídas registadas.

Quando o incidente exigir trabalho adicional de segurança ou PKI, identifique a tarefa por resolver e o seu responsável. Não deixe que uma verificação de replicação bem-sucedida se transforme silenciosamente numa aprovação de tudo o que está fora do seu âmbito.

Como a EtcSec deteta este problema

O coletor fornece três verificações ativas relevantes para este tema. Identificam sinais de configuração ou de necessidade de revisão; não provam que a floresta é recuperável.

O identificador HDS não estabelece um requisito HDS numerado específico nem prova a ausência de um plano de recuperação. Use-o para motivar uma revisão humana da topologia e do planeamento da recuperação.

BACKUP_AD_NOT_VERIFIED não é medido pelo coletor. O seu detetor descontinuado não devolve resultados e não está registado. Está excluído das etiquetas de vulnerabilidade deste artigo. A verificação da restauração necessita de evidências operacionais fora destas verificações do diretório.