Compartilhar via

Gerenciamento de identidade e acesso da zona de destino

  • Artigo

Depois de identificar sua arquitetura de identidade, você precisa gerenciar a autorização e o acesso a recursos em zonas de destino de aplicativo e plataforma. Considere a quais recursos cada entidade autenticada tem acesso e precisa de acesso e como reduzir o risco de acesso não autorizado aos seus recursos. Para obter mais informações, consulte Design de arquitetura de identidade.

Visão geral

A área de design de gerenciamento de identidade e acesso fornece diretrizes para ajudá-lo a implementar o modelo de acesso corporativo no Azure e implementar e proteger planos de controle. Quando você incorpora o princípio de design da democratização da assinatura, sua equipe de aplicativos pode gerenciar suas próprias cargas de trabalho dentro das proteções de política que a equipe da plataforma define. Essa abordagem também segue o princípio de governança orientada por políticas.

A equipe da plataforma é responsável por provisionar novas zonas de destino ou assinaturas de aplicativos. Quando eles provisionam uma zona de destino para um proprietário do aplicativo, a equipe da plataforma deve configurá-la com os controles de acesso apropriados para que o proprietário do aplicativo possa gerenciar seus próprios recursos. O proprietário do aplicativo deve ser capaz de criar e gerenciar usuários e grupos na ID do Microsoft Entra e atribuir funções a esses usuários e grupos. O proprietário do aplicativo pode gerenciar o acesso a seus próprios recursos e delegar acesso a outros usuários e grupos, conforme necessário. A zona de destino também deve ter conectividade de rede opcional com o AD DS (Active Directory Domain Services) ou os Serviços de Domínio Microsoft Entra na assinatura da plataforma de identidade da Microsoft, dependendo dos requisitos do aplicativo.

Use o RBAC (controle de acesso baseado em função) do Azure para gerenciar o acesso administrativo aos recursos do Azure. Considere se os usuários exigem permissões em um escopo restrito, como um administrador para um único aplicativo, ou em um escopo amplo, como um administrador de rede em várias cargas de trabalho de aplicativo. Em ambos os casos, siga o princípio de acesso apenas suficiente e certifique-se de que o usuário tenha apenas as funções necessárias para suas atividades normais. Use funções personalizadas e o Microsoft Entra Privileged Identity Management (PIM) quando necessário para impor o acesso JIT (just-in-time). Embora a equipe da plataforma seja responsável pela base de gerenciamento de identidade e acesso, as equipes de plataforma e aplicativo são consumidoras do serviço e devem seguir os mesmos princípios.

O gerenciamento de identidade e acesso é importante para a separação bem-sucedida de uma zona de destino de outra e o isolamento de cargas de trabalho dentro de uma organização. É uma área de design crítica para zonas de destino de plataforma e aplicativo.

Se sua organização usa um processo de venda automática de assinatura, você pode automatizar muitas das configurações de identidade e acesso para zonas de destino do aplicativo. Implemente a venda automática de assinaturas para ajudar a padronizar a criação de zonas de destino e para que as equipes de aplicativos possam gerenciar seus próprios recursos.

Considerações sobre o design

Algumas organizações compartilham serviços entre vários aplicativos. Por exemplo, pode haver um serviço de integração centralizado usado por vários aplicativos independentes. Nesse cenário, considere quais serviços são gerenciados centralmente e quais são devolvidos às equipes de aplicativos e entenda onde os limites de segurança precisam ser impostos. Dar às equipes de aplicativos acesso administrativo ao serviço compartilhado pode ser útil para a produtividade do desenvolvedor, mas pode fornecer mais acesso do que o necessário.

O gerenciamento de recursos de aplicativos que não cruzam os limites de segurança pode ser delegado às equipes de aplicativos. Considere delegar outros aspectos necessários para manter a segurança e a conformidade também. Permitir que os usuários provisionem recursos em um ambiente gerenciado com segurança possibilita às organizações aproveitar a natureza ágil da nuvem e evitar a violação de qualquer segurança crítica ou limite de governança.

RBAC

Importante

Os recursos clássicos e os administradores clássicos serão desativados em 31 de agosto de 2024. Remova coadministradores desnecessários e use o RBAC do Azure para controle de acesso refinado.

Entenda a diferença entre as funções de ID do Microsoft Entra e as funções RBAC do Azure.

  • As funções de ID do Microsoft Entra controlam os privilégios administrativos para serviços em todo o locatário, como o Microsoft Entra ID e outros serviços da Microsoft, incluindo o Microsoft Teams, o Microsoft Exchange Online e o Microsoft Intune.

  • As funções RBAC do Azure controlam os privilégios administrativos para recursos do Azure, como máquinas virtuais, assinaturas e grupos de recursos.

  • As funções Proprietário do RBAC do Azure e Administrador de Acesso do Usuário podem modificar as atribuições de função nos recursos do Azure. Por padrão, a função de Administrador Global do Microsoft Entra não tem permissão para gerenciar o acesso aos recursos do Azure. Ele deve ser habilitado explicitamente. Para obter mais informações, confira Elevar o acesso para gerenciar todas as assinaturas e grupos de gerenciamento do Azure.

Importante

A Microsoft recomenda que você use funções com o menor número de permissões. Isso ajuda a melhorar a segurança da sua organização. Administrador Global é uma função altamente privilegiada que deve ser limitada a cenários de emergência quando não for possível usar uma função existente.

O diagrama a seguir mostra a relação entre as funções de ID do Microsoft Entra e as funções RBAC do Azure:

Diagrama que mostra a relação entre a ID do Microsoft Entra e as funções RBAC do Azure.

  • Você pode criar grupos atribuíveis a funções e atribuir funções do Microsoft Entra aos grupos se definir a isAssignableToRole propriedade como true. Somente grupos com esse conjunto de propriedades são protegidos. As únicas funções que podem modificar a associação de um grupo são Administradores Globais, Administradores de Função com Privilégios ou o proprietário do grupo.

  • Apenas algumas funções podem redefinir as configurações de senha ou autenticação multifator (MFA) para outro administrador. Essa restrição impede que administradores não autorizados redefinam as credenciais de uma conta com privilégios mais altos para obter mais permissões.

  • Se as funções internas do Azure não atenderem às necessidades específicas de sua organização, você poderá criar funções personalizadas próprias. Assim como as funções internas, você pode atribuir funções personalizadas a usuários, grupos e entidades de serviço nos escopos de locatário, grupo de gerenciamento, assinatura e grupo de recursos. Procure usar funções internas do Azure sempre que possível e crie funções personalizadas apenas quando necessário.

  • Ao projetar sua estratégia de controle de acesso, conheça os limites de serviço para funções, atribuições de função e funções personalizadas.

  • Algumas funções RBAC do Azure dão suporte ao ABAC (controle de acesso baseado em atributo) ou condições de atribuição de função. Quando você usa condições, os administradores podem atribuir funções dinamicamente com base nos atributos do recurso. Por exemplo, você pode atribuir a função Colaborador de Dados do Blob de Armazenamento, mas apenas para blobs que têm uma marca de índice específica em vez de todos os blobs em um contêiner.

  • Você pode usar funções RBAC internas e personalizadas com Microsoft.Authorization/roleAssignments/write permissões ou Microsoft.Authorization/roleAssignments/delete para criar, excluir e atualizar atribuições de função. Qualquer pessoa que tenha essa função pode decidir quem tem permissões de gravação, leitura e exclusão para qualquer recurso no escopo da atribuição. Os membros da equipe da zona de destino da plataforma ou do aplicativo devem considerar como delegar funções privilegiadas a outros usuários e grupos para conceder a eles a autonomia necessária. Para garantir a conformidade com os princípios de acesso com privilégios mínimos, eles podem usar condições para delegar usuários.

Recomendações de design

Recomendações gerais

  • Imponha a MFA (autenticação multifator) do Microsoft Entra para usuários que têm direitos no ambiente do Azure, incluindo a assinatura da plataforma, a assinatura do aplicativo e o locatário da ID do Microsoft Entra. Muitas estruturas de conformidade exigem a imposição de MFA. A MFA ajuda a reduzir o risco de roubo de credenciais e acesso não autorizado. Para impedir o acesso não autorizado a informações confidenciais, certifique-se de incluir usuários com funções de Leitor nas políticas de MFA.

  • Use políticas de Acesso Condicional do Microsoft Entra para usuários que têm direitos no ambiente do Azure. O Acesso Condicional é outro recurso que ajuda a proteger um ambiente controlado do Azure contra acesso não autorizado. Os administradores de aplicativos e plataformas devem ter políticas de Acesso Condicional que reflitam o perfil de risco de sua função. Por exemplo, você pode ter requisitos para executar atividades administrativas somente em locais específicos ou estações de trabalho específicas. Ou a tolerância ao risco de entrada para usuários com acesso administrativo aos recursos do Azure pode ser menor do que para usuários padrão da ID do Microsoft Entra.

  • Habilite o Microsoft Defender para Identidade para ajudar a proteger as identidades do usuário e as credenciais do usuário. O Defender para Identidade faz parte do Microsoft Defender XDR. Você pode usar o Defender para Identidade para identificar atividades suspeitas do usuário e obter cronogramas de incidentes. Você também pode usá-lo com o Acesso Condicional para negar tentativas de autenticação de alto risco. Implante sensores do Defender para Identidade em controladores de domínio locais e controladores de domínio na assinatura de identidade do Azure.

  • Use o Microsoft Sentinel para fornecer recursos de investigação e inteligência contra ameaças. O Sentinel usa logs de logs do Azure Monitor, Microsoft Entra ID, Microsoft 365 e outros serviços para fornecer detecção, investigação e resposta proativas a ameaças.

  • Separe o acesso administrativo do acesso diário não administrativo, como navegação na Web e acesso a email. Web e e-mail são vetores de ataque comuns. Quando uma conta de usuário é comprometida, é menos provável que resulte em uma violação de segurança se a conta não for usada para acesso administrativo.

    • Use contas separadas e somente na nuvem para funções privilegiadas. Não use a mesma conta para uso diário que você usa para administração privilegiada. As funções privilegiadas do Microsoft Entra ID e RBAC do Azure são marcadas como PRIVILEGED no portal do Azure e na documentação.

    • Para funções de função de trabalho sem privilégios que podem gerenciar recursos de aplicativo do Azure, considere se você precisa de contas administrativas separadas ou usa o Microsoft Entra PIM para controlar o acesso administrativo. O PIM garante que a conta tenha as permissões necessárias somente quando necessário e que as permissões sejam removidas quando a tarefa for concluída (também conhecido como acesso just-in-time).

  • Para tornar as atribuições de função mais gerenciáveis, não atribua funções diretamente aos usuários. Em vez disso, atribua funções a grupos para ajudar a minimizar o número de atribuições de função, que tem um limite para cada assinatura.

    • Use o Microsoft Entra PIM para grupos para aplicar controles de acesso administrativo just-in-time a usuários privilegiados. Considere controlar a associação de grupo com o gerenciamento de direitos. Você pode usar o recurso de gerenciamento de direitos para adicionar fluxos de trabalho de aprovação e auditoria às operações de associação de grupo e ajudar a garantir que os membros do grupo administrativo não sejam adicionados ou removidos desnecessariamente.

    • Ao conceder acesso aos recursos, use grupos somente do Microsoft Entra para recursos do painel de controle do Azure. Os usuários e grupos somente do Entra e aqueles sincronizados do local usando o Microsoft Entra Connect podem ser adicionados a um grupo somente do Entra. Adicione grupos locais ao grupo somente do Microsoft Entra se um sistema de gerenciamento de grupo já estiver em vigor. O uso de grupos somente do Entra ajuda a proteger o painel de controle da nuvem contra modificações não autorizadas de serviços de diretório locais. Observe que o Microsoft Entra-only também é conhecido como somente nuvem.

  • Crie contas de acesso de emergência ou contas de emergência para evitar ser bloqueado acidentalmente de sua organização de ID do Microsoft Entra. As contas de acesso de emergência são altamente privilegiadas e são atribuídas apenas a indivíduos específicos. Armazene as credenciais das contas com segurança, monitore seu uso e teste-as regularmente para garantir que você possa usá-las em caso de desastre.

    Para obter mais informações, consulte Práticas de acesso seguro para administradores na ID do Microsoft Entra.

Recomendações de ID do Microsoft Entra

  • Integre a ID do Microsoft Entra ao Azure Monitor para que você possa analisar sua atividade de entrada e a trilha de auditoria de alterações em seu locatário. Defina uma configuração de diagnóstico para enviar logs de entrada e logs de auditoria para o workspace de Logs do Azure Monitor central da plataforma na assinatura de gerenciamento.

  • Use o recurso de gerenciamento de direitos da Governança de ID do Microsoft Entra para criar pacotes de acesso que controlam a associação ao grupo por meio de processos de aprovação automática e revisões regulares de acesso para membros do grupo privilegiado.

  • Use as funções internas do Microsoft Entra para gerenciar as seguintes configurações de identidade de um nível de locatário:

    Função Descrição Observação
    Administrador Global Gerencia todos os aspectos da ID do Microsoft Entra e dos serviços da Microsoft que usam identidades do Microsoft Entra. Não atribua mais de cinco pessoas a essa função.
    Administrador de Identidade Híbrida Gerencia o provisionamento de nuvem do Active Directory para a ID do Microsoft Entra e também gerencia o Microsoft Entra Connect, a autenticação de passagem do Microsoft Entra, a sincronização de hash de senha do Microsoft Entra, o SSO (logon único) contínuo do Microsoft Entra e as configurações de federação.
    Administrador de Segurança Lê informações e relatórios de segurança e gerencia configurações no Microsoft Entra ID e no Microsoft 365.
    Administrador de aplicativos Cria e gerencia todos os aspectos de registros de aplicativos e aplicativos empresariais. Você não pode conceder consentimento administrativo em todo o locatário.

  • Não atribua uma função com privilégios mais altos a uma tarefa que uma função com privilégios mais baixos pode fazer. Por exemplo, atribua a função de Administrador de Usuários para gerenciar usuários, não a função de Administrador Global. Para obter mais informações, consulte Permissões de funções internas do Microsoft Entra.

  • Use unidades administrativas para restringir um conjunto de administradores para que eles possam gerenciar apenas objetos específicos em seu locatário. Você pode usar unidades administrativas para delegar a administração de um subconjunto do diretório. Por exemplo, você pode delegar a administração de uma central de serviços a uma única unidade de negócios dentro de uma organização mais ampla.

    As unidades administrativas também podem ajudar a eliminar a necessidade de locatários separados do Microsoft Entra ID como um limite de segurança, em que equipes separadas gerenciam a plataforma Microsoft 365 e a plataforma Azure na mesma organização. Por exemplo, você pode usar unidades administrativas para delegar o gerenciamento de entidades de segurança de aplicativos do Azure à equipe de aplicativos sem conceder privilégios em todo o locatário da ID do Microsoft Entra.

  • Use unidades administrativas de gerenciamento restrito para fornecer proteção adicional. Impedir que qualquer pessoa que não seja um conjunto específico de administradores que você designar modifique objetos específicos. Por exemplo, suas políticas de separação de tarefas podem exigir que você use esse recurso para impedir que alguém modifique uma conta de usuário específica, mesmo usuários com a função de Administrador de usuários. Essa restrição é útil para contas de serviço que os aplicativos usam e que nem mesmo os administradores devem modificar. Você também pode evitar o escalonamento de privilégios, por exemplo, se alguém modificar uma conta de usuário ou grupo que tenha privilégios de administração de plataforma ou zona de destino.

Recomendações do RBAC do Azure

  • Para simplificar a administração e reduzir o risco de configuração incorreta, padronize funções e atribuições de função em todas as zonas de destino do aplicativo. Por exemplo, se você tiver uma função que delega usuários para gerenciar máquinas virtuais, use a mesma função em todas as zonas de destino do aplicativo. Essa abordagem também simplifica o processo de movimentação de recursos entre zonas de destino.

  • Use o RBAC do Azure para gerenciar o acesso do plano de dados aos recursos se possível. Exemplos de pontos de extremidade do plano de dados são o Azure Key Vault, uma conta de armazenamento ou um banco de dados SQL.

  • Verifique se os workspaces de Logs do Azure Monitor estão configurados com o modelo de permissão apropriado. Ao usar um workspace centralizado de Logs do Azure Monitor, use permissões de recurso para garantir que as equipes de aplicativos tenham acesso a seus próprios logs, mas não aos logs de outras equipes.

Funções internas

  • Considere se as funções internas são adequadas para seus requisitos. Em muitos casos, você pode atribuir várias funções internas a um grupo de segurança para fornecer o acesso apropriado a um usuário. Mas, às vezes, você não pode usar funções internas e também cumprir o acesso com privilégios mínimos porque as funções podem incluir permissões que excedem o que seus usuários exigem. Para um controle mais granular, considere a criação de uma função personalizada que reflita as permissões específicas necessárias para executar uma função de trabalho. Para obter mais informações, consulte Fornecer autorização baseada em função.

  • Muitas funções internas do Azure fornecem atribuições de função predefinidas no nível da plataforma e do recurso. Ao combinar várias atribuições de função, considere os efeitos gerais.

  • O acelerador de zona de destino do Azure inclui várias funções personalizadas para funções administrativas comuns. Você pode usar essas funções junto com as funções internas do Azure. A tabela a seguir descreve as funções ou áreas administrativas personalizadas para o acelerador de zona de destino do Azure:

    Função ou área administrativa Descrição Ações NotActions
    Proprietário da Plataforma do Azure (como a função de Proprietário interna) Gerencia grupos de gerenciamento e ciclos de vida de assinatura *
    Proprietário da assinatura Função delegada para o proprietário da assinatura * Microsoft.Authorization/*/write, Microsoft.Network/vpnGateways/*,
    Microsoft.Network/expressRouteCircuits/*,
    Microsoft.Network/routeTables/write,
    Microsoft.Network/vpnSites/*
    Proprietário do aplicativo (DevOps, operações de aplicativo) Função de colaborador para a equipe de aplicativos ou operações no escopo da assinatura * Microsoft.Authorization/*/write, Microsoft.Network/publicIPAddresses/write,
    Microsoft.Network/virtualNetworks/write,
    Microsoft.KeyVault/locations/deletedVaults/purge/action
    Gerenciamento de Rede (NetOps) Gerencia a conectividade global em toda a plataforma, como redes virtuais, UDRs, NSGs, NVAs, VPNs, Azure ExpressRoute e outros */read,
    Microsoft.Network/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Support/*
    Operações de segurança (SecOps) Função de Administrador de Segurança com uma exibição horizontal em todo o estado do Azure e a política de limpeza do Key Vault */read,
    */register/action,
    Microsoft.KeyVault/locations/deletedVaults/purge/action,
    Microsoft.PolicyInsights/*,
    Microsoft.Authorization/policyAssignments/*,
    Microsoft.Authorization/policyDefinitions/*,
    Microsoft.Authorization/policyExemptions/*,
    Microsoft.Authorization/policySetDefinitions/*,
    Microsoft.Insights/alertRules/*,
    Microsoft.Resources/deployments/*,
    Microsoft.Security/*,
    Microsoft.Support/*

    Essas funções podem precisar de direitos extras, dependendo do modelo de responsabilidade. Por exemplo, em algumas organizações, uma função NetOps pode precisar apenas gerenciar e configurar a conectividade global. Em organizações que precisam de uma abordagem mais centralizada, você pode enriquecer a função NetOps com mais ações permitidas, como criar emparelhamento entre hubs e seus spokes.

Atribuições e grupos de funções

  • Quando a equipe da plataforma provisiona uma zona de destino do aplicativo, ela deve garantir que todos os objetos de gerenciamento de identidade e acesso necessários sejam criados, como grupos de segurança, atribuições de função padrão e identidades gerenciadas atribuídas pelo usuário.

  • Crie atribuições de função de zona de destino no escopo da assinatura ou do grupo de recursos. As atribuições do Azure Policy ocorrem no escopo do grupo de gerenciamento, portanto, você deve provisionar atribuições de função da zona de destino em um escopo inferior. Use essa abordagem para garantir que os administradores da zona de destino tenham total autonomia sobre seus recursos, mas não possam modificar as atribuições do Azure Policy que regem sua zona de destino.

  • Cada zona de destino do aplicativo deve ter seus próprios grupos e atribuições de função. Não crie grupos genéricos e atribua-os a várias zonas de destino. Essa abordagem pode levar a configurações incorretas e violações de segurança, além de ser difícil de gerenciar em escala. Se um usuário precisar de acesso a várias zonas de destino, atribua-o aos grupos apropriados em cada zona de destino. Use a governança de ID para gerenciar a associação ao grupo.

  • Atribua funções a grupos, não a usuários. Essa abordagem ajuda a garantir que os usuários tenham as permissões corretas quando ingressarem ou saírem da sua organização. Também ajuda a garantir que os usuários tenham as permissões corretas quando se movem entre as equipes. Por exemplo, se um usuário passar da equipe de rede para a equipe de segurança, você deverá removê-lo do grupo de rede e adicioná-lo ao grupo de segurança. Se você atribuir uma função diretamente a um usuário, ele manterá a função depois de passar para uma equipe diferente. Use a Governança de ID para gerenciar a associação ao grupo em vez de adicionar e remover manualmente os membros do grupo.

  • Mantenha configurações de segurança separadas para diferentes ambientes do mesmo aplicativo, como desenvolvimento/teste e produção. Crie grupos e atribuições de função separados para cada ambiente. Não compartilhe identidades gerenciadas ou entidades de serviço entre ambientes. Trate cada ambiente como uma zona de destino separada. Essa abordagem ajuda a garantir o isolamento entre desenvolvimento/teste e produção e padroniza o processo de movimentação de implantações de aplicativos entre ambientes. Se o mesmo indivíduo precisar de acesso a várias zonas de destino, você deverá atribuí-los aos grupos apropriados em cada zona de destino.

  • Considere se os administradores da plataforma exigem permissões nas zonas de destino do aplicativo. Nesse caso, use o Microsoft Entra PIM para controlar o acesso a esses recursos e atribuir as permissões menos privilegiadas necessárias. Por exemplo, um administrador de plataforma pode exigir acesso a uma zona de destino de aplicativo específica para solucionar um problema, mas não deve ter acesso de rotina aos dados ou código do aplicativo. Nesse caso, o administrador da plataforma pode solicitar acesso ao aplicativo. Um administrador de função com privilégios aprova a solicitação e o administrador da plataforma recebe as permissões necessárias para o período de tempo especificado. Essa abordagem ajuda a impor a separação de tarefas e protege as zonas de destino do aplicativo contra configurações incorretas acidentais ou mal-intencionadas.

  • Ao delegar responsabilidade administrativa a outras pessoas, como equipes de aplicativos, considere se elas exigem o conjunto completo de privilégios ou apenas um subconjunto. Siga o princípio do menor privilégio (PoLP). Por exemplo, você pode atribuir a função de Administrador de Acesso do Usuário ou a função de Administrador do RBAC a um usuário que precisa gerenciar o acesso aos recursos do Azure, mas não precisa gerenciar os próprios recursos. Para limitar as identidades, os tipos de identidade e as funções às quais os usuários podem delegar e atribuir atribuições do RBAC do Azure, use atribuições de função delegadas com condições. As equipes de aplicativos podem usar condições para gerenciar suas próprias entidades de segurança dentro das restrições definidas pela equipe da plataforma. Atribuições de função com mais privilégios exigem escalonamento para a equipe da plataforma. Considere os seguintes fatores ao usar condições para delegar funções RBAC:

    • Examine as atribuições de função atuais para funções privilegiadas internas e personalizadas e avalie se você deve adicionar condições apropriadas a essas atribuições existentes. Por exemplo, você pode adicionar condições às funções personalizadas Proprietário da Assinatura e Proprietário do Aplicativo que o acelerador de zona de destino do Azure fornece. Essas condições podem restringir os tipos de entidade aos quais eles podem atribuir funções ou limitar funções específicas que podem ser atribuídas.

    • Siga o PoLP ao adicionar condições às atribuições de função. Por exemplo, limite os representantes para atribuir apenas funções a grupos ou permita que os delegados atribuam todas as funções, exceto funções de administrador privilegiado, como Proprietário, Administrador de Acesso do Usuário e Administrador RBAC.

    • Crie suas próprias condições se os modelos de condição disponíveis não atenderem aos seus requisitos ou políticas.

      Captura de tela que mostra os modelos de condição para delegação restrita de RBAC.

    • Examine as limitações conhecidas de delegar o gerenciamento de acesso do Azure a outras pessoas.

  • A tabela a seguir mostra um exemplo de estrutura de atribuição de função para um ambiente de zona de destino do Azure. Ele fornece um equilíbrio entre segurança e facilidade de administração. Você pode adaptar a estrutura para atender às necessidades da sua organização. Você pode atribuir o mesmo indivíduo a vários grupos, dependendo de sua função dentro da organização. Mas você deve aplicar as atribuições RBAC a um grupo específico dentro de uma zona de destino específica.

    Recurso Usuário Atribuição de função Destino da atribuição Escopo de atribuição
    Zona de destino do aplicativo X Proprietários do aplicativo X Proprietário do aplicativo (personalizado, incluído no acelerador de zona de destino do Azure) Application X Admins grupo de segurança Assinaturas de produção e desenvolvimento/teste do aplicativo X
    Zona de destino do aplicativo X Proprietários do aplicativo X Administrador de Acesso ao Aplicativo (personalizado, com condições de atribuição de função para gerenciar o acesso ao próprio aplicativo) Application X Admins grupo de segurança Assinaturas de produção e desenvolvimento/teste do aplicativo X
    Zona de destino do aplicativo X Administrador de dados do aplicativo X Administrador de dados (personalizado, com permissões nos recursos de dados necessários) Application X Data Team grupo de segurança Assinaturas de produção e desenvolvimento/teste do aplicativo X
    Zona de aterrissagem do aplicativo Y Proprietários do aplicativo Y Proprietário do aplicativo (personalizado, incluído no acelerador de zona de destino do Azure) Application Y Admins grupo de segurança Assinaturas de produção e desenvolvimento/teste do aplicativo Y
    Zona de aterrissagem do aplicativo Y Equipe de teste do aplicativo Y Colaborador de Teste (personalizado, com permissões necessárias para teste de aplicativo) Application Y Test Team grupo de segurança Aplicativo Y assinatura de desenvolvimento/teste
    Área restrita Equipe de desenvolvimento do Application Z Proprietário (interno) Application Z developers grupo de segurança Grupos de recursos do aplicativo Z na assinatura de área restrita
    Recursos da plataforma Equipe de gerenciamento de plataforma Colaborador (interno) Platform Admins Grupo PIM Platform Grupo de gestão
    Zonas de destino da plataforma Equipe de gerenciamento de plataforma Leitor (interno) Platform Team grupo de segurança Grupo de gerenciamento organizacional de nível superior
    Em todo o locatário Equipe de segurança Operações de segurança (personalizadas, incluídas no acelerador de zona de destino do Azure) Security Ops grupo de segurança Grupo de gerenciamento organizacional de nível superior
    Em todo o locatário Equipe de segurança Administrador de Acesso Condicional (interno, com ações protegidas habilitadas) Security administrators grupo de segurança Locatários do Microsoft Entra ID
    Em todo o locatário Equipe de Rede Operações de Rede (Personalizadas, incluídas no acelerador de zona de destino do Azure) Network Ops grupo de segurança Todas as assinaturas
    Em todo o locatário Equipe do FinOps Leitor de Faturamento (integrado) FinOps Team grupo de segurança Grupo de gerenciamento organizacional de nível superior

  • As atribuições do Azure Policy que têm o DeployIfNotExists efeito exigem uma identidade gerenciada para corrigir recursos não compatíveis. Se você usar uma identidade gerenciada atribuída pelo sistema como parte do processo de atribuição do Azure Policy, o Azure concederá automaticamente as permissões necessárias. Se você usar uma identidade gerenciada atribuída pelo usuário, as permissões deverão ser concedidas manualmente. As atribuições de função de identidade gerenciada devem seguir a PoLP e habilitar apenas as permissões necessárias para executar a correção de política no escopo de destino. As identidades gerenciadas de correção de política não dão suporte a definições de função personalizadas. Aplique atribuições de função diretamente a identidades gerenciadas e não a grupos.

Recomendações de PIM do Microsoft Entra

  • Use o Microsoft Entra PIM para cumprir o modelo Zero Trust e o acesso com privilégios mínimos. Correlacione as funções da sua organização com os níveis mínimos de acesso necessários. No Microsoft Entra PIM, você pode usar ferramentas nativas do Azure, estender ferramentas e processos existentes ou usar ferramentas existentes e nativas conforme necessário.

  • Use as revisões de acesso do PIM do Microsoft Entra para validar regularmente os direitos de recursos. As revisões de acesso fazem parte de muitas estruturas de conformidade, portanto, muitas organizações já têm um processo de revisão de acesso em vigor.

  • Use identidades privilegiadas para runbooks de automação que exigem permissões de acesso elevadas ou para pipelines de implantação privilegiados. Você pode usar as mesmas ferramentas e políticas para controlar fluxos de trabalho automatizados que acessam limites de segurança críticos que você usa para controlar usuários de privilégios equivalentes. Os pipelines de automação e implantação para equipes de aplicativos devem ter atribuições de função que impeçam que um proprietário de aplicativo escale seus próprios privilégios.

  • Controle funções RBAC do Azure altamente privilegiadas, como Proprietário ou Administradores de Acesso do Usuário que são atribuídos aos membros da equipe da zona de destino da plataforma ou do aplicativo em uma assinatura ou grupo de gerenciamento. Use o PIM do Microsoft Entra para grupos para configurar funções RBAC do Azure para que elas exijam o mesmo processo de elevação que as funções de ID do Microsoft Entra.

    Por exemplo, um usuário pode exigir rotineiramente acesso administrativo limitado a recursos em uma zona de destino do aplicativo. Ocasionalmente, eles podem exigir a função de proprietário. Você pode criar dois grupos de segurança: Administradores de Aplicativos e Proprietários de Aplicativos. Atribua as funções de privilégios mínimos ao grupo Administradores de Aplicativos e atribua a função de proprietário à função Proprietários de Aplicativos. Use grupos PIM para que o usuário possa solicitar a função Proprietário quando necessário. Em todos os outros momentos, o usuário tem apenas as permissões necessárias para realizar suas atividades típicas.

  • Use ações protegidas com o Microsoft Entra PIM para adicionar camadas extras de proteção. Na ID do Microsoft Entra, as ações protegidas são permissões atribuídas a políticas de Acesso Condicional. Quando um usuário tenta executar uma ação protegida, ele deve primeiro atender às políticas de Acesso Condicional atribuídas às permissões necessárias. Por exemplo, para permitir que os administradores atualizem as configurações de acesso entre locatários, você pode exigir que eles primeiro atendam à política de MFA resistente a phishing.

Gerenciamento de identidade e acesso no acelerador de zona de destino do Azure

O gerenciamento de identidade e acesso são os principais recursos da implementação do acelerador de zona de destino do Azure. A implantação inclui uma assinatura dedicada à identidade, em que as organizações podem implantar controladores de domínio do AD DS ou outros serviços de identidade, como servidores Microsoft Entra Connect, necessários para seu ambiente. Nem todas as organizações exigem serviços na assinatura. Por exemplo, algumas organizações podem ter aplicativos que já estão totalmente integrados ao Microsoft Entra ID.

A assinatura de identidade tem uma rede virtual emparelhada com a rede virtual do hub na assinatura da plataforma. Com essa configuração, a equipe da plataforma pode gerenciar a assinatura de identidade e os proprietários do aplicativo têm acesso aos serviços de identidade conforme necessário. Você deve proteger a assinatura de identidade e a rede virtual para proteger os serviços de identidade contra acesso não autorizado.

A implementação do acelerador de zona de destino do Azure também inclui opções para:

  • Atribuir políticas recomendadas para controlar a identidade e os controladores de domínio.
  • Criar uma rede virtual e conectá-la ao hub por meio do emparelhamento de rede virtual.

Próximas etapas

Gerenciamento de identidade e acesso ao aplicativo