A arquitetura neste artigo expande a arquitetura de linha de base da máquina virtual (VM) para abordar alterações e expectativas quando você a implanta em uma zona de aterrissagem 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 de identidade e políticas. Este exemplo pressupõe que a organização adote zonas de aterrissagem do Azure para impor governança consistente e eficiência de custos em várias cargas de trabalho.
Como proprietário da carga de trabalho, você pode descarregar o gerenciamento de recursos compartilhados para equipes centrais, para que possa se concentrar nos esforços de desenvolvimento da carga de trabalho. Este artigo apresenta a perspetiva da equipe de carga de trabalho. As recomendações que são para a equipe da plataforma são especificadas.
Importante
O que são zonas de aterrissagem do Azure? As zonas de aterrissagem do Azure apresentam duas perspetivas da pegada de nuvem de uma organização. Uma zona de aterrissagem de aplicativo é uma assinatura do Azure na qual uma carga de trabalho é executada. Está ligado aos recursos partilhados da organização. Por meio dessa conexão, ele tem acesso à infraestrutura básica que executa a carga de trabalho, como rede, gerenciamento de acesso de identidade, políticas e monitoramento. Uma zona de aterrissagem de plataforma é uma coleção de várias assinaturas, cada uma com uma função específica. Por exemplo, uma assinatura de conectividade fornece resolução centralizada de DNS (Sistema de Nomes de Domínio), conectividade entre locais e NVAs (dispositivos virtuais de rede) que estão disponíveis para uso das equipes de aplicativos.
Recomendamos que você entenda o conceito de zonas de aterrissagem do Azure para ajudá-lo a se preparar para a implementação dessa arquitetura.
Layout do artigo
| Arquitetura | Decisão de conceção | Abordagem do Azure Well-Architected Framework |
|---|---|---|
| ▪ Diagrama de arquitetura ▪ Recursos de carga de trabalho ▪ Recursos federados |
▪ Configuração da subscrição ▪ Requisitos de rede ▪ Alterações no design da rede a partir da linha de base ▪ Monitorização ▪ Conformidade com patches ▪ Governança organizacional ▪ Gestão da mudança |
▪ Fiabilidade ▪ Segurança ▪ Otimização de Custos |
Gorjeta
Esta implementação de referência demonstra as práticas recomendadas descritas neste artigo.
Os artefatos do repositório fornecem uma base personalizável para seu ambiente. A implementação configura uma rede de hub com recursos compartilhados, como o Firewall do Azure, para fins de demonstração. Você pode aplicar essa configuração a assinaturas separadas da zona de destino do aplicativo para funções distintas de carga de trabalho e plataforma.
Arquitetura
Transfira um ficheiro do Visio desta arquitetura.
Componentes
Todas as arquiteturas de zona de aterrissagem do Azure têm uma separação de propriedade entre a equipe da plataforma e a equipe de carga de trabalho. Os arquitetos de aplicativos e as equipes de DevOps precisam ter uma forte compreensão dessa divisão de responsabilidades para entender o que está sob sua influência ou controle direto 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.
As Máquinas Virtuais do Azure são a plataforma de aplicação. Os recursos de computação são distribuídos entre zonas de disponibilidade.
O Azure Load Balancer é usado para balancear a carga privada do tráfego das VMs front-end para as VMs back-end. O balanceador de carga distribui o tráfego para VMs entre zonas.
O Gateway de Aplicativo do Azure é usado como proxy reverso para rotear solicitações de 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 contra tráfego potencialmente 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.
A Política do Azure é usada para aplicar políticas específicas à carga de trabalho.
A equipe de carga de trabalho mantém e cumpre os seguintes recursos e responsabilidades.
Sub-redes de rede virtual spoke e os grupos de segurança de rede (NSGs) 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 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 as VMs são reinicializadas. Os servidores front-end têm discos anexados que você pode usar para implantar seu aplicativo sem monitoração de estado.
Recursos de propriedade da equipe da plataforma
A equipe da plataforma possui e mantém esses recursos centralizados. Essa arquitetura pressupõ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 fornece 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 possui esse componente.
A rede virtual spoke é onde a carga de trabalho é implantada.
Rotas definidas pelo usuário (UDRs) são usadas para forçar o tunelamento para a rede do hub.
As restrições de governança baseadas em políticas do Azure e
DeployIfNotExistsas políticas (DINE) fazem parte da assinatura de carga de trabalho.
Importante
As zonas de aterrissagem do Azure fornecem alguns dos recursos anteriores como parte das assinaturas da zona de aterrissagem da plataforma, e sua assinatura de carga de trabalho fornece outros recursos. Muitos dos recursos fazem parte da assinatura de conectividade, que tem recursos adicionais, como Azure ExpressRoute, Azure VPN Gateway e Azure DNS. Esses recursos adicionais fornecem acesso entre locais e resolução de nomes. A gestão destes recursos está fora do âmbito deste artigo.
Configuração da subscrição
Em um contexto de zona de pouso, sua equipe de carga de trabalho deve informar a equipe da 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 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 criticidade de negócios e nos requisitos técnicos da carga de trabalho, por exemplo, se uma carga de trabalho estiver exposta à Internet. A organização determina a configuração desses grupos de gerenciamento e a equipe da 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 internos de linha de negócios ou soluções comerciais prontas para uso (COTS), que geralmente estão localizados sob o grupo de gerenciamento Corp das zonas de aterrissagem do Azure.
Aplicações públicas, como em aplicações voltadas para a Internet, que muitas vezes estão sob o grupo de gestão 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ção sobre a configuração inicial da assinatura. No entanto, a equipe da plataforma normalmente faz alterações nos serviços centralizados para atender a requisitos perdidos ou alterados. As alterações na 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 devem estar cientes do ciclo de vida da solução baseada em VM e do ciclo de teste. Para obter mais informações, consulte Gerenciando alterações ao longo do tempo.
Requisitos e cumprimentos da 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 da plataforma. Use esses pontos como exemplos para entender a discussão e a negociação entre as duas equipes quando você implementa uma arquitetura semelhante.
O número de redes virtuais faladas: Nesta arquitetura, apenas um spoke dedicado é necessário. Os recursos implantados não precisam se estender por várias redes e são colocalizados em uma única rede virtual.
O tamanho da rede falada: 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árias, o tamanho máximo deve levar em conta 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 destes espaços pode introduzir uma complexidade extra. Seja proativo e solicite recursos de rede suficientes antecipadamente para garantir que o espaço alocado possa acomodar futuras expansões.
A região de implantação: é importante especificar as regiões onde a carga de trabalho será implantada. A equipe da plataforma pode usar essas informações para garantir que as redes virtuais de rádio e hub sejam provisionadas na mesma região. As redes em diferentes regiões podem levar a problemas de latência devido ao tráfego que atravessa fronteiras regionais e também podem incorrer em custos adicionais de largura de banda.
As características da carga de trabalho e as opções de design: comunique suas escolhas de design, componentes e características à equipe da plataforma. Por exemplo, se você espera que sua carga de trabalho gere um alto número de conexões simultâneas com a internet (chatty), a equipe da plataforma deve garantir que haja portas suficientes disponíveis para evitar o esgotamento. Eles podem adicionar endereços IP ao firewall centralizado para suportar o tráfego ou configurar um gateway NAT (Network Address Translation) para rotear o tráfego através de 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 os recursos de forma eficiente em toda a organização.
A equipe da plataforma precisa entender claramente quaisquer dependências. Por exemplo, sua carga de trabalho pode precisar de acesso a um banco de dados de propriedade de outra equipe 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 da plataforma saber.
A configuração do firewall: a equipe da plataforma deve estar ciente do tráfego que sai da rede spoke e é encapsulado 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 atualizações do Windows para permanecer corrigida, um firewall não deve bloquear essas atualizações. Da mesma forma, se houver agentes do Monitor que acessam pontos de extremidade específicos, um firewall não deve bloquear esse tráfego, pois pode interromper os dados de monitoramento da sua carga de trabalho. O aplicativo pode exigir acesso a pontos de extremidade de terceiros. Independentemente disso, use um firewall centralizado para distinguir entre tráfego esperado e injustificado.
Acesso do operador: se houver grupos de segurança do Microsoft Entra ID 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 suportem o protocolo seguro.
Além disso, informe a equipe da 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 de hub.
Os IPs públicos: Informe a equipe da plataforma sobre o perfil de tráfego de entrada, incluindo quaisquer endereços IP públicos antecipados. Nessa arquitetura, apenas o tráfego originado pela Internet tem como alvo o IP público no Application Gateway. 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 isso for 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 possui esse IP público e está inscrita em um serviço, como a Proteção contra DDoS, que a equipe da plataforma também gerencia.
Importante
Recomendamos um fluxo de trabalho de venda automática de assinatura para a equipe da plataforma que envolva uma série de perguntas projetadas para capturar informações da equipe de carga de trabalho. Essas perguntas podem variar de uma organização para outra, mas a intenção é reunir os requisitos para implementar assinaturas. Para obter mais informações, consulte Subscrição vending.
Opções de design de VM
As seleções de VM, SKU e disco permanecem as mesmas da 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. Diante desses requisitos, a equipe da plataforma pode gerenciar um conjunto de imagens padronizadas, muitas vezes chamadas de 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 aprovadas do sistema operacional ou artefatos de carga de trabalho. Ao escolher uma imagem do sistema operacional para VMs, consulte a equipe da plataforma sobre fontes de imagem, frequência de atualização e expectativas de uso. Certifique-se também de que as imagens possam atender aos requisitos de negócios necessários que a carga de trabalho cumpre.
Importante
Para a equipe da plataforma: Se você usar a Galeria de Computação, a carga de trabalho exigirá visibilidade de rede para a galeria privada. Colabore com a equipe de carga de trabalho para estabelecer conectividade segura.
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 da rede. A topologia Hub-spoke é assumida nessa arquitetura.
Transfira um ficheiro do Visio desta 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 obter mais informações, consulte Recursos de propriedade da equipe da plataforma. Recomendamos 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. Ele é emparelhado para a rede de hub, que contém os serviços centralizados. A equipa da plataforma é proprietária e gere esta rede falada. Esta rede contém os recursos de carga de trabalho. A equipe de carga de trabalho é proprietária dos recursos dessa rede, incluindo suas sub-redes.
Certifique-se de comunicar os requisitos de carga de trabalho à equipe da plataforma e revisá-los periodicamente.
Importante
Para a equipe da plataforma: a menos que especificamente exigido pela carga de trabalho, não emparelhe diretamente a rede falada para outra rede virtual falada. Essa prática protege os objetivos de segmentação da carga de trabalho. Sua equipe deve facilitar todas as conexões de rede virtual transitivas.
Sub-redes de rede virtual
Na rede virtual falada, 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 Application Gateway, VMs front-end, balanceador de carga, VMs back-end e pontos de extremidade privados.
Quando você implanta sua carga de trabalho em uma zona de aterrissagem do Azure, ainda precisa implementar controles de rede. As organizações podem impor restrições para proteger contra a exfiltração de dados e garantir visibilidade para o centro central de operações de segurança (SOC) e a equipe de rede de TI.
Com essa abordagem, a equipe da plataforma pode otimizar os gastos gerais da organização 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 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. 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 quaisquer recursos relacionados à entrada na Internet pública em sua carga de trabalho. Por exemplo, nessa arquitetura, o Application Gateway e seu 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 desmilitarizada centralizada (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, a escala da máquina virtual de carga de trabalho define o acesso à Internet pública por meio do Balanceador de Carga do Azure, mas esse tráfego não é restrito.
Esse design é diferente nesta arquitetura. Todo o tráfego que sai da rede virtual falada é roteado através da rede de hub emparelhada através 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 de IPs não encontrados na rede virtual local (0.0.0.0/0) para o Firewall do Azure do hub.
Transfira um ficheiro do Visio desta arquitetura.
A comunicação da carga de trabalho com o ponto de extremidade privado para acesso ao Cofre de Chaves permanece a mesma que a arquitetura de linha de base. Esse caminho é omitido do diagrama anterior por uma questão 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 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 apenas garantir que o tráfego esperado seja permitido. Trata-se também de garantir que apenas o tráfego esperado seja permitido. O tráfego de saída não comunicado provavelmente é negado por padrão, mas é do melhor interesse de segurança da carga de trabalho garantir que o tráfego seja roteado corretamente.
Gorjeta
Incentive a equipe da plataforma a usar grupos IP no Firewall do Azure. Essa prática garante que as necessidades de tráfego de saída da sua carga de trabalho sejam representadas com precisão com escopo apertado apenas para as sub-redes de origem. Por exemplo, uma regra que permite que VMs de carga de trabalho alcancem api.example.org não implica necessariamente que os recursos de suporte dentro da mesma rede virtual possam acessar o mesmo ponto de extremidade. Esse nível de controle granular pode melhorar a postura de segurança da sua rede.
Comunique quaisquer requisitos exclusivos 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. Em seguida, a equipe da 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 da carga de trabalho para saída. Nesse caso, você pode usar a Política do Azure para negar IPs públicos em placas de interface de rede (NICs) 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 de DNS. A equipe de carga de trabalho deve ter uma compreensão clara dos requisitos e do gerenciamento de zonas DNS privadas na assinatura que a equipe da plataforma fornece. As zonas DNS privadas são normalmente geridas em grande escala com políticas de DINE, o que permite que a Firewall do Azure funcione como um proxy DNS fiável e suporte regras de rede de nome de domínio totalmente qualificado (FQDN).
Nessa arquitetura, a equipe da plataforma garante a resolução DNS privada confiável para pontos de extremidade de link privado. Colabore com a equipe da sua plataforma para entender suas 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, nslookupou 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 usando o Azure Network Watcher.
Acesso do operador
Como a arquitetura de linha de base, o acesso operacional por meio do Azure Bastion é suportado 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 aterrissagem do Azure, elas 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 na organização o compartilham. 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.
Nota
Quando os operadores fazem logon em uma VM, eles devem usar suas identidades corporativas em seu locatário do Microsoft Entra ID e não compartilhar entidades de serviço entre funções.
Comece sempre com o princípio de privilégios mínimos e acesso granular a uma tarefa em vez de acesso de longa data. No contexto da zona de pouso, aproveite o suporte just-in-time (JIT) que a equipe da plataforma gerencia.
Conformidade com patches e atualizações do SO
A arquitetura de linha de base descreve uma abordagem autônoma para patches e atualizações. Quando a carga de trabalho é integrada com zonas de pouso, essa abordagem pode mudar. A equipe da plataforma pode ditar as operações de aplicação de patches para que todas as cargas de trabalho estejam em conformidade com os requisitos organizacionais.
Certifique-se de que o processo de aplicação de patches inclui todos os componentes que você adiciona à 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 estar em conformidade com os requisitos da plataforma.
Monitorização
A plataforma de zona de aterrissagem 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 de monitoramento de desempenho de aplicativos (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 dos recursos do Azure de propriedade da carga de trabalho e do código do aplicativo.
Transfira um ficheiro do Visio desta arquitetura.
Semelhante à linha de base, todos os recursos são configurados para enviar logs de Diagnóstico do Azure para o espaço de trabalho do Log Analytics que a equipe de carga de trabalho provisiona como parte da infraestrutura como implantação de código (IaC) dos recursos. Também pode ser necessário enviar logs para um espaço de trabalho central do Log Analytics. Nas zonas de aterrissagem do Azure, esse espaço de trabalho está na assinatura de gerenciamento.
A equipe da plataforma também pode ter políticas de DINE que podem ser usadas para configurar o Diagnóstico para enviar logs para suas 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 métricas da carga de trabalho e seus componentes de infraestrutura são armazenados no espaço de trabalho do Log Analytics da carga de trabalho. No entanto, os logs e 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 espaço de trabalho central do Log Analytics. Correlacionar dados de vários coletores pode ser uma tarefa complexa.
Os dados correlacionados são frequentemente utilizados durante a resposta a incidentes. Se houver um problema com a correlação de dados de vários coletores, certifique-se de que o runbook de triagem para essa arquitetura o aborde e inclua pontos de contato organizacionais se o problema se estender além dos recursos de carga de trabalho. Os administradores de carga de trabalho podem precisar de assistência de administradores de plataforma para correlacionar entradas de log de redes corporativas, segurança ou outros serviços de plataforma.
Importante
Para a equipe da plataforma: Sempre que possível, conceda controle de acesso baseado em função (RBAC) para consultar e ler coletores de log para recursos relevantes da plataforma. Habilite os logs de firewall para avaliações de regras de rede e aplicativos e proxy DNS porque as equipes de aplicativos podem usar essas informações durante as tarefas de solução de problemas.
Azure Policy
A equipe da 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 de zona de aterrissagem de aplicativos. 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 os recursos que as solicitações de processamento realmente usam. Uma solução típica é corrigir essas mudanças 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 entrem em conflito com os requisitos do aplicativo, você poderá negociar uma resolução com a equipe da plataforma.
Importante
As zonas de aterrissagem do Azure usam várias políticas de DINE, por exemplo, uma política que gerencia pontos de extremidade privados em escala. Esta política monitoriza implementações de pontos finais privados e atualiza o DNS do Azure na rede de hub, que faz parte de uma subscrição gerida pela plataforma. A equipe de carga de trabalho não tem permissão para modificar a política no hub e a equipe de plataforma não monitora as implantações das equipes de carga de trabalho para atualizar o DNS automaticamente. As políticas DINE são usadas para fornecer essa conexão.
Outras políticas podem afetar essa arquitetura, incluindo políticas que:
- Exigir uma VM do Windows para ingressar em um domínio do Ative Directory. Essa política garante que a extensão VM
JoinADDomainExtensionseja instalada e configurada. Para obter mais informações, consulte Impor VMs do Windows para ingressar em um domínio do Ative Directory. - Não permitir o encaminhamento de IP em interfaces de rede.
Gerir alterações ao longo do tempo
Os serviços e operações fornecidos pela plataforma são considerados dependências externas nesta arquitetura. A equipe da plataforma continua a aplicar mudanças, integrar usuários e aplicar controles de custos. A equipe da 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, patches automatizados 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. É importante testar as alterações, para que elas não afetem negativamente as cargas de trabalho.
Alterações na plataforma que afetam a carga de trabalho
Nessa arquitetura, a equipe da plataforma gerencia os seguintes recursos. As alterações nesses recursos podem potencialmente 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 nas políticas do Azure podem afetar os recursos de carga de trabalho e suas dependências. Por exemplo, pode haver alterações diretas de política ou movimento da zona de desembarque 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 completamente.
Regras de firewall: modificações nas regras de firewall podem afetar a rede virtual da carga de trabalho ou regras que se aplicam amplamente em todo o tráfego. Essas modificações podem resultar em tráfego bloqueado e até mesmo falhas de processo silenciosas, como falha na aplicação de patches do sistema operacional. Esses problemas potenciais se aplicam ao firewall do Azure de saída e às regras NSG aplicadas pelo Azure Virtual Network Manager.
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 potencialmente afetar a funcionalidade da carga de trabalho se uma carga de trabalho depender do roteamento para outras redes virtuais.
Host do Azure Bastion: as alterações na disponibilidade ou configuração do host do Azure Bastion podem afetar as operações de carga de trabalho. Certifique-se de que as alterações no padrão de acesso à caixa de salto tenham acesso de rotina, ad-hoc e de emergência eficaz.
Alterações de propriedade: comunique quaisquer 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 que você deve comunicar à 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 que elas entrem em vigor.
Saída de rede: monitore qualquer aumento significativo na saída de rede para evitar que a carga de trabalho se torne um vizinho barulhento em dispositivos de rede. Esse problema pode potencialmente afetar os objetivos de desempenho ou confiabilidade de outras cargas de trabalho.
Acesso público: alterações no acesso público aos componentes da carga de trabalho podem exigir testes adicionais. A equipe da plataforma pode realocar a carga de trabalho para um grupo de gerenciamento diferente.
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 nos requisitos de negócios da carga de trabalho
Para manter os objetivos de nível de serviço (SLOs) da carga de trabalho, a equipe da plataforma pode precisar estar envolvida nas 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 suporta os requisitos alterados.
Por exemplo, comunique alterações a qualquer fluxo de saída anteriormente 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 permitido anteriormente não for mais necessário, a equipe da plataforma deve 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 da arquitetura. Cada recurso está sujeito a políticas e, potencialmente, ao controle de firewall de saída.
Fiabilidade
Essa arquitetura está alinhada com as garantias de confiabilidade na arquitetura de linha de base.
Objetivos de fiabilidade
O SLO composto máximo possível é menor do que o SLO composto de linha de base devido a componentes como controle de rede de saída. Esses componentes, comuns em ambientes de zona de pouso, 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 aspeto 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 crítica que essa carga de trabalho e outras cargas de trabalho usam.
Para obter mais informações, consulte Recomendações para definir metas de confiabilidade.
Dependências críticas
Visualize todas as funcionalidades que a carga de trabalho executa na plataforma e na zona de aterrissagem 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 as seguintes dependências:
Firewall de saída: o firewall de saída centralizado, compartilhado por várias cargas de trabalho, sofre alterações não relacionadas à carga de trabalho.
Exaustão da porta de rede: picos de uso de todas as cargas de trabalho que compartilham o dispositivo de rede podem levar à saturação da rede ou ao esgotamento da porta no firewall de saída.
Políticas DINE: as políticas DINE para zonas DNS privadas do Azure DNS (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 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. Certifique-se de que os ambientes de pré-produção sejam semelhantes aos ambientes de produção para fornecer testes precisos e evitar desvios específicos do ambiente que possam bloquear uma implantação ou escala. Para obter mais informações, consulte Gerenciar ambientes de desenvolvimento de aplicativos em zonas de aterrissagem do Azure.
Muitas dessas considerações podem existir sem as zonas de aterrissagem 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
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 projeto de segurança no Well-Architected Framework.
Controlos 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 raios de carga de trabalho dentro de sua organização por meio de NSGs em suas sub-redes ou da natureza não transitiva ou controles 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 confie apenas na 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 Application Gateway tenha o Web Application Firewall definido para negar o modo, 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 assumir a responsabilidade de implantar políticas centradas na carga de trabalho que reforcem a postura de segurança de entrada.
A tabela a seguir mostra exemplos de controles de entrada nessa arquitetura.
| Origem | Propósito | Controle de carga de trabalho | Controlo da plataforma |
|---|---|---|---|
| Internet | Fluxos de tráfego de utilizadores | Canaliza todas as solicitações por meio de um NSG, Web Application Firewall e regras de roteamento antes de permitir a transição do tráfego público para o tráfego privado que entra nas VMs front-end | Nenhuma |
| Azure Bastion | Acesso do operador às VMs | NSG em sub-redes VM que bloqueia todo o tráfego para portas de acesso remoto, a menos que seja proveniente da sub-rede Azure Bastion designada pela plataforma | Nenhuma |
| Outros raios | Nenhuma | Bloqueado através de regras NSG | Roteamento não transitivo ou regras do Firewall do Azure no caso de um hub seguro da 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 todo o resto. Não confie apenas nos controles de rede do hub. Como operador de carga de trabalho, você tem a responsabilidade de interromper o tráfego de saída indesejado o mais próximo possível da origem.
Lembre-se de que, embora você seja o proprietário de 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 assinaturas. Certifique-se de que as alterações nas sub-redes e no posicionamento de recursos ao longo da vida útil da sua arquitetura ainda sejam compatíveis com a 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.
| Ponto final | Propósito | Controle de carga de trabalho (NSG) | Controlo da plataforma (hub) |
|---|---|---|---|
| ntp.ubuntu.com | O Network Time Protocol (NTP) para VMs linux | UDP/123 para a Internet na sub-rede VM front-end (o firewall de saída estreita essa ampla abertura) | Permissão 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 a partir de servidores Microsoft | TCP/443 e TCP/80 para a Internet na sub-rede VM back-end (o firewall de saída estreita essa ampla abertura) | Regra de permissão de firewall com tag 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 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 componente de aplicativo de exemplo) diretamente do fornecedor | TCP/443 para a Internet na sub-rede 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 em TCP/443 |
| Key Vault | Para importar certificados TLS (Transport Layer Security) no Application Gateway e VMs | - TCP/443 para uma sub-rede de ponto de extremidade privada de ambas as sub-redes 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 Application Gateway - TCP/443 de VMs marcadas com uma designação ASG (grupo de segurança de aplicativo) necessária e sub-rede do Application Gateway |
Nenhuma |
Proteção contra DDoS
Determine quem é responsável pela aplicação do plano de Proteção contra DDoS que cobre 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. Esta arquitetura deve ter cobertura porque envolve um IP público para entrada da internet.
Para obter mais informações, consulte Recomendações para rede e conectividade.
Gestão 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 em sua instância do Cofre de Chaves. Implante mais instâncias conforme necessário para dar suporte às operações de aplicativos e infraestrutura.
Para obter mais informações, consulte Recomendações para proteger segredos de aplicativos.
Otimização de custos
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 de zona de aterrissagem do Azure. Mesmo que você use esses recursos por meio de um modelo de estorno, a segurança adicional e a conectividade entre locais são mais econômicas do que o autogerenciamento desses recursos.
A equipe da plataforma gerencia os seguintes recursos nessa arquitetura. Esses recursos geralmente são baseados no consumo (chargeback) ou potencialmente gratuitos para a equipe de carga de trabalho.
- Azure Firewall
- Informações de segurança e gestão de eventos (SIEM)
- Hosts do Azure Bastion
- Conectividade entre locais, como ExpressRoute
Aproveite outras ofertas centralizadas da sua equipe de plataforma para estender esses benefícios à sua carga de trabalho sem comprometer o SLO, o RTO (Recovery Time Objetive, objetivo de tempo de recuperação) ou o RPO (Recovery Point Objetive, objetivo de ponto de recuperação).
Para obter mais informações, consulte Recomendações para coletar e revisar dados de custo.
Implementar este cenário
Está disponível uma implementação para esta arquitetura de referência no GitHub.
Próximo passo
Analise a colaboração e os detalhes técnicos compartilhados entre uma equipe de carga de trabalho e as equipes da plataforma.