As APIs têm se tornado cada vez mais importantes no modo como empresas e clientes acessam serviços interna e externamente. Internamente, elas são usadas para acessar aplicativos de linha de negócios, soluções criadas internamente e integrações de terceiros. E externamente, pois é cada vez maior o número de empresas que procuram ser produtivas e monetizar suas APIs. Considerando essa tendência, o Gerenciamento de API torna-se um componente central de uma abordagem padrão de gerenciamento, controle e publicação de APIs para públicos-alvo internos e externos.
Com a ajuda do Gateway de Aplicativo do Azure, agora é possível proteger e restringir o acesso de APIs que são fornecidas por meio do Gerenciamento de API do Azure. Este artigo descreve uma solução com a qual você pode gerenciar APIs internas e externas por meio de uma única instância do Gerenciamento de API. Você pode manter uma postura de segurança, evitando se expor diretamente pela internet, mas em vez disso o acesso é feito por meio de um Gateway de Aplicativo.
Observação
Essa arquitetura é usada como base das diretrizes para o Gerenciamento de API do Azure em zonas de destino do Azure no Cloud Adoption Framework.
Arquitetura
Este diagrama de arquitetura começa com uma caixa abrangente que representa o escopo de uma assinatura, uma zona de DNS privado em que os domínios privados serão resolvidos e o escopo de uma rede virtual identificada como VNet APIM-CS. Na parte superior da assinatura, há uma caixa que indica que consiste em uma carga de trabalho local. Na parte interna da caixa, há um ícone de servidor. Uma barra vertical indica uma conexão site a site, ou o Azure ExpressRoute se conecta à instância do Gerenciamento de API na assinatura do Azure. Há outras sete caixas menores dentro da caixa grande que mostra a assinatura do Azure. Quatro caixas estão na linha superior e três na linha inferior. Cada caixa representa uma sub-rede separada com um grupo de segurança de rede conectada. Na extremidade esquerda, há um endereço IP público anexado ao Gateway de Aplicativo do Azure na caixa mais à esquerda na linha superior. O Gateway de Aplicativo também fica localizado em uma das sete caixas menores, com a sub-rede chamada sub-rede App GW. À direita, há outra caixa, que contém a instância do Gerenciamento de API, com a sub-rede chamada sub-rede APIM. Ao lado dela, está a terceira caixa na linha superior, que contém um ponto de extremidade privado para a instância do Azure Functions na sub-rede chamada sub-rede PE. A caixa mais à direita na linha superior é a sub-rede de back-end que contém os Aplicativos Azure Functions, o plano do Serviço de Aplicativo do Azure para a função e a conta de armazenamento associada ao Aplicativo Functions. Na linha inferior, começando pela esquerda, há uma caixa que contém o Azure Bastion na sub-rede Bastion. A segunda caixa contém a VM do Jumpbox de gerenciamento na sub-rede Jump Box. A última caixa na linha inferior é o Agente do DevOps contido na sub-rede DevOps. No canto inferior direito da imagem, há três recursos compartilhados e os respectivos ícones. Da esquerda para a direita, estão as seguintes caixas: Key Vault, Application Insights e o espaço de trabalho do Log Analytics. Existem dois conjuntos de fluxos de trabalho. O primeiro fluxo de trabalho está indicado em círculos pretos, e o outro em círculos azuis, o que será explicado em seções mais adiante. O fluxo de trabalho preto indica o acesso de APIs disponíveis externamente. O fluxo começa com o usuário acessando o endereço IP público. A seta indica a direção do Gateway de Aplicativo, deste para o ponto de extremidade privado e deste para o aplicativo Functions. O fluxo de trabalho azul começa em um servidor local, com uma seta que aponta para a instância do Gerenciamento de API, por meio de um ícone de pipeline que indica uma conexão site a site ou via ExpressRoute. O restante do fluxo é igual ao descrito acima: do Gerenciamento de API para o ponto de extremidade privado e deste para o Azure Functions.
Esta arquitetura pressupõe que as políticas estão em vigor a partir do acelerador de zona de destino do Azure e que a estrutura é reduzida a partir do grupo de gerenciamento.
Baixe um Arquivo Visio dessa arquitetura.
Workflow
Cenário híbrido (círculos azuis)
Este cenário requer uma conexão site a site ou do Azure ExpressRoute para seu ambiente local.
- Um aplicativo local precisa de acesso a uma API interna que é fornecida por meio do Gerenciamento de API do Azure.
- O Gerenciamento de API conecta-se às APIs de back-end hospedadas no Azure Functions. Essa conexão ocorre por meio de um ponto de extremidade privado, que está disponível no plano Premium do Azure Functions e é hospedado em sua própria sub-rede.
- O ponto de extremidade privado acessa com segurança a API interna hospedada no Azure Functions.
Cenário de acesso externo (círculos pretos)
- Um aplicativo externo acessa um endereço IP público ou um FQDN personalizado, que está conectado ao Gateway de Aplicativo do Azure.
- O Gateway de Aplicativo atua como o firewall de aplicativo Web, que requer certificados PFX para a terminação SSL.
- O Gerenciamento de API conecta-se às APIs de back-end, hospedadas no Azure Functions, por meio de um ponto de extremidade privado. Esse ponto de extremidade está disponível por meio do plano Premium do Azure Functions e é hospedado em sua própria sub-rede.
- O ponto de extremidade privado acessa com segurança a API disponível externamente que está hospedada no Azure Functions.
Componentes
A arquitetura usa os seguintes componentes:
O Gerenciamento de API do Azure é um serviço gerenciado que permite gerenciar serviços em ambientes híbridos e multinuvem. O gerenciamento de API atua como uma fachada para abstrair a arquitetura de back-end, além de fornecer controle e segurança para observabilidade e consumo de API para usuários internos e externos.
O Azure Functions é uma solução sem servidor que permite que você se concentre mais nos blocos de código que podem ser executados com o mínimo de gerenciamento de infraestrutura. O Functions pode ser hospedado em vários planos de hospedagem, mas essa arquitetura de referência usa o plano premium devido ao uso de pontos de extremidade privados.
O Gateway de Aplicativo do Azure é um serviço gerenciado que atua como balanceador de carga de camada 7 e firewall de aplicativo Web. Nesse cenário, o gateway de aplicativo protege a instância interna do APIM, o que permite usar o modo interno e externo.
As zonas de DSN privado do DNS do Azure permitem gerenciar e resolver nomes de domínio em uma rede virtual, sem a necessidade de implementar uma solução de DNS personalizada. Uma zona de DNS privado pode ser alinhada a uma ou mais redes virtuais por meio de links de rede virtual. Como o Azure Functions fica exposto em um ponto de extremidade privado utilizado por essa arquitetura de referência, você deve usar uma zona de DNS privado.
O Azure Insights do Application Monitor ajuda os desenvolvedores a detectar anomalias, diagnosticar problemas e entender os padrões de uso. O Application Insights conta com monitoramento e gerenciamento do desempenho de aplicativos extensíveis para aplicativos Web dinâmicos. Há suporte para várias plataformas, como .NET, Node.js, Java e Python. Ele aceita aplicativos hospedados no Azure, no local, em um ambiente híbrido ou em outras nuvens públicas. O Application Insights foi incluído nessa arquitetura de referência para monitorar os comportamentos do aplicativo implantado.
O Log Analytics do Azure Monitor permite editar e executar consultas de log com dados nos Logs do Azure Monitor, opcionalmente de dentro do portal do Azure. Os desenvolvedores podem executar consultas simples de um conjunto de registros ou usar o Log Analytics para executar análises avançadas. Eles podem visualizar os resultados. O Log Analytics é configurado como parte dessa arquitetura de referência para agregar todos os logs de monitoramento e obter mais análises e relatórios.
As Máquinas Virtuais do Azure são um recurso de computação que pode ser usado para hospedar muitas cargas de trabalho diferentes. Nessa arquitetura de referência, as máquinas virtuais são usadas para fornecer um servidor jumpbox de gerenciamento, bem como um host para o agente de DevOps ou o executor do GitHub.
O Azure Key Vault é um serviço de nuvem que armazena e acessa segredos, que abrangem de chaves de API e senhas a certificados e chaves criptográficas, com segurança. Essa arquitetura de referência usa o Azure Key Vault para armazenar os certificados SSL usados pelo Gateway de Aplicativo.
O Azure Bastion é uma plataforma como serviço provisionada na rede virtual do desenvolvedor. Ele fornece conectividade RDP/SSH segura para as máquinas virtuais do desenvolvedor do portal do Azure via TLS. Com o Azure Bastion, as máquinas virtuais não precisam mais de um endereço IP público para se conectar via RDP/SSH. Essa arquitetura de referência usa o Azure Bastion para acessar o agente de DevOps, o servidor do executor do GitHub ou o servidor jump box de gerenciamento.
Se você usa uma ferramenta de DevOps, como o Azure DevOps ou o GitHub, os agentes ou executores hospedados na nuvem operam pela Internet pública. Pelo fato de o gerenciamento de API nessa arquitetura ser definido como uma rede interna, você precisará usar um agente do DevOps que tenha acesso à rede virtual. O agente do DevOps ajudará você a implantar políticas e outras alterações nas APIs de sua arquitetura. Ele pode ser usado para separar o processo e permitir que suas equipes de desenvolvimento implantem alterações, por API. Ele é executado pelos executores de DevOps.
Alternativas
Para os serviços de back-end aos quais a instância de Gerenciamento de API se conecta, há várias alternativas disponíveis, além do Azure Functions, que é usado nesta implementação de referência:
- O Serviço de Aplicativo do Azure é um serviço totalmente gerenciado com base em HTTP que cria, implanta e dimensiona aplicativos Web. Ele dá suporte para .NET, .NET Core, Java, Ruby, Node.js, PHP e Python. Os aplicativos podem ser executados e dimensionados em ambientes baseados em Windows ou Linux.
- O Serviço de Kubernetes do Azure oferece clusters de Kubernetes totalmente gerenciados para proporcionar uma experiência integrada de CI/CD (integração contínua, entrega contínua), governança e segurança.
- Os Aplicativos Lógicos do Azure são uma plataforma baseada em nuvem que cria e executa fluxos de trabalho automatizados. Um exemplo de arquitetura de referência está disponível em Integração empresarial básica no Azure.
- Os Aplicativos de Contêiner do Azure permitem executar microsserviços e aplicativos conteinerizados em uma plataforma sem servidor.
Para implantações em várias regiões, considere usar o Azure Front Door para fornecer acesso rápido, confiável e seguro entre os usuários e o conteúdo da Web estático e dinâmico de seus aplicativos.
Para ver mais exemplos de como o Gateway de Aplicativo pode proteger APIs, consulte Proteger APIs com o Gateway de Aplicativo e o Gerenciamento de API.
Considerações
Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios de orientação que podem ser usados para aprimorar a qualidade de uma carga de trabalho. Para obter mais informações, confira Microsoft Azure Well-Architected Framework.
Confiabilidade
A confiabilidade garante que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, confira Visão geral do pilar de confiabilidade.
- Implante pelo menos duas unidades de escala do Gerenciamento de API distribuídas em duas zonas de disponibilidade, por região. Esse método maximiza a disponibilidade e o desempenho.
- O emparelhamento VNet oferece ótimo desempenho em uma região, mas tem um limite de escalabilidade de, no máximo, 500 redes. Se você precisar conectar mais cargas de trabalho, use um design de hub-spoke ou o Azure vWAN.
Segurança
A segurança fornece garantias contra ataques deliberados e o abuso de seus dados e sistemas valiosos. Para saber mais, confira Visão geral do pilar de segurança.
- Políticas de validação do Gerenciamento de API estão disponíveis para validar solicitações e respostas de API em um esquema OpenAPI. Esses recursos não substituem um Firewall de Aplicativo Web, mas podem fornecer proteção extra contra algumas ameaças. Adicionar políticas de validação pode ter implicações de desempenho, por isso recomendamos que você use testes de carga de desempenho para avaliar o impacto na taxa de transferência de API.
- Implante o Firewall de Aplicativo Web (WAF) do Azure na frente do Gerenciamento de API para fornecer proteção contra explorações e vulnerabilidades comuns de aplicativos Web.
- Aplique valores nomeados com segredos do Key Vault para proteger informações confidenciais em políticas de APIM.
- Use o Gateway de Aplicativo para acesso externo de uma instância de APIM interna para proteger a instância de APIM e habilitar a conectividade híbrida.
- Implante o gateway de Gerenciamento de API em uma VNet para oferecer mais segurança e suporte para conectividade híbrida.
- O emparelhamento VNet oferece ótimo desempenho em uma região, mas tem um limite de escalabilidade de, no máximo, 500 redes. Se você precisar conectar mais cargas de trabalho, use um design de hub-spoke ou o Azure vWAN.
Otimização de custo
A otimização de custos é a análise de maneiras de reduzir as despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, confira Visão geral do pilar de otimização de custo.
- Devido à necessidade de suporte para a zona de disponibilidade e a rede virtual, selecionamos a camada Premium do Gerenciamento de API, seguindo os preços de cada região. Além disso, nessa carga de trabalho, o Azure Functions é hospedado no plano Premium devido à necessidade de acesso à VNet.
- Para prova de conceito ou protótipos, recomendamos usar outras camadas do Gerenciamento de API (como Desenvolvedor ou Standard).
Excelência operacional
A excelência operacional abrange os processos de operações que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, confira Visão geral do pilar de excelência operacional.
- As configurações do Gerenciamento de API devem ser representadas como modelos ARM, e você deve adotar uma mentalidade de infraestrutura como código.
- Use um processo de CI/CD para gerenciar, controlar versões e atualizar as configurações do Gerenciamento de API.
- Crie testes de integridade personalizados para ajudar a validar o status da instância de gerenciamento de API. Use a URL
/status-0123456789abcdefpara criar um ponto de extremidade de integridade comum para o serviço APIM no gateway de aplicativo. - Os certificados atualizados no cofre de chaves são revezados automaticamente no Gerenciamento de API, que é atualizado em 4 horas.
- Implante pelo menos duas unidades de escala do Gerenciamento de API distribuídas em duas zonas de disponibilidade, por região. Esse método maximiza a disponibilidade e o desempenho.
Implantar este cenário
Essa arquitetura está disponível no GitHub. Ela contém todos os arquivos necessários de infraestrutura como código e as instruções de implantação.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Principais autores:
- Pete Messina | Arquiteto Sênior de Soluções de Nuvem
- Anthony Nevico | Arquiteto Sênior de Soluções de Nuvem
Para ver perfis não públicos do LinkedIn, entre no LinkedIn.
Próximas etapas
- Diretrizes do Cloud Adoption Framework para o Gerenciamento de API do Azure em zonas de destino do Azure
- CI/CD para Gerenciamento de API usando modelos do Azure Resource Manager
- Introdução ao Gerenciamento de API
- Gerenciar APIs com APIM
- Recursos do Gerenciamento de API para começar
Confira os seguintes principais recursos:
- API Ops
- Documentação do Gerenciamento de API do Azure
- Principais conceitos do Gerenciamento de API do Azure
- Documentação do Gateway de Aplicativo
Saiba mais sobre estes serviços principais:
- Visão geral do Azure Functions
- Zonas DNS privadas do Azure
- Visão geral do Azure Application Insights
- Visão geral do Azure Log Analytics
- Visão geral das Máquinas Virtuais do Azure
- Conceitos do Azure Key Vault
- Visão geral do Azure Bastion