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 de Aplicativo 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 de aplicativos da Internet. Este artigo também explica como integrar a CI/CD (integração contínua e implantação contínua) aos Ambientes do Serviço de Aplicativo usando o Azure DevOps.

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

Arquitetura

Baixe um arquivo do Visio dessa arquitetura.

Fluxo de dados

O fluxo de dados a seguir corresponde ao diagrama anterior:

As solicitações HTTP e HTTPS chegam ao gateway de aplicativo.
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 essa etapa.
As solicitações do usuário fluem pelo ILB (balanceador de carga interno) do ambiente, que roteia o tráfego para o aplicativo Web de despesas.
O usuário cria um relatório de despesas.
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.
O sistema armazena o relatório de despesas no Banco de Dados SQL do Azure.
Para facilitar a implantação contínua, o código é verificado na instância do Azure DevOps.
A VM (máquina virtual de build) inclui o agente do Azure DevOps. Esse agente permite que a VM de build efetue pull dos artefatos do aplicativo Web e use-os para implantar o aplicativo Web no Ambiente do Serviço de Aplicativo. A VM de build 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 com segurança o aplicativo em alta escala. O Ambiente do Serviço de Aplicativo e suas cargas de trabalho residem atrás de uma rede virtual, portanto, a instalação adiciona uma camada extra de segurança e isolamento. Esse cenário usa um Ambiente do Serviço de Aplicativo ILB para atender à necessidade de alta escala e isolamento.
Essa carga de trabalho usa o tipo 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 SSD (unidade de estado sólido) e fornece os recursos máximos de expansão.
Os recursos de Aplicativos Web e Aplicativos de API de aplicativos Web host do Serviço de Aplicativo 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 Gateway de Aplicativo é um balanceador de carga de tráfego da Web de camada 7 que gerencia o tráfego para o aplicativo Web. Ele fornece descarregamento de SSL (Secure Sockets Layer), que remove a sobrecarga de descriptografar o tráfego dos servidores Web que hospedam o aplicativo.
O Firewall do Aplicativo Web é um recurso do Gateway de Aplicativo que aprimora a segurança. O firewall do aplicativo Web usa regras OWASP (Open Worldwide Application Security Project) 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 por meio do ExpressRoute ou de uma VPN (rede virtual privada) site a site. Esse cenário permite que um ponto de extremidade de serviço na rede virtual garanta 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 build e lançamento.
Uma VM de build do Azure permite que o agente instalado efetue pull do respectivo build 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 do 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. Elimina a necessidade de gerenciar a configuração do servidor, a orquestração de contêineres e os detalhes da implantação. Os Aplicativos de Contêiner fornecem todos os recursos de servidor de data up-tonecessários para manter seus aplicativos estáveis e seguros.
O AKS (Serviço de Kubernetes do Azure) é um projeto de software livre e uma plataforma de orquestração projetada para hospedar aplicativos multicontener complexos 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 do Kubernetes. Você deve ter um conhecimento significativo da plataforma Kubernetes para dar suporte e mantê-la, portanto, hospedar apenas alguns aplicativos Web em contêineres de instância única pode não ser a melhor opção.

Use a seguinte alternativa para a camada de dados:

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

Possíveis casos de uso

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

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

Endereçar decisões de design de TLS e DNS

As configurações do 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 do Serviço de Aplicativo ILB é interno para a 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 ao ambiente de rede virtual. Por exemplo, a Contoso Corporation pode usar um domínio raiz padrão para internal.contoso.com aplicativos destinados a serem resolvidos e acessíveis somente na rede virtual da Contoso. Um aplicativo nessa rede virtual pode ser acessado acessando APP-NAME.internal.contoso.com.

O sufixo de domínio personalizado se aplica 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 *.scm.CUSTOM-DOMAINSAN (Nome Alternativo da Entidade), o site do Gerenciador de Controle de Origem (SCM) se tornará acessível a partir de APP-NAME.scm.CUSTOM-DOMAIN. Você só pode acessar o SCM por 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 do Serviço de Aplicativo ILB:

Armazene um certificado TLS (Segurança de Camada de Transporte ou SSL) válido em um cofre de chaves do Azure em . Formato PFX.
Verifique se 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 atribuída pelo usuário para o Ambiente do Serviço de Aplicativo. A identidade gerenciada é autenticada no cofre de chaves do Azure em que o certificado SSL ou TLS reside.
Espere que o Ambiente do Serviço de Aplicativo aplique 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 que pode ser acessado na sub-rede em que o Ambiente do Serviço de Aplicativo é 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 no 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 a configuração de DNS.

Proteger o nome do host padrão exclusivo

O recurso de nome de host padrão exclusivo 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 seus recursos do Serviço de Aplicativo, ninguém de fora da sua organização poderá recriar recursos que tenham o mesmo nome de host padrão. Essa proteção impede que atores mal-intencionados explorem entradas DNS pendentes e assumam subdomínios. Para obter mais informações, consulte Secure unique default hostnames.

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ê faz aos seus clientes. Para obter mais informações, consulte a lista de verificação de revisão de design para Confiabilidade.

Considere usar a escala distribuída geograficamente com ambientes do Serviço de Aplicativo para maior resiliência e escalabilidade.
Examine os padrões de design típicos para resiliência e implemente-os quando apropriado.
Considere usar a replicação geográfica ativa para a camada de dados e o armazenamento com redundância geográfica para imagens e filas.
Para obter mais informações, consulte os seguintes recursos:

Disponibilidade

Considere aplicar os padrões de design típicos para disponibilidade ao criar seu aplicativo de nuvem.
Examine as considerações de disponibilidade na arquitetura de referência de aplicativo Web do Serviço de Aplicativo apropriada.
Para outras considerações de disponibilidade, consulte os guias de confiabilidade por serviço.

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 a lista de verificação de revisão de design para Segurança.

Examine as considerações de segurança na arquitetura de referência de aplicativo Web do Serviço de Aplicativo apropriada.
Considere seguir o processo de Ciclo de Vida de Desenvolvimento de Segurança para ajudar os desenvolvedores a criar software mais seguro e atender aos requisitos de conformidade de segurança, reduzindo o custo de desenvolvimento.
Use a Proteção contra DDoS do Azure e as práticas recomendadas de design de aplicativo para melhorar a proteção contra ataques de DDoS (negação de serviço distribuído). Habilite a Proteção contra DDoS em redes virtuais de perímetro.

Otimização de custos

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

Explore o custo de execução desse 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.

Implantação pequena: este exemplo de preço representa os componentes para uma instância mínima de nível de produção que atende alguns milhares de usuários por mês. O aplicativo usa uma única instância pequena de um aplicativo Web isolado. Cada componente extra é dimensionado para uma camada Básica para minimizar o custo, garantindo o suporte ao SLA (contrato de nível de serviço) e capacidade suficiente para lidar com uma carga de trabalho em nível de produção.
Implantação média: este exemplo de preço representa os componentes de uma implantação de tamanho moderado que atende aproximadamente 100.000 usuários por mês. Uma instância isolada do Serviço de Aplicativo isolada moderadamente gerencia o tráfego. A capacidade do Gateway de Aplicativo e do Banco de Dados SQL aumenta para dar suporte à carga de trabalho adicionada.
Implantação grande: este exemplo de preços representa os componentes de um aplicativo de alta escala que atende milhões de usuários por mês e move terabytes de dados. Esse nível de uso requer aplicativos Web de alto desempenho de camada isolada implantados em várias regiões e fronted pelo Gerenciador de Tráfego do Azure. A estimativa inclui o Gerenciador de Tráfego e instâncias extras do Gateway de Aplicativo e da Rede Virtual. A capacidade do Banco de Dados SQL aumenta para dar suporte à carga de trabalho adicionada.

Para ver os preços de 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 carga de trabalho de dimensionar para atender às demandas do usuário com eficiência. Para obter mais informações, consulte a lista de verificação de revisão de design para Eficiência de Desempenho.

Entenda como a escala funciona nos Ambientes do Serviço de Aplicativo.
Examine as práticas recomendadas para dimensionamento automático de aplicativos de nuvem.
Entenda os padrões de design típicos para escalabilidade ao criar um aplicativo de nuvem.
Examine as considerações de escalabilidade na arquitetura de referência de aplicativo Web do Serviço de Aplicativo apropriada.

Colaboradores

A Microsoft mantém este artigo. Os colaboradores a seguir escreveram este artigo.

Autor principal:

Nicholas McCollum | Engenheiro de cliente principal

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

Próximas etapas

Comentários

Esta página foi útil?