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

Este artigo fornece uma arquitetura de linha de base para executar aplicativos Web no Serviço de Aplicativo do Azure em uma única região. Ele detalha as diretrizes 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 Link Privado. O aplicativo Serviço de Aplicativo usa a integração de rede virtual e o Link Privado para se comunicar com segurança com os serviços de PaaS do Azure, como o Cofre de Chaves do Azure e o Banco de Dados SQL do Azure.

Arquitetura

Figura 1: Arquitetura do Serviço de Aplicativo do Azure de Linha de Base

Baixe um Arquivo Visio dessa arquitetura.

Componentes

• Microsoft Entra ID é um serviço de gerenciamento de identidade e acesso baseado em nuvem. Ele fornece um único plano de controle de identidade para gerenciar permissões e funções para usuários que acessam seu aplicativo Web. Ele se integra ao Serviço de Aplicativo e simplifica a autenticação e a autorização para aplicativos Web.
• 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 WAF (Web Application Firewall) é 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 Serviço de Aplicativo é uma plataforma totalmente gerenciada para criar, implantar e dimensionar aplicativos Web.
• O Cofre de Chaves do Azure é um serviço que armazena e gerencia com segurança segredos, chaves de criptografia e certificados. Centraliza o gerenciamento de informações sensíveis.
• O Azure Monitor é um serviço de monitoramento que coleta, analisa e atua em dados de telemetria em sua implantação.
• 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 da plataforma como serviço (PaaS) do Azure diretamente de redes virtuais privadas sem usar o 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.
• O Banco de Dados SQL do Azure é um serviço de banco de dados relacional gerenciado para dados relacionais.

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 do cliente
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 por meio do uso do Private Link
5. Os recursos de rede são logicamente agrupados e isolados uns dos outros por meio 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 do 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 Gateway de Aplicativo.
2. As regras do WAF são avaliadas. As regras do WAF afetam positivamente a confiabilidade do sistema, protegendo contra vários ataques, como scripts entre sites (XSS) e injeção de SQL. O Gateway de Aplicativo do Azure retornará um erro ao solicitante se uma regra WAF for violada e o processamento for interrompido. Se nenhuma regra de WAF for violada, o Gateway de Aplicativo roteia a solicitação para o pool de back-end, que nesse caso é o domínio padrão do Serviço de Aplicativo.
3. A zona privatelink.azurewebsites.net DNS privada está vinculada à 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.

Fluxo de serviços de PaaS do Serviço de Aplicativo para 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 Cofre de Chaves do Azure 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 Link Privado. 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 de 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 Aplicativo

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 e de camada 7 que oferece suporte a recursos como firewall de aplicativo Web e descarregamento de TLS. Considere os seguintes pontos ao implementar o Gateway de Aplicativo para entrada nos Serviços de Aplicativo do Azure.

• Implante o Application Gateway e configure uma política de 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 de tráfego dinâmicos.
• 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 por 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, em caso de falha, que uma instância esteja sendo 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 pela 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 de Chaves 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 poderia.

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 vinculadas à rede virtual. Os grupos de zonas DNS privadas garantem que os registros DNS de link privado sejam 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 de Chaves para Link Privado.
  • Negar acesso de rede pública ao SQL do Azure.

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 da regra e a função.

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 habilitam 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

Fiabilidade

A arquitetura dos Serviços de Aplicativo de linha de base 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 enfrenta 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. Dessa forma, as zonas de disponibilidade ajudam você a obter confiabilidade, fornecendo alta disponibilidade e tolerância a falhas.

Gateway de Aplicativo

Implante o Gateway de Aplicativo do Azure v2 em uma configuração redundante de zona. Considere o uso de uma contagem mínima de instâncias de escala 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 de Aplicativos

• 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 para fora 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 de Uso Geral, Premium ou Crítico de Negócios com redundância de zona habilitada. As camadas Uso Geral, Premium e Crítica de Negócios dão suporte à redundância de zona no Banco de Dados SQL do Azure.
• Configure backups de banco de dados SQL para usar ZRS (armazenamento com redundância de zona) ou GZRS (armazenamento com redundância de zona geográfica).

Armazenamento de Blobs

• O ZRS (Zone-Redundant Storage, armazenamento com redundância de zona) do Azure 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 entre 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.

Escalabilidade

A escalabilidade permite que os aplicativos lidem com aumentos e diminuições na demanda, otimizando o desempenho e o custo. As seções a seguir discutem a escalabilidade para os principais componentes dessa arquitetura.

Gateway de Aplicativo

• Implemente o dimensionamento automático para o Application Gateway para aumentar ou reduzir a escala para atender à demanda.
• Defina a contagem máxima de instâncias para um número maior do que a necessidade esperada. Você só será cobrado pelas Unidades de Capacidade que usar.
• 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 Aplicativo

• Use planos Standard ou superiores com três ou mais instâncias de trabalho para alta disponibilidade.
• Habilite o Autoscale para garantir que você possa aumentar e reduzir 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 Standard.
• Considere a implantação de 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 veicular 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
• Escalando horizontalmente com o Banco de Dados SQL do Azure
• Usar réplicas somente leitura para descarregar cargas de trabalho de consulta somente leitura

Outras diretrizes de escalabilidade

• Revise os limites e cotas de assinatura 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 da transação semi-estáticos.
  • Estado de sessão.
  • Saída HTML. Isso pode ser útil em aplicativos que renderizam saídas HTML complexas.

Segurança

A arquitetura do Serviço de Aplicativo de linha de base se concentra nas 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 Aplicativo

• Desabilitar métodos de autenticação local para implantações de site FTP e SCM
• Desativar 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 das plataformas com suporte, linguagens de programação, protocolos e estruturas.
• Considere o Ambiente do Serviço de Aplicativo se você precisar de maior isolamento ou acesso seguro à rede.

Criptografia

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 de Chaves 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 alto nível.

1. O usuário envia uma solicitação HTTPS para o aplicativo Web.
2. A solicitação HTTPS atinge o gateway de aplicativo.
3. O gateway de aplicativo usa um certificado (X.509) no Cofre de Chaves 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 de Chaves. 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 de Chaves para fornecer acesso. As políticas de acesso só permitem que você conceda 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 do 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 em repouso

• Criptografe dados confidenciais no Banco de Dados SQL do Azure usando criptografia de dados transparente. Os dados transparentes criptografam todo o banco de dados, backups e arquivos de log de transações e não exigem alterações em seu aplicativo Web.
• Minimize a latência de criptografia do banco de dados. Para minimizar a latência de criptografia, coloque os dados que você precisa proteger em seu próprio banco de dados e habilite apenas a criptografia para esse banco de dados.
• Entenda o suporte à criptografia interna. 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).

Gerenciamento de identidade e acesso

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

Identidades de usuário

• 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 pelo <application-gateway-endpoint> 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 Microsoft Entra ID. 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 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 pelo 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, confira Identidades gerenciadas.

Implantação

A implantação do aplicativo de Serviço de Aplicativo de linha de base segue as diretrizes em CI/CD para Aplicativos Web do Azure com Pipelines do Azure. Além dessa diretriz, 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 sã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 lança 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 pega 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 de CLI para atualizar o WEBSITE_RUN_FROM_PACKAGE appSetting para o nome do novo arquivo zip de publicação para o slot de preparo.

   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 definida como um nome de arquivo diferente.

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

Diretrizes de implantação

A seguir são destacadas as principais diretrizes de implantação para a arquitetura de linha de base.

• Use executar 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 arquivos entre implantação e tempo de execução e garante que apenas aplicativos totalmente implantados estejam em execução 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 selecionem 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 sobre o 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 Infraestrutura como Código (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 Teste de Carga do Azure 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 Cofre de Chaves do Azure para armazenar segredos.
• Use a configuração do Serviço de Aplicativo para a configuração do aplicativo. Se você precisar externalizar a configuração da configuração do aplicativo ou exigir suporte a sinalizador de recurso, considere usar a Configuração do Aplicativo do Azure.
• Use as referências do Cofre de Chaves 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 você alterna um slot de implantação, as configurações do aplicativo são alternadas por padrão.
• 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.

Monitoramento

Monitoramento é a coleta e análise de dados de sistemas de TI. 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 do Serviço de Aplicativo de linha de base.

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.

  Recursos do Azure	Métricas e descrições de logs
  Gateway de Aplicativo	Métricas e descrições de logs do Application Gateway
  Firewall do Aplicativo Web	Métricas e descrições de logs do firewall do aplicativo Web
  Serviço de Aplicativo	Métricas e descrições de logs do Serviço de Aplicativo
  Banco de Dados SQL do Azure	Descrição de métricas e logs do Banco de Dados SQL do Azure
  CosmosDB	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 isso custa. Para obter mais informações, consulte Cálculos e opções de custo do Log Analytics e Preços para o 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 iniciar e modificar ao longo do tempo, conforme necessário. Para saber mais, veja:

  • Visão geral dos alertas do Azure Monitor
  • Alertas do Gateway de Aplicativo
  • Alertas do Serviço de Aplicativo
  • Alertas do Banco de Dados SQL do Azure
  • Alertas de armazenamento de blobs
  • Alertas do Key Vault

Gateway de Aplicativo

O Application Gateway monitora a integridade dos recursos em seu pool de back-end. Use os logs do Application Gateway Access 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 Teste de integridade padrão do Gateway de Aplicativo e Logs de diagnóstico e integridade de back-end.

Serviço de Aplicativo

O Serviço de Aplicativo tem ferramentas de monitoramento integradas e integradas que você deve habilitar para melhorar a observabilidade. Se 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 aplicativo (APM). Para obter mais informações, consulte Monitorar o desempenho do Serviço de Aplicativo do Azure.
• Habilitar o rastreamento 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 criador de perfil de desempenho.
• Use instrumentação baseada em código para telemetria personalizada. O Azure Application Insights também oferece 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 log 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 no Espaço de Trabalho do Log Analytics.
• Ative a verificação de Integridade do Serviço de Aplicativo. A verificação de integridade redireciona as solicitações para fora de 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.

Backup de banco 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.

Governança

Os aplicativos Web se beneficiam da Política do Azure impondo decisões de arquitetura e segurança. A Política do Azure pode tornar (1) impossível implantar (negar) ou (2) fácil detectar (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 de 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 Link Privado do Azure para se conectar aos serviços de PaaS
• O Serviço de Aplicativo deve ter os métodos de autenticação local desabilitados para implantações de site FTP & 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 mais recente do TLS
• O Microsoft Defender para o Serviço de Aplicativo deve estar habilitado
• O WAF (Firewall do Aplicativo Web) deve ser habilitado para o Gateway de Aplicativo

Veja mais políticas internas para os principais serviços, 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 de comunidade (como das Zonas de Aterrissagem do Azure) se as políticas internas não cobrirem totalmente suas necessidades. Prefira políticas internas quando elas estiverem disponíveis.

Próximas etapas

Recursos relacionados

• Guia de Link Privado na WAN Virtual
• Expandir 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