Com mais cargas de trabalho aderindo à abordagem API-first para seu design e o número crescente e a gravidade das ameaças a aplicativos da Web pela Internet, é fundamental ter uma estratégia de segurança para proteger as APIs. Um passo para a segurança da API é proteger o tráfego de rede usando o padrão de Roteamento de Gateway. Você usa o gateway para restringir os locais de origem do tráfego e a qualidade do tráfego, além de oferecer suporte a regras de roteamento flexíveis. Este artigo descreve como usar o Gateway de Aplicativo do Azure e o Gerenciamento de API do Azure para proteger o acesso à API.
Arquitetura
Este artigo não aborda os serviços subjacentes do aplicativo, como o Ambiente do Serviço de Aplicativo, a Instância Gerenciada SQL do Azure e os Serviços Kubernetes do Azure. Essas partes do diagrama apenas mostram o que você pode fazer como uma solução mais ampla. Este artigo discute especificamente as áreas sombreadas, o Gerenciamento de API e o Application Gateway.
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de Trabalho
O Application Gateway recebe solicitações HTTP que foram permitidas pelo NSG (Network Security Group) de sua sub-rede.
Em seguida, o Web Application Firewall (WAF) no Application Gateway verifica a solicitação em relação às regras do WAF, incluindo a filtragem de correspondência geográfica. Se o pedido for válido, o pedido prossegue.
O Application Gateway configura um mecanismo de proxy de URL que envia a solicitação para o pool de back-end adequado. Por exemplo, dependendo do formato de URL da chamada de API:
URLs formatados como
api.<some-domain>/external/*podem chegar ao back-end para interagir com as APIs solicitadas.Chamadas formatadas como
api.<some-domain>/*ir para um beco sem saída (sinkpool), que é um pool de back-end sem destino.
Além disso, o Application Gateway aceita e faz proxy de chamadas internas, que vêm de recursos na mesma rede virtual do Azure, em
api.<some-domain>/internal/*.Finalmente, no nível de Gerenciamento de API, as APIs são configuradas para aceitar chamadas nos seguintes padrões:
api.<some-domain>/external/*api.<some-domain>/internal/*
Nesse cenário, o gerenciamento de API usa dois tipos de endereços IP, público e privado. Os endereços IP públicos são para comunicação interna na porta 3443 e para tráfego de API de tempo de execução na configuração de rede virtual externa. Quando o Gerenciamento de API envia uma solicitação para um back-end público voltado para a Internet, ele mostra um endereço IP público como a origem da solicitação. Para obter mais informações, consulte Endereços IP do serviço de Gerenciamento de API na VNet.
Uma regra de roteamento no nível do Application Gateway redireciona adequadamente os usuários para
portal.<some-domain>/*o portal do desenvolvedor, para que os desenvolvedores possam gerenciar APIs e suas configurações de ambientes internos e externos.
Componentes
A Rede Virtual do Azure permite que muitos tipos de recursos do Azure se comuniquem de forma privada entre si, com a Internet e com redes locais.
O Gateway de Aplicativo do Azure é um balanceador de carga de tráfego da Web que gerencia o tráfego para aplicativos Web. Este tipo de encaminhamento é conhecido como balanceamento de carga da camada de aplicação (camada OSI 7). Ele hospeda um Web Application Firewall (WAF) para proteger contra vetores comuns de ataque baseados na Web.
O Gerenciamento de API do Azure é uma plataforma de gerenciamento híbrida e multinuvem para APIs em todos os ambientes. O Gerenciamento de API cria gateways de API modernos e consistentes para serviços de back-end existentes.
Recomendações
Essa solução se concentra na implementação de toda a solução e no teste do acesso à API de dentro e fora da rede virtual de Gerenciamento de API. Para obter mais informações sobre o processo de integração de rede virtual do Gerenciamento de API, consulte Integrar o gerenciamento de API em uma VNET interna com o Application Gateway.
Para se comunicar com recursos privados no back-end, o Application Gateway e o Gerenciamento de API devem estar na mesma rede virtual que os recursos ou em uma rede virtual emparelhada.
O modelo de implantação privada e interna permite que o Gerenciamento de API se conecte a uma rede virtual existente, tornando-a acessível de dentro desse contexto de rede. Para habilitar esse recurso, implante as camadas de Gerenciamento de API Developer ou Premium.
Gerencie certificados e senhas no Cofre de Chaves do Azure.
Para personalizar as interações com os serviços, você pode usar entradas CNAME.
Alternativas
Você pode usar outros serviços para fornecer um nível semelhante de proteção de firewall e WAF (Web Application Firewall):
- Azure Front Door
- Azure Firewall
- Soluções de parceiros como a Barracuda
- Outras soluções disponíveis no Azure Marketplace
Considerações
Fiabilidade
O Azure Application Gateway é sempre implantado de forma altamente disponível, independentemente da contagem de instâncias. Para evitar o impacto de um mau funcionamento de zona, você pode configurar o Application Gateway para abranger várias zonas de disponibilidade. Para obter mais informações, consulte Autoscaling and High Availability.
Habilite a redundância de zona para seus componentes de serviço de Gerenciamento de API para fornecer resiliência e alta disponibilidade. A redundância de zona replica o gateway de gerenciamento de API e o plano de controle entre datacenters em zonas fisicamente separadas, tornando-os resilientes a falhas de zona. A camada Premium de Gerenciamento de API é necessária para dar suporte a zonas de disponibilidade.
O Gerenciamento de API também oferece suporte a implantações em várias regiões, o que pode melhorar a disponibilidade se uma região ficar offline. Para obter mais informações, consulte Implantação em várias regiões. Nessa topologia, é importante também ter um Application Gateway por região, já que o Application Gateway é um serviço regional.
Segurança
Para obter mais informações sobre a segurança do Gateway de Aplicativo, consulte Linha de base de segurança do Azure para o Gateway de Aplicativo.
Para obter mais informações sobre a segurança do Gerenciamento de API, consulte Linha de base de segurança do Azure para Gerenciamento de API.
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 DDOS do Azure em qualquer rede virtual de perímetro.
Otimização de custos
O custo dessa arquitetura depende de aspetos de configuração como:
- Escalões de serviço
- Escalabilidade, ou seja, o número de instâncias alocadas dinamicamente pelos serviços para dar suporte a uma determinada demanda
- Se essa arquitetura será executada continuamente ou apenas algumas horas por mês
Depois de avaliar esses aspetos, vá para a Calculadora de Preços do Azure para estimar os preços.
Eficiência de desempenho
O Application Gateway é o ponto de entrada para essa arquitetura, e o recurso WAF requer poder de processamento adicional para cada análise de solicitação. Para permitir que o Application Gateway expanda sua capacidade computacional no local, é importante habilitar o dimensionamento automático. Para obter mais informações, consulte Especificar dimensionamento automático. Siga as recomendações da documentação do produto do tamanho da sub-rede para o Application Gateway. Isso garante que a sub-rede seja grande o suficiente para suportar a expansão total.
Para oferecer suporte a cenários altamente simultâneos, ative o dimensionamento automático do Gerenciamento de API. O dimensionamento automático expande os recursos de gerenciamento de API em resposta ao número crescente de solicitações recebidas. Para obter mais informações, consulte Dimensionar automaticamente uma instância de Gerenciamento de API do Azure.
Implementar este cenário
Esse cenário é demonstrado na publicação da galeria de início rápido do Azure do Gateway de Aplicativo com Gerenciamento de API interno e Aplicativo Web.
Próximos passos
Projete suas APIs seguindo boas diretrizes de design de API Web e implemente-as usando boas práticas de implementação de API Web.