Partilhar via


Guia de referência de operações de gerenciamento de autenticação do Microsoft Entra

Esta seção do guia de referência de operações do Microsoft Entra descreve as verificações e ações que você deve tomar para proteger e gerenciar credenciais, definir a experiência de autenticação (AuthN), delegar atribuição, medir o uso e definir políticas de acesso com base na postura de segurança corporativa.

Nota

Estas recomendações estão atualizadas a partir da data de publicação, mas podem mudar ao longo do tempo. As organizações devem avaliar continuamente suas práticas de identidade à medida que os produtos e serviços da Microsoft evoluem ao longo do tempo.

Principais processos operacionais

Atribuir proprietários a tarefas principais

O gerenciamento do Microsoft Entra ID requer a execução contínua de tarefas e processos operacionais importantes, que podem não fazer parte de um projeto de implantação. Ainda é importante configurar essas tarefas para otimizar seu ambiente. As principais tarefas e seus proprietários recomendados incluem:

Tarefa Proprietário
Gerenciar o ciclo de vida da configuração de logon único (SSO) no Microsoft Entra ID Equipe de Operações de Gerenciamento de Identidade e Acesso (IAM)
Projetar políticas de Acesso Condicional para aplicativos Microsoft Entra Equipe de arquitetura InfoSec
Arquivar a atividade de entrada em um sistema de gerenciamento de eventos e informações de segurança (SIEM) Equipe de Operações InfoSec
Arquivar eventos de risco em um sistema SIEM Equipe de Operações InfoSec
Triagem e investigação de relatórios de segurança Equipe de Operações InfoSec
Triagem e investigação de eventos de risco Equipe de Operações InfoSec
Triagem e investigação de usuários sinalizados para relatórios de risco e vulnerabilidade do Microsoft Entra ID Protection Equipe de Operações InfoSec

Nota

A Proteção de ID do Microsoft Entra requer uma licença P2 do Microsoft Entra ID. Para encontrar a licença certa para seus requisitos, consulte Comparando os recursos geralmente disponíveis das edições Microsoft Entra ID Free e Microsoft Entra ID P1 ou P2.

À medida que você revisa sua lista, pode achar que precisa atribuir um proprietário para tarefas que estão faltando um proprietário ou ajustar a propriedade para tarefas com proprietários que não estão alinhadas com as recomendações acima.

Gestão de credenciais

Políticas de palavra-passe

Gerenciar senhas com segurança é uma das partes mais críticas do Gerenciamento de Identidade e Acesso e, muitas vezes, o maior alvo de ataques. O Microsoft Entra ID suporta vários recursos que podem ajudar a impedir que um ataque seja bem-sucedido.

Use a tabela a seguir para encontrar a solução recomendada para atenuar o problema que precisa ser resolvido:

Problema Recomendação
Nenhum mecanismo de proteção contra senhas fracas Habilite a redefinição de senha de autoatendimento (SSPR) e a proteção por senha do Microsoft Entra ID
Nenhum mecanismo para detetar senhas vazadas Permite a sincronização do hash de palavras-passe (PHS) para obter informações
Usando o AD FS e não é possível mover para a autenticação gerenciada Ativar o Bloqueio Inteligente da Extranet do AD FS e/ou o Bloqueio Inteligente do Microsoft Entra
A política de senha usa regras baseadas em complexidade, como comprimento, vários conjuntos de caracteres ou expiração Reconsidere em favor das Práticas Recomendadas da Microsoft e mude sua abordagem para o gerenciamento de senhas e implante a proteção por senha do Microsoft Entra.
Os usuários não estão registrados para usar a autenticação multifator Registar todas as informações de segurança do utilizador para que possam ser utilizadas como um mecanismo para verificar a identidade do utilizador juntamente com a sua palavra-passe
Não há revogação de senhas com base no risco do usuário Implantar políticas de risco do usuário do Microsoft Entra ID Protection para forçar alterações de senha em credenciais vazadas usando SSPR
Não há nenhum mecanismo de bloqueio inteligente para proteger a autenticação maliciosa de agentes mal-intencionados provenientes de endereços IP identificados Implementar a autenticação gerida pela cloud com a sincronização do hash de palavras-passe ou a autenticação pass-through (PTA)

Habilite a redefinição de senha de autoatendimento e a proteção por senha

Os usuários que precisam alterar ou redefinir suas senhas são uma das maiores fontes de volume e custo de chamadas de suporte técnico. Além do custo, alterar a senha como ferramenta para mitigar um risco do usuário é um passo fundamental para melhorar a postura de segurança da sua organização.

No mínimo, é recomendável implantar a redefinição de senha de autoatendimento (SSPR) do Microsoft Entra ID e a proteção por senha local para realizar:

  • Desviar chamadas de suporte técnico.
  • Substitua o uso de senhas temporárias.
  • Substitua qualquer solução de gerenciamento de senhas de autoatendimento existente que dependa de uma solução local.
  • Elimine senhas fracas em sua organização.

Nota

Para organizações com licenças do Microsoft Entra ID P2, é recomendável implantar o SSPR e usá-lo como parte de uma política de Acesso Condicional baseada em risco da Proteção de ID do Microsoft Entra.

Forte gerenciamento de credenciais

As senhas por si só não são seguras o suficiente para impedir que agentes mal-intencionados tenham acesso ao seu ambiente. No mínimo, qualquer usuário com uma conta privilegiada deve estar habilitado para autenticação multifator. Idealmente, você deve habilitar o registro combinado e exigir que todos os usuários se registrem para autenticação multifator e SSPR usando a experiência de registro combinado. Eventualmente, recomendamos que você adote uma estratégia para fornecer resiliência para reduzir o risco de bloqueio devido a circunstâncias imprevistas.

Fluxo combinado de experiência do usuário

Resiliência de autenticação de interrupção local

Além dos benefícios da simplicidade e de permitir a deteção de credenciais vazadas, o Microsoft Entra Password Hash Sync (PHS) e a autenticação multifator Microsoft Entra permitem que os usuários acessem aplicativos de software como serviço (SaaS) e o Microsoft 365, apesar das interrupções no local devido a ataques cibernéticos, como o NotPetya. Também é possível habilitar o PHS em conjunto com a federação. A habilitação do PHS permite um fallback de autenticação quando os serviços de federação não estão disponíveis.

Se sua organização local não tiver uma estratégia de resiliência de interrupção ou tiver uma que não esteja integrada ao Microsoft Entra ID, você deverá implantar o Microsoft Entra PHS e definir um plano de recuperação de desastres que inclua o PHS. Habilitar o Microsoft Entra PHS permitirá que os usuários se autentiquem no Microsoft Entra ID caso o Ative Directory local não esteja disponível.

fluxo de sincronização do hash de palavras-palavra

Para entender melhor suas opções de autenticação, consulte Escolher o método de autenticação certo para sua solução de identidade híbrida do Microsoft Entra.

Uso programático de credenciais

Os scripts do Microsoft Entra ID usando o PowerShell ou aplicativos que usam a API do Microsoft Graph exigem autenticação segura. O gerenciamento deficiente de credenciais executando esses scripts e ferramentas aumenta o risco de roubo de credenciais. Se você estiver usando scripts ou aplicativos que dependem de senhas codificadas ou prompts de senha, você deve primeiro revisar senhas em arquivos de configuração ou código-fonte, em seguida, substituir essas dependências e usar Identidades Gerenciadas do Azure, Autenticação Integrada do Windows ou certificados sempre que possível. Para aplicativos em que as soluções anteriores não são possíveis, considere usar o Azure Key Vault.

Se você determinar que há entidades de serviço com credenciais de senha e não tiver certeza de como essas credenciais de senha são protegidas por scripts ou aplicativos, entre em contato com o proprietário do aplicativo para entender melhor os padrões de uso.

A Microsoft também recomenda que você entre em contato com os proprietários de aplicativos para entender os padrões de uso se houver entidades de serviço com credenciais de senha.

Experiência de autenticação

Autenticação local

A autenticação federada com autenticação integrada do Windows (IWA) ou autenticação gerenciada de logon único contínuo (SSO) com sincronização de hash de senha ou autenticação de passagem é a melhor experiência do usuário quando está dentro da rede corporativa com linha de visão para controladores de domínio locais. Ele minimiza a fadiga do prompt de credenciais e reduz o risco de os usuários serem vítimas de ataques de phishing. Se você já estiver usando a autenticação gerenciada na nuvem com PHS ou PTA, mas os usuários ainda precisarem digitar sua senha ao autenticar localmente, implante imediatamente o SSO contínuo. Por outro lado, se você estiver atualmente federado com planos de migrar eventualmente para a autenticação gerenciada na nuvem, implemente o SSO contínuo como parte do projeto de migração.

Políticas de acesso de confiança do dispositivo

Como um usuário em sua organização, um dispositivo é uma identidade central que você deseja proteger. Você pode usar a identidade de um dispositivo para proteger seus recursos a qualquer momento e de qualquer local. Autenticar o dispositivo e contabilizar o seu tipo de confiança melhora a sua postura de segurança e usabilidade ao:

  • Evitar atrito, por exemplo, com autenticação multifator, quando o dispositivo é confiável
  • Bloquear o acesso a partir de dispositivos não fidedignos
  • Para dispositivos Windows 10, forneça logon único para recursos locais sem problemas.

Você pode realizar essa meta trazendo identidades de dispositivo e gerenciando-as no Microsoft Entra ID usando um dos seguintes métodos:

  • As organizações podem usar o Microsoft Intune para gerenciar o dispositivo e aplicar políticas de conformidade, atestar a integridade do dispositivo e definir políticas de Acesso Condicional com base na conformidade do dispositivo. O Microsoft Intune pode gerir dispositivos iOS, ambientes de trabalho Mac (através da integração JAMF), ambientes de trabalho Windows (utilizando nativamente a Gestão de Dispositivos Móveis para Windows 10 e cogestão com o Microsoft Configuration Manager) e dispositivos móveis Android.
  • A associação híbrida do Microsoft Entra fornece gerenciamento com Diretivas de Grupo ou Microsoft Configuration Manager em um ambiente com dispositivos de computadores associados ao domínio do Ative Directory. As organizações podem implantar um ambiente gerenciado por meio de PHS ou PTA com SSO contínuo. Trazer seus dispositivos para o Microsoft Entra ID maximiza a produtividade do usuário por meio do SSO em seus recursos locais e na nuvem e, ao mesmo tempo, permite que você proteja o acesso aos seus recursos na nuvem e no local com Acesso Condicional .

Se você tiver dispositivos Windows que ingressaram no domínio que não estão registrados na nuvem ou dispositivos Windows que ingressaram no domínio que estão registrados na nuvem, mas sem políticas de Acesso Condicional, registre os dispositivos não registrados e, em ambos os casos, use a associação híbrida do Microsoft Entra como um controle em suas políticas de Acesso Condicional.

Uma captura de tela da concessão na política de Acesso Condicional que requer dispositivo híbrido

Se você estiver gerenciando dispositivos com MDM ou Microsoft Intune, mas não estiver usando controles de dispositivo em suas políticas de Acesso Condicional, recomendamos usar Exigir que o dispositivo seja marcado como compatível como um controle nessas políticas.

Uma captura de tela da concessão na política de Acesso Condicional que exige conformidade do dispositivo

Windows Hello para empresas

No Windows 10, o Windows Hello for Business substitui senhas por autenticação forte de dois fatores em PCs. O Windows Hello for Business permite uma experiência de autenticação multifator mais simplificada para os usuários e reduz sua dependência de senhas. Se você ainda não começou a implantar dispositivos Windows 10 ou os implantou parcialmente, recomendamos que atualize para o Windows 10 e habilite o Windows Hello for Business em todos os dispositivos.

Se quiser saber mais sobre a autenticação sem senha, consulte Um mundo sem senhas com o Microsoft Entra ID.

Autenticação e atribuição de aplicativos

Logon único para aplicativos

Fornecer um mecanismo de logon único padronizado para toda a empresa é crucial para a melhor experiência do usuário, redução de riscos, capacidade de relatório e governança. Se você estiver usando aplicativos que suportam SSO com ID do Microsoft Entra, mas estão atualmente configurados para usar contas locais, você deve reconfigurar esses aplicativos para usar o SSO com o ID do Microsoft Entra. Da mesma forma, se você estiver usando qualquer aplicativo que ofereça suporte a SSO com o Microsoft Entra ID, mas estiver usando outro Provedor de Identidade, deverá reconfigurar esses aplicativos para usar o SSO com o Microsoft Entra ID também. Para aplicativos que não oferecem suporte a protocolos de federação, mas oferecem suporte à autenticação baseada em formulários, recomendamos que você configure o aplicativo para usar o cofre de senhas com o proxy de aplicativo Microsoft Entra.

Nota

Se você não tiver um mecanismo para descobrir aplicativos não gerenciados em sua organização, recomendamos implementar um processo de descoberta usando um agente de segurança de aplicativos em nuvem (CASB), como o Microsoft Defender for Cloud Apps.

Por fim, se você tiver uma galeria de aplicativos do Microsoft Entra e usar aplicativos que suportem SSO com a ID do Microsoft Entra, recomendamos listar o aplicativo na galeria de aplicativos.

Migração de aplicativos AD FS para o Microsoft Entra ID

A migração de aplicativos do AD FS para o Microsoft Entra ID permite recursos adicionais de segurança, gerenciamento mais consistente e uma melhor experiência de colaboração. Se você tiver aplicativos configurados no AD FS que suportem SSO com ID do Microsoft Entra, deverá reconfigurar esses aplicativos para usar o SSO com o Microsoft Entra ID. Se você tiver aplicativos configurados no AD FS com configurações incomuns não suportadas pela ID do Microsoft Entra, entre em contato com os proprietários do aplicativo para entender se a configuração especial é um requisito absoluto do aplicativo. Se não for necessário, você deve reconfigurar o aplicativo para usar o SSO com o ID do Microsoft Entra.

Microsoft Entra ID como o provedor de identidade principal

Nota

O Microsoft Entra Connect Health para AD FS pode ser usado para coletar detalhes de configuração sobre cada aplicativo que pode ser migrado para o Microsoft Entra ID.

Atribuir usuários a aplicativos

A atribuição de usuários a aplicativos é melhor mapeada usando grupos porque eles permitem maior flexibilidade e capacidade de gerenciar em escala. Os benefícios do uso de grupos incluem grupos de associação dinâmica baseados em atributos e delegação a proprietários de aplicativos. Portanto, se você já estiver usando e gerenciando grupos, recomendamos que você execute as seguintes ações para melhorar o gerenciamento em escala:

  • Delegue o gerenciamento e a governança do grupo aos proprietários de aplicativos.
  • Permitir acesso de autoatendimento ao aplicativo.
  • Defina grupos de associação dinâmicos se os atributos de usuário puderem determinar consistentemente o acesso aos aplicativos.
  • Implemente o atestado para grupos usados para acesso ao aplicativo usando revisões de acesso do Microsoft Entra.

Por outro lado, se você encontrar aplicativos que tenham atribuição a usuários individuais, certifique-se de implementar a governança em torno desses aplicativos.

Políticas de acesso

Localizações com nome

Com locais nomeados no Microsoft Entra ID, você pode rotular intervalos de endereços IP confiáveis em sua organização. O Microsoft Entra ID usa locais nomeados para:

  • Prevenir falsos positivos em eventos de risco. Iniciar sessão a partir de uma localização de rede fidedigna reduz o risco de início de sessão de um utilizador.
  • Configure o Acesso Condicional baseado em localização.

Localização com nome

Com base na prioridade, use a tabela a seguir para encontrar a solução recomendada que melhor atenda às necessidades da sua organização:

Prioridade Cenário Recomendação
1 Se você usa PHS ou PTA e os locais nomeados não foram definidos Definir locais nomeados para melhorar a deteção de eventos de risco
2 Se você estiver federado e não usar "insideCorporateNetwork", a reivindicação e os locais nomeados não tiverem sido definidos; Definir locais nomeados para melhorar a deteção de eventos de risco
3 Se você não usa locais nomeados nas políticas de Acesso Condicional e não há riscos ou controles de dispositivo nas políticas de Acesso Condicional Configurar a política de Acesso Condicional para incluir locais nomeados
4 Se você estiver federado e usar a declaração "insideCorporateNetwork" e os locais nomeados não tiverem sido definidos Definir locais nomeados para melhorar a deteção de eventos de risco
5 Se você estiver usando endereços IP confiáveis com autenticação multifator em vez de locais nomeados e marcá-los como confiáveis Defina locais nomeados e marque-os como confiáveis para melhorar a deteção de eventos de risco

Políticas de acesso baseadas no risco

O Microsoft Entra ID pode calcular o risco para cada entrada e cada usuário. Usar o risco como critério nas políticas de acesso pode fornecer uma melhor experiência ao usuário, por exemplo, menos prompts de autenticação e melhor segurança, por exemplo, avisar os usuários apenas quando eles forem necessários e automatizar a resposta e a correção.

Política de risco do início de sessão

Se você já possui licenças do Microsoft Entra ID P2 que suportam o uso de risco em políticas de acesso, mas elas não estão sendo usadas, é altamente recomendável adicionar risco à sua postura de segurança.

Políticas de acesso ao aplicativo cliente

O Gerenciamento de Aplicativos (MAM) do Microsoft Intune fornece a capacidade de enviar por push controles de proteção de dados, como criptografia de armazenamento, PIN, limpeza de armazenamento remoto e assim por diante. para aplicativos móveis cliente compatíveis, como o Outlook Mobile. Além disso, as políticas de Acesso Condicional podem ser criadas para restringir o acesso a serviços de nuvem, como o Exchange Online, a partir de aplicativos aprovados ou compatíveis.

Se seus funcionários instalarem aplicativos compatíveis com MAM, como aplicativos móveis do Office, para acessar recursos corporativos, como o Exchange Online ou o SharePoint no Microsoft 365, e você também oferecer suporte a BYOD (traga seu próprio dispositivo), recomendamos que você implante políticas de MAM de aplicativos para gerenciar a configuração do aplicativo em dispositivos pessoais sem registro de MDM e, em seguida, atualize suas políticas de Acesso Condicional para permitir apenas o acesso de clientes compatíveis com MAM.

Controle de Concessão de Acesso Condicional

Se os funcionários instalarem aplicativos compatíveis com MAM em relação aos recursos corporativos e o acesso for restrito em dispositivos gerenciados do Intune, você deverá considerar a implantação de políticas de MAM de aplicativos para gerenciar a configuração de aplicativos para dispositivos pessoais e atualizar as políticas de Acesso Condicional para permitir apenas o acesso de clientes compatíveis com MAM.

Implementação do Acesso Condicional

O Acesso Condicional é uma ferramenta essencial para melhorar a postura de segurança da sua organização. Portanto, é importante que você siga estas práticas recomendadas:

  • Certifique-se de que todos os aplicativos SaaS tenham pelo menos uma política aplicada
  • Evite combinar o filtro Todos os aplicativos com o controle de bloqueio para evitar o risco de bloqueio
  • Evite usar Todos os usuários como um filtro e adicionar inadvertidamente Convidados
  • Migrar todas as políticas "legadas" para o portal do Azure
  • Detetar todos os critérios para usuários, dispositivos e aplicativos
  • Use políticas de Acesso Condicional para implementar a autenticação multifator, em vez de usar uma MFA por usuário
  • Ter um pequeno conjunto de políticas principais que podem ser aplicadas a vários aplicativos
  • Definir grupos de exceções vazios e adicioná-los às políticas para ter uma estratégia de exceção
  • Planeje contas de vidro quebrado sem controles de autenticação multifator
  • Garanta uma experiência consistente em aplicativos cliente do Microsoft 365, por exemplo, Teams, OneDrive, Outlook e assim por diante.) implementando o mesmo conjunto de controles para serviços como o Exchange Online e o SharePoint no Microsoft 365
  • A atribuição a políticas deve ser implementada através de grupos, não de indivíduos
  • Faça revisões regulares dos grupos de exceção usados nas políticas para limitar o tempo que os usuários estão fora da postura de segurança. Se você possui o Microsoft Entra ID P2, então você pode usar as revisões de acesso para automatizar o processo

Área de superfície de acesso

Autenticação legada

Credenciais fortes, como a autenticação multifator, não podem proteger aplicativos usando protocolos de autenticação herdados, o que o torna o vetor de ataque preferido por atores mal-intencionados. Bloquear a autenticação herdada é crucial para melhorar a postura de segurança de acesso.

Autenticação herdada é um termo que se refere a protocolos de autenticação usados por aplicativos como:

  • Clientes mais antigos do Office que não usam autenticação moderna (por exemplo, cliente do Office 2010)
  • Clientes que usam protocolos de email, como IMAP (Internet Message Access Protocol)/SMTP (Simple Mail Transfer Protocol)/ponto de presença (POP)

Os atacantes preferem fortemente esses protocolos - na verdade, quase 100% dos ataques de pulverização de senha usam protocolos de autenticação legados! Os hackers usam protocolos de autenticação herdados, porque não suportam o início de sessão interativo, que é necessário para desafios de segurança adicionais, como a autenticação multifator e a autenticação de dispositivos.

Se a autenticação herdada for amplamente usada em seu ambiente, você deve planejar migrar clientes herdados para clientes que ofereçam suporte à autenticação moderna o mais rápido possível. Da mesma forma, se você tiver alguns usuários já usando autenticação moderna, mas outros que ainda usam autenticação herdada, você deve executar as seguintes etapas para bloquear clientes de autenticação herdada:

  1. Use os relatórios de atividade de entrada para identificar os usuários que ainda estão usando a autenticação herdada e planejar a correção:

    1. Atualize para clientes com capacidade de autenticação moderna para os usuários afetados.

    2. Planeje um período de tempo de transferência para bloquear de acordo com as etapas abaixo.

    3. Identifique quais aplicativos herdados têm uma dependência rígida da autenticação herdada. Consulte o passo 3 abaixo.

  2. Desabilite protocolos herdados na origem (por exemplo, Caixa de Correio do Exchange) para usuários que não estão usando autenticação herdada para evitar mais exposição.

  3. Para as contas restantes (idealmente identidades não humanas, como contas de serviço), use o Acesso Condicional para restringir protocolos herdados pós-autenticação.

Em um ataque de concessão de consentimento ilícito, o invasor cria um aplicativo registrado do Microsoft Entra que solicita acesso a dados como informações de contato, email ou documentos. Os usuários podem estar concedendo consentimento para aplicativos mal-intencionados por meio de ataques de phishing ao acessar sites mal-intencionados.

Abaixo está uma lista de aplicativos com permissões que você pode querer examinar para serviços do Microsoft Cloud:

  • Aplicações com aplicação ou delegadas *. Permissões de ReadWrite
  • Os aplicativos com permissões delegadas podem ler, enviar ou gerenciar emails em nome do usuário
  • Aplicativos que recebem as seguintes permissões:
Recurso Permissão
Exchange Online EAS. AccessAsUser.All
EWS. AccessAsUser.All
Mail.Leia
Microsoft Graph API Mail.Leia
Mail.Read.Compartilhado
Mail.ReadWrite
  • Os aplicativos concederam representação total do usuário conectado. Por exemplo:
Recurso Permissão
Microsoft Graph API Directory.AccessAsUser.All
API REST do Azure user_impersonation

Para evitar esse cenário, consulte Detetar e remediar concessões de consentimento ilícitas no Office 365 para identificar e corrigir quaisquer aplicativos com concessões ilícitas ou aplicativos que tenham mais concessões do que o necessário. Em seguida, remova completamente o autosserviço e estabeleça procedimentos de governança. Por fim, agende revisões regulares das permissões do aplicativo e remova-as quando não forem necessárias.

Configurações de usuário e grupo

Abaixo estão as configurações de usuário e grupo que podem ser bloqueadas se não houver uma necessidade comercial explícita:

Definições do utilizador

  • Usuários externos - a colaboração externa pode acontecer organicamente na empresa com serviços como Teams, Power BI, SharePoint no Microsoft 365 e Proteção de Informações do Azure. Se você tiver restrições explícitas para controlar a colaboração externa iniciada pelo usuário, é recomendável habilitar usuários externos usando o gerenciamento de direitos do Microsoft Entra ou uma operação controlada, como por meio do suporte técnico. Se você não quiser permitir a colaboração externa orgânica para serviços, poderá impedir que os membros convidem usuários externos completamente. Como alternativa, você também pode permitir ou bloquear domínios específicos em convites de usuários externos.
  • Registos de Aplicações - quando os registos de Aplicações estão ativados, os utilizadores finais podem integrar as próprias aplicações e conceder acesso aos seus dados. Um exemplo típico de registro de aplicativo é usuários que habilitam plug-ins do Outlook ou assistentes de voz, como Alexa e Siri, para ler seus e-mails e calendários ou enviar e-mails em seu nome. Se o cliente decidir desativar o registro do aplicativo, as equipes do InfoSec e do IAM devem estar envolvidas no gerenciamento de exceções (registros de aplicativos que são necessários com base nos requisitos de negócios), pois precisariam registrar os aplicativos com uma conta de administrador e, muito provavelmente, exigiriam projetar um processo para operacionalizar o processo.
  • Portal de Administração - as organizações podem bloquear a folha Microsoft Entra no portal do Azure para que os não-administradores não possam acessar o gerenciamento do Microsoft Entra no portal do Azure e fiquem confusos. Vá para as configurações do usuário no portal de gerenciamento do Microsoft Entra para restringir o acesso:

Acesso restrito ao portal de administração

Nota

Os não-administradores ainda podem acessar as interfaces de gerenciamento do Microsoft Entra por meio da linha de comando e outras interfaces programáticas.

Definições de grupo

Gerenciamento de grupo de autoatendimento / Os usuários podem criar grupos de segurança / grupos do Microsoft 365. Se não houver nenhuma iniciativa de autoatendimento atual para grupos na nuvem, os clientes podem decidir desativá-la até que estejam prontos para usar esse recurso.

Tráfego de locais inesperados

Os atacantes são originários de várias partes do mundo. Gerencie esse risco usando políticas de Acesso Condicional com a localização como condição. A condição de localização de uma política de Acesso Condicional permite-lhe bloquear o acesso a locais a partir dos quais não existe qualquer motivo comercial para iniciar sessão.

Criar um novo local nomeado

Se disponível, use uma solução de gerenciamento de eventos e informações de segurança (SIEM) para analisar e encontrar padrões de acesso entre regiões. Se você não usa um produto SIEM ou ele não está ingerindo informações de autenticação da ID do Microsoft Entra, recomendamos que você use o Azure Monitor para identificar padrões de acesso entre regiões.

Utilização do acesso

Logs do Microsoft Entra arquivados e integrados com planos de resposta a incidentes

Ter acesso à atividade de entrada, auditorias e eventos de risco para o Microsoft Entra ID é crucial para a solução de problemas, análise de uso e investigações forenses. O Microsoft Entra ID fornece acesso a essas fontes por meio de APIs REST que têm um período de retenção limitado. Um sistema de gerenciamento de informações e eventos de segurança (SIEM), ou tecnologia de arquivamento equivalente, é fundamental para o armazenamento de longo prazo de auditorias e capacidade de suporte. Para habilitar o armazenamento de longo prazo de logs do Microsoft Entra, você deve adicioná-los à sua solução SIEM existente ou usar o Azure Monitor. Arquive logs que podem ser usados como parte de seus planos de resposta a incidentes e investigações.

Resumo

Há 12 aspetos em uma infraestrutura de identidade segura. Essa lista ajudará você a proteger e gerenciar ainda mais as credenciais, definir a experiência de autenticação, delegar atribuições, medir o uso e definir políticas de acesso com base na postura de segurança corporativa.

  • Atribua proprietários a tarefas principais.
  • Implemente soluções para detetar senhas fracas ou vazadas, melhorar o gerenciamento e a proteção de senhas e proteger ainda mais o acesso do usuário aos recursos.
  • Gerencie a identidade dos dispositivos para proteger seus recursos a qualquer momento e de qualquer local.
  • Implemente a autenticação sem senha.
  • Forneça um mecanismo de logon único padronizado em toda a organização.
  • Migre aplicativos do AD FS para o Microsoft Entra ID para permitir melhor segurança e gerenciamento mais consistente.
  • Atribua usuários a aplicativos usando grupos para permitir maior flexibilidade e capacidade de gerenciamento em escala.
  • Configure políticas de acesso baseadas em risco.
  • Bloqueie protocolos de autenticação herdados.
  • Detetar e remediar concessões de consentimento ilícitas.
  • Bloqueie as configurações de usuário e grupo.
  • Habilite o armazenamento de longo prazo de logs do Microsoft Entra para solução de problemas, análise de uso e investigações forenses.

Próximos passos

Comece com as verificações e ações operacionais de governança de identidade.