Partilhar via

Aplicações web geridas de forma segura

Serviço de Aplicações do Azure
Gateway de Aplicação do Azure
Base de Dados SQL do Azure
Gateway de VPN do Azure
Firewall de Aplicações Web do Azure

Este artigo descreve como implantar aplicativos seguros usando o Ambiente do Serviço de Aplicativo. Essa arquitetura usa o Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web do Azure para restringir o acesso ao aplicativo da Internet. Este artigo também explica como integrar a integração contínua e a implantação contínua (CI/CD) com os Ambientes do Serviço de Aplicativo usando o Azure DevOps.

Setores como bancos e seguros costumam usar essa solução porque os clientes valorizam tanto a segurança no nível da plataforma quanto no nível do aplicativo. Para demonstrar esses conceitos, o aplicativo de exemplo a seguir permite que os usuários enviem relatórios de despesas.

Arquitetura

Diagrama que mostra a arquitetura de cenário de exemplo para uma implantação segura do Ambiente do Serviço de Aplicativo do balanceador de carga interno.

Baixe um arquivo Visio desta arquitetura.

Fluxo de dados

O seguinte fluxo de dados corresponde ao diagrama anterior:

  1. As solicitações HTTP e HTTPS chegam ao gateway do aplicativo.

  2. Opcionalmente, a autenticação do Microsoft Entra está habilitada para o aplicativo Web. Depois que o tráfego atinge o gateway de aplicativo, o usuário é solicitado a fornecer credenciais para autenticar com o aplicativo. O diagrama não mostra esta etapa.

  3. As solicitações do usuário fluem através do balanceador de carga interno (ILB) do ambiente, que roteia o tráfego para o aplicativo Web de despesas.

  4. O usuário cria um relatório de despesas.

  5. Como parte da criação do relatório de despesas, o aplicativo de API implantado é invocado para recuperar o nome e o email do gerente do usuário.

  6. O sistema armazena o relatório de despesas no Banco de Dados SQL do Azure.

  7. Para facilitar a implantação contínua, o código é verificado na instância do Azure DevOps.

  8. A máquina virtual (VM) de compilação inclui o agente de DevOps do Azure. Esse agente permite que a VM de compilação extraia os artefatos do aplicativo Web e os use para implantar o aplicativo Web no Ambiente do Serviço de Aplicativo. A VM de compilação reside em uma sub-rede dentro da mesma rede virtual que o Ambiente do Serviço de Aplicativo.

Componentes

  • O Ambiente do Serviço de Aplicativo fornece um ambiente totalmente isolado e dedicado para executar o aplicativo com segurança em alta escala. Tanto o Ambiente do Serviço de Aplicativo quanto suas cargas de trabalho residem atrás de uma rede virtual, portanto, a configuração adiciona uma camada extra de segurança e isolamento. Esse cenário usa um ambiente de serviço de aplicativo ILB para atender à necessidade de alta escala e isolamento.

  • Essa carga de trabalho usa a camada de preço Isolado do Serviço de Aplicativo. O aplicativo é executado em um ambiente dedicado privado em um datacenter do Azure que usa processadores mais rápidos e armazenamento de unidade de estado sólido (SSD) e fornece o máximo de recursos de expansão.

  • Os recursos Aplicativos Web e Aplicativos de API do Serviço de Aplicativo hospedam aplicativos Web e APIs RESTful. Esses aplicativos e APIs são hospedados no plano de serviço Isolado, que também fornece dimensionamento automático, domínios personalizados e outros recursos em uma camada dedicada.

  • O Application Gateway é um balanceador de carga de tráfego da Web de camada 7 que gerencia o tráfego para o aplicativo Web. Ele fornece descarregamento SSL (Secure Sockets Layer), que remove a sobrecarga de descriptografia de tráfego dos servidores Web que hospedam o aplicativo.

  • O Web Application Firewall é um recurso do Application Gateway que aumenta a segurança. O firewall do aplicativo Web usa regras do Open Worldwide Application Security Project (OWASP) para proteger o aplicativo Web contra ataques, como scripts entre sites, sequestros de sessão e injeção de SQL.

  • O Banco de dados SQL armazena os dados do aplicativo. A maioria dos dados é relacional, com alguns dos dados armazenados como documentos e blobs.

  • A Rede Virtual do Azure fornece vários recursos de rede no Azure. Você pode emparelhar redes virtuais e estabelecer conexões com datacenters locais via ExpressRoute ou uma VPN (rede virtual privada) site a site. Esse cenário habilita um ponto de extremidade de serviço na rede virtual para garantir que os dados fluam somente entre a rede virtual do Azure e a instância do Banco de Dados SQL.

  • O Azure DevOps dá suporte ao desenvolvimento ágil ajudando as equipes a colaborar durante sprints e fornecendo ferramentas para criar pipelines de compilação e lançamento.

  • Uma VM de compilação do Azure permite que o agente instalado puxe para baixo a respetiva compilação e implante o aplicativo Web no ambiente.

Alternativas

Um Ambiente do Serviço de Aplicativo pode executar aplicativos Web regulares no Windows ou, como neste exemplo, aplicativos Web executados como contêineres Linux implantados dentro do ambiente. Esse cenário usa um Ambiente do Serviço de Aplicativo para hospedar esses aplicativos em contêineres de instância única. Considere as seguintes alternativas ao projetar sua solução:

  • Os Aplicativos de Contêiner do Azure são uma plataforma sem servidor que reduz a sobrecarga de infraestrutura e economiza custos ao executar aplicativos em contêineres. Ele elimina a necessidade de gerenciar a configuração do servidor, a orquestração de contêineres e os detalhes da implantação. Container Apps fornece todos os recursos de servidor de up-todata necessários para manter seus aplicativos estáveis e seguros.

  • O Serviço Kubernetes do Azure (AKS) é um projeto de código aberto e uma plataforma de orquestração projetada para hospedar aplicativos complexos de vários contêineres que normalmente usam uma arquitetura baseada em microsserviços. O AKS é um serviço gerenciado do Azure que simplifica o provisionamento e a configuração de um cluster Kubernetes. Deve ter um conhecimento significativo da plataforma Kubernetes para a suportar e manter, por isso alojar apenas algumas aplicações web containerizadas de uma única instância pode não ser a melhor opção.

Use a seguinte alternativa para a camada de dados:

  • O Azure Cosmos DB é uma boa opção se a maioria dos seus dados estiver em formato não relacional.

Potenciais casos de utilização

Considere esta solução para os seguintes casos de uso:

  • Crie um aplicativo Web do Azure que exija segurança extra.
  • Forneça locação dedicada em vez de planos de Serviço de Aplicativo de locatário compartilhado.
  • Use o Azure DevOps com um Ambiente de Serviço de Aplicativo com balanceamento de carga interno .

Decisões de design de TLS e DNS de endereço

As configurações de DNS (Sistema de Nomes de Domínio) para o sufixo de domínio padrão do Ambiente do Serviço de Aplicativo não restringem a acessibilidade do aplicativo a esses nomes. O recurso de sufixo de domínio personalizado para um Ambiente do Serviço de Aplicativo ILB permite que você use seu próprio sufixo de domínio para acessar os aplicativos hospedados em seu Ambiente do Serviço de Aplicativo.

Um sufixo de domínio personalizado define um domínio raiz que o Ambiente do Serviço de Aplicativo usa. Para um Ambiente do Serviço de Aplicativo ILB, o domínio raiz padrão é appserviceenvironment.net. Um Ambiente de Serviço de Aplicativo ILB é interno à rede virtual de um cliente, para que os clientes possam usar um domínio raiz além do domínio padrão que se alinha com seu ambiente de rede virtual. Por exemplo, a Contoso Corporation pode usar um domínio raiz padrão de internal.contoso.com para aplicativos destinados a serem resolúveis e acessíveis somente na rede virtual da Contoso. Um aplicativo nesta rede virtual pode ser acessado acessando APP-NAME.internal.contoso.com.

O sufixo de domínio personalizado aplica-se ao Ambiente do Serviço de Aplicativo. Esse recurso difere de uma associação de domínio personalizada em uma instância individual do Serviço de Aplicativo.

Se o certificado usado para o sufixo de domínio personalizado contiver uma entrada SAN (Nome Alternativo da Entidade) para *.scm.CUSTOM-DOMAIN, o site do Gerenciador de Controle do Código-Fonte (SCM) poderá ser acessado a partir de APP-NAME.scm.CUSTOM-DOMAIN. Você só pode acessar o SCM sobre domínio personalizado usando a autenticação básica. O logon único só está disponível quando você usa o domínio raiz padrão.

Considere os seguintes fatores ao gerenciar certificados em um ambiente ILB App Service:

  • Armazene um certificado SSL ou TLS (Transport Layer Security) válido em um cofre de chaves do Azure em . Formato PFX.

  • Certifique-se de que o certificado tem menos de 20 KB.

  • Use um certificado curinga para o nome de domínio personalizado selecionado.

  • Configure uma identidade gerenciada atribuída pelo sistema ou pelo usuário para seu Ambiente do Serviço de Aplicativo. A identidade gerenciada é autenticada no cofre de chaves do Azure onde reside o certificado SSL ou TLS.

  • Espere que o Ambiente do Serviço de Aplicativo aplique as alterações de certificado dentro de 24 horas após a rotação em um cofre de chaves.

Acesso de rede ao Azure Key Vault

  • Você pode acessar o cofre de chaves publicamente ou por meio de um ponto de extremidade privado acessível a partir da sub-rede onde o Ambiente do Serviço de Aplicativo está implantado.

  • Se você usar o acesso público, poderá proteger seu cofre de chaves para aceitar apenas o tráfego do endereço IP de saída do Ambiente do Serviço de Aplicativo.

  • O Ambiente do Serviço de Aplicativo usa o endereço IP de saída da plataforma como o endereço de origem quando acessa o cofre de chaves. Você pode encontrar esse endereço IP na página Endereços IP no portal do Azure.

Configuração de DNS

Para acessar seus aplicativos em seu Ambiente do Serviço de Aplicativo usando seu sufixo de domínio personalizado, configure seu próprio servidor DNS ou configure o DNS em uma zona DNS privada do Azure para seu domínio personalizado. Para obter mais informações, consulte Configuração de DNS.

Nome de host padrão exclusivo seguro

O recurso de nome de host padrão exclusivo e seguro fornece uma solução de longo prazo para proteger seus recursos contra entradas DNS pendentes e aquisição de subdomínio. Se você habilitar esse recurso para os recursos do Serviço de Aplicativo, ninguém fora da sua organização poderá recriar recursos que tenham o mesmo nome de host padrão. Essa proteção impede que agentes mal-intencionados explorem entradas DNS pendentes e assumam o controle de subdomínios. Para obter mais informações, consulte Proteger nomes de host padrão exclusivos.

Considerações

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

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Disponibilidade

Segurança

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

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de design para otimização de custos.

Explore o custo de execução deste cenário. Os perfis de custo de exemplo a seguir são baseados no tráfego esperado. Todos os serviços são pré-configurados na calculadora de custos.

  • Pequena implantação: este exemplo de definição de preço representa os componentes para uma instância mínima de nível de produção que atende a alguns milhares de usuários por mês. O aplicativo usa uma única pequena instância de um aplicativo Web isolado. Cada componente extra é dimensionado para uma camada Básica para minimizar os custos e, ao mesmo tempo, garantir suporte ao contrato de nível de serviço (SLA) e capacidade suficiente para lidar com uma carga de trabalho de nível de produção.

  • Implantação média: este exemplo de preço representa os componentes para uma implantação de tamanho moderado que atende aproximadamente 100.000 usuários por mês. Uma única instância isolada do Serviço de Aplicativo de tamanho moderado gerencia o tráfego. A capacidade do Application Gateway e do Banco de dados SQL aumenta para dar suporte à carga de trabalho adicional.

  • Implantação grande: este exemplo de definição de preço representa os componentes de um aplicativo de alta escala que atende milhões de usuários todos os meses e move terabytes de dados. Esse nível de uso requer aplicativos Web de camada isolada de alto desempenho implantados em várias regiões e encabeçados pelo Gerenciador de Tráfego do Azure. A estimativa inclui o Gerenciador de Tráfego e instâncias extras do Application Gateway e da Rede Virtual. A capacidade do Banco de dados SQL aumenta para dar suporte à carga de trabalho adicionada.

Para ver o preço do seu caso de uso específico, altere as variáveis apropriadas para corresponder ao tráfego esperado.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

  • Nicholas McCollum - Brasil | Engenheiro de Clientes Principal

Para ver perfis não públicos do LinkedIn, inicie sessão no LinkedIn.

Próximos passos