Entender os escopos de implantação

  • 6 minutos

Máquinas virtuais, servidores lógicos do SQL do Azure e bancos de dados, 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 implantados de uma maneira diferente. Esses recursos são normalmente usados para controlar o comportamento do ambiente do Azure.

Nesta unidade, você examinará a hierarquia da organização de recursos do Azure e examinará 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:

Diagrama mostrando um locatário do Azure, três grupos de gerenciamento, três assinaturas e quatro grupos de recursos.

Seu locatário corresponde à instância do seu Microsoft Entra. Uma organização normalmente tem apenas uma instância do Microsoft Entra. Essa 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 sobre os locais de seus recursos.

As Assinaturas atuam como contas de cobrança e contêm grupos de recursos e recursos. Assim como os grupos de gerenciamento, as assinaturas não têm local e não restringem onde seus recursos são implantados.

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 acompanhar 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 destino, que é um conjunto de recursos e configuração do Azure que você precisa para começar a usar um ambiente do Azure de produção. A zona de destino em escala empresarial é uma abordagem comprovada para usar grupos de gerenciamento e assinaturas para gerenciar efetivamente seus recursos do Azure:

Diagrama de uma arquitetura de zona de destino em escala empresarial, com quatro grupos de gerenciamento e quatro assinaturas.

Seja qual for o modelo a seguir, compreendendo 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.

Observação

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 nos grupos de recursos, por isso, vamos ver 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 em uma assinatura. Por exemplo, se o 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.
  • Você está usando o Azure Policy e deseja definir ou aplicar uma política a todos os recursos dentro da assinatura. Por exemplo, o departamento de P e D da sua empresa de brinquedos pediu para você implantar uma política que restringe a lista de SKUs da máquina virtual que podem ser criadas na assinatura da equipe.

Recursos com escopo de grupo de gerenciamento

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

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

    Cuidado

    Tenha muito cuidado ao conceder acesso aos 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 de gerenciamento e autenticação de identidade e que ela siga o princípio de privilégios mínimos; ou seja, não conceda nenhum acesso que não seja necessário.

  • Você precisa aplicar políticas em toda a sua 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 grupo de gerenciamento raiz que bloqueará a criação de recursos nessa região.

Observação

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 no seu locatário quando:

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

    Observação

    Nem todos os clientes do Azure podem criar assinaturas usando a infraestrutura como código. Dependendo da relação de cobrança com a Microsoft, isso pode não ser possível. Para obter mais informações, confira Criar assinaturas do Azure de modo programático.

  • Você está criando ou configurando grupos de gerenciamento. O Azure cria um único grupo de gerenciamento raiz ao habilitar grupos de gerenciamento para seu locatário e você 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, não é preciso enviar implantações com escopo de locatário. Em vez disso, é mais simples implantar recursos com escopo de locatário usando um modelo em outro escopo. Você verá como fazer isso mais tarde neste módulo.

    Dica

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

IDs do recurso

Agora, você já está familiarizado com IDs de recursos para recursos que residem 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/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment

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

Captura de tela de uma ID de recurso para um grupo de recursos.

As assinaturas têm seus próprios IDs, como este:

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e

Observação

Embora as assinaturas sejam consideradas filhos de grupos de gerenciamento, as IDs de recurso não incluem uma ID do grupo de gerenciamento. O Azure controla a relação entre assinaturas e grupos de gerenciamento de uma maneira diferente de outras relações de recursos. Isso oferece a flexibilidade para mover assinaturas entre grupos de gerenciamento sem precisar alterar todas as IDs de recurso.

Quando você trabalha com recursos em um grupo de gerenciamento ou um escopo de locatário, as IDs do recurso 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

Aqui está como isso se parece:

Captura de tela de uma ID de recurso para um grupo de gerenciamento.

Observação

Os grupos de gerenciamento têm um identificador e um nome de exibição. O nome de exibição é uma descrição legível por humanos do grupo de gerenciamento. Você pode alterar o nome de 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 nível de grupo de gerenciamento.

/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

Aqui está uma representação visual da mesma ID:

Captura de tela de um Resource ID para uma definição de função implantada no escopo de um grupo de gerenciamento.

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

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

Aqui está uma representação visual da mesma ID:

Captura de tela de uma ID do recurso para uma definição de função implantada no escopo de uma assinatura.

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á a criar arquivos Bicep direcionados a cada um desses escopos.