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 dentro de uma assinatura do Azure

Antes de uma organização começa a usar o Azure para desenvolvimento de aplicativos em geral, os planejadores de TI devem primeiro examinar como introduzir a funcionalidade como parte de seu portfólio geral de serviços. As áreas a examinar devem tratar das seguintes preocupações:

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

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

A segunda prática recomendada é habilitar a assinatura do DevTest no Azure Enterprise Portal. Ela permite que uma organização execute sistemas operacionais cliente que não estão normalmente disponíveis em uma assinatura do Azure Enterprise. Em seguida, use o software empresarial, no qual você paga somente pela computação e não se preocupe com o licenciamento. Ele garante que a cobrança por serviços designados, incluindo imagens da galeria em IaaS como o Microsoft SQL Server, seja baseada somente no consumo. Detalhes sobre a assinatura do Azure DevTest podem ser encontrados aqui para os clientes do EA (Contrato Enterprise) e aqui para clientes com pagamento conforme o uso.

Esse modelo fornece a uma organização a flexibilidade para implantar o Azure DevTest Labs em escala. Uma organização pode dar suporte a centenas de laboratórios para várias unidades de negócios, com 100 a 1.000 máquinas virtuais em execução paralelamente. 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 de 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 assinaturas e de serviços, confira Assinatura do Azure e limites, cotas e restrições de serviços. 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 o uso aumenta na assinatura de desenvolvimento. Para obter mais informações sobre como dimensionar o DevTest Labs, confira Dimensionar cotas e limites no DevTest Labs.

Um limite de nível de assinatura comum que deve ser considerado é como as atribuições de intervalo IP de rede são alocadas para dar suporte a assinaturas de desenvolvimento e de produção. Essas atribuições devem levar em consideração o crescimento ao longo do tempo (presumindo conectividade local ou outra topologia de rede que exija que a empresa possa gerenciar sua pilha de rede em vez de usar a implementação do Azure por padrão). A prática recomendada é ter algumas redes virtuais com um grande prefixo de endereço IP atribuído e dividido com várias 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 de laboratórios por organização

É recomendável que as unidades de negócios e os grupos de desenvolvimento associados com o mesmo projeto de desenvolvimento sejam associados com o mesmo laboratório. Isso permite que os mesmos tipos de políticas, imagens e políticas de desligamento sejam aplicadas a ambos os grupos.

Você também precisará considerar os limites geográficos. Por exemplo, os desenvolvedores na região nordeste dos EUA (Estados Unidos) podem usar um laboratório provisionado no Leste dos EUA 2. E os desenvolvedores em Dallas, Texas e em Denver, Colorado podem ser direcionados para usar um recurso no Centro-Sul dos EUA. Se houver um esforço colaborativo com terceiros, eles poderão ser atribuídos a um laboratório não usado por desenvolvedores internos.

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

Impedindo a exclusão de recursos

Defina permissões apropriadas no nível do laboratório, para que somente 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 líder ou o líder de infraestrutura deve ser o Proprietário do DevTest Labs. É recomendável 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 usuários do laboratório têm direitos para usar os recursos, mas não podem atualizar as políticas de laboratório. Confira o artigo a seguir, que lista as funções e os direitos de cada grupo interno tem em um laboratório: Adicionar proprietários e usuários ao Azure DevTest Labs.

Gerenciar custo e propriedade

O custo e a propriedade são preocupações primárias ao considerar a criação de ambientes de desenvolvimento e teste. Nesta seção, há informações que ajudam você a otimizar o custo e alinhar a propriedade em todo o ambiente.

Otimizar para custos

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

Se você usar o DevTest Labs para cargas de trabalho de desenvolvimento e teste, considere usar o Benefício de Assinatura de Desenvolvimento/Teste Enterprise que faz parte do Contrato Enterprise. Ou, se você é um cliente de pagamento conforme o uso, considere a oferta DevTest pago conforme o uso.

Essa abordagem oferece várias vantagens:

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

Somente os assinantes ativos do Visual Studio (assinaturas padrão, assinaturas de nuvem anuais e assinaturas de nuvem mensais) podem usar os recursos do Azure em execução em uma assinatura de Desenvolvimento/Teste do Enterprise. No entanto, os usuários finais podem acessar o aplicativo para fornecer comentários ou fazer teste de aceitação. Você pode usar os recursos dentro dessa assinatura somente para desenvolver e testar aplicativos. Não há nenhuma garantia de tempo de atividade.

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

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

O Centro de TI deve ter apenas o que é necessário e permitir que as equipes de projeto e aplicativo tenham o nível de controle necessário. Normalmente, isso significa que a TI central controla a 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 indicar outros proprietários quando há necessidade ou aplicar políticas de nível de assinatura, por exemplo, "Nenhum IP público".

Pode haver um subconjunto de usuários que exija acesso por meio de uma assinatura, como o suporte à Camada 1 ou à Camada 2. Nesse caso, recomendamos que você conceda a esses usuários o acesso de colaborador para que eles possam gerenciar os recursos sem fornecer acesso a usuários nem ajustar políticas.

Os proprietários de recursos do DevTest Labs devem estar próximos ao projeto ou à equipe do aplicativo. Esses proprietários entendem os requisitos de computador e de software. Na maioria das organizações, o proprietário do recurso DevTest Labs é o líder de desenvolvimento ou do projeto. Esse proprietário pode gerenciar usuários e políticas dentro do ambiente de laboratório e gerenciar todas as máquinas virtuais no ambiente do 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, alinhados com as políticas de nível de laboratório e assinatura. Os usuários também podem gerenciar as próprias máquinas virtuais, mas não podem gerenciar máquinas virtuais que pertencem a outros usuários.

Para saber mais, confira a documentação do scaffolding empresarial do Azure – Governança de assinatura prescritiva.

Política e conformidade da empresa

Este artigo fornece diretrizes sobre governança da política da empresa e a conformidade para a infraestrutura do Azure DevTest Labs.

Repositório de artefatos público vs privado

O repositório de artefatos público fornece um conjunto inicial de pacotes de software que são mais comumente usados. Isso ajuda com implantação rápida, sem a necessidade de investir tempo para reproduzir as ferramentas para desenvolvedores e suplementos comuns. Você pode optar por implantar seu próprio repositório. Você pode usar um repositório público e um privado em paralelo. Você também pode optar por desabilitar 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 de ter software corporativo licenciado como parte de sua oferta do DevTest Labs? Se a resposta for sim, um repositório privado deverá ser criado.
• A organização desenvolve software personalizado que fornece uma operação específica, que é exigida como parte do processo geral de provisionamento? Se a resposta for sim, um repositório privado deverá ser implantado.
• Se a política de governança da organização exigir isolamento e os repositórios externos não estiverem sob o gerenciamento de configuração direta 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 com o repositório privado. Em seguida, o repositório público pode ser desabilitado para que ninguém na organização possa continuar acessando-o. 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 os descompassos de configuração.

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

Como parte da estratégia de gerenciamento de configuração e de governança de geral da sua organização, é recomendável 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 a padronização, a segurança, a facilidade de gerenciamento e elimina a duplicação de esforços. Como parte a centralização, as seguintes ações são práticas recomendadas para gerenciamento a longo prazo e de sustentabilidade:

• 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 centralmente gerenciado chamado Todos os Desenvolvedores do DevTest Labs no Microsoft Entra ID. Qualquer desenvolvedor que contribui para o desenvolvimento de artefatos deve ser colocado nesse 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 um repositório em desenvolvimento separado do repositório de produção primário. O conteúdo só é adicionado à ramificação principal com uma solicitação de pull após uma revisão de código apropriada. Depois que o revisor de código aprova a alteração, um desenvolvedor-chefe, que é responsável pela manutenção da ramificação principal, mescla o código atualizado.

Políticas de segurança corporativa

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

• 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 e de ativos de nuvem. Ele também define o que claramente viola a política.
• Desenvolver uma imagem personalizada, artefatos personalizados e um processo de implantação que permite a orquestração no realm de segurança que é definido com o Active Directory. Essa abordagem impõe o limite corporativo e define um conjunto comum de controles ambientais. Esses controles determinam o ambiente que um desenvolvedor pode considerar conforme desenvolve e segue um ciclo de vida de desenvolvimento seguro como parte de seu processo geral. O objetivo também é fornecer um ambiente que não seja excessivamente restritivo que possa atrapalhar o desenvolvimento, mas um conjunto razoável de controles. As políticas de grupo na UO (unidade organizacional) que contém máquinas virtuais do laboratório pode ser um subconjunto das políticas de grupo totais que são encontrados na produção. Como alternativa, elas podem ser um conjunto adicional para mitigar adequadamente todos os riscos identificados.

Integridade de dados

Uma organização pode assegurar a integridade de 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 atenuar a ameaça de consultores externos, prestadores de serviços ou funcionários que estão acessando remotamente para colaborar no DevTest Labs.

Conforme mencionado anteriormente, a primeira etapa precisa ter uma política de uso aceitável esboçada e definida que descreva claramente as consequências de quando alguém viola a política.

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

A segunda camada de controles é aplicar um conjunto de objetos de política de grupo que evita copiar e colar por meio da Área de Trabalho Remota. Uma política de rede pode ser implementada para não permitir a saída de serviços do ambiente, tais como serviços de protocolo RDP e FTP fora do ambiente. O roteamento definido pelo usuário pode forçar todo o tráfego de rede do Azure de volta para o local, mas o roteamento não pôde considerar todas as URLs que possam permitir o carregamento de dados, a menos que sejam controlados por meio de um proxy para verificar o conteúdo e as sessões. IPs públicos poderiam ser restritos dentro da rede virtual que dá suporte ao DevTest Labs para não permitir a passagem de um recurso de rede externo.

Por fim, restrições desse mesmo tipo precisam ser aplicadas em toda a organização, o que também teria que levar em conta todos os métodos possíveis de mídia removível ou URLs externas que pudessem aceitar uma postagem de conteúdo. Confira seu profissional de segurança para examinar e implementar uma política de segurança. Para obter mais recomendações, confira Segurança cibernética da Microsoft.

Integração e migração de aplicativos

Depois que seu ambiente de laboratório de desenvolvimento/teste tiver sido estabelecido, você precisará pensar sobre as perguntas a seguir:

• Como usar o ambiente dentro da equipe do projeto?
• Como você garante que segue as políticas organizacionais necessárias e mantém a agilidade para adicionar valor ao seu aplicativo?

Imagens do Microsoft Azure Marketplace versus imagens personalizadas

O Microsoft 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 softwares complexos que requerem um aplicativo para serem incluídos 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.
• Desenvolvedores e testadores necessitam de acesso rápido a uma máquina virtual e querem 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.

Use as imagens personalizadas com cuidado. As imagens personalizadas são mais complexas, pois agora você precisa gerenciar arquivos VHD para as imagens base subjacentes. Também será preciso aplicar patches frequentemente nas imagens base com atualizações de software. Essas atualizações incluem novas atualizações do sistema operacional (SO) e todas as alterações de atualizações ou configurações necessárias para o pacote de software.

Fórmula versus imagem personalizada

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

Você pode reduzir o custo criando uma imagem personalizada se:

• Muitos usuários ou laboratórios exigem a imagem.
• A imagem necessária tem muitos softwares baseados na imagem base.

Essa solução significa que você cria a imagem só uma vez. Uma imagem personalizada reduz o tempo de configuração da máquina virtual. Você não gera custos para executar a máquina virtual durante a instalação.

Outro fator é a frequência das alterações no pacote de software. Se você executa builds diários e exigi 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 definir a configuração de rede

Quando você garante que as máquinas virtuais de desenvolvimento e teste não conseguem acessar a Internet pública, há dois aspectos a serem considerados: o tráfego de entrada e o tráfego de saída.

Tráfego de entrada – Se a máquina virtual não tiver um endereço IP público, ela não poderá ser acessada pela Internet. Uma abordagem comum é definir uma política no nível da 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 acessem diretamente a Internet pública e forçar o tráfego com um firewall corporativo, você pode encaminhar o tráfego local pelo Azure ExpressRoute ou pela VPN usando o roteamento forçado.

Observação

Se você tiver um servidor proxy que bloqueia o tráfego sem as configurações de proxy, não se esqueça de adicionar exceções à conta de armazenamento de artefato 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 versus rede virtual existente

Se suas VMs precisam interagir com a infraestrutura existente, você deve considerar usar uma rede virtual existente no ambiente do DevTest Labs. Se você usar o ExpressRoute, minimize o número de redes virtuais e sub-redes para não fragmentar o espaço de endereços IP atribuído às assinaturas. Considere também usar o padrão de emparelhamento de rede virtual aqui (modelo hub-spoke). Essa abordagem habilita a comunicação da rede virtual e da sub-rede entre as assinaturas em uma determinada região.

Cada ambiente do DevTest Labs pode ter a própria rede virtual, mas há limites no 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ê usar uma VPN site a site ou 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.

Observação

Os proprietários de laboratórios podem alterar essa política de sub-rede para garantir que ninguém acidentalmente crie endereços IP públicos para suas VMs. O proprietário da assinatura deve criar uma política de assinatura impedindo 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 que violem os limites em endereços IP públicos para uma determinada assinatura.

Limites de laboratório

Há vários limites de laboratório do quais você deve estar ciente. Essas limitações são descritas nas seções a seguir.

Limites de laboratórios por assinatura

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

Limites de VMs por laboratório

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

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

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

• O custo geral que a equipe pode gastar em recursos do laboratório. É fácil acelerar várias máquinas. Para controlar os custos, um mecanismo serve para limitar o número de VMs por usuário e/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 é 800 grupos de recursos por assinatura. Os Laboratórios de Desenvolvimento/Teste criam um novo grupo de recursos para cada máquina virtual (a menos que sejam usados IPs públicos compartilhados). Se existem 10 laboratórios em uma assinatura, os laboratórios podem abrigar aproximadamente 79 máquinas virtuais em cada laboratório (limite superior de 800 – 10 grupos de recursos para os 10 laboratórios) = 79 máquinas virtuais por laboratório.
• Se o laboratório é conectado ao local por meio da Rota Expressa (por exemplo), há espaços de endereço IP definidos disponíveis para a VNet/sub-rede. Para garantir que as máquinas virtuais no laboratório não falhem ao serem criadas (erro: não é possível obter o endereço IP), os proprietários de laboratório podem especificar o máximo de máquinas virtuais por laboratório alinhado com o espaço de endereço IP disponível.

Use modelos do Gerenciador de Recursos

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

Esse cenário poderá 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 preparo que represente o de produção.

O número de máquinas virtuais por laboratório ou por opção do 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 ambientes com modelos do Resource Manager.