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

A arquitetura neste artigo expande a arquitetura de linha de base da máquina virtual (VM) para lidar com alterações e 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 gerenciados centralmente por uma equipe de plataforma. Esses recursos incluem recursos de rede para conectividade entre locais, gerenciamento de acesso a identidades e políticas. Este exemplo presume que a organização adota zonas de destino do Azure para aplicar governança consistente e economia em várias cargas de trabalho.

Como proprietário da carga de trabalho, você pode transferir o gerenciamento de recursos compartilhados para equipes centrais; assim, poderá focar esforços de desenvolvimento da carga de trabalho. Este artigo apresenta a perspectiva da equipe de carga de trabalho. Foram especificadas as recomendações para a equipe da plataforma.

Layout do artigo

Arquitetura	Decisão de design	Abordagem do Azure Well-Architected Framework
▪ Diagrama da arquitetura ▪ Recursos de carga de trabalho ▪ Recursos federados	▪ Configuração de assinatura ▪ Requisitos de rede ▪ Alterações no design da rede a partir da linha de base ▪ Monitoramento ▪ Conformidade com os patches ▪ Governança organizacional ▪ Gerenciamento de alterações	▪ Confiabilidade ▪ Segurança ▪ Otimização de custos

Arquitetura

Baixe um Arquivo 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 do DevOps precisam ter uma ótima compreensão dessa divisão de responsabilidades para entender o que está ou não sob influência ou controle direto.

Recursos de propriedade da equipe de carga de trabalho

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

• As Máquinas Virtuais do Azure são a plataforma de aplicativos. Os recursos de computação estão distribuídos entre zonas de destino.

• O Azure Load Balancer é usado no balanceamento privado da carga do tráfego das VMs front-end para back-end. O balanceador de carga distribui o tráfego para VMs em zonas.

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

• O Azure Key Vault é usado para armazenar segredos e certificados de aplicativos.

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

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

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

• Sub-redes de rede virtual spoke e os NSGs (grupos de segurança de rede) inseridos 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 de plataforma como serviço (PaaS) e as zonas DNS privadas necessárias para esses pontos de extremidade.

• O Azure Managed Disks armazena arquivos de log nos servidores back-end, e os dados são retidos mesmo quando há reinicialização de VMs. Os servidores front-end têm discos anexados que podem ser usados para implantar seu aplicativo sem estado.

Recursos de propriedade da equipe da plataforma

A equipe da plataforma possui e mantém esses recursos centralizados. Essa arquitetura supõe que esses recursos são pré-provisionados e os considera dependências.

• O Firewall do Azure na rede de 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 apresenta restrições ao tráfego de saída para a Internet.

• O Azure Bastion na rede de hub fornece acesso operacional seguro a VMs de carga de trabalho. Na arquitetura de linha de base, a equipe de carga de trabalho é proprietária desse componente.

• A carga de trabalho é implantada na rede virtual spoke.

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

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

Configuração de assinatura

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

Sua equipe de carga de trabalho deve incluir informações detalhadas sobre o espaço de rede que sua carga de trabalho precisa; assim, a equipe da plataforma pode alocar os recursos necessários. Sua equipe determina os requisitos e a equipe da 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 da plataforma atribui um grupo de gerenciamento apropriado com base na importância dos negócios e nos 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 da plataforma os implementa.

Por exemplo, considera-se os grupos de gerenciamento nos cenários de aplicativo para a arquitetura de linha de base:

• Aplicativos privados, como aplicativos internos de linha de negócios ou soluções de negócios prontas para uso (COTS), que costumam estar localizados no grupo de gerenciamento Corp de zonas de destino do Azure.

• Aplicativos públicos, como em aplicativos voltados para a Internet, que costumam estar sob o 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 orientações sobre a configuração inicial da assinatura. Mas, a equipe da plataforma em geral faz alterações nos serviços centralizados para atender aos requisitos perdidos ou alterados. As alterações na plataforma têm um efeito mais amplo em todas as equipes de carga de trabalho.

Assim, a equipe da plataforma deve garantir que todas as cargas de trabalho de VM estejam preparadas para alterações, e devem estar cientes do ciclo de vida da solução baseada em VM e do ciclo de teste. Para saber mais, confira Gerenciar alterações ao longo do tempo.

Requisitos e processamentos 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 requisitos de rede a seguir que você deve comunicar à equipe da 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, só é necessário um spoke dedicado. 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 conta os requisitos operacionais e o crescimento esperado da carga de trabalho. Por exemplo, se você pretende implementar atualizações azuis/verdes ou canárias, o tamanho máximo deve considerar o espaço exigido por suas implantações lado a lado.

  Alterações futuras podem exigir mais espaço IP, o que pode estar desalinhado com a alocação atual. A integração desses espaços pode trazer uma complexidade extra. Seja proativo e solicite recursos de rede suficientes no início para garantir que o espaço alocado acomode 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 de spoke e de hub sejam provisionadas na mesma região. Redes em regiões distintas podem levar a problemas de latência devido ao tráfego que cruza fronteiras regionais e também podem gerar custos adicionais 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 à 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 (conversação), a equipe da plataforma deve garantir que existam portas suficientes disponíveis para evitar a exaustão. Eles podem adicionar endereços IP ao firewall centralizado para dar suporte ao tráfego ou configurar um gateway NAT (Network Address Translation) 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 (ruído de fundo), a equipe da plataforma deve usar recursos com eficiência na organização.

  A equipe da plataforma precisa entender claramente dependências. Por exemplo, talvez sua carga de trabalho precise de acesso a um banco de dados de propriedade de outra equipe, ou sua carga de trabalho tenha tráfego entre locais. Sua carga de trabalho tem dependências fora do Azure? É importante que a equipe da plataforma conheça essas informações.

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

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

• Acesso do operador: se houver grupos de segurança do Microsoft Entra ID usados pelos operadores para acessar as VMs via Azure Bastion, informe a equipe da plataforma. O Azure Bastion costuma ser um recurso central. É essencial garantir o suporte dos grupos de segurança e das VMs ao protocolo seguro.

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

• Os IPs públicos: informe a equipe da plataforma sobre o perfil de tráfego de entrada, incluindo endereços IP públicos previstos. Nessa arquitetura, somente o tráfego originado na Internet visa o IP público no Application Gateway. A equipe da plataforma deve informar à equipe de carga de trabalho se esses IPs estão sob um plano de Proteção contra DDoS do Azure ou se isso é responsabilidade da equipe de carga de trabalho.

  Nessa arquitetura, há outro IP público para acesso operacional via Azure Bastion. A equipe da plataforma possui esse IP público e ele está inscrita em um serviço, como Proteção contra DDoS, também gerenciado pela equipe da plataforma.

Opções de design de VM

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

Uma organização pode impor requisitos de conformidade à equipe de carga de trabalho que exige o uso de imagens de VM específicas. Considerando esses requisitos, a equipe da plataforma pode gerenciar um conjunto de imagens padronizadas, frequentemente chamadas de imagens douradas, que são criadas para uso na 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 SO aprovadas ou artefatos de carga de trabalho. Ao escolher uma imagem do SO 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 atendidos pela carga de trabalho.

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 da plataforma determina a topologia de rede. Considera-se a topologia hub-spoke nessa arquitetura.

Baixe um Arquivo Visio dessa arquitetura.

• Rede virtual de hub: um hub regional contém serviços centralizados que se comunicam com recursos de carga de trabalho na mesma região. Para saber mais, confira Recursos de propriedade da equipe da plataforma. É recomendável colocar o hub na assinatura de conectividade.

• Rede virtual spoke: nesta arquitetura, a única rede virtual da arquitetura de linha de base é a rede spoke. Ela é emparelhada para a rede de 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 sub-redes.

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

Sub-redes da 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 o Gateway de Aplicativo, VMs front-end, o balanceador de carga, VMs back-end e pontos de extremidade privados.

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

Com essa abordagem, a equipe da plataforma pode otimizar gastos organizacionais em geral por meio de serviços centralizados, em vez de implantar controles de segurança redundantes para cada carga de trabalho na organização. Nessa arquitetura, o Firewall do Azure é um exemplo de um 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. É recomendável uma abordagem centralizada para o gerenciamento de firewall.

Tráfego de entrada

O fluxo de tráfego de entrada permanece igual ao da arquitetura de linha de base.

O proprietário da carga de trabalho é responsável por recursos relacionados à entrada da Internet pública em sua carga de trabalho. Por exemplo, nessa arquitetura, o Gateway de Aplicativo e o IP público são colocados na rede spoke e não na rede hub. Algumas organizações podem colocar recursos com tráfego de entrada em uma assinatura de conectividade usando uma implementação centralizada desmilitarizada (DMZ). 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 via Azure Load Balancer, mas esse tráfego não é restrito.

Esse design é distinto nessa arquitetura. Todo o tráfego que sai da rede virtual spoke é roteado por meio da rede hub emparelhada via 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 Arquivo Visio dessa arquitetura.

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

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 da plataforma permite o tráfego necessário, e todo o tráfego de saída não comunicado provavelmente é negado.

Controlar o tráfego de saída é mais do que simplesmente garantir a permissão do tráfego esperado. Trata-se também de garantir a permissão somente do tráfego esperado. O tráfego de saída não comunicado provavelmente é negado por padrão, mas, por questões de segurança da carga de trabalho, convém garantir o roteamento correto do tráfego.

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

Sua organização pode ter requisitos que desestimulam o uso de padrões de arquitetura, que usam IPs públicos de propriedade da carga de trabalho para saída. Nesse caso, você pode usar o Azure Policy para negar IPs públicos em placas de interface de rede (NICs) de VM e 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 operar com o provedor DNS. A equipe de carga de trabalho deve compreender claramente os requisitos e o gerenciamento de zonas DNS privadas na assinatura que a equipe da plataforma fornece. As zonas DNS privadas costumam ser gerenciadas em grande escala com políticas DINE, permitindo que o Firewall do Azure funcione como um proxy DNS confiável e seja compatível com regras de rede FQDN (nome de domínio totalmente qualificado).

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

Testes 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, nslookup ou tcping. Além disso, você pode examinar as configurações de DHCP (Dynamic Host Configuration Protocol) 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 por meio do Observador de Rede do Azure.

Acesso do operador

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

Mas, 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 da plataforma possui e mantém o Azure Bastion, e todas as cargas de trabalho o compartilham na organização. Para demonstrar esse caso de uso nessa arquitetura, o Azure Bastion está na rede de 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 privilégios mínimos e acesso granular a uma tarefa, em vez de acesso de longa duração. No contexto da zona de destino, aproveite o suporte just-in-time (JIT) gerenciado pela equipe da plataforma.

Conformidade com patches e atualizações do SO

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 com zonas de destino, é possível que essa abordagem mude. A equipe da plataforma pode ditar as operações de aplicação de patches para que todas as cargas de trabalho cumpram requisitos organizacionais.

Verifique se o processo de aplicação de patches inclui todos os componentes adicionados à arquitetura. Por exemplo, se você optar por adicionar VMs de agente de compilação para automatizar a implantação, o dimensionamento e o gerenciamento de aplicativos, essas VMs deverão cumprir os requisitos da plataforma.

Monitoramento

A plataforma de zona de destino do Azure oferece recursos de capacidade de observação compartilhados como parte da assinatura de gerenciamento. Mas, é recomendável provisionar 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, incluindo:

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

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

Baixe um Arquivo Visio dessa arquitetura.

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

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

Correlacione dados de vários coletores

Os logs e as métricas da carga de trabalho e os componentes de infraestrutura são armazenados no espaço de trabalho do Log Analytics da carga de trabalho. Mas, os logs e as métricas gerados pelos serviços centralizados, como o Firewall do Azure, a ID do Microsoft Entra e o Azure Bastion, são armazenados em um espaço de trabalho do Log Analytics central. Correlacionar dados de múltiplos coletores pode ser uma tarefa complexa.

Dados correlacionados costumam ser 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 aborda e inclui pontos de contato organizacionais caso o problema se estenda além dos recursos de carga de trabalho. Os administradores de carga de trabalho podem exigir assistência dos administradores de plataforma para correlacionar entradas de log de rede corporativa, segurança ou outros serviços de plataforma.

Azure Policy

É provável que a equipe da plataforma aplique políticas que afetem a implantação da carga de trabalho. Em geral, eles aplicam políticas DINE para tratar implantações automatizadas em uma assinatura de zona de destino de aplicativo. As políticas DINE podem alterar recursos de carga de trabalho ou adicionar recursos à sua implantação, resultando em uma discrepância entre os recursos que são implantados de forma declarativa por meio do modelo de carga de trabalho e os recursos que as solicitações de processamento de fato usam. Uma solução típica é corrigir essas mudanças com abordagens imperativas, que não é o ideal.

Para evitar essa discrepância, incorpore e teste de maneira preventiva as alterações iniciadas pela plataforma em seus modelos IaC. Se a equipe da plataforma usar políticas do Azure conflitantes com os requisitos do aplicativo, você poderá negociar uma resolução com a equipe da 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 a aplicar alterações, integrar usuários e aplicar controles de custos. A equipe da plataforma, que atende à 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 patches automatizada ou alterações de regras, 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. É essencial testar as alterações para que não afetem de forma negativa as cargas de trabalho.

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

Nessa arquitetura, a equipe da plataforma gerencia os recursos a seguir. As alterações nesses recursos têm o potencial de afetar a confiabilidade, a segurança, as operações e as metas de desempenho da carga de trabalho. É importante avaliar essas alterações antes que a equipe da plataforma as coloque em prática para determinar como elas afetam a carga de trabalho.

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

• Regras de firewall: modificações em regras de firewall podem afetar a rede virtual da carga de trabalho ou regras que se aplicam amplamente ao tráfego inteiro. Essas modificações podem resultar em tráfego bloqueado e até mesmo falhas silenciosas no processo, como falha na aplicação de patches do sistema operacional. Esses problemas em potencial 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 em recursos compartilhados podem afetar a carga de trabalho.

• Roteamento na rede de hub: alterações na natureza transitiva do roteamento no hub podem afetar potencialmente a funcionalidade de 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 operações de carga de trabalho. Certifique-se de que as alterações no padrão de acesso à caixa de salto tenham acesso efetivo de rotina, ad-hoc e de emergência.

• Alterações de propriedade: comunique alterações na propriedade e nos pontos de contato à equipe de carga de trabalho, pois elas podem afetar as solicitações de gerenciamento e 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 a serem transmitidas à equipe da plataforma. É importante que a equipe da plataforma valide as metas de confiabilidade, segurança, operações e desempenho do serviço da plataforma em relação às novas alterações da equipe de carga de trabalho antes de entrarem em vigor.

• Saída de rede: monitore aumentos significativos na saída de rede para evitar 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.

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

• Classificação de criticidade dos negócios: se houver alterações nos SLAs (contratos de nível de serviço) da carga de trabalho, talvez seja necessária uma nova abordagem de colaboração entre a plataforma e as equipes de carga de trabalho.

• Mudanças de propriedade: comunique as mudanças de propriedade e pontos de contato à equipe da plataforma.

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

Para manter os SLOs (objetivos de nível de serviço) da carga de trabalho, é necessário o envolvimento da equipe da plataforma 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 a qualquer fluxo de saída antes não permitido 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 antes permitido não for mais necessário, a equipe da plataforma deverá bloquear esse fluxo para manter a segurança da carga de trabalho. Também comunique alterações no roteamento para outras redes virtuais ou pontos de extremidade entre locais ou alterações nos componentes da arquitetura. Cada recurso está sujeito a políticas e, possivelmente, ao controle de firewall de saída.

Confiabilidade

Essa arquitetura se alinha com as garantias de confiabilidade na arquitetura de linha de base.

Metas 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á igualmente reduzido se a equipe de carga de trabalho controlar diretamente esses serviços do Azure.

Apesar de um SLO máximo possível mais baixo, o principal aspecto de confiabilidade é a divisão dos componentes da carga de trabalho entre as equipes funcionais. Com esse método, a equipe de carga de trabalho se beneficia de uma equipe especializada que se concentra na operação da infraestrutura essencial utilizada por essa carga de trabalho e outras cargas de trabalho.

Para saber mais, confira Recomendações para definir destinos de confiabilidade.

Dependências essenciais

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 de informações de contato para essas dependências. Inclua também essas dependências na análise de modo de falha (FMA) da carga de trabalho.

Para essa arquitetura, considere estas 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 relativas à carga de trabalho.

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

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

• Políticas de grupo de gerenciamento: políticas consistentes entre ambientes são essenciais para a confiabilidade. Verifique se os ambientes de pré-produção são semelhantes a ambientes de produção para fornecer testes precisos e evitar desvios específicos do ambiente que possam bloquear uma implantação ou escala. Para saber mais, confira 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 em colaboração para garantir que o atendimento às necessidades.

Para obter mais informações, consulte Recomendações para executar uma análise de modos de falha.

Segurança

As considerações de segurança dessa arquitetura derivam da arquitetura de linha de base. As recomendações nas seções a seguir se baseiam na lista de verificação de revisão de design de segurança no Well-Architected Framework.

Controles de rede

Configure corretamente os controles de rede para garantir a segurança de sua carga de trabalho.

Tráfego de entrada

Você pode isolar sua carga de trabalho de outros comandos de carga de trabalho na sua organização via NSGs em sub-redes ou da natureza não transitiva ou de controles no hub regional. Construa NSGs abrangentes que permitam apenas os requisitos de rede de entrada de seu aplicativo e infraestrutura. É recomendável não contar apenas com a natureza não transitiva da rede de hub para segurança.

A equipe da plataforma provavelmente implementa políticas do Azure para garantir que o Gateway de Aplicativo tenha o Firewall de Aplicativo Web definido como 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 ter a 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.

Origem	Finalidade	Controle de carga de trabalho	Controle da plataforma
Internet	Fluxos de tráfego de usuários	Afunila 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 entra nas VMs front-end	Nenhum
Azure Bastion	Acesso do operador às VMs	NSG em sub-redes de VM que bloqueia todo o tráfego para portas de acesso remoto, a menos que seja originado da sub-rede do Azure Bastion designada da plataforma	Nenhum
Outros spokes	Nenhum	Bloqueado via regras NSG	Roteamento não transitivo ou regras do Firewall do Azure no caso de um hub seguro de WAN Virtual do Azure

Tráfego de saída

Aplique regras NSG que expressem os requisitos de conectividade de saída necessários da sua solução e negue todos os restantes. Não confie apenas nos controles de rede do hub. Como operador de carga de trabalho, é sua função interromper o tráfego de saída indesejado o mais próximo possível da origem.

Lembre-se de que, embora você possua sua sub-rede na 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 o posicionamento de recursos ao longo do tempo de vida da arquitetura ainda são compatíveis com a solicitação original. Ou você pode trabalhar com sua equipe de rede para garantir a continuidade do controle de saída de acesso mínimo.

A tabela a seguir mostra exemplos da entrada nessa arquitetura.

Ponto de extremidade	Finalidade	Controle de carga de trabalho (NSG)	Controle de plataforma (hub)
ntp.ubuntu.com	O protocolo NTP (Network Time Protocol) para VMs linux	UDP/123 para a Internet na sub-rede da VM front-end (o firewall de saída estreita essa ampla abertura)	Permissão de regra de rede de firewall igual ao 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 da VM back-end (o firewall de saída reduz essa ampla abertura)	Regra de permissão de firewall com marcação FQDN de WindowsUpdate
Monitorar pontos de extremidade do agente	Tráfego necessário para a extensão do Monitor em VMs	TCP/443 para a Internet em ambas as sub-redes da VM (o firewall de saída estreita essa ampla abertura)	Permissões de regra de aplicativo de firewall necessárias para todos os FQDNs específicos no TCP/443
nginx.org	Para instalar o Nginx (um exemplo de componente de aplicativo) diretamente do fornecedor	TCP/443 para a Internet na sub-rede da VM front-end (o firewall de saída estreita essa ampla abertura)	Permissão de regra de aplicativo de firewall necessária para nginx.org no TCP/443
Key Vault	Para importar certificados TLS (Transport Layer Security) no Gateway de Aplicativo e VMs	- TCP/443 para uma sub-rede de ponto de extremidade privada de ambas as sub-redes de VM para uma sub-rede de ponto de extremidade privada - TCP/443 para uma sub-rede de ponto de extremidade privada de uma sub-rede do Gateway de Aplicativo - TCP/443 de VMs marcadas com uma designação 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 pela aplicação do 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 IP ou até mesmo usar a Política do Azure 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 saber mais, consulte Recomendações para rede e conectividade.

Gerenciamento de segredos

Para gerenciamento secreto, essa arquitetura segue a arquitetura de linha de base.

Como uma equipe de carga de trabalho, continue mantendo seus segredos na instância do Cofre de Chaves. Implante mais instâncias conforme necessário em apoio às operações de aplicativos e infraestrutura.

Para saber mais, confira Recomendações para proteger segredos de aplicativos.

Otimização de custo

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

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

A equipe da plataforma gerencia os recursos a seguir nesta arquitetura. Esses recursos costumam se basear em consumo (estorno) ou, possivelmente, são gratuitos para a equipe de carga de trabalho.

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

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

Para saber mais, confira Recomendações para coletar e revisar os dados de custo.

Implantar este 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.

Venda de assinaturas