Noticias

Los desafíos a nivel de seguridad de los centros de datos modernos

Los desafíos a nivel de seguridad de los centros de datos modernos

No solo en los productos de consumo cambia la informática a gran velocidad, sino que también se han visto grandes cambios en las estructuras corporativas en los últimos años, sobre todo desde la irrupción del cloud computing, que ha cambiado de forma radical la forma de entender los centros de datos.

En un mundo cada vez más competitivo, los centros de datos están siendo adaptados para las nuevas arquitecturas de software dominantes y las metodologías de DevOps, que se crean utilizando nuevas tecnologías. Actualmente, las infraestructuras computacionales de las grandes corporaciones se apoyan fuertemente tanto en la nube pública como la privada (dando como resultado una nube híbrida cuando se combinan), algo que está siendo impulsado mediante la virtualización y las tecnologías basadas en contenedores. Estas nuevas infraestructuras prometen una mayor escalabilidad y elasticidad, una mejor integración en la estructura de las aplicaciones mediante microservicios distribuidos, la reducción de los costes y ciclos de desarrollo más rápidos.

Sin embargo, no todo es de color rosa en la implementación y utilización de estas tecnologías en los centros de datos, ya que también conllevan retos a nivel de seguridad. En MuySeguridad hemos visto cómo el malware y los ciberdelincuentes han diversificado sus objetivos con el paso de los años. Si antes los usuarios finales eran casi la única prioridad, ahora las empresas, que manejan una gran cantidad de datos de interés y computadoras de mayor capacidad, se han convertido en un objetivo prioritario. Además de robar, también cabe la posibilidad de que su potencia computacional pueda acabar aprovechada para tareas como el minado malicioso de criptodivisas.

Los componentes a tener en cuenta en el entorno de virtualización y las aplicaciones

El fomentar las buenas prácticas de seguridad en los centros de datos es algo que va mucho más allá de ser algo recomendado por expertos de seguridad, sino que es un tema de interés público. El Instituto Nacional de Estándares y Tecnología (NIST/National Institute of Standards and Technology), una división del Departamento de Comercio de Estados Unidos, ha publicado una extensa guía sobre la seguridad de las aplicaciones contenedorizadas, de la que se puede extraer como primera recomendación “adaptar la cultura y procesos técnicos operacionales de la organización para soportar las nuevas vías de desarrollo, ejecución y soporte de aplicaciones mediante contenedores”. Además, el NIST también analiza los riesgos únicos que presentan.

Pero más allá de las recomendaciones, el NITS identifica diversas áreas en las que los contenedores han introducido nuevos elementos en los centros de datos, y cada uno de ellos conlleva sus propios riesgos a nivel de seguridad:

  • Las imágenes, que se componen de todos los ficheros incluidos en todos los componentes usados para ejecutar la aplicación.
  • El registro, compuesto por el servicio que permite a los desarrolladores almacenar las imágenes como las han creado, etiquetándolas e identificándolas para su identificación, control de versión, descubrimiento y reutilización.
  • El orquestador, que es el servicio que permite a los DevOps o las herramientas de automatización trabajar a su favor para tirar (pull) de las imágenes desde los registros, implementando dichas imágenes en contenedores y gestionando los contenedores en ejecución. Un ejemplo de software de orquestación de contenedores es Kubernetes, que además es la gran referencia dentro de su sector tras “derrotar” a Docker Swarm.
  • El entorno de ejecución de los contenedores es la capa de virtualización que se encarga de aislar los componentes de la aplicación y del sistema operativo anfitrión (sobre el cual se ejecutan los contenedores), a la vez que habilita la utilización de recursos locales como la CPU, la memoria y las interfaces de red.
  • El mismo sistema operativo anfitrión, que ya hemos definido en el punto anterior.

Las aplicaciones críticas del centro de datos

Tanto la arquitectura de los centros de datos modernos como las aplicaciones que ejecutan están inherentemente distribuidas, haciendo muy importante la interacción de los distintos componentes a través de la red. Aunque los riesgos son aparentemente bien conocidos, estos pueden quedar agravados en la implementación de entornos de virtualización.

En los centros de datos modernos se pueden encontrar diferentes aplicaciones compartiendo la misma red virtual. Al mismo tiempo, en la mayoría de los contenedores y entornos de virtualización, se puede acceder a los componentes de una aplicación individual y al sistema operativo anfitrión a través de red. Un ejemplo de esto podría ser la utilización de un servidor web que funciona de cara al público y una base de datos interna que trabajan en la misma red virtual, una situación que podría dejar información sensible expuesta a los atacantes en caso de que el servidor web estuviera comprometido. El ataque podría extenderse al resto de la red virtual compartida, exponiendo los datos internos de la compañía al alcanzarse los componentes del cluster que no trabajan de cara al público. En consecuencia, no solo hay que implementar una defensa perimetral en torno al centro de datos, sino también a nivel de las aplicaciones críticas debido a que el tráfico de red puede llegar a través de elementos dentro de la misma red que están expuestos.

Una buena práctica a nivel de seguridad para corregir este problema es creando una segmentación de red a través de las políticas que prohíban la conectividad entre diferentes conjuntos de aplicaciones. Sin embargo, esto presenta una serie de inconvenientes, ya que resulta difícil identificar y hacer un seguimiento de los miles de servicios de aplicaciones que se están añadiendo, eliminado o modificando a la velocidad que se espera de los equipos de DevOps. Las máquinas virtuales y los contenedores que no pasan los controles pertinentes pueden convertirse en algo común, sobre todo en los entornos de desarrollo, en los cuales los desarrolladores suelen probar su código. En caso de que esos componentes no sean debidamente comprobados para ver si contienen vulnerabilidades o están mal configurados, pueden terminar volviéndose susceptibles a los exploits. Cabe la posibilidad de que persistan en el entorno computacional sin que desarrolladores y administradores se percaten de ello, ofreciendo así un punto débil a los atacantes interesados o que descubran que pueden ir contra la organización.

La complejidad de la gestión del filtrado del tráfico de salida en un entorno virtualizado es mayor que en los centros de datos tradicionales, debido a que muchos conexiones entre las aplicaciones también están virtualizadas. Esto hace que el tráfico procedente de un contenedor sea simplemente paquetes encapsulados en la red sin indicar directamente la fuente, el destino o la carga final. Hay que tener en cuenta que las herramientas y los procesos operacionales son capaces de identificar el contexto, por lo que no pueden determinar qué tráfico representa una amenaza.

Los cambios a implementar en términos de seguridad no son tan dramáticos

Aunque los contenedores, sobre su todo su masificación a través de tecnologías como Docker, han cambiado la forma en que se construyen y despliegan las aplicaciones, tampoco es que haga falta una transformación radical de la seguridad para mantener este apartado a unos niveles altos, a pesar de la necesidad de tener que aplicar cambios y actualizaciones para adaptar las políticas al nuevo contexto tecnológico.

Un aspecto importante es que la seguridad debe ser tan portable como los propios contenedores y las máquinas virtuales, por lo que la organización deberá tomar medidas que funcionen a través de distintos entornos y plataformas.

Fuente: The New Stack

Powered by WPeMatico

Gustavo Genez

Informático de corazón y apasionado por la tecnología. La misión de este blog es llegar a los usuarios y profesionales con información y trucos acerca de la Seguridad Informática.