Editar

Partilhar via

Aplicações web geridas de forma segura

Azure App Service
Azure Application Gateway
Azure SQL Database
Azure VPN Gateway
Azure Web Application Firewall

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 ao aplicativo 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 orientação sobre integração contínua e implantação contínua (CI/CD) para Ambientes do Serviço de Aplicativo usando o Azure DevOps.

Esse cenário é comumente implantado em setores como bancos e seguros, onde os clientes estão conscientes da segurança no nível da plataforma, além da segurança no nível do aplicativo. Para demonstrar esses conceitos, usaremos um aplicativo que permite que os usuários enviem relatórios de despesas.

Potenciais casos de utilização

Considere este cenário para os seguintes casos de uso:

  • Criar um Aplicativo Web do Azure onde a segurança extra é necessária.
  • Fornecer locação dedicada, em vez de planos de serviço de aplicativo de locatário compartilhado.
  • Usando o Azure DevOps com um Ambiente de Serviço de Aplicativo com balanceamento de carga (ILB) interno.

Arquitetura

Diagrama com a arquitetura de cenário de exemplo para a implantação segura do ambiente do Serviço de Aplicativo ILB.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de dados

  1. As solicitações HTTP/HTTPS chegam primeiro ao gateway do aplicativo.
  2. Opcionalmente (não mostrado no diagrama), você pode ter a autenticação do Microsoft Entra habilitada para o Web App. Depois que o tráfego atinge o gateway de aplicativo pela primeira vez, o usuário será solicitado a fornecer credenciais para autenticar com o aplicativo.
  3. As solicitações do usuário fluem através do balanceador de carga interno (ILB) do ambiente, que, por sua vez, roteia o tráfego para o Aplicativo Web de Despesas.
  4. Em seguida, o usuário continua a criar 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 e-mail do 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. A VM de compilação tem o Agente de DevOps do Azure instalado, permitindo que a VM de compilação puxe os bits para o Aplicativo Web implantar no Ambiente do Serviço de Aplicativo (já que a VM de Compilação é 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 o aplicativo com segurança em alta 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. A exigência de alta escala e isolamento impulsionou a seleção do ILB App Service Environment.
  • Essa carga de trabalho usa a camada de preço isolada do Serviço de Aplicativo, portanto, o aplicativo é executado em um ambiente dedicado privado em um datacenter do Azure usando processadores mais rápidos, armazenamento de unidade de estado sólido (SSD) e o dobro da relação memória/núcleo em comparação com o Standard.
  • O Aplicativo Web do Serviço de Aplicativo do Azure e o Aplicativo de API hospedam aplicativos Web e APIs RESTful. Esses aplicativos e APIs são hospedados no plano de 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 de SSL, que remove a sobrecarga extra dos servidores da Web que hospedam o aplicativo da Web para descriptografar o tráfego novamente.
  • O Web Application Firewall é um recurso do Application Gateway. Habilitar o firewall do aplicativo Web no gateway de aplicativos aumenta ainda mais 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 do Azure foi selecionado porque a maioria dos dados neste aplicativo são dados relacionais, com alguns dados como 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 via ExpressRoute ou site a site. Nesse caso, um ponto de extremidade de serviço é habilitado na rede virtual para garantir que os dados estejam fluindo 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 Ágil, e para criar pipelines de compilação e lançamento.
  • Uma VM de compilação do Azure foi criada para que o agente instalado possa extrair a respetiva compilação e implantar 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 implantados dentro do ambiente que estão sendo executados como contêineres Linux. Um Ambiente do Serviço de Aplicativo foi selecionado para hospedar esses aplicativos em contêiner de instância única. Há alternativas disponíveis — analise as considerações abaixo ao projetar sua solução.

  • Azure Service Fabric: se o seu ambiente for baseado principalmente no Windows e suas cargas de trabalho forem principalmente baseadas no .NET Framework e você 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, o Service Fabric suporta APIs de programação C# ou Java e, para o desenvolvimento de microsserviços nativos, os clusters podem ser provisionados no Windows ou Linux.
  • O Serviço Kubernetes do Azure (AKS) é um projeto de código aberto e uma plataforma de orquestração mais adequada 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 abstrai as complexidades de provisionamento e configuração de um cluster Kubernetes. No entanto, é necessário um conhecimento significativo da plataforma Kubernetes para suportá-la e mantê-la, portanto, hospedar um punhado de 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 seus dados estiver em formato não relacional, o Azure Cosmos DB é uma boa alternativa. Este serviço fornece uma plataforma para executar outros modelos de dados, como MongoDB, Cassandra, dados gráficos ou armazenamento de tabelas simples.

Considerações

Há certas considerações ao lidar com certificados no ILB App Service Environment. 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 o IIS (Serviços de Informações da Internet), por exemplo, a primeira etapa é gerar uma solicitação de assinatura de certificado (CSR) do servidor IIS e, em seguida, enviá-la para a autoridade emissora de certificado SSL.

Não é possível emitir um CSR a partir do ILB (Balanceador de carga interno) de um Ambiente do Serviço de Aplicativo. A maneira de lidar com essa limitação é usar o procedimento curinga.

O procedimento curinga permite que você use a prova de propriedade do nome DNS em vez de um CSR. Se você possui um namespace DNS, você pode colocar um registro TXT DNS especial, o procedimento curinga verifica se o registro está lá e, se encontrado, sabe que você possui o servidor DNS porque você tem o registro correto. Com base nessas informações, ele emite um certificado que é registrado em uma raiz confiável, que você pode carregar para seu ILB. Você não precisa fazer nada com os armazenamentos de certificados individuais nos aplicativos Web porque você tem um certificado SSL raiz confiável no ILB.

Faça com que o certificado SSL autoassinado ou emitido internamente funcione se quiser fazer chamadas seguras entre serviços em execução em um Ambiente de Serviço de Aplicativo ILB. Outra solução a considerar sobre como fazer o Ambiente do Serviço de Aplicativo ILB funcionar com o certificado SSL emitido internamente e como carregar a CA interna para o armazenamento raiz confiável.

Ao provisionar o Ambiente do Serviço de Aplicativo, considere as seguintes limitações ao escolher um nome de domínio para o 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. Para um Ambiente do Serviço de Aplicativo ILB com o nome de domínio contoso.com, você não pode 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 esses nomes de domínio personalizados. Você pode usar algo como contoso-internal.com para o domínio do seu ambiente para este exemplo, porque isso não entrará em conflito com nomes de domínio personalizados que terminam em .contoso.com.

Outro ponto a considerar é o DNS. Para permitir que os aplicativos dentro do Ambiente do Serviço de Aplicativo se comuniquem entre si, por exemplo, um aplicativo Web para falar com uma API, você precisará ter o DNS configurado para sua rede virtual que contém o ambiente. Você pode trazer seu próprio DNS ou pode usar zonas privadas do DNS do Azure.

Disponibilidade

Escalabilidade

  • Entenda como a escala funciona em ambientes do Serviço de Aplicativo.
  • Analise as práticas recomendadas para o dimensionamento automático de aplicativos na nuvem.
  • Ao criar um aplicativo em nuvem, esteja ciente dos padrões de design típicos para escalabilidade.
  • Analise as considerações de escalabilidade na arquitetura de referência apropriada do aplicativo Web do Serviço de Aplicativo.
  • Para outros artigos sobre escalabilidade, consulte a lista de verificação de eficiência de desempenho disponível no Centro de Arquitetura do Azure.

Segurança

  • Analise a visão geral do pilar de segurança.
  • Analise as considerações de segurança na arquitetura de referência apropriada do aplicativo Web do Serviço de Aplicativo.
  • Considere seguir um processo de ciclo de vida de desenvolvimento seguro para ajudar os desenvolvedores a criar software mais seguro e atender aos requisitos de conformidade de segurança, reduzindo os custos de desenvolvimento.
  • Analise a arquitetura do blueprint para conformidade com o Azure PCI DSS.
  • A Proteção contra DDoS do Azure, combinada com as práticas recomendadas de design de aplicativos, fornece recursos aprimorados de mitigação de DDoS para fornecer mais defesa contra ataques DDoS. Você deve habilitar a Proteção contra DDoS do Azure em qualquer rede virtual de perímetro.

Resiliência

Implementar este cenário

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

Preços

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

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

  • Pequeno: este exemplo de definição de preço representa os componentes necessários para uma instância mínima de nível de produção que atende 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 ainda garantirá que haja suporte a SLA (Service Level Agreement, contrato de nível de serviço) e capacidade suficiente para lidar com uma carga de trabalho de nível de produção.
  • Médio: este exemplo de definição de preço representa os componentes necessários para uma implantação de tamanho moderado. Aqui estimamos 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, níveis moderados de serviços cognitivos e de pesquisa são adicionados à calculadora.
  • Grande: este exemplo de definição de preço representa um aplicativo destinado a alta escala, da ordem de milhões de usuários por mês, movendo terabytes de dados. Nesse nível de uso, são necessários aplicativos Web de nível Premium de alto desempenho implantados em várias regiões lideradas pelo Gerenciador de Tráfego. Os dados consistem nos seguintes componentes: armazenamento, bancos de dados e CDN, todos configurados para terabytes de dados.

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

  • Faisal Mustafa - Brasil | Engenheiro de Clientes Sênior

Próximos passos