Proteja sus aplicaciones y servicios mediante una instancia de host dedicada para solicitudes de agente entre los clientes y el servicio de la aplicación. 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
Los servicios en la nube exponen puntos de conexión que permiten a las aplicaciones cliente llamar a sus API. El código usado para implementar 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 el procesamiento de algunas o todas las solicitudes. Es probable que el código de la 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 los puntos de conexión públicos del código que procesa las solicitudes y accede al almacenamiento. Puede conseguirlo mediante una fachada o una tarea dedicada que interactúa con los clientes y, a continuación, entrega la solicitud, quizá mediante una interfaz desacoplada, a los hosts o a las tareas que controlarán la solicitud. La ilustración proporciona información general de alto nivel de este patrón.
El patrón del equipo selector se puede usar simplemente para proteger el almacenamiento, o bien, como una fachada más completa para proteger todas las funciones de la aplicación. Los factores importantes son:
- Validación controlada. El equipo selector valida todas las solicitudes y rechaza aquellas que no cumplan los requisitos de validación.
- Riesgo y exposición limitados. El equipo selector no tiene acceso a las credenciales o las claves que usa el host de confianza para acceder al almacenamiento y a los servicios. Si el equipo selector corre peligro, el atacante no obtiene acceso a estas credenciales o claves.
- Seguridad adecuada. El equipo selector se ejecuta en un modo con privilegios limitados, mientras que el resto de la aplicación se ejecuta en el modo de plena confianza necesario para acceder al almacenamiento y a los servicios. Si el equipo selector está en peligro, no puede acceder directamente a los servicios de la aplicación ni a los datos.
Este patrón actúa como un firewall en una topografía de red típica. Permite que el equipo selector examine las solicitudes y tome una decisión sobre si se debe pasar la solicitud al host de confianza que realiza las tareas necesarias. Esta decisión normalmente requiere que el equipo selector valide y corrija el contenido de la solicitud antes de pasarlo al host de confianza.
Problemas y consideraciones
Tenga en cuenta los puntos siguientes al decidir cómo implementar este patrón:
- Asegúrese de que los hosts de confianza expongan solo los puntos de conexión internos o protegidos que solo use el equipo selector. Los hosts de confianza no deben exponer los puntos de conexión externos ni las interfaces.
- El equipo selector debe ejecutarse en un modo con privilegios limitados, lo que normalmente requiere ejecutar el equipo selector y el host de confianza en servicios hospedados independientes o máquinas virtuales.
- El equipo selector no debe realizar ningún tipo de procesamiento relacionado con la aplicación o los servicios, ni acceder a los datos. Su función es exclusivamente validar y corregir solicitudes. Es posible que los hosts de confianza tengan que realizar una validación adicional de las solicitudes, pero que la validación principal debe hacerla el equipo selector.
- Cuando sea posible, utilice un canal de comunicación seguro (HTTPS, SSL o TLS) entre el equipo selector y los hosts de confianza o las tareas. Sin embargo, algunos entornos de hospedaje no admiten HTTPS en los puntos de conexión internos.
- Es probable que la incorporación de una capa adicional a la aplicación para implementar el patrón del equipo selector afecte al rendimiento debido al procesamiento adicional y a la comunicación de red que requiere.
- La instancia del equipo selector podría ser un único punto de error. 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 para mantener la disponibilidad.
Cuándo usar este patrón
Este patrón es útil para las aplicaciones que:
- manejan información confidencial
- expongan servicios que requieren un alto grado de protección frente a ataques malintencionados
- realizan operaciones críticas que no se pueden interrumpir
- realizan la validación de las solicitudes de forma independiente con respecto a las tareas principales o centralizan esta validación para simplificar la administración y el mantenimiento
Diseño de cargas de trabajo
El arquitecto debe evaluar cómo se puede usar el patrón Gatekeeper en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:
| 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. | Añadir una puerta de enlace al flujo de solicitudes le permite centralizar funciones de seguridad, como firewalls de aplicaciones web, DDoS Protection, 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 |
| La eficiencia del rendimiento ayuda a que la carga de trabajo satisfaga eficazmente las demandas mediante optimizaciones en el escalado, los datos y el código. | Este patrón es la forma en que se puede implementar la limitación en el nivel de puerta de enlace en lugar de implementar comprobaciones de velocidad en el nivel de nodo. Coordinar el estado de la velocidad entre todos los nodos no es intrínsecamente eficaz. - PE:03 Selección de servicios |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.
Ejemplo
En un escenario hospedado en la nube, este patrón se puede implementar desacoplando el rol del equipo selector o la máquina virtual de los roles y servicios de confianza en una aplicación. Para la implementación puede utilizar un punto de conexión interno, una cola o un almacenamiento como mecanismo de comunicación intermedio. En la ilustración se muestra cómo utilizar un punto de conexión interno.
Recursos relacionados
El patrón Valet Key también puede ser apropiado al implementar el patrón Gatekeeper. Cuando se establece comunicación entre Gatekeeper y los roles de confianza, se recomienda mejorar la seguridad mediante el uso de claves o tokens que limiten los permisos para acceder a los recursos. El patrón describe cómo usar un token o una clave que proporcione a los clientes acceso directo restringido a un recurso o servicio específicos.