Editar

Partilhar via


Acelerador de zona de aterrissagem do Azure API Management

Azure API Management
Azure Application Gateway
Azure Functions
.NET

As APIs têm se tornado cada vez mais proeminentes na forma como empresas e clientes acessam serviços, tanto interna quanto externamente. Internamente, as APIs são usadas para acessar aplicativos de linha de negócios, soluções domésticas e integrações de terceiros. Externamente, mais empresas procuram ser produtivas e rentabilizar as suas APIs. Com essa tendência em mente, o Gerenciamento de API torna-se um componente central para uma abordagem padrão de gerenciamento, governança e publicação de APIs para públicos internos e externos.

Com a ajuda do Azure Application Gateway, agora é possível proteger e restringir o acesso de APIs que são servidas por meio do Gerenciamento de API do Azure. Este artigo descreve uma solução onde você pode gerenciar APIs internas e externas por meio de uma única instância de Gerenciamento de API. Você pode manter uma postura segura de ser exposto diretamente pela Internet, mas em vez disso é acessado por meio de um Application Gateway.

Nota

Essa arquitetura é usada como a base da orientação para o Gerenciamento de API do Azure nas zonas de aterrissagem do Azure na Estrutura de Adoção de Nuvem.

Arquitetura

Diagrama que mostra a arquitetura do acelerador de zona de aterrissagem do Gerenciamento de API.

Este diagrama de arquitetura começa com uma caixa abrangente que representa o escopo de uma assinatura, uma zona DNS privada onde os domínios privados serão resolvidos e o escopo de uma rede virtual nomeia APIM-CS VNet. Na parte superior da assinatura há uma caixa que indica que é uma carga de trabalho local. A caixa tem um ícone de servidor dentro dela. Um pipe indica uma conexão site a site ou o Azure ExpressRoute se conecta à instância de Gerenciamento de API na assinatura do Azure. Sete caixas menores adicionais estão dentro da caixa grande que mostra a assinatura do Azure. Quatro das caixas estão na linha superior e três na linha inferior. Cada caixa individual representa uma sub-rede separada, com um grupo de segurança de rede anexado. Na parte mais à esquerda, há um endereço IP público anexado ao Gateway de Aplicativo do Azure na caixa mais à esquerda na linha superior. O Application Gateway também vive dentro de uma das sete caixas menores, com a sub-rede chamada sub-rede App GW. À direita está outra caixa que contém a instância de 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 de Função do Azure, o plano do Serviço de Aplicativo do Azure para a função e a conta de armazenamento associada ao Aplicativo de Função. 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 jumbox de gerenciamento 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, estão três recursos compartilhados com seus respetivos ícones. Da esquerda para a direita, estão as seguintes caixas: cofre de chaves, insights de aplicativos e espaço de trabalho de análise de log. 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, que serão explicados em seções posteriores. O fluxo de trabalho preto indica o acesso de APIs que estão disponíveis externamente. O fluxo começa a partir do usuário acessando o endereço IP público. Em seguida, a seta aponta para a direção do Application Gateway, do Application Gateway para o ponto de extremidade privado e do ponto de extremidade privado para o Function App. O fluxo de trabalho azul começa a partir de um servidor local, com uma seta que aponta para a instância de Gerenciamento de API, por meio de um ícone de pipeline que indica uma conexão site a site ou via Rota Expressa. O restante do fluxo é o mesmo descrito acima: do Gerenciamento de API para o ponto de extremidade privado e do ponto de extremidade privado para o Azure Function.

Essa arquitetura pressupõe que as políticas estejam em vigor a partir do acelerador de zona de aterrissagem do Azure e que a estrutura seja direcionada para baixo a partir do grupo de gerenciamento.

Transfira um ficheiro do Visio desta arquitetura.

Fluxo de Trabalho

Cenário híbrido (círculos azuis)

Este cenário requer uma conexão site a site ou uma conexão do Azure ExpressRoute com seu ambiente local.

  1. Um aplicativo local requer acesso a uma API interna que é servida por meio do Gerenciamento de API do Azure.
  2. O Gerenciamento de API se conecta às APIs de back-end hospedadas no Azure Functions. Essa conexão é por meio de um ponto de extremidade privado, que está disponível por meio do plano Premium do Azure Functions e é hospedado em sua própria sub-rede.
  3. O ponto de extremidade privado acessa com segurança a API interna hospedada no Azure Functions.

Cenário de acesso externo (círculos pretos)

  1. Um aplicativo externo acessa um endereço IP público ou FQDN personalizado, que é anexado ao Gateway de Aplicativo do Azure.
  2. O Application Gateway atua como o firewall do aplicativo Web, que requer certificados PFX para terminação SSL.
  3. O Gerenciamento de API se conecta às APIs de back-end, que são hospedadas no Azure Functions, por meio de um ponto de extremidade privado. Este ponto de extremidade está disponível através do plano Azure Functions Premium e está alojado na sua própria sub-rede.
  4. O ponto de extremidade privado acessa com segurança a API disponível externamente 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 e fornece controle e segurança para a observabilidade e o consumo de API para usuários internos e externos.

  • O Azure Functions é uma solução sem servidor que permite que você se concentre mais em blocos de código que podem ser executados com gerenciamento mínimo de infraestrutura. As funções podem ser hospedadas em vários planos de hospedagem, enquanto esta arquitetura de referência usa o plano premium, devido ao uso de endpoints privados.

  • O Gateway de Aplicativo do Azure é um serviço gerenciado que atua como um 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, que permite usar o modo interno e externo.

  • As zonas DNS Privadas do Azure permitem-lhegerir e resolver nomes de domínio numa rede virtual, sem necessidade de implementar uma solução DNS personalizada. Uma zona DNS privada pode ser alinhada a uma ou mais redes virtuais, através de links de rede virtual. Devido ao Azure Functions ser exposto em um ponto de extremidade privado que essa arquitetura de referência usa, você deve usar uma zona DNS privada.

  • O Azure MonitorApplication Insights ajuda os desenvolvedores a detetar anomalias, diagnosticar problemas e entender padrões de uso. O Application Insights apresenta gerenciamento e monitoramento extensíveis de desempenho de aplicativos para aplicativos Web ao vivo. Várias plataformas são suportadas, incluindo .NET, Node.js, Java e Python. Ele dá suporte a aplicativos hospedados no Azure, no local, em um ambiente híbrido ou em outras nuvens públicas. O Application Insights é incluído como parte dessa arquitetura de referência, para monitorar os comportamentos do aplicativo implantado.

  • O Azure MonitorLog Analytics 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 para um conjunto de registros ou usar o Log Analytics para executar análises avançadas. Eles podem então visualizar os resultados. O Log Analytics é configurado como parte dessa arquitetura de referência, para agregar todos os logs de monitoramento para 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 DevOps ou o corredor GitHub.

  • O Azure Key Vault é um serviço de nuvem que armazena e acessa segredos com segurança, que vão desde chaves de API e senhas até certificados e chaves criptográficas. Essa arquitetura de referência usa o Azure Key Vault para armazenar os certificados SSL usados pelo Application Gateway.

  • 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 por TLS, a partir do portal do Azure. 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 DevOps ou o servidor runner do GitHub ou o servidor de caixa de salto de gerenciamento.

Se você usar uma ferramenta de DevOps, como o Azure DevOps ou o GitHub, os agentes ou corredores hospedados na nuvem operarão pela Internet pública. Como o gerenciamento de API nessa arquitetura é definido como uma rede interna, você precisará usar um agente de DevOps que tenha acesso à rede virtual. O agente de DevOps ajudará você a implantar políticas e outras alterações nas APIs em sua arquitetura. Eles Modelos de CI/CD podem ser usados para separar o processo e permitir que suas equipes de desenvolvimento implantem alterações, por API. Eles são executados pelos corredores de DevOps.

Alternativas

Para os serviços de back-end aos quais a instância de Gerenciamento de API se conecta, várias alternativas estão 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 baseado em HTTP totalmente gerenciado que cria, implanta e dimensiona aplicativos Web. .NET, .NET Core, Java, Ruby, Node.js, PHP e Python são suportados. Os aplicativos podem ser executados e dimensionados em ambientes baseados em Windows ou Linux.
  • O Serviço Kubernetes do Azure oferece clusters Kubernetes totalmente gerenciados para uma experiência, governança e segurança integradas de integração contínua e entrega contínua (CI/CD).
  • As Aplicações Lógicas do Azure são uma plataforma baseada na nuvem que cria e executa fluxos de trabalho automatizados. Um exemplo de arquitetura de referência pode ser encontrado em Integração empresarial básica no Azure.
  • Os Aplicativos de Contêiner do Azure permitem que você execute microsserviços e aplicativos em contêineres 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 seus usuários e o conteúdo da Web estático e dinâmico de seus aplicativos.

Para ver exemplos adicionais de como o Application Gateway pode proteger APIs, consulte Proteger APIs com o Application Gateway e o Gerenciamento de APIs.

Considerações

Essas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que podem ser usados para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Microsoft Azure Well-Architected Framework.

Fiabilidade

A confiabilidade garante que seu aplicativo possa atender aos compromissos que você assume com seus clientes. Para obter mais informações, consulte 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. Este método maximiza a sua disponibilidade e desempenho.
  • O emparelhamento VNet oferece um ótimo desempenho em uma região, mas tem um limite de escalabilidade de no máximo 500 redes. Se você precisar que mais cargas de trabalho estejam conectadas, use um design hubspoke ou Azure vWAN.

Segurança

A segurança oferece garantias contra ataques deliberados e o abuso de seus valiosos dados e sistemas. Para obter mais informações, consulte Visão geral do pilar de segurança.

  • As políticas de validação do Gerenciamento de API estão disponíveis para validar solicitações e respostas de API em relação a um esquema OpenAPI. Esses recursos não substituem um Web Application Firewall, mas podem fornecer proteção adicional 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 seu impacto na taxa de transferência da API.
  • Implante o Firewall de Aplicativo Web do Azure (WAF) 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 Cofre da Chave para proteger informações confidenciais em políticas de APIM.
  • Use o Application Gateway para acesso externo de uma instância interna do APIM para proteger a instância do APIM e habilitar a conectividade híbrida.
  • Implante o gateway de Gerenciamento de API em uma rede virtual, para oferecer suporte à conectividade híbrida e ao aumento da segurança.
  • O emparelhamento VNet oferece um ótimo desempenho em uma região, mas tem um limite de escalabilidade de no máximo 500 redes. Se você precisar que mais cargas de trabalho estejam conectadas, use um design hubspoke ou Azure vWAN.

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, consulte Visão geral do pilar de otimização de custos.

  • Devido à necessidade de zona de disponibilidade e suporte de rede virtual, selecionamos o nível Premium de Gerenciamento de API, seguindo os preços para 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 que você use outras camadas de Gerenciamento de API (como Developer ou Standard).

Excelência operacional

A excelência operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Visão geral do pilar de excelência operacional.

  • As configurações de 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, versionar e atualizar as configurações do Gerenciamento de API.
  • Crie testes de integridade personalizados para ajudar a validar o status da sua instância de gerenciamento de API. Use a URL /status-0123456789abcdef para 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 alternados 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. Este método maximiza a disponibilidade e o desempenho.

Implementar este cenário

Essa arquitetura está disponível no GitHub. Ele contém todos os arquivos de infraestrutura como código necessários e as instruções de implantação.

Contribuidores

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

Principais autores:

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

Próximos passos

Consulte estes recursos-chave:

Saiba mais sobre estes serviços essenciais: