Gestão de identidade e acesso à zona de aterragem

Depois de identificar sua arquitetura de identidade, você precisa gerenciar a autorização e o acesso a recursos em zonas de aterrissagem de aplicativos e plataformas. 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.

Descrição geral

A área de design de gerenciamento de identidade e acesso fornece orientação 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 dos guardrails de política definidos pela equipe da plataforma. Esta abordagem segue igualmente o princípio da governação orientada para as políticas.

A equipe da plataforma é responsável pelo provisionamento de novas zonas de destino de aplicativos ou assinaturas. Quando eles provisionam uma zona de aterrissagem para um proprietário de 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 dentro do Microsoft Entra ID e atribuir funções a esses usuários e grupos. O proprietário do aplicativo pode gerenciar o acesso aos seus próprios recursos e delegar acesso a outros usuários e grupos, conforme necessário. A zona de aterrissagem também deve ter conectividade de rede opcional com os Serviços de Domínio Ative Directory (AD DS) 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 precisam de permissões em um escopo estreito, como um Administrador para um único aplicativo, ou em um escopo amplo, como um Administrador de Rede em várias cargas de trabalho de aplicativos. Em ambos os casos, siga o princípio de acesso 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 just-in-time (JIT). 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 para o isolamento de cargas de trabalho dentro de uma organização. É uma área de design crítica para zonas de aterrissagem de plataforma e aplicativo.

Se sua organização usa um processo de venda automática de assinaturas, você pode automatizar muitas das configurações de identidade e acesso para zonas de destino de aplicativos. 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 de 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 transferidos para 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 ultrapassam os limites de segurança pode ser delegado às equipes de aplicativos. Considere delegar outros aspetos 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 permite que as organizações aproveitem a natureza ágil da nuvem e evitem a violação de qualquer limite crítico de segurança ou governança.

RBAC

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 de todo o locatário, como o Microsoft Entra ID, e outros serviços da Microsoft, incluindo Microsoft Teams, Microsoft Exchange Online e 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 de Proprietário do RBAC do Azure e Administrador de Acesso de 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. Deve ser explicitamente habilitado. Para obter mais informações, veja Elevar o acesso para gerir todas as subscrições e grupos de gestão do Azure.

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

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

• Somente 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 redefina 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 da sua organização, você poderá criar suas próprias funções personalizadas. 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 do Azure RBAC dão suporte ao controle de acesso baseado em atributos (ABAC) ou a condições de atribuição de função. Quando você usa condições, os administradores podem atribuir dinamicamente funções com base nos atributos do recurso. Por exemplo, você pode atribuir a função de Colaborador de Dados de Blob de Armazenamento, mas apenas para blobs que tenham 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 ou Microsoft.Authorization/roleAssignments/delete permissões 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 plataforma ou da zona de aterrissagem de aplicativos devem considerar como delegar funções privilegiadas a outros usuários e grupos para conceder-lhes a autonomia necessária. Para garantir a conformidade com os princípios de acesso de privilégios mínimos, eles podem usar condições para delegar usuários.

Recomendações de design

Recomendações gerais

• Aplique a autenticação multifator (MFA) do Microsoft Entra para usuários que têm direitos sobre o ambiente do Azure, incluindo a assinatura da plataforma, a assinatura do aplicativo e o locatário do Microsoft Entra ID. Muitas estruturas de conformidade exigem a aplicação da AMF. O 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 as políticas de Acesso Condicional do Microsoft Entra para usuários que têm direitos para o 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 realizar atividades administrativas somente de 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 do Microsoft Entra ID.

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

• Use o Microsoft Sentinel para fornecer informações sobre ameaças e recursos de investigação. O Sentinel usa logs do Azure Monitor Logs, Microsoft Entra ID, Microsoft 365 e outros serviços para fornecer deteção, investigação e resposta proativas de ameaças.

• Separe o acesso administrativo do acesso diário não administrativo, como navegação na Web e acesso a e-mail. 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ê faz para administração privilegiada. As funções privilegiadas Microsoft Entra ID e Azure RBAC são marcadas como PRIVILEGED no portal do Azure e na documentação.

  • Para funções de função de trabalho não privilegiadas que podem gerenciar recursos de aplicativo do Azure, considere se você precisa de contas administrativas separadas ou use 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 participação no 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 a recursos, use grupos somente Microsoft Entra-somente para recursos do plano de controle do Azure. Os usuários e grupos somente Entra, e aqueles sincronizados no local usando o Microsoft Entra Connect, podem ser adicionados a um grupo somente Entra. Adicione grupos locais ao grupo somente Microsoft Entra, se um sistema de gerenciamento de grupo já estiver em vigor. O uso de grupos somente Entra-ajuda a proteger o plano de controle de nuvem contra a modificação não autorizada 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 quebra-vidro, para evitar ser acidentalmente bloqueado fora da sua organização do Microsoft Entra ID. 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 de forma segura, 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 no Microsoft Entra ID.

Recomendações do Microsoft Entra ID

• Integre o Microsoft Entra ID com o Azure Monitor para que possa analisar a sua atividade de início de sessão e o registo de auditoria das alterações no seu inquilino. Configure uma configuração de diagnóstico para enviar logs de entrada e logs de auditoria para o espaço de trabalho central do Azure Monitor Logs da plataforma na assinatura de gerenciamento.

• Use o recurso de gerenciamento de direitos do Microsoft Entra ID Governance 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 privilegiados do grupo.

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

  Função	Description	Nota
  Administrador Global	Gerencia todos os aspetos 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 esta função.
  Administrador de identidade híbrida	Gerencia o provisionamento de nuvem do Ative Directory para o Microsoft Entra ID 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 logon único (SSO) 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 da Aplicação	Cria e gerencia todos os aspetos de registros de aplicativos e aplicativos corporativos.	Não é possível 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ário 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 só possam gerenciar 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, onde 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 a todo o locatário do Microsoft Entra ID.

• Use unidades administrativas de gestão restritas para fornecer mais proteção. Impeça 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 qualquer pessoa modifique uma conta de usuário específica, até mesmo usuários com a função de Administrador de Usuário. 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 impedir 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 aterrissagem de aplicativos. 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 aterrissagem de aplicativos. Esta abordagem também simplifica o processo de transferência de recursos entre zonas de desembarque.

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

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

Funções incorporadas

• Considere se as funções incorporadas são adequadas às suas necessidades. Em muitos casos, você pode atribuir várias funções internas a um grupo de segurança para fornecer o acesso apropriado para um usuário. Mas, às vezes, você não pode usar funções internas e também cumprir com o acesso de 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 aterrissagem do Azure inclui várias funções personalizadas para funções administrativas comuns. Você pode usar essas funções ao lado de funções internas do Azure. A tabela a seguir descreve as funções ou áreas administrativas personalizadas para o acelerador de zona de aterrissagem do Azure:

  Função ou área administrativa	Description	Ações	NotActions
  Proprietário da Plataforma Azure (como a função de Proprietário incorporada)	Gerencia grupos de gerenciamento e ciclos de vida de assinatura	*
  Proprietário da Subscrição	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 do 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
  Gestão de redes (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 vista horizontal em todo o património do Azure e na política de limpeza do Cofre da Chave	*/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 a criação de emparelhamento entre hubs e seus porta-vozes.

Atribuições de funções e grupos

• Quando a equipe da plataforma provisiona uma zona de aterrissagem de 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 aterrissagem no escopo da assinatura ou do grupo de recursos. As atribuições de Política do Azure ocorrem no escopo do grupo de gerenciamento, portanto, você deve provisionar atribuições de função de zona de aterrissagem em um escopo mais baixo. Use essa abordagem para garantir que os administradores da zona de aterrissagem tenham total autonomia sobre seus recursos, mas não possam modificar as atribuições da Política do Azure que regem sua zona de aterrissagem.

• Cada zona de aterrissagem de 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 pouso. Essa abordagem pode levar a erros de configuração e violações de segurança, e é difícil de gerenciar em escala. Se um usuário precisar de acesso a várias zonas de pouso, atribua-as aos grupos apropriados em cada zona de pouso. 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 entram ou saem da sua organização. Também ajuda a garantir que os usuários tenham as permissões corretas quando se movem entre equipes. Por exemplo, se um usuário mudar 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 mudar 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 pouso 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 necessitar de acesso a várias zonas de desembarque, deve atribuí-las aos grupos apropriados em cada zona de desembarque.

• Considere se os administradores de plataforma exigem permissões em zonas de aterrissagem de aplicativos. Em caso afirmativo, use o Microsoft Entra PIM para controlar o acesso a esses recursos e atribuir as permissões com privilégios mínimos necessários. Por exemplo, um administrador de plataforma pode precisar de acesso a uma zona de aterrissagem 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 privilegiada 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 aterrissagem de aplicativos contra erros de configuração acidentais ou mal-intencionados.

• Ao delegar a 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 de Usuário ou a função de Administrador 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ções mais privilegiadas exigem escalonamento para a equipe da plataforma. Considere os seguintes fatores ao usar condições para delegar funções RBAC:

  • Analise 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 aterrissagem do Azure fornece. Essas condições podem restringir os tipos principais aos quais eles podem atribuir funções ou limitar funções específicas que eles podem atribuir.

  • Siga o PoLP quando adicionar condições às atribuições de função. Por exemplo, limite os delegados 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 de 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.

    

  • Analise 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 aterrissagem do Azure. Proporciona um equilíbrio entre segurança e facilidade de administração. Você pode adaptar a estrutura para atender aos requisitos 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 pouso específica.

  Recurso	User	Atribuição de função	Destino da atribuição	Âmbito de atribuição
  Aplicação X zona de aterragem	Proprietários de aplicativos X	Proprietário do aplicativo (personalizado, incluído no acelerador de zona de aterrissagem do Azure)	Application X Admins grupo de segurança	Produção de aplicativos X e assinaturas de desenvolvimento/teste
  Aplicação X zona de aterragem	Proprietários de aplicativos X	Administrador de Acesso ao Aplicativo (personalizado, com condições de atribuição de função para gerenciar o acesso ao seu próprio aplicativo)	Application X Admins grupo de segurança	Produção de aplicativos X e assinaturas de desenvolvimento/teste
  Aplicação X zona de aterragem	Administrador de dados do aplicativo X	Administrador de dados (personalizado, com permissões sobre os recursos de dados necessários)	Application X Data Team grupo de segurança	Produção de aplicativos X e assinaturas de desenvolvimento/teste
  Zona de aterragem da aplicação Y	Proprietários do aplicativo Y	Proprietário do aplicativo (personalizado, incluído no acelerador de zona de aterrissagem do Azure)	Application Y Admins grupo de segurança	Produção de aplicativos Y e assinaturas de desenvolvimento/teste
  Zona de aterragem da aplicação Y	Equipe de testes do aplicativo Y	Test Contributor (personalizado, com permissões necessárias para testes de aplicativos)	Application Y Test Team grupo de segurança	Subscrição de desenvolvimento/teste da Aplicação Y
  Sandbox	Equipe de desenvolvimento do aplicativo Z	Proprietário (incorporado)	Application Z developers grupo de segurança	Grupos de recursos do aplicativo Z na assinatura de área restrita
  Recursos da plataforma	Equipa de gestão da plataforma	Contribuidor (incorporado)	Platform Admins Grupo PIM	Platform Grupo de Gestão
  Zonas de aterragem da plataforma	Equipa de gestão da plataforma	Leitor (incorporado)	Platform Team grupo de segurança	Grupo de gestão de topo organizacional
  Em todo o inquilino	Equipa de segurança	Operações de Segurança (personalizadas, incluídas no acelerador de zona de aterrissagem do Azure)	Security Ops grupo de segurança	Grupo de gestão de topo organizacional
  Em todo o inquilino	Equipa de segurança	Administrador de Acesso Condicional (incorporado, com ações protegidas ativadas)	Security administrators grupo de segurança	Locatário do Microsoft Entra ID
  Em todo o inquilino	Equipa da rede	Operações de rede (Personalizadas, incluídas no acelerador de zona de aterrissagem do Azure)	Network Ops grupo de segurança	Todas as subscrições
  Em todo o inquilino	Equipa FinOps	Leitor de faturação (incorporado)	FinOps Team grupo de segurança	Grupo de gestão de topo organizacional

• As atribuições de Política do Azure 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 ao sistema como parte do processo de atribuição da Política do Azure, 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 o 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 oferecem 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 do Microsoft Entra PIM

• Use o Microsoft Entra PIM para estar em conformidade com o modelo Zero Trust e o acesso de 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 Microsoft Entra PIM 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 elevado ou para pipelines de implantação privilegiados. Você pode usar as mesmas ferramentas e políticas para governar fluxos de trabalho automatizados que acessam limites críticos de segurança que você usa para governar 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 um proprietário de aplicativo de escalar seus próprios privilégios.

• Controle funções RBAC do Azure altamente privilegiadas, como Administradores de Proprietário ou Acesso de Usuário atribuídos a membros da equipe da plataforma ou da zona de aterrissagem de aplicativos em uma assinatura ou grupo de gerenciamento. Use o Microsoft Entra PIM para grupos para configurar funções do Azure RBAC 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 rotineiramente exigir acesso administrativo limitado a recursos em uma zona de aterrissagem de 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 menor privilégio 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. No Microsoft Entra ID, 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 satisfazer as 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 satisfaçam a política de MFA resistente a phishing.

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

O gerenciamento de identidade e acesso são os principais recursos da implementação do acelerador de zona de aterrissagem do Azure. A implantação inclui uma assinatura dedicada à identidade, na qual as organizações podem implantar controladores de domínio 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 com o Microsoft Entra ID.

A assinatura de identidade tem uma rede virtual emparelhada à 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 de aplicativos 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 aterrissagem do Azure também inclui opções para:

• Atribua políticas recomendadas para governar controladores de identidade e domínio.
• Crie uma rede virtual e conecte-se ao hub por meio do emparelhamento de rede virtual.

Próximos passos