Este documento descreve as práticas recomendadas que podem ajudar você a proteger seus aplicativos e APIs usando o gerenciamento de APIs da Apigee e os seguintes produtos do Google Cloud:
Este documento é destinado a arquitetos de API, arquitetos de segurança e líderes de engenharia que gerenciam a infraestrutura de um aplicativo e querem expor APIs seguras, escalonáveis e de alto desempenho.
Este documento usa uma série de arquiteturas de exemplo para demonstrar as práticas recomendadas para o uso do gerenciamento de APIs da Apigee. Neste documento, também discutimos as práticas recomendadas para usar a proteção de apps da Web e APIs (WAAP), uma solução de segurança abrangente que pode ser usada para ajudar a proteger seus aplicativos e APIs.
Para seguir este documento, é necessário ter familiaridade com a rede, as APIs e o Google Cloud.
Gerenciamento de APIs da Apigee
A Apigee é uma plataforma para desenvolvimento e gerenciamento de APIs. Ao adicionar uma camada de proxy aos serviços, a Apigee oferece uma abstração ou fachada que ajuda a proteger as APIs de serviço de back-end.
Os usuários podem interagir com aplicativos usando o OAuth 2.0 e os intervalos de endereços IP listados na lista de permissões. Conforme mostrado na imagem a seguir, os usuários podem interagir com um aplicativo, e os dados e serviços são expostos em um fluxo bidirecional.
Os pontos de segurança são os seguintes:
- Usuários:
- OAuth 2.0
- Controle de acesso do endereço IP
- Aplicativos
- Chaves de API
- OAuth 2.0
- TLS
- Desenvolvedores e parceiros
- SSO
- RBAC
- APIs
- OAuth 2.0
- OpenID Connect
- Cotas
- Detenção de pico
- Proteção contra ameaças
- Equipe de API
- RBAC do IAM
- Lógica federada
- Mascaramento de dados
- Registros de auditoria
- Back-end
- Rede privada
- TLS mútuo
- Controle de acesso do endereço IP
Como mostra a imagem anterior, é possível usar mecanismos de segurança diferentes em um aplicativo, como uma chave de API ou o OAuth 2.0 com o Transport Layer Security (TLS). Também é possível adicionar limitação de taxa, políticas de proteção contra ameaças e configurar o TLS mútuo ao back-end da camada da API.
Para ajudar você a gerenciar o acesso de uma equipe de API na plataforma Apigee, a Apigee tem controle de acesso baseado em papéis (RBAC) e login federado.
Recomendamos que você use as políticas padrão da Apigee para proteger suas APIs. As políticas são as seguintes:
- Gerenciamento de tráfego. Ajuda a configurar o armazenamento em cache, controlar cotas, reduzir os efeitos dos picos e controlar o tráfego da API.
- Proteção no nível da mensagem. Permite inspecionar e validar payloads de solicitação para ajudar a proteger o back-end contra invasores mal-intencionados.
- Segurança. Ajuda a controlar o acesso às suas APIs.
É possível anexar uma ou mais dessas políticas à camada do proxy. A tabela a seguir lista o caso de uso de segurança para cada política, categorizada por tipo de política.
| Tipo de política | Nome da política | Caso de uso de segurança |
|---|---|---|
| Gerenciamento de tráfego | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="wwJSt9qVSU86+j+K5hdeMDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48/BPCjCPyqbJ4QIYkewUegZAhpcwIAZaV84OTWeC1qmI=" track-metadata-position="body" track-name="internalLink"> de SpikeArrest</atrack-type="bestpractices"> | Aplica a limitação de taxa ao número de solicitações enviadas ao back-end. |
| Gerenciamento de tráfego | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="yfev46B745dkygzs/X3PYjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48drLKNEpUjCcWt0NEMR35Aw==" track-metadata-position="body" track-name="internalLink">Política de cotas</atrack-type="bestpractices"> | Ajuda sua organização a impor cotas (o número de chamadas de API feitas) para cada consumidor. |
| Gerenciamento de tráfego | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48vgnRxI3oKuq9whtN9wbwxN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">Política do cache de resposta</atrack-type="bestpractices"> | Armazena respostas em cache, reduzindo o número de solicitações ao back-end. |
| Proteção no nível da mensagem | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48agkPHIw5NGRuiTaPVjcpJ94Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">Política de OASValidation</atrack-type="bestpractices"> | Valida as solicitações ou mensagens de resposta recebidas em relação a uma especificação OpenAPI 3.0 (JSON ou YAML). |
| Proteção no nível da mensagem | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadataposition" l10n-encrypted-href="rQxnC8xh5zt2v5zuykhd8TuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48n708TfUwM7jK4ICdhKxXZ/gECJOcw35DRsjAaj5xHIk=" track-metadataposition="body" track-name="internalLink">Política de SOAPMessageValidation</atrack-type="bestpractices"> | Valida mensagens XML de acordo com um esquema de sua escolha. Valida as mensagens SOAP em um JWT e determina se as mensagens JSON e XML estão formadas corretamente. |
| Proteção no nível da mensagem | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48PH2WHMyhNs2aCSuqrjke2kkmB2frJlapcQXWoVC+6R4=" track-metadata-position="body" track-name="internalLink">Política de JSONThreatProtection</atrack-type="bestpractices"> | Ajuda a reduzir o risco de ataques no nível do conteúdo, permitindo especificar limites em estruturas JSON, como matrizes e strings. |
| Proteção no nível da mensagem | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="Ev6aAOEX4vzZEHynKB7CyzuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48G5NfGFILzHG1aUVaCe5pKIMNSUpFOiLN5W6ZMdSmR88=" track-metadata-position="body" track-name="internalLink">Política de XMLThreatProtection</atrack-type="bestpractices"> | Ajuda a solucionar vulnerabilidades XML e reduzir o risco de ataques. Para isso, avalia o conteúdo da mensagem e detecta mensagens corrompidas ou malformadas antes que elas possam ser analisadas. |
| Proteção no nível da mensagem | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadataposition" l10n-encrypted-href="gJQUlh/pVJ3nw/DE2jI8yjuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48hnl+zSlYfRHrAeiDsqUTpvpqJhesabZJgL3V8ccue2E=" track-metadataposition="body" track-name="internalLink">Política de RegularExpressionProtection</atrack-type="bestpractices"> | Avalia o conteúdo em relação a expressões regulares predefinidas e o rejeita se a expressão for verdadeira. |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="r3pD7LpDHbEckDP2z0dAEDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48juAt8VDhRW36xJUC4mFdu43Qj5Gje9MJOejmpvMk7uk=" track-metadata-position="body" track-name="internalLink">Política de BasicAuthentication</atrack-type="bestpractices"> | A Base64 codifica e decodifica as credenciais do usuário. |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48D+PigKa3fMWEhWo+2kF/jN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">Política de VerifyAPIKey</atrack-type="bestpractices"> | Aplica a verificação e a validação de chaves de API no tempo de execução. Only allows applications with approved API keys associated with your <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="408dbk6WV0fWZ26OogAdmO6/+F4vggx0AzbnRBncDef5ATRnWKKNFnIyGajdRoduwWqfpzJjBKtDKUJN+Plw7g==" track-metadata-position="body" track-name="internalLink">Produtos de API para acessar suas APIs.</atrack-type="bestpractices"> |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="1Tp726mCvkMuEnFlF5rt4zuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48yTsdQQAvZw5EhOjj9jakUw==" track-metadata-position="body" track-name="internalLink">Política do OAuthV2</atrack-type="bestpractices"> | Executa operações de tipo de concessão do OAuth 2.0 para gerar e validar tokens de acesso. |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48xNqw8rr/3fZpAtK46UMv1Yw8J3aQGcGbGAQBhAwrScg=" track-metadata-position="body" track-name="internalLink">Políticas de JWS e JWT</atrack-type="bestpractices"> | Gera, verifica e decodifica JSON Web Tokens (JWT) e JSON Web Signatures (JWS). |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48VwHhKrlRQdC046sjz4nbjA==" track-metadata-position="body" track-name="internalLink">Política de HMAC</atrack-type="bestpractices"> | Calcula e verifica o código de autenticação de mensagem baseado em hash (HMAC) para autenticação e verificações de integridade no nível do aplicativo. |
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="sNIOJtAt5FZdwfenZs4WsDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48l/hI3hS5tq+mD5Tm6KH3CN4Jvbbifor6FLtE46wrhrk=" track-metadata-position="body" track-name="internalLink">Política de SAMLAssertion</atrack-type="bestpractices"> |
|
| Segurança | <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="uT7Wlj+BBoD8kfn3kHjQDDuonRA/XAWCehsxho1ekoeCtp+MpvB2DFs8FAOMtQ48gQT0uDbIMRYnV2IytSwUdg==" track-metadata-position="body" track-name="internalLink">Política de CORS</atrack-type="bestpractices"> | Lets you set <atrack-type="bestpractices" l10n-attrs-original-order="href,track-type,track-name,track-metadata-position" l10n-encrypted-href="h61XYN2JabzN6Gs65pqwthXSVh+mabqTVA5/45yLR2rpnRTZBLB1hFjkdAWzsfw5" track-metadata-position="body" track-name="internalLink">Cabeçalhos de compartilhamento de recursos entre origens (CORS) para APIs consumidas por aplicativos da Web.</atrack-type="bestpractices"> |
Recomendamos usar o Google Cloud Armor para controle de acesso baseado em endereço IP e localização geográfica. No entanto, quando não for possível, use a política AccessControl. Para ajudar a proteger as conexões da Apigee com o back-end, a Apigee também oferece gerenciamento de keystore, que permite configurar o keystore e o truststore para handshakes de TLS.
É possível usar a Apigee para criar produtos de API que permitem empacotar suas operações de API e disponibilizá-las para desenvolvedores de aplicativos para consumo. Especificamente, um produto de API agrupa uma ou mais operações. Uma operação especifica um proxy de API e os caminhos de recursos que podem ser acessados nesse proxy. Uma operação também pode limitar o acesso por métodos HTTP e por cota.
Você usa produtos de API para controlar o acesso às suas APIs. Ao definir um ou mais
produtos de API em um aplicativo do desenvolvedor,
é possível restringir o acesso a proxies com uma chave de API. Por exemplo, os aplicativos móveis usados por clientes só podem
executar uma operação POST no endpoint /v1/payments, neste caso,
https://$DOMAIN/v1/payments. Em outro exemplo, os aplicativos de central
de atendimento usados pela equipe da central de atendimento podem executar operações como
PUT ou DELETE no endpoint /payments, como https://$DOMAIN/v1/payments/1234,
para reverter ou reverter pagamentos.
Arquitetura inicial
Nesta seção, descrevemos um exemplo de arquitetura de microsserviços com os serviços implantados no data center e no provedor de nuvem. As práticas recomendadas de arquitetura a seguir demonstram como iterar e melhorar a arquitetura inicial.
A arquitetura inicial é a seguinte:
- Os serviços de pagamentos e contas são hospedados no data center, e o serviço de transferência de dinheiro é hospedado no Google Cloud.
- O balanceador de carga de aplicativo externo controla e configura a entrada nos serviços.
- O balanceador de carga de aplicativo externo encaminha a solicitação ao serviço de back-end ou de terceiros apropriado e processa o handshake de TLS.
No estado inicial, a arquitetura de exemplo tem as seguintes restrições:
- Não há probabilidade de escalonamento.
- É improvável que um sistema seja protegido contra ataques maliciosos.
- Ele não reflete as práticas recomendadas consistentes para segurança e criação de registros, porque esses serviços são desenvolvidos e mantidos por equipes diferentes dentro da organização.
Práticas recomendadas de arquitetura
A Apigee pode agregar valor e facilitar a exposição dos serviços aos consumidores, implementando um conjunto padrão de políticas de segurança em todas as APIs. Nesta seção, abordamos as práticas recomendadas para usar a Apigee para proteger as APIs.
Usar a Apigee como uma camada de proxy
No diagrama a seguir, mostramos a arquitetura inicial com a adição da Apigee como uma camada de proxy (facade):
A Apigee é provisionada em um projeto do Google Cloud, e o ambiente de execução é provisionado e peering em um projeto de locatário usando o Peering de rede VPC. Para proteger o sistema, em vez de enviar dados pela Internet, use a Apigee como uma camada de proxy para estabelecer uma conexão direta (privada) com seu data center por meio do Cloud Interconnect.
O fluxo de solicitação é o seguinte:
- O cliente envia a solicitação para o balanceador de carga de aplicativo externo com as credenciais para o aplicativo, por exemplo, uma chave, token ou certificado.
- O balanceador de carga encaminha a solicitação para a Apigee.
- A Apigee processa a solicitação, executa as políticas de segurança conforme descrito no gerenciamento de APIs da Apigee e permite ou nega a solicitação. A Apigee também pode ser usada para rotear a solicitação para diferentes back-ends com base no cliente, na solicitação ou no cliente e na solicitação.
- A Apigee encaminha a solicitação para os back-ends do GKE diretamente por meio de endereços IP internos. A comunicação entre a Apigee e o serviço de transferência de dinheiro pode acontecer em um endereço RFC 1918 (endereço IP interno) porque eles estão dentro da rede com peering.
- A Apigee envia a solicitação para os back-ends do data center particular usando o Cloud Interconnect.
- A Apigee envia a solicitação para serviços de terceiros por meio do provisionamento de endereço IP do NAT da Apigee.
Usar o Google Cloud Armor como uma camada do WAF com a Apigee
É possível adicionar o Google Cloud Armor à arquitetura para aumentar seu perímetro de segurança. O Google Cloud Armor faz parte da infraestrutura de balanceamento de carga global do Google Cloud. Ele fornece recursos de firewall de aplicativos da Web (WAF) e ajuda a evitar ataques distribuídos de negação de serviço (DDoS). Ele também pode ajudar a reduzir a ameaça aos aplicativos dos riscos listados nos 10 principais do OWASP.
É possível configurar regras e políticas no Google Cloud Armor para avaliar todas as chamadas feitas pelo cliente que chegam ao balanceador de carga de aplicativo externo. Também é possível automatizar a configuração de políticas do Google Cloud Armor. Veja mais informações sobre como configurar regras no Google Cloud Armor nos guias de instruções do Google Cloud Armor.
O diagrama a seguir mostra a arquitetura de exemplo com a Apigee e o Google Cloud Armor no local:
O fluxo de eventos nesta arquitetura é semelhante ao fluxo discutido em Usar a Apigee como uma camada proxy anteriormente neste documento. O fluxo de solicitação é o seguinte:
- O cliente envia a solicitação para o balanceador de carga de aplicativo externo com as credenciais para o aplicativo, por exemplo, uma chave, token ou certificado.
- O Google Cloud Armor filtra a solicitação porque o balanceador de carga de aplicativo externo está ativado. Ele aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, o Google Cloud Armor rejeitará a solicitação e exibirá uma mensagem de erro e um código de status.
- Se não houver violações de regras do Google Cloud Armor, o balanceador de carga de aplicativo externo encaminha a solicitação para a Apigee.
- A Apigee processa a solicitação, executa as políticas de segurança e permite ou nega a solicitação. Ela também pode ser usada para rotear a solicitação para back-ends diferentes com base no cliente, na solicitação ou no cliente e na solicitação.
- A Apigee encaminha a solicitação aos back-ends do GKE diretamente por meio de endereços IP internos. A comunicação entre a Apigee e o serviço de transferência de dinheiro pode acontecer em um endereço RFC 1918 (endereço IP interno) porque eles estão dentro da rede com peering.
- A Apigee envia a solicitação para os back-ends do data center particular usando o Cloud Interconnect.
- A Apigee envia a solicitação para serviços de terceiros por meio do provisionamento de endereço IP do NAT da Apigee.
Usar WAAP
Para melhorar ainda mais seu perfil de segurança, também é possível usar o WAAP, que reúne o Google Cloud Armor, o reCAPTCHA Enterprise e o Apigee para ajudar a proteger seu sistema contra ataques DDoS e bots. Ele também fornece proteção WAF e API.
Recomendamos WAAP para casos de uso corporativo em que as chamadas de API são feitas de um site e aplicativos para dispositivos móveis. É possível configurar aplicativos para carregar as bibliotecas do reCAPTCHA Enterprise para gerar um token reCAPTCHA Enterprise e enviá-lo quando fizerem uma solicitação.
Veja o fluxo de trabalho no diagrama a seguir:
O fluxo de solicitação no diagrama anterior é o seguinte:
- (1) Todas as solicitações HTTP(S) por clientes e consumidores de API são enviadas para o balanceador de carga de aplicativo externo.
- (2) O primeiro ponto de contato na solução WAAP é o Google Cloud Armor.
- (2a) Se nenhuma dessas regras for acionada pelas políticas do Google Cloud Armor, uma solicitação será enviada à API reCAPTCHA Enterprise para avaliar se o tráfego de entrada é uma solicitação legítima ou não.
- (3a) Se for uma solicitação legítima, ela será encaminhada para o back-end.
- (2b) Se a solicitação não for legítima, o Google Cloud Armor poderá negar a solicitação e enviar um código de resposta 403 para o usuário.
- (3b) Para todas as solicitações de API, depois que as regras OWASP do Google Cloud Armor e a proteção contra DDoS forem avaliadas, a solicitação será encaminhada para a Apigee para verificar a validade da solicitação de API.
- (4) A Apigee determina se as chaves de API ou os tokens de acesso usados na solicitação são válidos. Se a Apigee determinar que a solicitação não é legítima, ela poderá enviar um código de resposta 403.
- (5) Se a solicitação for legítima, a Apigee encaminhará a solicitação ao back-end.
O diagrama a seguir mostra a arquitetura do WAAP com o Google Cloud Armor, o reCAPTCHA Enterprise e a Apigee para as solicitações de API.
O fluxo de solicitação no diagrama anterior é o seguinte:
- O cliente envia a solicitação para o balanceador de carga de aplicativo externo com as credenciais para o aplicativo, por exemplo, uma chave, token ou certificado.
- Como o balanceador de carga de aplicativo externo tem o Google Cloud Armor ativado, o Google Cloud Armor seleciona a solicitação. Ele aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, o Google Cloud Armor rejeitará a solicitação com uma mensagem de erro e um código de status.
- Para chamadas de site, como o envio de um formulário para uma página de login, o Google Cloud Armor é integrado ao reCAPTCHA Enterprise. O reCAPTCHA Enterprise avalia o tráfego de entrada e adiciona pontuações de risco ao tráfego legítimo. Para tráfego não legítimo, o Google Cloud Armor pode negar a solicitação.
- Se não houver violações da regra do Google Cloud Armor, o balanceamento de carga de aplicativo encaminhará a solicitação da API para a Apigee.
- A Apigee processa a solicitação, executa as políticas de segurança e permite ou nega a solicitação. A Apigee também pode ser usada para rotear a solicitação para diferentes back-ends com base no cliente, na solicitação ou em ambos.
- A Apigee encaminha a solicitação para os back-ends do GKE diretamente por meio de endereços IP internos. A comunicação entre a Apigee e o serviço de transferência de dinheiro pode acontecer pelo endereço RFC 1918 (um endereço IP interno), porque ambos estão dentro da rede com peering.
- A Apigee envia a solicitação para os back-ends do data center particular usando o Cloud Interconnect.
- A Apigee envia a solicitação para serviços terceirizados por meio do provisionamento de endereços IP NAT da Apigee.
Usar o Cloud CDN para armazenamento em cache
O Cloud CDN usa a rede global do Google para exibir o conteúdo mais próximo dos usuários, o que acelera os tempos de resposta dos sites e aplicativos. O Cloud CDN também oferece recursos de armazenamento em cache que ajudam a proteger o back-end retornando a resposta do cache. Ao armazenar em cache dados acessados com frequência em um Google Front End (GFE), que está na borda da rede do Google, ele mantém os dados o mais próximos possível dos usuários e possibilita o acesso mais rápido possível.
O Cloud CDN também ajuda as organizações a lidar facilmente com picos sazonais de tráfego, por exemplo, picos que podem ocorrer durante as festas de fim de ano ou de volta às aulas. Essa abordagem do armazenamento em cache ajuda a melhorar a confiabilidade e a experiência do usuário em um ecossistema. Também pode ajudar a minimizar o carregamento do servidor da Web, a computação e o uso da rede. Para implementar essa arquitetura, ative o Cloud CDN no balanceador de carga que veicula o tráfego para a Apigee.
O Cloud CDN pode ser usado com qualquer uma das opções discutidas neste documento. O diagrama a seguir mostra o exemplo de arquitetura inicial do WAAP com a adição do Cloud CDN.
O fluxo de solicitação mostrado no diagrama anterior é o seguinte:
- O cliente usa as bibliotecas do reCAPTCHA Enterprise para receber um token e enviar a solicitação paraBalanceamento de carga de aplicativo externo pelas credenciais do aplicativo, por exemplo, uma chave, um token ou um certificado.
- O Cloud CDN verifica o cache com a chave de cache e retorna a resposta se a ocorrência em cache for verdadeira.
- Se a ocorrência em cache for falsa, o Google Cloud Armor vai filtrar a solicitação porque o balanceador de carga de aplicativo de externo tem o Google Cloud Armor ativado. O Google Cloud Armor aplica e avalia todas as regras e políticas configuradas. Se alguma regra for violada, ela rejeitará a solicitação com uma mensagem de erro e um código de status.
- O Google Cloud Armor é integrado ao reCAPTCHA Enterprise, que avalia o tráfego de entrada legítimo com pontuações de risco. Para tráfego não legítimo, o Google Cloud Armor pode negar a solicitação.
- Se não houver violações de regras do Google Cloud Armor, o balanceador de carga de aplicativo externo encaminhará a solicitação para a Apigee.
- A Apigee processa a solicitação, executa as políticas de segurança conforme descrito no gerenciamento de APIs da Apigee e permite ou nega a solicitação. Ela também pode ser usada para rotear a solicitação para back-ends diferentes com base no cliente, na solicitação ou em ambos.
- A Apigee encaminha a solicitação para os back-ends do GKE diretamente por meio de endereços IP internos. A comunicação entre a Apigee e o serviço de transferência de dinheiro pode acontecer pelo endereço RFC 1918 (um endereço IP interno), porque eles estão dentro da rede com peering.
- A Apigee envia a solicitação para os back-ends do data center particular usando o Cloud Interconnect.
- A Apigee envia a solicitação para serviços de terceiros por meio do provisionamento de endereço IP do NAT da Apigee.
- Quando uma resposta retorna ao cliente, o Cloud CDN a armazena em cache para que ela possa retornar a resposta do cache para chamadas futuras.
A seguir
- Saiba mais sobre as opções de provisionamento da Apigee.
- Leia sobre segurança de API de várias camadas com a Apigee e o Google Cloud Armor.
- Saiba como fornecer APIs globais de alto desempenho com a Apigee X e o Cloud CDN.
- Leia e faça perguntas na comunidade Apigee (em inglês).
- Acesse o repositório da Apigee (em inglês) no GitHub.
- Para mais arquiteturas de referência, diagramas e práticas recomendadas, confira a Central de arquitetura do Cloud.