Arquitetura de linha de base de Máquinas Virtuais do Azure em uma zona de destino do Azure

A arquitetura neste artigo se expande sobre a arquitetura de linha de base da VM (máquina virtual) para resolver as alterações e as expectativas ao implantá-la em uma zona de destino do Azure.

No exemplo deste artigo, uma organização deseja que uma carga de trabalho baseada em VM use recursos federados que uma equipe de plataforma gerencia centralmente. Esses recursos incluem recursos de rede para conectividade entre locais, gerenciamento de acesso de identidade e políticas. Este exemplo pressupõe que a organização adote zonas de destino do Azure para impor governança e eficiência de custo consistentes em várias cargas de trabalho.

Como proprietário de uma carga de trabalho, você pode descarregar o gerenciamento de recursos compartilhados para equipes centrais, para que você possa se concentrar nos esforços de desenvolvimento de carga de trabalho. Este artigo apresenta a perspectiva da equipe de carga de trabalho. Recomendações que são para a equipe de plataforma são especificadas.

Layout do artigo

Arquitetura	Decisão de design	Abordagem do Azure Well-Architected Framework
▪ de diagrama de arquitetura de ▪ recursos de carga de trabalho ▪ recursos federados	▪ de instalação da Assinatura ▪ requisitos de rede ▪ alterações de design de rede do de linha de base ▪ Monitoramento ▪ de conformidade do Patch ▪ de governança organizacional ▪ de gerenciamento de alterações	▪ de Confiabilidade ▪ security ▪ de Otimização de Custos

Arquitetura

Baixe um de arquivo do Visio dessa arquitetura.

Componentes

Todas as arquiteturas de zona de destino do Azure têm uma separação de propriedade entre a equipe de plataforma e a equipe de carga de trabalho. Os arquitetos de aplicativos e as equipes de DevOps precisam ter uma forte compreensão dessa responsabilidade dividida para entender o que está sob sua influência direta ou controle e o que não está.

Recursos de propriedade da equipe de carga de trabalho

Os recursos a seguir permanecem praticamente inalterados em relação à arquitetura de linha de base .

• de Máquinas Virtuais do Azure é a plataforma de aplicativo. Os recursos de computação são distribuídos entre zonas de disponibilidade.

• do Azure Load Balancer é usado para balancear o tráfego de carga privada das VMs front-end para as VMs de back-end. O balanceador de carga distribui o tráfego para VMs entre zonas.

• gateway de aplicativo do Azure é usado como o proxy reverso para rotear solicitações de usuário para as VMs front-end. A SKU selecionada também é usada para hospedar o Firewall do Aplicativo Web do Azure para proteger as VMs front-end contra tráfego potencialmente mal-intencionado.

• do Azure Key Vault é usado para armazenar segredos e certificados do aplicativo.

• Azure Monitor, Log Analytics e Application Insights são usados para coletar, armazenar e visualizar dados de observabilidade.

• do Azure Policy é usado para aplicar políticas específicas à carga de trabalho.

A equipe de carga de trabalho mantém e atende aos seguintes recursos e responsabilidades.

• as sub-redes de rede virtual do Spoke e os NSGs (grupos de segurança de rede) que são colocados nessas sub-redes para manter a segmentação e controlar o fluxo de tráfego.

• pontos de extremidade privados para proteger a conectividade com soluções paaS (plataforma como serviço) e as zonas DNS privadas necessárias para esses pontos de extremidade.

• o Azure Managed Disks armazena arquivos de log nos servidores de back-end e os dados são mantidos mesmo quando as VMs são reinicializadas. Os servidores front-end têm discos anexados que você pode usar para implantar seu aplicativo sem estado.

Recursos de propriedade da equipe da plataforma

A equipe de plataforma possui e mantém esses recursos centralizados. Essa arquitetura pressupõe que esses recursos sejam pré-provisionados e os considere dependências.

• Firewall do Azure no de rede do hub é usado para inspecionar e restringir o tráfego de saída. Esse componente substitui o balanceador de carga padrão na arquitetura de linha de base, que não fornece restrições sobre o tráfego de saída para a Internet.

• o Azure Bastion na rede do hub fornece acesso operacional seguro a VMs de carga de trabalho. Na arquitetura de linha de base, a equipe de carga de trabalho é dona desse componente.

• O de rede virtual de spoke é onde a carga de trabalho é implantada.

• UDRs (rotas definidas pelo usuário) são usadas para forçar o túnel para a rede do hub.

• restrições de governança baseadas no Azure Policy e políticas de DeployIfNotExists (DINE) fazem parte da assinatura da carga de trabalho.

Configuração da assinatura

Em um contexto de zona de destino, sua equipe de carga de trabalho deve informar a equipe de plataforma sobre seus requisitos específicos.

Sua equipe de carga de trabalho deve incluir informações detalhadas sobre o espaço de rede de que sua carga de trabalho precisa, para que a equipe da plataforma possa alocar os recursos necessários. Sua equipe determina os requisitos e a equipe de plataforma determina os endereços IP a serem atribuídos na rede virtual e no grupo de gerenciamento ao qual a assinatura é atribuída.

A equipe de plataforma atribui um grupo de gerenciamento apropriado com base na criticidade de negócios e requisitos técnicos da carga de trabalho, por exemplo, se uma carga de trabalho for exposta à Internet. A organização determina a configuração desses grupos de gerenciamento e a equipe de plataforma os implementa.

Por exemplo, os grupos de gerenciamento nos cenários de aplicativo para a arquitetura de linha de base são considerados:

• aplicativos privados, como aplicativos de linha de negócios internos ou soluções comerciais off-the-shelf (COTS), que geralmente estão localizadas no grupo de gerenciamento corp das zonas de destino do Azure.

• aplicativos públicos, como em aplicativos voltados para a Internet, que geralmente estão no grupo de gerenciamento Corp ou Online.

A equipe da plataforma também é responsável por configurar uma assinatura ou um grupo de assinaturas para a implantação da carga de trabalho.

As seções a seguir fornecem diretrizes sobre a configuração inicial da assinatura. No entanto, a equipe de plataforma normalmente faz alterações nos serviços centralizados para atender aos requisitos perdidos ou alterados. As alterações de plataforma têm um efeito mais amplo em todas as equipes de carga de trabalho.

Portanto, a equipe da plataforma deve garantir que todas as cargas de trabalho de VM estejam preparadas para quaisquer alterações e que elas devem estar cientes do ciclo de vida da solução baseada em VM e do ciclo de teste. Para obter mais informações, consulte Gerenciamento de alterações ao longo do tempo.

Requisitos e cumprimentos de carga de trabalho

A equipe de carga de trabalho e as equipes de plataforma compartilham duas responsabilidades principais: atribuição de grupo de gerenciamento e configuração de rede. Para essa arquitetura, considere os seguintes requisitos de rede que você deve comunicar à equipe de plataforma. Use esses pontos como exemplos para entender a discussão e a negociação entre as duas equipes ao implementar uma arquitetura semelhante.

• O número de redes virtuais spoke: nesta arquitetura, apenas um spoke dedicado é necessário. Os recursos implantados não precisam se estender por várias redes e são colocados em uma única rede virtual.

• O tamanho da rede spoke: leve em consideração os requisitos operacionais e o crescimento esperado da carga de trabalho. Por exemplo, se você planeja implementar atualizações azuis/verdes ou canários, o tamanho máximo deve considerar o espaço que suas implantações lado a lado exigem.

  Alterações futuras podem exigir mais espaço IP, o que pode desalinhar com a alocação atual. A integração desses espaços pode introduzir complexidade extra. Seja proativo e solicite recursos de rede suficientes antecipadamente para garantir que o espaço alocado possa acomodar a expansão futura.

• A região de implantação: é importante especificar as regiões em que a carga de trabalho será implantada. A equipe da plataforma pode usar essas informações para garantir que as redes virtuais spoke-and-hub sejam provisionadas na mesma região. Redes em diferentes regiões podem levar a problemas de latência devido ao tráfego que ultrapassa limites regionais e também podem incorrer em custos extras de largura de banda.

• As características da carga de trabalho e as opções de design: comunique suas opções de design, componentes e características à sua equipe de plataforma. Por exemplo, se você espera que sua carga de trabalho gere um alto número de conexões simultâneas com a Internet (tagarela), a equipe da plataforma deverá garantir que haja portas suficientes disponíveis para evitar o esgotamento. Eles podem adicionar endereços IP ao firewall centralizado para dar suporte ao tráfego ou configurar um gateway NAT (Conversão de Endereços de Rede) para rotear o tráfego por um caminho alternativo.

  Por outro lado, se você espera que sua carga de trabalho gere tráfego de rede mínimo (de ruído em segundo plano), a equipe da plataforma deverá usar recursos com eficiência em toda a organização.

  A equipe de plataforma precisa entender claramente as dependências. Por exemplo, sua carga de trabalho pode precisar de acesso a um banco de dados que outra equipe possui ou sua carga de trabalho pode ter tráfego entre locais. Sua carga de trabalho tem dependências fora do Azure? Essas informações são importantes para a equipe de plataforma saber.

• A configuração de firewall: a equipe da plataforma deve estar ciente do tráfego que sai da rede spoke e é túnel para a rede do hub. O firewall no hub não pode bloquear esse tráfego.

  Por exemplo, se sua carga de trabalho precisar acessar as atualizações do Windows para permanecer corrigida, um firewall não deverá bloquear essas atualizações. Da mesma forma, se houver agentes monitores, que acessam pontos de extremidade específicos, um firewall não deve bloquear esse tráfego porque pode interromper os dados de monitoramento da carga de trabalho. O aplicativo pode exigir acesso a pontos de extremidade de terceiros. Independentemente disso, use um firewall centralizado para distinguir entre o tráfego esperado e injustificado.

• o acesso do Operador: se houver grupos de segurança da ID do Microsoft Entra que os operadores usam para acessar as VMs por meio do Azure Bastion, informe a equipe da plataforma. O Azure Bastion normalmente é um recurso central. É crucial garantir que os grupos de segurança e as VMs ofereçam suporte ao protocolo seguro.

  Além disso, informe a equipe de plataforma sobre os intervalos de IP que contêm as VMs. Essas informações são necessárias para configurar os NSGs em torno do Azure Bastion na rede do hub.

• Os IPs públicos: informe a equipe de plataforma sobre o perfil de tráfego de entrada, incluindo todos os endereços IP públicos previstos. Nessa arquitetura, somente o tráfego de origem da Internet tem como destino o IP público no Gateway de Aplicativo. A equipe da plataforma deve informar a equipe de carga de trabalho se esses IPs estiverem sob um plano de Proteção contra DDoS do Azure ou se essa é a responsabilidade da equipe de carga de trabalho.

  Nessa arquitetura, há outro IP público para acesso operacional por meio do Azure Bastion. A equipe da plataforma é dona desse IP público e está registrada em um serviço, como a Proteção contra DDoS, que a equipe de plataforma também gerencia.

Opções de design de VM

As seleções de disco e SKU da VM permanecem iguais à arquitetura de linha de base .

Uma organização pode impor requisitos de conformidade à equipe de carga de trabalho que determina o uso de imagens de VM específicas. Considerando esses requisitos, a equipe de plataforma pode gerenciar um conjunto de imagens padronizadas, geralmente conhecidas como imagens douradas, que são criadas para uso em toda a organização.

A equipe da plataforma pode usar uma oferta gerenciada, como a Galeria de Computação do Azure ou um repositório privado para armazenar imagens do sistema operacional aprovadas ou artefatos de carga de trabalho. Ao escolher uma imagem do sistema operacional para VMs, consulte sua equipe de plataforma sobre fontes de imagem, frequência de atualização e expectativas de uso. Verifique também se as imagens podem atender aos requisitos de negócios necessários que a carga de trabalho atende.

Rede

Na arquitetura de linha de base , a carga de trabalho é provisionada em uma única rede virtual. A equipe de carga de trabalho gerencia a rede virtual.

Nessa arquitetura, a equipe de plataforma determina a topologia de rede. A topologia hub-spoke é assumida nessa arquitetura.

Baixe um de arquivo do Visio dessa arquitetura.

• Hubde rede virtual: um hub regional contém serviços centralizados que se comunicam com recursos de carga de trabalho na mesma região. Para obter mais informações, consulte Recursos de equipe da Plataforma. Recomendamos colocar o hub no de assinatura de conectividade.

• de rede virtual doSpoke: nesta arquitetura, a única rede virtual da arquitetura de linha de base é a rede spoke. Ele é emparelhado com a rede do hub, que contém os serviços centralizados. A equipe da plataforma é proprietária e gerencia essa rede spoke. Essa rede contém os recursos de carga de trabalho . A equipe de carga de trabalho possui os recursos nessa rede, incluindo suas sub-redes.

Verifique se você comunicar os requisitos de carga de trabalho à equipe da plataforma e revisá-los periodicamente.

Sub-redes de rede virtual

Na rede virtual spoke, a equipe de carga de trabalho cria e aloca as sub-redes. Colocar controles para restringir o tráfego dentro e fora das sub-redes ajuda a fornecer segmentação. Essa arquitetura usa a mesma topologia de sub-rede que a arquitetura de linha de base , que tem sub-redes dedicadas para Gateway de Aplicativo, VMs front-end, balanceador de carga, VMs de back-end e pontos de extremidade privados.

Ao implantar sua carga de trabalho em uma zona de destino do Azure, você ainda precisará implementar controles de rede. As organizações podem impor restrições para proteger contra a exfiltração de dados e garantir a visibilidade do SOC (Central de Operações de Segurança) e da equipe de rede de TI.

Com essa abordagem, a equipe da plataforma pode otimizar os gastos organizacionais gerais usando serviços centralizados, em vez de implantar controles de segurança redundantes para cada carga de trabalho em toda a organização. Nessa arquitetura, o Firewall do Azure é um exemplo de serviço central. Não é econômico ou prático para cada equipe de carga de trabalho gerenciar sua própria instância de firewall. Recomendamos uma abordagem centralizada para o gerenciamento de firewall.

Tráfego de entrada

O fluxo de tráfego de entrada permanece o mesmo que a arquitetura de linha de base .

O proprietário da carga de trabalho é responsável por todos os recursos relacionados à entrada da Internet pública em sua carga de trabalho. Por exemplo, nessa arquitetura, o Gateway de Aplicativo e seu IP público são colocados na rede spoke e não na rede do hub. Algumas organizações podem colocar recursos com tráfego de entrada em uma assinatura de conectividade usando uma implementação DMZ (desmilitarizada centralizada). A integração com essa topologia específica está fora do escopo deste artigo.

Tráfego de saída

Na arquitetura de linha de base, os conjuntos de dimensionamento de máquinas virtuais de carga de trabalho acessam a Internet pública por meio do Azure Load Balancer, mas esse tráfego não é restrito.

Esse design é diferente nessa arquitetura. Todo o tráfego que deixa a rede virtual spoke é roteado por meio da rede de hub emparelhada por meio de um firewall de saída. Uma rota é anexada a todas as sub-redes possíveis na rede spoke que direciona todo o tráfego para IPs não encontrados na rede virtual local (0.0.0.0/0) para o Firewall do Azure do hub.

Baixe um de arquivo do Visio dessa arquitetura.

A comunicação de carga de trabalho com o ponto de extremidade privado para acesso ao Key Vault permanece a mesma que a arquitetura de linha de base . Esse caminho é omitido do diagrama anterior para fins de brevidade.

A equipe de carga de trabalho deve identificar, documentar e comunicar todos os fluxos de tráfego de saída necessários para as operações de infraestrutura e carga de trabalho. A equipe de plataforma permite o tráfego necessário e todo o tráfego de saída não comunicada provavelmente é negado.

Controlar o tráfego de saída é mais do que apenas garantir que o tráfego esperado seja permitido. Trata-se também de garantir que apenas tráfego esperado seja permitido. O tráfego de saída não comunicada provavelmente é negado por padrão, mas é do melhor interesse de segurança da carga de trabalho garantir que o tráfego seja devidamente roteado.

Comunique todos os requisitos de tráfego de saída exclusivos para a equipe de plataforma. Por exemplo, se a carga de trabalho estabelecer várias conexões simultâneas com pontos de extremidade de rede externos, informe a equipe da plataforma. Em seguida, a equipe de plataforma pode provisionar uma implementação apropriada do Gateway nat do Azure ou adicionar mais IPs públicos no firewall regional para mitigação.

Sua organização pode ter requisitos que desencorajam o uso de padrões de arquitetura, que usam IPs públicos de propriedade de carga de trabalho para saída. Nesse caso, você pode usar o Azure Policy para negar IPs públicos em NICs (placas de interface de rede) de VM e quaisquer outros IPs públicos, além de seus pontos de entrada conhecidos.

Zonas DNS privadas

As arquiteturas que usam pontos de extremidade privados precisam de zonas DNS privadas para trabalhar com o provedor DNS. A equipe de carga de trabalho deve ter uma compreensão clara dos requisitos e do gerenciamento de zonas DNS privadas na assinatura fornecida pela equipe da plataforma. As zonas DNS privadas normalmente são gerenciadas em grande escala com políticas DINE, o que permite que o Firewall do Azure funcione como um proxy DNS confiável e dê suporte a regras de rede FQDN (nome de domínio totalmente qualificado).

Nessa arquitetura, a equipe de plataforma garante a resolução DNS privada confiável para pontos de extremidade de link privado. Colabore com sua equipe de plataforma para entender suas expectativas.

Teste de conectividade

Para arquiteturas baseadas em VM, há várias ferramentas de teste que podem ajudar a determinar problemas de linha de visão, roteamento e DNS de rede. Você pode usar ferramentas tradicionais de solução de problemas, como netstat, nslookupou tcping. Além disso, você pode examinar as configurações de DHCP (Protocolo de Configuração de Host Dinâmico) e DNS do adaptador de rede. Se houver NICs, você terá mais recursos de solução de problemas que permitem executar verificações de conectividade usando o Observador de Rede do Azure.

Acesso ao operador

Assim como a arquitetura de linha de base , há suporte para o acesso operacional por meio do Azure Bastion nessa arquitetura.

No entanto, a arquitetura de linha de base implanta o Azure Bastion como parte da carga de trabalho. Para uma organização típica que adota zonas de destino do Azure, eles implantam o Azure Bastion como recursos centrais para cada região. A equipe de plataforma possui e mantém o Azure Bastion e todas as cargas de trabalho na organização a compartilham. Para demonstrar esse caso de uso nessa arquitetura, o Azure Bastion está na rede do hub na assinatura de conectividade.

Identidade do operador

Essa arquitetura usa a mesma extensão de autenticação que a arquitetura de linha de base .

Sempre comece com o princípio de acesso de privilégio mínimo e granular a uma tarefa em vez de acesso de longa data. No contexto da zona de destino, aproveite o suporte JIT (just-in-time) que a equipe de plataforma gerencia.

Conformidade de patch e atualizações do sistema operacional

A arquitetura de linha de base descreve uma abordagem autônoma para aplicação de patch e atualizações. Quando a carga de trabalho é integrada às zonas de destino, essa abordagem pode mudar. A equipe da plataforma pode ditar as operações de aplicação de patch para que todas as cargas de trabalho estejam em conformidade com os requisitos organizacionais.

Verifique se o processo de aplicação de patch inclui todos os componentes que você adiciona à arquitetura. Por exemplo, se você optar por adicionar VMs do agente de build para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos, essas VMs deverão estar em conformidade com os requisitos da plataforma.

Monitorização

A plataforma de zona de destino do Azure fornece recursos de observabilidade compartilhados como parte da assinatura de gerenciamento. No entanto, recomendamos que você provisione seus próprios recursos de monitoramento para facilitar as responsabilidades de propriedade da carga de trabalho. Essa abordagem é consistente com a arquitetura de linha de base .

A equipe de carga de trabalho provisiona os recursos de monitoramento, que incluem:

• Application Insights como o serviço APM (monitoramento de desempenho do aplicativo) para a equipe de carga de trabalho.

• O workspace do Log Analytics como o coletor unificado para todos os logs e métricas coletados dos recursos do Azure de propriedade da carga de trabalho e do código do aplicativo.

Baixe um de arquivo do Visio dessa arquitetura.

Semelhante à linha de base, todos os recursos são configurados para enviar logs de Diagnóstico do Azure para o workspace do Log Analytics que a equipe de carga de trabalho provisiona como parte da implantação de iaC (infraestrutura como código) dos recursos. Talvez você também precise enviar logs para um workspace central do Log Analytics. Nas zonas de destino do Azure, esse workspace está na assinatura de gerenciamento.

A equipe de plataforma também pode ter políticas DINE que podem ser usadas para configurar o Diagnóstico para enviar logs para suas assinaturas de gerenciamento centralizadas. É importante garantir que sua implementação não restrinja os fluxos de log adicionais.

Correlacionar dados de vários coletores

Os logs e as métricas da carga de trabalho e seus componentes de infraestrutura são armazenados no workspace do Log Analytics da carga de trabalho. No entanto, os logs e as métricas que os serviços centralizados, como o Firewall do Azure, o Microsoft Entra ID e o Azure Bastion, geram são armazenados em um workspace central do Log Analytics. Correlacionar dados de vários coletores pode ser uma tarefa complexa.

Os dados correlacionados geralmente são usados durante a resposta a incidentes. Se houver um problema com a correlação de dados de vários coletores, verifique se o runbook de triagem dessa arquitetura o abordará e incluirá pontos organizacionais de contato se o problema se estender além dos recursos de carga de trabalho. Os administradores de carga de trabalho podem exigir assistência dos administradores da plataforma para correlacionar entradas de log de rede corporativa, segurança ou outros serviços de plataforma.

Azure Policy

A equipe de plataforma provavelmente aplica políticas que afetam a implantação da carga de trabalho. Eles geralmente aplicam políticas DINE para lidar com implantações automatizadas em uma assinatura da zona de destino do aplicativo. As políticas DINE podem modificar recursos de carga de trabalho ou adicionar recursos à sua implantação, o que pode resultar em uma discrepância entre os recursos que são implantados declarativamente por meio do modelo de carga de trabalho e dos recursos que as solicitações de processamento realmente usam. Uma solução típica é corrigir essas alterações com abordagens imperativas, que não são ideais.

Para evitar essa discrepância, incorpore e teste preventivamente as alterações iniciadas pela plataforma em seus modelos de IaC. Se a equipe da plataforma usar políticas do Azure que estão em conflito com os requisitos do aplicativo, você poderá negociar uma resolução com a equipe de plataforma.

Gerenciar alterações ao longo do tempo

Os serviços e operações fornecidos pela plataforma são considerados dependências externas nessa arquitetura. A equipe da plataforma continua aplicando alterações, integrando usuários e aplicando controles de custo. A equipe de plataforma, que atende a organização, pode não priorizar cargas de trabalho individuais. As alterações nessas dependências, sejam elas alterações de imagem dourada, modificações de firewall, aplicação de patch automatizada ou alterações de regra, podem afetar várias cargas de trabalho.

Portanto, as equipes de carga de trabalho e plataforma devem se comunicar de forma eficiente e oportuna para gerenciar todas as dependências externas. É importante testar as alterações, para que elas não afetem negativamente as cargas de trabalho.

Alterações de plataforma que afetam a carga de trabalho

Nessa arquitetura, a equipe de plataforma gerencia os recursos a seguir. As alterações nesses recursos podem afetar potencialmente a confiabilidade, a segurança, as operações e os destinos de desempenho da carga de trabalho. É importante avaliar essas alterações antes que a equipe da plataforma as coloque em vigor para determinar como elas afetam a carga de trabalho.

• políticas do Azure: as alterações nas políticas do Azure podem afetar os recursos de carga de trabalho e suas dependências. Por exemplo, pode haver alterações de política diretas ou movimentação da zona de destino em uma nova hierarquia de grupo de gerenciamento. Essas alterações podem passar despercebidas até que haja uma nova implantação, portanto, é importante testá-las minuciosamente.

• regras de Firewall: as modificações nas regras de firewall podem afetar a rede virtual da carga de trabalho ou as regras que se aplicam amplamente em todo o tráfego. Essas modificações podem resultar em tráfego bloqueado e até mesmo falhas no processo silencioso, como a aplicação com falha de patches do sistema operacional. Esses possíveis problemas se aplicam ao firewall do Azure de saída e às regras NSG aplicadas pelo Gerenciador de Rede Virtual do Azure.

• recursos compartilhados: alterações na SKU ou recursos em recursos compartilhados podem afetar a carga de trabalho.

• Roteamento na rede do hub: alterações na natureza transitiva do roteamento no hub podem afetar potencialmente a funcionalidade da carga de trabalho se uma carga de trabalho depender do roteamento para outras redes virtuais.

• host do Azure Bastion: alterações na disponibilidade ou configuração do host do Azure Bastion podem afetar as operações de carga de trabalho. Verifique se as alterações no padrão de acesso do jump box têm uma rotina eficaz, ad hoc e acesso de emergência.

• Alterações de propriedade: comunique quaisquer alterações na propriedade e pontos de contato para a equipe de carga de trabalho, pois elas podem afetar o gerenciamento e as solicitações de suporte da carga de trabalho.

Alterações na carga de trabalho que afetam a plataforma

Os exemplos a seguir são alterações de carga de trabalho nessa arquitetura que você deve comunicar à equipe de plataforma. É importante que a equipe de plataforma valide os destinos de confiabilidade, segurança, operações e desempenho do serviço de plataforma em relação às novas alterações da equipe de carga de trabalho antes de entrarem em vigor.

• saída de rede: monitore qualquer aumento significativo na saída da rede para impedir que a carga de trabalho se torne um vizinho barulhento em dispositivos de rede. Esse problema pode afetar potencialmente os destinos de desempenho ou confiabilidade de outras cargas de trabalho.

• de acesso público: as alterações no acesso público aos componentes da carga de trabalho podem exigir testes adicionais. A equipe de plataforma pode realocar a carga de trabalho para um grupo de gerenciamento diferente.

• Classificação de crítica comercial: se houver alterações nos SLAs (contratos de nível de serviço) da carga de trabalho, talvez seja necessário uma nova abordagem de colaboração entre as equipes de plataforma e carga de trabalho.

• Alterações de propriedade: comunique as alterações de propriedade e pontos de contato com a equipe da plataforma.

Alterações de requisitos de negócios de carga de trabalho

Para manter os SLOs (objetivos de nível de serviço) da carga de trabalho, a equipe da plataforma pode precisar estar envolvida em alterações na arquitetura da carga de trabalho. Essas alterações podem exigir o gerenciamento de alterações da equipe da plataforma ou a validação de que a governança existente dá suporte aos requisitos alterados.

Por exemplo, comunique alterações em qualquer fluxo de saída não permitido anteriormente para que a equipe da plataforma possa adicionar esse fluxo no firewall, no Virtual Network Manager ou em outros componentes para dar suporte ao tráfego necessário. Por outro lado, se um fluxo de saída permitido anteriormente não for mais necessário, a equipe da plataforma deverá bloquear esse fluxo para manter a segurança da carga de trabalho. Comunique também alterações no roteamento para outras redes virtuais ou pontos de extremidade entre locais ou alterações nos componentes de arquitetura. Cada recurso está sujeito a políticas e potencialmente controle de firewall de saída.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você faz aos seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design parade confiabilidade.

Essa arquitetura está alinhada com as garantias de confiabilidade na arquitetura de linha de base .

Destinos de confiabilidade

O SLO composto máximo possível é menor do que o slo composto de linha de base devido a componentes como o controle de rede de saída. Esses componentes, comuns em ambientes de zona de destino, não são exclusivos dessa arquitetura. O SLO será reduzido da mesma forma se a equipe de carga de trabalho controlar diretamente esses serviços do Azure.

Apesar de um SLO máximo menor possível, o aspecto de confiabilidade principal é a divisão de componentes de carga de trabalho entre equipes funcionais. Com esse método, a equipe de carga de trabalho se beneficia de uma equipe especializada que se concentra na infraestrutura crítica operacional que essa carga de trabalho e outras cargas de trabalho usam.

Para obter mais informações, consulte Recomendações para definir destinos de confiabilidade.

Dependências críticas

Exiba todas as funcionalidades que a carga de trabalho executa na plataforma e na zona de destino do aplicativo como dependências. Os planos de resposta a incidentes exigem que a equipe de carga de trabalho esteja ciente do ponto e do método das informações de contato para essas dependências. Inclua também essas dependências na FMA (análise de modo de falha) da carga de trabalho.

Para essa arquitetura, considere as seguintes dependências:

• firewall de saída: o firewall de saída centralizado, compartilhado por várias cargas de trabalho, passa por alterações não relacionadas à carga de trabalho.

• esgotamento da porta de rede: picos de uso de todas as cargas de trabalho que compartilham o dispositivo de rede podem levar à saturação de rede ou esgotamento da porta no firewall de saída.

• políticas DINE: políticas DINE para zonas DNS privadas DNS do Azure (ou qualquer outra dependência fornecida pela plataforma) são melhor esforço, sem SLA na execução. Um atraso na configuração de DNS pode causar atrasos na preparação de um aplicativo para lidar com o tráfego.

• políticas de grupo de gerenciamento: políticas consistentes entre ambientes são fundamentais para a confiabilidade. Verifique se os ambientes de pré-produção são semelhantes aos ambientes de produção para fornecer testes precisos e evitar desvios específicos do ambiente que podem bloquear uma implantação ou escala. Para obter mais informações, consulte Gerenciar ambientes de desenvolvimento de aplicativos em zonas de destino do Azure.

Muitas dessas considerações podem existir sem zonas de destino do Azure, mas as equipes de carga de trabalho e plataforma precisam resolver esses problemas de forma colaborativa para garantir que as necessidades sejam atendidas.

Para obter mais informações, consulte Recomendações para executar a análise do modo de falha.

Segurança

A segurança fornece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design parade segurança.

As considerações de segurança para essa arquitetura são transferidas da arquitetura de linha de base . As recomendações nas seções a seguir são baseadas na lista de verificação de revisão de design de segurança nodo Well-Architected Framework.

Controles de rede

Configure corretamente os controles de rede para garantir que sua carga de trabalho esteja segura.

Tráfego de entrada

Você pode isolar sua carga de trabalho de outros spokes de carga de trabalho em sua organização por meio de NSGs em suas sub-redes ou da natureza ou controles nãotransitivos no hub regional. Construa NSGs abrangentes que permitam apenas os requisitos de rede de entrada de seu aplicativo e sua infraestrutura. Recomendamos que você não dependa apenas da natureza nãotransitiva da rede do hub para segurança.

A equipe de plataforma provavelmente implementa políticas do Azure para garantir que o Gateway de Aplicativo tenha o Firewall do Aplicativo Web definido para modo de negação, para restringir o número de IPs públicos disponíveis para sua assinatura e outras verificações. Além dessas políticas, a equipe de carga de trabalho deve ser proprietária da responsabilidade de implantar políticas centradas na carga de trabalho que reforçam a postura de segurança de entrada.

A tabela a seguir mostra exemplos de controles de entrada nessa arquitetura.

Fonte	Propósito	Controle de carga de trabalho	Controle de plataforma
Internet	Fluxos de tráfego do usuário	Canaliza todas as solicitações por meio de um NSG, firewall de aplicativo Web e regras de roteamento antes de permitir que o tráfego público faça a transição para o tráfego privado que insira as VMs front-end	Nenhum
Azure Bastion	Acesso de operador a VMs	NSG em sub-redes de VM que bloqueia todo o tráfego para portas de acesso remoto, a menos que seja proveniente da sub-rede designada do Azure Bastion da plataforma	Nenhum
Outros spokes	Nenhum	Bloqueado por meio de regras NSG	Roteamento não retransitivo ou regras do Firewall do Azure no caso de um hub protegido da WAN Virtual do Azure

Tráfego de saída

Aplique regras NSG que expressam os requisitos de conectividade de saída necessários da sua solução e negam todo o resto. Não dependa apenas dos controles de rede do hub. Como um operador de carga de trabalho, você tem a responsabilidade de interromper o tráfego de saída indesejado tão próximo da origem quanto praticável.

Lembre-se de que, embora você possua sua sub-rede dentro da rede virtual, a equipe da plataforma provavelmente criou regras de firewall para representar especificamente seus requisitos capturados como parte do processo de venda automática de assinatura. Verifique se as alterações nas sub-redes e no posicionamento de recursos ao longo do tempo de vida da arquitetura ainda são compatíveis com sua solicitação original. Ou você pode trabalhar com sua equipe de rede para garantir a continuidade do controle de saída de menor acesso.

A tabela a seguir mostra exemplos de saída nessa arquitetura.

Extremidade	Propósito	Controle de carga de trabalho (NSG)	Controle de plataforma (hub)
ntp.ubuntu.com	O Protocolo de Tempo de Rede (NTP) para VMs linux	UDP/123 à Internet na sub-rede de VM de front-end (o firewall de saída restringe essa abertura ampla)	Subsídio de regra de rede de firewall para o mesmo que o controle de carga de trabalho
Pontos de extremidade do Windows Update	Funcionalidade do Windows Update de servidores Microsoft	TCP/443 e TCP/80 para a Internet na sub-rede de VM de back-end (o firewall de saída restringe essa abertura ampla)	Regra de subsídio de firewall com marca FQDN de WindowsUpdate
Monitorar pontos de extremidade do agente	Tráfego necessário para a extensão Monitor em VMs	TCP/443 para a Internet em ambas as sub-redes de VM (o firewall de saída restringe essa abertura ampla)	Subsídios de regra de aplicativo de firewall necessários para todos os FQDNs específicos no TCP/443
nginx.org	Para instalar o Nginx (um componente de aplicativo de exemplo) diretamente do fornecedor	TCP/443 à Internet na sub-rede de VM de front-end (o firewall de saída restringe essa abertura ampla)	Subsídio de regra de aplicativo de firewall necessário para nginx.org no TCP/443
Key Vault	Para importar certificados TLS (Transport Layer Security) no Gateway de Aplicativo e em VMs	- TCP/443 para uma sub-rede de ponto de extremidade privado de ambas as sub-redes de VM para uma sub-rede de ponto de extremidade privado - TCP/443 para uma sub-rede de ponto de extremidade privado de uma sub-rede do Gateway de Aplicativo - TCP/443 de VMs marcadas com uma designação do ASG (grupo de segurança de aplicativo) necessária e sub-rede do Gateway de Aplicativo	Nenhum

Proteção contra DDoS

Determine quem é responsável por aplicar o plano de Proteção contra DDoS que abrange todos os IPs públicos da sua solução. A equipe da plataforma pode usar planos de proteção de IP ou até mesmo usar o Azure Policy para impor planos de proteção de rede virtual. Essa arquitetura deve ter cobertura porque envolve um IP público para entrada da Internet.

Para obter mais informações, consulte Recomendações parade rede e conectividade.

Gerenciamento de segredo

Para o gerenciamento de segredos, essa arquitetura segue a arquitetura de linha de base .

Como uma equipe de carga de trabalho, continue mantendo seus segredos em sua instância do Key Vault. Implante mais instâncias conforme necessário para dar suporte às operações de aplicativo e infraestrutura.

Para obter mais informações, consulte Recomendações para proteger os segredos do aplicativo.

Otimização de custos

A Otimização de Custos trata-se de procurar maneiras de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design parade Otimização de Custos.

Para os recursos de carga de trabalho, as estratégias de otimização de custo na arquitetura de linha de base também se aplicam a essa arquitetura.

Essa arquitetura se beneficia muito dos recursos da plataforma de zona de destino do Azure. Mesmo se você usar esses recursos por meio de um modelo de chargeback, a segurança adicional e a conectividade entre locais serão mais econômicas do que o autogerenciamento desses recursos.

A equipe de plataforma gerencia os seguintes recursos nesta arquitetura. Esses recursos geralmente são baseados em consumo (chargeback) ou potencialmente gratuitos para a equipe de carga de trabalho.

• Azure Firewall
• SIEM (gerenciamento de eventos e informações de segurança)
• Hosts do Azure Bastion
• Conectividade entre locais, como o ExpressRoute

Aproveite outras ofertas centralizadas da sua equipe de plataforma para estender esses benefícios para sua carga de trabalho sem comprometer seu SLO, o RTO (objetivo de tempo de recuperação) ou o RPO (objetivo de ponto de recuperação).

Para obter mais informações, consulte Recomendações para coletar e revisar dados de custo.

Implantar esse cenário

Uma implantação para essa arquitetura de referência está disponível no GitHub.

Próxima etapa

Examine a colaboração e os detalhes técnicos compartilhados entre uma equipe de carga de trabalho e equipes de plataforma.

de venda automática de assinatura