Camadas do AD: protegendo o acesso do administrador às camadas 1 e 2 

À medida que a superfície de ataque à identidade continua a evoluir com novos métodos de comprometer as organizações, surge a necessidade de proteger a segurança de uma organização. Active Directory (AD) torna-se cada vez mais importante. Enquanto Active Directory a hierarquização é uma prática fundamental para segregar e proteger contas de alto privilégio, mas muitas organizações ignoram a sua importância, deixando-as vulneráveis ​​a agentes mal-intencionados.  

A implementação de controles de segurança rigorosos para grupos de acesso é essencial para evitar acesso não autorizado e movimento lateral dentro da rede. Neste blog, exploraremos os fundamentos da classificação por níveis do AD e dos desafios comuns de proteção, e discutiremos como Silverfort os recursos de proteção ajudam as organizações a superar esses desafios, tornando a proteção das camadas do AD mais simples e eficiente. 

Desafios comuns para estender os controles de acesso além do nível 0

Uma vez Active Directory O projeto de hierarquização atingiu a fase de implementação, normalmente controles nativos (Active Directory políticas de grupo com restrições de logon) e / ou Silos de política de autenticação são usados ​​para bloquear o acesso ao Nível 0 (Controladores de Domínio, CA de assinatura on-line PKI, Entra Connect/AD FS), que será então gerenciado exclusivamente a partir de consoles de administração dedicados, as Estações de Trabalho de Acesso Privilegiado. 

No entanto, por vários motivos, as organizações muitas vezes lutam para estender esta abordagem ao Nível 1 – onde normalmente 98% de todas as contas de administrador e contas privilegiadas contas de serviço residir. Como resultado, clientes em potencial frequentemente nos perguntam como podemos ajudá-los a implementar controles de acesso eficazes além do Nível 0.

A seguir estão os principais desafios que a maioria das organizações enfrenta quando tentam estender a segurança autenticação e controles de acesso ao Nível 1 e Nível 2:  

GPOs (objetos de política de grupo) não são escalonáveis

O grande número de permutações distintas de controle de acesso necessárias para cada combinação de função (proprietário do aplicativo, administrador de banco de dados, backup, etc.), recurso (nome do aplicativo) e ambiente (dev/test/staging/prod), exige um número tão grande de GPOs que sua implementação e operação se tornariam muito complexas para serem gerenciadas com sucesso para serem implementadas Ultimo privilégio dentro do Nível 1. 

Restrições de logon definidas centralmente, mas aplicadas localmente

Restrições de logon – sendo o método mais comum para implementar controles de acesso, são definidas centralmente e armazenadas no compartilhamento de arquivos SYSVOL, baixadas para cada computador com um mapeador de política de grupo e aplicadas localmente. Esta abordagem tem várias desvantagens: 

• Usuários ou processos com privilégios de administrador em um sistema podem alterar/desabilitar/modificar restrições de logon de usuário para outras contas.  

• Problemas na análise de políticas de grupo podem levar à não aplicação de restrições de logon.  

Para detectar problemas ao aplicar as políticas ou tentativas de contorná-las (por exemplo, usando ntrights.exe or Carbono), é necessário monitorar alterações de configuração local em cada sistema, bem como relatórios centralizados de quaisquer notificações de não conformidade.  

Controles de acesso separados para não-Windows Active Directory Ativos

Uma área considerável de infraestrutura não-Windows que está de alguma forma integrada com Active Directory; se os sistemas *NIX se uniram usando alguma forma de ponte AD, aplicativos e dispositivos que dependem de LDAP, Kerberos ou autenticações NTLM com AD – geralmente usando uma conta de serviço em vez de uma identidade de máquina e não processam nenhuma ou apenas algumas políticas de grupo. Esses dispositivos, aplicativos e dispositivos precisam de seus próprios controles de acesso, normalmente definidos localmente e vinculados à associação ao grupo AD. 

Cada um desses recursos exige uma configuração dedicada para controles de acesso e monitoramento de conformidade. 

Silos de política de autenticação da Microsoft – sem panacéia

Para superar os problemas associados aos controles de acesso aplicados localmente em cada parte da infraestrutura, a Microsoft propõe Silos de política de autenticação. Eles podem ser eficazes para gerenciar e impor limites de autenticação centralmente a contas e ativos e são avaliados pelo controlador de domínio para cada autenticação. Embora seja um ótimo método para bloquear o Nível 0, sua falta de flexibilidade tende a impedir a implementação no Nível 1, o que faz com que os ativos (recursos e contas) façam parte apenas de um único silo de política de autenticação por vez. Muitas vezes, diferentes grupos de usuários privilegiados precisam de acesso a diferentes conjuntos de sistemas, que podem ser parcialmente sobrepostos, o que não se enquadra nos Silos de Política de Autenticação. 

Para usar Silos de Política de Autenticação, o Kerberos Armoring (FAST) precisa estar habilitado. Nem todas as ferramentas existentes, nomeadamente algumas PAM - Gestão de Acesso Privilegiado / Soluções do tipo Bastion são compatíveis com Kerberos Armoring.  

Após a implementação de controles de acesso eficazes no Nível 0, a implementação para outros níveis geralmente é interrompida devido a um ou mais dos desafios acima encontrados pela equipe de TI, que até agora eram muito difíceis de contornar. Vamos discutir algumas das coisas Silverfort podemos fazer para ampliar a implementação de controles de acesso e MFA além do Nível 0. 

Como funciona o dobrador de carta de canal Silverfort Ajuda com camadas do AD   

Silverfort pode melhorar Active Directory (AD) camadas por oferta ampla visibilidade e controle sobre o acesso do usuário em toda a organização. Ele monitora continuamente as atividades de autenticação e acesso, atribuindo indicadores e pontuações de risco aos usuários e máquinas com base em seus padrões de comportamento, e verifica se o contexto de autenticação corresponde a algum Silverfort políticas de autenticação. Se houver uma correspondência, a política definirá se a autenticação será permitida, pausada a autenticação para impor MFA ou bloqueada a autenticação, muito parecido com um semáforo para o seu Active Directory autenticações. Esse processo ajuda a identificar e gerenciar o acesso a ativos de alto risco ou alto valor, o que é crucial para a classificação em níveis do AD. Adicionalmente, Silverfortintegração de com azuread fornece mais insights sobre o comportamento e o risco do usuário, apoiando a implementação de uma estratégia eficaz de classificação de AD. 

Vamos ver exatamente como isso é feito em Silverfortconsole: 

pós-colheita 

Silverfort políticas estendem o conceito de controles de acesso condicional para Active Directory, permitindo o controle sobre quem pode autenticar onde, bem como o nível de garantia de autenticação (se a MFA é necessária, bem como o tipo de autenticação aceito durante a etapa de autenticação secundária), com base no contexto do usuário enriquecido com seu próprio mecanismo de risco, bem como qualquer risco percebido por mecanismos de risco de terceiros, como parte de EDR, XDR e silos de identidade em nuvem, e são aplicados centralmente no controlador de domínio. 

Aqui estão alguns exemplos Silverfort políticas de autenticação que podem ajudar na implementação de um modelo de camadas do AD: 

Bloquear logon interativo em níveis  

Após o treinamento de conscientização com administradores de TI que cruzaram barreiras de nível com suas contas de nível 0 ou nível 1 (por exemplo, descobertas usando as políticas NOTIFY propostas em o artigo do blog AD Tiering sobre visibilidade), pode ser um bom momento para mudar essas políticas de ação NOTIFY para DENY, para bloquear o uso inadequado da conta em todos os níveis e receber alertas em tempo real, bem como relatórios diários sobre quaisquer tentativas de fazer isso. 

Proteger Privilegiados Contas de usuário Com MFA apropriado

O acesso com contas privilegiadas em qualquer nível pode ser protegido com métodos MFA apropriados. Por exemplo, a administração remota do «Aplicativo X no PROD» por administradores de aplicativos de Nível 1 para este perímetro pode ser protegida com FIDO2 e/ou Silverfort Mobile Push MFA se não houver MFA de terceiros dedicado disponível para as contas de nível 1. 

Acesso seguro ao console em controladores de domínio

 Se o acesso aos controladores de domínio no console for possível (por exemplo, através do hipervisor) e não estiver protegido adequadamente, o Silverfort para a política de logon do Windows pode ajudar a proteger o acesso ao console. 

Aplicar o uso de soluções administrativas específicas de nível

Para forçar a administração de um servidor de salto administrativo dedicado ou Solução PAM em T1, a autenticação RDP e Remote PowerShell pode ser negada de qualquer outra origem usando uma política DENY. 

Interromper o movimento lateral de contas de usuário em uma camada

Para limitar o movimento lateral/implementar privilégios mínimos no Nível 1, a administração remota de um grupo de servidores «Aplicativo X no PROD» pode ser limitada ao(s) grupo(s) de administradores dos servidores de aplicativos usando uma política DENY. 

Interromper o movimento lateral por contas de serviço em uma camada

Para limitar o movimento lateral/implementar privilégios mínimos dentro do Nível 1, as contas de serviço podem ser “protegidas” para fornecer acesso apenas ao perímetro onde devem operar. 

Silverfort As políticas de proteção ajudam a estender a classificação do AD além do nível 0 

A combinação de Silverfort Firewall de autenticação, políticas de MFA e contas de serviço de políticas de proteção fornecem uma abordagem elegante e eficaz para acelerar a implantação de Active Directory Camadas além do Nível 0 

Silverfort pode ajudar a proteger contas de qualquer Active Directory nível com um método MFA mais apropriado para a tarefa. O Silverfort O firewall de autenticação permite a detecção e prevenção de qualquer acesso entre camadas por contas privilegiadas para evitar escalação de privilégios ataques, bem como limitar o acesso horizontal dentro de uma camada para evitar movimentos laterais, usando a aplicação central e evitando as complexidades típicas associadas aos métodos existentes.  

Tanto as contas humanas quanto as de serviço podem ser protegidas, bloqueando o acesso não autorizado para interromper o movimento lateral e evitar a escalada de privilégios por um adversário. Usando os controles de segurança fornecidos por Silverfort pode acelerar a implementação de um Active Directory projeto de hierarquização em camadas ou pode ajudar a colocar o projeto de volta nos trilhos se ele estiver paralisado no final da camada 0. Procurando fortalecer seu gerenciamento de hierarquização do AD e obter visibilidade completa em todo o seu ambiente? Fale com um de nossos especialistas aqui.