Implementação de modelos administrativos Least-Privilege

O seguinte excerto é do The Administrator Accounts Security Planning Guide, publicado pela primeira vez em 1 de abril de 1999:

"A maioria dos cursos de treinamento e documentação relacionados à segurança discute a implementação de um princípio de menor privilégio, mas as organizações raramente o seguem. O princípio é simples, e o impacto de aplicá-lo corretamente aumenta muito a sua segurança e reduz o seu risco. O princípio afirma 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. Isso fornece proteção contra códigos maliciosos, entre outros ataques. Este princípio aplica-se aos computadores e aos utilizadores desses computadores. "Uma razão pela qual esse princípio funciona tão bem é que ele força você a fazer algumas pesquisas internas. Por exemplo, você deve determinar os privilégios de acesso que um computador ou usuário realmente precisa e, em seguida, implementá-los. Para muitas organizações, esta tarefa pode inicialmente parecer muito trabalhosa; No entanto, é um passo essencial para proteger com sucesso o 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 menor privilégio. 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, em vez disso, o administrador tivesse iniciado sessão com uma conta não privilegiada (não administrativa), o âmbito do dano do vírus seria apenas o computador local porque é executado como um utilizador de computador local. "Em outro exemplo, as contas às quais você concede direitos de administrador no nível do 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 proteger contra o aumento não autorizado de privilégios."

O seguinte excerto é do Microsoft Windows Security Resource Kit, publicado pela primeira vez em 2005:

"Pense sempre na segurança em termos de conceder o mínimo de privilégios necessários para realizar a tarefa. Se um aplicativo que tem muitos privilégios deve ser comprometido, o invasor pode ser capaz de expandir o ataque além do que faria se o aplicativo estivesse sob a menor quantidade de privilégios possível. Por exemplo, examine as consequências de um administrador de rede abrir involuntariamente um anexo de e-mail que inicia um vírus. Se o administrador estiver conectado usando a conta de administrador do domínio, o vírus terá privilégios de administrador em todos os computadores no domínio e, 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 e, portanto, poderá acessar quaisquer dados no computador e instalar software mal-intencionado, como software de registro de pressionamento de tecla no computador. Se o administrador estiver conectado usando uma conta de usuário normal, o vírus terá acesso apenas aos dados do administrador e não poderá instalar software mal-intencionado. Ao utilizar o mínimo de privilégios necessários para aceder a e-mails, neste exemplo, o escopo potencial do comprometimento é muito reduzido.

O problema dos privilégios

Os princípios descritos nos trechos anteriores não mudaram, mas ao avaliar as instalações do Ative Directory, invariavelmente encontramos um número excessivo de contas que receberam direitos e permissões muito além daqueles necessários para executar o trabalho diário. O tamanho do ambiente afeta os números brutos de contas excessivamente privilegiadas, mas não a proporção - diretórios de médio porte podem ter dezenas de contas nos grupos mais altamente 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 atacantes normalmente seguem o caminho de menor resistência. Eles aumentam a complexidade de suas ferramentas e abordagem apenas se e quando mecanismos mais simples falharem ou forem frustrados pelos defensores.

Infelizmente, o caminho de menor resistência em muitos ambientes provou ser o uso excessivo de contas com amplo e profundo privilégio. 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 Help Desk pode receber permissões que lhes permitem redefinir as senhas em muitas contas de usuário.

Privilégios profundos são privilégios poderosos que são aplicados a um segmento restrito da população, como conceder a um engenheiro direitos de administrador em um servidor para que ele possa executar reparos. Nem o privilégio amplo nem o privilégio profundo são necessariamente perigosos, mas quando muitas contas no domínio recebem permanentemente privilégios amplos e profundos, se apenas uma das contas for comprometida, ele pode ser usado rapidamente para reconfigurar o ambiente para os propósitos do invasor ou até mesmo para destruir grandes segmentos da infraestrutura.

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

1. Normalmente, é fácil para um invasor obter um privilégio profundo em um único computador e, em seguida, 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 pass-the-hash sejam eliminados, os atacantes simplesmente usariam táticas diferentes, não uma estratégia diferente. Em vez de plantar malware que contém ferramentas de roubo de credenciais, eles podem plantar malware que registra pressionamentos de teclas ou aproveitar qualquer número de outras abordagens para capturar credenciais que são poderosas em todo o ambiente. Independentemente da tática, os alvos permanecem os mesmos: contas com amplo e profundo privilégio.

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

No Ative Directory

No Ative 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 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 se deve à 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 difiram, eles devem ser efetivamente considerados grupos igualmente poderosos, porque um membro de um pode tornar-se 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 um punhado de 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 grandes associações são aninhados nos 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 ao grupo Administradores local em seus computadores pessoais. Quando isso ocorre, mesmo que o UAC esteja habilitado, esses usuários apresentam um risco elevado para a integridade de suas estações de trabalho.

Em Aplicações

Em ataques em que o alvo é a propriedade intelectual de uma organização, contas que receberam privilégios poderosos dentro de aplicativos podem ser direcionadas 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, as contas que podem manipular a configuração de um aplicativo ou o acesso às informações fornecidas pelo aplicativo apresentam riscos.

Em repositórios de dados

Tal como acontece com outros alvos, os atacantes que procuram acesso à propriedade intelectual sob a forma de documentos e outros ficheiros podem visar as contas que controlam o acesso aos armazenamentos de ficheiros, contas que têm acesso direto aos ficheiros ou mesmo grupos ou funções que têm acesso aos ficheiros. Por exemplo, se um servidor de arquivos for usado para armazenar documentos contratuais e o acesso for concedido aos documentos pelo uso de um grupo do Ative Directory, um invasor que possa modificar a associação do grupo poderá adicionar contas comprometidas ao grupo e acessar os documentos contratuais. Nos casos em que o acesso a documentos é fornecido por aplicativos como o SharePoint, os invasores podem direcionar os aplicativos conforme descrito anteriormente.

Reduzindo privilégios

Quanto maior e mais complexo for um ambiente, mais difícil será a sua gestão e segurança. Em organizações pequenas, revisar e reduzir privilégios pode ser uma proposta relativamente simples, mas cada servidor, estação de trabalho, conta de usuário e aplicativo adicional em uso em uma organização adiciona outro objeto que deve ser protegido. Como pode ser difícil ou mesmo impossível proteger adequadamente todos os aspetos 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 Ative Directory e as contas locais privilegiadas em estações de trabalho e servidores membros.

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

Embora este documento se concentre na proteção do Ative Directory, como foi discutido anteriormente, 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 local em estações de trabalho e servidores membros.

Protegendo contas de administrador local

Em todas as versões do Windows atualmente em suporte base, a conta de Administrador local é desativada por padrão, o que torna a conta inutilizável para ataques pass-the-hash e outros ataques de roubo de credenciais. No entanto, em domínios que contenham sistemas operacionais herdados ou nos quais as contas de Administrador local tenham sido habilitadas, essas contas podem ser usadas conforme descrito anteriormente 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 associados ao domínio.

Instruções detalhadas para implementar esses controles são fornecidas no Apêndice H: Protegendo contas e grupos de administradores locais. Antes de implementar essas configurações, no entanto, certifique-se de que as contas de administrador local 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 completamente antes de implementá-las em um ambiente de produção.

Controles para contas de administrador local

As contas de Administrador incorporadas nunca devem ser utilizadas como contas de serviço em servidores membros, nem devem ser utilizadas para iniciar sessão em computadores locais (exceto no Modo de Segurança, que é permitido mesmo que a conta esteja desativada). O objetivo da implementação das 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 sejam primeiro revertidos. Ao implementar esses controles e monitorar as contas de Administrador em busca de alterações, você pode reduzir significativamente a probabilidade de sucesso de um ataque direcionado a contas de Administrador locais.

Configurando GPOs para restringir contas de administrador em sistemas Domain-Joined

Em um ou mais GPOs criados e vinculados a UOs de estação de trabalho e servidor membro 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 de Usuário:

• Recusar acesso a este computador à rede
• Negar iniciar sessão como um trabalho em lote
• Negar o início de sessão como um serviço
• Negar início de sessão através dos Serviços de Ambiente de Trabalho Remoto

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

Essas configurações garantirão que a conta de Administrador de um computador não possa ser usada para se conectar a outros computadores, mesmo que esteja habilitada inadvertidamente ou maliciosamente. Os logons locais usando a conta de Administrador local não podem ser completamente desativados, nem você deve tentar fazê-lo, porque a conta de Administrador local de um computador foi projetada para ser usada em cenários de recuperação de desastres.

Se um servidor membro ou estação de trabalho se separar do domínio sem outras contas locais com privilégios administrativos concedidos, o computador pode ser inicializado no modo de segurança, a conta de administrador pode ser ativada e a conta pode ser usada para efetuar reparos no computador. Quando os reparos forem concluídos, a conta de administrador deve ser desativada novamente.

Protegendo contas e grupos privilegiados locais no Ative Directory

Lei número seis: Um computador é tão seguro quanto o administrador é confiável. - Dez Leis Imutáveis de Segurança (Versão 2.0)

As informações fornecidas aqui destinam-se a fornecer diretrizes gerais para proteger as contas e grupos internos de maior privilégio no Ative Directory. Instruções detalhadas passo a passo também são fornecidas no Apêndice D: Protegendo Built-In contas de administrador no Ative Directory, no Apêndice E: Protegendo grupos de administradores corporativos no Ative Directory, no Apêndice F: Protegendo grupos de administradores de domínio no Ative Directory e no Apêndice G: Protegendo grupos de administradores no Ative Directory.

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

Protegendo contas de administrador embutidas no Active Directory

Em cada domínio no Ative Directory, uma conta de Administrador é criada como parte da criação do domínio. Essa conta é, por padrão, um membro dos grupos Administradores do 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 de Empresa. O uso da conta de Administrador local de um domínio deve ser reservado apenas para atividades iniciais de compilação e, possivelmente, cenários de recuperação de desastres. Para garantir que uma conta de Administrador interna possa ser usada para efetuar reparos caso nenhuma outra conta possa ser usada, você não deve alterar a associação padrão da conta de Administrador em nenhum domínio da floresta. Em vez disso, você deve seguir as diretrizes para ajudar a proteger a conta de Administrador em cada domínio da floresta. Instruções detalhadas para implementar esses controles são fornecidas no Apêndice D: Protegendo Built-In contas de administrador no Ative Directory.

Controles para contas de administrador integradas

O objetivo da implementação das 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. Ao implementar esses controles e monitorar as contas de Administrador em busca de 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 de Administrador em cada domínio da floresta, você deve definir as seguintes configurações.

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

Por padrão, todas as contas no Ative 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 a outros computadores para obter serviços em nome da conta. Quando você habilita o atributo Conta é confidencial e não pode ser delegado 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 os ataques que aproveitam a delegação para usar as credenciais da conta em outros sistemas.

Habilite o sinalizador "O cartão inteligente é necessário para logon interativo" na conta

Quando você habilita o cartão inteligente é necessário para o atributo de 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 internas, você garante que a senha da conta não seja apenas longa e complexa, mas não seja conhecida por nenhum usuário. Não é tecnicamente necessário criar cartões inteligentes para as contas antes de ativar 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 cartão inteligente seja necessária para o sinalizador de logon interativo redefine a senha da conta, isso não impede que um usuário com direitos para redefinir a senha da conta defina a conta para um valor conhecido e use o nome e a nova senha da conta para acessar recursos na rede. Por isso, você deve implementar os seguintes controles adicionais na conta.

Configurando GPOs para restringir contas de administrador de domínios em sistemas Domain-Joined

Embora desativar a conta de Administrador em um domínio torne a conta efetivamente inutilizável, você deve implementar restrições adicionais na conta caso a conta seja habilitada inadvertidamente ou maliciosamente. Embora esses controles possam ser revertidos pela conta de administrador, o objetivo é criar controles que retardem o progresso de um invasor e limitem os danos que a conta pode infligir.

Em um ou mais GPOs criados e vinculados a UOs de estação de trabalho e servidor membro em cada domínio, adicione a conta de 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 de Usuário:

• Recusar acesso a este computador à rede
• Negar iniciar sessão como um trabalho em lote
• Negar o início de sessão como um serviço
• Negar início de sessão através dos Serviços de Ambiente de Trabalho Remoto

Configurando GPOs para restringir contas de administrador em controladores de domínio

Em cada domínio na floresta de domínios, a política dos Controladores de Domínio Padrão ou uma política vinculada à Unidade Organizacional (UO) dos Controladores de Domínio deve ser modificada para adicionar a conta de Administrador de cada domínio aos seguintes direitos de utilizador em Configuração do Computador\Políticas\Configurações do Windows\Configurações de Segurança\Políticas Locais\Atribuições de Direitos de Utilizador:

• Recusar acesso a este computador à rede
• Negar iniciar sessão como um trabalho em lote
• Negar o início de sessão como um serviço
• Negar início de sessão através dos Serviços de Ambiente de Trabalho Remoto

Configurar auditoria das contas de administrador incorporadas

Depois de proteger a conta de Administrador de cada domínio e desativá-la, você deverá configurar a auditoria para monitorar alterações na conta. Se a conta estiver habilitada, sua senha for redefinida ou quaisquer outras modificações forem feitas na 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.

Protegendo Administradores, Administradores de Domínio e Grupos de Administradores de Empresa

Protegendo grupos de administradores corporativos

O grupo Administradores de Empresa, que está alojado no domínio raiz da floresta, não deve conter utilizadores no dia-a-dia, com a possível exceção da conta de Administrador local do domínio, desde que esteja protegida conforme descrito anteriormente e no Apêndice D: Protegendo Built-In Contas de Administrador no Ative Directory.

Quando o acesso EA é necessário, os usuários cujas contas exigem direitos e permissões EA devem ser temporariamente colocados no grupo Administradores Corporativos. Embora os usuários estejam usando as contas altamente privilegiadas, suas atividades devem ser auditadas e, de preferência, realizadas com um usuário realizando as alterações e outro usuário observando as alterações para minimizar a probabilidade de uso indevido ou configuração incorreta. Quando as atividades forem concluídas, as contas devem ser removidas do grupo EA. Isso pode ser alcançado por meio de procedimentos manuais e processos documentados, software de gerenciamento de identidade/acesso privilegiado de terceiros (PIM/PAM) 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 Ative Directory são fornecidas em Contas atraentes para roubo de credenciais e instruções detalhadas são fornecidas no Apêndice I: Criando contas de gerenciamento para contas e grupos protegidos no Ative Directory.

Os Administradores de Empresa são, por predefinição, membros do grupo Administradores nativo em cada domínio na floresta de domínios. Remover o grupo Administradores de Empresa dos grupos Administradores em cada domínio é uma modificação inadequada porque, no caso de um cenário de recuperação de desastres florestais, os direitos de EA provavelmente serão necessários. Se o grupo Administradores de Empresa tiver sido removido dos grupos Administradores em uma floresta, ele deverá ser adicionado ao grupo Administradores em cada domínio e os seguintes controles adicionais deverão ser implementados:

• Conforme descrito anteriormente, o grupo Administradores de Empresa 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: Protegendo Built-In Contas de Administrador no Ative Directory.
• Em GPOs vinculados a UOs que contenham servidores membros e estações de trabalho em cada domínio, o grupo EA deve ser adicionado aos seguintes direitos de usuário:
  • Recusar acesso a este computador à rede
  • Negar iniciar sessão como um trabalho em lote
  • Negar o início de sessão como um serviço
  • Negar o início de sessão local
  • Negar início de sessão através do Remote Desktop Services.

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

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

Protegendo grupos de administradores de domínio

Como é o caso do grupo Administradores de Empresa, a associação a grupos de Administradores de Domínio deve ser exigida apenas em cenários de configuração ou recuperação após 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 no Apêndice D: Protegendo Built-In Contas de Administrador no Ative Directory.

Quando o acesso DA é necessário, as contas que precisam desse nível de acesso devem ser temporariamente colocadas no grupo DA para o domínio em questão. Embora os usuários estejam usando as contas altamente privilegiadas, as atividades devem ser auditadas e, de preferência, realizadas com um usuário realizando 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 forem concluídas, as contas deverão ser removidas do grupo Administradores do Domínio. Isto pode ser conseguido através de procedimentos manuais e processos documentados, através de software de gestão de identidade/acesso privilegiado de terceiros (PIM/PAM) 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 Ative Directory são fornecidas no Apêndice I: Criando contas de gerenciamento para contas e grupos protegidos no Ative Directory.

Os Administradores de Domínio são, por padrão, membros dos grupos Administradores locais em todos os servidores membros e estações de trabalho em seus respetivos domínios. Esse aninhamento padrão não deve ser modificado porque afeta a capacidade de suporte e as opções de recuperação de desastres. Se os grupos Administradores do Domínio tiverem sido removidos dos grupos Administradores locais nos servidores membros, eles deverão ser adicionados ao grupo Administradores em cada servidor membro e estação de trabalho no domínio por meio de configurações de grupo restrito em GPOs vinculados. Os seguintes controles gerais, descritos detalhadamente no Apêndice F: Protegendo grupos de administradores de domínio no Ative 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 DA, com a possível exceção da conta de Administrador interna do domínio, desde que ela tenha sido protegida conforme descrito no Apêndice D: Protegendo Built-In Contas de Administrador no Ative Directory.

2. Em GPOs ligadas a OUs que contêm servidores membros e estações de trabalho em cada domínio, o grupo DA deve ser adicionado às seguintes permissões de utilizador.

   • Recusar acesso a este computador à rede
   • Negar iniciar sessão como um trabalho em lote
   • Negar o início de sessão como um serviço
   • Negar o início de sessão local
   • Negar início de sessão através dos Serviços de Ambiente de Trabalho Remoto

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

3. A auditoria deve ser configurada para enviar alertas se forem feitas modificações nas propriedades ou na associação do grupo DA. Esses alertas devem ser enviados, no mínimo, para usuários ou equipes responsáveis pela administração do AD DS e resposta a incidentes. Você também deve definir processos e procedimentos para o preenchimento temporário do grupo DA, incluindo procedimentos de notificação quando é efetuada a composição legítima do grupo.

Protegendo grupos de administradores no Ative Directory

Como é o caso dos grupos EA e DA, a associação ao grupo Administradores (BA) deve ser necessária apenas em cenários de construção ou recuperação de desastres. Não deve haver contas de usuário diárias no grupo Administradores, com exceção da conta de Administrador local do domínio, se ela tiver sido protegida conforme descrito no Apêndice D: Protegendo Built-In Contas de Administrador no Ative Directory.

Quando o acesso de Administradores é necessário, as contas que precisam desse nível de acesso devem ser temporariamente colocadas no grupo Administradores do domínio em questão. Embora os usuários estejam usando as contas altamente privilegiadas, as atividades devem ser auditadas e, de preferência, realizadas com um usuário realizando as alterações e outro usuário observando as alterações para minimizar a probabilidade de uso indevido ou configuração incorreta. Quando as atividades forem concluídas, as contas devem ser removidas imediatamente do grupo Administradores. Isto pode ser conseguido através de procedimentos manuais e processos documentados, através de software de gestão de identidade/acesso privilegiado de terceiros (PIM/PAM) 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 respetivos domínios. A associação a este grupo pode ser necessária em cenários de compilação e recuperação de desastres nos quais é necessário possuir ou ter a capacidade de assumir a propriedade de objetos. Além disso, DAs e EAs herdam vários de seus direitos e permissões em virtude de sua associação padrão no grupo Administradores. O aninhamento de grupo padrão para grupos privilegiados no Ative Directory não deve ser modificado e o grupo Administradores de cada domínio deve ser protegido conforme descrito no Apêndice G: Protegendo grupos de administradores no Ative Directory e nas instruções gerais abaixo.

1. Remova todos os membros do grupo Administradores, com a possível exceção da conta de Administrador local do domínio, desde que ela tenha sido protegida conforme descrito no Apêndice D: Protegendo Built-In Contas de Administrador no Ative Directory.

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

   • Recusar acesso a este computador à rede
   • Negar início de sessão como trabalho em lote,
   • Negar o início de sessão como um serviço
   • Isso impedirá que os membros do grupo de Administradores sejam usados para iniciar sessão ou conectar-se a servidores ou estações de trabalho pertencentes ao grupo (a menos que múltiplos controles sejam comprometidos inicialmente), onde suas credenciais podem ser armazenadas em cache e, portanto, sujeitas a comprometimento. Uma conta privilegiada nunca deve ser usada para fazer logon em um sistema menos privilegiado, e a aplicação desses controles oferece proteção contra uma série de ataques.

3. Na OU dos controladores de domínio em cada domínio na floresta, o grupo Administradores deve ter atribuídos os seguintes direitos de utilizador (se ainda não tiverem esses direitos), o que permitirá aos membros do grupo Administradores executar as funções necessárias para um cenário de recuperação de desastres em toda a floresta.

   • Aceder a este computador a partir da rede
   • Permitir início de sessão local
   • Permitir início de sessão através dos Serviços de Ambiente de Trabalho Remoto

4. A auditoria deve ser configurada para enviar alertas se forem feitas modificações nas propriedades ou na associação do grupo Administradores. Esses alertas devem ser enviados, no mínimo, para 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 devem ser definidos procedimentos para modificar a associação do grupo Administradores. Especificamente, esses processos devem incluir um procedimento pelo qual a equipe de segurança é notificada quando o grupo Administradores será modificado para que, quando os alertas forem enviados, eles sejam esperados e um alarme não seja disparado. 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 implementados.

Controles de acesso Role-Based (RBAC) para o Ative Directory

De um modo geral, os controles de acesso baseados em função (RBAC) são um mecanismo para agrupar usuários e fornecer acesso a recursos com base em regras de negócios. No caso do Ative Directory, a implementação do 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 conceder-lhes privilégios excessivos. O RBAC para Ative Directory pode ser projetado e implementado por meio de ferramentas e interfaces nativas, aproveitando o software que você já possui, 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 Ative 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 do RBAC para Ative Directory

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

Em alguns casos, os grupos de segurança existentes no Ative 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 zonas e registros DNS, delegar essas responsabilidades pode ser tão simples quanto criar uma conta para cada administrador de DNS e adicioná-la ao grupo Administradores de DNS no Ative Directory. O grupo Administradores de DNS, ao contrário dos grupos mais privilegiados, tem poucos direitos poderosos no Ative Directory, embora aos membros desse grupo tenham sido delegadas permissões que lhes permitem administrar o DNS e ainda esteja sujeito a comprometimento e abuso pode 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 a objetos do Ative 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 Help Desk forem responsáveis por redefinir senhas esquecidas, ajudar os usuários com problemas de conectividade e solucionar problemas de configurações de aplicativos, talvez seja necessário combinar as configurações de delegação em objetos de usuário no Ative Directory com privilégios que permitam que os usuários do Help Desk se conectem remotamente aos computadores dos usuários para exibir ou modificar as definições de configuração dos usuários. Para cada função que definir, deve identificar:

1. Que tarefas os membros da função executam no dia-a-dia e que 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 ser concedidos como membros de uma função.
4. Como será feita a gestão das associações de funções.

Em muitos ambientes, a criação manual de controles de acesso baseados em função para administração de um ambiente do Ative Directory pode ser um desafio de 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 Forefront Identity Manager (FIM) 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 System Center Operations Manager (SCOM), 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), pode emitir e exigir cartões inteligentes para a equipe de TI responsável pela administração do ambiente. Com o FIM Credential Management (FIM CM), você pode até combinar o gerenciamento de funções e credenciais para sua equipe administrativa.

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

1. Orçamento: Ao investir no desenvolvimento do RBAC usando software e ferramentas que você já possui, você pode reduzir os custos de software envolvidos na implantação de uma solução. No entanto, a menos que você tenha uma equipe experiente na criação e implantação de soluções RBAC nativas, talvez seja necessário contratar recursos de consultoria para desenvolver sua solução. Você deve ponderar cuidadosamente os custos previstos para uma solução desenvolvida sob medida com os custos para implantar uma solução "pronta para uso", especialmente se o seu orçamento for limitado.
2. Composição do ambiente de TI: Se o seu ambiente for composto principalmente por sistemas Windows ou se você já estiver aproveitando o Ative Directory para o gerenciamento de contas e sistemas que não sejam Windows, as soluções nativas personalizadas podem fornecer a solução ideal para suas necessidades. Se sua infraestrutura contiver muitos sistemas que não executam o Windows e não são gerenciados pelo Ative Directory, talvez seja necessário considerar opções para o gerenciamento de sistemas que não sejam Windows separadamente do ambiente do Ative 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 Ative Directory e não oferece opções que não exigem que privilégios excessivos sejam concedidos ao software RBAC, você realmente não reduziu sua superfície de ataque do Ative Directory, apenas alterou a composição dos grupos mais privilegiados no diretório. A menos que um fornecedor de aplicativo possa fornecer controles para contas de serviço que minimizem a probabilidade de as contas serem comprometidas e usadas maliciosamente, convém considerar outras opções.

Privileged Identity Management

O gerenciamento privilegiado de identidades (PIM), às vezes chamado de gerenciamento privilegiado de contas (PAM) ou gerenciamento privilegiado de credenciais (PCM), é o design, a construção e a implementação de abordagens para gerenciar contas privilegiadas em sua infraestrutura. De um modo geral, o PIM fornece mecanismos através dos quais as contas recebem direitos e permissões temporários necessários para executar funções de correção de construção ou falhas, ao invés de manter privilégios permanentemente associados às contas. Se a funcionalidade PIM é criada manualmente ou implementada por meio da implantação de software de terceiros, um ou mais dos seguintes recursos podem estar disponíveis:

• "Acervos" de credenciais, onde as senhas de contas privilegiadas são "retiradas" e atribuídas uma senha inicial e, em seguida, "devolvidas" quando as atividades forem concluídas, momento em que as senhas são novamente redefinidas nas contas.
• Restrições limitadas no tempo ao uso de credenciais privilegiadas
• Credenciais de uso único
• Concessão de privilégio gerada por fluxo de trabalho com monitoramento e relatórios de atividades realizadas e remoção automática de privilégio quando as atividades são concluídas ou o tempo alocado expirou
• Substituição de credenciais codificadas, como nomes de usuário e senhas em scripts, por interfaces de programação de aplicativos (APIs) que permitem que as credenciais sejam recuperadas dos cofres conforme necessário
• Gerenciamento automático de credenciais de conta de serviço

Criação de contas sem privilégios para gerenciar contas privilegiadas

Um dos desafios na gestão de contas privilegiadas é que, por predefinição, as contas que podem gerir contas e grupos privilegiados e protegidos são contas privilegiadas e protegidas. Se você implementar soluções RBAC e PIM apropriadas para sua instalação do Ative Directory, as soluções poderão incluir abordagens que permitam despovoar efetivamente a 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 a criação de contas que não tenham privilégios e com a única função de preencher e despovoar grupos privilegiados no Ative Directory quando necessário. O Apêndice I: Criando Contas de Gerenciamento para Contas e Grupos Protegidos no Ative Directory fornece instruções passo a passo que você pode usar para criar contas para essa finalidade.

Implementando controles de autenticação robustos

Lei Número Seis: Realmente há alguém por aí tentando adivinhar suas senhas. - 10 Leis Imutáveis de Administração de Segurança

Pass-the-hash e outros ataques de roubo de credenciais não são específicos dos sistemas operacionais Windows, nem são novos. O primeiro ataque pass-the-hash foi criado em 1997. Historicamente, no entanto, esses ataques exigiam ferramentas personalizadas, tinham sucesso incerto e exigiam que os atacantes tivessem uma habilidade relativamente elevada. A introdução de ferramentas gratuitas e fáceis de usar que extraem credenciais nativamente resultou em um aumento exponencial no número e no sucesso dos ataques de roubo de credenciais nos últimos anos. No entanto, os ataques de roubo de credenciais não são, de forma alguma, os únicos mecanismos pelos quais as credenciais são direcionadas e comprometidas.

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

Embora a implementação da autenticação multifator não proteja contra ataques de pass-the-hash, implementar a autenticação multifator em combinação com sistemas protegidos pode oferecer proteção. Mais informações sobre a implementação de sistemas protegidos são fornecidas em Implementando 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 fazê-lo. Os cartões inteligentes implementam a proteção imposta por hardware de chaves privadas em um par de chaves público-privado, impedindo que a chave privada de um usuário seja acessada ou usada, a menos que o usuário apresente o PIN, a senha ou o identificador biométrico adequados ao cartão inteligente. Mesmo que o PIN ou a senha de um usuário seja intercetado por um registrador de pressionamento de tecla em um computador comprometido, para que um invasor possa reutilizar o PIN ou a senha, 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 códigos secretos relativamente simples sem que as credenciais sejam suscetíveis a ataques de força bruta ou mesa arco-íris. Os PINs de cartão inteligente não são armazenados no Ative Directory ou em bancos de dados SAM locais, embora hashes de credenciais ainda possam ser armazenados na memória protegida por LSASS em computadores nos quais os cartões inteligentes foram usados para autenticação.

Controlos Adicionais para Contas VIP

Outro benefício da implementação de cartões inteligentes ou outros mecanismos de autenticação baseados em certificados é 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 está definido como Windows Server 2012 ou Windows Server 2008 R2. Quando habilitada, 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 no fato de o usuário fazer 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 que é o 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 obter mais informações sobre a Garantia do Mecanismo de Autenticação, consulte o Guia Passo a Passo da Garantia do Mecanismo de Autenticação para AD DS no Windows Server 2008 R2.

Configurando a autenticação de conta privilegiada

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

Embora a configuração 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 por usuários com permissões que lhes 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 Ative Directory e das configurações de certificado nos Serviços de Certificados do Ative Directory (AD CS) ou de uma PKI de terceiros, os atributos UPN (Nome Principal do Usuário) para contas administrativas ou VIP podem ser direcionados para um tipo específico de ataque, conforme descrito aqui.

Sequestro UPN para falsificação de certificados

Embora uma discussão aprofundada sobre ataques contra infraestruturas de chave pública (PKIs) esteja fora do escopo deste documento, os ataques contra PKIs públicas e privadas aumentaram exponencialmente desde 2008. Violações de PKIs públicas têm sido amplamente divulgadas, mas os ataques contra a PKI interna de uma organização talvez sejam ainda mais prolíficos. Um desses ataques aproveita o Ative Directory e os certificados para permitir que um invasor falsifice as credenciais de outras contas de uma maneira que pode ser difícil de detetar.

Quando um certificado é apresentado para autenticação em um sistema associado a um domínio, o conteúdo do atributo Subject ou do Subject Alternative Name (SAN) no certificado é usado para mapear o certificado para um objeto de usuário no Ative Directory. Dependendo do tipo de certificado e de como ele é construído, o atributo Assunto em um certificado normalmente contém o nome comum (CN) de um usuário, conforme mostrado na captura de tela a seguir.

Por padrão, o Ative 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 Ative Directory não são necessários ou garantidos como exclusivos, e mover uma conta de usuário para um local diferente no diretório altera o nome distinto (DN) 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 é garantido que os nomes de entidade do certificado sejam estáticos ou exclusivos, o conteúdo do Nome Alternativo da Entidade é frequentemente usado para localizar o objeto de usuário no Ative Directory. O atributo SAN para certificados emitidos para usuários de autoridades de certificação corporativas (CAs integradas ao Ative Directory) geralmente contém o UPN ou o endereço de e-mail do usuário. Como é garantido que os UPNs sejam exclusivos em uma floresta do AD DS, a localização de um objeto de usuário pelo UPN geralmente é realizada 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 de conta SAM e CN também podem ser alterados neste momento, embora isso geralmente não seja necessário pelos motivos descritos anteriormente.

Quando o atributo UPN na conta de destino tiver sido alterado, uma conta de usuário obsoleta e habilitada ou um atributo UPN de uma conta de usuário recém-criada será alterada para o valor que foi originalmente atribuído à conta de destino. Contas de usuário inativas, mas habilitadas, são contas que não fizeram logon por longos períodos de tempo, mas não foram desativadas. São alvo de atacantes que pretendem "esconder-se à vista de todos" pelas seguintes razões:

1. Como a conta está habilitada, mas não foi usada recentemente, é improvável que o uso da conta acione alertas da mesma forma que habilitar uma conta de usuário desabilitada.
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 integrando-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 Ative Directory.

Quando os certificados são obtidos para a conta do atacante, os UPNs na "nova" conta e na conta de destino são devolvidos aos seus 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 modificada temporariamente. Embora uma discussão completa de todas as maneiras pelas quais certificados e PKI podem ser alvo de invasores esteja fora do escopo deste documento, esse mecanismo de ataque é fornecido para ilustrar por que você deve monitorar contas privilegiadas e VIP no AD DS em busca de alterações, particularmente para 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 um conjunto tão pequeno quanto 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.