Planejar para comprometimento
Aplica-se a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2 e Windows Server 2012
Lei número um: ninguém acredita que algo de ruim possa acontecer com eles, até que aconteça. - Dez leis imutáveis da administração de segurança
Os planos de recuperação de desastre em muitas organizações se concentram na recuperação de desastres regionais ou falhas que resultam na perda de serviços de computação. No entanto, ao trabalhar com clientes comprometidos, muitas vezes descobrimos que a recuperação de comprometimento intencional não está nos seus planos de recuperação de desastre. Isso ocorre especialmente quando o comprometimento resulta em roubo de propriedade intelectual ou destruição intencional que aproveita os limites lógicos (como destruição de todos os domínios do Active Directory ou todos os servidores) em vez dos limites físicos (como destruição de um datacenter). Embora uma organização possa ter planos de resposta a incidentes que definem atividades iniciais a serem executadas quando um comprometimento é descoberto, esses planos geralmente omitem as etapas de recuperação de um comprometimento que afete toda a infraestrutura de computação.
Como o Active Directory fornece recursos avançados de gerenciamento de identidade e acesso para usuários, servidores, estações de trabalho e aplicativos, ele acaba sendo o alvo de invasores. Se um invasor obtiver acesso altamente privilegiado a um domínio ou controlador de domínio do Active Directory, esse acesso poderá ser aproveitado para acessar, controlar ou até mesmo destruir toda a floresta do Active Directory.
Este documento discutiu alguns dos ataques mais comuns contra o Windows e o Active Directory, bem como contramedidas que você pode implementar para reduzir sua superfície de ataque, mas a única maneira segura de se recuperar em caso de um comprometimento completo do Active Directory é estar preparado antes da sua ocorrência. Esta seção se concentra menos nos detalhes de implementação técnica do que nas seções anteriores deste documento e mais nas recomendações de alto nível que você pode usar para criar uma abordagem holística e abrangente para proteger e gerenciar os ativos críticos de TI e de negócios da sua organização.
Se sua infraestrutura nunca foi atacada, resistiu a tentativas de violações ou sucumbiu a ataques e foi totalmente comprometida, você deve se planejar para a inevitável realidade de que será atacado várias vezes. Não é possível evitar ataques, mas há como evitar violações significativas ou comprometimentos completos. Cada organização deve avaliar de perto seus programas de gerenciamento de riscos existentes e fazer os ajustes necessários para ajudar a reduzir seu nível geral de vulnerabilidade, fazendo investimentos equilibrados em prevenção, detecção, contenção e recuperação.
Para criar defesas eficazes enquanto ainda fornece serviços aos usuários e empresas que dependem de sua infraestrutura e aplicativos, talvez seja necessário considerar novas maneiras de prevenir, detectar e conter o comprometimento em seu ambiente e, em seguida, recuperar-se. As abordagens e recomendações neste documento podem não ajudá-lo a reparar uma instalação comprometida do Active Directory, mas a se proteger da próxima.
As recomendações para recuperar uma floresta do Active Directory são apresentadas em Recuperação de floresta do AD – Etapas para restaurar a floresta. Você pode impedir que seu novo ambiente seja completamente comprometido, mas, mesmo que não consiga, você terá ferramentas para recuperar o controle do seu ambiente.
Repensando a abordagem
Lei Número Oito: a dificuldade de defesa de uma rede é diretamente proporcional à sua complexidade. - Dez leis imutáveis da administração de segurança
É bem aceito que, se um invasor tiver obtido acesso SYSTEM, Administrator, raiz ou equivalente a um computador, independentemente do sistema operacional, esse computador não poderá mais ser considerado confiável, independentemente de quantos esforços forem feitos para "limpar" o sistema. O Active Directory não é diferente. Se um invasor tiver obtido acesso privilegiado a um controlador de domínio ou a uma conta altamente privilegiada no Active Directory, a menos que você tenha um registro de cada modificação feita pelo invasor ou um bom backup conhecido, você nunca poderá restaurar o diretório para um estado completamente confiável.
Quando um servidor membro ou uma estação de trabalho é comprometida e alterada por um invasor, o computador não é mais confiável, mas servidores e estações de trabalho vizinhas não comprometidas ainda podem ser confiáveis. O comprometimento de um computador não implica que todos os computadores estejam comprometidos.
No entanto, em um domínio do Active Directory, todos os controladores de domínio hospedam réplicas do mesmo banco de dados do AD DS. Se um único controlador de domínio for comprometido e um invasor modificar o banco de dados do AD DS, essas modificações serão replicadas para todos os outros controladores de domínio no domínio e, dependendo da partição na qual as modificações são feitas, na floresta. Mesmo que você reinstale todos os controladores de domínio na floresta, você está simplesmente reinstalando os hosts nos quais o banco de dados do AD DS reside. Modificações mal-intencionadas no Active Directory serão replicadas para controladores de domínio recém-instalados tão facilmente quanto para controladores de domínio que estão em execução há anos.
Ao avaliar ambientes comprometidos, normalmente descobrimos que o que se acreditava ser o primeiro "evento" de violação foi, na verdade, disparado após semanas, meses ou até anos após os invasores terem inicialmente comprometido o ambiente. Os invasores geralmente obtiveram as credenciais para contas altamente privilegiadas muito antes de uma violação ser detectada e aproveitaram essas contas para comprometer o diretório, os controladores de domínio, os servidores membros, as estações de trabalho e até mesmo os sistemas não Windows conectados.
Essas conclusões são consistentes com várias descobertas no Relatório de Investigações de Violação de Dados de 2012 da Verizon, que afirma que:
98% das violações de dados decorreram de agentes externos
85% das violações de dados levaram semanas ou mais para serem descobertas
92% dos incidentes foram descobertos por terceiros, e
97% das violações podiam ter sido evitadas por controles simples ou intermediários.
Um comprometimento com o grau descrito anteriormente é efetivamente irreparável, e o conselho padrão para "limpar e reconstruir" todos os sistemas comprometidos não é viável se o Active Directory tiver sido comprometido ou destruído. Até mesmo a restauração para um bom estado conhecido não elimina as falhas que permitiram que o ambiente fosse comprometido em primeiro lugar.
Embora você precise defender cada faceta de sua infraestrutura, um invasor só precisa encontrar falhas suficientes em suas defesas para chegar ao objetivo desejado. Se seu ambiente for relativamente simples e primitivo e historicamente bem gerenciado, a implementação das recomendações fornecidas anteriormente neste documento pode ser uma proposta simples.
No entanto, descobrimos que quanto mais antigo, maior e mais complexo o ambiente, maior a probabilidade das recomendações neste documento serem inviáveis ou até mesmo impossíveis de serem implementadas. É muito mais difícil proteger uma infraestrutura após o fato do que começar de novo e construir um ambiente resistente a ataques e comprometimentos. Mas, como observado anteriormente, não é uma tarefa pequena recriar uma floresta inteira do Active Directory. Por esses motivos, recomendamos uma abordagem mais focada e direcionada para proteger suas florestas do Active Directory.
Em vez de se concentrar e tentar corrigir todas as coisas que estão "quebradas", considere uma abordagem na qual você prioriza o que é mais importante para sua empresa e na sua infraestrutura. Em vez de tentar corrigir um ambiente cheio de sistemas e aplicativos desatualizados e configurados incorretamente, considere criar um ambiente pequeno e seguro no qual você possa fazer a portabilidade com segurança dos usuários, sistemas e informações mais importantes para sua empresa.
Nesta seção, descrevemos uma abordagem pela qual você pode criar uma floresta primitiva do AD DS que serve como um "bote salva-vidas" ou "célula de segurança" para sua infraestrutura de negócios principal. Uma floresta primitiva é simplesmente uma floresta do Active Directory recém-instalada que normalmente tem tamanho e escopo limitados, e que é criada usando sistemas operacionais atuais, aplicativos e com os princípios descritos em Como reduzir a superfície de ataque do Active Directory.
Ao implementar as configurações recomendadas em uma floresta recém-criada, você pode criar uma instalação do AD DS criada desde o início com configurações e práticas seguras e reduzir os desafios que acompanham o suporte a sistemas e aplicativos herdados. Embora as instruções detalhadas para o design e a implementação de uma instalação primitiva do AD DS estejam fora do escopo deste documento, você deve seguir alguns princípios gerais e diretrizes para criar uma "célula de segurança" na qual você pode abrigar seus ativos mais importantes. Essas diretrizes são as seguintes:
Identificar os princípios para segregar e proteger ativos críticos.
Definir um plano de migração limitado e baseado em risco.
Aproveitar migrações "nãomigratórias" quando necessário.
Implementar a "destruição criativa".
Isolar sistemas e aplicativos herdados.
Simplificar segurança para usuários finais.
Identificar princípios para segregar e proteger ativos críticos
As características do ambiente primitivo que você cria para abrigar ativos importantes podem variar muito. Por exemplo, você pode optar por criar uma floresta primitiva na qual migre apenas usuários VIP e dados confidenciais que somente esses usuários podem acessar. Você pode criar uma floresta primitiva na qual você migra não apenas usuários VIP, mas que você implementa como uma floresta administrativa, implementando os princípios descritos em Como reduzir a superfície de ataque do Active Directory para criar contas administrativas e hosts seguros que podem ser usados para gerenciar suas florestas herdadas da floresta primitiva. Você pode implementar uma floresta com finalidade específica que abriga contas VIP, contas privilegiadas e sistemas que exigem segurança adicional, como servidores que executam o AD CS (Active Directory Certificate Services) com o único objetivo de separe-los de florestas menos seguras. Por fim, você pode implementar uma floresta primitiva que se torne o local de fato para todos os novos usuários, sistemas, aplicativos e dados, permitindo que você eventualmente desative sua floresta herdada por meio de atrito.
Independentemente da floresta primitiva conter um punhado de usuários e sistemas ou se ela forma a base para uma migração mais agressiva, você deve seguir estes princípios em seu planejamento:
Suponha que suas florestas herdadas tenham sido comprometidas.
Não configure um ambiente primitivo para confiar em uma floresta herdada, embora você possa configurar um ambiente herdado para confiar em uma floresta primitiva.
Não migre contas de usuário ou grupos de uma floresta herdada para um ambiente primitivo se houver a possibilidade das associações de grupo das contas, do histórico de SID ou outros atributos terem sido modificados maliciosamente. Em vez disso, use abordagens "nãomigratórias" para preencher uma floresta primitiva. (As abordagens nãomigratórias estão descritas mais adiante nesta seção.)
Não migre computadores de florestas herdadas para florestas primitivas. Implemente servidores recém-instalados na floresta primitiva, instale aplicativos nos servidores recém-instalados e migre dados do aplicativo para os sistemas recém-instalados. Para servidores de arquivos, copie dados para servidores recém-instalados, defina ACLs usando usuários e grupos na nova floresta e crie servidores de impressão de maneira semelhante.
Não permita a instalação de sistemas operacionais ou aplicativos herdados na floresta primitiva. Se um aplicativo não puder ser atualizado e instalado recentemente, deixe-o na floresta herdada e considere a destruição criativa para substituir a funcionalidade do aplicativo.
Definir um plano de migração limitado e baseado em risco
A criação de um plano de migração limitado e baseado em risco significa simplesmente que, ao decidir quais usuários, aplicativos e dados serão migrados para sua floresta primitiva, você deve identificar destinos de migração com base no grau de risco ao qual sua organização é exposta se um dos usuários ou sistemas estiver comprometido. Os usuários VIP cujas contas são mais propensas a serem alvo de invasores devem ser hospedados na floresta primitiva. Os aplicativos que fornecem funções comerciais vitais devem ser instalados em servidores recém-criados na floresta primitiva e os dados altamente confidenciais devem ser movidos para servidores seguros na floresta primitiva.
Se você ainda não tiver uma visão clara dos usuários, sistemas, aplicativos e dados mais críticos para os negócios em seu ambiente do Active Directory, trabalhe com unidades de negócios para identificá-los. Qualquer aplicativo necessário para a empresa operar deve ser identificado, assim como todos os servidores nos quais aplicativos críticos são executados ou dados críticos são armazenados. Ao identificar os usuários e os recursos necessários para que sua organização continue funcionando, você cria uma coleção naturalmente priorizada de ativos nos quais os esforços devem ser concentrados.
Aproveitando migrações "nãomigratórias"
Se você sabe que seu ambiente foi comprometido, suspeita que ele foi comprometido ou simplesmente prefere não migrar dados e objetos herdados de uma instalação herdada do Active Directory para uma nova, considere abordagens de migração que tecnicamente não "migram" objetos.
Contas de usuário
Em uma migração tradicional do Active Directory de uma floresta para outra, o atributo SIDHistory (histórico de SID) em objetos de usuário é usado para armazenar o SID dos usuários e os SIDs de grupos dos quais os usuários eram membros na floresta herdada. Se as contas de usuários forem migradas para uma nova floresta e acessarem recursos na floresta herdada, os SIDs no histórico de SID serão usados para criar um token de acesso que permita que os usuários acessem recursos aos quais tiveram acesso antes da migração das contas.
A manutenção do histórico de SID, no entanto, tem se mostrado problemática em alguns ambientes, pois o preenchimento dos tokens de acesso dos usuários com SIDs atuais e históricos pode resultar em sobrecarga de token. A sobrecarga de token é um problema no qual o número de SIDs que devem ser armazenados no token de acesso de um usuário usa ou excede a quantidade de espaço disponível no token.
Embora os tamanhos de token possam ser aumentados em uma extensão limitada, a solução final para a sobrecarga de token é reduzir o número de SIDs associados a contas de usuário, seja racionalizando associações de grupo, eliminando o histórico de SID ou uma combinação de ambos. Para obter mais informações sobre a sobrecarga de token, consulte Sobrecarga de token Kerberos e MaxTokenSize.
Em vez de migrar usuários de um ambiente herdado (particularmente aquele em que associações de grupo e históricos de SID podem ser comprometidos) usando o histórico de SID, considere aproveitar aplicativos de metadiretório para "migrar" usuários, sem levar históricos de SID para a nova floresta. Quando as contas de usuário são criadas na nova floresta, você pode usar um aplicativo de metadiretório para mapear as contas para suas contas correspondentes na floresta herdada.
Para fornecer às novas contas de usuário acesso aos recursos na floresta herdada, você pode usar as ferramentas de metadiretório para identificar grupos de recursos nos quais as contas herdadas dos usuários receberam acesso e, em seguida, adicionar as novas contas dos usuários a esses grupos. Dependendo da estratégia de grupo na floresta herdada, talvez seja necessário criar grupos locais de domínio para acesso a recursos ou converter grupos existentes em grupos locais de domínio para permitir que as novas contas sejam adicionadas aos grupos de recursos. Focando primeiro nos aplicativos e dados mais importantes e migrando-os para o novo ambiente (com ou sem histórico de SID), você pode limitar a quantidade de esforço gasto no ambiente herdado.
Servidores e estações de trabalho
Em uma migração tradicional de uma floresta do Active Directory para outra, a migração de computadores geralmente é simples em comparação com a migração de usuários, grupos e aplicativos. Dependendo da função de computador, a migração para uma nova floresta pode ser tão simples quanto a desativação de um domínio antigo e ingresso em um novo. No entanto, a migração de contas de computador intactas para uma floresta primitiva anula a finalidade de criação de um ambiente novo. Em vez de migrar contas de computador (potencialmente comprometidas, configuradas incorretamente ou desatualizadas) para uma nova floresta, você deve instalar servidores e estações de trabalho no novo ambiente. Você pode migrar dados de sistemas na floresta herdada para sistemas na floresta primitiva, mas não os sistemas que hospedam os dados.
Aplicativos
Os aplicativos podem apresentar o desafio mais significativo em qualquer migração de uma floresta para outra, mas no caso de uma migração "nãomigratória", um dos princípios mais básicos que você deve aplicar é que os aplicativos na floresta primitiva devem ser atuais, compatíveis e instalados recentemente. Os dados podem ser migrados de instâncias de aplicativo na floresta antiga, sempre que possível. Em situações em que um aplicativo não pode ser "recriado" na floresta primitiva, você deve considerar abordagens como destruição criativa ou isolamento de aplicativos herdados, conforme descrito na seção a seguir.
Implementar a destruição criativa
Destruição criativa é um termo de economia que descreve o desenvolvimento econômico criado pela destruição de uma ordem anterior. Nos últimos anos, o termo foi aplicado à tecnologia da informação. Normalmente, ele se refere a mecanismos pelos quais a infraestrutura antiga é eliminada, não atualizando-a, mas substituindo-a por algo completamente novo. O Gartner Symposium ITXPO para CIOs e executivos seniores de TI de 2011 apresentou a destruição criativa como um de seus principais temas para redução de custos e maior eficiência. Melhorias na segurança são possíveis como um crescimento natural do processo.
Por exemplo, uma organização pode ser composta por várias unidades de negócios que usam um aplicativo diferente que executa funcionalidades semelhantes, com diferentes graus de modernidade e suporte do fornecedor. Historicamente, a TI pode ser responsável por manter o aplicativo de cada unidade de negócios separadamente, e os esforços de consolidação consistiriam em tentar descobrir qual aplicativo oferecia a melhor funcionalidade e, em seguida, migrar dados para esse aplicativo dos outros.
Na destruição criativa, em vez de manter aplicativos desatualizados ou redundantes, você implementa aplicativos totalmente novos para substituir os antigos, migrar dados para os novos aplicativos e desativar os aplicativos antigos e os sistemas nos quais eles são executados. Em alguns casos, você pode implementar a destruição criativa de aplicativos herdados implantando um novo aplicativo em sua própria infraestrutura, mas, sempre que possível, você deve considerar a portabilidade do aplicativo para uma solução baseada em nuvem.
Ao implantar aplicativos baseados em nuvem para substituir aplicativos internos herdados, você não reduz apenas os esforços e os custos de manutenção, mas a superfície de ataque da sua organização eliminando sistemas herdados e aplicativos que apresentam vulnerabilidades para os invasores aproveitarem. Essa abordagem fornece uma maneira mais rápida para uma organização obter a funcionalidade desejada e, ao mesmo tempo, eliminar metas herdadas na infraestrutura. Embora o princípio de destruição criativa não se aplique a todos os ativos de TI, ele fornece uma opção muitas vezes viável para eliminar sistemas e aplicativos herdados, ao mesmo tempo em que implanta aplicativos robustos, seguros e baseados em nuvem.
Isolar sistemas e aplicativos herdados
Um crescimento natural da migração de seus usuários e sistemas comercialmente críticos para um ambiente seguro e primitivo é que sua floresta herdada conterá informações e sistemas menos valiosos. Embora os sistemas herdados e os aplicativos que permanecem no ambiente menos seguro possam apresentar um risco elevado de comprometimento, eles também representam uma gravidade reduzida. Ao hospedar novamente e modernizar seus ativos de negócios críticos, você pode se concentrar na implantação de gerenciamento e monitoramento eficazes, sem precisar acomodar configurações e protocolos herdados.
Ao remover esses sistemas de domínios em que eles forçaram a implementação de configurações herdadas, você pode aumentar posteriormente a segurança dos domínios configurando-os para dar suporte apenas aos sistemas operacionais e aplicativos atuais. Embora seja preferível desativar sistemas e aplicativos herdados sempre que possível. Se a desativação não for viável para um pequeno segmento de sua população herdada, a separação do domínio (ou floresta) permitirá que você execute melhorias incrementais no restante da instalação herdada.
Simplificar a segurança para usuários finais
Na maioria das organizações, os usuários que têm acesso às informações mais confidenciais devido à natureza de suas funções na organização geralmente têm a menor quantidade de tempo para se dedicar ao aprendizado de restrições e controles de acesso complexos. Embora você deva ter um programa abrangente de educação em segurança para todos os usuários em sua organização, você também deve se concentrar em tornar o uso da segurança o mais simples possível implementando controles transparentes e simplificando os princípios aos quais os usuários aderem.
Por exemplo, você pode definir uma política na qual executivos e outros VIPs são obrigados a usar estações de trabalho seguras para acessar dados e sistemas confidenciais, permitindo que eles usem outros dispositivos para acessar dados menos confidenciais. Esse é um princípio simples para os usuários se lembrarem, mas você pode implementar vários controles de back-end para ajudar a impor a abordagem.
Você pode usar a Garantia do mecanismo de autenticação para permitir que os usuários acessem dados confidenciais somente se eles tiverem feito logon em seus sistemas seguros usando seus cartões inteligentes e podem usar restrições de direitos de usuário e IPsec para controlar os sistemas dos quais eles podem se conectar a repositórios de dados confidenciais. Você pode implementar o Controle de Acesso Dinâmico para restringir o acesso a dados com base nas características de uma tentativa de acesso, convertendo regras de negócios em controles técnicos.
Da perspectiva do usuário, o acesso a dados confidenciais de um sistema seguro "simplesmente funciona" e tentar fazê-lo de um sistema não seguro "simplesmente não funciona". No entanto, do ponto de vista do monitoramento e do gerenciamento do seu ambiente, você está ajudando a criar padrões identificáveis em como os usuários acessam dados e sistemas confidenciais, facilitando a detecção de tentativas anormais de acesso.
Em ambientes em que a resistência do usuário a senhas longas e complexas resultou em políticas de senha insuficientes, especialmente para usuários VIP, considere abordagens alternativas à autenticação. Abordagens alternativas incluem cartões inteligentes (que vêm em uma série de fatores forma e com recursos adicionais para fortalecer a autenticação), controles biométricos, como leitores de passar o dedo ou até mesmo dados de autenticação protegidos por chips de TPM (Trusted Platform Module) nos computadores dos usuários. A autenticação multifator não impede ataques de roubo de credenciais se um computador já está comprometido. Porém, ao fornecer aos usuários controles de autenticação fáceis de usar, você pode atribuir senhas mais robustas às contas de usuários para os quais os controles tradicionais de nome de usuário e senha são difíceis.