Los servicios nativos de la nube se han vuelto cada vez más populares en el espacio de desarrollo de software, ya que ofrecen funciones listas para usar para resolver problemas que, de otro modo, requerirían recursos significativos en el desarrollo de software tradicional. Hay cientos de servicios en la nube disponibles en la actualidad para ayudar a los desarrolladores a reducir sus cargas de trabajo; por ejemplo, los servicios de almacenamiento de objetos facilitan el almacenamiento de archivos y otros datos.
Con la creciente dependencia del software de los servicios en la nube, se acuñó el término «nativo de la nube». Nativo de la nube se refiere al software creado en torno a la computación en la nube y, por lo tanto, se beneficia de las características de la nube, como la escalabilidad y varios servicios de implementación, de forma nativa.
Cloud Native Computing Foundation (CNCF) es el hogar de muchas herramientas y software de código abierto e independientes del proveedor que se pueden usar de forma inmediata en cualquier plataforma de nube pública. Esto significa que con algunos cambios menores en su configuración, puede ejecutar estas herramientas en cualquier nube principal, ya sea AWS , Azure , Google Cloud Platform (GCP) , Digital Ocean u otras.
CNCF esencialmente combina los conceptos de nube nativa y agnóstica de la nube, mediante la promoción de herramientas que se pueden usar entre los proveedores de la nube y que tienen una estrecha integración con las ofertas específicas de la nube. Por lo tanto, los usuarios no dependen de ningún proveedor único y pueden cambiar fácilmente de proveedor de nube sin afectar la compatibilidad de una herramienta.
Por supuesto, junto con los beneficios de la nube vienen algunos riesgos. El principal de ellos es la seguridad.
En este artículo, analizaremos cómo el movimiento nativo de la nube (especialmente representado por CNCF) ha cambiado el panorama de los desarrolladores y cómo esto afecta la necesidad de seguridad web.
Las ventajas del desarrollo impulsado por CNCF sobre el desarrollo de software tradicional
Hay muchos beneficios para la computación en la nube. Muchas tareas de implementación y administración que anteriormente estaban a cargo de los desarrolladores ahora se están convirtiendo en responsabilidad de los proveedores de la nube.
Por ejemplo, puede usar la base de datos como servicio sin tener que administrar los servidores de la base de datos o lidiar con la complejidad que implican las conmutaciones por error, la replicación, etc. Del mismo modo, el uso de caché como servicio significa que no tiene que administrar los servidores de caché usted mismo. Estos servicios son generalmente fáciles de usar; a menudo, todo lo que tiene que hacer es proporcionar a sus aplicaciones las credenciales adecuadas y dejar que los servicios hagan el resto.
De manera similar, cuando se trata de la capa de infraestructura, descargar la implementación a los proveedores de la nube ha facilitado la vida de los desarrolladores al asumir algunas de sus responsabilidades. Esto, a su vez, ha llevado a un desarrollo y una entrega más rápidos.
Los desarrolladores que adoptan (ya sea parcial o totalmente) el ecosistema CNCF de código abierto obtienen aún más beneficios. Muchas herramientas CNCF son soluciones poderosas y maduras que brindan múltiples funciones listas para usar. Los desarrolladores no tienen que hacer ningún esfuerzo para implementar estas capacidades, por lo que pueden concentrarse en otras cosas.
Por ejemplo, una herramienta como Envoy ahorra a los desarrolladores una gran cantidad de tiempo y esfuerzo al eliminar la necesidad de lidiar con las conmutaciones por error, los umbrales, la limitación de velocidad, la terminación de TLS, etc. Envoy implementa todas estas funcionalidades, por lo que su aplicación no tiene a. Mientras tanto, una herramienta como Prometheus le permite raspar fácilmente las métricas de las aplicaciones y trazarlas para una mejor visibilidad.
Existe una tendencia creciente en el uso de herramientas como Kubernetes, mallas de servicio, Fluentd, FluxCD y Prometheus en la capa de infraestructura, abstrayendo las tareas de administración de instancias de aplicaciones de los desarrolladores. Herramientas como containerd proporcionan una forma confiable de crear y ejecutar contenedores en Kubernetes. También permiten a los desarrolladores enviar toda su aplicación como una imagen a la capa de infraestructura.
La contenedorización permite el movimiento nativo de la nube a lo grande. Con solo unos pocos cambios básicos de configuración de la nube, la creación de contenedores le permite ejecutar el mismo software sin tener que realizar cambios en el código en ninguna nube o servicios como EKS, ECS, AKS y GKE; es decir, los desarrolladores ni siquiera tienen que pensar en qué nube se ejecutará su aplicación.
Todas estas tendencias combinadas han respaldado otra: la creciente popularidad de los microservicios. Gracias a la abstracción de la infraestructura, las potentes herramientas de código abierto y otras ventajas inherentes del desarrollo nativo de la nube, los desarrolladores pueden concentrarse solo en su lógica comercial y pueden implementar una variedad de servicios pequeños y bien enfocados.
Seguridad y arquitecturas nativas de la nube
Si bien la computación nativa en la nube ofrece muchos beneficios, también crea algunos desafíos. Esto es especialmente cierto para la seguridad web. Discutiremos dos aspectos de esto: los desafíos de proteger los contenedores y de proteger las arquitecturas de microservicios de los atacantes.
Contenedores de seguridad
En los modelos tradicionales, la seguridad web se basa principalmente en firewalls y en el fortalecimiento del servidor. Sin embargo, con los modelos modernos de contenedorización, el manejo de cambios con firewalls, refuerzo de servidores, políticas de red, ACL, etc., se vuelve cada vez más difícil.
El fortalecimiento del servidor se puede lograr mediante cambios en las imágenes del contenedor y la implementación del clúster en sí. Por ejemplo, al lanzar su clúster de Kubernetes, puede seguir el Benchmark de CIS para Kubernetes. La red, por otro lado, es un componente en constante movimiento, con la introducción de nuevos servicios, la implementación de nuevos módulos y la caída de módulos más antiguos.
Por supuesto, es normal que los pods o las VM dejen de funcionar en la nube o en Kubernetes. Esto significa que es necesario implementar la seguridad de alguna manera para que cualquier cambio en sus reglas de seguridad pueda persistir en el nuevo pod o VM.
Si los cambios en el firewall de la aplicación web se pueden implementar a través de comandos, ¿por qué no se puede hacer esto en contenedores? Los contenedores son entidades que mueren con frecuencia, por lo que ejecutar comandos de seguridad no funcionará. Debe asegurarse de que los cambios que desea realizar estén integrados en las imágenes de los contenedores. O bien, debe encontrar una manera de implementar estos cambios utilizando métodos de implementación nativos de Kubernetes, como contenedores u operadores de inicio.
Para proteger los contenedores, el método moderno para implementar reglas implica ejecutar comandos en su inicio. Pero esto se vuelve complicado para los desarrolladores, ya que el equipo de seguridad debe enviar el contenedor final. Parecería necesario inyectar estas reglas en el contenedor durante el tiempo de ejecución.
Protección de arquitecturas de microservicios
Muchas arquitecturas modernas dependen de microservicios que se comunican entre sí y forman un sistema coherente en conjunto. Sin embargo, una gran cantidad de microservicios que interactúan crea una superficie de ataque amplia y complicada que puede ser difícil de proteger.
Por lo general, muchos de los microservicios están orientados a Internet. Esto crea varios problemas:
- En lugar de tener un perímetro cerrado y defendible, gran parte de la infraestructura «interior» del sistema está expuesta a posibles atacantes.
- Además, la mayor parte de esta exposición consiste en puntos finales de API. Esto puede dificultar la seguridad, ya que la mayoría de las soluciones de seguridad se basan en tecnologías heredadas (p. ej., reCAPTCHA) que no se pueden usar para filtrar llamadas API hostiles.
- La cantidad potencialmente grande de API puede hacer que sea muy difícil crear políticas y conjuntos de reglas de seguridad que permitan todas las diversas permutaciones de uso legítimo, al mismo tiempo que bloquean todas las formas de tráfico malicioso.
- Las prácticas modernas de CI/CD a menudo dan como resultado que las API evolucionen muy rápidamente, lo que nuevamente dificulta la creación y el mantenimiento de políticas de seguridad sólidas.
- La administración en general puede volverse muy complicada cuando se trata de microservicios. Dado que cada uno es una entidad separada, esto puede hacer que sea tedioso mantener una lista blanca correcta de servicio a servicio, por ejemplo.
Por si todo esto fuera poco, las arquitecturas de microservicios no siempre responden a los ataques de la misma forma que las aplicaciones monolíticas. Por ejemplo, los ataques DDoS pueden causar estragos , especialmente cuando sus solicitudes entrantes desencadenan una mayor comunicación dentro del servicio, lo que amplifica los efectos del ataque.
