Gerenciar ambientes de desenvolvimento de aplicativos nas zonas de aterrissagem do Azure

Artigo
12/13/2023

Este artigo descreve como as equipes de plataforma de nuvem podem implementar guardrails para gerenciar ambientes de aplicativos em zonas de aterrissagem do Azure. Ele também explica como alinhar vários ambientes de desenvolvimento de aplicativos com sua estrutura. Um aspecto fundamental na criação do ambiente adequado é colocar assinaturas nos grupos de gerenciamento apropriados.

Estabeleça a base

As equipes de desenvolvimento exigem a capacidade de iterar rapidamente, e as equipes de governança e plataforma de nuvem precisam gerenciar o risco organizacional, a conformidade e a segurança em escala. Você pode gerenciar adequadamente os ambientes de aplicativos concentrando-se em dois princípios principais de design da zona de aterrissagem do Azure: governança orientada por políticas e democratização de assinaturas. Esses princípios fornecem grades de proteção fundamentais e descrevem como delegar controles às equipes de aplicativos. As equipes de aplicativos usam a orientação do Azure Well-Architected Framework para projetar sua carga de trabalho. Eles implantam e gerenciam seus próprios recursos da zona de aterrissagem, e a equipe da plataforma controla os recursos atribuindo políticas do Azure.

É importante fornecer recursos de área restrita para recursos semi-governados, para que as equipes de aplicativos possam experimentar tecnologias e recursos.

Quando os proprietários de aplicativos usam vending de assinatura ou outros processos de criação de assinatura, eles devem saber como solicitar assinaturas para vários ambientes de desenvolvimento.

Este artigo descreve a zona de aterrissagem do Azure, incluindo os grupos de gerenciamento, as políticas e a arquitetura de plataforma compartilhada e a carga de trabalho ou a zona de aterrissagem do aplicativo.

Observação

A orientação neste artigo é apenas para zonas de aterrissagem de carga de trabalho ou aplicativo. Para testes e segregação de ambiente para a própria plataforma de zona de aterrissagem do Azure, consulte Abordagem de teste para zonas de aterrissagem do Azure, que descreve a abordagem canária.

Na prática, você pode usar qualquer número e tipo de ambiente em fases. Este artigo faz referência aos seguintes ambientes em fases.

Environment	Descrição	Grupo de gerenciamento
Área restrita	O ambiente que é usado para inovação rápida de protótipos, mas não configurações ligadas à produção	Grupo de gerenciamento de área restrita
Desenvolvimento	O ambiente usado para criar candidatos a lançamento em potencial	Grupo de gerenciamento de arquétipos, como corp ou online
Test	O ambiente usado para executar testes, incluindo testes de unidade, testes de aceitação do usuário e testes de garantia de qualidade	Grupo de gerenciamento de arquétipos, como corp ou online
Produção	O ambiente usado para agregar valor aos clientes	Grupo de gerenciamento de arquétipos, como corp ou online

Para obter mais informações, consulte os vídeos Manipulando ambientes de desenvolvimento, teste e produção para cargas de trabalho de aplicativos e Quantas assinaturas devo usar no Azure?

Ambientes, assinaturas e grupos de gerenciamento

Como pré-requisito para esta seção, consulte Área de design da organização de recursos.

Você deve organizar corretamente suas assinaturas ao adotar as práticas de zona de aterrissagem do Azure. Idealmente, cada ambiente de aplicativo deve ter sua própria assinatura. Esse método fornece controles de segurança e diretiva que mantêm os ambientes isolados. Ele contém problemas potenciais para um ambiente.

Assinaturas separadas têm as mesmas políticas no nível do arquétipo. Se necessário, os proprietários de aplicativos podem atribuir políticas específicas de assinatura para impor o comportamento específico do aplicativo e do ambiente.

Algumas arquiteturas de aplicativos exigem que os serviços sejam compartilhados entre ambientes. Se esse for o caso, você pode usar uma única assinatura para vários ambientes. Recomendamos que os proprietários de carga de trabalho trabalhem com equipes de plataforma de nuvem para determinar se uma única assinatura para vários ambientes é necessária.

Use uma única assinatura para vários ambientes de aplicativos se:

Os ambientes não podem ser isolados em suas próprias assinaturas.
Os ambientes têm as mesmas equipes atribuídas a funções funcionais, como operadores de rede.
Os ambientes podem usar as mesmas políticas.

Se uma carga de trabalho de aplicativo ou serviço precisar estar em uma única assinatura e você precisar fazer alterações nas políticas que se aplicam a cada ambiente, você poderá:

Crie um novo grupo de gerenciamento alinhado ao arquétipo abaixo do grupo de gerenciamento de zonas de pouso. Para obter mais informações, consulte Hierarquia do grupo de gerenciamento neste artigo.
Use assinaturas de áreas privadas para atividades de desenvolvimento. As áreas restritas têm um conjunto de políticas menos restritivo.
Use políticas aplicadas no nível de assinatura em vez do nível do grupo de gerenciamento. Você pode adicionar marcas nas definições de política para ajudar a filtrar e aplicar políticas ao ambiente correto. Você também pode atribuir políticas ou excluí-las de grupos de recursos específicos.

Você pode atribuir políticas durante o processo de criação de assinatura como parte do vending de assinatura.

Para políticas que você implementa para ajudar a controlar os custos, aplique a definição de política em um nível de assinatura quando necessário. Ou você pode responsabilizar o proprietário da zona de pouso pelos custos, o que proporciona verdadeira autonomia. Para obter mais informações, consulte Automação de plataforma e DevOps.

Aviso

Ao contrário das políticas e controles no nível do grupo de gerenciamento, as políticas e marcas baseadas em assinatura podem ser alteradas por indivíduos com permissões elevadas para a assinatura. Os administradores com funções apropriadas podem ignorar esses controles excluindo políticas, modificando políticas ou alterando as marcas nos recursos.

Como resultado, você não deve aplicar marcas nas definições de políticas focadas em segurança. Além disso, não atribua permissões como sempre ativas para as seguintes ações:

Microsoft.Authorization/policyAssignments/*
Microsoft.Authorization/policyDefinitions/*
Microsoft.Authorization/policyExemptions/*
Microsoft.Authorization/policySetDefinitions/*

Você pode controlar essas ações usando o PIM (Gerenciamento de Identidades Privilegiadas).

Hierarquia do grupo de gerenciamento

Evite hierarquias complicadas do grupo de gerenciamento. Eles podem exigir alterações frequentes, dimensionar de forma ineficiente e não ter valor. Para evitar esses possíveis problemas, os grupos de gerenciamento de zona de aterrissagem do Azure são alinhados ao arquétipo da carga de trabalho. Para obter mais informações, confira Grupo de gerenciamento e organização de assinatura.

Alinhado a arquétipos significa que os grupos de gerenciamento são criados apenas para arquétipos de carga de trabalho específicos. Por exemplo, na arquitetura conceitual, o grupo de gerenciamento de zonas de aterrissagem tem grupos de gerenciamento de filhos corporativos e online . Esses grupos de gerenciamento infantil se alinham com padrões de arquétipo distintos para as cargas de trabalho que possuem. Os grupos de gerenciamento filho se concentram nos requisitos de conectividade híbrida (VPN/Azure ExpressRoute), como somente aplicativos e serviços internos versus públicos.

Excluindo ambientes de área restrita, vários ambientes de aplicativos devem usar o mesmo arquétipo para implantação. Mesmo que os ambientes sejam divididos em várias assinaturas, eles são mantidos no mesmo grupo de gerenciamento único (corporativo ou online), com base no arquétipo do grupo de gerenciamento e nos requisitos.

Você pode usar assinaturas de área restrita para desenvolvimento não estruturado, como laboratórios pessoais ou para uma carga de trabalho que não tenha um arquétipo. Uma equipe de carga de trabalho de aplicativo ou serviço usa um grupo de gerenciamento de área restrita para testar vários serviços do Azure para determinar o que funciona melhor para seus requisitos. Depois de decidirem sobre os serviços, eles podem provisionar uma zona de pouso (no grupo de gerenciamento alinhado ao arquétipo de carga de trabalho correto na hierarquia do grupo de gerenciamento de zonas de aterrissagem) para a equipe.

Os ambientes de área restrita podem ser usados para aplicativos específicos ou uma equipe de carga de trabalho pode usá-los para experimentação.

Para saber mais, veja:

Grupos de gestão.
Área de design de organização de recursos.
Personalize a arquitetura da zona de aterrissagem do Azure para atender aos requisitos.

Desafios do grupo de gerenciamento baseado em ambiente

Grupos de gerenciamento para ambientes dentro de arquétipos podem adicionar sobrecarga de gerenciamento e fornecer valor mínimo.

O grupo de gerenciamento de zonas de desembarque deve ter políticas universais que imponham grades de proteção para grupos de gerenciamento de crianças corporativos e online . A Corp e o online têm políticas exclusivas que impõem as diretrizes da empresa relacionadas a cargas de trabalho públicas e privadas.

Muitas organizações criam grupos de gerenciamento separados para ambientes de ciclo de vida de desenvolvimento de software (SDLC) de carga de trabalho para atribuir políticas e controles ambientais. Na prática, esse método cria mais desafios para as equipes de carga de trabalho do que resolve. Os ambientes SDLC não devem ter políticas diferentes, portanto, não recomendamos grupos de gerenciamento separados.

Os proprietários de aplicativos podem alterar a topologia ou a configuração de recursos de uma carga de trabalho para se alinhar às políticas em vários ambientes SDLC por meio dos quais ela é promovida. Este método aumenta o risco. Regras específicas para cada ambiente podem resultar em uma experiência de desenvolvimento ruim para as equipes de desenvolvimento e garantia de qualidade. Problemas também podem surgir se um aplicativo tiver um conjunto de diretivas de guardrail que funcionam em um ambiente e o aplicativo for exposto a um conjunto diferente de políticas posteriormente em seu ciclo de promoção. Talvez seja necessário fazer ajustes em um aplicativo se os controles forem alterados.

Para evitar esse trabalho extra, crie políticas consistentes em toda a promoção de código em ambientes SDLC. Você não deve criar políticas para cada ambiente, mas fornecer um conjunto consistente para todos os ambientes de desenvolvimento, excluindo ambientes de área restrita.

Por exemplo, imagine que uma organização defina uma política que exija que as contas de armazenamento sejam configuradas com regras de firewall específicas para impedir a entrada de redes públicas. Em vez disso, as contas de armazenamento usam pontos de extremidade privados dentro das redes de zona de aterrissagem do Azure para comunicação. Se o ambiente de desenvolvimento não tiver essa política, o teste da carga de trabalho não encontrará uma configuração incorreta da conta de armazenamento que permita acesso público. As implantações de teste funcionam no ambiente de desenvolvimento e são iteradas. Quando a solução é promovida para outro ambiente que tenha a política de conta de armazenamento, a implantação falha devido à política imposta.

Como resultado, a equipe de desenvolvimento de aplicativos deve retrabalhar sua implantação e arquitetura, depois de já ter investido esforços significativos. Este exemplo demonstra como políticas diferentes em vários ambientes podem criar problemas.

Observação

A equação a seguir demonstra por que um grupo de gerenciamento separado para cada ambiente ou carga de trabalho não é bem dimensionado: N cargas de trabalho x Z grupos de gerenciamento = total de grupos de gerenciamento.

Se uma organização tiver 30 cargas de trabalho que exigem um grupo de gerenciamento e um grupo de gerenciamento filho para ambientes de desenvolvimento, teste e produção, a organização ficará com:

N = o número de cargas de trabalho/aplicativos = 30

Z = o número de grupos de gerenciamento para a carga de trabalho e ambientes (1 para a carga de trabalho + 3 para os ambientes) = 4

N (30) x Z (4) = 120 grupos de gestão total

Os proprietários de aplicativos podem precisar que as políticas sejam aplicadas de forma diferente a vários ambientes. Por exemplo, os proprietários de aplicativos podem exigir configurações de backup para ambientes de produção, mas não para outros ambientes.

Algumas políticas podem ser habilitadas como políticas de auditoria no nível do grupo de gerenciamento. As equipes de aplicativo determinam como implementar o controle. Esse método não impede implantações, mas cria conscientização e permite que as equipes de aplicativos gerenciem suas necessidades exclusivas. Eles podem então criar políticas de subnível ou incorporar esses requisitos em sua infraestrutura como módulos de implantação de código (IaC).

Nesse modelo de responsabilidade compartilhada, a equipe da plataforma audita as práticas e a equipe do aplicativo gerencia a implementação. Esse modelo pode melhorar a agilidade das implantações.

Os operadores da plataforma devem trabalhar com cada equipe de carga de trabalho de aplicativo ou serviço (proprietários da zona de pouso) para entender seus requisitos. As operadoras da plataforma podem fornecer assinaturas com base nos requisitos e planos do aplicativo. Os operadores da plataforma também podem decidir designar linhas de produtos para vários tipos de cargas de trabalho para que possam criar processos de criação de assinatura e ferramentas com base em requisitos comuns de equipes de carga de trabalho de aplicativos ou serviços.

Cenário: cargas de trabalho baseadas em máquina virtual (VM)

As cargas de trabalho iniciais nas zonas de aterrissagem do Azure geralmente são compostas por VMs do Azure. Você pode implantar essas cargas de trabalho no Azure ou migrá-las de datacenters existentes.

Em vez de implantar VMs em vários ambientes em uma única assinatura, você pode:

Estabeleça assinaturas para cada ambiente de aplicativo e coloque-as todas no mesmo grupo de gerenciamento de arquétipo.
Implante uma rede virtual para cada ambiente de aplicativo na assinatura apropriada. Você pode determinar o tamanho da rede virtual com base no tamanho do ambiente do aplicativo.
Implante as VMs em sua assinatura apropriada. As VMs podem usar SKUs diferentes e configurações de disponibilidade diferentes para cada ambiente, se apropriado.

Vários recursos de ambiente de aplicativo são protegidos por diferentes controles de acesso. Como resultado, quando os desenvolvedores de aplicativos configuram pipelines de implantação, a identidade de cada pipeline pode ser limitada ao ambiente. Essa configuração ajuda a proteger os ambientes contra implantações acidentais.

Cenário: Serviço de Aplicativo do Azure

Uma carga de trabalho com assinaturas ambientais que usam o Serviço de Aplicativo pode criar desafios. Para desenvolvedores de aplicativos, uma prática recomendada do Serviço de Aplicativo é usar slots de implantação para ajudar a gerenciar alterações e atualizações em um aplicativo Web.

No entanto, esse recurso só pode ser usado com o aplicativo que está no plano do Serviço de Aplicativo, que só pode viver em uma única assinatura. Se os operadores de plataforma exigirem que os proprietários de aplicativos usem assinaturas separadas para ambientes de desenvolvimento, teste e produção, o ciclo de vida de implantação do aplicativo poderá ser mais difícil de gerenciar.

Para este exemplo, a melhor opção é uma única assinatura para a carga de trabalho do aplicativo ou serviço. Os proprietários de aplicativos podem usar o RBAC (controle de acesso baseado em função) do Azure com o PIM no nível do grupo de recursos para aumentar a segurança.

Compartilhar via