Prácticas recomendadas para proteger tus aplicaciones y API mediante Apigee

En este documento, se describen las prácticas recomendadas que pueden ayudarte a proteger tus aplicaciones y API mediante la administración de la API de Apigee y los siguientes productos de Google Cloud:

Este documento está dirigido a arquitectos de API, arquitectos de seguridad y de ingeniería, que administran la infraestructura de una aplicación y desean exponer API seguras, escalables y eficaces.

En este documento, se usa una serie de arquitecturas de ejemplo a fin de demostrar las prácticas recomendadas para usar la administración de API de Apigee. En este documento, también se analizan las prácticas recomendadas para usar la app web y la protección de la API (WAAP), una solución de seguridad integral que puedes usar para proteger tus aplicaciones y API.

En este documento, se da por sentado que estás familiarizado con las Herramientas de redes, las API y Google Cloud.

Administración de API de Apigee

Apigee es una plataforma para desarrollar y administrar la API. Cuando agregas una capa de proxy a tus servicios, Apigee proporciona una abstracción o fachada que te ayuda a proteger las API de tu servicio de backend.

Los usuarios pueden interactuar con las aplicaciones mediante OAuth 2.0 y los rangos de direcciones IP incluidos en la lista de anunciantes permitidos. Como se muestra en la siguiente imagen, los usuarios pueden interactuar con una aplicación, y los datos y servicios se exponen en un flujo bidireccional.

Puntos de seguridad entre la interacción del usuario con una aplicación y el backend.

Los puntos de seguridad son los siguientes:

  • Usuarios:
    • OAuth 2.0
    • Control de acceso a la dirección IP
  • Aplicaciones
    • Claves de API
    • OAuth 2.0
    • TLS
  • Desarrolladores y socios
    • SSO
    • RBAC
  • API
    • OAuth 2.0
    • OpenID Connect
    • Cuotas
    • SpikeArrest
    • Protección contra amenazas
  • Equipo de API
    • RBAC de IAM
    • Lógica federada
    • Enmascarar datos
    • Registros de auditoría
  • Backend
    • Herramientas de redes privadas
    • TLS mutua
    • Control de acceso a la dirección IP

Como se muestra en la imagen anterior, puedes usar diferentes mecanismos de seguridad en una aplicación, como una clave de API o OAuth 2.0 con la seguridad de la capa de transporte (TLS). También puedes agregar límite de frecuencia, políticas de protección contra amenazas y configurar TLS mutua en el backend de la capa de la API.

A fin de ayudarte a administrar el acceso de un equipo de API dentro de la plataforma de Apigee, Apigee tiene control de acceso basado en funciones (RBAC) y acceso federado.

Te recomendamos usar las políticas predeterminadas de Apigee para proteger las API. Las políticas son las siguientes:

  • Administración del tráfico. Te ayuda a configurar el almacenamiento en caché, controlar las cuotas, mitigar los efectos de los aumentos y controlar el tráfico de la API.
  • Protección al nivel de los mensajes. Te permite inspeccionar y validar las cargas útiles de solicitudes para ayudar a proteger tu backend de atacantes maliciosos.
  • Seguridad. Te ayuda a controlar el acceso a las API.

Puedes adjuntar una o más de estas políticas a tu capa de proxy. En la siguiente tabla, se enumera el caso práctico de seguridad de cada política, clasificado por tipo de política.

Tipo de política Nombre de la política Caso de uso de seguridad
Administración del tráfico <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">SpikeArrest policy</atrack-type="bestpractices"> Aplica el límite de frecuencia a la cantidad de solicitudes enviadas al backend.
Administración del tráfico <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">Quota policy</atrack-type="bestpractices"> Ayuda a que tu organización aplique cuotas (la cantidad de llamadas a la API realizadas) a cada consumidor.
Administración del tráfico <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">ResponseCache policy</atrack-type="bestpractices"> Almacena en caché las respuestas, lo que reduce la cantidad de solicitudes al backend.
Protección al nivel de los mensajes <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">OASValidation policy</atrack-type="bestpractices"> Valida los mensajes entrantes o los mensajes de respuesta con una especificación de OpenAPI 3.0 (JSON o YAML).
Protección al nivel de los mensajes <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">SOAPMessageValidation policy</atrack-type="bestpractices"> Valida los mensajes XML con el esquema que elijas. Valida los mensajes SOAP con respecto a un WSDL y determina si los mensajes JSON y XML se forman correctamente.
Protección al nivel de los mensajes <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">JSONThreatProtection policy</atrack-type="bestpractices"> Ayuda a mitigar el riesgo de ataques a nivel de contenido, ya que te permite especificar límites en estructuras JSON, como arrays y strings.
Protección al nivel de los mensajes <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">XMLThreatProtection policy</atrack-type="bestpractices"> Te ayuda a abordar las vulnerabilidades de XML y mitigar el riesgo de ataques mediante la evaluación del contenido de los mensajes y la detección de mensajes dañados o con formato incorrecto para que se puedan analizar.
Protección al nivel de los mensajes <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">RegularExpressionProtection policy</atrack-type="bestpractices"> Evalúa el contenido según las expresiones regulares predefinidas y lo rechaza si la expresión es verdadera.
Seguridad <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">BasicAuthentication policy</atrack-type="bestpractices"> Base64 codifica y decodifica las credenciales de usuario.
Seguridad <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">VerifyAPIKey policy</atrack-type="bestpractices"> Aplica la verificación y validación de las claves de API en el entorno de ejecución. Solo permite aplicaciones con claves de API aprobadas asociadas con tu <atrack-type="prácticas recomendadas" l10n-projs-original-order="mailto,track-type,track-name,track-metadata-position" l10n-encrypted- href="408dbk6WV0fWZ26OogAdmO6/+F4vggx0AzbnRBncDef5ATRnWKKNFnIyGajdRoduwWqfpzJjBKtDKUJN+Plw7g==" track-metadata-position="body" track-name="internaltrack"} para acceder a las API.</atrack-type="bestpractices">
Seguridad <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">OAuthV2 policy</atrack-type="bestpractices"> Realiza operaciones de tipo de otorgamiento de OAuth 2.0 para generar y validar tokens de acceso.ss
Seguridad <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">JWS and JWT policies</atrack-type="bestpractices"> Genera, verifica y decodifica tokens web JSON (JWT) y firmas web de JSON (JWS).
Seguridad <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">HMAC policy</atrack-type="bestpractices"> Calcula y verifica el código de autenticación de mensajes basado en hash (HMAC) para verificaciones de integridad a nivel de la aplicación y autenticación.
Seguridad <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">SAMLAssertion policy</atrack-type="bestpractices">
  • Valida los mensajes entrantes que contienen una aserción de SAML firmada de forma digital.
  • Genera aserciones de SAML para solicitudes XML salientes.
Seguridad <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">CORS policy</atrack-type="bestpractices"> Te permite configurar <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">cross-origin resource sharing (CORS) headers for APIs that are consumed by web applications.</atrack-type="bestpractices">

Te recomendamos que uses Google Cloud Armor para el control de acceso basado en direcciones IP y geográficas. Sin embargo, en los casos en que no sea posible, puedes usar la política AccessControl. A fin de ayudarte a proteger las conexiones de Apigee a tu backend, Apigee también proporciona administración de almacén de claves, que te permite configurar el almacén de claves y almacén de confianza para los protocolos de enlace TLS.

Puedes usar Apigee a fin de crear productos de API que te permitan agrupar tus operaciones de API y hacer que estén disponibles para los desarrolladores de aplicaciones. Un producto de API agrupa una o más operaciones. Una operación especifica un proxy de API y rutas de recursos a las que se puede acceder en ese proxy. Una operación también puede limitar el acceso mediante métodos HTTP y por cuota.

Debes usar productos de API para controlar el acceso a tus API. Cuando defines uno o más productos de API en una app para desarrolladores, puedes restringir el acceso a los proxies con una clave de API. Por ejemplo, las aplicaciones para dispositivos móviles que usan los clientes solo pueden realizar una operación POST en el extremo /v1/payments, en este caso, https://$DOMAIN/v1/payments. En otro ejemplo, las aplicaciones del centro de llamadas que usa el personal del centro de atención telefónica pueden realizar operaciones como PUT o DELETE en el extremo /payments, como https://$DOMAIN/v1/payments/1234, para revertir o revertir pagos.

Arquitectura inicial

En esta sección, se describe un ejemplo de arquitectura de microservicios con los servicios implementados en el centro de datos y el proveedor de servicios en la nube. En las siguientes prácticas recomendadas de arquitectura, se muestra cómo puedes iterar y mejorar la arquitectura inicial.

Arquitectura de microservicios de ejemplo con los servicios implementados en el centro de datos y el proveedor de servicios en la nube.

La arquitectura inicial es la siguiente:

  • Los servicios de pagos y cuentas se alojan en el centro de datos, y el servicio de transferencia de dinero se aloja en Google Cloud.
  • El balanceo de cargas de HTTP(S) controla y configura la entrada a los servicios.
  • El balanceo de cargas de HTTP(S) reenvía la solicitud al servicio de backend o de terceros adecuado y controla el protocolo de enlace TLS.

En su estado inicial, la arquitectura de ejemplo tiene las siguientes restricciones:

  • Es poco probable que se escale.
  • Es poco probable que protejas un sistema de ataques maliciosos.
  • No refleja prácticas recomendadas coherentes para la seguridad y el registro, ya que diferentes equipos de la organización desarrollan y mantienen estos servicios.

Prácticas recomendadas de arquitectura

Apigee puede agregar valor y facilitar la exposición de los servicios a los consumidores mediante la implementación de un conjunto estándar de políticas de seguridad en todas las API. En esta sección, se analizan las prácticas recomendadas para usar Apigee a fin de ayudar a proteger las API.

Usa Apigee como una capa de proxy

En el siguiente diagrama, se muestra la arquitectura inicial con la incorporación de Apigee como capa de proxy (fachada):

Apigee como una capa de proxy.

Apigee se aprovisiona en un proyecto de Google Cloud y el entorno de ejecución se aprovisiona y realiza un intercambio de tráfico en un proyecto de usuario mediante el intercambio de tráfico entre redes de VPC. Para ayudar a proteger tu sistema, en lugar de enviar datos a través de Internet, puedes usar Apigee como una capa de proxy para establecer una conexión directa (privada) a tu centro de datos con Cloud Interconnect.

El flujo de solicitudes es el siguiente:

  1. El cliente envía la solicitud al balanceo de cargas de HTTP(S) con las credenciales de la aplicación, por ejemplo, una clave, un token o un certificado.
  2. El balanceo de cargas HTTP(S) enruta la solicitud a Apigee.
  3. Apigee procesa la solicitud, ejecuta las políticas de seguridad como se describe en Administración de API de Apigee y permite o rechaza la solicitud. Apigee también se puede usar para enrutar la solicitud a diferentes backends según el cliente, la solicitud o ambos.
  4. Apigee reenvía la solicitud a los backends de GKE directamente a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia de dinero se puede realizar a través de una dirección RFC 1918 (dirección IP interna) porque se encuentran en la red de intercambio de tráfico.
  5. Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
  6. Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de direcciones IP de Apigee NAT.

Usa Google Cloud Armor como una capa de WAF con Apigee

Puedes agregar Google Cloud Armor a la arquitectura para aumentar el perímetro de seguridad. Google Cloud Armor es parte de la infraestructura de balanceo de cargas global para Google Cloud. Proporciona capacidades de firewall de aplicación web (WAF) y ayuda a evitar ataques de denegación de servicio distribuido (DSD). También puede ayudarte a mitigar la amenaza a las aplicaciones desde los riesgos que se enumeran en las 10 amenazas principales de OWASP.

Puedes configurar reglas y políticas en Google Cloud Armor para evaluar cada llamada realizada por el cliente que llega al balanceo de cargas de HTTP(S). También puedes automatizar la configuración de las políticas de Google Cloud Armor. Para obtener más información sobre cómo configurar reglas en Google Cloud Armor, consulta las guías prácticas de Google Cloud Armor.

En el siguiente diagrama, se muestra la arquitectura de ejemplo con Apigee y Google Cloud Armor implementado:

Arquitectura con Google Cloud Armor

El flujo de eventos en esta arquitectura es similar a los que se analizaron en Usa Apigee como una capa de proxy en este documento. El flujo de solicitudes es el siguiente:

  1. El cliente envía la solicitud al balanceo de cargas de HTTP(S) con las credenciales de la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Google Cloud Armor filtra la solicitud porque el balanceo de cargas de HTTP(S) la tiene habilitada. Aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, Google Cloud Armor rechaza la solicitud y te muestra un mensaje de error y un código de estado.
  3. Si no hay incumplimientos de reglas de Google Cloud Armor, el balanceo de cargas de HTTP(S) enruta la solicitud a Apigee.
  4. Apigee procesa la solicitud, ejecuta las políticas de seguridad y permite o rechaza la solicitud. También se puede usar para enrutar la solicitud a diferentes backends según el cliente, la solicitud o ambos.
  5. Apigee reenvía la solicitud a los backends de GKE directamente a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia de dinero se puede realizar a través de una dirección RFC 1918 (dirección IP interna) porque se encuentran dentro de la red de intercambio de tráfico.
  6. Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
  7. Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de direcciones IP de Apigee NAT.

Usa WAAP

Para mejorar aún más tu perfil de seguridad, también puedes usar WAAP, que une Google Cloud Armor, reCAPTCHA Enterprise y Apigee para ayudar a proteger tu sistema contra ataques de DSD y bots. También proporciona protección de WAF y API.

Recomendamos WAAP para casos prácticos empresariales en los que las llamadas a la API se realizan desde un sitio web y aplicaciones para dispositivos móviles. Puedes configurar aplicaciones para cargar las bibliotecas de reCAPTCHA Enterprise a fin de generar un token de reCAPTCHA Enterprise y enviarlas cuando realicen una solicitud.

En el siguiente diagrama, se muestra el flujo de trabajo:

Flujo de solicitud para WAAP.

El flujo de solicitudes en el diagrama anterior es el siguiente:

  • (1) Todas las solicitudes HTTP(S) de los clientes y consumidores de API se envían al balanceo de cargas de HTTP(S).
  • (2) El primer punto de contacto en la solución de WAAP es Google Cloud Armor.
  • (2a) Si las políticas de Google Cloud Armor no activan ninguna de estas reglas, se envía una solicitud a la API de reCAPTCHA Enterprise para evaluar si el tráfico entrante es una solicitud legítima o no.
  • (3a) Si es una solicitud legítima, la solicitud se reenvía al backend.
  • (2b) Si la solicitud no es legítima, Google Cloud Armor puede rechazar la solicitud y enviar un código de respuesta 403 al usuario.
  • (3b) Para cualquier solicitud a la API, después de evaluar la protección DSD y las reglas de OWASP de Google Cloud Armor, la solicitud se reenvía a Apigee a fin de verificar la validez de la solicitud a la API.
  • (4) Apigee determina si las claves de API o los tokens de acceso que se usaron en la solicitud son válidos. Si Apigee determina que la solicitud no es legítima, Apigee puede enviar un código de respuesta 403. (5) Si la solicitud es legítima, Apigee reenvía la solicitud al backend.

En el siguiente diagrama, se muestra la arquitectura de WAAP con Google Cloud Armor, reCAPTCHA Enterprise y Apigee para las solicitudes a la API.

Flujo de solicitud para WAAP con Google Cloud Armor, reCAPTCHA Enterprise y Apigee.

El flujo de solicitudes en el diagrama anterior es el siguiente:

  1. El cliente envía la solicitud al balanceo de cargas de HTTP(S) con las credenciales de la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Debido a que el balanceo de cargas de HTTP(S) tiene habilitado Google Cloud Armor, Google Cloud Armor selecciona la solicitud. Aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, Google Cloud Armor rechaza la solicitud con un mensaje de error y un código de estado.
  3. Para las llamadas a sitios web, como el envío de un formulario de una página de acceso, Google Cloud Armor se integra en reCAPTCHA Enterprise. reCAPTCHA Enterprise evalúa el tráfico entrante y agrega puntuaciones de riesgo al tráfico legítimo. Para el tráfico que no es legítimo, Google Cloud Armor puede rechazar la solicitud.
  4. Si no hay incumplimientos de reglas de Google Cloud Armor, el balanceo de cargas de HTTP(S) enruta la solicitud a la API a Apigee.
  5. Apigee procesa la solicitud, ejecuta las políticas de seguridad y permite o rechaza la solicitud. Apigee también se puede usar para enrutar la solicitud a diferentes backends según el cliente, la solicitud o ambos.
  6. Apigee reenvía la solicitud a los backends de GKE directamente a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia de dinero se puede realizar a través de la dirección RFC 1918, que es una dirección IP interna, porque ambas están dentro de la red de intercambio de tráfico.
  7. Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
  8. Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de direcciones IP de Apigee NAT.

Usa Cloud CDN para el almacenamiento en caché

Cloud CDN usa la red global de Google para entregar contenido más cerca de los usuarios, lo que acelera los tiempos de respuesta de los sitios web y las aplicaciones. Cloud CDN también ofrece capacidades de almacenamiento en caché que te ayudan a proteger el backend mediante la respuesta de su caché. Si almacenas en caché los datos de acceso frecuente en Google Front End (GFE), que se encuentra en el perímetro de la red de Google, mantiene los datos lo más cerca posible de los usuarios y permite el acceso más rápido posible.

Cloud CDN también ayuda a las organizaciones a manejar sin problemas los aumentos estacionales en el tráfico, por ejemplo, los aumentos que pueden ocurrir durante las temporadas de festividades o de regreso a la escuela. Este enfoque para el almacenamiento en caché ayuda a mejorar la confiabilidad y la experiencia del usuario en un ecosistema. También puede ser útil para minimizar la carga del servidor web, el procesamiento y el uso de la red. Para implementar esta arquitectura, debes habilitar Cloud CDN en el balanceador de cargas que entrega tráfico para Apigee.

Cloud CDN se puede usar con cualquiera de las opciones que se analizan en este documento. En el diagrama siguiente, se muestra la arquitectura de ejemplo inicial de WAAP con la adición de Cloud CDN.

Flujo de solicitud con Cloud CDN

El flujo de solicitudes que se muestra en el diagrama anterior es el siguiente:

  1. El cliente usa bibliotecas reCAPTCHA Enterprise para obtener un token y envía la solicitud al balanceo de cargas HTTP(S) con las credenciales de la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Cloud CDN verifica la caché con la clave de caché y muestra la respuesta si el acierto de caché es verdadero.
  3. Si el acierto de caché es falso, Google Cloud Armor filtra la solicitud porque el balanceo de cargas de HTTP(S) tiene Google Cloud Armor habilitado. Google Cloud Armor aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, se rechaza la solicitud con un mensaje de error y un código de estado.
  4. Google Cloud Armor está integrado en reCAPTCHA Enterprise, que evalúa el tráfico entrante legítimo con puntuaciones de riesgo. Para el tráfico que no es legítimo, Google Cloud Armor puede rechazar la solicitud.
  5. Si no hay incumplimientos de reglas de Google Cloud Armor, el balanceo de cargas de HTTP(S) enruta la solicitud a Apigee.
  6. Apigee procesa la solicitud, ejecuta las políticas de seguridad como se describe en Administración de API de Apigee y permite o rechaza la solicitud. También se puede usar para enrutar la solicitud a diferentes backends según el cliente, la solicitud o ambos.
  7. Apigee reenvía la solicitud a los backends de GKE directamente a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia de dinero se puede realizar a través de la dirección RFC 1918, que es una dirección IP interna, porque se encuentran dentro de la red de intercambio de tráfico.
  8. Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
  9. Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de direcciones IP de Apigee NAT.
  10. Cuando una respuesta vuelve al cliente, Cloud CDN la almacena en caché a fin de que pueda mostrar la respuesta desde la caché para llamadas futuras.

¿Qué sigue?