El poder de la red mínima viable

Comprender las redes en el cloud es uno de los mayores ajustes para las organizaciones que inician su camino hacia el cloud. Cuando se observan el esquema de direccionamiento y los componentes, parece una red IP. Y desde la mayoría de las perspectivas lo es, pero en muchos otros aspectos no lo es. Una red definida por software (SDN), como las que se ofrecen en el cloud, no está sujeta a las mismas restricciones que una red física, y eso puede resultar bastante confuso al comenzar.

En lugar de tratar de entender en qué se diferencia la SDN de su red física, centrémonos más en lo que usted necesita que haga la red y, sobre todo, en lo que no debería permitirse. Puede que usted tenga edad suficiente para recordar un concepto llamado “denegación por defecto”, que significaba que, a menos que se permitiera explícitamente una conexión, esta se bloqueaba por defecto. Luego llegó esto de la web y ya no fue posible restringir el puerto 80 o el 443, porque prácticamente todas las aplicaciones usaban esos puertos. Además, la “denegación por defecto” nunca llegó realmente más allá del perímetro y nuestras redes internas tendían a ser planas y abiertas, apoyándose en una DMZ para filtrar el tráfico dañino proveniente del mundo exterior. Como lo ha demostrado una brecha de seguridad tras otra, este modelo solo es moderadamente eficaz.

Pero la SDN nos permite acercarnos mucho más a la denegación por defecto, mediante un concepto que llamamos la “red mínima viable”, que permite construir redes personalizadas únicamente con las piezas necesarias para hacer el trabajo, y nada más.

Una red mínima viable debe determinar la arquitectura de la aplicación y luego crear ÚNICAMENTE las redes necesarias para dar soporte a esa aplicación, aplicando enrutamiento y grupos de seguridad de mínimo privilegio, y utilizando además componentes PaaS como los balanceadores de carga del cloud. Esto convierte efectivamente la red de conmutación de paquetes en una red de conmutación de circuitos, en el sentido de que los componentes de la aplicación SOLO pueden comunicarse con los demás componentes permitidos, y nada puede interceptar el tráfico intermedio (excepto, en algunos casos, el proveedor de cloud). La red descarta todo el resto del tráfico. Esto elimina la necesidad de construcciones como la DMZ tradicional o las zonas de red, ya que toda la red en sí misma es de mínimo privilegio y denegación por defecto.

Hagamos esto un poco más tangible con un ejemplo. Usted puede crear una pila de aplicaciones tradicional de 3 capas con un Application Load Balancer de cara al público, respaldado por un servidor web en una subred privada que SOLO acepta tráfico del balanceador de carga. Los servidores web solo pueden conectarse a servidores de aplicaciones que aceptan conexiones desde ellos. De forma similar, los servidores de aplicaciones solo pueden enviar tráfico a bases de datos que permiten dichas conexiones. Cada capa opera con denegación por defecto y solo permite conexiones entrantes desde los balanceadores de carga y conexiones salientes hacia las bases de datos. En muchos casos, usted puede implementar esto sin ninguna conectividad a Internet (en subredes privadas), salvo por los balanceadores de carga públicos, que son construcciones PaaS altamente seguras mantenidas por el proveedor de cloud.

En lugar de construir la red y colocar las aplicaciones dentro, usted diseña las aplicaciones y luego ajusta la red a las necesidades de la aplicación. Esto reduce drásticamente la superficie de ataque de la pila de aplicaciones y reduce su riesgo en consecuencia.

Utilizamos estos principios cuando construimos el sitio securosis.com, como puede verse en el diagrama de arquitectura a continuación. Si observamos ese diseño con una mirada de seguridad de red, vemos:

• El acceso está restringido desde el WAF en el cloud, de modo que solo el tráfico limpio llega a la VPC.
• Los balanceadores de carga de aplicaciones (ALB) son los únicos recursos en las subredes de cara al público y solo permiten tráfico 80/443.
• Todas las instancias están en subredes privadas y solo aceptan tráfico de los ALB.
• La instancia “admin” acepta inicios de sesión, pero solo desde una VPN alojada en un entorno distinto.
• No se muestran las subredes de la base de datos RDS, que también son exclusivamente privadas y solo aceptan tráfico de las instancias. Si se necesitan inicios de sesión directos o acceso RDBMS para manipular datos, se modifican las reglas de los grupos de seguridad para otorgar acceso temporal.
• Las conexiones a S3 se realizan mediante un endpoint de servicio, lo que elimina la necesidad de un NAT Gateway para el acceso a Internet.
• SSH está deshabilitado en las instancias que no son de administración. Estas se autoescalan, son inmutables y solo se modifican cambiando la imagen base.
• No hay grupos de seguridad autorreferenciados (grupos de seguridad que permiten el acceso interno), para impedir ataques horizontales. Los grupos de seguridad en AWS funcionan a nivel de recurso, no a nivel de subred, lo que resulta muy potente para bloquear ataques Este/Oeste.
• Esta arquitectura reduce drásticamente la superficie de ataque general. La red solo permite la conectividad mínima requerida, y solo contiene las subredes y tablas de rutas mínimas requeridas para permitir el acceso. Esencialmente, hemos ajustado la red a la aplicación. De hecho, la red se diseñó solo después de haber definido la arquitectura de la pila de aplicaciones.
• Este es un ejemplo muy sencillo de un sitio pequeño, pero los principios pueden aplicarse a arquitecturas mucho más grandes, con un mayor número de capas, balanceadores de carga internos, API Gateways y componentes PaaS.

Como puede ver, se dispone de una enorme flexibilidad al utilizar las construcciones de redes en el cloud. Por fin se tiene la capacidad de construir la red que la aplicación necesita, en lugar de adaptar la aplicación a la red existente. Pero con esta flexibilidad llega también la posibilidad de configurar las cosas de forma incorrecta y exponer amplias porciones de su infraestructura a la Internet pública. Por eso siempre recomendamos supervisar su postura de seguridad en el cloud y aplicar las mejores prácticas con una plataforma de operaciones de seguridad en el cloud (como la que ofrece DisruptOps).