Recomendações para gerenciamento de identidade e acesso

Aplica-se a esta recomendação de lista de verificação de segurança do Azure Well-Architected Framework:

Este guia descreve as recomendações para autenticar e autorizar identidades que estão tentando acessar seus recursos de carga de trabalho.

Do ponto de vista do controlo técnico, a identidade é sempre o perímetro primário. Esse escopo não inclui apenas as bordas da sua carga de trabalho. Ele também inclui componentes individuais que estão dentro da sua carga de trabalho. As identidades típicas incluem:

• Humanos. Usuários de aplicativos, administradores, operadores, auditores e agentes mal-intencionados.

• sistemas. Identidades de carga de trabalho, identidades gerenciadas, chaves de API, entidades de serviço e recursos do Azure.

• Anónimo. Entidades que não forneceram qualquer prova sobre quem são.

Definições 

O papel de um provedor de identidade

Um provedor de identidade (IdP) é um serviço hospedado na nuvem que armazena e gerencia usuários como identidades digitais.

Aproveite os recursos fornecidos por um IdP confiável para seu gerenciamento de identidade e acesso. Não implemente sistemas personalizados para substituir um IdP. Os sistemas IdP são melhorados com frequência com base nos vetores de ataque mais recentes, capturando bilhões de sinais em vários locatários todos os dias. O Microsoft Entra ID é o IdP para a plataforma de nuvem do Azure.

Autenticação

A autenticação é um processo que verifica identidades. A identidade requerente é necessária para fornecer alguma forma de identificação verificável. Por exemplo:

• Um nome de utilizador e uma palavra-passe.

• Um segredo pré-compartilhado, como uma chave de API que concede acesso.

• Um token de assinatura de acesso compartilhado (SAS).

• Um certificado usado na autenticação mútua TLS.

Tanto quanto possível, o processo de verificação deve ser tratado pelo seu IdP.

Autorização

A autorização é um processo que permite ou nega ações solicitadas pela identidade verificada. A ação pode ser operacional ou estar relacionada com a gestão de recursos.

A autorização requer que você atribua permissões às identidades, o que você precisa fazer usando a funcionalidade fornecida pelo seu IdP.

Principais estratégias de design

Para obter uma visão holística das necessidades de identidade para uma carga de trabalho, você precisa catalogar os fluxos, ativos de carga de trabalho e personas, e as ações que os ativos e personas executarão. Sua estratégia deve abranger todos os casos de uso que lidam com os fluxos que atingem a carga de trabalho ou seus componentes (acesso externo) e fluxos que alcançam a carga de trabalho para outras fontes (acesso interno).

Cada caso de uso provavelmente terá seu próprio conjunto de controles que você precisa projetar com uma mentalidade de violação de assunção. Com base nos requisitos de identidade do caso de uso ou das personas, identifique as escolhas condicionais. Evite usar uma solução para todos os casos de uso. Por outro lado, os controles não devem ser tão granulares a ponto de você introduzir despesas gerais de gerenciamento desnecessárias.

Você precisa registrar a trilha de acesso à identidade. Isso ajuda a validar os controles e você pode usar os logs para auditorias de conformidade.

Determinar todas as identidades para autenticação

• Acesso exterior-in. Seu design de identidade deve autenticar todos os usuários que acessam a carga de trabalho para várias finalidades. Por exemplo, um usuário final que acessa o aplicativo chamando APIs.

  Em um nível granular, os componentes da carga de trabalho também podem precisar de acesso externo. Por exemplo, um operador que precisa de acesso através do portal ou acesso à computação para executar comandos.

  Ambos são exemplos de identidades de usuários que têm personas diferentes.

• Acesso de dentro para fora. Seu aplicativo precisará acessar outros recursos. Por exemplo, ler ou gravar na plataforma de dados, recuperar segredos do armazenamento secreto e registrar telemetria em serviços de monitoramento. Pode até precisar acessar serviços de terceiros. Essas necessidades de acesso exigem identidade de carga de trabalho, o que permite que o aplicativo se autentique em relação aos outros recursos.

  O conceito aplica-se ao nível dos componentes. No exemplo a seguir, o contêiner pode precisar de acesso a pipelines de implantação para obter sua configuração. Essas necessidades de acesso exigem identidade de recursos.

Todas essas identidades devem ser autenticadas pelo seu IdP.

Aqui está um exemplo de como a identidade pode ser implementada em uma arquitetura:

Determinar ações para autorização

Em seguida, você precisa saber o que cada identidade autenticada está tentando fazer para que essas ações possam ser autorizadas. As ações podem ser divididas pelo tipo de acesso que exigem:

• Acesso ao plano de dados. As ações que ocorrem no plano de dados causam transferência de dados para acesso de dentro para fora ou de fora. Por exemplo, um aplicativo lendo dados de um banco de dados e gravando dados em um banco de dados, buscando segredos ou gravando logs em um coletor de monitoramento. No nível do componente, a computação que está puxando ou enviando imagens de ou para um registro é considerada operações de plano de dados.

• Controle o acesso ao plano. As ações que ocorrem no plano de controle fazem com que um recurso do Azure seja criado, modificado ou excluído. Por exemplo, alterações nas propriedades do recurso.

Os aplicativos normalmente visam operações de plano de dados, enquanto as operações geralmente acessam planos de controle e de dados. Para identificar as necessidades de autorização, observe as ações operacionais que podem ser executadas no recurso. Para obter informações sobre as ações permitidas para cada recurso, consulte Operações do provedor de recursos do Azure.

Fornecer autorização baseada em função

Com base na responsabilidade de cada identidade, autorizar ações que devem ser permitidas. Não se deve permitir que uma identidade faça mais do que aquilo a que tem de fazer. Antes de definir regras de autorização, você precisa ter uma compreensão clara de quem ou o que está fazendo solicitações, o que essa função pode fazer e até que ponto ela pode fazê-lo. Esses fatores levam a escolhas que combinam identidade, papel e escopo.

Considere uma identidade de carga de trabalho como um exemplo. O aplicativo deve ter acesso ao plano de dados ao banco de dados, portanto, ações de leitura e gravação no recurso de dados devem ser permitidas. No entanto, o aplicativo precisa controlar o acesso do plano ao armazenamento secreto? Se a identidade da carga de trabalho for comprometida por um agente mal-intencionado, qual seria o impacto para o sistema, em termos de confidencialidade, integridade e disponibilidade?

Atribuição de função

Uma função é um conjunto de permissões atribuídas a uma identidade. Atribua funções que permitam apenas que a identidade conclua a tarefa, e não mais. Quando as permissões do usuário são restritas aos seus requisitos de trabalho, é mais fácil identificar comportamentos suspeitos ou não autorizados no sistema.

Faça perguntas como estas:

• O acesso somente leitura é suficiente?
• A identidade precisa de permissões para excluir recursos?

Limitar o nível de acesso que usuários, aplicativos ou serviços têm aos recursos do Azure reduz a superfície de ataque potencial. Se você conceder apenas as permissões mínimas necessárias para executar tarefas específicas, o risco de um ataque bem-sucedido ou acesso não autorizado será significativamente reduzido. Por exemplo, as equipes de segurança só precisam de acesso somente leitura aos atributos de segurança para todos os ambientes técnicos. Esse nível é suficiente para avaliar os fatores de risco, identificar potenciais mitigações e relatar os riscos.

Há cenários em que os usuários precisam de mais acesso por causa da estrutura organizacional e da organização da equipe. Pode haver uma sobreposição entre várias funções ou usuários individuais podem executar várias funções padrão. Nesse caso, use várias atribuições de função baseadas na função de negócios em vez de criar uma função personalizada para cada um desses usuários. Isso torna as funções mais fáceis de gerenciar.

Evite permissões que façam referência específica a recursos ou usuários individuais. Permissões granulares e personalizadas criam complexidade e confusão porque não transmitem a intenção para novos recursos semelhantes. Isso pode criar uma configuração herdada complexa que é difícil de manter e afeta negativamente a segurança e a confiabilidade.

Compensação: Uma abordagem granular de controle de acesso permite uma melhor auditoria e monitoramento das atividades do usuário.

Uma função também tem um escopo associado. A função pode operar no grupo de gerenciamento permitido, assinatura, grupo de recursos ou escopo de recurso, ou em outro escopo personalizado. Mesmo que a identidade tenha um conjunto limitado de permissões, ampliar o escopo para incluir recursos que estão fora da função de trabalho da identidade é arriscado. Por exemplo, o acesso de leitura a todo o código-fonte e dados pode ser perigoso e deve ser controlado.

Você atribui funções a identidades usando RBAC (controle de acesso baseado em função). Use sempre o RBAC fornecido pelo IdP para aproveitar os recursos que permitem aplicar o controle de acesso de forma consistente e revogá-lo rigorosamente.

Use funções internas. Eles são projetados para cobrir a maioria dos casos de uso. As funções personalizadas são poderosas e, às vezes, úteis, mas você deve reservá-las para cenários em que as funções internas não funcionarão. A personalização leva a uma complexidade que aumenta a confusão e torna a automação mais complexa, desafiadora e frágil. Todos esses fatores afetam negativamente a segurança.

Conceda funções que comecem com privilégios mínimos e adicione mais com base nas suas necessidades operacionais ou de acesso a dados. Suas equipes técnicas devem ter orientações claras para implementar permissões.

Se você quiser um controle refinado no RBAC, adicione condições na atribuição de função com base no contexto, como ações e atributos.

Fazer escolhas de acesso condicional

Não dê a todas as identidades o mesmo nível de acesso. Baseie as suas decisões em dois fatores principais:

• Tempo. Por quanto tempo a identidade pode acessar seu ambiente.

• Privilégio. O nível de permissões.

Esses fatores não são mutuamente exclusivos. Uma identidade comprometida que tenha mais privilégios e duração ilimitada de acesso pode obter mais controle sobre o sistema e os dados ou usar esse acesso para continuar a mudar o ambiente. Restringir esses fatores de acesso como medida preventiva e para controlar o raio de explosão.

• As abordagens Just in Time (JIT) fornecem os privilégios necessários apenas quando são necessárias.

• Just Enough Access (JEA) fornece apenas os privilégios necessários.

Embora o tempo e o privilégio sejam os fatores principais, existem outras condições que se aplicam. Por exemplo, você também pode usar o dispositivo, a rede e o local de onde o acesso se originou para definir políticas.

Use controles fortes que filtrem, detetem e bloqueiem o acesso não autorizado, incluindo parâmetros como identidade e localização do usuário, integridade do dispositivo, contexto da carga de trabalho, classificação de dados e anomalias.

Por exemplo, sua carga de trabalho pode precisar ser acessada por identidades de terceiros, como fornecedores, parceiros e clientes. Eles precisam do nível apropriado de acesso em vez das permissões padrão que você fornece aos funcionários em tempo integral. A diferenciação clara de contas externas torna mais fácil prevenir e detetar ataques provenientes desses vetores.

Sua escolha de IdP deve ser capaz de fornecer essa diferenciação, fornecer recursos internos que concedem permissões com base no menor privilégio e fornecer inteligência interna contra ameaças. Isso inclui o monitoramento de solicitações de acesso e logins. O IdP do Azure é o Microsoft Entra ID. Para obter mais informações, consulte a seção Facilitação do Azure deste artigo.

Proteja contas de impacto crítico

As identidades administrativas introduzem alguns dos riscos de segurança de maior impacto porque as tarefas que executam exigem acesso privilegiado a um amplo conjunto desses sistemas e aplicativos. O compromisso ou a utilização indevida podem ter um efeito prejudicial na sua empresa e nos seus sistemas de informação. A segurança da administração é uma das áreas de segurança mais críticas.

Proteger o acesso privilegiado contra adversários determinados exige que você adote uma abordagem completa e cuidadosa para isolar esses sistemas dos riscos. Seguem-se algumas estratégias:

• Minimize o número de contas de impacto crítico.

• Use funções separadas em vez de elevar os privilégios para identidades existentes.

• Evite o acesso permanente ou permanente usando os recursos JIT do seu IdP. Para situações de quebra de vidro, siga um processo de acesso de emergência.

• Use protocolos de acesso modernos, como autenticação sem senha ou autenticação multifator. Externalize esses mecanismos para o seu IdP.

• Imponha atributos de segurança de chave usando políticas de acesso condicional.

• Descomissionar contas administrativas que não estão sendo usadas.

Use uma única identidade entre ambientes e associe uma única identidade ao usuário ou entidade de segurança. A consistência das identidades em ambientes locais e na nuvem reduz os erros humanos e os riscos de segurança resultantes. As equipes em ambos os ambientes que gerenciam recursos precisam de uma fonte consistente e autorizada para atender às garantias de segurança. Trabalhe com sua equipe central de identidade para garantir que as identidades em ambientes híbridos sejam sincronizadas.

Risco: há um risco associado à sincronização de identidades de alto privilégio. Um invasor pode obter controle total de ativos locais, e isso pode levar a um comprometimento bem-sucedido de uma conta na nuvem. Avalie sua estratégia de sincronização filtrando as contas que podem ser adicionadas à superfície de ataque.

Estabeleça processos para gerenciar o ciclo de vida da identidade

O acesso às identidades não deve durar mais do que os recursos que as identidades acessam. Certifique-se de ter um processo para desativar ou excluir identidades quando houver alterações na estrutura da equipe ou nos componentes de software.

Esta orientação se aplica ao controle da fonte, dados, planos de controle, usuários da carga de trabalho, infraestrutura, ferramentas, monitoramento de dados, logs, métricas e outras entidades.

Estabeleça um processo de governança de identidade para gerenciar o ciclo de vida de identidades digitais, usuários com privilégios elevados, usuários externos/convidados e usuários de carga de trabalho. Implemente revisões de acesso para garantir que, quando as identidades deixarem a organização ou a equipe, suas permissões de carga de trabalho sejam removidas.

Proteja segredos não baseados em identidade

Segredos de aplicativos, como chaves pré-compartilhadas, devem ser considerados pontos vulneráveis no sistema. Na comunicação bidirecional, se o fornecedor ou o consumidor forem comprometidos, podem ser introduzidos riscos de segurança significativos. Essas chaves também podem ser onerosas porque introduzem processos operacionais.

Quando puder, evite usar segredos e considere o uso de autenticação baseada em identidade para acesso do usuário ao próprio aplicativo, não apenas aos seus recursos.

A lista a seguir fornece um resumo das orientações. Para obter mais informações, consulte Recomendações para segredos de aplicativos.

• Trate esses segredos como entidades que podem ser extraídas dinamicamente de uma loja secreta. Eles não devem ser codificados no código do aplicativo, scripts IaC, pipelines de implantação ou em qualquer outro artefato.

• Certifique-se de que você tem a capacidade de revogar segredos.

• Aplique práticas operacionais que lidam com tarefas como rotação e expiração de chaves.

Para obter informações sobre políticas de rotação, consulte Automatizar a rotação de um segredo para recursos que têm dois conjuntos de credenciais de autenticação e Tutorial: Atualizando a frequência de rotação automática de certificados no Cofre de Chaves.

Mantenha os ambientes de desenvolvimento seguros

Todos os códigos e scripts, ferramentas de pipeline e sistemas de controle de origem devem ser considerados ativos de carga de trabalho. O acesso às gravações deve ser fechado com automação e revisão por pares. O acesso de leitura ao código-fonte deve ser limitado às funções com base na necessidade de conhecimento. Os repositórios de código devem ter controle de versão e as revisões de código de segurança por pares devem ser uma prática regular integrada ao ciclo de vida de desenvolvimento. Você precisa ter um processo em vigor que analise os recursos regularmente e identifique as vulnerabilidades mais recentes.

Use identidades de carga de trabalho para conceder acesso a recursos de ambientes de implantação, como o GitHub.

Manter uma pista de auditoria

Um aspeto do gerenciamento de identidade é garantir que o sistema seja auditável. As auditorias validam se as estratégias de violação de assunção são eficazes. A manutenção de uma pista de auditoria ajuda-o a:

• Verifique se a identidade está autenticada com autenticação forte. Qualquer ação deve ser rastreável para evitar ataques de repúdio.

• Detete protocolos de autenticação fracos ou ausentes e obtenha visibilidade e informações sobre entradas de usuários e aplicativos.

• Avalie o acesso de identidades à carga de trabalho com base nos requisitos de segurança e conformidade e considere o risco da conta de usuário, o status do dispositivo e outros critérios e políticas definidos.

• Acompanhe o progresso ou desvio dos requisitos de conformidade.

A maioria dos recursos tem acesso ao plano de dados. Você precisa conhecer as identidades que acessam os recursos e as ações que eles executam. Você pode usar essas informações para diagnósticos de segurança.

Para obter mais informações, consulte Recomendações sobre monitoramento de segurança e análise de ameaças.

Facilitação do Azure

Recomendamos que você sempre use protocolos de autenticação modernos que levem em conta todos os pontos de dados disponíveis e usem acesso condicional. O Microsoft Entra ID fornece gerenciamento de identidade e acesso no Azure. Ele abrange o plano de gerenciamento do Azure e é integrado com os planos de dados da maioria dos serviços do Azure. O Microsoft Entra ID é o locatário associado à assinatura de carga de trabalho. Ele rastreia e gerencia identidades e suas permissões permitidas e simplifica o gerenciamento geral para minimizar o risco de supervisão ou erro humano.

Esses recursos se integram nativamente ao mesmo modelo de identidade e permissão do Microsoft Entra para segmentos de usuário:

• ID do Microsoft Entra. Funcionários e recursos da empresa.

• ID Externo do Microsoft Entra. Parceiros.

• Azure AD B2C. clientes.

• Lista de compatibilidade de federação do Microsoft Entra. Soluções de federação de terceiros.

Você pode usar o Microsoft Entra ID para autenticação e autorização de aplicativos personalizados por meio da Biblioteca de Autenticação da Microsoft (MSAL) ou recursos da plataforma, como autenticação para aplicativos Web. Ele abrange o plano de gerenciamento do Azure, os planos de dados da maioria dos serviços do Azure e os recursos de integração para seus aplicativos.

Você pode manter-se atualizado visitando O que há de novo no Microsoft Entra ID.

Compensação: o Microsoft Entra ID é um único ponto de falha, assim como qualquer outro serviço fundamental. Não há solução alternativa até que a interrupção seja corrigida pela Microsoft. No entanto, o rico conjunto de recursos do Microsoft Entra supera o risco de usar soluções personalizadas.

O Azure suporta protocolos abertos como OAuth2 e OpenID Connect. Recomendamos que você use esses mecanismos padrão de autenticação e autorização em vez de projetar seus próprios fluxos.

RBAC do Azure

O RBAC do Azure representa entidades de segurança no Microsoft Entra ID. Todas as atribuições de função são feitas por meio do RBAC do Azure. Aproveite as funções internas que fornecem a maioria das permissões de que você precisa. Para obter mais informações, veja Funções incorporadas do Microsoft Entra.

Aqui estão alguns casos de uso:

• Ao atribuir usuários a funções, você pode controlar o acesso aos recursos do Azure. Para obter mais informações, consulte Visão geral do controle de acesso baseado em função no Microsoft Entra ID.

• Você pode usar o Privileged Identity Management para fornecer ativação de função baseada em tempo e aprovação para funções associadas a identidades de alto impacto. Para obter mais informações, consulte O que é o Privileged Identity Management?.

Para obter mais informações sobre RBAC, consulte Práticas recomendadas para o RBAC do Azure.

Para obter informações sobre controles baseados em atributos, consulte O que é o Azure ABAC?.

Identidade da carga de trabalho

O Microsoft Entra ID pode lidar com a identidade do seu aplicativo. A entidade de serviço associada ao aplicativo pode ditar seu escopo de acesso.

Para obter mais informações, consulte O que são identidades de carga de trabalho?.

A entidade de serviço também é abstraída quando você usa uma identidade gerenciada. A vantagem é que o Azure gerencia todas as credenciais para o aplicativo.

Nem todos os serviços suportam identidades gerenciadas. Se não for possível usar identidades gerenciadas, você poderá usar entidades de serviço. No entanto, o uso de entidades de serviço aumenta a sobrecarga de gerenciamento. Para obter mais informações, veja O que são identidades geridas para os recursos do Azure?.

Identidade do recurso

O conceito de identidades gerenciadas pode ser estendido aos recursos do Azure. Os recursos do Azure podem usar identidades gerenciadas para autenticar-se em outros serviços que oferecem suporte à autenticação do Microsoft Entra. Para obter mais informações, consulte Serviços do Azure que podem usar identidades gerenciadas para acessar outros serviços.

Políticas de acesso condicional

O acesso condicional descreve a sua política para uma decisão de acesso. Para usar o acesso condicional, você precisa entender as restrições necessárias para o caso de uso. Configure o Acesso Condicional do Microsoft Entra configurando uma política de acesso baseada em suas necessidades operacionais.

Para obter mais informações, consulte Acesso condicional: usuários, grupos e identidades de carga de trabalho.

Gestão de acesso de grupo

Em vez de conceder permissões a usuários específicos, atribua acesso a grupos no Microsoft Entra ID. Se um grupo não existir, trabalhe com sua equipe de identidade para criar um. Em seguida, você pode adicionar e remover membros do grupo fora do Azure e certificar-se de que as permissões estão atualizadas. Você também pode usar o grupo para outros fins, como listas de discussão.

Para obter mais informações, consulte Controle de acesso seguro usando grupos no Microsoft Entra ID.

Deteção de ameaças

O Microsoft Entra ID Protection pode ajudá-lo a detetar, investigar e corrigir riscos baseados em identidade. Para obter mais informações, consulte O que é a Proteção de Identidade?.

A deteção de ameaças pode assumir a forma de reagir a um alerta de atividade suspeita ou procurar proativamente eventos anómalos nos registos de atividades. A Análise de Comportamento de Usuários e Entidades (UEBA) no Microsoft Sentinel facilita a deteção de atividades suspeitas. Para obter mais informações, consulte Identificar ameaças avançadas com o UEBA.

Sistemas híbridos

No Azure, não sincronize contas com o Microsoft Entra ID que tenham altos privilégios no Ative Directory existente. Essa sincronização está bloqueada na configuração padrão do Microsoft Entra Connect Sync, portanto, você só precisa confirmar que não personalizou essa configuração.

Para obter informações sobre filtragem no Microsoft Entra ID, consulte Microsoft Entra Connect Sync: Configurar a filtragem.

Registo de identidades

Habilite as configurações de diagnóstico nos recursos do Azure para emitir informações que você pode usar como uma trilha de auditoria. As informações de diagnóstico mostram quais identidades tentam acessar quais recursos e o resultado dessas tentativas. Os logs coletados são enviados para o Azure Monitor.

Compensação: o registro em log incorre em custos devido ao armazenamento de dados usado para armazenar os logs. Isso também pode causar um impacto no desempenho, especialmente no código e nas soluções de registro em log que você adiciona ao aplicativo.

Exemplo

O exemplo a seguir mostra uma implementação de identidade. Diferentes tipos de identidades são usados juntos para fornecer os níveis necessários de acesso.

Componentes de identidade

• Identidades gerenciadas pelo sistema. O Microsoft Entra ID fornece acesso a planos de dados de serviço que não enfrentam usuários, como o Azure Key Vault e armazenamentos de dados. Essas identidades também controlam o acesso, via RBAC, ao plano de gerenciamento do Azure para componentes de carga de trabalho, agentes de implantação e membros da equipe.

• Identidades de carga de trabalho. Os serviços de aplicativo no cluster do Serviço Kubernetes do Azure (AKS) usam identidades de carga de trabalho para autenticar-se em outros componentes da solução.

• Identidades gerenciadas. Os componentes do sistema na função cliente usam identidades gerenciadas pelo sistema, incluindo agentes de compilação.

• Identidades humanas. A autenticação de usuário e operador é delegada ao Microsoft Entra ID ou Microsoft Entra ID (nativo, B2B ou B2C).

A segurança de segredos pré-partilhados é fundamental para qualquer aplicação. O Azure Key Vault fornece um mecanismo de armazenamento seguro para esses segredos, incluindo Redis e segredos de terceiros.

Um mecanismo de rotação é usado para ajudar a garantir que os segredos não sejam comprometidos. Os tokens para a implementação da plataforma de identidade Microsoft do OAuth 2 e do OpenID Connect são usados para autenticar usuários.

A Política do Azure é usada para garantir que os componentes de identidade, como o Cofre da Chave, usem RBAC em vez de políticas de acesso. JIT e JEA fornecem permissões permanentes tradicionais para operadores humanos.

Os logs de acesso são habilitados em todos os componentes por meio do Diagnóstico do Azure ou por meio de código para componentes de código.

Ligações relacionadas

• Tutorial: Automatizar a rotação de um segredo para recursos que têm dois conjuntos de credenciais de autenticação
• Tutorial: Atualizando a frequência de rotação automática do certificado no Cofre da Chave
• O que há de novo no Microsoft Entra ID?
• Funções incorporadas do Microsoft Entra
• Descrição geral do controlo de acesso baseado em funções no Microsoft Entra ID
• O que são identidades de carga de trabalho?
• O que são identidades geridas para recursos do Azure?
• Acesso condicional: identidades de usuários, grupos e carga de trabalho
• Microsoft Entra Connect Sync: Configurar filtragem

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.