Governança da infraestrutura do Azure DevTest Labs

Este artigo aborda o alinhamento e o gerenciamento de recursos para o DevTest Labs em sua organização.

Recursos

Alinhar recursos do DevTest Labs em uma assinatura do Azure

Antes de uma organização começar a usar o Azure para desenvolvimento geral de aplicativos, os planejadores de TI devem primeiro analisar como introduzir o recurso como parte de seu portfólio geral de serviços. Os domínios a rever devem dar resposta às seguintes preocupações:

• Como medir o custo associado ao ciclo de vida de desenvolvimento de aplicativos?
• Como a organização alinha a oferta de serviços proposta com a política de segurança corporativa?
• A segmentação é necessária para separar os ambientes de desenvolvimento e produção?
• Que controlos são introduzidos para facilitar a gestão, a estabilidade e o crescimento a longo prazo?

A primeira prática recomendada é revisar a taxonomia do Azure das organizações, onde as divisões entre assinaturas de produção e desenvolvimento são descritas. No diagrama a seguir, a taxonomia sugerida permite uma separação lógica dos ambientes de desenvolvimento/teste e produção. Com essa abordagem, uma organização pode introduzir códigos de faturamento para controlar os custos associados a cada ambiente separadamente. Para obter mais informações, consulte Governança de assinatura prescritiva. Além disso, você pode usar marcas do Azure para organizar recursos para fins de acompanhamento e cobrança.

A segunda prática recomendada é habilitar a assinatura DevTest no portal do Azure Enterprise. Ele permite que uma organização execute sistemas operacionais cliente que normalmente não estão disponíveis em uma assinatura corporativa do Azure. Em seguida, use um software empresarial onde você paga apenas pela computação e não se preocupe com o licenciamento. Ele garante que a cobrança de serviços designados, incluindo imagens de galeria em IaaS, como o Microsoft SQL Server, seja baseada apenas no consumo. Detalhes sobre a assinatura do Azure DevTest podem ser encontrados aqui para clientes do Enterprise Agreement (EA) e aqui para clientes do Pay as you Go.

Este modelo fornece a uma organização a flexibilidade para implantar o Azure DevTest Labs em escala. Uma organização pode oferecer suporte a centenas de laboratórios para várias unidades de negócios com 100 a 1000 máquinas virtuais em execução paralela. Ele promove a noção de uma solução de laboratório empresarial centralizada que pode compartilhar os mesmos princípios de gerenciamento de configuração e controles de segurança.

Esse modelo também garante que a organização não esgote seus limites de recursos associados à sua assinatura do Azure. Para obter detalhes sobre limites de assinatura e serviço, consulte Limites de assinatura e serviço, cotas e restrições do Azure. O processo de provisionamento do DevTest Labs pode consumir um grande número de grupos de recursos. Você pode solicitar que os limites sejam aumentados por meio de uma solicitação de suporte na assinatura do Azure DevTest. Os recursos dentro da assinatura de produção não são afetados à medida que a assinatura de desenvolvimento cresce em uso. Para obter mais informações sobre como dimensionar o DevTest Labs, consulte Dimensionar cotas e limites no DevTest Labs.

Um limite comum de nível de assinatura que precisa ser contabilizado é como as atribuições de intervalo IP de rede são alocadas para dar suporte a assinaturas de produção e desenvolvimento. Essas atribuições devem levar em conta o crescimento ao longo do tempo (assumindo conectividade local ou outra topologia de rede que exija que a empresa gerencie sua pilha de rede em vez de usar como padrão a implementação do Azure). A prática recomendada é ter algumas redes virtuais que tenham um prefixo de endereço IP grande atribuído e dividido com muitas sub-redes grandes, em vez de ter várias redes virtuais com sub-redes pequenas. Por exemplo, com 10 assinaturas, você pode definir 10 redes virtuais (uma para cada assinatura). Todos os laboratórios que não exigem isolamento podem compartilhar a mesma sub-rede na rede virtual da assinatura.

Número de usuários por laboratório e laboratórios por organização

Unidades de negócios e grupos de desenvolvimento associados ao mesmo projeto de desenvolvimento devem estar associados ao mesmo laboratório. Ele permite que os mesmos tipos de políticas, imagens e políticas de desligamento sejam aplicados a ambos os grupos.

Também pode ser necessário considerar os limites geográficos. Por exemplo, desenvolvedores no nordeste dos Estados Unidos (EUA) podem usar um laboratório provisionado no leste dos EUA2. E, desenvolvedores em Dallas, Texas, e Denver, Colorado podem ser direcionados para usar um recurso no US South Central. Se houver um esforço colaborativo com um terceiro externo, eles podem ser atribuídos a um laboratório que não é usado por desenvolvedores internos.

Você também pode usar um laboratório para um projeto específico dentro dos Projetos de DevOps do Azure. Em seguida, você aplica a segurança por meio de um grupo especificado do Microsoft Entra, que permite o acesso a ambos os conjuntos de recursos. A rede virtual atribuída ao laboratório pode ser outro limite para consolidar usuários.

Impedir a supressão de recursos

Defina permissões no nível de laboratório para que apenas usuários autorizados possam excluir recursos ou alterar políticas de laboratório. Os desenvolvedores devem ser colocados dentro do grupo Usuários do DevTest Labs. O desenvolvedor principal ou o líder de infraestrutura deve ser o proprietário do DevTest Labs. Recomendamos que você tenha apenas dois proprietários de laboratório. Essa política se estende ao repositório de código para evitar corrupção. Os usos de laboratório têm direitos para usar recursos, mas não podem atualizar as políticas de laboratório. Consulte o seguinte artigo que lista as funções e os direitos que cada grupo interno tem em um laboratório: Adicionar proprietários e usuários no Azure DevTest Labs.

Gerencie custos e propriedade

O custo e a propriedade são as principais preocupações quando você considera a criação de seus ambientes de desenvolvimento e teste. Nesta seção, você encontra informações que ajudam a otimizar o custo e alinhar a propriedade em todo o ambiente.

Otimize para custos

Vários recursos integrados do DevTest Labs ajudam você a otimizar o custo. Consulte os artigos de gerenciamento de custos, limites e políticas para limitar as atividades de seus usuários.

Se você usa o DevTest Labs para cargas de trabalho de desenvolvimento e teste, considere usar o Benefício da Assinatura de Desenvolvimento/Teste Empresarial que faz parte do seu Enterprise Agreement. Ou, se você for um cliente Pay as you Go, considere a oferta Pay-as-you Go DevTest.

Esta abordagem oferece várias vantagens:

• Taxas especiais mais baixas de desenvolvimento/teste em máquinas virtuais Windows, serviços de nuvem, HDInsight, Serviço de Aplicativo e Aplicativos Lógicos
• Taxas do Great Enterprise Agreement (EA) em outros serviços do Azure
• Acesso a imagens exclusivas de Programador/Teste na Galeria, incluindo o Windows 8.1 e o Windows 10

Apenas os subscritores ativos do Visual Studio (subscrições padrão, subscrições anuais na nuvem e subscrições mensais na nuvem) podem utilizar os recursos do Azure em execução numa subscrição empresarial de Desenvolvimento/Teste. No entanto, os usuários finais podem acessar o aplicativo para fornecer feedback ou fazer testes de aceitação. Você pode usar os recursos desta assinatura apenas para desenvolver e testar aplicativos. Não há garantia de tempo de atividade.

Se você decidir usar a oferta DevTest, use esse benefício exclusivamente para desenvolver e testar seus aplicativos. O uso dentro da assinatura não possui um SLA com suporte financeiro, exceto para o uso do Azure DevOps e do HockeyApp.

Definir acesso baseado em função em toda a sua organização

A TI central deve possuir apenas o que é necessário e permitir que as equipes de projeto e aplicativos tenham o nível necessário de controle. Normalmente, isso significa que a TI central é proprietária da assinatura e lida com as principais funções de TI, como configurações de rede. O conjunto de proprietários de uma assinatura deve ser pequeno. Esses proprietários podem nomear outros proprietários quando houver necessidade ou aplicar políticas de nível de assinatura, por exemplo, "Sem IP público".

Pode haver um subconjunto de usuários que exigem acesso em uma assinatura, como suporte de Nível 1 ou Nível 2. Nesse caso, recomendamos que você conceda a esses usuários o acesso de colaborador para que eles possam gerenciar os recursos, mas não fornecer acesso de usuário ou ajustar políticas.

Os proprietários de recursos do DevTest Labs devem estar próximos da equipe do projeto ou do aplicativo. Esses proprietários entendem os requisitos de máquina e software. Na maioria das organizações, o proprietário do recurso DevTest Labs é o líder do projeto ou desenvolvimento. Esse proprietário pode gerenciar usuários e políticas dentro do ambiente de laboratório e pode gerenciar todas as máquinas virtuais no ambiente DevTest Labs.

Adicione membros da equipe de projeto e aplicativo à função Usuários do DevTest Labs. Esses usuários podem criar máquinas virtuais, de acordo com as políticas de laboratório e de nível de assinatura. Os usuários também podem gerenciar suas próprias máquinas virtuais, mas não podem gerenciar máquinas virtuais que pertencem a outros usuários.

Para obter mais informações, consulte Azure enterprise scaffold – prescriptive subscription governance.

Política e conformidade da empresa

Esta seção fornece orientação sobre como governar a política da empresa e a conformidade para a infraestrutura do Azure DevTest Labs.

Repositório de artefatos público versus privado

O repositório público de artefatos fornece um conjunto inicial de pacotes de software que são mais comumente usados. Ele ajuda com a implantação rápida sem ter que investir tempo para reproduzir ferramentas e suplementos comuns do desenvolvedor. Você pode optar por implantar seu próprio repositório privado. Você pode usar um repositório público e um repositório privado em paralelo. Você também pode optar por desativar o repositório público. Os critérios para implantar um repositório privado devem ser orientados pelas seguintes perguntas e considerações:

• A organização tem um requisito para ter software corporativo licenciado como parte de sua oferta DevTest Labs? Se a resposta for sim, então um repositório privado deve ser criado.
• A organização desenvolve software personalizado que fornece uma operação específica, que é necessária como parte do processo geral de provisionamento? Se a resposta for sim, um repositório privado deve ser implantado.
• Se a política de governança da organização exigir isolamento e os repositórios externos não estiverem sob gerenciamento direto de configuração pela organização, um repositório de artefatos privado deverá ser implantado. Como parte desse processo, uma cópia inicial do repositório público pode ser copiada e integrada ao repositório privado. Em seguida, o repositório público pode ser desativado para que ninguém dentro da organização possa acessá-lo mais. Essa abordagem força todos os usuários dentro da organização a ter apenas um único repositório que é aprovado pela organização e minimizar o desvio de configuração.

Repositório único ou vários repositórios

Como parte da estratégia geral de governança e gerenciamento de configuração da sua organização, recomendamos que você use um repositório centralizado. Quando você usa vários repositórios, eles podem se tornar silos de software não gerenciado ao longo do tempo. Com um repositório central, várias equipes podem consumir artefatos desse repositório para seus projetos. Ele impõe padronização, segurança, facilidade de gerenciamento e elimina a duplicação de esforços. Como parte da centralização, são recomendadas as seguintes ações para a gestão e sustentabilidade a longo prazo:

• Associe o Azure Repos ao mesmo locatário do Microsoft Entra que a assinatura do Azure está usando para autenticação e autorização.
• Crie um grupo chamado All DevTest Labs Developers na ID do Microsoft Entra que é gerenciado centralmente. Qualquer desenvolvedor que contribua para o desenvolvimento de artefatos deve ser colocado neste grupo.
• O mesmo grupo do Microsoft Entra pode ser usado para fornecer acesso ao repositório do Azure Repos e ao laboratório.
• No Azure Repos, a ramificação ou bifurcação deve ser usada para separar um repositório em desenvolvimento do repositório de produção principal. O conteúdo só é adicionado à ramificação principal com uma solicitação pull após uma revisão de código adequada. Uma vez que o revisor de código aprova a alteração, um desenvolvedor principal, que é responsável pela manutenção da ramificação principal, mescla o código atualizado.

Políticas de segurança corporativas

Uma organização pode aplicar políticas de segurança corporativas:

• Desenvolver e publicar uma política de segurança abrangente. A política articula as regras de uso aceitável associadas ao uso de software, ativos em nuvem. Também define o que claramente viola a política.
• Desenvolver uma imagem personalizada, artefatos personalizados e um processo de implantação que permita orquestração dentro da região de segurança definida com o Ative Directory. Esta abordagem impõe os limites da empresa e estabelece um conjunto comum de controlos ambientais. Esses controles em relação ao ambiente que um desenvolvedor pode considerar ao desenvolver e seguir um ciclo de vida de desenvolvimento seguro como parte de seu processo geral. O objetivo também é proporcionar um ambiente que não seja excessivamente restritivo que possa prejudicar o desenvolvimento, mas um conjunto razoável de controles. As diretivas de grupo na unidade organizacional (UO) que contém máquinas virtuais de laboratório podem ser um subconjunto do total de diretivas de grupo encontradas na produção. Alternativamente, eles podem ser outro conjunto para mitigar adequadamente quaisquer riscos identificados.

Integridade dos dados

Uma organização pode garantir a integridade dos dados para garantir que os desenvolvedores remotos não possam remover código ou introduzir malware ou software não aprovado. Há várias camadas de controle para mitigar a ameaça de consultores externos, contratados ou funcionários que se comunicam para colaborar no DevTest Labs.

Como dito anteriormente, o primeiro passo deve ter uma política de uso aceitável elaborada e definida que descreva claramente as consequências quando alguém viola a política.

A primeira camada de controles para acesso remoto é aplicar uma diretiva de acesso remoto por meio de uma conexão VPN que não esteja diretamente conectada ao laboratório.

A segunda camada de controles é aplicar um conjunto de objetos de diretiva de grupo que impedem copiar e colar através da área de trabalho remota. Uma política de rede pode ser implementada para não permitir que serviços de saída do ambiente, como serviços FTP e RDP, saiam do ambiente. O roteamento definido pelo usuário poderia forçar todo o tráfego de rede do Azure de volta ao local, mas o roteamento não poderia levar em conta todas as URLs que poderiam permitir o carregamento de dados, a menos que controlado por meio de um proxy para verificar conteúdo e sessões. IPs públicos podem ser restritos dentro da rede virtual que suporta DevTest Labs para não permitir a ponte de um recurso de rede externa.

Em última análise, o mesmo tipo de restrições precisa ser aplicado em toda a organização, que também teria que levar em conta todos os métodos possíveis de mídia removível ou URLs externas que poderiam aceitar uma postagem de conteúdo. Consulte o seu profissional de segurança para rever e implementar uma política de segurança. Para obter mais recomendações, consulte Microsoft Cyber Security.

Migração e integração de aplicações

Uma vez que seu ambiente de laboratório de desenvolvimento/teste tenha sido estabelecido, você precisa pensar nas seguintes perguntas:

• Como você usa o ambiente dentro da sua equipe de projeto?
• Como você garante que segue as políticas organizacionais necessárias e mantém a agilidade para agregar valor à sua aplicação?

Imagens do Azure Marketplace vs. imagens personalizadas

O Azure Marketplace deve ser usado por padrão, a menos que você tenha preocupações específicas ou requisitos organizacionais. Alguns exemplos comuns incluem;

• Configuração de software complexa que requer a inclusão de um aplicativo como parte da imagem base.
• A instalação e a configuração de um aplicativo podem levar muitas horas, o que não é um uso eficiente do tempo de computação a ser adicionado em uma imagem do Azure Marketplace.
• Os desenvolvedores e testadores exigem acesso a uma máquina virtual rapidamente e desejam minimizar o tempo de configuração de uma nova máquina virtual.
• Condições de conformidade ou regulamentares (por exemplo, políticas de segurança) que devem estar em vigor para todas as máquinas.

Considere o uso cuidadoso de imagens personalizadas. As imagens personalizadas introduzem complexidade extra, pois agora você precisa gerenciar arquivos VHD para essas imagens de base subjacentes. Você também precisa corrigir rotineiramente essas imagens básicas com atualizações de software. Essas atualizações incluem novas atualizações do sistema operacional (SO) e quaisquer atualizações ou alterações de configuração necessárias para o próprio pacote de software.

Fórmula versus imagem personalizada

Normalmente, o fator decisivo neste cenário é o custo e a reutilização.

Você pode reduzir os custos criando uma imagem personalizada se:

• Muitos usuários ou laboratórios exigem a imagem.
• A imagem necessária tem um monte de software em cima da imagem base.

Esta solução significa que você cria a imagem uma vez. Uma imagem personalizada reduz o tempo de configuração da máquina virtual. Você não incorre em custos ao executar a máquina virtual durante a instalação.

Outro fator é a frequência das alterações no seu pacote de software. Se você executa compilações diárias e exige que o software esteja nas máquinas virtuais dos usuários, considere usar uma fórmula em vez de uma imagem personalizada.

Padrões para configurar a configuração de rede

Quando você garante que as máquinas virtuais de desenvolvimento e teste não consigam acessar a Internet pública Há dois aspetos a considerar – tráfego de entrada e de saída.

Tráfego de entrada – Se a máquina virtual não tiver um endereço IP público, a Internet não poderá acessá-lo. Uma abordagem comum é definir uma política de nível de assinatura para que nenhum usuário possa criar um endereço IP público.

Tráfego de saída – Se quiser impedir que as máquinas virtuais vão diretamente para a Internet pública e forçar o tráfego através de uma firewall empresarial, pode encaminhar o tráfego no local através do Azure ExpressRoute ou VPN, utilizando o encaminhamento forçado.

Nota

Se você tiver um servidor proxy que bloqueia o tráfego sem configurações de proxy, não se esqueça de adicionar exceções à conta de armazenamento de artefatos do laboratório, .

Você também pode usar grupos de segurança de rede para máquinas virtuais ou sub-redes. Esta etapa adiciona outra camada de proteção para permitir ou bloquear o tráfego.

Rede virtual nova vs. existente

Se suas VMs precisarem interagir com a infraestrutura existente, você deve considerar o uso de uma rede virtual existente dentro do ambiente do DevTest Labs. Se você usa a Rota Expressa, minimize o número de redes virtuais e sub-redes para não fragmentar o espaço de endereço IP atribuído às suas assinaturas. Considere também usar o padrão de emparelhamento de rede virtual aqui (modelo Hub-Spoke). Essa abordagem permite a comunicação de rede virtual e sub-rede entre assinaturas dentro de uma determinada região.

Cada ambiente DevTest Labs pode ter sua própria rede virtual, mas há limites para o número de redes virtuais por assinatura. O valor padrão é 50, embora esse limite possa ser aumentado para 100.

IP compartilhado, público ou privado

Se você usa uma VPN site a site ou uma Rota Expressa, considere o uso de IPs privados para que suas máquinas sejam acessíveis por meio de sua rede interna e inacessíveis pela Internet pública.

Nota

Os proprietários de laboratórios podem alterar essa política de sub-rede para garantir que ninguém crie acidentalmente endereços IP públicos para suas VMs. O proprietário da subscrição deve criar uma política de subscrição que impeça a criação de IPs públicos.

Ao usar IPs públicos compartilhados, as máquinas virtuais em um laboratório compartilham um endereço IP público. Essa abordagem pode ser útil quando você precisa evitar violar os limites de endereços IP públicos de uma determinada assinatura.

Limites laboratoriais

Existem vários limites laboratoriais que você deve estar ciente. Esses limites são descritos nas seções a seguir.

Limites de laboratórios por subscrição

Não há um limite específico para o número de laboratórios que podem ser criados por assinatura. No entanto, a quantidade de recursos utilizados por subscrição é limitada. Você pode ler sobre os limites e cotas para assinaturas do Azure e como aumentar esses limites.

Limites de VMs por laboratório

Não há limite específico para o número de VMs que podem ser criadas por laboratório. No entanto, os recursos (núcleos de VM, endereços IP públicos e assim por diante) usados são limitados por assinatura. Você pode ler sobre os limites e cotas para assinaturas do Azure e como aumentar esses limites.

Limites do número de máquinas virtuais por usuário ou laboratório

Quando você considera o número de máquinas virtuais por usuário ou por laboratório, há três preocupações principais:

• O custo total que a equipe pode gastar em recursos no laboratório. É fácil girar muitas máquinas. Para controlar os custos, um mecanismo é limitar o número de VMs por usuário ou por laboratório
• O número total de máquinas virtuais em um laboratório é afetado pelas cotas de nível de assinatura disponíveis. Um dos limites superiores é de 800 grupos de recursos por assinatura. Atualmente, o DevTest Labs cria um novo grupo de recursos para cada VM (a menos que IPs públicos compartilhados sejam usados). Se houver 10 laboratórios em uma assinatura, os laboratórios poderão caber aproximadamente 79 máquinas virtuais em cada laboratório (limite superior de 800 – 10 grupos de recursos para os próprios 10 laboratórios) = 79 máquinas virtuais por laboratório.
• Se o laboratório estiver conectado ao local via Rota Expressa (por exemplo), há espaços de endereço IP definidos disponíveis para a VNet/Sub-rede. Para garantir que as VMs no laboratório não deixem de ser criadas (erro: não é possível obter o endereço IP), os proprietários do laboratório podem especificar o máximo de VMs por laboratório alinhado com o espaço de endereço IP disponível.

Utilizar os modelos do Resource Manager

Implante seus modelos do Resource Manager usando as etapas em Usar o Azure DevTest Labs para ambientes de teste. Basicamente, você verifica seus modelos do Resource Manager em um repositório Git do Azure Repos ou GitHub e adiciona um repositório privado para seus modelos ao laboratório.

Esse cenário pode não ser útil se você estiver usando o DevTest Labs para hospedar máquinas de desenvolvimento. Use este cenário para criar um ambiente de preparação representativo da produção.

O número de máquinas virtuais por laboratório ou por opção de usuário limita apenas o número de máquinas criadas nativamente no próprio laboratório. Essa opção não limita a criação por nenhum ambiente com modelos do Resource Manager.