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

IP 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 reconocerán esto de inmediato. La estructura simple hace que la información sea fácil de consumir y comprender. Es lo que hace que Internet escale y funcione. Y para aquellos que trabajan con él, su jerarquía proporciona información inmediata.

Imagina la alternativa: un mundo donde las personas definen estructuras arbitrarias. ¿Qué pasaría si en un minuto vieras 192.179.134.56.245.23 y al siguiente vieras 24.87? ¿Cómo averiguamos cómo se relacionan entre sí?

Si bien consideramos que la flexibilidad y el libre albedrío son positivos, en el mundo del direccionamiento de red, e igualmente en el etiquetado de la carga de trabajo (especialmente en la microsegmentación), puede generar confusión y complejidad. En última instancia, esto conduce a políticas inconsistentes y problemas similares a los que se experimentan con las políticas de firewall tradicionales.

Durante algunos años, etiquetamos objetos con una amplia gama de atributos para identificar y agrupar activos, lo que una y otra vez causó desafíos con la escala y la capacidad de administración. 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 brindan enormes beneficios operativos sobre el etiquetado de objetos arbitrarios.

En pocas palabras, las etiquetas deben ser fáciles de usar, repetibles, previsibles 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. Cíñete 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, un proveedor de nube, etc.
2. Medio ambiente: ¿Este objeto reside en Producción, Desarrollo o Prueba?
3. Aplicación: ¿Está sirviendo a una aplicación de finanzas, recursos humanos o CRM?
4. Rol: ¿Es un servidor de aplicaciones, un servidor sitio web o una base de datos?

Al ceñirnos 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 también portátil y extensible.

Esta estructura permite a los usuarios pivotar sobre 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 fueran para vehículos y tomaran la forma de "Tipo | Hacer | Modelo | Color", luego 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 de manera más simple para definir el objeto y su propósito principal, no sus relaciones. Apegar 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 informática, hay una gran diferencia entre 'Producción', 'Prod' y 'prod'. Siempre habrá ocasiones en las que se produzcan errores ortográficos y, en un modelo estructurado de 4 dimensiones, es fácil solucionar problemas.

Sin embargo, en un entorno de freestyle suelto, tratando de encontrar el error en "prod.fin.win.UK.CRM.sitio 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 "Producción", 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 conducir a una aplicación de políticas inconsistente o desafíos de compatibilidad.

Se recomienda usar los nombres completos (Producción, Desarrollo y Prueba) a menos que una versión abreviada o un acrónimo sea la nomenclatura de uso común en su organización (como UAT). Un ejemplo tradicional en el que esto puede causar problemas es cuando se crean etiquetas de "Prod" y "Production". Si algunas cargas de trabajo están etiquetadas 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. Mantener consistente en todos los sistemas

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

Si estableció 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 el proyecto de implementación, si descubre que el origen de datos estándar también tiene incoherencias, esta es una oportunidad para solucionarlo y mejorar la calidad de ese origen de datos. Esto es enormemente beneficioso por una gran cantidad 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 la etiqueta teniendo en cuenta a toda la organización ahorrará trabajo si la implementación se expande. Los esquemas de etiquetas más simples son más escalables y compatibles.

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

Cuando necesite diferenciar la directiva entre objetos, emplee 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 a este respecto incluye la política de seguridad, pero también RBAC, reportes, 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 usan puertos y protocolos de servicio similares, como 80/TCP o 443/TCP. Por lo tanto, le recomendamos que emplee un nombre de etiqueta común, como 'Servidor sitio web'. 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 solo cuando las cargas de trabajo requieran una directiva de seguridad diferente. Por ejemplo, Oracle, IBM DB2 y MS SQL Server usan diferentes puertos y protocolos de servicio, y cada uno tiene elementos de política de seguridad únicos, como los flujos de tráfico del clúster. Por lo tanto, se recomienda 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 los servidores de Oracle Enterprise Manager solo accedan a los servidores de Oracle Database y no a los servidores de Sybase.

Cómo puede ayudar Illumio

Illumio Core emplea un diseño multidimensional, con una combinación de cuatro etiquetas que identifican objetos de política. Otros productos que emplean el etiquetado pueden permitirle crear cualquier número de etiquetas. Aunque pueda parecer que esto hace que el etiquetado sea más flexible, da lugar a desafíos que se vuelven más pronunciados con el tiempo.

Si sigue agregando diferentes dimensiones de etiqueta, rápidamente terminará con un modelo unidimensional donde cualquier etiqueta determinada indica una aplicación de directiva única. Una gran analogía con esto es un servicio de directorio, donde se puede crear un nuevo grupo (etiqueta) 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, lo que provoca duplicación. No es raro que exista un escenario en el que haya 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 a un gran número de etiquetas.

A continuación, corresponde a los administradores asociar todos los objetos con todas las etiquetas que necesiten. El resultado de esto es que cada vez que se crea un nuevo objeto, debe etiquetar con una colección cada vez mayor de etiquetas para obtener el acceso requerido. En este escenario, la escalabilidad se vuelve desafiante y la consistencia comienza a fallar.

Muchos de nosotros estuvimos en una situación en la que nuestro acceso no es exactamente el mismo que el de otro afiliado a 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, previsible, repetible y compatible, y la herencia en el diseño de la directiva mejora significativamente la capacidad de administración.

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

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