Editar

Compartilhar via

Aplicativos web gerenciados com segurança

Serviço de aplicativo do Azure
Gateway de Aplicativo do Azure
Banco de Dados SQL do Azure
Gateway de VPN do Azure
Firewall do aplicativo Web do Azure

Este artigo fornece uma visão geral da implantação de aplicativos seguros usando o Ambiente do Serviço de Aplicativo. Para restringir o acesso a aplicativos da Internet, o serviço Gateway de Aplicativo do Azure e o Firewall de Aplicativo Web do Azure são usados. Este artigo também fornece diretrizes sobre integração contínua e implantação contínua (CI/CD) para Ambientes do Serviço de Aplicativo que usam o Azure DevOps.

Esse cenário costuma ser implantado em setores bancários e de seguros, por exemplo, em que os clientes têm conhecimento da segurança no nível da plataforma e no nível do aplicativo. Para demonstrar esses conceitos, vamos usar um aplicativo que permite que os usuários enviem relatórios de despesas.

Possíveis casos de uso

Considere este cenário para os casos de uso a seguir:

  • A criação de um aplicativo Web do Azure que exige segurança extra.
  • O fornecimento de locação dedicada, em vez de Planos do Serviço de Aplicativo de locatário compartilhado.
  • O uso do Azure DevOps com um Ambiente do Serviço de Aplicativo com um balanceador de carga interno(ILB).

Arquitetura

Diagrama apresentando a arquitetura de cenário de exemplo para implantação do Ambiente do Serviço de Aplicativo do ILB Seguro.

Baixe um Arquivo Visio dessa arquitetura.

Fluxo de dados

  1. As solicitações HTTP/HTTPS atingem primeiro o Gateway de Aplicativo.
  2. Opcionalmente (não mostrado no diagrama), a autenticação do Microsoft Entra pode estar habilitada no aplicativo Web. Depois que o tráfego alcança o Gateway de Aplicativo pela primeira vez, o usuário é solicitado a fornecer credenciais para se autenticar no aplicativo.
  3. As solicitações do usuário fluem pelo ILB (balanceador de carga interno) do ambiente, que, por sua vez, encaminha o tráfego para o aplicativo Web de despesas.
  4. Em seguida, 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 de gerente do usuário.
  6. O relatório de despesas criado é armazenado 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. O agente do Azure DevOps é instalado na VM de build, permitindo que a VM de build efetue pull nos bits para que o aplicativo Web faça a implantação no Ambiente do Serviço de Aplicativo (uma vez que a VM de build está implantada em uma sub-rede dentro da mesma rede virtual).

Componentes

  • O Ambiente do Serviço de Aplicativo fornece um ambiente totalmente isolado e dedicado para executar com segurança os aplicativos em larga escala. Além disso, como o Ambiente do Serviço de Aplicativo e as cargas de trabalho executadas nele estão atrás de uma rede virtual, ele também fornece uma camada extra de segurança e isolamento. O requisito de alta escala e isolamento levou à seleção do Ambiente do Serviço de Aplicativo ILB.
  • Essa carga de trabalho usa o tipo de preço isolado do Serviço de Aplicativo. Portanto, o aplicativo é executado em um ambiente dedicado privado em um datacenter do Azure que usa processadores mais rápidos, armazenamento em SSD e o dobro da taxa de memória/núcleo do Standard.
  • O aplicativo Web e o aplicativo de API do Serviço de Aplicativos do Azure hospedam aplicativos Web e APIs RESTful. Esses aplicativos e APIs são hospedados no plano se serviço Isolado, que também oferece dimensionamento automático, domínios personalizados e assim por diante, mas em uma camada dedicada.
  • O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web que opera na Camada 7 que gerencia o tráfego para o aplicativo Web. Ele oferece descarregamento SSL, que remove a sobrecarga extra dos servidores Web que hospedam o aplicativo Web para descriptografar o tráfego novamente.
  • O Firewall de Aplicativo Web é um recurso do Gateway de Aplicativo. A habilitação do firewall do aplicativo Web no Gateway de Aplicativo aumenta ainda mais a segurança. O firewall do aplicativo Web usa regras do Open Worldwide Application Security Project (OWASP) para proteger o aplicativo da web contra ataques como scripts entre sites, sequestros de sessão e injeção de SQL.
  • O Banco de Dados SQL do Azure foi escolhido porque a maioria dos dados deste aplicativo são relacionais, e alguns são documentos e Blobs.
  • A Rede do Azure fornece vários recursos de rede no Azure e as redes podem ser emparelhadas com outras redes virtuais no Azure. As conexões também podem ser estabelecidas com datacenters locais por meio do ExpressRoute ou site a site. Nesse caso, um ponto de extremidade de serviço é habilitado na rede virtual para garantir que os dados fluam apenas entre a rede virtual do Azure e a instância do Banco de Dados SQL.
  • O Azure DevOps é usado para ajudar as equipes a colaborar durante sprints, usando recursos que dão suporte ao Desenvolvimento Agile e para criar pipelines de lançamento e build.
  • Uma VM de build do Azure foi criada para que o agente instalado possa efetuar pull do respectivo build e implantar o aplicativo Web no ambiente do ambiente.

Alternativas

O Ambiente do Serviço de Aplicativo pode executar aplicativos Web comuns no Windows ou, como neste exemplo, aplicativos Web implantados dentro do ambiente que são executados como contêineres do Linux. O Ambiente do Serviço de Aplicativo foi escolhido para hospedar esses aplicativos conteinerizados de instância única. Essas são as alternativas disponíveis. Ao criar sua solução, analise as considerações acima.

  • Azure Service Fabric: se o seu ambiente for baseado predominantemente no Windows, e suas cargas de trabalho forem baseadas principalmente no .NET Framework e você ainda não estiver considerando rearquitetar para o .NET Core, use o Service Fabric para dar suporte e implantar contêineres do Windows Server. Além disso, Service Fabric dá suporte a APIs de programação C# ou Java e, para desenvolver microsserviços nativos, os clusters podem ser provisionados no Windows ou no Linux.
  • AKS (Serviço de Kubernetes do Azure) é um projeto de código aberto e uma plataforma de orquestração mais adequada para hospedar aplicativos de vários contêineres complexos que normalmente usam uma arquitetura baseada em microsserviços. O AKS é um serviço gerenciado do Azure que facilita o provisionamento e a configuração de um cluster do Kubernetes. Mesmo assim, é necessário ter um conhecimento significativo do Kubernetes para dar suporte e manutenção. Portanto, hospedar alguns aplicativos Web em contêineres de instância única pode não ser a melhor opção.

Outras opções para a camada de dados incluem:

  • Azure Cosmos DB: se a maioria dos dados estiver em formato não relacional, o Cosmos DB é uma boa alternativa. Esse serviço fornece uma plataforma para executar outros modelos de dados, como MongoDB, Cassandra, dados do Graph ou armazenamento de tabela simples.

Considerações

Há certas considerações ao lidar com certificados no Ambiente do Serviço de Aplicativo ILB. Você precisa gerar um certificado que esteja encadeado a uma raiz confiável sem exigir uma Solicitação de Assinatura de Certificado gerada pelo servidor onde o certificado será eventualmente armazenado. Com os Serviços de Informações da Internet (IIS), por exemplo, a primeira etapa é gerar uma solicitação de assinatura de certificado (CSR) do servidor IIS e, em seguida, enviá-lo para a autoridade de emissão de certificado SSL.

Não é possível emitir um CSR do Load Balancer Interno (ILB) de um Ambiente do Serviço de Aplicativo. A maneira de lidar com essa limitação é usar o procedimento curinga.

O procedimento curinga permite usar a prova de propriedade do nome DNS em vez de um CSR. Se você tem um namespace DNS, pode colocar um registro TXT DNS especial. O procedimento curinga verifica se o registro está lá e, quando está, sabe que você tem o servidor DNS porque você tem o registro certo. Com base nessa informação, ele emite um certificado que está assinado em uma raiz confiável, que você pode carregar no seu ILB. Você não precisa fazer nada com os repositórios de certificado individuais nos aplicativos Web porque tem um certificado SSL raiz confiável no ILB.

Faça com que o certificado SSL autoassinado ou emitido internamente funcione se você quiser fazer chamadas seguras entre serviços em execução em um Ambiente do Serviço de Aplicativo ILB. Outra solução a ser considerada é ade como fazer o Ambiente do Serviço de Aplicativo ILB funcionar com o certificado SSL emitido internamente e como carregar a AC interna no repositório raiz confiável.

Ao provisionar o Ambiente do Serviço de Aplicativo, analise estas limitações para escolher o nome de domínio do ambiente. Os nomes de domínio não podem ser:

  • net
  • azurewebsites.net
  • p.azurewebsites.net
  • nameofthease.p.azurewebsites.net

Além disso, o nome de domínio personalizado usado para aplicativos e o nome de domínio usado pelo Ambiente do Serviço de Aplicativo ILB não podem se sobrepor. Em um Ambiente do Serviço de Aplicativo ILB com o nome de domínio contoso.com, não é possível usar nomes de domínio personalizados para seus aplicativos, como:

  • www.contoso.com
  • abcd.def.contoso.com
  • abcd.contoso.com

Escolha um domínio para o Ambiente do Serviço de Aplicativo ILB que não entre em conflito com os nomes de domínio personalizados. Você pode usar algo como contoso-internal.com para o domínio do seu ambiente nesse exemplo, porque isso não entra em conflito com os nomes de domínio personalizados que terminam em .contoso.com.

Outro ponto a ser considerado é o DNS. Para que os aplicativos dentro do Ambiente do Serviço de Aplicativo se comuniquem uns com os outros, por exemplo, a comunicação de um aplicativo Web com uma API, você precisará configurar o DNS na rede virtual do Ambiente do Serviço de Aplicativo. Você pode trazer seu próprio DNS ou usar zonas DNS do Azure privadas.

Disponibilidade

Escalabilidade

Segurança

Resiliência

Implantar este cenário

Para implantar este cenário, siga este tutorial passo a passo que demonstra como implantar manualmente cada componente. Selecione o Ambiente do Serviço de Aplicativo v3 em vez do v2, ao seguir o tutorial. Este tutorial também fornece um aplicativo de exemplo do .NET que executa um aplicativo de relatório de despesas simples da Contoso.

Preços

Explore o custo de execução desse cenário. Todos os serviços são pré-configurados na calculadora de custos. Para ver como o preço mudaria para o seu uso específico, altere as variáveis apropriadas para que eles sejam correspondentes ao tráfego esperada.

Fornecemos três perfis de custo de exemplo com base na quantidade de tráfego que você espera receber:

  • Pequeno: esse exemplo de preço representa os componentes necessários para uma instância de nível mínimo de produção que atende a alguns milhares de usuários por mês. O aplicativo está usando uma única instância de um aplicativo Web padrão que será suficiente para habilitar o dimensionamento automático. Cada um dos outros componentes é dimensionado para uma camada básica que minimizará os custos, mas garante que haja suporte a acordo de nível de serviço (SLA) e capacidade suficiente para lidar com uma carga de trabalho de nível de produção.
  • Médio: esse exemplo de preço representa os componentes necessários para uma implantação de tamanho moderado. Aqui, podemos estimar aproximadamente 100.000 usuários ao longo de um mês. O tráfego esperado é tratado em uma única instância do Serviço de Aplicativo com uma camada Standard moderada. Além disso, camadas moderadas de serviços cognitivos e de pesquisa são adicionados à calculadora.
  • Grande: esse exemplo de preço representa um aplicativo de alta escala, na ordem de milhões de usuários por mês, para mover terabytes de dados. Nesse nível de uso, são necessários aplicativos web de alto desempenho e da camada Premium implantados em várias regiões administrados pelo Gerenciador de Tráfego. Os dados consistem nos seguintes componentes: armazenamento, bancos de dados e CDN, todos configurados para terabytes de dados.

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

  • Faisal Mustafa | Engenheiro sênior de clientes

Próximas etapas