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, red), la red fue la más lenta en evolucionar hacia el mundo moderno de 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 centro de datos o arquitectura en la nube. Sin una red, la computación y el almacenamiento son islas inalcanzables. La red permite el acceso y la comunicación entre todos los recursos informáticos y de almacenamiento, entre sí y hacia los usuarios finales de estos recursos. Sin la red subyacente a ninguna arquitectura, todas las conversaciones en la nube carecen de sentido. No importa qué tan lejos abstraiga las conversaciones en la nube sobre los recursos informáticos, desde bare-metal hasta serverless, si hay un paquete IP en cualquier lugar de la imagen, la red es fundamental.

La seguridad de la red ahora se define empleando 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 red. Aún así, se menciona aquí por el simple hecho de que la seguridad en los centros de datos o las implementaciones en la nube se implementaron tradicionalmente en la red. Para 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 red. El software de punto final se puede implementar en recursos informáticos, que generalmente son herramientas basadas en firmas que buscan malware conocido o mal comportamiento, pero generalmente inspeccionan el tráfico, no lo bloquean ni lo permiten. La mayoría de las cargas de trabajo tienen algún tipo de capacidades de firewall integradas, como iptables en Linux, pero la orquestación de estas herramientas a escala a menudo es difícil de gestionar y, por lo tanto, no se usa. Por lo tanto, la seguridad de la red y la aplicación del tráfico se realizan tradicionalmente con firewalls de red.

La seguridad a menudo se define en un idioma diferente

Dado que los firewalls generalmente son gestionados por equipos de red, la política de seguridad se define con mayor frecuencia mediante términos que son familiares para los equipos de redes. Los firewalls existieron durante décadas y la forma en que se configuran cambió mínimamente a lo largo de los años. Las reglas de directiva se escriben tradicionalmente mediante direcciones IP, puertos TCP/UDP, 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 contienen, ya que quieren evitar convertir 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 profundos 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 en sus encabezados de red. Pero debido a que los viejos hábitos tardan en morir, la realidad es que a menudo estos firewalls se configuran a la antigua usanza, y las opciones de próxima generación no se emplean. El resultado es un dispositivo que emplea terminología de red para definir la seguridad de la red, que no es la forma en que los usuarios de recursos alojados en un centro de datos o nube perciben esos recursos. Los usuarios a menudo no saben, o no les importa, en qué segmento de red está alojado un recurso. Se preocupan por el recurso en sí.

La directiva 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 acceder a un recurso alojado en un centro de datos o en la nube, normalmente se referirá a la carga de trabajo o aplicación específica a la que no se puede acceder. Por lo general, no informarán que no se puede acceder a una dirección IP específica a través de un puerto específico. Sin embargo, los equipos de redes u operaciones de seguridad aplicar 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 aplican la política de red. El lenguaje de la aplicación generalmente no es igual al lenguaje de redes.

Un detalle importante en la búsqueda de automatizar tantos recursos como sea posible en las arquitecturas en la nube es la capacidad de definir la política de red empleando los mismos términos que los usuarios perciben que son los recursos que se protegen. Si un firewall aplica una directiva entre las aplicaciones X, Y y Z, debe poder definir una directiva específica para esas aplicaciones y no específica para el recurso de red en el que se hospedan.

Esto es especialmente relevante en las infraestructuras modernas alojadas en la nube pública, como los microservicios, en los 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 modernas de la nube. En cambio, están relegados a sentar en el perímetro de un tejido de nubes, imponiendo solo el tráfico Norte-Sur, ciego a la mayoría del tráfico Este-Oeste.

Defina la seguridad mediante metadatos, no IP

La mayoría de los controladores SDN modernos pueden crear lo que equivale a una base de datos local de IP de carga de trabajo y metadatos que se aplican 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 direcciones IP de carga de trabajo asignadas a una etiqueta de metadatos de "SQL-Prod" y las segundas cinco direcciones IP de carga de trabajo asignadas a una etiqueta de metadatos de "SQL-Dev". El controlador monitorear esas cargas de trabajo y, si alguna carga de trabajo cambia su IP por cualquier motivo, o si se desactiva, 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 que se le asignan, independientemente de la dirección IP que le asignó. El reenvío de paquetes hacia y desde las cargas de trabajo todavía se realiza mediante búsquedas de IP, empleando su dirección IP asignada actualmente. Pero la identidad de esa carga de trabajo se mantiene mediante sus metadatos asignados, independientemente del segmento de red al que esté asignado.

La identificación de una carga de trabajo mediante metadatos permite que la identidad de esa carga de trabajo se abstraiga por completo de cualquier detalle de red: así es como se debe definir la seguridad moderna. Definir una política que diga algo como "Ningún servidor SQL en desarrollo puede iniciar contacto con servidores SQL en prod" está mucho más cerca de cómo los usuarios perciben estos recursos que algo como definir la política para que se lea como "192.168.10.0/24 TCP 1024-2000 10.10.0.0/16 licencia." Los términos de metadatos son mucho más legibles para el ser humano que los términos de redes.

El uso de metadatos para identificar recursos generalmente se conoce como "etiquetas" o "etiquetas". Y este concepto es empleado 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 directiva se puede definir mediante esas etiquetas. Por lo tanto, un conjunto de reglas de Illumio no se refiere a puertos o IP; se refiere a las etiquetas.

El valor de las etiquetas Illumio

El concepto de etiquetas puede parecer un detalle menor, pero vale la pena enfatizarlo. Con las etiquetas, puede definir la directiva con los mismos términos que los usuarios perciben los recursos que se protegen. Este es un cambio significativo de cómo se define tradicionalmente la seguridad de la red. Durante décadas, la seguridad de la red se definió en torno a construcciones de red: IP, VLAN y puertos. Los firewalls ven 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 directiva 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 directiva ahora coincide con la forma en que se usan realmente los recursos. La seguridad de la red ahora se define empleando lenguaje natural, no lenguaje de red. Y esta política de lenguaje natural se define una vez, permaneciendo silenciosa incluso cuando las cargas de trabajo migran a través de estructuras de red, se reducen o aumentan, o se escalan verticalmente a grandes implementaciones.

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

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

Incluso si los equipos de redes se acostumbran a definir políticas empleando etiquetas de lenguaje natural, para crear un lenguaje más legible para el ser humano, 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 aún piensan en los límites de confianza como límites de red. Pero, a medida que más y más compañías adoptan una mentalidad de confianza cero , una característica importante requiere que las organizaciones alejen los límites de confianza de la red y se dirijan directamente a los recursos a los que se refieren las etiquetas. Si tiene cinco cargas de trabajo de SQL, cada una de estas cargas de trabajo tiene 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 implementa agentes, conocidos como VENs, en cada carga de trabajo monitorear, y estos agentes traducen la política basada en etiquetas en reglas en el firewall integrado 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 en Zero Trust es que "ningún paquete llegará al plano de reenvío de la red hasta que fue inspeccionado". Con Illumio, cuando un paquete llega al plano de reenvío de red, la seguridad ya se aplicó.

Esto es especialmente importante cuando se trata de abordar el problema del movimiento lateral, que permite que los actores maliciosos o el malware atraviesen una red sin ser detectados. Cuando se discuten las 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 usa como justificación para no molestar en proteger una carga de trabajo. Si bien es posible que ese usuario no tenga nada que ocultar, alguien más podría hacerlo. El malware a menudo infringe una carga de trabajo con el propósito específico de saltar de esa carga de trabajo a otras cargas de trabajo, siendo el destino un recurso más valioso. Este es el movimiento lateral, empleando 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 infringe una de varias cargas de trabajo en ese segmento de red, puede mover lateralmente entre cargas de trabajo que comparten un segmento sin que el firewall de red se dé cuenta de nada. El movimiento lateral debe evitar en cada carga de trabajo, no en la estructura de red.

Las etiquetas son útiles para hacer que la política sea más fácil de entender y para mantener el objetivo final en el foco: llevar la solución de seguridad a lo que está tratando de proteger. No confíe en una capa de una arquitectura de nube para proteger una capa diferente. Sus límites de confianza están dondequiera que residan sus cargas de trabajo. Confianza cero significa que cada carga de trabajo es un segmento, y si protege cada carga de trabajo, reducirá significativamente el riesgo de movimiento lateral.

Para obtener más información sobre Illumio ASP y cómo pensamos sobre el etiquetado, consulte:

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