Guia de referência de operações de gestão de autenticação Azure Ative Directory

Esta secção do guia de referência de operações Azure AD descreve os controlos e ações que deve tomar para proteger e gerir credenciais, definir experiência de autenticação, delegar, medir o uso e definir políticas de acesso com base na postura de segurança da empresa.

Nota

Estas recomendações estão em vigor a partir da data da publicação, mas podem mudar ao longo do tempo. As organizações devem avaliar continuamente as 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-chave

Gerir Azure Ative Directory requer a execução contínua de tarefas e processos operacionais fundamentais, que podem não fazer parte de um projeto de implantação. Ainda é importante que crie estas tarefas para otimizar o seu ambiente. As tarefas-chave e os seus proprietários recomendados incluem:

Tarefa Proprietário
Gerir o ciclo de vida da configuração de um único sign-on (SSO) em Azure AD Equipa de Operações do IAM
Conceber políticas de acesso condicional para aplicações AD Azure Equipa de Arquitetura InfoSec
Atividade de inscrição de arquivo num sistema SIEM Equipa de Operações InfoSec
Archive eventos de risco num sistema SIEM Equipa de Operações InfoSec
Triagem e investigar relatórios de segurança Equipa de Operações InfoSec
Triagem e investigar eventos de risco Equipa de Operações InfoSec
Triagem e investigam utilizadores sinalizados por relatórios de risco e vulnerabilidade da Azure AD Identity Protection Equipa de Operações InfoSec

Nota

A Azure AD Identity Protection requer uma licença de Azure AD Premium P2. Para encontrar a licença certa para os seus requisitos, consulte Comparar funcionalidades geralmente disponíveis das edições Azure AD Gratuito e Azure AD Premium.

Ao rever a sua lista, poderá descobrir que precisa de atribuir um proprietário para tarefas que faltam a um proprietário ou ajustar a propriedade para tarefas com proprietários que não estejam alinhados com as recomendações acima.

Gestão de credenciais

Políticas de palavra-passe

Gerir as palavras-passe de forma segura é uma das partes mais críticas da gestão de identidade e acesso e muitas vezes o maior alvo de ataques. A Azure AD suporta várias funcionalidades que podem ajudar a evitar que um ataque seja bem sucedido.

Utilize o quadro abaixo para encontrar a solução recomendada para atenuar a questão que precisa de ser abordada:

Problema Recomendação
Nenhum mecanismo para proteger contra senhas fracas Ativar o reset da palavra-passe de autosserviço AZure (SSPR) e a proteção da palavra-passe
Nenhum mecanismo para detetar senhas vazadas Permite a sincronização do hash de palavras-passe (PHS) para obter informações
Utilização de FS AD e incapaz de mover-se para a autenticação gerida Ativar o bloqueio inteligente da extranet AD FS e/ou Azure AD Smart Lockout
A política de palavra-passe utiliza regras baseadas na complexidade, tais como comprimento, múltiplos conjuntos de caracteres ou expiração Reconsidere a favor das práticas recomendadas pela Microsoft e altere a sua abordagem para a gestão de passwords e implemente a proteção de senha AZure AD.
Os utilizadores não estão registados para utilizar a autenticação de vários fatores (MFA) Registar todas as informações de segurança do utilizador para que possa ser usado como um mecanismo para verificar a identidade do utilizador juntamente com a sua palavra-passe
Não há revogação de senhas baseadas no risco do utilizador Implementar políticas de risco de proteção de identidade Azure AD para forçar alterações de senha em credenciais vazadas usando SSPR
Não existe nenhum mecanismo de bloqueio inteligente para proteger a autenticação maliciosa de maus atores 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)

Ativar o reset da palavra-passe de autosserviço e a proteção da palavra-passe

Os utilizadores que precisam de alterar ou redefinir as suas palavras-passe é uma das maiores fontes de volume e custo das chamadas de secretária de ajuda. Além do custo, alterar a palavra-passe como uma ferramenta para mitigar o risco do utilizador é um passo fundamental para melhorar a postura de segurança da sua organização.

No mínimo, recomenda-se que implemente o reset da palavra-passe de autosserviço AZure AD (SSPR) e a proteção da palavra-passe no local para realizar:

  • Desvie as chamadas de secretária de ajuda.
  • Substitua a utilização de senhas temporárias.
  • Substitua qualquer solução de gestão de senha de autosserviço existente que dependa de uma solução no local.
  • Elimine senhas fracas na sua organização.

Nota

Para organizações com uma subscrição Azure AD Premium P2, é aconselhável implementar a SSPR e usá-la como parte de uma Política de Risco de Utilização de Proteção de Identidade.

Forte gestão credencial

As palavras-passe por si só não são suficientemente seguras para impedir que os maus atores tenham acesso ao seu ambiente. No mínimo, qualquer utilizador com uma conta privilegiada deve ser ativado para a autenticação de vários fatores (MFA). Idealmente, deve permitir o registo combinado e exigir que todos os utilizadores se registem para MFA e SSPR usando a experiência de registo combinado. Eventualmente, recomendamos que adote uma estratégia para fornecer resiliência para reduzir o risco de bloqueio devido a circunstâncias imprevistas.

Combined user experience flow

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

Além dos benefícios da simplicidade e da deteção de credenciais vazadas, a Azure AD Password Hash Sync (PHS) e a Azure AD MFA permitem aos utilizadores aceder a aplicações e Microsoft 365 saaS, apesar de falhas no local devido a ciberataques como o NotPetya. Também é possível permitir phs enquanto em conjunto com a federação. Permitir o PHS permite uma redução da autenticação quando os serviços da federação não estão disponíveis.

Se a sua organização no local não tiver uma estratégia de resiliência de paralisação ou tiver uma que não esteja integrada com a Azure AD, deve implementar o Azure AD PHS e definir um plano de recuperação de desastres que inclua PHS. Permitir que o Azure AD PHS permita aos utilizadores autenticar-se contra a AD Azure caso o seu Ative Directory no local não esteja disponível.

password hash sync flow

Para melhor compreender as suas opções de autenticação, consulte Escolha o método de autenticação certo para a sua solução de identidade híbrida Azure Ative Directory.

Utilização programática de credenciais

Os scripts AD do AZure que utilizam o PowerShell ou aplicações que utilizam o Microsoft Graph API requerem autenticação segura. A má gestão da credencial que executa esses scripts e ferramentas aumenta o risco de roubo de credenciais. Se estiver a utilizar scripts ou aplicações que se baseiem em palavras-passe ou pedidos de palavra-passe codificados por código rígido, deve primeiro rever as palavras-passe em ficheiros config ou código fonte, em seguida, substituir essas dependências e utilizar identidades geridas, Integrated-Windows autenticação ou certificados sempre que possível. Para aplicações em que as soluções anteriores não são possíveis, considere usar o Azure Key Vault.

Se determinar que existem principais serviços com credenciais de senha e não tem a certeza de como essas credenciais de senha são protegidas por scripts ou aplicações, contacte o proprietário da aplicação para entender melhor os padrões de utilização.

A Microsoft também recomenda que contacte os proprietários de aplicações para entender os padrões de utilização se existirem princípios de serviço com credenciais de senha.

Experiência de autenticação

Autenticação no local

A autenticação federada com autenticação integrada Windows (IWA) ou Sign-On única sem emenda (SSO) é a melhor experiência do utilizador quando dentro da rede corporativa com controladores de domínio de linha de visão para as instalações. Minimiza a fadiga da origem da credencial e reduz o risco de os utilizadores serem vítimas de ataques de phishing. Se já estiver a utilizar a autenticação gerida pela nuvem com PHS ou PTA, mas os utilizadores ainda precisam de escrever a sua palavra-passe ao autenticar no local, então deve implementar imediatamente o SSO sem emenda. Por outro lado, se atualmente está federado com planos para eventualmente migrar para a autenticação gerida pela nuvem, então deve implementar o SSO sem emenda como parte do projeto de migração.

Políticas de acesso de confiança do dispositivo

Como um utilizador na sua organização, um dispositivo é uma identidade central que quer proteger. Pode utilizar a identidade de um dispositivo para proteger os seus recursos a qualquer momento e a partir de qualquer local. A autenticação do dispositivo e a contabilização do seu tipo de confiança melhora a sua postura de segurança e usabilidade através de:

Pode realizar este objetivo trazendo identidades do dispositivo e gerindo-as em Azure AD utilizando um dos seguintes métodos:

  • As organizações podem usar Microsoft Intune para gerir o dispositivo e impor políticas de conformidade, atestam a saúde do dispositivo e definir políticas de acesso condicional com base no cumprimento do dispositivo. Microsoft Intune pode gerir dispositivos iOS, desktops Mac (integração via JAMF), Windows desktops (nativamente usando Gestão de Dispositivos Móvel para Windows 10, e cogestão com Microsoft Endpoint Configuration Manager) e dispositivos móveis Android.
  • A ad a azure híbrida fornece gestão com políticas de grupo ou Microsoft Endpoint Configuration Manager num ambiente com dispositivos de computadores ligados ao domínio do Ative Directory. As organizações podem implementar um ambiente gerido através de PHS ou PTA com SSO sem emenda. Trazer os seus dispositivos para a Azure AD maximiza a produtividade do utilizador através do SSO através da sua nuvem e recursos no local, permitindo-lhe garantir o acesso à sua nuvem e recursos no local com Acesso Condicional ao mesmo tempo.

Se tiver dispositivos Windows unidos por domínios que não estejam registados na nuvem, ou dispositivos Windows unidos ao domínio que estejam registados na nuvem mas sem políticas de acesso condicional, então deve registar os dispositivos não registados e, em qualquer dos casos, utilizar a AD Híbrida Azure como um controlo nas suas políticas de acesso condicional.

A screenshot of grant in conditional access policy requiring hybrid device

Se estiver a gerir dispositivos com MDM ou Microsoft Intune, mas não utilizar controlos do dispositivo nas suas políticas de acesso condicional, recomendamos que utilize o dispositivo Require para ser marcado como um controlo nessas políticas.

A screenshot of grant in conditional access policy requiring device compliance

Windows Hello para empresas

Em Windows 10, Windows Hello para Empresas substitui as palavras-passe por uma autenticação forte de dois fatores nos Computadores. Windows Hello para Empresas permite uma experiência de MFA mais simplificada para os utilizadores e reduz a sua dependência de senhas. Se ainda não começou a lançar Windows 10 dispositivos, ou apenas os implementou parcialmente, recomendamos que atualize para Windows 10 e permita Windows Hello para Empresas em todos os dispositivos.

Se quiser saber mais sobre a autenticação sem palavras-passe, consulte Um mundo sem palavras-passe com Azure Ative Directory.

Autenticação e atribuição de candidaturas

Único s-on para apps

Fornecer um mecanismo de inscrição única padronizado a toda a empresa é crucial para a melhor experiência do utilizador, redução de risco, capacidade de reportar e governação. Se estiver a utilizar aplicações que suportam SSO com Azure AD mas que estão atualmente configuradas para utilizar contas locais, deve reconfigurar essas aplicações para utilizar SSO com Azure AD. Da mesma forma, se estiver a utilizar quaisquer aplicações que suportem SSO com Azure AD mas que estejam a utilizar outro Fornecedor de Identidade, deverá reconfigurar essas aplicações para utilizar o SSO com Azure AD também. Para aplicações que não suportam protocolos da federação mas que suportem a autenticação baseada em formulários, recomendamos que configures a aplicação para usar o cofre de palavras-passe com Proxy de Aplicações Azure.

AppProxy Password-based Sign-on

Nota

Se não tiver um mecanismo para descobrir aplicações não geridos na sua organização, recomendamos implementar um processo de descoberta usando uma solução de corretor de segurança de acesso à nuvem (CASB), como Microsoft Defender for Cloud Apps.

Por fim, se tiver uma galeria de aplicações AD AZure e utilizar aplicações que suportem SSO com Azure AD, recomendamos a listagem da aplicação na galeria de aplicações.

Migração de aplicações da AD FS para Azure AD

A migração de aplicações de AD FS para Azure AD permite capacidades adicionais em segurança, gestão mais consistente e uma melhor experiência de colaboração. Se tiver aplicações configuradas em FS AD que suportam SSO com AZure AD, então deve reconfigurar essas aplicações para usar SSO com Azure AD. Se tiver aplicações configuradas em FS AD com configurações incomuns não suportadas pelo Azure AD, deve contactar os proprietários da aplicação para perceber se a configuração especial é um requisito absoluto da aplicação. Se não for necessário, então deve reconfigurar a aplicação para usar SSO com Azure AD.

Azure AD as the primary identity provider

Nota

A Azure AD Ligação Health for ADFS pode ser usada para recolher detalhes de configuração sobre cada aplicação que pode potencialmente ser migrada para Azure AD.

Atribuir utilizadores a aplicações

Atribuir os utilizadores às aplicações é melhor mapeado através da utilização de grupos, porque permitem uma maior flexibilidade e capacidade de gestão em escala. Os benefícios da utilização de grupos incluem a adesão dinâmica baseada no atributo e delegação aos proprietários de aplicações. Portanto, se já está a utilizar e a gerir grupos, recomendamos que tome as seguintes ações para melhorar a gestão em escala:

  • Delegar gestão e governação de grupos aos proprietários de candidaturas.
  • Permitir o acesso self-service à aplicação.
  • Defina grupos dinâmicos se os atributos do utilizador puderem determinar consistentemente o acesso às aplicações.
  • Implementar atestado para grupos utilizados para acesso a aplicações usando revisões de acesso AZure AD.

Por outro lado, se encontrar aplicações que tenham atribuição a utilizadores individuais, não se esqueça de implementar a governação em torno dessas aplicações.

Políticas de acesso

Localizações com nome

Com localizações nomeadas em Azure AD, pode rotular gamas de endereços IP fidedignos na sua organização. O Microsoft Azure AD utiliza localizações com nome para:

Named location

Com base na prioridade, utilize a tabela abaixo para encontrar a solução recomendada que melhor satisfaça as necessidades da sua organização:

Priority Cenário Recomendação
1 Se você usar PHS ou PTA e locais nomeados não foram definidos Definir localizações nomeadas para melhorar a deteção de eventos de risco
2 Se você é federado e não usar a reivindicação "insideCorporateNetwork" e locais nomeados não foram definidos Definir localizações nomeadas para melhorar a deteção de eventos de risco
3 Se não utilizar localizações nomeadas em políticas de acesso condicional e não houver riscos ou controlos de dispositivos em políticas de acesso condicional Configure a política de acesso condicional para incluir localizações nomeadas
4 Se você é federado e você usa a reivindicação "insideCorporateNetwork" e locais nomeados não foram definidos Definir localizações nomeadas para melhorar a deteção de eventos de risco
5 Se estiver a usar endereços IP fidedignos com MFA em vez de localizações nomeadas e marcando-os como confiáveis Defina localizações nomeadas e marque-as como confiáveis para melhorar a deteção de eventos de risco

Políticas de acesso baseadas no risco

O Azure AD pode calcular o risco para cada sedura e cada utilizador. A utilização do risco como critério nas políticas de acesso pode proporcionar uma melhor experiência do utilizador, por exemplo, menos pedidos de autenticação e uma melhor segurança, por exemplo, apenas levar os utilizadores quando são necessários, e automatizar a resposta e a remediação.

Sign-in risk policy

Se já possui licenças Azure AD Premium P2 que suportam o uso de riscos nas políticas de acesso, mas não estão a ser usadas, recomendamos vivamente a adição de riscos à sua postura de segurança.

Políticas de acesso a aplicações do cliente

Microsoft Intune Application Management (MAM) fornece a capacidade de pressionar controlos de proteção de dados, tais como encriptação de armazenamento, PIN, limpeza remota de armazenamento, etc. para aplicações móveis compatíveis do cliente, tais como Outlook Mobile. Além disso, podem ser criadas políticas de acesso condicional para restringir o acesso a serviços na nuvem, como Exchange Online de aplicações aprovadas ou compatíveis.

Se os seus colaboradores instalarem aplicações capazes de MAM, como Office aplicações móveis para aceder a recursos corporativos como Exchange Online ou SharePoint Online, e também apoiar o BYOD (traga o seu próprio dispositivo), recomendamos que implemente políticas de aplicação MAM para gerir a configuração da aplicação em dispositivos de propriedade pessoal sem a inscrição de MDM e, em seguida, atualizar as suas políticas de acesso condicional para apenas permitir o acesso a partir de Clientes capazes de MAM.

Conditional Access Grant control

Se os colaboradores instalarem aplicações capazes de MAM contra recursos corporativos e o acesso for restrito em dispositivos geridos Intune, então deve considerar a implementação de políticas de MAM para gerir a configuração da aplicação para dispositivos pessoais e atualizar políticas de Acesso Condicional apenas para permitir o acesso de clientes capazes de MAM.

Implementação do Acesso Condicional

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

  • Certifique-se de que todas as aplicações saaS têm pelo menos uma política aplicada
  • Evite combinar o filtro All apps com o controlo do bloco para evitar o risco de bloqueio
  • Evite utilizar os Todos os utilizadores como filtro e adicionar inadvertidamente os Hóspedes
  • Migrar todas as políticas "legados" para o portal do Azure
  • Apanhe todos os critérios para utilizadores, dispositivos e aplicações
  • Utilize políticas de acesso condicional para implementar MFA, em vez de utilizar um MFA por utilizador
  • Ter um pequeno conjunto de políticas centrais que podem aplicar-se a múltiplas aplicações
  • Defina grupos de exceção vazios e adicione-os às políticas para ter uma estratégia de exceção
  • Plano para quebrar contas de vidro sem controlos de MFA
  • Garantir uma experiência consistente em Microsoft 365 aplicações de clientes, por exemplo, Teams, OneDrive, Outlook, etc.) implementando o mesmo conjunto de controlos para serviços como Exchange Online e SharePoint Online
  • A atribuição às políticas deve ser implementada através de grupos, não de indivíduos
  • Faça revisões regulares dos grupos de exceção utilizados nas políticas para limitar o tempo que os utilizadores estão fora da postura de segurança. Se é dono do Azure AD P2, então pode usar comentários de acesso para automatizar o processo

Área de superfície de acesso

Autenticação do legado

Credenciais fortes como mFA não podem proteger aplicações usando protocolos de autenticação legado, que fazem dele o vetor de ataque preferido por atores mal-intencionados. Bloquear a autenticação do legado é crucial para melhorar a postura de segurança de acesso.

A autenticação do legado é um termo que se refere a protocolos de autenticação utilizados por apps como:

  • Clientes Office mais velhos que não utilizam a autenticação moderna (por exemplo, Office cliente de 2010)
  • Clientes que utilizam protocolos de correio como IMAP/SMTP/POP

Os atacantes preferem fortemente estes protocolos - na verdade, quase 100% dos ataques de spray de senha usam protocolos de autenticação legado! Os hackers usam protocolos de autenticação antigas, porque não suportam a inscrição interativa, o que é necessário para desafios adicionais de segurança como a autenticação de vários fatores e a autenticação do dispositivo.

Se a autenticação de legados for amplamente utilizada no seu ambiente, deverá planear migrar clientes legados para clientes que suportem a autenticação moderna o mais rapidamente possível. No mesmo tom, se já tem alguns utilizadores que já utilizam a autenticação moderna mas outros que ainda utilizam a autenticação antiga, deve tomar as seguintes medidas para bloquear clientes de autenticação antiga:

  1. Utilize relatórios de Atividade de Inscrição para identificar utilizadores que ainda utilizam a autenticação do legado e planeiam a remediação:

    a. Upgrade para clientes capazes de autenticação moderna para utilizadores afetados.

    b. Planeie um prazo de corte para bloquear por degraus abaixo.

    c. Identifique quais aplicações antigas têm uma dependência difícil da autenticação do legado. Veja o passo 3 abaixo.

  2. Desative os protocolos legados na fonte (por exemplo, Exchange Mailbox) para utilizadores que não estão a usar auth legado para evitar mais exposição.

  3. Para as restantes contas (idealmente identidades não-humanas, como contas de serviço), utilize o acesso condicional para restringir os protocolos legados pós-autenticação.

Num ataque de concessão de consentimento ilícito, o intruso cria uma aplicação registada em Azure AD que solicita o acesso a dados como informações de contacto, e-mail ou documentos. Os utilizadores podem estar a conceder consentimento a aplicações maliciosas através de ataques de phishing ao aterrar em sites maliciosos.

Abaixo está uma lista de aplicações com permissões que você pode querer examinar para os serviços na nuvem da Microsoft:

  • Aplicativos com app ou delegado *. Permissões ReadWrite
  • Aplicações com permissões delegadas podem ler, enviar ou gerir e-mail em nome do utilizador
  • Aplicativos a quem é concedida a utilização das seguintes permissões:
Recurso Permissão
Exchange Online EAS. AccessAsUser.All
EWS. AccessAsUser.All
Correio.Ler
Microsoft Graph API Correio.Ler
Mail.Read.Shared
E-mail.ReadWrite
  • As aplicações concederam a personificação completa do utilizador do utilizador inscrito. Por exemplo:
Recurso Permissão
Microsoft Graph API Diretório.AccessAsUser.All
API REST do Azure user_impersonation

Para evitar este cenário, deverá consultar e remediar as concessões de consentimento ilícitas em Office 365 identificar e corrigir quaisquer pedidos com subvenções ilícitas ou aplicações que tenham mais subvenções do que as necessárias. Em seguida, remover completamente o autosserviço e estabelecer procedimentos de governação. Por fim, agende as análises regulares das permissões das aplicações e remova-as quando não forem necessárias.

Configurações de utilizador e grupo

Abaixo estão as definições do utilizador e do grupo que podem ser bloqueadas se não houver uma necessidade explícita do negócio:

Definições do utilizador

  • Utilizadores Externos - a colaboração externa pode acontecer organicamente na empresa com serviços como Teams, Power BI, SharePoint Online e Azure Information Protection. Se tiver restrições explícitas para controlar a colaboração externa iniciada pelo utilizador, recomenda-se que permita utilizadores externos utilizando a gestão do Direito AD Azure ou uma operação controlada, como através do seu balcão de ajuda. Se não quiser permitir a colaboração externa orgânica para serviços, pode impedir os membros de convidarem completamente os utilizadores externos. Em alternativa, também pode permitir ou bloquear domínios específicos em convites externos do utilizador.
  • Registos de aplicações - quando Registos de aplicações estiverem ativados, os utilizadores finais podem embarcar aplicações e conceder acesso aos seus dados. Um exemplo típico do registo de App são os utilizadores que permitem que Outlook plug-ins, ou assistentes de voz como Alexa e Siri, leiam o seu e-mail e calendário ou enviem e-mails em seu nome. Se o cliente decidir desligar o registo da App, as equipas InfoSec e IAM devem estar envolvidas na gestão de exceções (registos de aplicações que são necessários com base nos requisitos do negócio), uma vez que teriam de registar as aplicações com uma conta administradora, e muito provavelmente requerem a conceção de um processo para operacionalizar o processo.
  • Portal da Administração - as organizações podem bloquear a lâmina AZure AD no portal do Azure para que os não administradores não possam aceder à gestão AD do Azure no portal do Azure e ficar confusos. Aceda às definições do utilizador no portal de gestão Azure AD para restringir o acesso:

Administration portal restricted access

Nota

Os não administradores ainda podem aceder às interfaces de gestão AZure AD através da linha de comando e de outras interfaces programáticas.

Definições de grupo

Self-Service Gestão do Grupo / Os Utilizadores podem criar grupos de Segurança /Microsoft 365 grupos. Se não houver uma iniciativa de autosserviço atual para grupos na nuvem, os clientes podem decidir desligá-la até estarem prontos para usar esta capacidade.

Tráfego de locais inesperados

Os agressores são originários de várias partes do mundo. Gerencie este risco utilizando 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 de onde não há razão comercial para iniciar sedu.

Create a new named location

Se disponível, utilize uma solução de informação de segurança e gestão de eventos (SIEM) para analisar e encontrar padrões de acesso entre regiões. Se não utilizar um produto SIEM, ou não estiver a ingerir informações de autenticação a partir da Azure AD, recomendamos que utilize o Azure Monitor para identificar padrões de acesso em todas as regiões.

Utilização de acesso

Registos AD AZure arquivados e integrados com planos de resposta a incidentes

Ter acesso a atividade de inscrição, auditorias e eventos de risco para a Azure AD é crucial para a resolução de problemas, análises de uso e investigações forenses. A Azure AD fornece acesso a estas fontes através de APIs REST que têm um período de retenção limitado. Um sistema de informação de segurança e gestão de eventos (SIEM), ou tecnologia de arquivo equivalente, é fundamental para o armazenamento a longo prazo de auditorias e suporte. Para permitir o armazenamento a longo prazo dos registos AD Azure, deve adicioná-los à sua solução SIEM existente ou utilizar o Azure Monitor. Registos de arquivo que podem ser usados como parte dos seus planos de resposta a incidentes e investigações.

Resumo

Há 12 aspetos para uma infraestrutura de identidade segura. Esta lista irá ajudá-lo a proteger e gerir ainda mais as credenciais, definir experiência de autenticação, atribuição de delegados, medir o uso e definir políticas de acesso baseadas na postura de segurança da empresa.

  • Atribua os proprietários a tarefas-chave.
  • Implementar soluções para detetar senhas fracas ou vazadas, melhorar a gestão e proteção de passwords e garantir ainda mais o acesso dos utilizadores aos recursos.
  • Gerencie a identidade dos dispositivos para proteger os seus recursos a qualquer momento e a partir de qualquer local.
  • Implementar a autenticação sem palavras-passe.
  • Forneça um mecanismo de inscrição único padronizado em toda a organização.
  • Migrar aplicativos de AD FS para Azure AD para permitir uma melhor segurança e uma gestão mais consistente.
  • Atribua os utilizadores às aplicações utilizando grupos para permitir uma maior flexibilidade e capacidade de gestão em escala.
  • Configure políticas de acesso baseadas no risco.
  • Bloqueie os protocolos de autenticação do legado.
  • Detetar e remediar subsídios de consentimento ilícitos.
  • Bloqueie as definições do utilizador e do grupo.
  • Permitir armazenamento a longo prazo de registos AZure AD para resolução de problemas, análises de uso e investigações forenses.

Passos seguintes

Introdução com a verificação operacional da identidade e as ações.