Aplicativo Web com redundância de zona altamente disponível de linha de base

Essa arquitetura de linha de base é baseada na arquitetura de aplicativo Web Básica e a estende para fornecer orientação detalhada para projetar um aplicativo Web seguro, com redundância de zona e altamente disponível no Azure. A arquitetura expõe um ponto de extremidade público por meio do Gateway de Aplicativo do Azure com o Firewall de Aplicativo Web. Ele roteia solicitações para o Serviço de Aplicativo do Azure por meio do Private Link. O aplicativo do Serviço de Aplicativo usa a integração de rede virtual e o Private Link para se comunicar com segurança com os serviços PaaS do Azure, como o Azure Key Vault e o Banco de Dados SQL do Azure.

Arquitetura

Figura 1: Arquitetura de linha de base do Serviço de Aplicativo do Azure

Transfira um ficheiro do Visio desta arquitetura.

Componentes

Muitos componentes dessa arquitetura são os mesmos que a arquitetura básica de aplicativos Web. A lista a seguir destaca apenas as alterações na arquitetura básica.

• O Application Gateway é um balanceador de carga de camada 7 (HTTP/S) e um gerenciador de tráfego da Web. Ele usa o roteamento baseado em caminho de URL para distribuir o tráfego de entrada entre zonas de disponibilidade e descarrega a criptografia para melhorar o desempenho do aplicativo.
• O Web Application Firewall (WAF) é um serviço nativo da nuvem que protege aplicativos Web contra explorações comuns, como injeção de SQL e scripts entre sites. O WAF fornece visibilidade sobre o tráfego de e para seu aplicativo Web, permitindo que você monitore e proteja seu aplicativo.
• O Azure Key Vault é um serviço que armazena e gerencia segredos, chaves de criptografia e certificados com segurança. Centraliza a gestão de informação sensível.
• A rede virtual do Azure é um serviço que permite criar redes virtuais privadas isoladas e seguras no Azure. Para um aplicativo Web no Serviço de Aplicativo, você precisa de uma sub-rede de rede virtual para usar pontos de extremidade privados para comunicação segura de rede entre recursos.
• O Private Link possibilita que os clientes acessem os serviços PaaS (plataforma como serviço) do Azure diretamente de redes virtuais privadas sem usar endereçamento IP público.
• O DNS do Azure é um serviço de hospedagem para domínios DNS que fornece resolução de nomes usando a infraestrutura do Microsoft Azure. As zonas DNS privadas fornecem uma maneira de mapear o FQDN (nome de domínio totalmente qualificado) de um serviço para o endereço IP de um ponto de extremidade privado.

Rede

A segurança de rede está no centro da arquitetura de linha de base dos Serviços de Aplicativo (consulte a Figura 2). A partir de um alto nível, a arquitetura de rede garante o seguinte:

1. Um único ponto de entrada seguro para o tráfego de clientes
2. O tráfego de rede é filtrado
3. Os dados em trânsito são criptografados de ponta a ponta com TLS
4. A exfiltração de dados é minimizada mantendo o tráfego no Azure através do uso do Private Link
5. Os recursos de rede são logicamente agrupados e isolados uns dos outros através da segmentação de rede

Fluxos de rede

Figura 2: Arquitetura de rede do aplicativo de linha de base do Serviço de Aplicativo do Azure

A seguir estão descrições do fluxo de entrada de tráfego da Internet para a instância do Serviço de Aplicativo e o fluxo do Serviço de Aplicativo para os serviços do Azure.

Fluxo de entrada

1. O usuário emite uma solicitação para o IP público do Application Gateway.
2. As regras do WAF são avaliadas. As regras do WAF afetam positivamente a confiabilidade do sistema, protegendo contra vários ataques, como cross-site scripting (XSS) e injeção de SQL. O Gateway de Aplicativo do Azure retorna um erro para o solicitante se uma regra WAF for violada e o processamento for interrompido. Se nenhuma regra WAF for violada, o Application Gateway roteia a solicitação para o pool de back-end, que neste caso é o domínio padrão do Serviço de Aplicativo.
3. A zona privatelink.azurewebsites.net DNS privada está ligada à rede virtual. A zona DNS tem um registro A que mapeia o domínio padrão do Serviço de Aplicativo para o endereço IP privado do ponto de extremidade privado do Serviço de Aplicativo. Essa zona DNS privada vinculada permite que o DNS do Azure resolva o domínio padrão para o endereço IP do ponto de extremidade privado.
4. A solicitação é roteada para uma instância do Serviço de Aplicativo por meio do ponto de extremidade privado.

Serviço de Aplicativo para o fluxo de serviços PaaS do Azure

1. O Serviço de Aplicativo faz uma solicitação para o nome DNS do serviço do Azure necessário. A solicitação pode ser para o Azure Key Vault para obter um segredo, o Armazenamento do Azure para obter um arquivo zip de publicação, o Banco de Dados SQL do Azure ou qualquer outro serviço do Azure que ofereça suporte ao Private Link. O recurso de integração de rede virtual do Serviço de Aplicativo roteia a solicitação pela rede virtual.
2. Como a etapa 3 no fluxo de entrada, a zona DNS privada vinculada tem um registro A que mapeia o domínio do serviço do Azure para o endereço IP privado do ponto de extremidade privado. Novamente, essa zona DNS privada vinculada permite que o DNS do Azure resolva o domínio para o endereço IP do ponto de extremidade privado do serviço.
3. A solicitação é roteada para o serviço por meio do ponto de extremidade privado.

Ingresso nos Serviços de Aplicativos

O Application Gateway é um recurso regional que atende aos requisitos dessa arquitetura de linha de base. O Application Gateway é um balanceador de carga escalável, regional, de camada 7 que suporta recursos como firewall de aplicativos Web e descarregamento de TLS. Considere os seguintes pontos ao implementar o Application Gateway para entrada nos Serviços de Aplicativo do Azure.

• Implante o Application Gateway e configure uma política WAF com um conjunto de regras gerenciado pela Microsoft. Use o modo de Prevenção para mitigar ataques da Web, que podem fazer com que um serviço de origem (Serviço de Aplicativo na arquitetura) fique indisponível.
• Implemente criptografia TLS de ponta a ponta.
• Use pontos de extremidade privados para implementar o acesso privado de entrada ao seu Serviço de Aplicativo.
• Considere a implementação do dimensionamento automático para o Application Gateway para se ajustar prontamente aos fluxos dinâmicos de tráfego.
• Considere usar uma contagem mínima de instâncias de escala não inferior a três e sempre use todas as zonas de disponibilidade suportadas pela sua região. Embora o Application Gateway seja implantado de forma altamente disponível, mesmo para uma instância de escala única, a criação de uma nova instância em caso de falha pode levar até sete minutos. A implantação de várias instâncias em zonas de disponibilidade ajuda a garantir que, em caso de falha, uma instância seja executada enquanto uma nova instância está sendo criada.
• Desative o acesso à rede pública no Serviço de Aplicativo para garantir o isolamento da rede. No Bicep, isso é feito definindo publicNetworkAccess: 'Disabled' em properties/siteConfig.

Fluxo dos Serviços de Aplicativo para os serviços do Azure

Essa arquitetura usa a integração de rede virtual para o Serviço de Aplicativo, especificamente para rotear o tráfego para pontos de extremidade privados por meio da rede virtual. A arquitetura de linha de base não permite que todo o roteamento de tráfego force todo o tráfego de saída através da rede virtual, apenas o tráfego interno, como o tráfego destinado a pontos de extremidade privados.

Os serviços do Azure que não exigem acesso da Internet pública devem ter pontos de extremidade privados habilitados e pontos de extremidade públicos desabilitados. Os pontos de extremidade privados são usados em toda essa arquitetura para melhorar a segurança, permitindo que o Serviço de Aplicativo se conecte aos serviços de Link Privado diretamente de sua rede virtual privada sem usar endereçamento IP público.

Nessa arquitetura, o Banco de Dados SQL do Azure, o Armazenamento do Azure e o Cofre da Chave têm pontos de extremidade públicos desabilitados. Os firewalls de serviço do Azure são usados apenas para permitir o tráfego de outros serviços autorizados do Azure. Você deve configurar outros serviços do Azure com pontos de extremidade privados, como o Azure Cosmos DB e o Cache Redis do Azure. Nessa arquitetura, o Azure Monitor não usa um ponto de extremidade privado, mas pode.

A arquitetura de linha de base implementa uma zona DNS privada para cada serviço. A zona DNS privada contém um registro A que mapeia entre o nome de domínio totalmente qualificado do serviço e o endereço IP privado do ponto de extremidade privado. As zonas estão ligadas à rede virtual. Os grupos de zonas DNS privadas garantem que os registos DNS de ligação privada são criados e atualizados automaticamente.

Considere os seguintes pontos ao implementar a integração de rede virtual e pontos de extremidade privados.

• Use as diretrizes de configuração de zona DNS dos serviços do Azure para nomear zonas DNS privadas.
• Configure firewalls de serviço para garantir que a conta de armazenamento, o cofre de chaves, o Banco de Dados SQL e outros serviços do Azure só possam ser conectados de forma privada.
  • Defina a regra de acesso à rede padrão da conta de armazenamento para negar todo o tráfego.
  • Habilite o Cofre da Chave para Link Privado.
  • Negar acesso de rede pública ao Azure SQL.

Segmentação e segurança de redes virtuais

A rede nessa arquitetura tem sub-redes separadas para o Gateway de Aplicativo, componentes de integração do Serviço de Aplicativo e pontos de extremidade privados. Cada sub-rede tem um grupo de segurança de rede que limita o tráfego de entrada e saída dessas sub-redes apenas ao que é necessário. A tabela a seguir mostra uma exibição simplificada das regras NSG que a linha de base adiciona a cada sub-rede. A tabela fornece o nome e a função da regra.

Considere os seguintes pontos ao implementar a segmentação e a segurança da rede virtual.

• Habilite a proteção contra DDoS para a rede virtual com uma sub-rede que faça parte de um gateway de aplicativo com um IP público.
• Adicione um NSG a cada sub-rede sempre que possível. Você deve usar as regras mais rígidas que permitem a funcionalidade completa da solução.
• Use grupos de segurança de aplicativos. Os grupos de segurança de aplicativos permitem agrupar NSGs, facilitando a criação de regras para ambientes complexos.

Um exemplo de um esquema de sub-rede virtual pode ser:

Referência Azure-Samples\app-service-baseline-implementation

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ê assume com seus clientes. Para obter mais informações, consulte Visão geral do pilar de confiabilidade.

A arquitetura de linha de base dos Serviços de Aplicativo se concentra na redundância zonal para os principais serviços regionais. As zonas de disponibilidade são locais fisicamente separados dentro de uma região. Eles fornecem redundância zonal para serviços de suporte quando duas ou mais instâncias são implantadas em regiões de suporte. Quando uma zona sofre tempo de inatividade, as outras zonas ainda podem não ser afetadas.

A arquitetura também garante instâncias suficientes de serviços do Azure para atender à demanda. As seções a seguir fornecem diretrizes de confiabilidade para os principais serviços na arquitetura. Desta forma, as zonas de disponibilidade ajudam-no a obter fiabilidade, fornecendo alta disponibilidade e tolerância a falhas.

Gateway de Aplicação

Implante o Gateway de Aplicativo do Azure v2 em uma configuração redundante de zona. Considere o uso de uma contagem de instâncias de escala mínima não inferior a três para evitar o tempo de inicialização de seis a sete minutos para uma instância do Application Gateway se houver uma falha.

Serviços Aplicacionais

• Implante um mínimo de três instâncias dos Serviços de Aplicativo com suporte à Zona de Disponibilidade.
• Implemente pontos de extremidade de verificação de integridade em seus aplicativos e configure o recurso de verificação de integridade do Serviço de Aplicativo para redirecionar solicitações longe de instâncias não íntegras. Para obter mais informações sobre a verificação de integridade do Serviço de Aplicativo, consulte Monitorar instâncias do Serviço de Aplicativo usando a verificação de integridade. Para obter mais informações sobre como implementar pontos de extremidade de verificação de integridade em aplicativos ASP.NET, consulte Verificações de integridade no ASP.NET Core.
• Capacidade de provisionamento excessivo para poder lidar com falhas de zona.

Banco de dados SQL

• Implante o Banco de Dados SQL do Azure General Purpose, Premium ou Business Critical com redundância de zona habilitada. As camadas de Uso Geral, Premium e Crítica de Negócios dão suporte à redundância de zona no SQL DB do Azure.
• Configure backups de banco de dados SQL para usar armazenamento com redundância de zona (ZRS) ou armazenamento com redundância de zona geográfica (GZRS).

Armazenamento de Blobs

• O Armazenamento com Redundância de Zona do Azure (ZRS) replica seus dados de forma síncrona em três zonas de disponibilidade na região. Crie contas de armazenamento ZRS padrão ou GZRS padrão para garantir que os dados sejam replicados em zonas de disponibilidade.
• Crie contas de armazenamento separadas para implantações, ativos da Web e outros dados para que você possa gerenciar e configurar as contas separadamente.

Eficiência de desempenho

Eficiência de desempenho é a capacidade da sua carga de trabalho para dimensionar para satisfazer as exigências que os utilizadores lhe colocam de forma eficiente. Para obter mais informações, consulte Visão geral do pilar de eficiência de desempenho.

As seções a seguir discutem a escalabilidade para os principais componentes dessa arquitetura.

Gateway de Aplicação

• Implemente o dimensionamento automático para o Application Gateway para aumentar ou diminuir a escala para atender à demanda.
• Defina a contagem máxima de instâncias para um número maior do que a sua necessidade esperada. Só lhe serão cobradas as Unidades de Capacidade que utilizar.
• Defina uma contagem mínima de instâncias que possa lidar com pequenos picos de tráfego. Você pode usar o uso médio da Unidade de Computação para calcular sua contagem mínima de instâncias.
• Siga as orientações sobre o dimensionamento da sub-rede do Application Gateway.

Serviço de Aplicações

• Use planos Standard ou superiores com três ou mais instâncias de trabalho para alta disponibilidade.
• Habilite o dimensionamento automático para garantir que você possa aumentar e diminuir a escala para atender à demanda.
• Considere abrir um tíquete de suporte para aumentar o número máximo de trabalhadores para duas vezes a contagem de instâncias se o Serviço de Aplicativo usar consistentemente metade do número máximo de instâncias. O número máximo de instâncias tem como padrão até 30 para um plano do Serviço de Aplicativo Premium e 10 para um plano Padrão.
• Considere implantar vários carimbos do aplicativo quando o Serviço de Aplicativo começar a atingir os limites superiores.
• Escolha o plano certo do Serviço de Aplicativo do Azure que atenda aos seus requisitos de carga de trabalho.
• Adicione a CDN do Azure ao Serviço de Aplicativo do Azure para fornecer conteúdo estático.
• Considere o Ambiente do Serviço de Aplicativo se vizinhos barulhentos forem uma preocupação.

SQL Server

O dimensionamento de recursos de banco de dados é um tópico complexo fora do escopo dessa arquitetura. Considere os seguintes recursos ao dimensionar seu banco de dados,

• Dimensione dinamicamente os recursos do banco de dados com o mínimo de tempo de inatividade
• Aumentar horizontalmente com a Base de Dados SQL do Azure
• Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura

Outras orientações de escalabilidade

• Revise os limites de assinatura e as cotas para garantir que os serviços sejam dimensionados de acordo com a demanda.
• Considere o armazenamento em cache para os seguintes tipos de dados para aumentar o desempenho e a escalabilidade:
  • Dados de transação semiestáticos.
  • Estado da sessão.
  • Saída HTML. Tal pode ser útil em aplicações que compõem uma saída HTML complexa.

Segurança

A arquitetura de linha de base do Serviço de Aplicativo se concentra em recomendações de segurança essenciais para seu aplicativo Web. Entender como a criptografia e a identidade funcionam em cada camada é fundamental para proteger sua carga de trabalho.

Serviço de Aplicações

• Desabilitar métodos de autenticação local para implantações de sites FTP e SCM
• Desative a depuração remota.
• Use a versão mais recente do TLS.
• Habilite o Microsoft Defender para Serviço de Aplicativo.
• Use as versões mais recentes de plataformas, linguagens de programação, protocolos e estruturas suportadas.
• Considere o Ambiente do Serviço de Aplicativo se precisar de maior isolamento ou acesso seguro à rede.

Encriptação

Um aplicativo Web de produção precisa criptografar dados em trânsito usando HTTPS. O protocolo HTTPS depende do Transport Layer Security (TLS) e usa chaves públicas e privadas para criptografia. Você deve armazenar um certificado (X.509) no Cofre da Chave e permitir que o Application Gateway recupere a chave privada. Para dados em repouso, alguns serviços criptografam dados automaticamente e outros permitem personalizar.

Dados em trânsito

Na arquitetura de linha de base, os dados em trânsito são criptografados do usuário para o aplicativo Web no Serviço de Aplicativo. O fluxo de trabalho a seguir descreve como a criptografia funciona em um alto nível.

1. O usuário envia uma solicitação HTTPS para o aplicativo Web.
2. A solicitação HTTPS chega ao gateway de aplicativo.
3. O gateway de aplicativo usa um certificado (X.509) no Cofre da Chave para criar uma conexão TLS segura com o navegador da Web do usuário. O gateway de aplicativo descriptografa a solicitação HTTPS para que o firewall do aplicativo Web possa inspecioná-la.
4. O gateway de aplicativo cria uma conexão TLS com o Serviço de Aplicativo para criptografar novamente a solicitação do usuário. O Serviço de Aplicativo fornece suporte nativo para HTTPS, portanto, você não precisa adicionar um certificado ao Serviço de Aplicativo. O gateway de aplicativo envia o tráfego criptografado para o Serviço de Aplicativo. O Serviço de Aplicativo descriptografa o tráfego e o aplicativo Web processa a solicitação.

Considere as seguintes recomendações ao configurar a criptografia de dados em trânsito.

• Crie ou carregue seu certificado no Cofre da Chave. A criptografia HTTPS requer um certificado (X.509). Você precisa de um certificado de uma autoridade de certificação confiável para seu domínio personalizado.
• Armazene a chave privada para o certificado no Cofre da Chave.
• Siga as orientações em Conceder permissão a aplicativos para acessar um cofre de chaves do Azure usando o RBAC do Azure e identidades gerenciadas para recursos do Azure para fornecer acesso do Gateway de Aplicativo à chave privada do certificado. Não use políticas de acesso ao Cofre da Chave para fornecer acesso. As políticas de acesso só permitem conceder permissões amplas, não apenas a valores específicos.
• Habilite a criptografia de ponta a ponta. O Serviço de Aplicativo é o pool de back-end para o gateway de aplicativo. Ao definir a configuração de back-end para o pool de back-end, use o protocolo HTTPS na porta de back-end 443.

Dados inativos

• Criptografe dados confidenciais no Banco de Dados SQL do Azure usando criptografia de dados transparente. Os dados transparentes encriptam toda a base de dados, cópias de segurança e ficheiros de registo de transações e não requerem alterações à sua aplicação Web.
• Minimize a latência de criptografia do banco de dados. Para minimizar a latência de criptografia, coloque os dados necessários para proteger em seu próprio banco de dados e habilite apenas a criptografia para esse banco de dados.
• Entenda o suporte de criptografia integrado. O Armazenamento do Azure criptografa automaticamente os dados em repouso usando a criptografia do lado do servidor (AES de 256 bits). O Azure Monitor criptografa automaticamente os dados em repouso usando chaves gerenciadas pela Microsoft (MMKs).

Gestão de Acesso e Identidades

A linha de base do Serviço de Aplicativo configura autenticação e autorização para identidades de usuário (usuários) e identidades de carga de trabalho (recursos do Azure) e implementa o princípio de menor privilégio.

Identidades de utilizador

• Use o mecanismo de autenticação integrado para o Serviço de Aplicativo ("EasyAuth"). O EasyAuth simplifica o processo de integração de provedores de identidade em seu aplicativo Web. Ele lida com a autenticação fora do seu aplicativo Web, para que você não precise fazer alterações significativas no código.
• Configure a URL de resposta para o domínio personalizado. Você deve redirecionar o aplicativo Web para https://<application-gateway-endpoint>/.auth/login/<provider>/callback. Substitua <application-gateway-endpoint> pelo endereço IP público ou pelo nome de domínio personalizado associado ao gateway de aplicativo. Substitua <provider> pelo provedor de autenticação que você está usando, como "aad" para o ID do Microsoft Entra. Você pode usar a documentação do Azure Front para configurar esse fluxo com o Gateway de Aplicativo ou Configurando o Gateway de Aplicativo.

Identidades de carga de trabalho

• Use a identidade gerenciada para identidades de carga de trabalho. A identidade gerenciada elimina a necessidade de os desenvolvedores gerenciarem credenciais de autenticação.
• Use identidades gerenciadas atribuídas pelo usuário. Uma identidade atribuída ao sistema pode fazer com que as implantações de infraestrutura como código falhem com base nas condições de corrida e na ordem das operações. Você pode usar identidades gerenciadas atribuídas pelo usuário para evitar alguns desses cenários de erro de implantação. Para obter mais informações, veja Identidades geridas.

Excelência operacional

A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.

A implantação do aplicativo do Serviço de Aplicativo de linha de base segue as orientações em CI/CD para Aplicativos Web do Azure com Pipelines do Azure. Além dessa orientação, a arquitetura de linha de base dos Serviços de Aplicativo leva em conta que o aplicativo e a conta de armazenamento de implantação estão protegidos pela rede. A arquitetura nega acesso público ao Serviço de Aplicativo. Isso significa que você não pode implantar de fora da rede virtual. A linha de base mostra como implantar o código do aplicativo na rede virtual usando agentes de implantação auto-hospedados. As diretrizes de implantação a seguir se concentram na implantação do código do aplicativo e não na implantação de alterações na infraestrutura ou no banco de dados.

Figura 3: Implantando aplicativos do Serviço de Aplicativo do Azure

Fluxo de implantação

1. Como parte do pipeline de liberação, o pipeline publica uma solicitação de trabalho para os agentes auto-hospedados na fila de trabalhos. A solicitação de trabalho é para que o agente carregue o artefato de compilação do arquivo zip de publicação em uma Conta de Armazenamento do Azure.

2. O agente de implantação auto-hospedado seleciona a nova solicitação de trabalho por meio de sondagem. Ele baixa o trabalho e o artefato de construção.

3. O agente de implantação auto-hospedado carrega o arquivo zip para a conta de armazenamento por meio do ponto de extremidade privado da conta de armazenamento.

4. O pipeline continua e um agente gerenciado pega um trabalho subsequente. O agente gerenciado faz uma chamada CLI para atualizar o appSetting WEBSITE_RUN_FROM_PACKAGE ao nome do novo arquivo zip de publicação para o slot de preparação.

   az webapp config appsettings set -g MyResourceGroupName -n MyUniqueApp --slot staging --settings WEBSITE_RUN_FROM_PACKAGE=UriToNewZip
   

5. O Serviço de Aplicativo do Azure extrai o novo arquivo zip de publicação do armazenamento por meio do ponto de extremidade privado da conta de armazenamento. A instância de preparo é reiniciada com o novo pacote porque WEBSITE_RUN_FROM_PACKAGE foi definido como um nome de arquivo diferente.

6. O gasoduto retoma e executa quaisquer testes de fumaça ou aguarda a aprovação. Se os testes forem aprovados ou a aprovação for dada, o pipeline troca os slots de preparação e produção.

Orientação de implementação

A seguir destacam-se as principais diretrizes de implantação para a arquitetura de linha de base.

• Use executar a partir do pacote para evitar conflitos de implantação. Quando você executa seu aplicativo diretamente de um pacote no Serviço de Aplicativo do Azure, os arquivos no pacote não são copiados para o diretório wwwroot. Em vez disso, o próprio pacote ZIP é montado diretamente como o diretório wwwroot somente leitura. Isso elimina conflitos de bloqueio de arquivo entre implantação e tempo de execução e garante que apenas aplicativos totalmente implantados sejam executados a qualquer momento
• Inclua números de versão nos arquivos zip do pacote implantado. Atualizar o WEBSITE_RUN_FROM_PACKAGE appSetting para o pacote de implantação com um nome de arquivo diferente faz com que os Serviços de Aplicativo escolham automaticamente a nova versão e reiniciem o serviço.
• Use slots de implantação para implantações de código resiliente.
• Considere o uso de uma combinação de agentes gerenciados e auto-hospedados.
  • Use agentes auto-hospedados para carregar o arquivo zip do pacote para a conta de armazenamento através do ponto de extremidade privado. O agente inicia a comunicação com o pipeline por meio de sondagem para que não seja necessário abrir a rede para uma chamada de entrada.
  • Use agentes gerenciados para os outros trabalhos no pipeline.
• Automatize implantações de infraestrutura com Infrastructure as Code (IaC).
• Valide continuamente a carga de trabalho para testar o desempenho e a resiliência de toda a solução usando serviços como o Azure Load Testing e o Azure Chaos Studio.

Configuração

Os aplicativos exigem valores de configuração e segredos. Use as diretrizes a seguir para configuração e gerenciamento de segredos.

• Nunca verifique segredos como senhas ou chaves de acesso no controle do código-fonte.
• Use o Azure Key Vault para armazenar segredos.
• Use a configuração do Serviço de Aplicativo para a configuração do seu aplicativo. Se você precisar externalizar a configuração da configuração do seu aplicativo ou precisar de suporte ao sinalizador de recurso, considere usar a Configuração do Aplicativo do Azure.
• Use as referências do Cofre da Chave na configuração do Serviço de Aplicativo para expor segredos com segurança em seu aplicativo.
• Crie configurações de aplicativo que se mantenham em um slot e não sejam trocadas se você precisar de configurações de produção e preparo diferentes. Quando troca um bloco de implementação, as definições da aplicação regressam aos valores predefinidos.
• Defina variáveis de ambiente local para desenvolvimento local ou aproveite os recursos da plataforma de aplicativos. A configuração dos Serviços de Aplicativo expõe as configurações do aplicativo como variáveis de ambiente. O Visual Studio, por exemplo, permite definir variáveis de ambiente em perfis de inicialização. Ele também permite que você use Configurações do aplicativo e segredos do usuário para armazenar configurações e segredos do aplicativo local.

Monitorização

A monitorização consiste na recolha e análise de dados dos sistemas informáticos. O objetivo do monitoramento é a observabilidade em várias camadas para rastrear a integridade e a segurança do aplicativo Web. A observabilidade é uma faceta fundamental da arquitetura de linha de base do Serviço de Aplicativo.

Para monitorar seu aplicativo Web, você precisa coletar e analisar métricas e logs do código do aplicativo, da infraestrutura (tempo de execução) e da plataforma (recursos do Azure). Para obter mais informações, consulte Log de atividades do Azure, logs de recursos do Azure e logs de aplicativos.

Monitore a plataforma

O monitoramento de plataforma é a coleta de dados dos serviços do Azure em sua arquitetura. Considere as seguintes orientações sobre o monitoramento da plataforma.

• Adicione uma configuração de diagnóstico para cada recurso do Azure. Cada serviço do Azure tem um conjunto diferente de logs e métricas que você pode capturar. Use a tabela a seguir para descobrir as métricas e os logs que você deseja coletar.

  Recurso do Azure	Métricas e descrições de logs
  Gateway de Aplicação	Métricas e descrições de logs do Application Gateway
  Firewall de Aplicações Web	Métricas e descrições de logs do firewall de aplicativos Web
  Serviço de Aplicações	Métricas e descrições de logs do Serviço de Aplicativo
  Base de Dados SQL do Azure	Descrição das métricas e logs do Banco de Dados SQL do Azure
  Cosmos DB	Métricas e descrições de logs do Azure Cosmos DB
  Key Vault	Métricas e descrições de logs do Key Vault
  Armazenamento de Blobs	Métricas e descrições de logs do Armazenamento de Blobs do Azure
  Application Insights	Métricas e descrições de logs do Application Insights
  Endereço IP público	Métricas de endereço IP público e descrições de logs

• Entenda o custo da coleta de métricas e logs. Em geral, quanto mais métricas e logs você coletar, mais custa. Para obter mais informações, consulte Cálculos e opções de custo do Log Analytics e Preços do espaço de trabalho do Log Analytics.

• Criar alertas. Você deve criar alertas para todos os recursos do Azure na arquitetura e configurar Ações para corrigir problemas. Escolha regras de alerta comuns e recomendadas para começar e modificar ao longo do tempo, conforme necessário. Para obter mais informações, consulte:

  • Visão geral dos alertas do Azure Monitor
  • Alertas do Application Gateway
  • Alertas do Serviço de Aplicativo
  • Alertas do Banco de Dados SQL do Azure
  • Alertas de armazenamento de Blob
  • Alertas do cofre de chaves

Gateway de Aplicação

O Application Gateway monitora a integridade dos recursos em seu pool de back-end. Use os logs de Acesso ao Gateway de Aplicativo para coletar informações como o carimbo de data/hora, o código de resposta HTTP e o caminho da URL. Para obter mais informações, consulte Application Gateway default health probe e Backend health and diagnostic logs.

Serviço de Aplicações

O Serviço de Aplicativo tem ferramentas de monitoramento integradas e integradas que você deve habilitar para melhorar a observabilidade. Se o seu aplicativo Web já tiver recursos de telemetria e monitoramento ("instrumentação em processo"), ele deverá continuar a funcionar no Serviço de Aplicativo.

• Habilite a instrumentação automática. O Serviço de Aplicativo tem uma extensão de instrumentação que você pode habilitar sem alterações de código. Você ganha visibilidade de monitoramento de desempenho de aplicativos (APM). Para obter mais informações, consulte Monitorar o desempenho do Serviço de Aplicativo do Azure.
• Ativar o rastreio distribuído. A instrumentação automática oferece uma maneira de monitorar sistemas de nuvem distribuídos por meio de rastreamento distribuído e um perfilador de desempenho.
• Use instrumentação baseada em código para telemetria personalizada. O Azure Application Insights também dá suporte à instrumentação baseada em código para telemetria de aplicativo personalizada. Adicione o SDK do Application Insights ao seu código e use a API do Application Insights.
• Habilite os logs do Serviço de Aplicativo. A plataforma do Serviço de Aplicativo oferece suporte a quatro logs adicionais que você deve habilitar para dar suporte à solução de problemas. Esses logs são logs de aplicativos, logs de servidor Web, mensagens de erro detalhadas e rastreamento de solicitação com falha.
• Use o registro estruturado. Adicione uma biblioteca de log estruturada ao código do aplicativo. Atualize seu código para usar pares chave-valor e habilite os logs do Aplicativo no Serviço de Aplicativo para armazenar esses logs em seu espaço de trabalho do Log Analytics.
• Ative a verificação de Estado de Funcionamento do Serviço de Aplicação. A verificação de integridade redireciona as solicitações para longe das instâncias não íntegras e substitui as instâncias não íntegras. Seu plano do Serviço de Aplicativo precisa usar duas ou mais instâncias para que as verificações de integridade funcionem.

Base de Dados

• Insights do banco de dados do usuário. Para bancos de dados SQL do Azure, você deve configurar o SQL Insights no Azure Monitor. O Database Insights usa exibições de gerenciamento dinâmico para expor os dados necessários para monitorar a integridade, diagnosticar problemas e ajustar o desempenho. Para obter mais informações, consulte Monitorando o Banco de Dados SQL do Azure com o Azure Monitor.
• Se sua arquitetura incluir o Cosmos DB, você não precisará habilitar ou configurar nada para usar os insights do Cosmos DB.

Governação

Os aplicativos Web se beneficiam da Política do Azure aplicando decisões de arquitetura e segurança. A Política do Azure pode tornar (1) impossível implantar (negar) ou (2) fácil detetar (auditoria) desvio de configuração do seu estado desejado preferido. Isso ajuda você a capturar implantações de Infraestrutura como Código (IaC) ou alterações no portal do Azure que se desviam da arquitetura acordada. Você deve colocar todos os recursos em sua arquitetura sob a governança da Política do Azure. Use políticas internas ou iniciativas de política sempre que possível para impor topologia de rede essencial, recursos de serviço, segurança e decisões de monitoramento, por exemplo:

• O Serviço de Aplicativo deve desabilitar o acesso à rede pública
• O serviço de aplicativo deve usar a integração de rede virtual
• O Serviço de Aplicativo deve usar o Azure Private Link para se conectar aos serviços PaaS
• O Serviço de Aplicativo deve ter métodos de autenticação local desabilitados para implantações de site FTP ou SCM
• O Serviço de Aplicativo deve ter a depuração remota desativada
• Os aplicativos do Serviço de Aplicativo devem usar a versão TLS mais recente
• O Microsoft Defender para Serviço de Aplicativo deve estar habilitado
• O Web Application Firewall (WAF) deve ser habilitado para o Application Gateway

Veja mais políticas internas para serviços importantes, como Gateway de Aplicativo e componentes de rede, Serviço de Aplicativo, Cofre de Chaves e Monitoramento. É possível criar políticas personalizadas ou usar políticas da comunidade (como das Zonas de Aterrissagem do Azure) se as políticas internas não cobrirem totalmente suas necessidades. Prefira políticas internas quando estiverem disponíveis.

Próximos passos

Recursos relacionados

• Guia para Link Privado em WAN Virtual
• Dimensionar um aplicativo no Serviço de Aplicativo do Azure
• Migrar o Serviço de Aplicativo para o suporte à zona de disponibilidade
• Dimensionamento do Application Gateway v2 e WAF v2