Práticas recomendadas para proteger as suas aplicações e APIs com o Apigee

Last reviewed 2025-04-01 UTC

Este documento descreve as práticas recomendadas que podem ajudar a proteger as suas aplicações e APIs através da gestão de APIs da Apigee e dos seguintes produtos Google Cloud :

Este documento destina-se a arquitetos de API, arquitetos de segurança e responsáveis de engenharia que gerem a infraestrutura de uma aplicação e que pretendam expor APIs seguras, escaláveis e com bom desempenho.

Este documento usa uma série de arquiteturas de exemplo para demonstrar as práticas recomendadas para usar a gestão de APIs do Apigee. Este documento também aborda as práticas recomendadas para usar a proteção de apps Web e APIs (WAAP), uma solução de segurança abrangente que pode usar para ajudar a proteger as suas aplicações e APIs.

Este documento pressupõe que tem conhecimentos sobre redes, APIs e Google Cloud.

Gestão de APIs da Apigee

O Apigee é uma plataforma para desenvolver e gerir APIs. Ao adicionar uma camada de proxy aos seus serviços, o Apigee fornece uma abstração ou uma fachada que ajuda a proteger as suas APIs de serviços de back-end.

Os utilizadores podem interagir com aplicações através do OAuth 2.0 e de intervalos de endereços IP na lista de autorizações. Conforme mostrado na imagem seguinte, os utilizadores podem interagir com uma aplicação, e os dados e os serviços são expostos num fluxo bidirecional.

Pontos de segurança entre a interação do utilizador com uma aplicação e o back-end.

Os pontos de segurança são os seguintes:

  • Utilizadores:
    • OAuth 2.0
    • Controlo de acesso por endereço IP
  • Aplicações
    • Chaves da API
    • OAuth 2.0
    • TLS
  • Programadores e parceiros
    • SSO
    • RBAC
  • APIs
    • OAuth 2.0
    • OpenID Connect
    • Quotas
    • Spike arrest
    • Proteção contra ameaças
  • Equipa da API
    • RBAC do IAM
    • Lógica federada
    • Ocultação de dados
    • Registos de auditoria
  • Back-end
    • Redes privadas
    • TLS mútuo
    • Controlo de acesso por endereço IP

Como mostra a imagem anterior, pode usar diferentes mecanismos de segurança numa aplicação, como a chave de API ou o OAuth 2.0 com Transport Layer Security (TLS). Também pode adicionar limites de taxa, políticas de proteção contra ameaças e configurar o TLS mútuo no back-end da sua camada de API.

Para ajudar a gerir o acesso de uma equipa de APIs na plataforma Apigee, o Apigee tem controlo de acesso baseado em funções (CABF) e início de sessão federado.

Recomendamos que use as políticas predefinidas do Apigee para proteger as suas APIs. As políticas são as seguintes:

  • Gestão de tráfego. Ajuda a configurar o armazenamento em cache, controlar as quotas, mitigar os efeitos dos picos e controlar o tráfego da API.
  • Proteção ao nível da mensagem. Permite inspecionar e validar payloads de pedidos para ajudar a proteger o seu back-end de atacantes maliciosos.
  • Segurança. Ajuda a controlar o acesso às suas APIs.

Pode anexar uma ou mais destas políticas à sua camada de proxy. A tabela seguinte lista o exemplo de utilização de segurança para cada política, categorizado por tipo de política.

Tipo de política Nome da política Exemplo de utilização de segurança
Gestão de tráfego Política SpikeArrest Aplica a limitação de taxa ao número de pedidos enviados para o back-end.
Gestão de tráfego Política de quotas Ajuda a sua organização a aplicar quotas (o número de chamadas de API feitas) para cada consumidor.
Gestão de tráfego Política ResponseCache Coloca as respostas em cache, reduzindo o número de pedidos ao back-end.
Proteção ao nível da mensagem Política de validação da OAS Valida as solicitações recebidas ou as mensagens de resposta com base numa especificação OpenAPI 3.0 (JSON ou YAML).
Proteção ao nível da mensagem Política SOAPMessageValidation Valida mensagens XML de acordo com um esquema à sua escolha. Valida mensagens SOAP de acordo com um WSDL e determina se as mensagens JSON e XML têm o formato correto.
Proteção ao nível da mensagem Política JSONThreatProtection Ajuda a mitigar o risco de ataques ao nível do conteúdo, permitindo-lhe especificar limites em estruturas JSON, como matrizes e strings.
Proteção ao nível da mensagem Política XMLThreatProtection Ajuda a resolver vulnerabilidades de XML e a mitigar o risco de ataques através da avaliação do conteúdo das mensagens e da deteção de mensagens danificadas ou com formato incorreto antes de poderem ser analisadas.
Proteção ao nível da mensagem Política RegularExpressionProtection Avalia o conteúdo com base em expressões regulares predefinidas e rejeita-o se a expressão for verdadeira.
Segurança Política de BasicAuthentication Codifica e descodifica credenciais de utilizador em Base64.
Segurança Política VerifyAPIKey Aplica a validação das chaves da API em tempo de execução. Só permite que as aplicações com chaves da API aprovadas associadas aos seus produtos de API acedam às suas APIs.
Segurança Política OAuthV2 Realiza operações do tipo de concessão OAuth 2.0 para gerar e validar tokens de acesso.
Segurança Políticas de JWS e JWT Gera, valida e descodifica símbolos da Web JSON (JWT) e assinaturas Web JSON (JWS).
Segurança Política de HMAC Calcula e valida o código de autenticação de mensagens baseado em hash (HMAC) para autenticação e verificações de integridade ao nível da aplicação.
Segurança Política de SAMLAssertion
  • Valida as mensagens recebidas que contêm uma afirmação SAML com assinatura digital.
  • Gera afirmações SAML para pedidos XML de saída.
Segurança Política de CORS Permite definir cabeçalhos de partilha de recursos de origem cruzada (CORS) para APIs consumidas por aplicações Web.

Recomendamos que use o Cloud Armor para o controlo de acesso com base no endereço IP e na localização geográfica. No entanto, nos casos em que não for possível, pode usar a política AccessControl. Para ajudar a proteger as ligações do Apigee ao seu back-end, o Apigee também oferece a gestão de keystores, que lhe permite configurar o keystore e o truststore para os handshakes TLS.

Pode usar o Apigee para criar produtos de API que lhe permitem agrupar as suas operações de API e disponibilizá-las aos programadores de aplicações para consumo. Um produto API agrupa uma ou mais operações. Uma operação especifica um proxy de API e caminhos de recursos que podem ser acedidos nesse proxy. Uma operação também pode limitar o acesso por métodos HTTP e por quota.

Utiliza produtos de API para controlar o acesso às suas APIs. Ao definir um ou mais produtos da API numa aplicação para programadores, pode restringir o acesso a proxies com uma chave da API. Por exemplo, as aplicações para dispositivos móveis usadas pelos clientes só podem executar uma operação POST no ponto final /v1/payments, neste caso, https://$DOMAIN/v1/payments. Noutro exemplo, as aplicações de centros de chamadas usadas pelos funcionários dos centros de chamadas podem realizar operações como PUT ou DELETE no ponto final /payments, como https://$DOMAIN/v1/payments/1234, para reverter ou anular pagamentos.

Arquitetura inicial

Esta secção descreve uma arquitetura de microsserviços de exemplo com os serviços implementados no centro de dados e no fornecedor de nuvem. As seguintes práticas recomendadas de arquitetura demonstram como pode iterar e melhorar a arquitetura inicial.

Exemplo de arquitetura de microsserviços com os serviços implementados no centro de dados e no fornecedor de nuvem.

A arquitetura inicial é a seguinte:

  • Os serviços de pagamentos e contas estão alojados no centro de dados e o serviço de transferência de dinheiro está alojado em Google Cloud.
  • O balanceador de carga de aplicações externo controla e configura a entrada nos serviços.
  • O Application Load Balancer externo encaminha o pedido para o serviço de terceiros ou o back-end adequado e processa o handshake TLS.

No estado inicial, a arquitetura de exemplo tem as seguintes restrições:

  • É improvável que seja escalável.
  • É improvável que proteja um sistema contra ataques maliciosos
  • Não reflete as práticas recomendadas consistentes para segurança e registo, porque estes serviços são desenvolvidos e mantidos por diferentes equipas na organização.

Práticas recomendadas de arquitetura

O Apigee pode adicionar valor e facilitar a exposição dos seus serviços aos consumidores através da implementação de um conjunto padrão de políticas de segurança em todas as APIs. Esta secção aborda as práticas recomendadas para usar o Apigee de modo a ajudar a proteger as suas APIs.

Use o Apigee como uma camada de proxy

O diagrama seguinte mostra a arquitetura inicial com a adição do Apigee como uma camada de proxy (fachada):

Apigee como camada de proxy.

O Apigee é aprovisionado num Google Cloud projeto e o tempo de execução é aprovisionado e intercambiado num projeto de inquilino através do intercâmbio de redes VPC. Para ajudar a proteger o seu sistema, em vez de enviar dados através da Internet, pode usar o Apigee como uma camada de proxy para estabelecer uma ligação direta (privada) ao seu centro de dados através do Cloud Interconnect.

O fluxo de pedidos é o seguinte:

  1. O cliente envia o pedido para o Application Load Balancer externo com as credenciais da aplicação, por exemplo, uma chave, um token ou um certificado.
  2. O balanceador de carga encaminha o pedido para o Apigee.
  3. O Apigee processa o pedido, executa as políticas de segurança conforme descrito na gestão de APIs da Apigee e permite ou nega o pedido. O Apigee também pode ser usado para encaminhar o pedido para diferentes back-ends com base no cliente, no pedido ou no cliente e no pedido.
  4. O Apigee encaminha o pedido para os back-ends do GKE diretamente através de endereços IP internos. A comunicação entre o Apigee e o serviço de transferência de dinheiro pode ocorrer através de um endereço RFC 1918 (endereço IP interno) porque estão na rede com peering.
  5. O Apigee envia o pedido para os back-ends do centro de dados privado através do Cloud Interconnect.
  6. O Apigee envia o pedido para serviços de terceiros através do aprovisionamento do endereço IP NAT do Apigee.

Use o Cloud Armor como uma camada de WAF com o Apigee

Pode adicionar o Cloud Armor à arquitetura para aumentar o perímetro de segurança. O Cloud Armor faz parte da infraestrutura de balanceamento de carga global para o Google Cloud. Oferece capacidades de firewall de aplicação Web (WAF) e ajuda a evitar ataques de negação de serviço distribuída (DDoS). Também pode ajudar a mitigar a ameaça às aplicações dos riscos indicados no OWASP Top 10.

Pode configurar regras e políticas no Cloud Armor para avaliar cada chamada feita pelo cliente que atinge o Application Load Balancer externo. Também pode automatizar a configuração das políticas do Cloud Armor. Para mais informações sobre como configurar regras no Cloud Armor, consulte os guias de instruções do Cloud Armor.

O diagrama seguinte mostra a arquitetura de exemplo com o Apigee e o Cloud Armor implementados:

Arquitetura com o Cloud Armor.

O fluxo de eventos nesta arquitetura é semelhante aos abordados em Use o Apigee como uma camada de proxy anteriormente neste documento. O fluxo de pedidos é o seguinte:

  1. O cliente envia o pedido para o Application Load Balancer externo com as credenciais da aplicação, por exemplo, uma chave, um token ou um certificado.
  2. O Cloud Armor filtra o pedido porque o Application Load Balancer externo tem a funcionalidade ativada. Aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, o Cloud Armor rejeita o pedido e apresenta uma mensagem de erro e um código de estado.
  3. Se não existirem violações de regras do Cloud Armor, o Application Load Balancer externo encaminha o pedido para o Apigee.
  4. O Apigee processa o pedido, executa as políticas de segurança e permite ou recusa o pedido. Também pode ser usado para encaminhar o pedido para diferentes backends com base no cliente, no pedido ou em ambos.
  5. O Apigee encaminha o pedido diretamente para os back-ends do GKE através de endereços IP internos. A comunicação entre o Apigee e o serviço de transferência de dinheiro pode ocorrer através de um endereço RFC 1918 (endereço IP interno) porque estão na rede com peering.
  6. O Apigee envia o pedido para os back-ends do centro de dados privado através do Cloud Interconnect.
  7. O Apigee envia o pedido para serviços de terceiros através do aprovisionamento do endereço IP NAT do Apigee.

Use a WAAP

Para melhorar ainda mais o seu perfil de segurança, também pode usar a WAAP, que reúne o Cloud Armor, o reCAPTCHA e o Apigee para ajudar a proteger o seu sistema contra ataques DDoS e bots. Também oferece proteção de WAF e API.

Recomendamos a WAAP para exemplos de utilização empresariais em que as chamadas API são feitas a partir de um Website e aplicações para dispositivos móveis. Pode definir as aplicações para carregar as bibliotecas reCAPTCHA para gerar um token reCAPTCHA e enviá-lo quando fazem um pedido.

O diagrama seguinte mostra o fluxo de trabalho:

Fluxo de solicitação para WAAP.

O fluxo de pedidos no diagrama anterior é o seguinte:

  • (1) Todos os pedidos HTTP(S) dos clientes e consumidores de API são enviados para o balanceador de carga da aplicação externo.
  • (2) O primeiro ponto de contacto na solução WAAP é o Cloud Armor.
  • (2a) Se nenhuma destas regras for acionada pelas políticas do Cloud Armor, é enviado um pedido à API reCAPTCHA para avaliar se o tráfego recebido é um pedido legítimo ou não.
  • (3a) Se for um pedido legítimo, o pedido é encaminhado para o back-end.
  • (2b) Se o pedido não for legítimo, o Cloud Armor pode recusar o pedido e enviar um código de resposta 403 ao utilizador.
  • (3b) Para quaisquer pedidos de API, após a avaliação das regras OWASP do Cloud Armor e da proteção contra DDoS, o pedido é encaminhado para o Apigee para verificar a validade do pedido de API.
  • (4) O Apigee determina se as chaves da API ou os tokens de acesso usados no pedido são válidos. Se o Apigee determinar que o pedido não é legítimo, pode enviar um código de resposta 403.
  • (5) Se o pedido for legítimo, o Apigee encaminha-o para o back-end.

O diagrama seguinte mostra a arquitetura da WAAP com o Cloud Armor, o reCAPTCHA e o Apigee para os pedidos de API.

Fluxo de pedidos para WAAP com Cloud Armor, reCAPTCHA e Apigee.

O fluxo de pedidos no diagrama anterior é o seguinte:

  1. O cliente envia o pedido para o Application Load Balancer externo com as credenciais da aplicação, por exemplo, uma chave, um token ou um certificado.
  2. Uma vez que o Application Load Balancer externo tem o Cloud Armor ativado, o Cloud Armor seleciona o pedido. Aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, o Cloud Armor rejeita o pedido com uma mensagem de erro e um código de estado.
  3. Para chamadas de Websites, como o envio de um formulário para uma página de início de sessão, o Cloud Armor está integrado com o reCAPTCHA. O reCAPTCHA avalia o tráfego recebido e adiciona pontuações de risco ao tráfego legítimo. Para tráfego que não seja legítimo, o Cloud Armor pode negar o pedido.
  4. Se não existirem violações de regras do Cloud Armor, o Application Load Balancer externo encaminha o pedido de API para o Apigee.
  5. O Apigee processa o pedido, executa as políticas de segurança e permite ou recusa o pedido. O Apigee também pode ser usado para encaminhar o pedido para diferentes backends com base no cliente, no pedido ou em ambos.
  6. O Apigee encaminha o pedido para os back-ends do GKE diretamente através de endereços IP internos. A comunicação entre o Apigee e o serviço de transferência de dinheiro pode ocorrer através do endereço RFC 1918, que é um endereço IP interno, porque ambos estão na rede com peering.
  7. O Apigee envia o pedido para os back-ends do centro de dados privado através do Cloud Interconnect.
  8. O Apigee envia o pedido para serviços de terceiros através do aprovisionamento de endereços IP NAT do Apigee.

Use o Cloud CDN para colocar em cache

A RFC na nuvem usa a rede global da Google para fornecer conteúdo mais próximo dos utilizadores, o que acelera os tempos de resposta dos seus Websites e aplicações. A RFC do Google Cloud também oferece capacidades de colocação em cache que ajudam a proteger o back-end devolvendo a resposta da respetiva cache. Ao colocar em cache os dados acedidos com frequência num front-end da Google (GFE), que se encontra no limite da rede Google, mantém os dados o mais perto possível dos utilizadores e permite o acesso mais rápido possível.

A CDN na nuvem também ajuda as organizações a processarem facilmente picos sazonais no tráfego, por exemplo, picos que podem ocorrer durante a época festiva ou o regresso às aulas. Esta abordagem à colocação em cache ajuda a melhorar a fiabilidade e a experiência do utilizador num ecossistema. Também pode ajudar a minimizar a carga do servidor Web, o cálculo e a utilização da rede. Para implementar esta arquitetura, tem de ativar a RFC na solução de equilíbrio de carga que serve tráfego para o Apigee.

Pode usar a CDN na nuvem com qualquer uma das opções abordadas neste documento. O diagrama seguinte mostra a arquitetura de exemplo inicial da WAAP com a adição do Cloud CDN.

Fluxo de pedidos com a RFC de multimédia na nuvem.

O fluxo de pedidos apresentado no diagrama anterior é o seguinte:

  1. O cliente usa bibliotecas do reCAPTCHA para obter um token e envia o pedido para o Application Load Balancer externo com as credenciais da aplicação, por exemplo, uma chave, um token ou um certificado.
  2. A RFC na nuvem verifica a cache com a chave de cache e devolve a resposta se o resultado da cache for verdadeiro.
  3. Se o resultado da cache for falso, o Cloud Armor filtra o pedido porque o Application Load Balancer externo tem o Cloud Armor ativado. O Cloud Armor aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, rejeita o pedido com uma mensagem de erro e um código de estado.
  4. O Cloud Armor está integrado com o reCAPTCHA, que avalia o tráfego de entrada legítimo com classificações de risco. Para tráfego que não seja legítimo, o Cloud Armor pode recusar o pedido.
  5. Se não existirem violações de regras do Cloud Armor, o Application Load Balancer externo encaminha o pedido para o Apigee.
  6. O Apigee processa o pedido, executa as políticas de segurança conforme descrito na gestão de APIs da Apigee e permite ou nega o pedido. Também pode ser usado para encaminhar o pedido para diferentes backends com base no cliente, no pedido ou no cliente e no pedido.
  7. O Apigee encaminha o pedido para os back-ends do GKE diretamente através de endereços IP internos. A comunicação entre o Apigee e o serviço de transferência de dinheiro pode ocorrer através do endereço RFC 1918, que é um endereço IP interno, porque estão na rede com peering.
  8. O Apigee envia o pedido para os back-ends do centro de dados privado através do Cloud Interconnect.
  9. O Apigee envia o pedido para serviços de terceiros através do aprovisionamento do endereço IP NAT do Apigee.
  10. Quando uma resposta flui de volta para o cliente, o Cloud CDN armazena-a em cache para que possa devolver a resposta da cache para chamadas futuras.

O que se segue?