Protegiendo las 4 Cs de los Sistemas Nativos de la Nube: Cloud, Cluster, Container, y Código

Por Magno Logan (Threat Researcher) 

 

El cómputo nativo de la nube es un enfoque de desarrollo de software para crear y correr aplicaciones escalables en la nube – ya sea pública, privada, on-premises o en entornos de nube híbrida. El cómputo nativo de la nube potencia software de código abierto y propietario para implementar aplicaciones como los microservicios, que se encuentran empaquetados en containers individuales. Un container, como un container en Docker, se utiliza para empaquetar todo el software y aplicaciones necesarias en procesos aislados y ejecutables. Ya que las organizaciones usualmente corren múltiples containers en múltiples hosts, pueden usar sistemas de orquestación, como Kubernetes, el cual es gestionado y desplegado a través de herramientas CI/CD que potencian metodologías DevOps. Al final del día, son las tecnologías nativas de la nube las que permiten que los negocios saquen el mayor provecho posible de sus recursos en la nube con menos costos, tiempos de respuesta más rápidos y gestión más simple. 

Como con cualquier tecnología que usa varias herramientas y plataformas interconectadas, la seguridad juega un papel crítico en el cómputo en la nube. Si hay una cosa en la que los expertos de seguridad están completamente de acuerdo, es en el hecho de que no existen sistemas complejos de software  modernos que son completamente invulnerables – nada es inmune a ser hackeado. Esto ha llevado a la aplicación de la defensa en profundidad, un concepto adoptado de los militares, en el ámbito de la ciberseguridad. 

La defensa en profundidad hace uso de múltiples capas de control y estabiliza las barreras de seguridad a lo largo de diferentes áreas dentro de una organización para ofrecer protección multicapa en caso de que uno de sus controles falle o se convierta en un exploit. La seguridad nativa de la nube adopta este enfoque y divide las estrategias de seguridad utilizadas en los sistemas nativos de la nube en cuatro capas diferentes, como se puede ver en el diagrama debajo llamado “Las 4 Cs de la Seguridad Nativa de la Nube.” 

[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2020/06/tm_blog_4c_diagram.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]

Figura 1. Las 4 Cs de la Seguridad Nativa de la Nube 

 

Es muy importante aplicar controles de seguridad a cada capa; de otra forma, se pueden dejar aplicaciones vulnerables frente a ataques porque cada capa ofrece su propia superficie de ataque y puede no estar protegida por las demás capas. Por ejemplo: una aplicación web insegura que se vea atacada con una inyección SQL no recibirá protección de las capas externas como se ve en la figura 1 sin el uso de algún software especializado de tercero. Los responsables de la ciberseguridad deberán cubrir cada escenario posible y proteger los sistemas de cada forma posible. Y, por duro que suene, a veces los atacantes sólo necesitan encontrar una sola falla para comprometer un sistema entero. Este artículo describe los problemas más comunes de seguridad encontrados en cada capa nativa de la nube y ofrece consejos de detección y protección. 

 

Seguridad en la Nube 

 

Bajo este framework, la capa de nube se refiere a la infraestructura en la que corren los servidores. Hay muchos servicios diferentes involucrados en la configuración de un servidor en su CSP (Cloud Service Provider) preferido. Y, aunque mucha de la responsabilidad por la seguridad de esos servicios (por ejemplo, el sistema operativo, la gestión de la plataforma y la configuración de la red) recae en el CSP, el cliente aún es responsable por revisar y configurar estos servicios, así como supervisar y asegurar sus datos. La comprensión de este modelo de responsabilidad compartida es esencial para migrar recursos y servicios organizacionales a la nube. 

 

[image url=”http://blog.la.trendmicro.com/wp-content/uploads/2020/06/TM_blog_4c_diagram2.png” raw=”true” alignment=”center” margin_left=”0″ margin_right=”0″ margin_top=”0″ margin_bottom=”0″]

 

Estos son los problemas más comunes en los sistemas de nube actuales: 

 

• Temas de configuración: Conforme aumenta el número de componentes para varias arquitecturas en la nube, también esperamos ver un incremento en el número de errores de configuración. Aunque sean producto de descuidos u olvidos, los temas de configuración a menudo le dan ventaja a los cibercriminales, costándole grandes sumas de dinero a los negocios, e incluso a su reputación. Los temas de configuración son bastente comunes. Por ejemplo, temas de configuración permitieron que atacantes agregaran cryptominers a la consola de administración de Kubernetes de Tesla. Muchos servicios y aplicaciones fueron creados con configuraciones por defecto que los exponen al internet, y a muchos bots y actores maliciosos que buscan explotarlos. Recientemente, hemos observado cómo es que los cibercriminales abusaron de instancias expuestas de Redis y realizaron ejecución remota de código (RCE) o las convirtieron en bots de cryptomining.

• Automatización: La automatización es buena para incrementar la velocidad de la creación de nuevos sistemas y para el despliegue de nuevas aplicaciones. Sin embargo, también puede propagar errores y temas de seguridad mucho más rápido si no se les monitorea correctamente. Además de las mismas amenazas, la velocidad a la cual las amenazas pueden desplegarse en un sistema o dispositivo vulnerable conectado a la web es alarmante. En un estudio, investigadores descubrieron que solamente le tomó a los cibercriminales 52 segundos escanear y atacar sus dispositivos no protegidos a través de honeypots que instalaron los investigadores. Por lo tanto, las organizaciones deben poder asegurar las diferentes partes de su arquitectura de manera correcta y eficiente. 

 

Las organizaciones pueden evitar encontrarse con estos problemas siguiendo las recomendaciones de su proveedor de nube y realizando auditorías regulares para asegurarse de que todo está configurado apropiadamente antes de que se implemente en la producción y se exponga a internet. 

La adopción de prácticas de Infrastructure as Code (IaC) es una medida efectiva que asegura que los sistemas sean creados correctamente y que sus configuraciones son apropiadas. IaC usa código para automatizar el correcto aprovisionamiento de arquitecturas de TI, lo cual permite la eliminación del aprovisionamiento manual por los ingenieros de DevOps, minimizando así la supervisión y el error humano siempre y cuando se sigan las mejores prácticas. Herramientas como Terraform, Ansible, y CloudFormation son grandes maneras de definir las configuraciones de su infraestructura, incluyendo sus configuraciones de seguridad. También ayuda a asegurar que dichas configuraciones no sufren cambios a menos de que alguien los apruebe y despliegue el código necesario para realizar el cambio. 

Usar prácticas de IaC, es el nuevo normal en cuanto a la creación y desarrollo de entornos en la nube se refiere, y permite que las organizaciones aprovechen al máximo los diferentes niveles de automatización, así como sus velocidades de implementación. Realmente no hay necesidad de crear y configurar servidores de forma manual actualmente – la automatización es clave para la seguridad de las arquitecturas en la nube. 

Además, asegúrese de seguir las recomendaciones de seguridad de su CSP. Estas son algunas de las mejores prácticas de seguridad de los CSPs más populares: 

• Amazon Web Services - https://aws.amazon.com/security/

• Google Cloud Platform - https://cloud.google.com/security/ 

•  Microsoft Azure - https://docs.microsoft.com/en-us/azure/security/azure-security 

 

Las soluciones que ofrecen visibilidad a las arquitecturas en la nube y automatizar la seguridad y las auditorías de seguridad, como Trend Micro™ Cloud One – Conformity, ayudan a simplificar y optimizar la seguridad en esta capa. 

 

Seguridad de Clusters 

 

Cuando hablamos sobre seguridad de clusters, nos enfocaremos principalmente en Kubernetes, ya que es la herramienta de orquestación más usada actualmente. Sin embargo, los principios de seguridad también pueden aplicarse a otras soluciones. 

Hay tres elementos principales relevantes a clusters en los que las organizaciones deben enforcarse: 

 

• Compomentes del cluster: Esto se relaciona con la protección de los componentes que conforman el cluster, o el nodo maestro, en el caso de Kubernetes. Elementos como el control de las APIs que acceden al servidor y restringir el acceso directo a etcd, el cual es el almacén principal de datos de Kubernetes, deberían ser prioridades cuando se habla de la seguridad de clusters. Kubernetes tiene un documento detallado que aborda cómo proteger clusters contra accesos maliciosos o accidentales. En un artículo reciente, hablamos sobre 3,000 hosts donde etcd fue expuesto públicamente. Para evitar esto, recomendamos que los administradores de la nube nieguen el acceso por defecto y permitan únicamente tráfico explícito. A menos de que tenga un equipo grande y/o requerimientos estrictos de cumplimiento, se recomienda usar servicios gestionados de clusters como Azure Kubernetes Service (AKS), Elastic Kubernetes Service (EKS) o Google Kubernetes Engine (GKE).

• Servicios de cluster: Esto aplica a la configuración y controles de acceso correctos a los servicios que corren en el cluster. Para proteger estos servicios, Kubernetes recomienda medias protectivas como la administración de recursos y correr servicios con menos privilegios. Asegúrese de configurar autenticación y autorización para sus clusters, encriptar su tráfico usando Transport Layer Security (TLS) y proteger información sensible usando secretos. También recomendamos que explore el Center for Internet (CIS) Kubernetes Benchmark para conocer más detalles técnicos sobre la protección de sus servicios de clusters.

• Red de clusters: Esto se relaciona con la asignación adecuada de puertos para facilitar la comunicación entre containers, pods y servicios. Es importante asegurarse de que el modelo de red de Kubernetes está implementado de manera segura usando una Container Network Interface (CNI) que permitirá que los usuarios restrinjan el tráfico de pods. 

 

Consulte recomendaciones más detalladas para la protección u orquestación de containers en nuestra guía de modelos de amenazas para Kubernetes. 

 

Seguridad de Containers 

 

Los Container Runtime Engines (CREs) son necesarios para correr los containers en el cluster. Aunque Docker es uno de los CREs más populares, Kubernetes también soporta otros como containerd o CRI-O. Hay tres cosas principales que las organizaciones deben abordar en esta capa: 

 

• ¿Qué tan seguras son sus imágenes? Esto se resume en asegurar que sus containers estén actualizados y libres de cualquier vulnerabilidad importante que pudiese ser explotada por un cibercriminal. Las organizaciones deben proteger no solamente la imagen base, sino también asegurar que las aplicaciones que están ejecutándose en sus containers han sido escaneadas y verificadas. Aunque existen algunas herramientas de código abierto disponibles para este fin, no todas pueden detectar vulnerabilidades más allá de los paquetes del SO. Para esto, las empresas pueden usar una solución que también cubre las vulnerabilidades de las aplicaciones, como Deep Security™ Smart Check. 

• ¿Se puede confiar en ellas? ¿Están construidos los containers que corren en su sistema a partir de las imágenes en sus registros? ¿Cómo puede proteger eso? Al usar herramientas como TUF o Notary, puede firmar sus imágenes y mantener un sistema confiable para el contenido de sus containers.

• ¿Están corriendo con los privilegios adecuados? El principio del menor privilegio aplica aquí. Sólo debería correr containers con usuarios que tienen los privilegios mínimos necesarios del SO para llevar a cabo sus tareas. Hemos explicado a detalle previamente la razón de por qué es mala idea correr containers privilegiados en Docker, o containers que tienen las capacidades raíz que una máquina host. 

 

Hemos creado una guía integral para una mejor protección de containers a través de una examinación de las amenazas potenciales en cada etapa del pipeline. 

 

Seguridad del Código 

 

Esto también puede llamarse seguridad de aplicaciones, y es la capa sobre la cual las organizaciones tienen más control. El código de sus aplicaciones es el corazón de sus sistemas, junto con sus respectivas bases de datos, y usualmente están expuestas al internet – por lo tanto, los criminales se enfocarán en esto si todos sus demás componentes están protegidos adecuadamente. Entonces, ¿cómo es que las organizaciones pueden asegurar que el código de sus aplicaciones está escrito de manera correcta y segura cuando tienen decenas, cientos o incluso miles de desarrolladores escribiendo y desplegando código todos los días en su ambiente de producción? 

Primero que nada, las organizaciones deben asegurar que todas las comunicaciones se realizan por medio de Encripción TLS, incluso entre servicios internos como el balance de cargas, servidores de aplicaciones y bases de datos. Cuando se usa una herramienta de orquestación como Kubernetes, se pueden aprovechar servicios como Istio o Linkerd. 

Las organizaciones pueden reducir significativamente la superficie de ataque de sus sistemas solamente con limitar y monitorear los servicios, puertos y APIs en los endpoints expuestos. Aquí es importante también pensar en las imágenes de base del contenedor y los sistemas sobre los cuales están corriendo sus clusters. 

Hay varias verificaciones de seguridad del código que puede agregar a su pipeline para asegurar que su código está protegido. Estas son algunas: 

 

• Análisis estático de la seguridad en las aplicaciones: También llamado “revisión de la seguridad del código” o “auditoría del código”, esta es una de las maneras más rápidas de detectar problemas de seguridad en su código. Sin importar el lenguaje que está usando, debe tener al menos una herramienta estática de análisis integrada en su pipeline que busque prácticas inseguras cada vez que sus desarrolladores inserten código nuevo. La Open Web Application Security Project (OWASP) Foundation tiene una lista de herramientas comerciales y open source diseñadas para analizar código fuente y/o compilado para detectar fallas de seguridad.

• Análisis dinámico de la seguridad en las aplicaciones: Aunque el análisis dinámico sólo puede hacerse cuando tiene una aplicación corriendo, también es una buena idea realizar escaneos y revisiones automáticas para detectar ataques comunes a aplicaciones como inyecciones de SQL, cross-site scripting (XSS) y cross-site request forgery (CSRF). Estas herramientas también pondrán a prueba la resiliencia de su aplicación, container y cluster cuando enfrentan un incremento de carga y solicitudes no esperadas. OWASP tiene una herramienta de análisis dinámico que también puede automatizarse e integrarse en su pipeline, OWASP Zed Attack Proxy (ZAP).

• Análisis de composición de software: Entre el 70 y el 90% de todas las aplicaciones nativas de nube están hechas de bibliotecas o dependencias de terceros. Estos son pedazos de código – probablemente escrito por alguien fuera de su organización – que está integrado y corriendo dentro de sus sistemas en producción. Estos códigos generalmente no se revisan durante la fase de análisis estático. Herramientas como OWASP dependency-check pueden ser útiles para revisar bibliotecas vulnerables o desactualizadas en su código. Snyk también ofrece verificación de terceros para proyectos de código abierto.
  

Las cuatro capas de los sistemas nativos de nube son críticas para mantener seguras las aplicaciones – y dejar a una de ellas expuesta a los atacantes les dará el apalancamiento necesario para comprometer el sistema completo. Asegurar que su sistema nativo de nube es resiliente es esencial para mantener a su organización productiva, dinámica y, sobre todo, a flote. 

 

Las soluciones de seguridad de Trend Micro 

 

Las soluciones de seguridad específicas de nube como Trend Micro™ Hybrid Cloud Security pueden ayudar a proteger sus sistemas nativos de nube y sus capas. Está potenciado por Trend Micro Cloud One™, una plataforma de servicios de seguridad para desarrolladores en la nube que ofrece protección automatizada para el pipeline CI/CD y las aplicaciones. También ayuda a identificar y resolver problemas de seguridad de forma más temprana, y a mejorar el tiempo de entrega para los equipos de DevOps. Incluye: 

• Workload Security: protección en runtime para workloads

• Container Security: escaneo automatizado de imágenes y registros de container 

• File Storage Security: seguridad para servicios de almacenamiento de archivos y objetos en la nube

• Network Security: seguridad IPS para la capa de la red en la nube

• Application Security: seguridad para funciones serverless, APIs y aplicaciones 

• Conformity: protección en tiempo real para la infraestructura en la nube – proteja, optimice, cumpla