Patrón de guardián

Proteja las aplicaciones y los servicios mediante un componente dedicado para agente de solicitudes entre clientes y la aplicación o el servicio. El agente valida y sanea las solicitudes y puede proporcionar una capa adicional de seguridad y limitar la superficie expuesta a ataques del sistema.

Contexto y problema

Muchos servicios en la nube exponen puntos de conexión que permiten a las aplicaciones cliente llamar a sus API a través de Internet u otra red que no es de confianza. El código que implementa las API desencadena o realiza varias tareas, entre las que se incluyen, entre otras, la autenticación, la autorización, la validación de parámetros y algunos o todos los procesamientos de solicitudes. Es probable que el código de API acceda al almacenamiento y a otros servicios en nombre del cliente.

Si un usuario malintencionado pone en peligro el sistema y obtiene acceso al entorno de hospedaje de la aplicación, se exponen sus mecanismos de seguridad, así como el acceso a los datos y a otros servicios. Como consecuencia, el usuario malintencionado puede obtener acceso libre a la información confidencial y a otros servicios.

Solución

Una solución a este problema es desacoplar el código que implementa puntos de conexión públicos desde el código que procesa solicitudes y accede al almacenamiento. Desacople el código mediante una capa de fachada que interactúe con los clientes y redirija las solicitudes aprobadas, a través de un punto de conexión interno, una cola o un intermediario de mensajes, a los componentes de la carga de trabajo que ejecutan la operación de negocio. El diagrama proporciona información general de alto nivel de este patrón.

Puede usar el patrón Gatekeeper para proteger el almacenamiento o puede usarlo como una fachada más completa para proteger todas las funciones de la aplicación. Entre los factores importantes se incluyen:

Validación controlada: El gatekeeper valida todas las solicitudes y rechaza las solicitudes que no cumplen los requisitos de validación.
Riesgo y exposición limitados: Los riesgos y la exposición se reducen porque el gatekeeper no tiene acceso a las credenciales ni a las claves que usa el host de confianza para acceder al almacenamiento y los servicios. Si el gatekeeper se pone en peligro, los atacantes no pueden acceder a estas credenciales ni claves.
Seguridad adecuada: El gatekeeper se ejecuta en modo de privilegios limitados, mientras que el resto de la aplicación se ejecuta en el modo de plena confianza necesario para acceder al almacenamiento y los servicios. Si el guardián se ve comprometido, no puede acceder directamente a los servicios ni a los datos de la aplicación.

Este patrón actúa como un firewall en una topografía de red típica. A diferencia de un firewall tradicional, permite al gatekeeper examinar las solicitudes en detalle y tomar una decisión controlada por la aplicación sobre si se pasa la solicitud al host de confianza que realiza las tareas necesarias. Esta decisión normalmente requiere que el guardián valide y sane el contenido de la solicitud antes de pasarlo al host de confianza. Los gatekeepers pueden autorizar la solicitud, buscar contenido de carga inesperado o no válido, limitar la velocidad y realizar otras comprobaciones.

Problemas y consideraciones

Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:

Asegúrese de que los hosts de confianza solo exponen puntos de conexión internos o protegidos que solo usa el guardián. Los hosts de confianza no deben exponer los puntos de conexión externos ni las interfaces.
El controlador de acceso debe ejecutarse en un modo de privilegios limitados. En la práctica, aloje el componente de control de acceso y el back-end de confianza en entornos de ejecución independientes, y mantenga como privados los puntos de conexión del back-end.
El gatekeeper no debe realizar el procesamiento relacionado con la aplicación o los servicios ni acceder a los datos. Su función es únicamente para validar y sanear las solicitudes. Es posible que los hosts de confianza necesiten realizar una validación adicional de solicitudes, pero el guardián debe realizar la validación principal.
Utilice un canal de comunicación seguro, como HTTPS, Secure Sockets Layer (SSL) o Transport Layer Security (TLS), entre el controlador de acceso y los hosts o las tareas de confianza cuando sea posible. Sin embargo, algunos entornos de hospedaje no admiten HTTPS en los puntos de conexión internos.
Agregar la capa adicional para implementar el patrón Gatekeeper es probable que afecte al rendimiento debido al procesamiento adicional y la comunicación de red necesaria.
El gatekeeper puede ser un único punto de error (SPoF). Para minimizar el impacto de un error, considere la posibilidad de implementar instancias redundantes y usar un mecanismo de escalado automático para garantizar la capacidad y mantener la disponibilidad.

Cuándo usar este patrón

Use este patrón en los siguientes supuestos:

Controla la información confidencial.
Expone servicios que requieren una protección segura contra el tráfico malintencionado.
Usted lleva a cabo operaciones esenciales para la misión que no admiten la exposición directa a los servicios de backend.
Necesita solicitar validación y saneamiento para separarse del procesamiento empresarial principal.

Este patrón podría no ser adecuado cuando:

Puede satisfacer los requisitos de seguridad y validación a través de controles de plataforma integrados en el servicio back-end sin agregar un nivel de guardián dedicado.
Se han agregado saltos de red y latencia de validación que infringen los requisitos estrictos de latencia de un extremo a otro.

Diseño de cargas de trabajo

Evalúe cómo usar el patrón Gatekeeper en el diseño de una carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.

Fundamento	Cómo apoya este patrón los objetivos de los pilares
Las decisiones de diseño de seguridad ayudan a garantizar la confidencialidad, integridad y disponibilidad de los datos y sistemas de su carga de trabajo.	Un guardián en el flujo de solicitudes le ayuda a centralizar la funcionalidad de seguridad, como firewalls de aplicaciones web, protección contra DDoS, detección de bots, manipulación de solicitudes, inicio de autenticación y comprobaciones de autorización. - SE:06 Controles de red - SE:10 Detección de amenazas y supervisión
Eficiencia del rendimiento ayuda a su carga de trabajo a satisfacer eficientemente las demandas mediante optimizaciones en el escalado, los datos y el código.	Puede usar este patrón para implementar la limitación en un nivel de guardián en lugar de implementar comprobaciones de velocidad en el nivel de nodo. La coordinación del estado de velocidad entre todos los nodos no es intrínsecamente eficaz. - PE:03 Seleccionar servicios

Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.

Example

El patrón Gatekeeper suele implementar una ruta de acceso de solicitud superpuesta, donde cada capa tiene una responsabilidad específica y un ámbito de confianza limitado.

Descargue un archivo de Visio de esta arquitectura.

En este diseño, Azure Application Gateway con Azure Web Application Firewall es el portero exterior. Inspecciona el tráfico accesible desde Internet y aplica controles de seguridad antes de que el tráfico alcance el nivel de API. Azure API Management es el controlador de acceso interno. Aplica controles específicos de la API y reenvía solo el tráfico aprobado a back-ends privados.

Por ejemplo, Azure Web Application Firewall puede detectar y bloquear patrones de inyección de código SQL y de secuencias de comandos entre sitios, aplicar reglas de protocolo y de tamaño de las solicitudes, y filtrar bots y direcciones IP antes de que las solicitudes lleguen a API Management o a servidores back-end privados.

Cuando se usa API Management en la capa interna, se aplican directivas a las solicitudes entrantes y las respuestas salientes en la canalización de puerta de enlace. Para obtener más información sobre cómo API Management procesa las solicitudes y respuestas, consulte Directivas en API Management. Para consultar opciones de directiva como la validación de JSON Web Token (JWT), la limitación de tasa, la transformación de encabezados y el modelado de respuestas, consulte la referencia de directivas de API Management.

Utilice identidades administradas para recursos de Azure de forma coherente para la autenticación de servicio a servicio en esta ruta de acceso. Por ejemplo, API Management puede usar la directiva autenticar con identidad administrada para obtener tokens de Microsoft Entra para llamadas al back-end sin almacenar secretos.

La parte del servidor sigue siendo privada. Por ejemplo, el back-end puede ser una aplicación Azure App Service que usa un punto de conexión private, por lo que se puede acceder a la aplicación de forma privada.

Para las cargas de trabajo en contenedores, una alternativa puede reemplazar API Management más la ruta interna de App Service por computación basada en ingress:

Azure Kubernetes Service (AKS), lo que proporciona más control sobre la elección del controlador de entrada, las directivas de Kubernetes, la topología de red y las operaciones de clúster.
Azure Container Apps, que es una plataforma administrada de contenedores sin servidor que proporciona capacidades de ingress y reduce la necesidad de administrar la infraestructura.

En estas alternativas, Ingress puede encaminar el tráfico según el host o la ruta, terminar TLS y exponer servicios internos únicamente. Las funcionalidades específicas, como los límites de solicitudes y las reglas de permitir o denegar dependen de la implementación de entrada seleccionada. En todos los casos, mantenga los límites de la puerta de enlace: aplique la validación y la aplicación de políticas en el punto de entrada, y mantenga accesibles los servicios de back-end solo a través de esa puerta de enlace.

Cada capa de esta ruta emite registros y métricas que debería centralizar. Los registros de diagnóstico de Azure Web Application Firewall registran las reglas coincidentes y bloqueadas por solicitud. API Management genera registros de la puerta de enlace que registran la duración de la solicitud, los códigos de respuesta y los resultados de las directivas. Los servicios back-end emiten telemetría de nivel de aplicación. Recopile estos registros y métricas en Azure Monitor y enrutelos a un área de trabajo de Log Analytics para realizar consultas unificadas. Estandarice la correlación de solicitudes de extremo a extremo generando o reenviando un identificador de correlación en el perímetro y propagándolo a través de API Management y los servicios de back-end (por ejemplo, mediante cabeceras de solicitud y el contexto de trazas distribuidas), para que una sola transacción pueda rastrearse en todas las capas. Utilice Microsoft Defender para la nube para mostrar recomendaciones de seguridad en todos los componentes de Gatekeeper. Configure alertas para tasas de bloqueo anómalas de Azure Web Application Firewall o picos de errores de API Management para detectar amenazas antes de que lleguen a los back-ends privados.

Pasos siguientes

Las instrucciones siguientes pueden ser relevantes al implementar este patrón:

Los siguientes patrones de diseño en la nube se usan a menudo junto con el patrón Gatekeeper:

Comentarios

¿Le ha resultado útil esta página?

Last updated on 2026-06-03