As APIs têm-se tornado cada vez mais proeminentes na forma como as empresas e os clientes acedem aos serviços, tanto interna como externamente. Internamente, as APIs são utilizadas para aceder a aplicações de linha de negócio, soluções criadas em casa e integrações de terceiros. Externamente, mais empresas parecem ser produtivas e rentabilizar as suas APIs. Com esta tendência em mente, Gestão de API se torna um componente central para uma abordagem padrão de gestão, governação e publicação de APIs para audiências internas e externas.
Com a ajuda de Gateway de Aplicação do Azure, agora é possível proteger e restringir o acesso das APIs que são servidas através do Azure Gestão de API. Este artigo descreve uma solução onde pode gerir as APIs internas e externas através de uma única instância Gestão de API. Pode manter uma postura segura de ser exposta diretamente através da Internet, mas é acedida através de um Gateway de Aplicação.
Nota
Esta arquitetura é utilizada como base do acelerador de zonas de destino do Azure Gestão de API no Cloud Adoption Framework.
Arquitetura
Este diagrama de arquitetura começa com uma caixa abrangente que representa o âmbito de uma subscrição, uma zona de DNS Privado onde os domínios privados serão resolvidos e o âmbito de uma rede virtual denominada VNet APIM-CS. Na parte superior da subscrição encontra-se uma caixa que indica que se trata de uma carga de trabalho no local. A caixa tem um ícone de servidor no mesmo. Um pipe indica uma ligação site a site ou o Azure ExpressRoute liga-se à instância Gestão de API na subscrição do Azure. Existem sete caixas mais pequenas dentro da caixa grande que mostra a subscrição do Azure. Quatro das caixas estão na linha superior e três estão na linha inferior. Cada caixa individual representa uma sub-rede separada, com um grupo de segurança de rede anexado. A partir da esquerda, existe um endereço IP público anexado ao Gateway de Aplicação do Azure na caixa mais à esquerda na linha superior. Gateway de Aplicação também se encontra numa das sete caixas mais pequenas, com a sub-rede denominada sub-rede GW da Aplicação. À direita encontra-se outra caixa que contém a instância Gestão de API, com a sub-rede denominada sub-rede APIM. Junto à mesma encontra-se a terceira caixa na linha superior, que contém um ponto final privado para a instância Funções do Azure na sub-rede denominada sub-rede PE. A caixa mais à direita na linha superior é a sub-rede de back-end que contém as Aplicações de Funções do Azure, o plano de Serviço de Aplicações do Azure para a função e a conta de armazenamento associada à Aplicação de Funções. Na linha inferior, a partir da esquerda, encontra-se uma caixa que contém o Azure Bastion na sub-rede bastion. A segunda caixa contém a VM jumbox de gestão na Sub-rede Jump Box. A última caixa na linha inferior é o Agente de DevOps contido na sub-rede DevOps. No canto inferior direito da imagem, encontram-se três recursos partilhados com os respetivos ícones. Da esquerda para a direita, são as seguintes caixas: cofre de chaves, informações da aplicação e área de trabalho do Log Analytics. Existem dois conjuntos de fluxos de trabalho. O primeiro fluxo de trabalho é indicado em círculos pretos e o outro fluxo de trabalho é indicado em círculos azuis, o que será explicado em secções posteriores. O fluxo de trabalho preto indica o acesso das APIs que estão disponíveis externamente. O fluxo começa a partir do utilizador que acede ao endereço IP Público. Em seguida, a seta aponta para a direção do Gateway de Aplicação, desde o Gateway de Aplicação ao ponto final privado e do ponto final privado até à Aplicação de Funções. O fluxo de trabalho azul começa a partir de um servidor no local, com uma seta que aponta para a instância Gestão de API, através de um ícone de pipeline que indica uma ligação site a site ou através do ExpressRoute. O resto do fluxo é o mesmo que descrito acima: do Gestão de API ao ponto final privado e do ponto final privado para a Função do Azure.
Esta arquitetura pressupõe que as políticas estão implementadas a partir do acelerador de zonas de destino do Azure e que a estrutura é impulsionada para baixo a partir do grupo de gestão.
Transfira um ficheiro do Visio desta arquitetura.
Fluxo de trabalho
Cenário híbrido (círculos azuis)
Este cenário requer uma ligação site a site ou do Azure ExpressRoute ao seu ambiente no local.
- Uma aplicação no local requer acesso a uma API interna que é servida através do Azure Gestão de API.
- Gestão de API liga às APIs de back-end alojadas no Funções do Azure. Esta ligação é através de um ponto final privado, que está disponível através do plano Funções do Azure Premium e está alojada na sua própria sub-rede.
- O ponto final privado acede de forma segura à API interna alojada no Funções do Azure.
Cenário de Acesso Externo (círculos pretos)
- Uma aplicação externa acede a um endereço IP público ou FQDN personalizado, que está anexado ao Gateway de Aplicação do Azure.
- Gateway de Aplicação funciona como a firewall de aplicações Web, que requer certificados PFX para terminação SSL.
- Gestão de API liga-se às APIs de back-end, que estão alojadas no Funções do Azure, através de um ponto final privado. Este ponto final está disponível através do plano Funções do Azure Premium e está alojado na sua própria sub-rede.
- O ponto final privado acede de forma segura à API disponível externamente que está alojada no Funções do Azure.
Componentes
A arquitetura utiliza os seguintes componentes:
O Azure Gestão de API é um serviço gerido que lhe permite gerir serviços em ambientes híbridos e multi cloud. A gestão de API funciona como uma fachada para abstrair a arquitetura de back-end e fornece controlo e segurança para a observabilidade e consumo da API para utilizadores internos e externos.
Funções do Azure é uma solução sem servidor que lhe permite concentrar-se mais em blocos de código que podem ser executados com uma gestão de infraestrutura mínima. As funções podem ser alojadas em vários planos de alojamento, enquanto esta arquitetura de referência utiliza o plano premium, devido à utilização de pontos finais privados.
Gateway de Aplicação do Azure é um serviço gerido que atua como um balanceador de carga de camada 7 e firewall de aplicações Web. Neste cenário, o gateway de aplicação protege a instância interna da APIM, que lhe permite utilizar o modo interno e externo.
As zonasDNS Privado DNS do Azure permitem-lhe gerir e resolver nomes de domínio numa rede virtual, sem ter de implementar uma solução DNS personalizada. Uma zona de DNS Privado pode ser alinhada com uma ou mais redes virtuais através de ligações de rede virtual. Devido ao Funções do Azure estar exposto sobre um ponto final privado que esta arquitetura de referência utiliza, tem de utilizar uma zona DNS privada.
O Azure MonitorApplication Insights ajuda os programadores a detetar anomalias, diagnosticar problemas e compreender os padrões de utilização. O Application Insights apresenta gestão de desempenho de aplicações extensível e monitorização para aplicações Web em direto. São suportadas várias plataformas, incluindo .NET, Node.js, Java e Python. Suporta aplicações alojadas no Azure, no local, num ambiente híbrido ou noutras clouds públicas. O Application Insights está incluído como parte desta arquitetura de referência, para monitorizar os comportamentos da aplicação implementada.
O Log Analytics do Azure Monitor permite-lhe editar e executar consultas de registo com dados nos Registos do Azure Monitor, opcionalmente a partir do portal do Azure. Os programadores podem executar consultas simples para um conjunto de registos ou utilizar o Log Analytics para realizar análises avançadas. Em seguida, podem visualizar os resultados. O Log Analytics está configurado como parte desta arquitetura de referência, para agregar todos os registos de monitorização para obter mais análises e relatórios.
O Azure Máquinas Virtuais é um recurso de computação que pode ser utilizado para alojar muitas cargas de trabalho diferentes. Nesta arquitetura de referência, as máquinas virtuais são utilizadas para fornecer um servidor jumpbox de gestão, bem como um anfitrião para o agente de DevOps ou o corredor do GitHub.
O Azure Key Vault é um serviço cloud que armazena e acede de forma segura a segredos, que vão desde chaves de API e palavras-passe a certificados e chaves criptográficas. Esta arquitetura de referência utiliza Key Vault do Azure para armazenar os certificados SSL utilizados pelo Gateway de Aplicação.
O Azure Bastion é uma plataforma como serviço aprovisionada na rede virtual do programador. Fornece conectividade RDP/SSH segura às máquinas virtuais do programador através do TLS, a partir do portal do Azure. Com o Azure Bastion, as máquinas virtuais já não necessitam de um endereço IP público para ligar através de RDP/SSH. Esta arquitetura de referência utiliza o Azure Bastion para aceder ao agente de DevOps ou ao servidor de corredor do GitHub ou ao servidor jump box de gestão.
Se utilizar uma ferramenta de DevOps, como o Azure DevOps ou o GitHub, os agentes ou corredores alojados na cloud operam através da Internet pública. Uma vez que a gestão de API nesta arquitetura está definida como uma rede interna, terá de utilizar um agente de DevOps que tenha acesso à VNet. O agente de DevOps irá ajudá-lo a implementar políticas e outras alterações às APIs na sua arquitetura. Estes para separar o processo e permitir que as suas equipas de desenvolvimento implementem alterações, por API. São executados pelos corredores do DevOps.
Alternativas
Para os serviços de back-end aos quais a instância Gestão de API se liga, estão disponíveis várias alternativas, além de Funções do Azure, que é utilizada nesta implementação de referência:
- Serviço de Aplicações do Azure é um serviço totalmente gerido baseado em HTTP que cria, implementa e dimensiona aplicações Web. São todos suportados .NET, .NET Core, Java, Ruby, Node.js, PHP e Python. As aplicações podem ser executadas e dimensionadas em ambientes baseados em Windows ou Linux.
- Azure Kubernetes Service oferece clusters do Kubernetes totalmente geridos para uma experiência de integração contínua integrada e entrega contínua (CI/CD), governação e segurança.
- O Azure Logic Apps é uma plataforma baseada na cloud que cria e executa fluxos de trabalho automatizados. Pode encontrar uma arquitetura de referência de exemplo na Integração empresarial básica no Azure.
- O Azure Container Apps permite-lhe executar microsserviços e aplicações em contentor numa plataforma sem servidor.
Para implementações de várias regiões, considere utilizar o Azure Front Door para fornecer acesso rápido, fiável e seguro entre os seus utilizadores e os conteúdos Web estáticos e dinâmicos das suas aplicações.
Para ver exemplos adicionais de como Gateway de Aplicação podem proteger APIs, veja Proteger APIs com Gateway de Aplicação e Gestão de API.
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser utilizados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, veja Microsoft Azure Well-Architected Framework.
Fiabilidade
A fiabilidade garante que a sua aplicação cumpre os compromissos assumidos com os seus clientes. Para obter mais informações, veja Descrição geral do pilar de fiabilidade.
- Implemente pelo menos duas unidades de escala de Gestão de API que estão distribuídas por duas zonas de disponibilidade, por região. Este método maximiza a disponibilidade e o desempenho.
- O VNet Peering proporciona um excelente desempenho numa região, mas tem um limite de escalabilidade máximo de 500 redes. Se precisar que sejam ligadas mais cargas de trabalho, utilize um design hub spoke ou a vWAN do Azure.
Segurança
A segurança fornece garantias contra ataques deliberados e abuso dos seus valiosos dados e sistemas. Para obter mais informações, veja Descrição geral do pilar de segurança.
- Gestão de API políticas de validação estão disponíveis para validar pedidos e respostas de API relativamente a um esquema OpenAPI. Estas funcionalidades não substituem uma Firewall de Aplicações Web, mas podem fornecer proteção adicional contra algumas ameaças. Adicionar políticas de validação pode ter implicações de desempenho, pelo que recomendamos que utilize testes de carga de desempenho para avaliar o impacto no débito da API.
- Implemente o Azure Firewall de Aplicações Web (WAF) à frente de Gestão de API para fornecer proteção contra exploits e vulnerabilidades comuns de aplicações Web.
- Aplique valores nomeados com Key Vault segredos para proteger informações confidenciais em políticas de APIM.
- Utilize Gateway de Aplicação para aceder externamente a uma instância da APIM interna para proteger a instância da APIM e ativar a conectividade híbrida.
- Implemente o gateway de Gestão de API numa VNet para suportar a conectividade híbrida e uma maior segurança.
- O VNet Peering proporciona um excelente desempenho numa região, mas tem um limite de escalabilidade máximo de 500 redes. Se precisar que sejam ligadas mais cargas de trabalho, utilize um design hub spoke ou a vWAN do Azure.
Otimização de custos
A otimização de custos consiste em procurar formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, veja Descrição geral do pilar de otimização de custos.
- Devido à necessidade de zona de disponibilidade e suporte de rede virtual, selecionámos o escalão Premium de Gestão de API, seguindo os preços de cada região. Além disso, nesta carga de trabalho, Funções do Azure está alojada no plano Premium, devido à necessidade de acesso à VNet.
- Para prova de conceito ou protótipos, recomendamos que utilize outras camadas de Gestão de API (como Programador ou Standard).
Excelência operacional
A excelência operacional abrange os processos de operações que implementam uma aplicação e a mantêm em execução na produção. Para obter mais informações, veja Descrição geral do pilar de excelência operacional.
- Gestão de API configurações devem ser representadas como modelos arm e deve adotar uma mentalidade de infraestrutura como código.
- Utilize um processo de CI/CD para gerir, versão e atualizar configurações de Gestão de API.
- Crie pesquisas de estado de funcionamento personalizadas para ajudar a validar o estado da instância de gestão de API. Utilize o URL
/status-0123456789abcdefpara criar um ponto final de estado de funcionamento comum para o serviço APIM no gateway de aplicação. - Os certificados atualizados no cofre de chaves são rodados automaticamente no Gestão de API, que é atualizado dentro de 4 horas.
- Implemente pelo menos duas unidades de escala de Gestão de API que estão distribuídas por duas zonas de disponibilidade, por região. Este método maximiza a disponibilidade e o desempenho.
Implementar este cenário
Esta arquitetura está disponível no GitHub. Contém todos os ficheiros de infraestrutura como código necessários e as instruções de implementação.
Contribuidores
Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.
Principais autores:
- Pete Messina | Arquiteto Sénior de Soluções Cloud
- Anthony Nevico | Arquiteto Sénior de Soluções Cloud
Para ver perfis do LinkedIn não públicos, inicie sessão no LinkedIn.
Passos seguintes
- Esta mesma arquitetura é utilizada como base do acelerador de zonas de destino Gestão de API do Azure no Cloud Adoption Framework.
- CI/CD para Gestão de API com modelos de Resource Manager do Azure
- Introdução ao Gestão de API
- Gerir APIs com APIM
- Recursos do Gestão de API para começar
Veja estes recursos principais:
- Acelerador de zonas de destino do Azure
- Operações de API
- Documentação do Azure Gestão de API
- Conceitos-chave do Azure Gestão de API
- Documentação do Gateway de Aplicação
- Acelerador de zonas de destino do Azure Gestão de API
Saiba mais sobre estes serviços principais:
- descrição geral do Funções do Azure
- Zonas de DNS Privado do Azure
- Descrição geral do Aplicação Azure Insights
- Descrição geral do Azure Log Analytics
- Descrição geral do Azure Máquinas Virtuais
- Conceitos do Azure Key Vault
- Descrição geral do Azure Bastion