Implementar modelos administrativos com menos privilégios

O trecho a seguir é do Guia de Planejamento de Segurança de Contas de Administrador, publicado pela primeira vez em 1º de abril de 1999:

"A maioria dos cursos de treinamento relacionados à segurança e a documentação discute a implementação de um princípio de privilégios mínimos, mas as organizações raramente o seguem. O princípio é simples e o impacto de aplicá-lo corretamente aumenta muito sua segurança e reduz o risco. O princípio determina que todos os usuários devem fazer logon com uma conta de usuário que tenha as permissões mínimas absolutas necessárias para concluir a tarefa atual e nada mais. Fazer isso fornece proteção contra códigos mal-intencionados, entre outros ataques. Esse princípio se aplica aos computadores e aos usuários desses computadores. "Uma das razões pelas quais esse princípio funciona tão bem é que força você a fazer algumas pesquisas internas. Por exemplo, você deve determinar os privilégios de acesso de que um computador ou usuário realmente precisa e implementá-los. Para muitas organizações, essa tarefa pode inicialmente parecer um grande trabalho; no entanto, é uma etapa essencial para proteger com êxito seu ambiente de rede. "Você deve conceder a todos os usuários administradores de domínio seus privilégios de domínio sob o conceito de privilégio mínimo. Por exemplo, se um administrador fizer logon com uma conta privilegiada e executar inadvertidamente um programa de vírus, o vírus terá acesso administrativo ao computador local e a todo o domínio. Se o administrador tivesse feito logon com uma conta não privilegiada (não administrativa), o escopo de danos do vírus seria apenas o computador local, pois ele é executado como um usuário de computador local. "Em outro exemplo, as contas às quais você concede direitos de administrador no nível de domínio não devem ter direitos elevados em outra floresta, mesmo que haja uma relação de confiança entre as florestas. Essa tática ajuda a evitar danos generalizados se um invasor conseguir comprometer uma floresta gerenciada. As organizações devem auditar regularmente sua rede para protegerem-se contra escalonamento não autorizado de privilégios."

O seguinte trecho é do Kit de Recursos de Segurança do Microsoft Windows, publicado pela primeira vez em 2005:

"Sempre pense em segurança em termos de conceder a menor quantidade de privilégios necessários para realizar a tarefa. Se um aplicativo com muitos privilégios for comprometido, o invasor poderá conseguir expandir o ataque além do que conseguiria se o aplicativo tivesse a menor quantidade de privilégios possível. Por exemplo, examine as consequências de um administrador de rede abrir involuntariamente um anexo de email que inicia um vírus. Se o administrador estiver conectado usando a conta de administrador de domínio, o vírus terá privilégios de Administrador em todos os computadores no domínio, portanto, acesso irrestrito a quase todos os dados na rede. Se o administrador estiver conectado usando uma conta de Administrador local, o vírus terá privilégios de Administrador no computador local, portanto, poderá acessar todos os dados no computador e instalar software mal-intencionado, como software de registro em log de traço de chave no computador. Se o administrador estiver conectado usando uma conta de usuário normal, o vírus terá acesso somente aos dados do administrador e não poderá instalar software mal-intencionado. Usando os privilégios mínimos necessários para ler emails, neste exemplo, o escopo potencial do comprometimento é muito reduzido."

O problema do privilégio

Os princípios descritos nos trechos anteriores não foram alterados, porém, ao avaliar as instalações do Active Directory, invariavelmente encontramos um número excessivo de contas que receberam direitos e permissões muito além das necessárias para executar o trabalho diário. O tamanho do ambiente afeta o número bruto de contas com privilégios excessivos, mas não a proporção; diretórios de tamanhão médio podem ter dezenas de contas nos grupos mais privilegiados, enquanto grandes instalações podem ter centenas ou até milhares. Com poucas exceções, independentemente da sofisticação das habilidades e do arsenal de um atacante, os invasores normalmente seguem o caminho de menor resistência. Eles aumentam a complexidade de suas ferramentas e abordagem somente se e quando mecanismos mais simples falham ou são derrotados pelas defesas.

Infelizmente, o caminho de menor resistência em muitos ambientes é o uso excessivo de contas com privilégios amplos e profundos. Privilégios amplos são direitos e permissões que permitem que uma conta execute atividades específicas em uma grande seção transversal do ambiente. Por exemplo, a equipe de suporte técnico pode receber permissões para redefinir as senhas em muitas contas de usuário.

Privilégios profundos são privilégios poderosos aplicados a um pequeno segmento da população, como dar a um engenheiro direitos de administrador em um servidor para que ele possa executar reparos. Nenhum privilégio amplo nem privilégio profundo é necessariamente perigoso, porém, quando muitas contas no domínio recebem permanentemente privilégios amplos e profundos, se apenas uma delas for comprometida, essa conta poderá ser usada rapidamente para reconfigurar o ambiente para os fins do invasor ou até mesmo para destruir grandes segmentos da infraestrutura.

Os ataques de pass-the-hash, que são um tipo de ataque de roubo de credencial, são onipresentes porque as ferramentas para executá-los estão livremente disponíveis e são fáceis de usar, e também porque muitos ambientes são vulneráveis aos ataques. Os ataques de pass-the-hash, no entanto, não são o verdadeiro problema. O cerne do problema é duplo:

1. Geralmente, é fácil para um invasor obter privilégios profundos em um só computador e então propagar esse privilégio amplamente para outros computadores.
2. Geralmente, há muitas contas permanentes com altos níveis de privilégio em todo o cenário de computação.

Mesmo que os ataques de pass-the-hash fossem eliminados, os invasores simplesmente usariam táticas diferentes, não uma estratégia diferente. Em vez de plantar malware que contenha ferramentas de roubo de credenciais, eles podem plantar malware que registre em log pressionamentos de tecla ou aproveitar várias outras abordagens para capturar credenciais poderosas em todo o ambiente. Independentemente das táticas, os destinos permanecem os mesmos: contas com privilégios amplos e profundos.

A concessão de privilégio excessivo não é encontrada apenas no Active Directory em ambientes comprometidos. Quando uma organização desenvolve o hábito de conceder mais privilégios do que o necessário, isso normalmente é encontrado em toda a infraestrutura, conforme discutido nas seções a seguir.

No Active Directory

No Active Directory, é comum descobrir que os grupos EA, DA e BA contêm um número excessivo de contas. Mais comumente, o grupo EA de uma organização contém o menor número de membros, os grupos de DA geralmente contêm um multiplicador do número de usuários no grupo EA, e os grupos administradores geralmente contêm mais membros do que as populações dos outros grupos combinados. Isso geralmente ocorre devido a uma crença de que os administradores são de alguma forma "menos privilegiados" do que DAs ou EAs. Embora os direitos e permissões concedidos a cada um desses grupos sejam diferentes, eles devem ser efetivamente considerados grupos igualmente poderosos porque um membro de um pode se tornar um membro dos outros dois.

Em servidores membros

Quando recuperamos a associação de grupos de administradores locais em servidores membros em muitos ambientes, encontramos associações que variam de algumas contas locais e de domínio a dezenas de grupos aninhados que, quando expandidos, revelam centenas, até milhares, de contas com privilégio de administrador local nos servidores. Em muitos casos, os grupos de domínio com associações grandes são aninhados em grupos de administradores locais dos servidores membros, sem considerar o fato de que qualquer usuário que possa modificar as associações desses grupos no domínio pode obter controle administrativo de todos os sistemas nos quais o grupo foi aninhado em um grupo de Administradores local.

Em estações de trabalho

Embora as estações de trabalho normalmente tenham significativamente menos membros em seus grupos de Administradores locais do que os servidores membros, em muitos ambientes, os usuários recebem associação no grupo administradores local em seus computadores pessoais. Quando isso ocorre, mesmo que o UAC esteja habilitado, esses usuários representam um risco elevado à integridade de suas estações de trabalho.

Em aplicativos

Em ataques nos quais o destino é propriedade intelectual de uma organização, contas que receberam privilégios poderosos em aplicativos podem ser alvos para permitir a exfiltração de dados. Embora as contas que têm acesso a dados confidenciais possam não ter recebido privilégios elevados no domínio ou no sistema operacional, contas que podem manipular a configuração de um aplicativo ou acesso às informações que o aplicativo fornece representam um risco.

Em repositórios de dados

Como é o caso de outros destinos, os invasores que buscam acesso à propriedade intelectual na forma de documentos e outros arquivos podem ter como alvo contas que controlam o acesso aos repositórios de arquivos, contas que têm acesso direto aos arquivos ou até mesmo grupos ou funções que têm acesso aos arquivos. Por exemplo, se um servidor de arquivos for usado para armazenar documentos de contrato e o acesso for concedido aos documentos pelo uso de um grupo do Active Directory, um invasor que pode modificar a associação do grupo poderá adicionar contas comprometidas ao grupo e acessar os documentos do contrato. Nos casos em que o acesso a documentos é fornecido por aplicativos como o SharePoint, os invasores podem ter aplicativos como alvo, conforme já descrito.

Reduzir privilégios

Quanto maior e mais complexo um ambiente, mais difícil é gerenciar e proteger. Em pequenas organizações, a revisão e a redução de privilégios podem ser propostas relativamente simples, mas cada servidor, estação de trabalho, conta de usuário e aplicativo adicional em uso em uma organização é mais um objeto que deve ser protegido. Como pode ser difícil ou até mesmo impossível proteger corretamente todos os aspectos da infraestrutura de TI de uma organização, você deve concentrar os esforços primeiro nas contas cujo privilégio cria o maior risco, que normalmente são as contas e grupos privilegiados internos no Active Directory e contas locais privilegiadas em estações de trabalho e servidores membros.

Proteger contas de administrador local em estações de trabalho e servidores membros

Embora este documento se concentre em proteger o Active Directory, como já foi discutido, a maioria dos ataques contra o diretório começa como ataques contra hosts individuais. Não é possível fornecer diretrizes completas para proteger grupos locais em sistemas membros, mas as recomendações a seguir podem ser usadas para ajudá-lo a proteger as contas de administrador locais em estações de trabalho e servidores membros.

Como proteger contas de administrador local

Em todas as versões do Windows atualmente com o suporte base, a conta de Administrador local está desabilitada por padrão, o que torna a conta inutilizável para ataques de roubo de credenciais e Pass-the-Hash. No entanto, em domínios que contêm sistemas operacionais herdados ou em que contas de administrador locais foram habilitadas, essas contas podem ser usadas conforme já descrito para propagar o comprometimento entre servidores membros e estações de trabalho. Por esse motivo, os controles a seguir são recomendados para todas as contas de Administrador local em sistemas conectados ao domínio.

Instruções detalhadas para implementar esses controles são apresentadas no Apêndice H: Como proteger contas e grupos de administradores locais. No entanto, antes de implementar essas configurações, verifique se as contas de administrador locais não são usadas atualmente no ambiente para executar serviços em computadores ou executar outras atividades para as quais essas contas não devem ser usadas. Teste essas configurações detalhadamente antes de implementá-las em um ambiente de produção.

Controles para contas de Administrador local

Contas de administrador interno nunca devem ser usadas como contas de serviço em servidores membros, nem devem ser usadas para fazer logon em computadores locais (exceto no Modo de Segurança, que é permitido mesmo se a conta está desabilitada). A meta de implementar as configurações descritas aqui é impedir que a conta de administrador local de cada computador seja utilizável, a menos que os controles de proteção primeiro sejam revertidos. Ao implementar esses controles e monitorar contas de administrador para alterações, você pode reduzir significativamente a probabilidade de sucesso de um ataque direcionado a contas de administrador locais.

Configurar GPOs para restringir contas de administrador em sistemas conectados ao domínio

Em um ou mais GPOs que você cria e vincula às UOs de servidor membro e de estação de trabalho em cada domínio, adicione a conta de Administrador aos seguintes direitos de usuário em Configuração do Computador\Políticas\Configurações do Windows\Configurações de Segurança\Políticas Locais\Atribuições de Direitos do Usuário:

• Negar acesso a este computador pela rede
• Negar o logon como um trabalho em lotes
• Negar o logon como um serviço
• Negar o logon por meio dos Serviços de Área de Trabalho Remota

Ao adicionar contas de administrador a esses direitos do usuário, especifique se você está adicionando a conta de Administrador local ou a conta de Administrador do domínio pela maneira como rotula a conta. Por exemplo, para adicionar a conta administrador do domínio NWTRADERS a esses direitos de negação, digite a conta como NWTRADERS\Administrator ou navegue até a conta administrador do domínio NWTRADERS. Para garantir que você restrinja a conta de Administrador local, digite Administrador nessas configurações de direitos do usuário no Editor de Objeto de Política de Grupo.

Essas configurações garantirão que a conta de Administrador de um computador não possa ser usada para se conectar aos outros computadores, mesmo que ela seja habilitada de modo inadvertido ou mal-intencionado. Logons locais que usam a conta de Administrador local não podem ser completamente desabilitados, nem você deve tentar fazer isso, pois a conta de administrador local de um computador foi projetada para ser usada em cenários de recuperação de desastre.

Se um servidor membro ou estação de trabalho ficar desconectado do domínio sem que outras contas locais recebam privilégios administrativos, o computador poderá ser inicializado no modo de segurança, a conta administrador poderá ser habilitada e a conta então poderá ser usada para efetuar reparos no computador. Quando os reparos forem concluídos, a conta administrador deverá ser desabilitada novamente.

Proteger contas e grupos privilegiados locais no Active Directory

Lei Número Seis: um computador é tão seguro quanto o administrador é confiável. - Dez leis imutáveis da segurança (versão 2.0)

As informações fornecidas aqui têm como objetivo fornecer diretrizes gerais para proteger as contas e grupos internos de privilégios mais altos no Active Directory. Instruções passo a passo detalhadas também são apresentadas no Apêndice D: Como proteger conta de administrador interno no Active Directory, Apêndice E: Como proteger grupos de administradores corporativos no Active Directory, Apêndice F: Como proteger grupos de administradores de domínio no Active Directory e no Apêndice G: Como proteger grupos de administradores no Active Directory.

Antes de implementar qualquer uma dessas configurações, você também deve testar todas as configurações detalhadamente para determinar se elas são apropriadas para seu ambiente. Nem todas as organizações poderão implementar essas configurações.

Como proteger contas de administrador interno no Active Directory

Em cada domínio no Active Directory, uma conta de Administrador é criada como parte da criação do domínio. Essa conta é, por padrão, membro dos grupos Administradores de Domínio e Administradores no domínio e, se o domínio for o domínio raiz da floresta, a conta também será membro do grupo Administradores Corporativos. O uso da conta de administrador local de um domínio deve ser reservado apenas para atividades de build iniciais e, possivelmente, cenários de recuperação de desastre. Para garantir que uma conta de Administrador interno possa ser usada para realizar reparos caso nenhuma outra conta possa ser usada, você não deve alterar a associação padrão da conta administrador em nenhum domínio na floresta. Em vez disso, siga as diretrizes para ajudar a proteger a conta de administrador em cada domínio na floresta. Instruções detalhadas para implementar esses controles são apresentadas no Apêndice D: Como proteger contas de administrador interno no Active Directory.

Controles para contas de administrador interno

A meta de implementar as configurações descritas aqui é impedir que a conta de administrador de cada domínio (não um grupo) seja utilizável, a menos que vários controles sejam revertidos. Implementando esses controles e monitorando as contas de Administrador para alterações, você pode reduzir significativamente a probabilidade de um ataque bem-sucedido aproveitando a conta de administrador de um domínio. Para a conta administrador em cada domínio em sua floresta, defina as configurações a seguir.

Habilite na conta o sinalizador "A conta é confidencial e não pode ser delegada na conta"

Por padrão, todas as contas no Active Directory podem ser delegadas. A delegação permite que um computador ou serviço apresente as credenciais de uma conta autenticada no computador ou serviço para outros computadores para obter serviços em nome da conta. Quando você habilita o atributo Conta é confidencial e não pode ser delegada em uma conta baseada em domínio, as credenciais da conta não podem ser apresentadas a outros computadores ou serviços na rede, o que limita ataques que aproveitam a delegação para usar as credenciais da conta em outros sistemas.

Habilite na conta o sinalizador "O cartão inteligente é obrigatório para o logon interativo"

Quando você habilita o atributo O cartão inteligente é necessário para logon interativo em uma conta, o Windows redefine a senha da conta para um valor aleatório de 120 caracteres. Ao definir esse sinalizador em contas de administrador interno, você garante que a senha da conta não seja apenas longa e complexa, como também não seja conhecida por nenhum usuário. Tecnicamente, não é necessário criar cartões inteligentes para as contas antes de habilitar esse atributo, mas, se possível, os cartões inteligentes devem ser criados para cada conta de administrador antes de configurar as restrições de conta e os cartões inteligentes devem ser armazenados em locais seguros.

Embora a configuração do sinalizador O cartão inteligente é necessário para logon interativo redefina a senha da conta, ela não impede que um usuário com direitos para redefinir a senha da conta defina a conta como um valor conhecido e use o nome da conta e a nova senha para acessar recursos na rede. Por isso, implemente os controles adicionais a seguir na conta.

Como configurar GPOs para restringir contas de administrador de domínios em sistemas conectados ao domínio

Embora desabilitar a conta de Administrador em um domínio torne a conta efetivamente inutilizável, você deve implementar restrições adicionais na conta caso ela seja habilitada de modo inadvertido ou mal-intencionado. Embora esses controles possam, em última análise, ser revertidos pela conta administrador, a meta é criar controles que retardem o progresso de um invasor e limitem os danos que a conta pode causar.

Em um ou mais GPOs que você cria e vincula às OUs de servidor membro e de estação de trabalho em cada domínio, adicione a conta Administrador de cada domínio aos seguintes direitos de usuário em Configuração do Computador\Políticas\Configurações do Windows\Configurações de Segurança\Políticas Locais\Atribuições de Direitos do Usuário:

• Negar acesso a este computador pela rede
• Negar o logon como um trabalho em lotes
• Negar o logon como um serviço
• Negar o logon por meio dos Serviços de Área de Trabalho Remota

Como configurar GPOs para restringir contas de administrador em controladores de domínio

Em cada domínio na floresta, a política Controladores de Domínio Padrão ou uma política vinculada à UO controladores de domínio deve ser modificada para adicionar a conta de administrador de cada domínio aos seguintes direitos do usuário em Configuração do Computador\Políticas\Configurações do Windows\Configurações de Segurança\Políticas Locais\Atribuições de Direitos do Usuário:

• Negar acesso a este computador pela rede
• Negar o logon como um trabalho em lotes
• Negar o logon como um serviço
• Negar o logon por meio dos Serviços de Área de Trabalho Remota

Configurar a auditoria de contas de administrador interno

Quando você tiver protegido a conta de administrador de cada domínio e desabilitado, deverá configurar a auditoria para monitorar as alterações na conta. Se a conta estiver habilitada, sua senha for redefinida ou qualquer outra modificação for feita à conta, os alertas deverão ser enviados aos usuários ou equipes responsáveis pela administração do AD DS, além das equipes de resposta a incidentes em sua organização.

Como proteger administradores, administradores de domínio e grupos de administradores corporativos

Como proteger grupos admin corporativos

O grupo de administradores corporativos, hospedado no domínio raiz da floresta, não deve conter usuários no dia a dia, com a possível exceção da conta de administrador local do domínio, desde que seja protegida conforme descrito anteriormente e no Apêndice D: Como proteger contas de administrador interno no Active Directory.

Quando o acesso ao EA é necessário, os usuários cujas contas exigem direitos e permissões do EA devem ser colocados temporariamente no grupo de administradores corporativos. Embora os usuários estejam usando as contas altamente privilegiadas, suas atividades devem ser auditadas e preferencialmente executadas com um usuário executando as alterações e outro usuário observando as alterações para minimizar a probabilidade de uso indevido inadvertido ou configuração incorreta. Quando as atividades tiverem sido concluídas, as contas deverão ser removidas do grupo EA. Isso pode ser obtido por meio de procedimentos manuais e processos documentados, software PIM/PAM (gerenciamento de identidade/acesso privilegiado) de terceiros ou uma combinação de ambos. As diretrizes para a criação de contas que podem ser usadas para controlar a associação de grupos privilegiados no Active Directory são fornecidas em Contas Atraentes para Roubo de Credenciais e instruções detalhadas são fornecidas no Apêndice I: Como criar contas de gerenciamento para contas e grupos protegidos no Active Directory.

Os administradores corporativos são, por padrão, membros do grupo administradores internos em cada domínio na floresta. A remoção do grupo administradores corporativos dos grupos administradores em cada domínio é uma modificação inadequada porque, no caso de um cenário de recuperação de desastre de floresta, os direitos de EA provavelmente serão necessários. Se o grupo de administradores corporativos tiver sido removido dos grupos de administradores em uma floresta, ele deverá ser adicionado ao grupo de administradores em cada domínio e os seguintes controles adicionais deverão ser implementados:

• Conforme descrito anteriormente, o grupo de administradores corporativos não deve conter usuários no dia a dia, com a possível exceção da conta de administrador do domínio raiz da floresta, que deve ser protegida conforme descrito no Apêndice D: Como proteger contas de administrador interno no Active Directory.
• Em GPOs vinculados a UOs que contêm servidores membros e estações de trabalho em cada domínio, o grupo de EA deve ser adicionado aos seguintes direitos do usuário:
  • Negar acesso a este computador pela rede
  • Negar o logon como um trabalho em lotes
  • Negar o logon como um serviço
  • Negar o logon localmente
  • Negar o logon por meio dos Serviços de Área de Trabalho Remota.

Isso impedirá que os membros do grupo EA faça logon em servidores membros e estações de trabalho. Se jump servers forem usados para administrar os controladores de domínio e o Active Directory, verifique se os jump servers estão localizados em uma UO à qual GPOs restritivos não estão vinculados.

• A auditoria deve ser configurada para enviar alertas se alguma modificação for feita nas propriedades ou na associação do grupo de EA. Esses alertas devem ser enviados, no mínimo, para usuários ou equipes responsáveis pela administração do Active Directory e pela resposta a incidentes. Você também deve definir processos e procedimentos para preencher temporariamente o grupo de EA, incluindo procedimentos de notificação quando a população legítima do grupo é executada.

Como proteger grupos de administrador de domínio

Como é o caso do grupo de administradores corporativos, a associação em grupos de administradores de domínio deve ser necessária apenas em cenários de build ou recuperação de desastre. Não deve haver contas de usuário diárias no grupo DA, com exceção da conta de administrador local do domínio, se ela tiver sido protegida conforme descrito em Apêndice D: Como proteger contas de administrador interno no Active Directory.

Quando o acesso ao DA é necessário, as contas que precisam desse nível de acesso devem ser temporariamente colocadas no grupo de DA para o domínio em questão. Embora os usuários estejam usando as contas altamente privilegiadas, as atividades devem ser auditadas e preferencialmente executadas com um usuário executando as alterações e outro usuário observando as alterações para minimizar a probabilidade de uso indevido inadvertido ou configuração incorreta. Quando as atividades tiverem sido concluídas, as contas deverão ser removidas do grupo de administradores de domínio. Isso pode ser obtido por meio de procedimentos manuais e processos documentados usando software PIM/PAM (gerenciamento de identidade privilegiada/acesso) de terceiros ou uma combinação de ambos. As diretrizes para a criação de contas que podem ser usadas para controlar a associação de grupos privilegiados no Active Directory são fornecidas no Apêndice I: Como criar contas de gerenciamento para contas e grupos protegidos no Active Directory.

Os Administradores do Domínio são, por padrão, membros dos grupos Administradores locais em todos os servidores membro e estações de trabalho nos respectivos domínios. Esse aninhamento padrão não deve ser modificado porque afeta as opções de suporte e recuperação de desastre. Se os grupos de administradores de domínio tiverem sido removidos dos grupos de administradores locais nos servidores membros, eles deverão ser adicionados ao grupo de administradores em cada servidor membro e estação de trabalho no domínio por meio de configurações de grupo restritas em GPOs vinculados. Os seguintes controles gerais, descritos detalhadamente no Apêndice F: Como proteger grupos de administradores de domínio no Active Directory também devem ser implementados.

Para o grupo Administradores do Domínio em cada domínio da floresta:

1. Remova todos os membros do grupo de DA, com a possível exceção da conta de administrador interno do domínio, desde que ela tenha sido protegida, conforme descrito no Apêndice D: Como proteger contas de administrador interno no Active Directory.

2. Em GPOs vinculados a UOs que contêm servidores membros e estações de trabalho em cada domínio, o grupo da DA deve ser adicionado aos seguintes direitos do usuário:

   • Negar acesso a este computador pela rede
   • Negar o logon como um trabalho em lotes
   • Negar o logon como um serviço
   • Negar o logon localmente
   • Negar o logon por meio dos Serviços de Área de Trabalho Remota

   Isso impedirá que os membros do grupo de DA façam logon em servidores membros e estações de trabalho. Se jump servers forem usados para administrar os controladores de domínio e o Active Directory, verifique se os jump servers estão localizados em uma UO à qual GPOs restritivos não estão vinculados.

3. A auditoria deve ser configurada para enviar alertas se alguma modificação for feita nas propriedades ou na associação de grupo de DA. Esses alertas devem ser enviados, no mínimo, para usuários ou equipes responsáveis pela administração do AD DS e pela resposta a incidentes. Você também deve definir processos e procedimentos para preencher temporariamente o grupo de DA, incluindo procedimentos de notificação quando a população legítima do grupo é executada.

Como proteger grupos de administradores no Active Directory

Como ocorre nos grupos de EA e de AD, a associação no grupo de BA (conta de administradores) deve ser necessária somente em cenários de recuperação de desastre ou de build. Não deve haver contas de usuário diárias no grupo de administradores, com exceção da conta administrador local do domínio, se ela tiver sido protegida conforme descrito no Apêndice D: Como proteger contas de administrador interno no Active Directory.

Quando o acesso de administradores é necessário, as contas que precisam desse nível de acesso devem ser colocadas temporariamente no grupo de administradores para o domínio em questão. Embora os usuários estejam usando as contas altamente privilegiadas, as atividades devem ser auditadas e preferencialmente executadas com um usuário executando as alterações e outro usuário observando as alterações para minimizar a probabilidade de uso indevido inadvertido ou configuração incorreta. Quando as atividades tiverem sido concluídas, as contas deverão ser removidas imediatamente do grupo de administradores. Isso pode ser obtido por meio de procedimentos manuais e processos documentados usando software PIM/PAM (gerenciamento de identidade privilegiada/acesso) de terceiros ou uma combinação de ambos.

Os administradores são, por padrão, os proprietários da maioria dos objetos do AD DS em seus respectivos domínios. A associação a esse grupo pode ser necessária em cenários de recuperação de desastre e build em que a propriedade ou a capacidade de assumir a propriedade de objetos é necessária. Além disso, os ADs e EAs herdam vários de seus direitos e permissões em virtude da associação padrão no grupo de administradores. O aninhamento de grupo padrão para grupos privilegiados no Active Directory não deve ser modificado e o grupo de administradores de cada domínio deve ser protegido conforme descrito no Apêndice G: Como proteger grupos de administradores no Active Directory e nas instruções gerais abaixo.

1. Remova todos os membros do grupo de administradores, com a possível exceção da conta administrador local para o domínio, desde que ele tenha sido protegido, conforme descrito no Apêndice D: Como proteger contas de administrador interno no Active Directory.

2. Os membros do grupo de administradores do domínio nunca devem precisar fazer logon em servidores membros ou estações de trabalho. Em um ou mais GPOs vinculados à estação de trabalho e às OUs do servidor membro em cada domínio, o grupo de administradores deve ser adicionado aos seguintes direitos do usuário:

   • Negar acesso a este computador pela rede
   • Negar o logon como um trabalho em lotes
   • Negar o logon como um serviço
   • Isso impedirá que membros do grupo de administradores sejam usados para fazer logon ou se conectar a servidores membros ou estações de trabalho (a menos que vários controles sejam violados pela primeira vez), em que suas credenciais podem ser armazenadas em cache e, assim, comprometidas. Uma conta privilegiada nunca deve ser usada para fazer logon em um sistema menos privilegiado e impor esses controles oferece proteção contra uma série de ataques.

3. Na UO dos controladores de domínio em cada domínio na floresta, o grupo de administradores deverá receber os seguintes direitos do usuário (se eles ainda não tiverem esses direitos), o que permitirá que os membros do grupo de administradores executem as funções necessárias para um cenário de recuperação de desastre em toda a floresta:

   • Acesso a este computador da rede
   • Permitir logon localmente
   • Permitir logon por meio dos Serviços de Área de Trabalho Remota

4. A auditoria deve ser configurada para enviar alertas se alguma modificação for feita nas propriedades ou na associação do grupo de administradores. Esses alertas devem ser enviados, no mínimo, aos membros da equipe responsável pela administração do AD DS. Os alertas também devem ser enviados aos membros da equipe de segurança e os procedimentos devem ser definidos para modificar a associação do grupo de administradores. Especificamente, esses processos devem incluir um procedimento pelo qual a equipe de segurança é notificada quando o grupo de administradores será modificado para que, quando os alertas forem enviados, eles sejam esperados e um alarme não seja acionado. Além disso, os processos para notificar a equipe de segurança quando o uso do grupo Administradores tiver sido concluído e as contas usadas tiverem sido removidas do grupo devem ser implementadas.

RBAC (controles de acesso baseados em função) para o Active Directory

Em geral, os RBAC (controles de acesso baseados em função) são um mecanismo para agrupar usuários e fornecer acesso a recursos com base em regras de negócios. No caso do Active Directory, implementar o RBAC para AD DS é o processo de criação de funções às quais direitos e permissões são delegados para permitir que os membros da função executem tarefas administrativas diárias sem lhes conceder privilégios excessivos. O RBAC para Active Directory pode ser projetado e implementado por meio de ferramentas e interfaces nativas, aproveitando o software que você talvez já tenha, comprando produtos de terceiros ou qualquer combinação dessas abordagens. Esta seção não fornece instruções passo a passo para implementar o RBAC para o Active Directory, mas discute os fatores que você deve considerar ao escolher uma abordagem para implementar o RBAC em suas instalações do AD DS.

Abordagens nativas para RBAC para Active Directory

Na implementação mais simples do RBAC, você pode implementar funções como grupos do AD DS e delegar direitos e permissões aos grupos que permitem que eles executem a administração diária dentro do escopo designado da função.

Em alguns casos, os grupos de segurança existentes no Active Directory podem ser usados para conceder direitos e permissões apropriados a uma função de trabalho. Por exemplo, se funcionários específicos em sua organização de TI forem responsáveis pelo gerenciamento e manutenção de registros e zonas DNS, delegar essas responsabilidades poderá ser tão simples quanto criar uma conta para cada administrador DNS e adicioná-la ao grupo de administradores de DNS no Active Directory. O grupo de administradores de DNS, ao contrário de grupos mais altamente privilegiados, tem poucos direitos poderosos em todo o Active Directory, embora os membros desse grupo tenham recebido permissões que lhes permitem administrar o DNS e ainda está sujeito a comprometimentos e abusos podem resultar em elevação de privilégio.

Em outros casos, talvez seja necessário criar grupos de segurança e delegar direitos e permissões para objetos do Active Directory, objetos do sistema de arquivos e objetos do Registro para permitir que os membros dos grupos executem tarefas administrativas designadas. Por exemplo, se os operadores do suporte técnico forem responsáveis por redefinir senhas esquecidas, ajudar os usuários com problemas de conectividade e solucionar problemas de configurações de aplicativo, talvez seja necessário combinar as configurações de delegação em objetos de usuário no Active Directory com privilégios que permitem que os usuários do Suporte Técnico se conectem remotamente aos computadores dos usuários para exibir ou modificar as configurações dos usuários. Para cada função definida, você deve identificar:

1. Quais tarefas os membros da função executam diariamente e quais tarefas são executadas com menos frequência.
2. Em quais sistemas e em quais aplicativos os membros de uma função devem receber direitos e permissões.
3. Quais usuários devem receber associação em uma função.
4. Como o gerenciamento de associações de função será executado.

Em muitos ambientes, criar manualmente controles de acesso baseados em função para administração de um ambiente do Active Directory pode ser um desafio para implementar e manter. Se você tiver funções e responsabilidades claramente definidas para a administração de sua infraestrutura de TI, convém aproveitar ferramentas adicionais para ajudá-lo a criar uma implantação RBAC nativa gerenciável. Por exemplo, se o FIM (Forefront Identity Manager) estiver em uso em seu ambiente, você poderá usar o FIM para automatizar a criação e o preenchimento de funções administrativas, o que pode facilitar a administração contínua. Se você usar o Microsoft Endpoint Configuration Manager e o SCOM (System Center Operations Manager), poderá usar funções específicas do aplicativo para delegar funções de gerenciamento e monitoramento e também impor configuração e auditoria consistentes entre sistemas no domínio. Se você implementou uma PKI (infraestrutura de chave pública), poderá emitir e exigir cartões inteligentes para a equipe de TI responsável por administrar o ambiente. Com o FIM CM (Gerenciamento de Credenciais do FIM), você pode até combinar o gerenciamento de funções e credenciais para sua equipe administrativa.

Em outros casos, pode ser preferível que uma organização considere a implantação de software RBAC de terceiros que fornece funcionalidade "pronta para uso". COTS (Soluções comerciais padronizadas) para RBAC para diretórios e sistemas operacionais do Active Directory, Windows e não Windows são oferecidas por vários fornecedores. Ao escolher entre soluções nativas e produtos de terceiros, considere os seguintes fatores:

1. Orçamento: ao investir no desenvolvimento do RBAC usando software e ferramentas que você já tem, você pode reduzir os custos de software envolvidos na implantação de uma solução. No entanto, a menos que você tenha funcionários experientes na criação e na implantação de soluções RBAC nativas, talvez seja necessário envolver recursos de consultoria para desenvolver sua solução. Você deverá avaliar cuidadosamente os custos previstos para uma solução personalizada com os custos para implantar uma solução "pronta para uso", especialmente se seu orçamento for limitado.
2. Composição do ambiente de TI: se o ambiente for composto principalmente por sistemas Windows ou se você já estiver aproveitando o Active Directory para gerenciamento de sistemas e contas não Windows, soluções nativas personalizadas poderão fornecer a solução ideal para suas necessidades. Se sua infraestrutura contiver muitos sistemas que não estão executando o Windows e não são gerenciados pelo Active Directory, talvez seja necessário considerar as opções para o gerenciamento de sistemas não Windows separadamente do ambiente do Active Directory.
3. Modelo de privilégio na solução: se um produto depende do posicionamento de suas contas de serviço em grupos altamente privilegiados no Active Directory e não oferece opções que não exigem privilégio excessivo concedido ao software RBAC, você realmente não reduziu sua superfície de ataque do Active Directory, só alterou a composição dos grupos mais privilegiados do diretório. A menos que um fornecedor de aplicativos possa fornecer controles para contas de serviço que minimizem a probabilidade de as contas serem comprometidas e usadas maliciosamente, talvez você queira considerar outras opções.

Privileged Identity Management

O PIM (Privileged Identity Management), às vezes chamado de PAM (privileged account management) ou PCM (privileged credential Management) é o design, a construção e a implementação de abordagens para gerenciar contas privilegiadas em sua infraestrutura. Em geral, o PIM fornece mecanismos pelos quais as contas recebem direitos temporários e permissões necessárias para executar funções de correção de build ou falha, em vez de deixar privilégios permanentemente anexados às contas. Se a funcionalidade do PIM for criada manualmente ou implementada por meio da implantação de software de terceiros, um ou mais dos seguintes recursos podem estar disponíveis:

• Credenciais "cofres", em que senhas para contas privilegiadas são "verificadas" e atribuídas uma senha inicial, depois "check-in" quando as atividades foram concluídas, quando as senhas são redefinidas novamente nas contas.
• Restrições de limite de tempo no uso de credenciais privilegiadas
• Credenciais de uso único
• Concessão de privilégio gerada pelo fluxo de trabalho com monitoramento e relatório de atividades executadas e remoção automática de privilégios quando as atividades são concluídas ou o tempo alocado expirou
• Substituição de credenciais embutidas em código, como nomes de usuário e senhas em scripts por APIs (interfaces de programação de aplicativo) que permitem que as credenciais sejam recuperadas dos cofres conforme necessário
• Gerenciamento automático de credenciais da conta de serviço

Como criar contas não privilegiadas para gerenciar contas privilegiadas

Um dos desafios no gerenciamento de contas privilegiadas é que, por padrão, as contas que podem gerenciar contas e grupos privilegiados e protegidos são contas privilegiadas e protegidas. Se você implementar soluções apropriadas de RBAC e PIM para sua instalação do Active Directory, as soluções poderão incluir abordagens que permitem remover o preenchimento efetivamente da associação dos grupos mais privilegiados no diretório, preenchendo os grupos apenas temporariamente e quando necessário.

No entanto, se você implementar RBAC e PIM nativos, considere criar contas sem privilégios e com a única função de preencher e remover o preenchimento de grupos privilegiados no Active Directory quando necessário. Apêndice I: a criação de contas de gerenciamento para contas e grupos protegidos no Active Directory fornece instruções passo a passo que você pode usar para criar contas para essa finalidade.

Como implementar controles de autenticação robustos

Lei número seis: há realmente alguém lá fora tentando adivinhar suas senhas. - Dez leis imutáveis da administração de segurança

Pass-the-hash e outros ataques de roubo de credenciais não são específicos para sistemas operacionais Windows, nem são novos. O primeiro ataque de pass-the-hash foi criado em 1997. Historicamente, no entanto, esses ataques exigiam ferramentas personalizadas, o sucesso era do tipo acerto ou erro e exigiam que os invasores tivessem um grau relativamente alto de habilidade. A introdução de ferramentas fáceis de usar disponíveis livremente que extrai credenciais nativamente resultou em um aumento exponencial no número e no sucesso de ataques de roubo de credenciais nos últimos anos. No entanto, os ataques de roubo de credenciais não são de maneira alguma os únicos mecanismos pelos quais as credenciais são almejadas e comprometidas.

Embora você deva implementar controles para ajudar a protegê-lo contra ataques de roubo de credenciais, também deve identificar as contas em seu ambiente que provavelmente serão alvo de invasores e implementar controles de autenticação robustos para essas contas. Se suas contas mais privilegiadas estiverem usando a autenticação de fator único, como nomes de usuário e senhas (ambas são "algo que você sabe", que é um fator de autenticação), essas contas serão fracamente protegidas. Tudo o que um invasor precisa é de conhecimento do nome de usuário e do conhecimento da senha associada à conta, e os ataques de pass-the-hash não são necessários para que o invasor possa se autenticar como o usuário em todos os sistemas que aceitam credenciais de fator único.

Embora a implementação da autenticação multifator não proteja você contra ataques de pass-the-hash, a implementação da autenticação multifator em combinação a sistemas protegidos protege. Mais informações sobre como implementar sistemas protegidos são apresentadas em Como implementar hosts administrativos seguros e as opções de autenticação são discutidas nas seções a seguir.

Controles gerais de autenticação

Se você ainda não implementou a autenticação multifator, como cartões inteligentes, considere fazer isso. Cartões inteligentes implementam a proteção imposta por hardware de chaves privadas em um par de chaves públicas-privadas, impedindo que a chave privada do usuário seja acessada ou usada, a menos que o usuário apresente o PIN, senha ou identificador biométrico correto para o cartão inteligente. Mesmo que o PIN ou a senha de um usuário seja interceptado por um agente de pressionamento de tecla em um computador comprometido, para um invasor reutilizar o PIN ou código secreto, o cartão também deve estar fisicamente presente.

Nos casos em que senhas longas e complexas se mostraram difíceis de implementar devido à resistência do usuário, os cartões inteligentes fornecem um mecanismo pelo qual os usuários podem implementar PINs ou senhas relativamente simples sem que as credenciais estejam suscetíveis a ataques de força bruta ou de tabela arco-íris. Os PINs dos cartões inteligentes não são armazenados no Active Directory ou em bancos de dados SAM locais, embora os hashes de credencial ainda possam ser armazenados na memória protegida por LSASS em computadores em que foram usados cartões inteligentes para autenticação.

Controles adicionais para contas VIP

Outro benefício da implementação de cartões inteligentes ou outros mecanismos de autenticação baseados em certificado é a capacidade de aproveitar a Garantia do Mecanismo de Autenticação para proteger dados confidenciais acessíveis aos usuários VIP. A Garantia do Mecanismo de Autenticação está disponível em domínios nos quais o nível funcional é definido como Windows Server 2012 ou Windows Server 2008 R2. Quando ele está habilitado, a Garantia do mecanismo de Autenticação adiciona uma associação de grupo global designada pelo administrador ao token Kerberos de um usuário quando as credenciais do usuário são autenticadas durante o logon usando um método de logon baseado em certificado.

Isso possibilita que os administradores de recursos controlem o acesso a recursos, como arquivos, pastas e impressoras, com base em se o usuário faz logon usando um método de logon baseado em certificado, além do tipo de certificado usado. Por exemplo, quando um usuário faz logon usando um cartão inteligente, o acesso do usuário aos recursos na rede pode ser especificado como diferente do acesso quando o usuário não usa um cartão inteligente (ou seja, quando o usuário faz logon inserindo um nome de usuário e senha). Para mais informações sobre a Garantia do Mecanismo de Autenticação, confira o Guia passo a passo do Mecanismo de Autenticação do AD DS no Windows Server 2008 R2.

Como configurar a autenticação de conta privilegiada

No Active Directory para todas as contas administrativas, habilite o atributo Exigir cartão inteligente para logon interativo e audite as alterações para (no mínimo), qualquer um dos atributos na guia Conta da conta (por exemplo, objetos de usuário administrativos cn, name, sAMAccountName, userPrincipalName e userAccountControl).

Embora configurar Exigir cartão inteligente para logon interativo em contas redefina a senha da conta para um valor aleatório de 120 caracteres e exija cartões inteligentes para logons interativos, o atributo ainda pode ser substituído pelos usuários com permissões que permitem alterar senhas nas contas e as contas podem ser usadas para estabelecer logons não interativos apenas com nome de usuário e senha.

Em outros casos, dependendo da configuração de contas no Active Directory e das configurações de certificado no AD CS (Serviços de Certificados do Active Directory) ou em um PKI de terceiros, os atributos de nome UPN para contas administrativas ou VIP podem ser direcionados para um tipo específico de ataque, conforme descrito aqui.

Sequestro UPN para falsificação de certificado

Embora uma discussão completa sobre ataques contra PKIs (infraestruturas de chave pública) esteja fora do escopo deste documento, os ataques contra PKIs públicos e privados aumentaram exponencialmente desde 2008. As violações de PKIs públicas foram amplamente divulgadas, mas os ataques contra a PKI interna de uma organização talvez sejam ainda mais prolíficos. Um desses ataques aproveita o Active Directory e os certificados para permitir que um invasor falsifique as credenciais de outras contas de um modo que possa ser difícil de detectar.

Quando um certificado é apresentado para autenticação em um sistema conectado ao domínio, o conteúdo da Entidade ou o atributo SAN (Nome Alternativo da Entidade) no certificado são usados para mapear o certificado para um objeto de usuário no Active Directory. Dependendo do tipo de certificado e de como ele é construído, o atributo Subject em um certificado normalmente contém o CN (nome comum) de um usuário, conforme mostrado na captura de tela a seguir.

Por padrão, o Active Directory constrói o CN de um usuário concatenando o nome da conta + " "+ sobrenome. No entanto, os componentes CN de objetos de usuário no Active Directory não são necessários ou têm garantia de serem exclusivos e mover uma conta de usuário para um local diferente no diretório altera o DN (nome diferenciado) da conta, que é o caminho completo para o objeto no diretório, conforme mostrado no painel inferior da captura de tela anterior.

Como não há garantia de que os nomes de entidade de certificado sejam estáticos ou exclusivos, o conteúdo do Nome Alternativo da Entidade geralmente é usado para localizar o objeto de usuário no Active Directory. O atributo SAN para certificados emitidos para usuários de autoridades de certificação corporativas (CAs integradas ao Active Directory) normalmente contém o UPN ou o endereço de email do usuário. Como há garantia de que os UPNs sejam exclusivos em uma floresta do AD DS, a localização de um objeto de usuário pelo UPN normalmente é executada como parte da autenticação, com ou sem certificados envolvidos no processo de autenticação.

O uso de UPNs em atributos SAN em certificados de autenticação pode ser aproveitado por invasores para obter certificados fraudulentos. Se um invasor tiver comprometido uma conta que tenha a capacidade de ler e gravar UPNs em objetos de usuário, o ataque será implementado da seguinte maneira:

O atributo UPN em um objeto de usuário (como um usuário VIP) é temporariamente alterado para um valor diferente. O atributo de nome da conta SAM e o CN também podem ser alterados no momento, embora isso geralmente não seja necessário pelos motivos descritos anteriormente.

Quando o atributo UPN na conta de destino é alterado, uma conta de usuário obsoleta e habilitada ou um atributo UPN de conta de usuário recém-criado é alterado para o valor originalmente atribuído à conta de destino. Contas de usuário obsoletas e habilitadas são contas que não fizeram logon por longos períodos de tempo, mas não foram desabilitadas. Eles são alvo de invasores que pretendem "se esconder em vista" pelos seguintes motivos:

1. Como a conta está habilitada, mas não foi usada recentemente, é improvável que o uso da conta dispare alertas da maneira que a habilitação de uma conta de usuário desabilitada pode.
2. O uso de uma conta existente não requer a criação de uma nova conta de usuário que possa ser notada pela equipe administrativa.
3. Contas de usuário obsoletas que ainda estão habilitadas geralmente são membros de vários grupos de segurança e recebem acesso a recursos na rede, simplificando o acesso e "misturando-se" a uma população de usuários existente.

A conta de usuário na qual o UPN de destino foi configurado agora é usada para solicitar um ou mais certificados dos Serviços de Certificados do Active Directory.

Quando os certificados são obtidos para a conta do invasor, os UPNs na conta "nova" e a conta de destino são retornados aos valores originais.

O invasor agora tem um ou mais certificados que podem ser apresentados para autenticação em recursos e aplicativos como se o usuário fosse o usuário VIP cuja conta foi temporariamente modificada. Embora uma discussão completa sobre todas as maneiras pelas quais certificados e PKI podem ser alvos de invasores esteja fora do escopo deste documento, esse mecanismo de ataque é apresentado para ilustrar por que você deve monitorar alterações em contas privilegiadas e VIP no AD DS, especialmente alterações em qualquer um dos atributos na guia Conta da conta (por exemplo, cn, name, sAMAccountName, userPrincipalName e userAccountControl). Além de monitorar as contas, você deve restringir quem pode modificar as contas para o menor número possível de usuários administrativos. Da mesma forma, as contas de usuários administrativos devem ser protegidas e monitoradas para alterações não autorizadas.