Guia de referência de operações de gerenciamento de autenticação do Azure Active Directory

Esta seção do Guia de referência de operações do Azure AD descreve as verificações e as ações que você deve executar para proteger e gerenciar credenciais, definir a experiência de autenticação, delegar a atribuição, o uso de medidas e definir políticas de acesso com base na postura de segurança corporativa.

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 proprietários a tarefas principais

O gerenciamento do Azure Active Directory 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 Azure AD Equipe de operações do IAM
Criar políticas de acesso condicional para aplicativos do Azure AD Equipe de arquitetura da InfoSec
Arquivar atividade de entrada em um sistema 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 Azure AD Identity Protection Equipe de operações da InfoSec

Observação

O Azure AD Identity Protection requer uma licença do Azure AD Premium P2. Confira Como comparar recursos em disponibilidade geral das edições do Azure AD Gratuito e do Azure AD Premium a fim de localizar a licença mais adequada para seus requisitos.

Ao examinar sua lista, você pode achar necessário atribuir um proprietário para tarefas que não têm um proprietário ou ajustar a propriedade para tarefas com proprietários que não estão de acordo com as recomendações acima.

Gerenciamento de credenciais

Políticas de senha

O gerenciamento de senhas com segurança é uma das partes mais importantes do gerenciamento de identidade e acesso e, muitas vezes, o maior alvo de ataques. O Azure AD dá suporte a vários recursos que podem ajudar a impedir que um ataque seja bem-sucedido.

Use a seguinte tabela para encontrar a solução recomendada para mitigar 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) do Azure AD e da proteção de senha
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 Azure AD
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 Azure AD.
Os usuários não estão registrados para usar a MFA (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 Azure AD 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 proibidos 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)

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 Azure AD 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 Azure AD Premium 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). O ideal é que você habilite o registro combinado e exija que todos os usuários se registrem para a MFA e a 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.

Combined user experience flow

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 PHS (sincronização de hash de senha) do Azure AD e a MFA do Azure AD permitem que os usuários acessem a aplicativos SaaS e o Microsoft 365 apesar de interrupções locais devido a ataques cibernéticos como 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 Azure AD, você deverá implantar a PHS do Azure AD e definir um plano de recuperação de desastre que inclua a PHS. Habilitar a PHS do Azure AD permitirá que os usuários se autentiquem no Azure AD se o seu Active Directory local estiver indisponível.

password hash sync flow

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 Azure Active Directory.

Uso programático de credenciais

Os scripts do Azure AD 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 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 imediatamente o SSO contínuo. 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:

É possível alcançar essa meta colocando e gerenciando identidades de dispositivo no Azure AD 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 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 Endpoint Configuration Manager) e dispositivos móveis Android.
  • O ingresso no Azure AD híbrido fornece gerenciamento com políticas de grupo ou o Microsoft Endpoint Configuration Manager em um ambiente com dispositivos de computadores conectados ao domínio. As organizações podem implantar um ambiente gerenciado por meio de PHS ou PTA com SSO contínuo. Trazer seus dispositivos para o Azure AD 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 Azure AD híbrido como um controle em suas políticas de acesso condicional.

A screenshot of grant in conditional access policy requiring hybrid device

Se você estiver gerenciando dispositivos com o MDM ou o Microsoft Intune, mas não usando controles de dispositivo em suas políticas de acesso condicional, é recomendável usar o Exigir que o dispositivo seja marcado em conformidade como um controle nessas políticas.

A screenshot of grant in conditional access policy requiring device compliance

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 MFA mais simplificada para os 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 Azure Active Directory.

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 Azure AD, mas estiverem atualmente configurados para usar contas locais, você deverá reconfigurar esses aplicativos para usar o SSO com o Azure AD. Da mesma forma, se você estiver usando qualquer aplicativo que dá suporte a SSO com o Azure AD, mas estiver usando outro provedor de identidade, deverá reconfigurar esses aplicativos para usar o SSO com o Azure AD 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 Azure AD.

AppProxy Password-based Sign-on

Observação

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

Por fim, se você tiver uma galeria de aplicativos do Azure AD e usar aplicativos que dão suporte a SSO com o Azure AD, é recomendável listar o aplicativo na galeria de aplicativos.

Migração de aplicativos dos AD FS para o Azure AD

A migração de aplicativos dos AD FS para o Azure AD 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 Azure AD, deverá reconfigurar esses aplicativos para usar o SSO com o Azure AD. Se você tiver aplicativos configurados nos AD FS com configurações incomuns sem suporte no Azure AD, contate 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 Azure AD.

Azure AD as the primary identity provider

Observação

O Azure AD Connect Health para ADFS pode ser usado para coletar detalhes de configuração sobre cada aplicativo que pode ser migrado para o Azure AD.

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 Azure AD.

Por outro lado, se você encontrar aplicativos com atribuição a usuários individuais, implemente a governança em torno desses aplicativos.

Políticas de acesso

Localizações nomeadas

Com as localizações nomeadas no Azure AD, você pode rotular os intervalos de endereços IP confiáveis em sua organização. O Azure AD usa localizações nomeadas para:

Named location

Com base na prioridade, use a tabela abaixo 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 localizações nomeadas em 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 localizações nomeadas
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 a MFA em vez de localizações nomeadas e marcá-los 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 Azure AD 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 é, os usuários receberão solicitações somente quando for necessário. Esse critério também pode automatizar a resposta e a correção.

Sign-in risk policy

Se você já tiver licenças do Azure AD Premium 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 do aplicativo cliente

O MAM (gerenciamento de aplicativo do Microsoft Intune) fornece a capacidade de efetuar push dos controles de proteção de dados, como criptografia de armazenamento, PIN, limpeza de armazenamento remoto etc., para aplicativos móveis de 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, de aplicativos aprovados ou compatíveis.

Se seus funcionários instalarem aplicativos compatíveis com o MAM, como aplicativos móveis do Office, para acessar recursos corporativos, como o Exchange Online ou o SharePoint Online, e você também der suporte a BYOD (Traga seu próprio dispositivo), recomendamos implantar políticas de MAM de aplicativo para gerenciar a configuração de aplicativos em dispositivos de propriedade pessoal sem registro de MDM e, em seguida, atualizar suas políticas de acesso condicional para permitir o acesso somente de clientes compatíveis com o MAM.

Conditional Access Grant control

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
  • Use políticas de acesso condicional para implementar a MFA, 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
  • Planeje contas break-glass sem controles de MFA
  • Garanta uma experiência consistente em Microsoft 365 aplicativos cliente, por exemplo, Teams, OneDrive, Outlook, etc.) Implementando o mesmo conjunto de controles para serviços como Exchange Online e SharePoint Online
  • 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 Azure AD P2, poderá usar as revisões de acesso para automatizar o processo

Área da superfície de acesso

Autenticação herdada

Credenciais fortes, como a MFA, não podem proteger aplicativos usando protocolos de autenticação herdados, que os tornam o vetor de ataque preferencial por atores proibidos. 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 IMAP/SMTP/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:

  1. 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:

    a. Atualize para clientes compatíveis com a autenticação moderna para usuários afetados.

    b. Planeje um período de substituição para bloquear de acordo com as etapas abaixo.

    c. Identifique quais aplicativos herdados têm uma dependência rígida na autenticação herdada. Confira a etapa 3 abaixo.

  2. 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.

  3. Para as contas restantes (de preferência identidades não humanas, como contas de serviço), use o acesso condicional para restringir a pós-autenticação de protocolos herdados.

Em um ataque de concessão de consentimento ilícito, o invasor cria um aplicativo registrado no Azure AD 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 você pode querer analisar 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 conferir o artigo Detectar e corrigir concessões de consentimento ilícitas no Office 365 para identificar e corrigir aplicativos com concessões ilícitas ou aplicativos com 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.

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 ocorrer de forma orgânica na empresa com serviços como o Teams, o Power BI, o SharePoint Online e a 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 Azure AD 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 Azure AD no portal do Azure de forma que os não administradores não possam acessar o gerenciamento do Azure AD no portal do Azure e ficarem confusos. Vá para as configurações de usuário no portal de gerenciamento do Azure AD para restringir o acesso:

Administration portal restricted access

Observação

Os não administradores ainda podem acessar as interfaces de gerenciamento do Azure AD 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 autoatendimento atual para grupos na nuvem, os clientes poderão decidir desativá-los até que estejam prontos para usar esse recurso.

Tráfego de localizações inesperadas

Os invasores se originam de várias partes do mundo. Gerencie esse risco usando políticas de acesso condicional com localização como a 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.

Create a new named location

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 Azure AD, recomendamos que use o Azure Monitor para identificar padrões de acesso entre regiões.

Uso de acesso

Logs do Azure AD arquivados e integrados com planos de resposta a incidentes

Ter acesso a atividades de entrada, auditorias e eventos de risco do Azure AD é crucial para solução de problemas, análise de uso e investigações forenses. O Azure AD 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 Azure AD, 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.

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 Azure AD 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 Azure AD 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.