En este documento se describen las prácticas recomendadas que pueden ayudarte a proteger tus aplicaciones y APIs con la gestión de APIs de Apigee y los siguientes productos: Google Cloud
Este documento está dirigido a arquitectos de APIs, arquitectos de seguridad y jefes de ingeniería que gestionan la infraestructura de una aplicación y quieren exponer APIs seguras, escalables y con buen rendimiento.
En este documento se usan una serie de arquitecturas de ejemplo para mostrar las prácticas recomendadas para usar la gestión de APIs de Apigee. En este documento también se describen las prácticas recomendadas para usar la protección de aplicaciones web y APIs (WAAP), una solución de seguridad integral que puedes usar para proteger tus aplicaciones y APIs.
En este documento se da por supuesto que tienes conocimientos sobre redes, APIs yGoogle Cloud.
Gestión de APIs con Apigee
Apigee es una plataforma para desarrollar y gestionar APIs. Al añadir una capa de proxy a tus servicios, Apigee proporciona una abstracción o una fachada que te ayuda a proteger las APIs de tus servicios de backend.
Los usuarios pueden interactuar con las aplicaciones mediante OAuth 2.0 y rangos de direcciones IP incluidas en listas de permitidas. Como se muestra en la siguiente imagen, los usuarios pueden interactuar con una aplicación, y los datos y los servicios se exponen en un flujo bidireccional.
Los puntos de seguridad son los siguientes:
- Usuarios:
- OAuth 2.0
- Control de acceso por dirección IP
- Aplicaciones
- Claves de API
- OAuth 2.0
- TLS
- Desarrolladores y partners
- SSO
- RBAC
- APIs
- OAuth 2.0
- OpenID Connect
- Cuotas
- Spike arrest
- Protección frente a amenazas
- Equipo de APIs
- RBAC de gestión de identidades y accesos
- Lógica federada
- Enmascaramiento de datos
- Registros de auditoría
- Backend
- Redes privadas
- TLS mutuo
- Control de acceso por 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 Seguridad en la capa de transporte (TLS). También puedes añadir límites de frecuencia y políticas de protección contra amenazas, así como configurar TLS mutuo en el backend de tu capa de API.
Para ayudarte a gestionar el acceso de un equipo de APIs en la plataforma Apigee, Apigee tiene control de acceso basado en roles (RBAC) e inicio de sesión federado.
Te recomendamos que uses las políticas predeterminadas de Apigee para proteger tus APIs. Las políticas son las siguientes:
- Gestión del tráfico Te ayuda a configurar el almacenamiento en caché, controlar las cuotas, mitigar los efectos de los picos y controlar el tráfico de las APIs.
- Protección a nivel de mensaje. Te permite inspeccionar y validar las cargas útiles de las solicitudes para proteger tu backend de atacantes maliciosos.
- Seguridad. Te ayuda a controlar el acceso a tus APIs.
Puede adjuntar una o varias de estas políticas a su capa de proxy. En la siguiente tabla se muestra el caso práctico de seguridad de cada política, categorizado por tipo de política.
| Tipo de política | Nombre de la política | Caso práctico de seguridad |
|---|---|---|
| Gestión del tráfico | Política SpikeArrest | Aplica un límite de frecuencia al número de solicitudes enviadas al backend. |
| Gestión del tráfico | Política de cuotas | Ayuda a tu organización a aplicar cuotas (el número de llamadas a la API realizadas) a cada consumidor. |
| Gestión del tráfico | Política de ResponseCache | Almacena en caché las respuestas, lo que reduce el número de solicitudes al backend. |
| Protección a nivel de mensaje | Política OASValidation | Valida las solicitudes o los mensajes de respuesta entrantes con una especificación de OpenAPI 3.0 (JSON o YAML). |
| Protección a nivel de mensaje | Política SOAPMessageValidation | Valida mensajes XML con el esquema que elijas. Valida mensajes SOAP con un archivo WSDL y determina si los mensajes JSON y XML tienen el formato correcto. |
| Protección a nivel de mensaje | Política JSONThreatProtection | Ayuda a mitigar el riesgo de ataques a nivel de contenido, ya que te permite especificar límites en estructuras JSON, como arrays y cadenas. |
| Protección a nivel de mensaje | Política XMLThreatProtection | Te ayuda a abordar las vulnerabilidades de XML y a mitigar el riesgo de ataques evaluando el contenido de los mensajes y detectando mensajes dañados o con formato incorrecto antes de que se puedan analizar. |
| Protección a nivel de mensaje | Política RegularExpressionProtection | Evalúa el contenido con expresiones regulares predefinidas y lo rechaza si la expresión es verdadera. |
| Seguridad | Política BasicAuthentication | Codifica y decodifica las credenciales de usuario en Base64. |
| Seguridad | Política VerifyAPIKey | Aplica la verificación y la validación de las claves de API en el tiempo de ejecución. Solo permite que las aplicaciones con claves de API aprobadas asociadas a tus productos de API accedan a tus APIs. |
| Seguridad | Política de OAuthV2 | Realiza operaciones de tipo de concesión de OAuth 2.0 para generar y validar tokens de acceso. |
| Seguridad | Políticas de JWS y JWT | Genera, verifica y decodifica JSON Web Tokens (JWT) y JSON Web Signatures (JWS). |
| Seguridad | Política de HMAC | Calcula y verifica el código de autenticación de mensajes basado en hash (HMAC) para la autenticación y las comprobaciones de integridad a nivel de aplicación. |
| Seguridad | Política de SAMLAssertion |
|
| Seguridad | Política de CORS | Te permite definir encabezados de uso compartido de recursos entre dominios (CORS) para las APIs que usan las aplicaciones web. |
Te recomendamos que uses Cloud Armor para controlar el acceso en función de la dirección IP y la ubicación geográfica. Sin embargo, en los casos en los que no sea posible, puedes usar la política AccessControl. Para ayudarte a proteger las conexiones de Apigee a tu backend, Apigee también proporciona la gestión de almacenes de claves, que te permite configurar el almacén de claves y el almacén de confianza para los handshakes de TLS.
Puedes usar Apigee para crear productos de API que te permitan agrupar tus operaciones de API y ponerlas a disposición de los desarrolladores de aplicaciones para que las consuman. Un producto de API agrupa una o varias operaciones. Una operación especifica un proxy de API y las rutas de recursos a las que se puede acceder en ese proxy. Una operación también puede limitar el acceso por métodos HTTP y por cuota.
Los productos de API se usan para controlar el acceso a tus APIs. Si defines uno o varios productos de API en una aplicación de desarrollador, puedes restringir el acceso a los proxies con una clave de API. Por ejemplo, las aplicaciones móviles que usan los clientes solo pueden realizar una operación POST en el endpoint /v1/payments, en este caso, https://$DOMAIN/v1/payments. En otro ejemplo, las aplicaciones de centros de llamadas que usan los empleados de centros de llamadas pueden realizar operaciones como PUT o DELETE en el endpoint /payments, como https://$DOMAIN/v1/payments/1234, para revertir o cancelar 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 la nube. Las siguientes prácticas recomendadas de arquitectura muestran cómo puedes iterar y mejorar la arquitectura inicial.
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 carga de aplicaciones externo controla y configura el tráfico entrante a los servicios.
- El balanceador de carga de aplicaciones externo reenvía la solicitud al backend o al servicio de terceros adecuado y gestiona la negociación de TLS.
En su estado inicial, la arquitectura de ejemplo tiene las siguientes restricciones:
- Es poco probable que se escale.
- Es poco probable que proteja un sistema frente a ataques maliciosos
- No refleja las prácticas recomendadas coherentes en cuanto a seguridad y registro, ya que estos servicios los desarrollan y mantienen diferentes equipos de la organización.
Prácticas recomendadas de arquitectura
Apigee puede aportar valor y facilitar la exposición de tus servicios a tus consumidores implementando un conjunto estándar de políticas de seguridad en todas las APIs. En esta sección se describen las prácticas recomendadas para usar Apigee y proteger tus APIs.
Usar Apigee como capa de proxy
En el siguiente diagrama se muestra la arquitectura inicial con la incorporación de Apigee como capa de proxy (fachada):
Apigee se aprovisiona en un Google Cloud proyecto y el tiempo de ejecución se aprovisiona y se empareja en un proyecto de arrendatario mediante el emparejamiento entre redes de VPC. Para proteger tu sistema, en lugar de enviar datos a través de Internet, puedes usar Apigee como capa de proxy para establecer una conexión directa (privada) con tu centro de datos mediante Cloud Interconnect.
El flujo de solicitudes es el siguiente:
- El cliente envía la solicitud al balanceador de carga de aplicación externo con las credenciales de la aplicación (por ejemplo, una clave, un token o un certificado).
- El balanceador de carga enruta la solicitud a Apigee.
- Apigee procesa la solicitud, ejecuta las políticas de seguridad tal como se describe en Gestión de APIs de Apigee y permite o deniega la solicitud. Apigee también se puede usar para enrutar la solicitud a diferentes back-ends en función del cliente, la solicitud o ambos.
- 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 puede producirse a través de una dirección RFC 1918 (dirección IP interna) porque están en la red emparejada.
- Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
- Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de la dirección IP de NAT de Apigee.
Usar Cloud Armor como capa de WAF con Apigee
Puedes añadir Cloud Armor a la arquitectura para aumentar el perímetro de seguridad. Cloud Armor forma parte de la infraestructura de balanceo de carga global de Google Cloud. Proporciona funciones de cortafuegos de aplicaciones web (WAF) y ayuda a evitar ataques de denegación de servicio distribuido (DDoS). También puede ayudarte a reducir la amenaza a las aplicaciones de los riesgos que se indican en el Top 10 de OWASP.
Puede configurar reglas y políticas en Cloud Armor para evaluar cada llamada realizada por el cliente que llegue al balanceador de carga de aplicaciones externo. También puedes automatizar la configuración de las políticas de Cloud Armor. Para obtener más información sobre cómo configurar reglas en Cloud Armor, consulta las guías prácticas de Cloud Armor.
En el siguiente diagrama se muestra la arquitectura de ejemplo con Apigee y Cloud Armor:
El flujo de eventos de esta arquitectura es similar al que se describe en la sección Usar Apigee como capa de proxy de este documento. El flujo de solicitudes es el siguiente:
- El cliente envía la solicitud al balanceador de carga de aplicación externo con las credenciales de la aplicación (por ejemplo, una clave, un token o un certificado).
- Cloud Armor filtra la solicitud porque el balanceador de carga de aplicación externo tiene habilitada esta opción. Aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, Cloud Armor rechaza la solicitud y te muestra un mensaje de error y un código de estado.
- Si no hay infracciones de reglas de Cloud Armor, el balanceador de carga de aplicaciones externo enruta la solicitud a Apigee.
- Apigee procesa la solicitud, ejecuta las políticas de seguridad y permite o deniega la solicitud. También se puede usar para enrutar la solicitud a diferentes back-ends en función del cliente, la solicitud o ambos.
- Apigee reenvía la solicitud directamente a los backends de GKE a través de direcciones IP internas. La comunicación entre Apigee y el servicio de transferencia de dinero puede producirse a través de una dirección RFC 1918 (dirección IP interna) porque están en la red emparejada.
- Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
- Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de la dirección IP de NAT de Apigee.
Usar WAAP
Para mejorar aún más tu perfil de seguridad, también puedes usar WAAP, que combina Cloud Armor, reCAPTCHA y Apigee para proteger tu sistema frente a ataques DDoS y bots. También ofrece protección de WAF y APIs.
Recomendamos la API WAAP para casos prácticos empresariales en los que las llamadas a la API se realizan desde un sitio web y aplicaciones móviles. Puedes configurar las aplicaciones para que carguen las bibliotecas reCAPTCHA, generen un token reCAPTCHA y lo envíen cuando hagan una solicitud.
En el siguiente diagrama se muestra el flujo de trabajo:
El flujo de solicitudes del diagrama anterior es el siguiente:
- 1. Todas las solicitudes HTTP(S) de los clientes y los consumidores de APIs se envían al balanceador de carga de aplicaciones externo.
- (2) El primer punto de contacto de la solución WAAP es Cloud Armor.
- 2a) Si ninguna de estas reglas se activa por las políticas de Cloud Armor, se envía una solicitud a la API reCAPTCHA para evaluar si el tráfico entrante es una solicitud legítima o no.
- 3a) Si se trata de una solicitud legítima, se reenvía al backend.
- 2b) Si la solicitud no es legítima, Cloud Armor puede denegarla y enviar un código de respuesta 403 al usuario.
- 3b) En el caso de las solicitudes a la API, después de evaluar las reglas de OWASP de Cloud Armor y la protección contra DDoS, la solicitud se reenvía a Apigee para comprobar su validez.
- (4) Apigee determina si las claves de API o los tokens de acceso utilizados en la solicitud son válidos. Si Apigee determina que la solicitud no es legítima, puede enviar un código de respuesta 403.
- (5) Si la solicitud es legítima, Apigee la reenvía al backend.
En el siguiente diagrama se muestra la arquitectura de WAAP con Cloud Armor, reCAPTCHA y Apigee para las solicitudes de API.
El flujo de solicitudes del diagrama anterior es el siguiente:
- El cliente envía la solicitud al balanceador de carga de aplicación externo con las credenciales de la aplicación (por ejemplo, una clave, un token o un certificado).
- Como el balanceador de carga de aplicación externo tiene habilitado Cloud Armor, Cloud Armor selecciona la solicitud. Aplica y evalúa todas las reglas y políticas configuradas. Si se infringe alguna regla, Cloud Armor rechaza la solicitud con un mensaje de error y un código de estado.
- En el caso de las llamadas de sitios web, como el envío de un formulario de una página de inicio de sesión, Cloud Armor se integra con reCAPTCHA. reCAPTCHA evalúa el tráfico entrante y añade puntuaciones de riesgo al tráfico legítimo. En el caso del tráfico que no es legítimo, Cloud Armor puede rechazar la solicitud.
- Si no hay infracciones de reglas de Cloud Armor, el balanceador de carga de aplicaciones externo enruta la solicitud de API a Apigee.
- Apigee procesa la solicitud, ejecuta las políticas de seguridad y permite o deniega la solicitud. Apigee también se puede usar para enrutar la solicitud a diferentes back-ends en función del cliente, la solicitud o ambos.
- 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 producir a través de la dirección RFC 1918, que es una dirección IP interna, porque ambos están en la red emparejada.
- Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
- Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de direcciones IP de NAT de Apigee.
Usar Cloud CDN para el almacenamiento en caché
Cloud CDN usa la red mundial de Google para servir contenido más cerca de los usuarios, lo que acelera los tiempos de respuesta de tus sitios web y aplicaciones. Cloud CDN también ofrece funciones de almacenamiento en caché que te ayudan a proteger el backend devolviendo la respuesta de su caché. Al almacenar en caché los datos a los que se suele acceder en un 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 acceder a ellos con la máxima rapidez.
Cloud CDN también ayuda a las organizaciones a gestionar sin problemas los picos de tráfico estacionales, como los que pueden producirse durante las vacaciones o la vuelta al cole. Esta estrategia de almacenamiento en caché ayuda a mejorar la fiabilidad y la experiencia de usuario en un ecosistema. También puede ayudar a minimizar la carga del servidor web, el uso de la red y los recursos de computación. Para implementar esta arquitectura, debe habilitar Cloud CDN en el balanceador de carga que sirve el tráfico de Apigee.
Cloud CDN se puede usar con cualquiera de las opciones que se describen en este documento. En el siguiente diagrama se muestra la arquitectura del ejemplo inicial de WAAP con la adición de Cloud CDN.
El flujo de solicitudes que se muestra en el diagrama anterior es el siguiente:
- El cliente usa bibliotecas de reCAPTCHA para obtener un token y envía la solicitud al balanceador de carga de aplicaciones externo con las credenciales de la aplicación (por ejemplo, una clave, un token o un certificado).
- La CDN de Cloud comprueba la caché con la clave de caché y devuelve la respuesta si la coincidencia de caché es verdadera.
- Si el acierto de caché es falso, Cloud Armor filtra la solicitud porque el balanceador de carga de aplicación externo tiene habilitado Cloud Armor. 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.
- Cloud Armor está integrado con reCAPTCHA, que evalúa el tráfico entrante legítimo con puntuaciones de riesgo. En el caso del tráfico que no sea legítimo, Cloud Armor puede denegar la solicitud.
- Si no hay infracciones de reglas de Cloud Armor, el balanceador de carga de aplicación externo enruta la solicitud a Apigee.
- Apigee procesa la solicitud, ejecuta las políticas de seguridad tal como se describe en Gestión de APIs de Apigee y permite o deniega la solicitud. También se puede usar para enrutar la solicitud a diferentes backends en función del cliente, la solicitud o ambos.
- 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 puede producirse a través de la dirección RFC 1918, que es una dirección IP interna, porque están en la red emparejada.
- Apigee envía la solicitud a los backends del centro de datos privado a través de Cloud Interconnect.
- Apigee envía la solicitud a servicios de terceros a través del aprovisionamiento de la dirección IP de NAT de Apigee.
- Cuando una respuesta vuelve al cliente, Cloud CDN la almacena en caché para poder devolverla desde la caché en llamadas futuras.
Siguientes pasos
- Más información sobre las opciones de aprovisionamiento de Apigee
- Consulta información sobre la seguridad de las APIs de varias capas con Apigee y Cloud Armor.
- Consulta cómo ofrecer APIs globales de alto rendimiento con Apigee X y Cloud CDN.
- Lee y haz preguntas en la comunidad de Apigee.
- Consulta el repositorio de Apigee en GitHub.
- Para ver más arquitecturas de referencia, diagramas y prácticas recomendadas, consulta el centro de arquitectura de Cloud.