Aprovechar el lenguaje natural para definir y simplificar las políticas de microsegmentación

De los tres recursos básicos en cualquier centro de datos o nube (computación, almacenamiento de información, red), la red ha sido la más lenta en evolucionar hacia el mundo moderno de la virtualización y abstracción de recursos. Esto es en gran parte por diseño. Se puede argumentar que la estructura de red es el recurso más crítico en cualquier data center o arquitectura de nube. Sin una red, la computación y el almacenamiento de información son islas inalcanzables. La red permite el acceso y la comunicación entre todos los recursos de cómputo y almacenamiento de información, entre ellos y hacia los usuarios finales de estos recursos. Sin la red subyacente a ninguna arquitectura, todas las conversaciones en la nube no tienen sentido. No importa qué tan lejos abstraga las conversaciones en la nube en torno a los recursos de computación, desde bare-metal hasta sin servidor, si hay un paquete IP en cualquier parte de la imagen, la red es crítica.

La seguridad de la red ahora se define utilizando lenguaje natural, no lenguaje de red.

Esto es de sentido común, y las redes tienen sus propias formas de virtualización de recursos destinadas a resolver problemas específicos de redes. Aún así, se menciona aquí por el simple hecho de que la seguridad en data centers o implementaciones en la nube tradicionalmente se ha implementado en la red. Con el fin de bloquear o habilitar el tráfico de red en tránsito entre los recursos de la nube, se implementa un firewall en algún lugar de la estructura de la red. El software de punto final puede implementarse en recursos de cómputo, que generalmente son herramientas basadas en firmas que buscan malware conocido o mal comportamiento, pero generalmente están inspeccionando el tráfico, no bloqueándolo ni permitiéndolo. La mayoría de las cargas de trabajo tienen algún tipo de capacidades de firewall integradas, como iptables en Linux, pero orquestar estas herramientas a escala a menudo es difícil de administrar y, por lo tanto, no se usa. Entonces, seguridad de red y la aplicación del tráfico se realiza tradicionalmente con firewalls de red.

La seguridad a menudo se define en un idioma diferente

Dado que los firewalls generalmente son administrados por equipos de redes, la política de seguridad se define con mayor frecuencia utilizando términos que son familiares para los equipos de redes. Los firewalls han existido durante décadas y la forma en que se configuran ha cambiado mínimamente a lo largo de los años. Las reglas de política se escriben tradicionalmente utilizando direcciones IP, puertos de tipo CPS, VLAN y zonas. Los firewalls generalmente no están diseñados para profundizar en la carga útil de datos de los paquetes para inspeccionar qué contenido o aplicaciones están contenidos, ya que quieren evitar convertirse en un cuello de botella de tráfico de red.

Existen los llamados firewalls de próxima generación (NGFW) que tienen la capacidad de inspeccionar paquetes mucho más profundamente a la velocidad del cable y pueden definir políticas contra lo que realmente está contenido en la carga útil de datos de un paquete, y no solo sus encabezados de red. Pero debido a que los viejos hábitos mueren duramente, la realidad es que a menudo estos firewalls se configuran de la manera antigua, con las opciones de próxima generación dejadas sin usar. El resultado es un dispositivo que utiliza terminología de red para definir seguridad de red, que no es la forma en que los usuarios de recursos alojados en un data center o en la nube perciben esos recursos. Los usuarios a menudo no saben, o no les importa, en qué segmento de red se aloja un recurso. Se preocupan por el recurso en sí.

La política de red debe reflejar cómo los usuarios perciben los recursos que se protegen

Cuando un usuario o desarrollador informa de un problema, como no poder llegar a un recurso que está alojado en un centro de datos o en la nube, por lo general se referirá a la carga de trabajo o aplicación específica que es inalcanzable. Por lo general, no informan que una dirección IP específica no es accesible a través de un puerto específico. Sin embargo, la creación de redes o operaciones de seguridad los equipos solicitarán esta información. Y aquí es donde surge el problema: El problema que se informa está en un idioma diferente al de los dispositivos que están haciendo cumplir la política de red. Por lo general, el lenguaje de las aplicaciones no es igual al lenguaje de red.

Un detalle importante en la búsqueda de automatizar tantos recursos como sea posible en arquitecturas de nube es la capacidad de definir políticas de red utilizando los mismos términos que los usuarios perciben que son los recursos protegidos. Si un firewall aplica políticas entre las aplicaciones X, Y y Z, debería poder definir políticas específicas para esas aplicaciones y no específicas para el recurso de red en el que están alojados.

Esto es especialmente relevante en las infraestructuras modernas alojadas en la nube pública, como los microservicios, en las que las direcciones IP son efímeras. Las cargas de trabajo y las aplicaciones a menudo se migran dinámicamente a través de diferentes segmentos de red, por lo que una dirección IP ya no es una forma confiable de identificar ninguna carga de trabajo específica para el ciclo de vida de ese recurso. Si tiene que modificar un firewall cada vez que cambia una dirección IP, esto no es escalable.

El resultado es que, muy a menudo, los firewalls simplemente no se implementan en las arquitecturas de nube modernas. En su lugar, quedan relegados a sentarse en el perímetro de una estructura de nubes, imponiendo únicamente el tráfico Norte-Sur, ciegos a la mayoría del tráfico Este-Oeste.

Definir la seguridad mediante metadatos, no IPs

La mayoría de los controladores SDN modernos pueden crear lo que equivale a una base de datos local de IPs y metadatos de carga de trabajo que se aplica a cada carga de trabajo. Por ejemplo, si cinco cargas de trabajo de producción son servidores SQL y otras cinco cargas de trabajo son servidores SQL de desarrollo, el controlador creará un registro local que enumera esos servidores en dos categorías, con las primeras cinco IP de carga de trabajo asignadas a una etiqueta de metadatos de “SQL-prod” y las segundas cinco IP de carga de trabajo asignadas a una etiqueta de metadatos de “SQL-dev”. El controlador supervisará esas cargas de trabajo y, si alguna carga de trabajo cambia su IP por algún motivo, o si se desplaza, el controlador actualizará sus registros locales de asignaciones de metadatos a IP.

De esta manera, el controlador puede realizar un seguimiento del ciclo de vida completo de la carga de trabajo en función de los metadatos asignados a ella, independientemente de la dirección IP que le haya asignado. El reenvío de paquetes hacia y desde las cargas de trabajo se sigue realizando mediante búsquedas IP, utilizando su dirección IP asignada actualmente. Pero la identidad de esa carga de trabajo se mantiene mediante sus metadatos asignados, independientemente de a qué segmento de red está asignado.

La identificación de una carga de trabajo mediante metadatos permite que la identidad de esa carga de trabajo se abstraga completamente de cualquier detalle de red; así es como se debe definir la seguridad moderna. Definir una política que dice algo así como “Ningún servidor SQL en dev puede iniciar contacto con servidores SQL en prod” está mucho más cerca de cómo los usuarios perciben estos recursos que de algo como definir la política para leer como “192.168.10.0/24 TCP 1024-2000 10.10.0.0/16 permiso”. Los términos de metadatos son mucho más legibles para los humanos que los términos de red.

El uso de metadatos para identificar recursos generalmente se conoce como “etiquetas” o “etiquetas”. Y este concepto es utilizado por controladores distintos de SDN. Con Illumio ASP, puede asignar una etiqueta a cada carga de trabajo y cada etiqueta tiene cuatro “dimensiones”: Rol, Aplicación, Entorno y Ubicación. A cada carga de trabajo se le puede asignar una etiqueta que la identifique en una o todas estas dimensiones, y la política se puede definir utilizando esas etiquetas. Entonces, un conjunto de reglas de Illumio no se refiere a puertos o IPs; se refiere a etiquetas.

El valor de las etiquetas Illumio

El concepto de etiquetas puede parecer un detalle menor, pero es digno de enfatizarlo. Mediante el uso de etiquetas, puede definir políticas utilizando los mismos términos en cuanto a la forma en que los usuarios perciben los recursos que se protegen. Este es un cambio significativo con respecto a la forma en que tradicionalmente se define la seguridad de la red. Durante décadas, la seguridad de la red se ha definido en torno a las construcciones de redes: IPs, VLAN y puertos. Los firewalls visualiza la seguridad a través de la lente de estas construcciones de red, y si alguna de estas construcciones cambia, es necesario modificar la configuración del firewall.

Pero si la política se define mediante etiquetas, y estas etiquetas dan como resultado que las capacidades de firewall integradas de la carga de trabajo se configuren para aplicar esta definición en segundo plano, la política ahora coincide con la forma en que se utilizan realmente los recursos. La seguridad de la red ahora se define utilizando lenguaje natural, no lenguaje de red. Y esta política de lenguaje natural se define una sola vez, permaneciendo silenciosa incluso cuando las cargas de trabajo migran a través de las telas de red, se hacen girar hacia abajo o hacia arriba, o se escalan a grandes implementaciones.

La seguridad no debe ser un obstáculo para los requerimientos de escalabilidad de la carga de trabajo. El uso del lenguaje natural para definir políticas (mediante etiquetas) permite la evolución de la carga de trabajo sin que la seguridad ralentiza el proceso de DevOps.

Así que estoy usando etiquetas: ¿Y ahora qué?

Incluso si los equipos de redes se acostumbran a definir políticas utilizando etiquetas de lenguaje natural, con el fin de crear un lenguaje más legible para los humanos, la mentalidad detrás de la definición de políticas sigue estando a menudo centrada en la red. Si bien las etiquetas se referirán a cargas de trabajo y aplicaciones, los equipos de redes siguen pensando en los límites de confianza como límites de red. Pero, a medida que más y más empresas adoptan un Cero Confianza mentalidad, una característica importante requiere que las organizaciones empujen los límites de confianza lejos de la red y directamente a los recursos a los que se refieren las etiquetas. Si tiene cinco cargas de trabajo SQL, cada una de estas cargas de trabajo es su propio límite de confianza. El límite de confianza no es ningún segmento de red común que todos puedan estar compartiendo.

Illumio despliega agentes, conocidos como VENs, en cada carga de trabajo monitoreada, y estos agentes traducen la política basada en etiquetas en reglas en el firewall incorporado en cada carga de trabajo. Entonces, el primer paso en la vida de un paquete, en su nacimiento, es la política. Otra forma de pensar sobre Zero Trust es, “ningún paquete llegará al plano de reenvío de red hasta que haya sido inspeccionado”. Con Illumio, para cuando un paquete llega al plano de reenvío de red, ya se ha aplicado la seguridad.

Esto es especialmente importante cuando se trata de abordar el problema de movimiento lateral, que permite que actores maliciosos o malware atraviesen una red sin ser detectados. Cuando se discuten pautas de seguridad con usuarios remotos, por ejemplo, generalmente se reconoce la necesidad de seguridad, pero una respuesta común es “no tengo nada que ocultar”, que se utiliza como justificación para no molestarse en asegurar una carga de trabajo. Si bien es posible que ese usuario no tenga nada que ocultar, alguien más podría. El malware a menudo rompe una carga de trabajo con el propósito específico de pasar de esa carga de trabajo a otras cargas de trabajo, siendo el destino un recurso más valioso. Esto es movimiento lateral, utilizando una carga de trabajo como plataforma de lanzamiento para otra carga de trabajo.

Si un límite de confianza es un segmento de red y el malware incumple una de varias cargas de trabajo en ese segmento de red, puede moverse lateralmente entre cargas de trabajo que comparten un segmento sin que el firewall de red note nada. Es necesario evitar el movimiento lateral en cada carga de trabajo, no en la estructura de la red.

Las etiquetas son útiles para facilitar la comprensión de las políticas y para mantener el objetivo final en foco: llevar la solución de seguridad hacia lo que está tratando de proteger. No confíe en una capa de una arquitectura de nube para asegurar una capa diferente. Sus límites de confianza están dondequiera que se encuentren sus cargas de trabajo. La confianza cero significa que cada carga de trabajo es un segmento, y si asegura cada carga de trabajo, reducirá drásticamente el riesgo de movimiento lateral.

Para saber más sobre Illumio ASP y cómo pensamos sobre el etiquetado, echa un vistazo a:

• Nuevo video sobre el poder de las etiquetas
• El Guía de diseño de Illumio ASP