Prácticas recomendadas para proteger tus aplicaciones y APIs a través de Apigee

Last reviewed 2024-03-19 UTC

En este documento, se describen las prácticas recomendadas que pueden ayudarte a proteger tus aplicaciones y APIs a través de 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 APIs seguras, escalables y eficaces.

En este documento, se usa una serie de arquitecturas de ejemplo para demostrar las prácticas recomendadas de uso de 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 APIs.

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

Administración de API de Apigee

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

Los usuarios pueden interactuar con las aplicaciones a través de 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
  • APIs
    • 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 OAuth 2.0 o una clave de API 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.

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

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

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

Puedes adjuntar una o más de estas políticas a tu capa de proxy. En la siguiente tabla, se enumera el caso de uso 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 tu organización a aplicar cuotas (la cantidad de llamadas a la API realizadas) para 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 que se envían 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 contra un WSDL y determina si los mensajes JSON y XML se forman de manera correcta.
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 a mitigar el riesgo de ataques a través de 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 de 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 tus <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"> productos de API para acceder a tus APIs.</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, comprueba 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 comprueba el código de autenticación de mensajes basado en hash (HMAC) para la autenticación y las verificaciones de integridad a nivel de la aplicació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 SAML con firma 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 los que no es posible, puedes usar la política AccessControl. Para 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 el almacén de certificados de confianza para los protocolos de enlace TLS.

Puedes usar Apigee para crear productos de API que te permitan agrupar tus operaciones de API y hacer que estén disponibles para el consumo de 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 a través de métodos HTTP y por cuota.

Debes usar productos de API para controlar el acceso a tus APIs. Cuando defines uno o más productos de API en una aplicación 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 pagos o revertirlos.

Arquitectura inicial

En esta sección, se describe un ejemplo de la 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 balanceador de cargas de aplicaciones externo controla y configura la entrada a los servicios.
  • El balanceador de cargas de aplicaciones externo reenvía la solicitud al backend o al servicio de terceros adecuados 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 las prácticas recomendadas coherentes para la seguridad y el registro, ya que diferentes equipos desarrollan y mantienen estos servicios dentro de la organización.

Prácticas recomendadas de arquitectura

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

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 a través del 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 a través de Cloud Interconnect.

El flujo de solicitudes es el siguiente:

  1. El cliente envía la solicitud al balanceador de cargas de aplicaciones externo con las credenciales para la aplicación, por ejemplo, una clave, un token o un certificado.
  2. El balanceador de cargas 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 de forma directa 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 prevenir 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 todas las llamadas que realiza el cliente que llegan al balanceador de cargas de aplicaciones externo. 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 con anterioridad. El flujo de solicitudes es el siguiente:

  1. El cliente envía la solicitud al balanceador de cargas de aplicaciones externo con las credenciales para la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Google Cloud Armor filtra la solicitud porque el balanceador de cargas de aplicaciones externo lo tiene habilitado. 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 balanceador de cargas de aplicaciones externo 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 de forma directa 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.
  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 de uso 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 para 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 del diagrama anterior es el siguiente:

  • (1) Todas las solicitudes HTTP(S) de los clientes y los consumidores de la API se envían al balanceador de cargas de aplicaciones externo.
  • (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, 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 para comprobar la validez de la solicitud a la API.
  • (4) Apigee determina si las claves de API o los tokens de acceso usados 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 del diagrama anterior es el siguiente:

  1. El cliente envía la solicitud al balanceador de cargas de aplicaciones externo con las credenciales para la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Debido a que el balanceador de cargas de aplicaciones externo tiene Google Cloud Armor habilitado, 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 balanceador de cargas de aplicaciones externo 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 de forma directa a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia monetaria 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 de las aplicaciones. Cloud CDN también ofrece capacidades de almacenamiento en caché que te ayudan a proteger el backend a través de 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 ayudar a minimizar el uso de la red, el procesamiento y la carga del servidor web. 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 balanceador de cargas de aplicaciones externo con las credenciales de la aplicación, por ejemplo, una clave, un token o un certificado.
  2. Cloud CDN comprueba 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 balanceador de cargas de aplicaciones externo tiene habilitado Google Cloud Armor. Google Cloud Armor aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, 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 balanceador de cargas de aplicaciones externo 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 de forma directa a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia monetaria 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é para que pueda mostrar la respuesta desde la caché para llamadas futuras.

¿Qué sigue?