5 consejos para simplificar el etiquetado de cargas de trabajo para la microsegmentación

La propiedad intelectual tiene una estructura que todos y cada máquina pueden entender. Si le muestra a alguien un conjunto de números de 4 dimensiones como 192.168.1.254, muchos lo reconocerán de inmediato. La estructura simple hace que la información sea fácil de consumir y entender. Es lo que hace que internet escale y funcione. Y a quienes trabajan con él, su jerarquía proporciona insights inmediatos.

Imagina la alternativa: un mundo donde la gente define estructuras arbitrarias. ¿Y si un minuto viste 192.179.134.56.245.23 y al siguiente viste 24.87? ¿Cómo averiguaremos cómo estos se relacionan entre sí?

Si bien vemos la flexibilidad y el libre albedrío como positivos, en el mundo del direccionamiento de redes, e igualmente en el etiquetado de cargas de trabajo (especialmente en microsegmentación) — puede resultar en confusión y complejidad. En última instancia, esto conduce a políticas inconsistentes y problemas similares a los experimentados con las políticas de firewall tradicionales.

Desde hace algunos años, hemos etiquetado objetos con una amplia gama de atributos para identificar y agrupar activos, lo que una y otra vez ha causado desafíos con escalabilidad y manejabilidad. Sin estructura, crear una arquitectura que pueda perdurar cada vez más se convierte en un problema con el tiempo. En Illumio, identificamos esto temprano y decidimos que la estructura y la simplicidad arroja enormes beneficios operativos sobre el etiquetado arbitrario de objetos.

En pocas palabras, las etiquetas deben ser fáciles de usar, repetibles, predecibles y fáciles de comprender más adelante.

Entonces, con esto en mente, aquí hay 5 consejos para simplificar el etiquetado de las cargas de trabajo:

1. Apegarse a un esquema de etiquetado de 4 dimensiones

Esto funciona clasificando las cargas de trabajo con algunos parámetros dimensionales simples y obvios. Por ejemplo:

1. Ubicación: ¿Dónde se encuentra la carga de trabajo? Esto podría ser un país, una ciudad, en un proveedor de nube, etc.
2. Entorno: ¿Este objeto reside en Producción, Desarrollo o Prueba?
3. Aplicación: ¿Sirve una aplicación de finanzas, RRHH o CRM?
4. Rol: ¿Es un servidor de aplicaciones, un servidor web o una base de datos?

Al apegarnos a los cuatro grupos simples de Rol, Aplicación, Entorno y Ubicación (RAEL), podemos crear un modelo de etiquetado que no solo sea fácil de entender, sino portátil y extensible.

Esta estructura permite a los usuarios pivote en cualquiera de las cuatro etiquetas y usar una sola sección para simplificar el control y reducir el tiempo de computación. Si nuestras etiquetas eran para vehículos y tomaban la forma de “Tipo | Marca | Modelo | Color”, entonces identificar solo BMW o vehículos rojos hace que el ejercicio sea muy simple y rápido.

Y recuerde, el etiquetado de objetos se usa más simplemente para definir el objeto y su propósito principal, no sus relaciones. Apegarse a este principio y usar la política para definir las relaciones, es el camino hacia la felicidad — créeme en esto.

2. Estandarizar en un formato

Aunque podemos ver cosas similares para las redes y la computación, existe una gran diferencia entre 'Producción', 'Prod' y 'prod'. Siempre habrá ocasiones en las que se produzca un error ortográfico, y en un modelo estructurado de 4 dimensiones, es fácil solucionar problemas.

Sin embargo, en un entorno de estilo libre suelto, tratar de encontrar el error en “Prod.Fin.Win.UK.CRM.Web.Bldg1.10” será un proceso largo.

3. Tenga cuidado al acortar los nombres de las etiquetas

Por ejemplo, acorta una etiqueta, como “Producción” a “Prod”, pero no acorta “Base de datos”. El acortamiento inconsistente de los nombres de las etiquetas puede resultar en la duplicación de etiquetas, lo que a su vez puede dar lugar a problemas de soporte o aplicación de políticas inconsistentes.

Le recomendamos que utilice los nombres completos (Producción, Desarrollo y Prueba) a menos que una versión abreviada o acrónimo sea la nomenclatura comúnmente utilizada en su organización (como UAT). Un ejemplo clásico en el que esto puede causar problemas es cuando se crea una etiqueta “Prod” y “Production”. Si algunas cargas de trabajo se etiquetan como 'Prod', las reglas creadas para 'Producción' no se les aplicarán.

Definir un estándar de nomenclatura no es un concepto nuevo, y hay una buena razón para ello.

4. Manténgase consistente en todos los sistemas

Además de la consistencia dentro de su esquema de etiquetado para la microsegmentación, le recomendamos que mantenga la coherencia con fuentes externas de metadatos.

Si ha establecido convenciones de nomenclatura de metadatos, tal vez en su base de datos de administración de configuración (CMDB), convenciones de nomenclatura de host o uso de bloques de direcciones IP, no cree convenciones alternativas para su esquema de etiquetado. Durante su proyecto de implementación, si descubre que su origen de datos estándar también tiene inconsistencias, esta es una oportunidad para abordar esto y mejorar la calidad de ese origen de datos. Esto es enormemente beneficioso por una plétora de razones, y su organización se beneficiará.

Su caso de uso de implementación inicial puede estar limitado a un entorno o aplicación específicos. Sin embargo, estructurar el diseño de su etiqueta teniendo en cuenta a toda su organización ahorrará trabajo si la implementación se expande. Los esquemas de etiquetas más simples son más escalables y soportables.

5. Usar etiquetas para permitir la diferenciación entre objetos

Cuando necesite diferenciar la política entre objetos, utilice etiquetas diferentes. A menudo hay casos en los que puede ser tentador usar etiquetas distintas, pero en realidad no hay diferenciación de políticas, por lo que es innecesario. Y recuerde que la política en este sentido incluye la política de seguridad, pero también RBAC, reporting, control de cambios y otros tipos de políticas.

Teniendo esto en cuenta, use nombres comunes para sus etiquetas siempre que sea posible. Por ejemplo, Apache, Nginx e IIS utilizan puertos y protocolos de servicio similares, como 80/TCP o 443/TCP. En consecuencia, le recomendamos que utilice un nombre de etiqueta común, como 'Web Server'. En la mayoría de los casos, es probable que no necesite escribir políticas diferentes para estos.

Varíe los nombres de las etiquetas sólo cuando las cargas de trabajo requieran una política de seguridad diferente. Por ejemplo, Oracle, IBM DB2 y MS SQL Server utilizan diferentes puertos de servicio y protocolos, y cada uno tiene elementos de política de seguridad únicos, como los flujos de tráfico de cluster. Por lo tanto, le recomendamos asignarles tres etiquetas de rol diferentes a las cargas de trabajo que ejecutan estas aplicaciones. Por ejemplo, esto le permitirá escribir una política específica para permitir que sus servidores Oracle Enterprise Manager solo accedan a sus servidores de base de datos Oracle, y no a sus servidores Sybase.

Cómo puede ayudar Illumio

Núcleo de Illumio utiliza un diseño multidimensional, con una combinación de cuatro etiquetas que identifican objetos de política. Otros productos que utilizan etiquetado pueden permitirle crear cualquier número de etiquetas. Si bien puede parecer que esto flexibiliza el etiquetado, da como resultado desafíos que se vuelven más pronunciados con el tiempo.

Si sigue agregando diferentes dimensiones de etiqueta, terminará rápidamente con un modelo unidimensional en el que cualquier etiqueta determinada indica una aplicación de política única. Una gran analogía con esto es un servicio de directorio, donde se puede crear un nuevo grupo (tag) para cada nuevo requisito y aplicarlo a los usuarios. Estos grupos crecen rápidamente en número y a menudo se asocian con los mismos objetos, causando duplicación. No es raro que exista un escenario donde hay más grupos que usuarios. Del mismo modo, en una solución basada en etiquetas, puede terminar con más etiquetas que objetos con cada objeto asociado con un gran número de etiquetas.

A continuación, corresponde a los administradores asociar todos los objetos con todas las etiquetas que requieren. El resultado de esto es que cada vez que se crea un nuevo objeto, necesita ser etiquetado con una colección cada vez mayor de etiquetas para obtener el acceso requerido. En este escenario, la escalabilidad se convierte en un desafío y la consistencia comienza a fallar.

Muchos de nosotros hemos estado en una situación en la que nuestro acceso no es exactamente el mismo que otro miembro de nuestro equipo, y resulta que nos falta un grupo (o etiqueta). Mediante el uso de un modelo simple de 4 dimensiones, el etiquetado de nuevos objetos es sencillo, predecible, repetible y soportable, y la herencia en el diseño de políticas mejora significativamente la capacidad de administración.

Definir un esquema de etiquetado escalable y consistente requiere un cambio de mentalidad en la forma en que piensa sobre el diseño de políticas, pero una vez entendido, su simplicidad hará que la administración de políticas sea más efectiva.

Para obtener más información sobre cómo pensamos sobre el etiquetado en Illumio, consulte este gran video de nuestro principal evangelista, Natanael Iversen.