Partilhar via

Configurar o Microsoft Entra para Zero Trust: Proteja sistemas de engenharia

O pilar da Iniciativa Futuro Seguro para proteger sistemas de engenharia foi desenvolvido pela primeira vez para salvaguardar os próprios ativos de software e infraestrutura da Microsoft. As práticas e insights obtidos com esse trabalho interno agora são compartilhados com os clientes, permitindo que você fortaleça seus próprios ambientes.

Essas recomendações se concentram em garantir o acesso com privilégios mínimos aos sistemas e recursos de engenharia da sua organização.

Recomendações de segurança

As contas de acesso de emergência são configuradas adequadamente

A Microsoft recomenda que as organizações tenham duas contas de acesso de emergência somente na nuvem permanentemente atribuídas à função de Administrador Global . Essas contas são altamente privilegiadas e não são atribuídas a indivíduos específicos. As contas são limitadas a cenários de emergência ou de "quebra de vidro" em que as contas normais não podem ser usadas ou todos os outros administradores são bloqueados acidentalmente.

Ação de reparação

A ativação da função de Administrador Global aciona um fluxo de trabalho de aprovação

Sem fluxos de trabalho de aprovação, os agentes de ameaças que comprometem as credenciais do Administrador Global por meio de phishing, preenchimento de credenciais ou outras técnicas de desvio de autenticação podem ativar imediatamente a função mais privilegiada em um locatário sem qualquer outra verificação ou supervisão. O Privileged Identity Management (PIM) permite que ativações de funções qualificadas fiquem ativas em segundos, para que as credenciais comprometidas possam permitir o escalonamento de privilégios quase instantâneo. Uma vez ativados, os agentes de ameaças podem usar a função de Administrador Global para usar os seguintes caminhos de ataque para obter acesso persistente ao locatário:

  • Criar novas contas privilegiadas
  • Modificar políticas de Acesso Condicional para excluir essas novas contas
  • Estabeleça métodos de autenticação alternativos, como autenticação baseada em certificado ou registros de aplicativos com altos privilégios

A função de Administrador Global fornece acesso a recursos administrativos no ID do Microsoft Entra e serviços que usam identidades do Microsoft Entra, incluindo Microsoft Defender XDR, Microsoft Purview, Exchange Online e SharePoint Online. Sem portas de aprovação, os agentes de ameaças podem escalar rapidamente para concluir a aquisição do locatário, exfiltrando dados confidenciais, comprometendo todas as contas de usuário e estabelecendo backdoors de longo prazo por meio de entidades de serviço ou modificações de federação que persistem mesmo depois que o comprometimento inicial é detetado.

Ação de reparação

Os Administradores Globais não têm acesso permanente às subscrições do Azure

Os Administradores Globais com acesso persistente às subscrições do Azure expandem a superfície de ataque para agentes de ameaças. Se uma conta de Administrador Global for comprometida, os invasores poderão enumerar recursos imediatamente, modificar configurações, atribuir funções e exfiltrar dados confidenciais em todas as assinaturas. A exigência de elevação just-in-time para acesso à assinatura introduz sinais detetáveis, diminui a velocidade do invasor e encaminha operações de alto impacto por meio de pontos de controle observáveis.

Ação de reparação

A criação de novos aplicativos e entidades de serviço é restrita a usuários privilegiados

Se usuários sem privilégios puderem criar aplicativos e entidades de serviço, essas contas poderão ser configuradas incorretamente ou receber mais permissões do que o necessário, criando novos vetores para que os invasores obtenham acesso inicial. Os invasores podem explorar essas contas para estabelecer credenciais válidas no ambiente e ignorar alguns controles de segurança.

Se essas contas sem privilégios receberem por engano permissões elevadas de proprietário de aplicativos, os invasores poderão usá-las para passar de um nível inferior de acesso para um nível mais privilegiado de acesso. Os invasores que comprometem contas sem privilégios podem adicionar suas próprias credenciais ou alterar as permissões associadas aos aplicativos criados pelos usuários sem privilégios para garantir que eles possam continuar a acessar o ambiente sem serem detetados.

Os invasores podem usar entidades de serviço para se misturar com processos e atividades legítimas do sistema. Como as entidades de serviço geralmente executam tarefas automatizadas, as atividades maliciosas realizadas nessas contas podem não ser sinalizadas como suspeitas.

Ação de reparação

Os aplicativos inativos não têm permissões altamente privilegiadas da API do Microsoft Graph

Os invasores podem explorar aplicativos válidos, mas inativos, que ainda têm privilégios elevados. Essas aplicações podem ser usadas para obter acesso inicial sem disparar alarme porque são aplicações legítimas. A partir daí, os invasores podem usar os privilégios do aplicativo para planejar ou executar outros ataques. Os invasores também podem manter o acesso manipulando o aplicativo inativo, como adicionando credenciais. Essa persistência garante que, mesmo que o método de acesso principal seja detetado, eles possam recuperar o acesso mais tarde.

Ação de reparação

Os aplicativos inativos não têm funções internas altamente privilegiadas

Os invasores podem explorar aplicativos válidos, mas inativos, que ainda têm privilégios elevados. Essas aplicações podem ser usadas para obter acesso inicial sem disparar alarme porque são aplicações legítimas. A partir daí, os invasores podem usar os privilégios do aplicativo para planejar ou executar outros ataques. Os invasores também podem manter o acesso manipulando o aplicativo inativo, como adicionando credenciais. Essa persistência garante que, mesmo que o método de acesso principal seja detetado, eles possam recuperar o acesso mais tarde.

Ação de reparação

Os registros de aplicativos usam URIs de redirecionamento seguro

Os aplicativos OAuth configurados com URLs que incluem curingas ou encurtadores de URL aumentam a superfície de ataque para agentes de ameaça. URIs de redirecionamento inseguros (URLs de resposta) podem permitir que adversários manipulem solicitações de autenticação, sequestrem códigos de autorização e intercetem tokens direcionando os usuários para pontos de extremidade controlados por invasores. As entradas curinga expandem o risco ao permitir que domínios não intencionais processem respostas de autenticação, enquanto URLs encurtadores podem facilitar phishing e roubo de token em ambientes não controlados.

Sem uma validação rigorosa dos URIs de redirecionamento, os invasores podem ignorar os controles de segurança, personificar aplicativos legítimos e aumentar seus privilégios. Essa configuração incorreta permite persistência, acesso não autorizado e movimento lateral, à medida que os adversários exploram a fraca aplicação do OAuth para se infiltrar em recursos protegidos sem serem detetados.

Ação de reparação

As entidades de serviço usam URIs de redirecionamento seguro

Aplicativos não Microsoft e multilocatários configurados com URLs que incluem curingas, localhost ou encurtadores de URL aumentam a superfície de ataque para agentes de ameaça. Esses URIs (URLs de resposta) de redirecionamento inseguros podem permitir que adversários manipulem solicitações de autenticação, sequestrem códigos de autorização e intercetem tokens direcionando os usuários para pontos de extremidade controlados por invasores. As entradas curinga expandem o risco permitindo que domínios não intencionais processem respostas de autenticação, enquanto URLs de host local e encurtador podem facilitar phishing e roubo de token em ambientes não controlados.

Sem uma validação rigorosa dos URIs de redirecionamento, os invasores podem ignorar os controles de segurança, personificar aplicativos legítimos e aumentar seus privilégios. Essa configuração incorreta permite persistência, acesso não autorizado e movimento lateral, à medida que os adversários exploram a fraca aplicação do OAuth para se infiltrar em recursos protegidos sem serem detetados.

Ação de reparação

Os registros de aplicativos não devem ter URIs de redirecionamento de domínio suspensos ou abandonados

URIs de redirecionamento não mantidos ou órfãos em registros de aplicativos criam vulnerabilidades de segurança significativas quando fazem referência a domínios que não apontam mais para recursos ativos. Os agentes de ameaças podem explorar essas entradas DNS "pendentes" provisionando recursos em domínios abandonados, assumindo efetivamente o controle dos pontos de extremidade de redirecionamento. Essa vulnerabilidade permite que os invasores intercetem tokens e credenciais de autenticação durante os fluxos do OAuth 2.0, o que pode levar a acesso não autorizado, sequestro de sessão e potencial comprometimento organizacional mais amplo.

Ação de reparação

Permitir que os proprietários de grupos consintam com aplicativos no Microsoft Entra ID cria um caminho de escalonamento lateral que permite que os agentes de ameaças persistam e roubem dados sem credenciais de administrador. Se um invasor comprometer uma conta de proprietário de grupo, ele poderá registrar ou usar um aplicativo mal-intencionado e consentir com permissões de alto privilégio da API do Graph com escopo para o grupo. Os atacantes podem potencialmente ler todas as mensagens do Teams, acessar arquivos do SharePoint ou gerenciar a associação ao grupo. Essa ação de consentimento cria uma identidade de aplicativo de longa duração com permissões delegadas ou de aplicativo. O invasor mantém a persistência com tokens OAuth, rouba dados confidenciais de canais e arquivos da equipe e se faz passar por usuários por meio de permissões de mensagens ou e-mail. Sem a aplicação centralizada de políticas de consentimento de aplicativos, as equipes de segurança perdem visibilidade e aplicativos mal-intencionados se espalham sob o radar, permitindo ataques em vários estágios em plataformas de colaboração.

Ação de reparação Configure a pré-aprovação das permissões de Consentimento de Resource-Specific (RSC).

As identidades de carga de trabalho não recebem funções privilegiadas

Se os administradores atribuírem funções privilegiadas a identidades de carga de trabalho, como entidades de serviço ou identidades gerenciadas, o locatário poderá ser exposto a riscos significativos se essas identidades forem comprometidas. Os agentes de ameaças que obtêm acesso a uma identidade de carga de trabalho privilegiada podem realizar reconhecimento para enumerar recursos, escalar privilégios e manipular ou exfiltrar dados confidenciais. A cadeia de ataques normalmente começa com roubo de credenciais ou abuso de um aplicativo vulnerável. A próxima etapa é o escalonamento de privilégios por meio da função atribuída, o movimento lateral entre os recursos de nuvem e, finalmente, a persistência por meio de outras atribuições de função ou atualizações de credenciais. As identidades de carga de trabalho são frequentemente usadas na automação e podem não ser monitoradas tão de perto quanto as contas de usuário. O comprometimento pode passar despercebido, permitindo que os agentes de ameaças mantenham o acesso e o controle sobre recursos críticos. As identidades de carga de trabalho não estão sujeitas a proteções centradas no usuário, como MFA, tornando essencial a atribuição de privilégios mínimos e a revisão regular.

Ação de reparação

Os aplicativos corporativos devem exigir atribuição explícita ou provisionamento com escopo

Quando os aplicativos corporativos não têm requisitos de atribuição explícitos E controles de provisionamento com escopo, os agentes de ameaças podem explorar essa dupla fraqueza para obter acesso não autorizado a aplicativos e dados confidenciais. O maior risco ocorre quando os aplicativos são configurados com a configuração padrão: "Atribuição necessária" é definido como "Não" e o provisionamento não é necessário ou tem escopo. Essa combinação perigosa permite que os agentes de ameaças que comprometem qualquer conta de usuário dentro do locatário acessem imediatamente aplicativos com amplas bases de usuários, expandindo sua superfície de ataque e potencial de movimento lateral dentro da organização.

Enquanto um aplicativo com atribuição aberta, mas escopo de provisionamento adequado (como filtros baseados em departamento ou requisitos de associação a grupos) mantém controles de segurança por meio da camada de provisionamento, os aplicativos sem ambos os controles criam caminhos de acesso irrestritos que os agentes de ameaças podem explorar. Quando os aplicativos provisionam contas para todos os usuários sem restrições de atribuição, os agentes de ameaças podem abusar de contas comprometidas para realizar atividades de reconhecimento, enumerar dados confidenciais em vários sistemas ou usar os aplicativos como pontos de preparação para ataques adicionais contra recursos conectados. Esse modelo de acesso irrestrito é perigoso para aplicativos que têm permissões elevadas ou estão conectados a sistemas de negócios críticos. Os agentes de ameaças podem usar qualquer conta de usuário comprometida para acessar informações confidenciais, modificar dados ou executar ações não autorizadas permitidas pelas permissões do aplicativo. A ausência de controles de atribuição e escopo de provisionamento também impede que as organizações implementem uma governança de acesso adequada. Sem uma governança adequada, é difícil rastrear quem tem acesso a quais aplicativos, quando o acesso foi concedido e se o acesso deve ser revogado com base em mudanças de função ou status de emprego. Além disso, aplicativos com amplos escopos de provisionamento podem criar riscos de segurança em cascata onde uma única conta comprometida fornece acesso a todo um ecossistema de aplicativos e serviços conectados.

Ação de reparação

Limitar o número máximo de dispositivos por utilizador a 10

Controlar a proliferação de dispositivos é importante. Defina um limite razoável para o número de dispositivos que cada usuário pode registrar em seu locatário do Microsoft Entra ID. Limitar o registro de dispositivos mantém a segurança e, ao mesmo tempo, permite flexibilidade nos negócios. O Microsoft Entra ID permite que os usuários registrem até 50 dispositivos por padrão. Reduzir esse número para 10 minimiza a superfície de ataque e simplifica o gerenciamento de dispositivos.

Ação de reparação

As políticas de Acesso Condicional para Estações de Trabalho de Acesso Privilegiado estão configuradas

Se as ativações de função privilegiada não estiverem restritas a Estações de Trabalho de Acesso Privilegiado (PAWs) dedicadas, os agentes de ameaças poderão explorar dispositivos de ponto de extremidade comprometidos para executar ataques de escalonamento privilegiados de estações de trabalho não gerenciadas ou não compatíveis. As estações de trabalho de produtividade padrão geralmente contêm vetores de ataque, como navegação irrestrita na Web, clientes de e-mail vulneráveis a phishing e aplicativos instalados localmente com vulnerabilidades potenciais. Quando os administradores ativaram funções privilegiadas dessas estações de trabalho, os agentes de ameaças que obtêm acesso inicial por meio de malware, explorações de navegador ou engenharia social podem usar as credenciais privilegiadas armazenadas em cache localmente ou sequestrar sessões autenticadas existentes para aumentar seus privilégios. As ativações de função privilegiada concedem amplos direitos administrativos no Microsoft Entra ID e nos serviços conectados, para que os invasores possam criar novas contas administrativas, modificar políticas de segurança, acessar dados confidenciais em todos os recursos organizacionais e implantar malware ou backdoors em todo o ambiente para estabelecer acesso persistente. Esse movimento lateral de um endpoint comprometido para recursos de nuvem privilegiados representa um caminho de ataque crítico que ignora muitos controles de segurança tradicionais. O acesso privilegiado parece legítimo quando originado de uma sessão de administrador autenticado.

Se essa verificação for aprovada, seu locatário terá uma política de Acesso Condicional que restringe o acesso de função privilegiada a dispositivos PAW, mas não é o único controle necessário para habilitar totalmente uma solução PAW. Você também precisa configurar uma política de configuração e conformidade de dispositivo do Intune e um filtro de dispositivo.

Ação de reparação

  • Last updated on