Recomendações para gerenciamento de identidade e acesso

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

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 controle técnico, a identidade é sempre o perímetro principal. Esse escopo não inclui apenas as bordas de sua carga de trabalho. Ele também inclui componentes individuais que estão dentro de 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 nenhuma evidência sobre quem são.

Definições 

A função 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 aprimorados com frequência com base nos vetores de ataque mais recentes, capturando bilhões de sinais em vários locatários todos os dias. A ID do Microsoft Entra é o IdP da plataforma de nuvem do Azure.

Autenticação

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

• Um nome de usuário e senha.

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

• Um token SAS (Assinatura de Acesso Compartilhado).

• 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 estar operacional ou relacionada ao gerenciamento 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 de 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 para dentro) e fluxos que alcançam a carga de trabalho para outras fontes (acesso de dentro para fora).

Cada caso de uso provavelmente terá seu próprio conjunto de controles que você precisa projetar com uma mentalidade de violação de suposição. Com base nos requisitos de identidade do caso de uso ou das personas, identifique as opções 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 introduzir uma sobrecarga de gerenciamento desnecessária.

Você precisa registrar a trilha de acesso de 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 externo. 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 por meio do portal ou acesso à computação para executar comandos.

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

• Acesso interno. Seu aplicativo precisará acessar outros recursos. Por exemplo, ler ou gravar na plataforma de dados, recuperar segredos do repositório secreto e registrar a telemetria em log nos 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 se aplica no nível do componente. 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 recurso.

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 elas exigem:

• Acesso ao plano de dados. As ações que ocorrem no plano de dados causam a transferência de dados para acesso de dentro para fora ou de fora para dentro. 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.

• Acesso ao plano de controle. As ações que ocorrem no painel 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 do plano de dados, enquanto as operações geralmente acessam os 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, autorize ações que devem ser permitidas. Uma identidade não deve ter permissão para fazer mais do que precisa 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 tem permissão para fazer e até que ponto ela pode fazê-lo. Esses fatores levam a escolhas que combinam identidade, função e escopo.

Considere uma identidade de carga de trabalho como exemplo. O aplicativo deve ter acesso ao plano de dados ao banco de dados, portanto, as ações de leitura e gravação no recurso de dados devem ser permitidas. No entanto, o aplicativo precisa de acesso ao plano de controle ao repositório secreto? Se a identidade da carga de trabalho for comprometida por um agente mal-intencionado, qual seria o impacto no 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 nada mais. Quando as permissões do usuário são restritas aos requisitos do 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 possíveis mitigações e relatar os riscos.

Há cenários em que os usuários precisam de mais acesso devido à estrutura organizacional e à organização da equipe. Pode haver uma sobreposição entre várias funções ou usuários únicos 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 referenciam especificamente usuários ou recursos individuais. Permissões granulares e personalizadas criam complexidade e confusão porque não transmitem a intenção a 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 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, assinatura, grupo de recursos ou escopo de recurso permitidos 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 o RBAC (controle de acesso baseado em função). Sempre use 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 à complexidade, o que aumenta a confusão e torna a automação mais complexa, desafiadora e frágil. Esses fatores afetam negativamente a segurança.

Conceda funções que comecem com privilégios mínimos e adicione mais com base em suas necessidades operacionais ou de acesso a dados. Suas equipes técnicas devem ter diretrizes 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 opções de acesso condicional

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

• Hora. 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 tem 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 alterar o ambiente. Restrinja esses fatores de acesso como medida preventiva e para controlar o raio da explosão.

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

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

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

Use controles fortes que filtram, detectam e bloqueiam 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 facilita a prevenção e a detecção de ataques provenientes desses vetores.

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

Proteger contas de impacto crítico

As identidades administrativas apresentam 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 comprometimento ou o uso indevido podem ter um efeito prejudicial em seus negócios e seus sistemas de informação. A segurança da administração é uma das áreas de segurança mais críticas.

Proteger o acesso privilegiado em relação a determinados adversários requer uma abordagem completa e elaborada para isolar esses sistemas contra riscos. Veja algumas estratégias:

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

• Use funções separadas em vez de elevar 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 os principais atributos de segurança usando políticas de acesso condicional.

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

Use uma única identidade em todos os ambientes e associe uma única identidade ao usuário ou entidade de segurança. A consistência de identidades em ambientes de nuvem e locais 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 autoritativa 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 dos ativos locais e isso pode levar a um comprometimento bem-sucedido de uma conta de nuvem. Avalie sua estratégia de sincronização filtrando contas que podem ser adicionadas à superfície de ataque.

Estabelecer processos para gerenciar o ciclo de vida da identidade

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

Essas diretrizes se aplicam ao controle do código-fonte, dados, planos de controle, usuários de 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 altos privilégios, usuários externos/convidados e usuários de carga de trabalho. Implemente revisões de acesso para garantir que, quando as identidades saírem da organização ou da equipe, suas permissões de carga de trabalho sejam removidas.

Proteger 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 provedor ou consumidor for comprometido, riscos de segurança significativos podem ser introduzidos. 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 a seus recursos.

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

• Trate esses segredos como entidades que podem ser extraídas dinamicamente de um repositório secreto. Eles não devem ser codificados no código do aplicativo, nos scripts de IaC, nos 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 Key Vault.

Mantenha os ambientes de desenvolvimento seguros

Todos os códigos e scripts, ferramentas de pipeline e sistemas de controle do código-fonte devem ser considerados ativos de carga de trabalho. O acesso às gravações deve ser bloqueado com automação e revisão por pares. O acesso de leitura ao código-fonte deve ser limitado a 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 verifique 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 trilha de auditoria

Um aspecto do gerenciamento de identidade é garantir que o sistema seja auditável. As auditorias validam se as estratégias de violação de suposição são eficazes. Manter uma trilha de auditoria ajuda você a:

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

• Detecte protocolos de autenticação fracos ou ausentes e obtenha visibilidade e insights 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 do usuário, o status do dispositivo e outros critérios e políticas definidos.

• Acompanhe o progresso ou o 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 o acesso condicional. O Microsoft Entra ID fornece gerenciamento de identidade e acesso no Azure. Ele abrange o plano de gerenciamento do Azure e é integrado aos planos de dados da maioria dos serviços do Azure. A ID do Microsoft Entra é 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:

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

• ID externa 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 a ID do Microsoft Entra para autenticação e autorização de aplicativos personalizados por meio da MSAL (Biblioteca de Autenticação da Microsoft) ou recursos da plataforma, como autenticação para aplicativos Web. Ele aborda 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 se manter atualizado visitando Novidades na ID do Microsoft Entra.

Compensação: O Microsof 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 dá suporte a 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 na ID do Microsoft Entra. 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 necessárias. Para obter mais informações, confira Funções internas 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 na ID do Microsoft Entra.

• 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 o 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

A ID do Microsoft Entra 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 do aplicativo.

Nem todos os serviços dão suporte a identidades gerenciadas. Se você não puder usar identidades gerenciadas, 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, consulte O que são identidades gerenciadas para 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 se autenticar em outros serviços que dão 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 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 com base em suas necessidades operacionais.

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

Gerenciamento de acesso ao 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 verificar se as permissões estão atualizadas. Você também pode usar o grupo para outros fins, como listas de e-mail.

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

Detecção de ameaças

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

A detecção de ameaças pode assumir a forma de reação a um alerta de atividade suspeita ou pesquisa proativa de eventos anômalos em logs de atividades. A UEBA (Análise de Comportamento de Usuário e Entidade) no Microsoft Sentinel facilita a detecçã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 a ID do Microsoft Entra que tenham altos privilégios no Active Directory existente. Essa sincronização é 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 como filtrar na ID do Microsoft Entra, consulte Sincronização do Microsoft Entra Connect: configurar a filtragem.

Registro de identidade

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 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. A ID do Microsoft Entra fornece acesso a planos de dados de serviço que não são voltados para os usuários, como o Azure Key Vault e armazenamentos de dados. Essas identidades também controlam o acesso, por meio do 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 AKS (Serviço de Kubernetes do Azure) usam identidades de carga de trabalho para se autenticar em outros componentes da solução.

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

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

A segurança de segredos pré-compartilhados é fundamental para qualquer aplicativo. O Azure Key Vault fornece um mecanismo de armazenamento seguro para esses segredos, incluindo segredos do Redis e 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 da Microsoft do OAuth 2 e do OpenID Connect são usados para autenticar usuários.

O Azure Policy é usado para garantir que os componentes de identidade, como o Key Vault, usem o RBAC em vez de políticas de acesso. O JIT e o 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 do código para componentes de código.

Links relacionados

• 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 de certificados no Key Vault
• O que há de novo na ID do Microsoft Entra?
• Funções internas do Microsoft Entra
• Visão geral do controle de acesso baseado em função no Microsoft Entra ID
• O que são identidades de carga de trabalho?
• O que são identidades gerenciadas para recursos do Azure?
• Acesso condicional: usuários, grupos e identidades de carga de trabalho
• Sincronização do Microsoft Entra Connect: configurar a filtragem

Lista de verificação de segurança

Consulte o conjunto completo de recomendações.