Guia de referência de operações de gerenciamento de autenticação 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 executar 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 da empresa.
Observação
Essas recomendações são atuais a partir da data de publicação, mas podem mudar ao longo do tempo. As organizações devem avaliar frequentemente suas práticas de identidade à medida que os produtos e os serviços da Microsoft evoluem.
Principais processos operacionais
Atribuir tarefas importantes aos proprietários
O gerenciamento do Microsoft Entra ID requer a execução contínua das principais tarefas e processos operacionais, que podem não fazer parte de um projeto de distribuição. Ainda é importante que você configure 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 SSO (logon único) no Microsoft Entra ID | Equipe de operações do Gerenciamento de Identidades e Acesso (IAM) |
| Criar políticas de Acesso Condicional para aplicativos Microsoft Entra | Equipe de arquitetura da InfoSec |
| Arquivar a atividade de entrada em um sistema de gerenciamento de eventos e informações de segurança (SIEM) | Equipe de operações da InfoSec |
| Arquivar eventos de risco em um sistema SIEM | Equipe de operações da InfoSec |
| Fazer triagem e investigar relatórios de segurança | Equipe de operações da InfoSec |
| Fazer triagem e investigar eventos de risco | Equipe de operações da InfoSec |
| Fazer triagem e investigar usuários sinalizados para os relatórios de risco e vulnerabilidades do Microsoft Entra ID Identity Protection | Equipe de operações da InfoSec |
Observação
Microsoft Entra ID Protection requer uma licença Microsoft Entra ID P2. Para encontrar a licença certa para seus requisitos, consulte Comparando os recursos disponíveis em geral das edições ID de Microsoft Entra Gratuita e Microsoft Entra ID P1 ou P2.
Ao revisar sua lista, talvez você conclua ser necessário atribuir um proprietário para tarefas sem proprietário ou ajustar a propriedade para tarefas com proprietários que não estão alinhados com as recomendações acima.
Proprietário – leitura recomendada
Gerenciamento de credenciais
Políticas de senha
Gerenciar senhas com segurança é uma das partes mais críticas do Gerenciamento de Identidades e Acesso e, muitas vezes, o maior alvo de ataques. O Microsoft Entra ID dá suporte a 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 para proteção contra senhas fracas | Habilitar a SSPR (redefinição de senha self-service)e a proteção de senha do Microsoft Entra ID |
| Nenhum mecanismo para detectar senhas vazadas | Habilitar a PHS (sincronização de hash de senha) para obter informações |
| Usar os AD FS e sem opção de mudar para a autenticação gerenciada | Habilitar o Bloqueio de extranet inteligente do AD FS e/ou o Bloqueio inteligente do Microsoft Entra ID |
| A política de senha usa regras baseadas em complexidade, como comprimento, vários conjuntos de caracteres ou expiração | Reconsidere a favor das Práticas recomendadas da Microsoft, e mude sua abordagem para o gerenciamento de senhas e implante a proteção de senha do Microsoft Entra ID. |
| Os usuários não estão registrados para usar a autenticação multifator | Registrar as informações de segurança de todos os usuários para que possam ser usadas como um mecanismo para verificar a identidade dos usuários junto as respectivas senhas |
| Não há revogação de senhas com base no risco do usuário | Implantar as políticas de risco do usuário do Microsoft Entra Identity Protection para forçar alterações de senha em credenciais vazadas usando a SSPR |
| Não há mecanismos de bloqueio inteligente para proteger a autenticação maliciosa de atores mal-intencionados provenientes de endereços IP identificados | Implantar a autenticação gerenciada por nuvem com a sincronização de hash de senha ou a PTA (autenticação de passagem) |
Políticas de senha – leitura recomendada
Habilitar a redefinição de senha self-service e a proteção de senha
O grande volume e custo de chamadas para o suporte técnico vêm dos usuários que precisam alterar ou redefinir as senhas deles. Além do custo, alterar a senha como uma ferramenta para mitigar um risco do usuário é uma etapa fundamental para melhorar a postura de segurança de sua organização.
No mínimo, é recomendável implantar a SSPR (redefinição de senha self-service) do Microsoft Entra ID e a proteção de senha local para:
- Evitar chamadas ao suporte técnico.
- Substituir o uso de senhas temporárias.
- Substituir soluções de gerenciamento de senha self-service existentes que dependam de uma solução local.
- Eliminar senhas fracas em sua organização.
Observação
Para organizações com uma assinatura do Microsoft Entra ID P2, é recomendável implantar a SSPR e usá-la como parte de uma Política de risco do usuário de proteção de identidade.
Gerenciamento de credenciais fortes
As senhas por si só não são seguras o suficiente para evitar que atores proibidos obtenham acesso ao seu ambiente. No mínimo, qualquer usuário com uma conta privilegiada deve ser habilitado para a MFA (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. Por último, recomendamos que você adote uma estratégia para fornecer resiliência a fim de 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 da habilitação da detecção de credenciais vazadas, a sincronização de hash de senha (PHS) do Microsoft Entra e a autenticação multifator do Microsoft Entra permitem que os usuários acessem aplicativos de software como serviço (SaaS) e o Microsoft 365 mesmo diante de interrupções locais devido a ataques cibernéticos como o NotPetya. Além disso, é possível habilitar a PHS enquanto estiver em conjunto com a federação. Habilitar a 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 se tiver uma que não esteja integrada ao Microsoft Entra, você deverá implantar a PHS do Microsoft Entra e definir um plano de recuperação de desastre que inclua a PHS. Habilitar a PHS do Microsoft Entra permitirá que os usuários se autentiquem no Microsoft Entra ID se o seu Active Directory local estiver indisponível.
Para entender melhor suas opções de autenticação, confira Escolher o método de autenticação correto para a solução de identidade híbrida do Microsoft Entra.
Uso programático de credenciais
Os scripts do Microsoft Entra com o PowerShell ou aplicativos que usam a API do Microsoft Graph exigem autenticação segura. O gerenciamento de credenciais ruins executando esses scripts e ferramentas aumenta o risco de roubo de credenciais. Se você estiver usando scripts ou aplicativos que dependem de senhas embutidas em código ou de solicitações de senha, deverá primeiro examinar as senhas em arquivos de configuração ou código-fonte e 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 o uso do 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 são protegidas por scripts ou aplicativos, contate o proprietário do aplicativo para entender melhor os padrões de uso.
A Microsoft também recomenda que você contate os proprietários do aplicativo 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 a IWA (Autenticação Integrada do Windows) ou a autenticação gerenciada de SSO (logon único) contínuo com a sincronização de hash de senha ou a autenticação de passagem é a melhor experiência de usuário quando dentro da rede corporativa com a linha de visão para controladores de domínio locais. Minimiza a fadiga de solicitação de credenciais e reduz o risco de os usuários se depararem com ataques de phishing. Se você já estiver usando a autenticação gerenciada por nuvem com PHS ou PTA, mas os usuários ainda precisarem digitar a senha deles ao autenticar no local, você deverá implantar o SSO contínuo imediatamente. Por outro lado, se estiver atualmente federado com planos para eventualmente migrar para a autenticação gerenciada por nuvem, deverá implementar o SSO contínuo como parte do projeto de migração.
Políticas de acesso de confiança do dispositivo
Como um usuário na sua organização, um dispositivo é uma identidade importante que você quer proteger. É possível usar uma identidade do dispositivo para proteger seus recursos a qualquer momento e de qualquer local. A autenticação do dispositivo e a contabilização do respectivo tipo de confiança aumenta sua postura e usabilidade de segurança:
- Evitar atritos, por exemplo, com a autenticação multifator, quando o dispositivo é confiável
- Bloqueando o acesso de dispositivos não confiáveis
- Para dispositivos Windows 10, forneça logon único para recursos locais diretamente.
É possível alcançar essa meta colocando e gerenciando identidades de dispositivo no Microsoft Entra ID seguindo um dos seguintes métodos:
- As organizações podem usar o Microsoft Intune para gerenciar o dispositivo e impor 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 gerenciar dispositivos iOS, desktops Mac (via integração do JAMF), desktops Windows (usando nativamente o gerenciamento de dispositivo móvel para Windows 10 e o cogerenciamento com o Microsoft Configuration Manager) e dispositivos móveis Android.
- O ingresso no Microsoft Entra híbrido fornece gerenciamento com Políticas de Grupo ou o Microsoft Configuration Manager em um ambiente com dispositivos de computadores conectados ao domínio Active 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 de SSO em seus recursos de nuvem e locais, permitindo que você proteja o acesso aos recursos de nuvem e locais com acesso condicional ao mesmo tempo.
Se você tiver dispositivos Windows conectados ao domínio não registrados na nuvem ou dispositivos Windows conectados ao domínio registrados na nuvem, mas sem políticas de acesso condicional, deverá registrar os dispositivos não registrados e, em ambos os casos, usar o ingresso do Microsoft Entra híbrido 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 de dispositivo – leitura recomendada
- Como planejar sua implementação de junção híbrida Microsoft Entra
- Configurações de acesso à identidade e ao dispositivo
Windows Hello para Empresas
No Windows 10, o Windows Hello para Empresas substitui senhas por autenticação forte de dois fatores em computadores. O Windows Hello para Empresas permite uma experiência de autenticação multifator mais simplificada para usuários e reduz sua dependência de senhas. Se você não começou a distribuir dispositivos com Windows 10 ou os implantou parcialmente, recomendamos que atualize para o Windows 10 e habilite o Windows Hello para Empresas em todos os dispositivos.
Se desejar saber mais sobre autenticação sem senha, confira Um mundo sem senhas com o Microsoft Entra ID.
Atribuição e autenticação de aplicativos
Logon único para aplicativos
Fornecer um mecanismo de logon único padronizado para toda a empresa é crucial para uma melhor experiência do usuário, redução de risco, capacidade de relatório e governança. Se você estiver usando aplicativos que dão suporte ao SSO com o Microsoft Entra ID, mas que não estão atualmente configurados para usar contas locais, você deverá reconfigurar esses aplicativos para usar o SSO com o Microsoft Entra ID. Da mesma forma, se você estiver usando qualquer aplicativo que dá 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 dão suporte a protocolos de federação, mas sim à Autenticação Baseada em Formulários, recomendamos que você configure o aplicativo para usar a compartimentação de senha com o Proxy de Aplicativo do Microsoft Entra.
Observação
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 acesso à nuvem (CASB), como o Microsoft Defender para Aplicativos de Nuvem.
Por fim, se você tiver uma galeria de aplicativos do Microsoft Entra e usar aplicativos que dão suporte a SSO com o Microsoft Entra, é recomendável listar o aplicativo na galeria de aplicativos.
Logon único – leitura recomendada
Migração de aplicativos do AD FS para Microsoft Entra ID
A migração de aplicativos dos AD FS para o Microsoft Entra ID permite recursos adicionais de segurança, capacidade de gerenciamento mais consistente e uma melhor experiência de colaboração. Se você tiver aplicativos configurados nos AD FS que dão suporte a SSO com o Microsoft Entra ID, 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 sem suporte pelo Microsoft Entra ID, 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ê deverá reconfigurar o aplicativo para usar o SSO com o Microsoft Entra ID.
Observação
O Microsoft Entra Connect Health para AD FS pode ser usado para coletar detalhes de configuração sobre cada aplicativo que pode potencialmente ser migrado para o Microsoft Entra ID.
Atribuir usuários a aplicativos
A atribuição de usuários aos aplicativos é melhor mapeada usando grupos, pois eles permitem maior flexibilidade e capacidade de gerenciar em escala. Os benefícios de usar grupos incluem associação de grupo dinâmica baseada em atributo e delegação a proprietários de aplicativo. Portanto, se você já estiver usando e gerenciando grupos, recomendamos que execute as seguintes ações para melhorar o gerenciamento em escala:
- Delegue gerenciamento e governança de grupo para proprietários de aplicativos.
- Permita o acesso de autoatendimento ao aplicativo.
- Defina grupos dinâmicos se os atributos de usuário puderem determinar o acesso aos aplicativos de forma consistente.
- Implemente atestado para grupos usados para acesso do aplicativo usando revisões de acesso do Microsoft Entra.
Por outro lado, se você encontrar aplicativos com atribuição a usuários individuais, implemente a governança em torno desses aplicativos.
Atribuir usuários a aplicativos – leitura recomendada
- Atribuir usuários e grupos a um aplicativo em Microsoft Entra ID
- Delegar permissões de registro de aplicativo na ID do Microsoft Entra
- Regras de associação dinâmica para grupos no Microsoft Entra ID
Políticas de acesso
Localizações nomeadas
Com as localizações nomeadas no Microsoft Entra ID, você pode rotular os intervalos de endereços IP confiáveis em sua organização. Microsoft Entra ID usa locais nomeados para:
- Evitar falsos positivos em eventos de risco. Conectar de um local de rede confiável diminui o risco de entrada do usuário.
- Configure o acesso condicional com base 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ê usar PHS ou PTA, e as localizações nomeadas não tiverem sido definidas | Defina as localizações nomeadas para melhorar a detecção de eventos de risco |
| 2 | Se você for federado e não usar a declaração "insideCorporateNetwork", e as localizações nomeadas não tiverem sido definidas | Defina as localizações nomeadas para melhorar a detecção de eventos de risco |
| 3 | Se você não usar locais nomeados nas políticas de Acesso Condicional e não houver controles de risco ou de dispositivo nas políticas de Acesso Condicional | Configure a política de Acesso Condicional para incluir locais nomeados |
| 4 | Se você for federado e usar a declaração "insideCorporateNetwork", e as localizações nomeadas não tiverem sido definidas | Defina as localizações nomeadas para melhorar a detecçã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 marcando-os como confiáveis | Definir as localizações nomeadas e marque-as como confiáveis para melhorar a detecção de eventos de risco |
Políticas de acesso baseadas em risco
O Microsoft Entra ID pode calcular o risco de todas as entradas e usuários. O uso de risco como um critério nas políticas de acesso pode proporcionar uma melhor experiência do usuário, por exemplo, menos solicitações de autenticação e maior segurança, isto é, enviar solicitações aos usuários somente quando necessário e automatizar a resposta e a correção.
Se você já tiver licenças do Microsoft Entra ID P2 que dão suporte ao uso de risco em políticas de acesso, mas não estão sendo usadas, é altamente recomendável adicionar risco à sua postura de segurança.
Políticas de acesso baseada em risco – leitura recomendada
Políticas de acesso do aplicativo cliente
O Gerenciamento de Aplicativos do Microsoft Intune (MAM) 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 em nuvem, como o Exchange Online, a partir de aplicativos aprovados ou compatíveis.
Se os seus funcionários instalam aplicativos compatíveis com o 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 dá suporte ao BYOD (traga seu próprio dispositivo), recomendamos implantar políticas de MAM de aplicativo para gerenciar a configuração do aplicativo em dispositivos de propriedade pessoal sem registro de MDM e atualizar suas políticas de acesso condicional para permitir apenas o acesso de clientes compatíveis com MAM.
Caso os funcionários instalem aplicativos compatíveis com o MAM em recursos corporativos e o acesso seja restrito em dispositivos gerenciados pelo Intune, você deve 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 o acesso somente de clientes compatíveis com o MAM.
Implementação de acesso condicional
O acesso condicional é uma ferramenta essencial para melhorar a postura de segurança de sua organização. Portanto, é importante seguir estas melhores práticas:
- Verifique se todos os aplicativos SaaS têm pelo menos uma política aplicada
- Evite combinar o filtro Todos os aplicativos com o controle Bloquear para evitar o risco de bloqueio
- Evite usar Todos os usuários como um filtro e adicionar Convidados inadvertidamente
- Migre todas as políticas "herdadas" para o portal do Azure
- Capture todos os critérios para usuários, dispositivos e aplicativos
- Usar políticas de Acesso Condicional para implementar a autenticação multifator, em vez de usar uma MFA por usuário
- Tenha um pequeno conjunto de políticas base que pode ser aplicado a vários aplicativos
- Defina grupos de exceções vazios e adicione-os às políticas para ter uma estratégia de exceção
- Planejar contas de emergência sem controles de autenticação multifator
- Garanta uma experiência consistente entre 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 às políticas deve ser implementada por meio de grupos, não por indivíduos
- Faça revisões regulares dos grupos de exceção usados em políticas para limitar o tempo que os usuários ficam fora da postura de segurança. Se você tiver o Microsoft Entra ID P2, poderá usar as revisões de acesso para automatizar o processo
Acesso condicional – leitura recomendada
- Práticas recomendadas para acesso condicional em Microsoft Entra ID
- Configurações de acesso à identidade e ao dispositivo
- referência de configurações de acesso condicional Microsoft Entra
- Políticas de acesso condicional comuns
Área da superfície de acesso
Autenticação herdada
Credenciais fortes, como autenticação multifator, não podem proteger aplicativos usando protocolos de autenticação herdados, o que as torna o vetor de ataque preferencial de atores mal-intencionados. O bloqueio da autenticação herdada é crucial para melhorar a postura de segurança de acesso.
A autenticação herdada é um termo que se refere aos protocolos de autenticação usados por aplicativos como:
- Clientes mais antigos do Office que não usam uma autenticação moderna (por exemplo, um cliente do Office 2010)
- Clientes que usam protocolos de email, como Protocolo IMAP/Protocolo SMTP/ponto de presença (POP)
Os invasores preferem claramente esses protocolos, na verdade, quase todos os ataques de pulverização de senha usam protocolos de autenticação herdada. Os hackers usam protocolos de autenticação herdada, pois não dão suporte a entrada interativa, o que é necessário para desafios de segurança adicionais, como autenticação multifator e autenticação de dispositivo.
Se a autenticação herdada for amplamente usada em seu ambiente, você deverá planejar a migração de clientes herdados para clientes que dão suporte à autenticação moderna assim que possível. No mesmo token, se você tiver alguns usuários que já usam autenticação moderna, mas outros que ainda usam autenticação herdada, deverá executar as seguintes etapas para bloquear clientes de autenticação herdada:
Use relatórios de atividade de entrada para identificar os usuários que ainda estão usando a autenticação herdada e planeje a correção:
Atualize para clientes compatíveis com a autenticação moderna para usuários afetados.
Planeje um período de substituição para bloquear de acordo com as etapas abaixo.
Identifique quais aplicativos herdados têm uma dependência rígida na autenticação herdada. Confira a etapa 3 abaixo.
Desabilite os protocolos herdados na origem (por exemplo, caixa de correio do Exchange) para os usuários que não estão usando autenticação herdada a fim de evitar mais exposição.
Para as contas restantes (de preferência identidades não humanas, como contas de serviço), use o Acesso Condicional para restringir os protocolos herdados após a autenticação.
Autenticação herdada – leitura recomendada
Concessões de consentimento
Em um ataque de concessão de consentimento ilícito, o invasor cria um aplicativo registrado no Microsoft Entra que solicita acesso a dados, como informações de contato, email ou documentos. Os usuários podem dar consentimento a aplicativos mal-intencionados por meio de ataques de phishing durante a aterrissagem em sites mal-intencionados.
Veja abaixo uma lista de aplicativos com permissões que talvez você queira examinar para os serviços de nuvem da Microsoft:
- Aplicativos com aplicativo ou delegado *. Permissões de ReadWrite
- Aplicativos com permissões delegadas podem ler, enviar ou gerenciar email em nome do usuário
- Aplicativos com concessão das seguintes permissões:
| Recurso | Permissão |
|---|---|
| Exchange Online | EAS.AccessAsUser.All |
| EWS.AccessAsUser.All | |
| Mail.Read | |
| API do Microsoft Graph | Mail.Read |
| Mail.Read.Shared | |
| Mail.ReadWrite |
- Aplicativos com concessão de representação completa do usuário do usuário conectado. Por exemplo:
| Recurso | Permissão |
|---|---|
| API do Microsoft Graph | Directory.AccessAsUser.All |
| API REST do Azure | user_impersonation |
Para evitar esse cenário, você deve consultar Detectar e corrigir concessões de consentimento ilícitas no Office 365 para identificar e corrigir quaisquer aplicativos com concessões ou aplicativos ilícitos que tenham mais concessões do que o necessário. Em seguida, remova o autoatendimento completamente e estabeleça procedimentos de governança. Por fim, agende revisões regulares de permissões de aplicativo e remova-as quando elas não forem necessárias.
Concessões de consentimento – leitura recomendada
Configurações de usuário e grupo
Veja abaixo as configurações de usuário e grupo que podem ser bloqueadas se não houver uma necessidade comercial explícita:
Configurações do usuário
- 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, por exemplo, por meio de seu suporte técnico. Se você não quiser permitir a colaboração externa orgânica para serviços, poderá bloquear completamente os membros de convidar usuários externos. Como alternativa, também pode permitir ou bloquear domínios específicos em convites de usuários externos.
- Registros de aplicativo – quando os Registros de aplicativo estão habilitados, os usuários finais podem integrar aplicativos e conceder acesso aos dados deles. Um exemplo típico de Registro de aplicativo são os usuários que habilitam plug-ins do Outlook, ou assistentes de voz, como Alexa e Siri para ler o email e o calendário deles ou enviar emails nos respectivos nomes. Se o cliente decidir desativar o Registro de aplicativo, as equipes do IAM e da InfoSec deverão estar envolvidas no gerenciamento de exceções (registros de aplicativo que são necessários com base nos requisitos de negócios), pois precisariam registrar os aplicativos com uma conta de administrador e, provavelmente, exigirem a criação de um processo para colocá-lo em ação.
- Portal de administração – as organizações podem bloquear a folha do Microsoft Entra no portal do Azure de forma que os não administradores não possam acessar o gerenciamento do Microsoft Entra no portal do Azure e ficarem confusos. Vá para as configurações de usuário no portal de gerenciamento do Microsoft Entra para restringir o acesso:
Observação
Os não administradores ainda podem acessar as interfaces de gerenciamento do Microsoft Entra por meio de linha de comando e outras interfaces programáticas.
Configurações de grupo
Gerenciamento de grupos de autoatendimento/Os usuários podem criar grupos de segurança/Grupos de Microsoft 365. Se não houver uma iniciativa de self-service atual para grupos na nuvem, os clientes poderão decidir desativá-los até que estejam prontos para usar esse recurso.
Grupos – leitura recomendada
- O que é colaboração B2B no Microsoft Entra?
- Integrando aplicativos com Microsoft Entra ID
- Aplicativos, permissões e consentimento em Microsoft Entra ID.
- Usar grupos para gerenciar o acesso a recursos em Microsoft Entra ID
- Configuração do gerenciamento de acesso de aplicativos de autoatendimento no Microsoft Entra ID
Tráfego de localizações inesperadas
Os invasores se originam de várias partes do mundo. Gerencie esse risco usando as 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 bloquear o acesso para locais de onde não há nenhum motivo comercial para se conectar.
Se disponível, use uma solução SIEM (gerenciamento de eventos e informações de segurança) para analisar e localizar padrões de acesso entre regiões. Se você não usar um produto SIEM ou não estiver ingerindo informações de autenticação do Microsoft Entra ID, recomendamos que use o Azure Monitor para identificar padrões de acesso entre regiões.
Uso de acesso
Logs do Microsoft Entra arquivados e integrados com planos de resposta a incidentes
Ter acesso a atividades de entrada, auditorias e eventos de risco do Microsoft Entra ID é crucial para 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 com um período de retenção limitado. Um sistema SIEM (gerenciamento de eventos e informações de segurança) ou uma tecnologia de arquivamento equivalente é fundamental para o armazenamento de longo prazo de auditorias e suporte. Para habilitar o armazenamento de longo prazo de logs do Microsoft Entra, você deve adicioná-lo à 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 – leitura recomendada
- Referência da API de auditoria do Microsoft Entra ID
- Referência da API de relatório de atividade de entrada do Microsoft Entra
- Obter dados usando a API de relatório do Microsoft Entra com certificados
- Microsoft Graph para Microsoft Entra ID Protection
- Referência de API de atividade de gerenciamento do Office 365
- Como usar o Pacote de Conteúdo do Power BI da ID Microsoft Entra
Resumo
Há 12 aspectos para uma infraestrutura de identidade segura. Esta lista ajudará você a proteger e gerenciar credenciais, definir a experiência de autenticação, delegar a atribuição, mensurar o uso e definir políticas de acesso com base na postura de segurança corporativa.
- Atribuir proprietários a tarefas principais.
- Implementar soluções para detectar senhas fracas ou vazadas, melhorar o gerenciamento e a proteção de senha e proteger ainda mais o acesso dos usuários aos recursos.
- Gerenciar a identidade de dispositivos para proteger seus recursos a qualquer momento e de qualquer local.
- Implementar a autenticação sem senha.
- Fornecer um mecanismo de logon único padronizado em toda a organização.
- Migrar aplicativos dos AD FS para o Microsoft Entra ID para permitir maior segurança e capacidade de gerenciamento mais consistente.
- Atribuir usuários a aplicativos usando grupos para permitir maior flexibilidade e capacidade de gerenciar em escala.
- Configurar políticas de acesso baseadas em risco.
- Bloquear protocolos de autenticação herdada.
- Detectar e corrigir concessões de consentimento ilícitas.
- Bloquear configurações de usuário e de grupo.
- Habilitar o armazenamento de longo prazo de logs do Microsoft Entra para solução de problemas, análise de uso e investigações forenses.
Próximas etapas
Introdução às verificações e ações operacionais de governança de identidade.