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.
Leitura recomendada pelo proprietário
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) |
Políticas de senha de leitura recomendada
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.
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.
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.
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.
Políticas de acesso de confiança do dispositivo leitura recomendada
- Como: Planejar sua implementação de associação híbrida do Microsoft Entra
- Configurações de identidade e acesso ao 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.
Leitura recomendada do logon único
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.
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.
Atribuir usuários a aplicativos de leitura recomendada
- Atribuir usuários e grupos a um aplicativo no Microsoft Entra ID
- Delegar permissões de registro de aplicativo no Microsoft Entra ID
- Regras de associação dinâmica para grupos no Microsoft Entra ID
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.
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.
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 baseadas em risco leitura recomendada
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.
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
Acesso condicional leitura recomendada
- Práticas recomendadas para acesso condicional no Microsoft Entra ID
- Configurações de identidade e acesso ao dispositivo
- Referência de configurações de Acesso Condicional do Microsoft Entra
- Políticas de Acesso Condicional comuns
Á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:
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:
Atualize para clientes com capacidade de autenticação moderna para os usuários afetados.
Planeje um período de tempo de transferência para bloquear de acordo com as etapas abaixo.
Identifique quais aplicativos herdados têm uma dependência rígida da autenticação herdada. Consulte o passo 3 abaixo.
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.
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.
Leitura recomendada da autenticação herdada
Concessões de consentimento
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.
O consentimento concede leitura recomendada
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:
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.
Grupos de leitura recomendada
- O que é a colaboração B2B do Microsoft Entra?
- Integrando aplicativos com o Microsoft Entra ID
- Aplicações, permissões e consentimento no Microsoft Entra ID.
- Usar grupos para gerenciar o acesso a recursos no Microsoft Entra ID
- Configurando o gerenciamento de acesso a aplicativos de autoatendimento no Microsoft Entra ID
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.
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.
Logs de leitura recomendada
- Referência da API de auditoria do Microsoft Entra
- Referência da API do relatório de atividade de entrada do Microsoft Entra
- Obter dados usando a API de relatórios do Microsoft Entra com certificados
- Proteção de ID do Microsoft Graph for Microsoft Entra
- Referência da API de Atividade de Gerenciamento do Office 365
- Como usar o Microsoft Entra ID Power BI Content Pack
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.