Header Ads Widget

Ticker

6/recent/ticker-posts

Formas de reforzar la arquitectura de la nueva plataforma


Cada año aparecen nuevos estilos de diseño de arquitectura de software. Prometen ofrecer una mayor flexibilidad, más potencia y más libertad para realizar cálculos de formas únicas. Desafortunadamente, este mayor poder conlleva una mayor responsabilidad para garantizar que se aborden los agujeros de seguridad .

Los estilos arquitectónicos populares como máquinas virtuales , sin servidor , microservicios y contenedores vienen con nuevas preocupaciones de seguridad que los arquitectos no pueden permitirse pasar por alto. Hoy, adoptamos un enfoque DevSecOps para considerar cómo las nuevas arquitecturas de plataforma pueden ser vulnerables de nuevas formas.

Abordemos los problemas fundamentales a los que están sujetos estos nuevos estilos y consideremos los métodos que podemos adoptar para reforzar su seguridad.

Maquinas virtuales

Una máquina virtual es, en esencia, una instancia única virtualizada que se ejecuta en varios recursos físicos. Por esta razón, las máquinas virtuales presentan problemas únicos en términos de acceso a datos , redundancia y seguridad holística en comparación con otras ofertas. Al analizar las técnicas de endurecimiento, debe tenerse en cuenta que estas técnicas deben aplicarse universalmente. Por supuesto, esto se hace mucho más fácil mediante el uso de una imagen. al configurar las instancias virtuales, pero no obstante, es un punto débil potencial que debe abordarse.

En primer lugar, a menos que exista un caso comercial válido y sólido (como la creación de una red virtual o una oficina virtual), cada máquina virtual debe funcionar esencialmente de forma aislada . Si bien, por supuesto, se espera la comunicación con el mundo exterior, el sistema central en sí debe estar aislado. Si la máquina virtual puede hablar con otras máquinas virtuales en el mismo clúster, la escalada de privilegios puede convertirse rápidamente en una amenaza significativa.

Más específicamente, al reforzar una máquina virtual, la capacidad de esa máquina para escribir en la memoria del host, independientemente del motivo, debe estar muy limitada y supervisada . Si bien existen algunas advertencias específicas (y de hecho áreas específicas en las que se justifica una mayor restricción), el simple hecho es que una máquina virtual es tan segura como está controlada . Cuando esa máquina es capaz de liberarse de sus limitaciones, se pueden producir daños a gran escala.

Un ejemplo del daño potencial que se puede hacer se puede encontrar en la forma en que las máquinas virtuales informan y registran datos . A medida que una máquina virtual ejecuta sus funciones, a menudo escribirá datos en un registro local para que la administración remota pueda rastrear los cambios y contextualizar los procesos. En teoría, si esto no se reduce y los tamaños no están limitados, un atacante podría desbordar el tamaño de este registro, involucrando a la máquina host en un ataque interno de tipo DDoS que luego afectaría a todas las demás máquinas virtualizadas.

Otro agujero de seguridad importante en las máquinas virtuales es la virtualización de los medios adjuntos. Una máquina virtual no tiene una unidad de CD o un puerto USB, pero esto a menudo se puede emular con bastante facilidad, especialmente al transferir unidades virtuales a medios físicos locales. Algunos hipervisores de virtualización permiten esto de forma predeterminada, y en tales casos, se expone un enorme agujero de seguridad, lo que permite a los usuarios montar ISO problemáticos o cargar programas portátiles en espacio aislado para escalar privilegios, distribución de virus o cualquier otro de los muchos posibles vectores de ataque habilitados.

Sin embargo, pase lo que pase , una máquina virtual es como cualquier otra máquina: es fundamentalmente insegura y los esfuerzos para hacerla más segura siempre se encontrarán con ataques más avanzados y escaladas de amenazas. En consecuencia, una de las mejores cosas que puede hacer para mejorar la seguridad integral de las máquinas virtuales es eliminar las máquinas virtuales cuando ya no tienen un propósito . A menudo, debido a que su puesta en marcha y mantenimiento son tan baratos, las máquinas virtuales suelen quedar a perpetuidad. Esto aumenta la superficie de ataque de toda su red subyacente, además de agregar vectores de ataque al sistema en sí debido al mantenimiento deficiente y la falta de supervisión.

MicroVM

Las MicroVM son, en términos generales, lo mismo que una máquina virtual estándar, con la salvedad de que tienen una función singular o un propósito aislado . Debido a esto, tienen algunas advertencias específicas sobre su seguridad y la naturaleza de su uso, interacción y mantenimiento.

Un microVM realmente no hace nada por sí solo; en cambio, aprovecha un poderoso backend de integraciones y recursos para llevar a cabo su trabajo en lo que es esencialmente una unidad de cálculo discreta. Desafortunadamente, esto significa que la seguridad del sistema subyacente de integraciones y recursos de soporte es una amenaza única y unificada . Asegurar que cada recurso sea confiable, actualizado, aislado y confiable es una tarea grande, pero debe participar para que el microVM se pueda utilizar de manera segura.

También está el hecho de que, a diferencia de una máquina virtual, las microVM a menudo toman datos especialmente diseñados de una variedad de fuentes . Esto, a su vez, significa que la entrada de datos debe desinfectarse y validarse , ya que los datos introducidos en el sistema podrían invalidar muchas salvaguardas.

Dicho esto, un microVM está, por diseño, tan aislado de otras unidades de cómputo que cada amenaza a la seguridad generalmente se borra cuando el microVM alcanza su corta vida útil. Aún así, las microVM presentan muchos de los mismos problemas de seguridad que presenta una VM tradicional y deben tratarse como un tipo diferente de la misma clase de soluciones.

Sin servidor

Sin servidor es un enfoque interesante; Es esencialmente un servidor que gestiona la asignación de recursos cuando y donde sea necesario. Si bien este enfoque de función como servicio es excelente para sistemas dependientes de la velocidad, de alta disponibilidad y controlados por eventos, tiene sus propias implicaciones de seguridad que deben contextualizarse adecuadamente.

El mayor riesgo de seguridad en el mundo sin servidores es el método y el nivel de acceso otorgado a cada solicitud de recursos. Por su naturaleza, una solicitud de recursos debe tener acceso a recursos en un mundo sin servidores. Pero al hacerlo, existe el peligro de otorgar demasiado acceso y luego no administrarlo adecuadamente más adelante. Esto puede resultar en que a una función se le otorguen demasiados recursos y luego le permita solicitar más y más recursos, iniciando así un tipo de ataque de denegación de servicio.

Este tipo de ataques se pueden mitigar en gran medida desinfectando los insumos . Esto es especialmente cierto para cualquier aplicación sin servidor que permita la funcionalidad de scripts o bases de datos, ya que algo tan simple como una inyección SQL puede cambiar drásticamente la asignación de recursos y las capacidades de un sistema de cómputo discreto y simple.

También está el problema obvio que surge al colocar todas las solicitudes sin servidor en el mismo grupo de recursos. Esto, a su vez, sugiere que las bibliotecas y las integraciones que subyacen a ese servicio deben administrarse, actualizarse y protegerse. Esto también era un problema con las máquinas virtuales, pero en el mundo sin servidor, una función personalizada que utiliza un error de biblioteca que se enfrenta públicamente sin tener su control de acceso correctamente administrado puede resultar en una única función que esencialmente se hace cargo de todo el sistema. Con microVM, simplemente puede cerrar la instancia. Con Serverless, es un poco más complejo en tal caso.

También existe la realidad de que la tecnología sin servidor presenta una mayor complejidad del sistema en comparación con las soluciones tradicionales. En esta complejidad, los problemas de seguridad pueden volverse más grandes de lo que parecen inicialmente simplemente debido a la naturaleza compleja de detectarlos, probarlos, parchearlos y prevenirlos. Esto también da como resultado una mayor superficie de ataque que a su vez es más compleja, multiplicando estas situaciones problemáticas a mayores alturas con cada función adicional activada.

Más sobre seguridad de API: 9 preguntas para la auditoría de seguridad de API de nivel superior

Microservicios

En muchos sentidos, muchas de las principales amenazas de seguridad subyacentes a las API son fundamentalmente igualmente válidas en los microservicios . Las solicitudes externas significan que cada paquete de datos debe ser validado, desinfectado y dentro de un parámetro de forma determinado. Los recursos deben ser limitados, el acceso debe estar regulado y, en general, los microservicios deben comunicarse entre sí internamente sin exponer necesariamente la funcionalidad del sistema central subyacente.

Dicho esto, hay muchas más partes móviles con una colección de microservicios en comparación con una API tradicional y, como tal, merece cierta discusión. Una única API dividida en diez microservicios significa que su superficie de ataque ha aumentado drásticamente, así como la cantidad de vectores específicos. Si bien esto puede ser combatida con la adecuada limitación de velocidad y de la validación de datos , esto comienza con lo que el conjunto de microservicios más cerca de una singular y unificada de productos - en otras palabras, una API.

La naturaleza única de tal colección de microservicios significa que algunos tipos de ataques solo existen en esta configuración específica. Por ejemplo, con una configuración incorrecta , es posible que un atacante pueda formar una solicitud única que haga que los microservicios se repitan entre sí, enviando constantemente el mismo tráfico una y otra vez a cada nodo. Esto sería similar a un ataque DDoS de autoservicio. Incluso cuando la tasa está correctamente limitada, si no se tiene en cuenta el tamaño, este ataque puede provocar ataques de desbordamiento que causan un daño masivo al estado de la red subyacente y a la capacidad del microservicio para hacer lo que debe hacer.

También está el hecho muy obvio de que un microservicio es esencialmente un servicio que se ha dividido en partes, y con esto, los mismos requisitos redundantes en bibliotecas y recursos que necesitan actualizarse, monitorearse, etc., pasan a primer plano. Gran parte de esto puede automatizarse o incluso excluirse. Por ejemplo, no es necesario tener una biblioteca de mensajes para la pieza de microservicio que no envíe mensajes al cliente, pero en la práctica, esto significa una mayor complejidad.

El endurecimiento de microservicios se maneja mejor en un enfoque por capas . El microservicio debe ser el primero en asegurarse. Aísle cualquier problema de API, endpoints no documentados y amenazas de escalamiento. Luego, busque el software subyacente y la capa de transporte . Asegurarlos garantizará que los datos en tránsito estén a salvo de la manipulación y que sus esfuerzos en la capa de microservicios no se desperdicien. Finalmente, mire el hardware . Las actualizaciones de paquetes principales, las vulnerabilidades subyacentes e incluso las inseguridades físicas pueden significar que la seguridad de todo el sistema se anula esencialmente. Endurecimiento en cada etapa; La implementación de cortafuegos, la prevención de la inyección de código, la mitigación de ataques mediante la heurística y las comparaciones de línea de base, etc., es necesaria para la seguridad total del microservicio.

Lee mas: ¿Cuál es la diferencia entre API y microservicios?

Contenerización

Contenedores son, por diseño, sistemas discretos. Sus funciones y datos están destinados a estar separados entre sí, y como tal, hay una cierta cantidad de endurecimiento incorporado. Desafortunadamente, este espíritu también requiere que cada contenedor hable con otros contenedores y con los sistemas subyacentes y, como tal, todos los problemas inherentes a las máquinas virtuales también se encuentran en los contenedores.

La mayor amenaza aquí, como con la mayoría de los productos de virtualización, es el acceso a datos sin restricciones. . Sin embargo, el flujo de datos también debe ser limitado, ya que los datos del contenedor que fluyen de un contenedor a otro pueden afectar a toda la colección de contenedores, garantizar que los datos se limiten solo al contenedor en cuestión antes de ser desinfectados puede contribuir en gran medida a proteger su red.

Cada contenedor también puede tener su propio conjunto de actualizaciones y parches, especialmente con muchos clientes. Esto puede dar lugar a problemas de seguridad desde una versión anterior que se propaga a versiones más nuevas cuando la ejecución del código no está correctamente limitada y la comunicación es libre y abierta.

También debe tenerse en cuenta que, a diferencia de una máquina virtual, todos los contenedores comparten el núcleo . Esto significa que cualquier exposición o vulnerabilidad del kernel es esencialmente global y puede afectar a todos los contenedores del kernel. Por lo tanto, la seguridad del kernel es un problema importante. También es posible que las imágenes utilizadas por el kernel para crear un contenedor puedan estar expuestas o envenenadas, y cuando eso ocurre, las imágenes envenenadas pueden distribuirse a todas las áreas y fundamentalmente hacer que su red sea insegura.

Esfuerzos para proteger la virtualización

Casi toda la arquitectura de la nueva plataforma que hemos discutido en este artículo son enfoques fundamentalmente diferentes para la virtualización discreta . Esto es cada vez más normal a medida que las empresas adoptan estrategias de alquiler de datos y computación en la nube. Desafortunadamente, eso también significa que los riesgos de seguridad centrales más tradicionales de los sistemas físicos están siendo reemplazados por problemas más complejos, a veces fundamentales, que a menudo se pasan por alto en favor de sugerencias simples como "instalar firewalls en su sistema operativo emulado" que hacen muy poco, en todo caso, para detener las amenazas sistémicas.

Con esto en mente, comprender las limitaciones centrales, las amenazas y las exposiciones básicas del concepto de virtualización puede ayudar a proteger sus sistemas, si no a aislarlos perfectamente de las amenazas potenciales.

¿Crees que enfrentamos las mayores amenazas a este modelo de diseño de arquitectura? Háganos saber en los comentarios a continuación.


Publicar un comentario

0 Comentarios