Getty Images
Estrategias operativas para el aislamiento en la computación de nube
Aunque es inevitable que ciertas aplicaciones alojadas en la nube compartan recursos, las vulnerabilidades que estas conexiones exponen hacen que las estrategias de aislamiento sean absolutamente necesarias.
Los recursos compartidos y la virtualización crean canales directos entre las aplicaciones basadas en la nube. Por desgracia, las ventajas que aporta esta práctica se ven superadas por el riesgo de interferir accidentalmente en las operaciones de otra aplicación o de abrirla a ataques deliberados.
Es posible aislar estas aplicaciones utilizando servidores de nube dedicados en lugar de máquinas virtuales o contenedores basados en la nube. Sin embargo, teniendo en cuenta que la escalabilidad depende de la puesta en común de los recursos, el enfoque de la nube dedicada probablemente no será suficiente para el rendimiento.
Una forma de asegurar estas aplicaciones es implementar estrategias específicas de aislamiento, especialmente entre los hosts y la red. Mientras que las prácticas internas de gobierno y seguridad definirán exactamente lo que debe mantenerse separado y cuán separado debe estar, estas estrategias de aislamiento ayudarán a garantizar que se sigan esas directrices.
Examinemos algunas de las mejores prácticas relacionadas con el establecimiento de una estrategia sólida de aislamiento en escenarios de computación en nube. El primer paso será seleccionar un enfoque de alojamiento en la nube que proporcione el aislamiento necesario para determinados tipos de aplicaciones y componentes. A partir de ahí, los equipos tendrán que añadir protecciones que giren en torno a la conectividad de la red, el acceso a la API y el uso compartido de la base de datos.
Elija una estrategia de alojamiento en la nube
Empecemos por el alojamiento. Compartir recursos en la nube conlleva el riesgo de que el rendimiento de una aplicación se resienta si otra aplicación que comparte el servidor acapara recursos. Esta situación concreta suele ser difícil de detectar, ya que un equipo puede suponer que el problema se debe a un cuello de botella en la carga de trabajo o a alguna otra causa común.
Puede limitar estos problemas seleccionando el modelo de alojamiento adecuado, que consta de tres grandes categorías:
- Servicios VM o IaaS
- servicios de contenedores
- computación funcional y sin servidor.
A falta de servidores dedicados, IaaS ofrece el mayor aislamiento inherente. Para aplicaciones con necesidades críticas de seguridad y rendimiento, debe seleccionar la opción IaaS. Las capacidades de aislamiento de los contenedores están mejorando constantemente y son más que suficientes para las aplicaciones empresariales típicas. Los riesgos de la informática funcional y sin servidor son más difíciles de evaluar debido a la aparición de opciones de implementación.
En el caso de los servicios de contenedores, los problemas de aislamiento suelen derivarse de una mala gestión del entorno de contenedores en la nube. Para las organizaciones con personal o habilidades de gestión de contenedores limitadas, los servicios de contenedores gestionados por terceros son una opción popular, y muy segura. Incluso las organizaciones con buenos conocimientos del personal deberían considerar el uso de una única plataforma de contenedores integrada en lugar de confiar en colecciones de herramientas personalizadas que no coinciden. Sin embargo, hay que tener en cuenta que el rendimiento de los contenedores suele ser más sensible al uso de recursos que la opción típica de VM.
Aísle las aplicaciones a nivel de red
Una configuración de red inadecuada suele dejar las aplicaciones vulnerables y abiertas a los ataques de software. Para evitarlo, es fundamental aislar las aplicaciones a nivel de red y utilizar un único espacio de direcciones por grupo de aplicaciones.
Para mayor seguridad, los servicios de nube pública suelen operar dentro de un espacio de direcciones IP privado que los protege del acceso exterior. Sin embargo, incluso en este caso, sigue siendo una buena idea desplegar aplicaciones relacionadas como un grupo y mantenerlas dentro de un espacio de direcciones común.
No exagere ante preocupaciones sobre el aislamiento
Los servicios de nube pública suelen estar protegidos contra las vulnerabilidades que provienen directamente de la nube o de los inquilinos que interactúan con ella. Sin embargo, lo que no pueden ofrecer es protección contra los problemas de sus propios procesos de gestión de aplicaciones y configuración de la red.
Concéntrese principalmente en hacer que las aplicaciones sean seguras tanto a nivel de la red como de los componentes. Una vez que esto esté implementado, lo más probable es que el proveedor de la nube que elija no aumente significativamente su exposición o riesgo.
Revise la exposición de las API
Las API públicas son una necesidad si pretende que los sistemas externos accedan a una aplicación interna. Sin embargo, asegúrese de no exponer accidentalmente API que no están destinadas a un uso externo. Si es posible, es preferible exponer las API a través de una VPN dedicada de la empresa en lugar de la web general. Para un control aún más detallado de su red, considere la posibilidad de implementar una red virtual o SD-WAN. Éstas están disponibles tanto en proveedores de redes, como Juniper y Cisco, como en empresas de software en la nube como VMware.
También debería considerar la posibilidad de segmentar una parte del espacio de direcciones de la VPN corporativa como una subred que contenga las direcciones y API compartidas en una red basada en la nube. A continuación, designe una colección específica de API protegidas que formarán una especie de «frontera» que proteja el resto de la VPN.
Proteja el acceso a las bases de datos compartidas
Una base de datos es un ejemplo perfecto de un recurso de aplicación que necesita protección con aislamiento en la computación en nube. Un sistema de gestión de bases de datos (DBMS) típico soportará el uso concurrente, pero puede limitar la velocidad a la que varias aplicaciones pueden acceder a la base de datos.
Esto es más probable si los componentes de software que acceden a un DBMS escalan dinámicamente en respuesta a las cargas de trabajo. En general, los únicos componentes que deberían escalar dinámicamente son los que no comparten una base de datos.
