Compreender os escopos de implantação

Concluído

Máquinas virtuais, servidores lógicos e bancos de dados SQL do Azure, contas de armazenamento, redes virtuais e a maioria dos outros recursos do Azure precisam ser colocados em um grupo de recursos. No entanto, alguns recursos podem ou devem ser utilizados de forma diferente. Esses recursos são normalmente usados para controlar o comportamento do seu ambiente do Azure.

Nesta unidade, você analisará a hierarquia de organização de recursos do Azure e verá como determinados recursos podem ser implantados em vários escopos.

A hierarquia de recursos do Azure

O Azure tem uma estrutura de recursos hierárquica com vários níveis de gerenciamento. Aqui está um diagrama mostrando como sua empresa de brinquedos pode organizar seu ambiente do Azure:

Diagram showing an Azure tenant, three management groups, three subscriptions, and four resource groups.

Seu locatário corresponde à sua instância do Microsoft Entra. Uma organização normalmente tem apenas uma instância do Microsoft Entra. Esta instância atua como a raiz da hierarquia de recursos.

Os grupos de gerenciamento fornecem uma maneira de organizar assinaturas do Azure. Cada locatário tem um único grupo de gerenciamento raiz e você pode estabelecer sua própria hierarquia de grupos de gerenciamento sob ele. Você pode criar grupos de gerenciamento separados para as várias partes da sua organização ou para assinaturas que tenham seus próprios requisitos de segurança ou governança. Você pode aplicar restrições de política e controle de acesso a grupos de gerenciamento, e todas as assinaturas abaixo desse grupo de gerenciamento na hierarquia herdam essas restrições. Os grupos de gerenciamento não são implantados em regiões e não têm impacto nos locais dos recursos.

As subscrições funcionam como contas de faturação e contêm grupos de recursos e recursos. Tal como os grupos de gestão, as subscrições não têm localização e não restringem o local onde os seus recursos são implementados.

Os grupos de recursos são contêineres lógicos para seus recursos. Com grupos de recursos, você pode gerenciar e controlar recursos relacionados como uma única unidade. Recursos como máquinas virtuais, planos do Serviço de Aplicativo do Azure, contas de armazenamento e redes virtuais devem ser colocados em um grupo de recursos. Os grupos de recursos são criados em um local para que o Azure possa rastrear os metadados dos recursos no grupo, mas os recursos dentro do grupo podem ser implantados em outros locais.

O exemplo ilustrado anteriormente é um cenário bastante básico que mostra como você pode usar grupos de gerenciamento. Sua organização também pode considerar a implementação de uma zona de aterrissagem, que é um conjunto de recursos e configurações do Azure que você precisa para começar a usar um ambiente do Azure de produção. A zona de aterrissagem em escala empresarial é uma abordagem comprovada para usar grupos de gerenciamento e assinaturas para gerenciar com eficiência seus recursos do Azure:

Diagram of an enterprise-scale landing-zone architecture, with four management groups and four subscriptions.

Seja qual for o modelo que você seguir, entendendo os vários níveis da hierarquia, você pode começar a aplicar controles flexíveis sobre como seu ambiente do Azure é usado e gerenciado. Usando o Bicep, você pode gerenciar esses controles com todos os benefícios da infraestrutura como código.

Nota

Há também alguns outros recursos que são implantados em escopos específicos. Os recursos de extensão são implantados no escopo de outro recurso do Azure. Por exemplo, um bloqueio de recurso é um recurso de extensão, que é implantado em um recurso como uma conta de armazenamento.

Você já está familiarizado com a implantação de recursos em grupos de recursos, então vamos examinar os outros escopos para implantação.

Recursos com escopo de assinatura

Você pode implantar recursos em uma assinatura quando:

  • Você precisa criar um novo grupo de recursos. Um grupo de recursos é, na verdade, apenas um recurso com escopo de assinatura.
  • Você precisa conceder acesso a todos os recursos dentro de uma assinatura. Por exemplo, se o seu departamento de RH tiver uma assinatura do Azure que contenha todos os recursos do Azure do departamento, você poderá criar atribuições de função para permitir que todos no departamento de RH leiam o conteúdo da assinatura.
  • Está a utilizar a Política do Azure e pretende definir ou aplicar uma política a todos os recursos da subscrição. Por exemplo, o departamento de pesquisa e desenvolvimento da sua empresa de brinquedos pediu que você implantasse uma política que restrinja a lista de SKUs de máquinas virtuais que podem ser criadas dentro da assinatura da equipe.

Recursos com escopo de grupo de gerenciamento

Você pode implantar recursos em um grupo de gerenciamento quando:

  • Você precisa conceder acesso a todos os recursos dentro de quaisquer assinaturas que se enquadrem na hierarquia do grupo de gerenciamento. Por exemplo, sua equipe de operações na nuvem pode precisar de acesso a todas as assinaturas em sua organização. Você pode criar uma atribuição de função em seu grupo de gerenciamento raiz, que concede à sua equipe de operações na nuvem acesso a tudo no Azure.

    Atenção

    Tenha muito cuidado ao conceder acesso a recursos usando grupos de gerenciamento e, especialmente, o grupo de gerenciamento raiz. Lembre-se de que cada recurso sob o grupo de gerenciamento na hierarquia herda a atribuição de função. Certifique-se de que sua organização siga as práticas recomendadas para gerenciamento e autenticação de identidades e que siga o princípio de menor privilégio; ou seja, não conceda nenhum acesso que não seja necessário.

  • Você precisa aplicar políticas em toda a organização. Por exemplo, sua organização pode ter uma política de que os recursos não podem ser criados em determinadas regiões geográficas, em nenhuma circunstância. Você pode aplicar uma política ao seu grupo de gerenciamento raiz que bloqueará a criação de recursos nessa região.

Nota

Antes de usar grupos de gerenciamento pela primeira vez, configure-os para seu ambiente do Azure.

Recursos com escopo de locatário

Você pode implantar recursos em seu locatário quando:

  • Você precisa criar assinaturas do Azure. Quando você usa grupos de gerenciamento, as assinaturas ficam sob grupos de gerenciamento na hierarquia de recursos, mas uma assinatura é implantada como um recurso com escopo de locatário.

    Nota

    Nem todos os clientes do Azure podem criar assinaturas usando a infraestrutura como código. Dependendo da sua relação de cobrança com a Microsoft, isso pode não ser possível. Para obter mais informações, consulte Criar subscrições do Azure através de programação.

  • Você está criando ou configurando grupos de gerenciamento. O Azure cria um único grupo de gerenciamento raiz quando você habilita grupos de gerenciamento para seu locatário e pode criar vários níveis de grupos de gerenciamento sob ele. Você pode usar o Bicep para definir toda a hierarquia do grupo de gerenciamento. Você também pode atribuir assinaturas a grupos de gerenciamento.

    Com o Bicep, você pode enviar implantações para o escopo do locatário. As implantações com escopo de locatário exigem permissão especial. No entanto, na prática, você não precisa enviar implantações com escopo de locatário. Em vez disso, é mais simples implantar recursos com escopo de locatário usando um modelo em um escopo diferente. Você verá como fazer isso mais adiante neste módulo.

    Gorjeta

    Não é possível criar políticas ou atribuições de função no escopo do locatário. No entanto, se você precisar conceder acesso ou aplicar políticas em toda a organização, poderá implantar esses recursos no grupo de gerenciamento raiz.

IDs de recursos

No momento, você já está familiarizado com IDs de recursos para recursos que vivem dentro de assinaturas. Por exemplo, aqui está uma ID de recurso que representa um grupo de recursos, que é um recurso com escopo de assinatura:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/resourceGroups/ToyDevelopment

Aqui está uma representação visual das mesmas informações:

Screenshot of a Resource ID for a resource group.

As próprias subscrições têm os seus próprios IDs, como este:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c

Nota

Embora as assinaturas sejam consideradas filhas de grupos de gerenciamento, suas IDs de recursos não incluem uma ID de grupo de gerenciamento. O Azure controla a relação entre subscrições e grupos de gestão de uma forma diferente de outras relações de recursos. Isso lhe dá a flexibilidade de mover assinaturas entre grupos de gerenciamento sem precisar alterar todas as IDs de recursos.

Quando você está trabalhando com recursos em um grupo de gerenciamento ou escopo de locatário, as IDs de recursos podem parecer um pouco diferentes do normal. Eles seguem principalmente o padrão padrão de intercalar o tipo de recurso com as informações sobre seus recursos específicos. No entanto, o formato específico depende do recurso com o qual você está trabalhando.

Aqui está um exemplo de ID de recurso para um grupo de gerenciamento:

/providers/Microsoft.Management/managementGroups/ProductionMG

Veja como é:

Screenshot of a Resource ID for a management group.

Nota

Os grupos de gerenciamento têm um identificador e um nome para exibição. O nome para exibição é uma descrição legível por humanos do grupo de gerenciamento. Você pode alterar o nome para exibição sem afetar a ID do grupo de gerenciamento.

Quando um recurso é implantado em um escopo de grupo de gerenciamento, sua ID de recurso inclui a ID do grupo de gerenciamento. Aqui está um exemplo de ID de recurso para uma definição de função que foi criada em um escopo de grupo de gerenciamento:

/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca

Aqui está uma representação visual do mesmo ID:

Screenshot of a Resource ID for a role definition that's deployed at a management group scope.

Outra definição de função pode ser definida em um escopo de assinatura, portanto, sua ID de recurso parece um pouco diferente:

/subscriptions/f0750bbe-ea75-4ae5-b24d-a92ca601da2c/providers/Microsoft.Authorization/roleDefinitions/d79b8492-6f38-49f9-99e6-b2e667d4f3ca

Aqui está uma representação visual do mesmo ID:

Screenshot of a Resource ID for a role definition that's deployed at a subscription scope.

Agora que você entende a hierarquia de recursos do Azure e os tipos de recursos que você pode implantar em cada escopo, você pode tomar decisões sobre os escopos nos quais implantar seus recursos. Por exemplo, você pode fazer uma escolha informada sobre se deve criar uma definição de política no escopo de um grupo de recursos, assinatura ou grupo de gerenciamento. Na próxima unidade, você aprenderá como criar arquivos Bicep direcionados a cada um desses escopos.