Puesta en práctica de Zero Trust – Paso 5: Diseñar la política

Este serial de blogs amplía las ideas introducidas en mi publicación de marzo, "Zero Trust no es difícil... Si eres pragmático".

En esa publicación, describí seis pasos para lograr Zero Trust, y aquí me gustaría ampliar uno de esos pasos, a saber, diseñar la política. Le mostraré cómo este paso puede respaldar la implementación de un marco estable que puede ser empleado por cualquier profesional de la microsegmentación para hacer que sus proyectos sean más exitosos, independientemente del tamaño de la organización.

Antes de comenzar, aquí hay un repaso de los seis pasos:

Paso 5: Diseñar la directiva

En la última publicación de este serial, analicé "prescribir qué datos se necesitan". En este artículo, señalé lo siguiente:

"Uno de los aspectos más importantes de Zero Trust, y no recibe tanta cobertura como debería, es que la implementación efectiva de Zero Trust se basa en el acceso a información de contexto, o metadatos, para ayudar a formular políticas. Por lo tanto, cuando se habla de microsegmentación en el contexto de la protección de cargas de trabajo, los metadatos mínimos fuera de un reporte de tráfico estándar que necesita describen las cargas de trabajo en el contexto de las aplicaciones y entornos de su centro de datos".

Con base en esta afirmación, los tres datos clave que necesitamos son:

1. Eventos de tráfico en tiempo real para las cargas de trabajo que queremos proteger.
2. Datos de contexto para cada carga de trabajo y conexión : esto incluye metadatos asociados con la carga de trabajo que provendrían de un sistema de registro, como una CMDB, y también información como detalles del proceso de comunicación que se origina directamente de la carga de trabajo. '
3. An Mapa de dependencias de aplicaciones (derivado de los elementos 1 y 2) que permite al propietario de una aplicación o al profesional de la segmentación visualizar rápidamente las dependencias ascendentes y descendentes de una aplicación específica.

Poniéndolo todo junto

Así que ahora está casi listo para construir esa política, pero permítanme recordarles los objetivos:

• Desea crear una política de microsegmentación para proteger sus cargas de trabajo.
• Desea que esta política siga los principios de Confianza cero.
• Por lo tanto, las reglas que construya solo deben permitir el acceso dentro y fuera de las cargas de trabajo necesarias para realizar su función empresarial.

Siguiendo con los datos que dije que eran "necesarios", a continuación verá ejemplos de algunas entradas de registro de tráfico que se pueden usar para crear una política:

Conexión de registro de tráfico 1:

• Origen: 10.0.0.1, 10.0.0.2
• Contexto de origen: Servidor sitio web, aplicación de pagos, producción, Reino Unido
• Destino: 192.168.0.1
• Destino: Contexto: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido o Proceso de destino: denominado
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Conexión de registro de tráfico 2:

• Origen: 10.0.0.1,10.0.0.2
• Contexto de origen: Servidor sitio web, aplicación de pagos, producción, Reino Unido
• Destino: 10.0.1.5,10.0.1.6,10.0.1.7
• Contexto de destino: Servidor de aplicaciones, Aplicación de pagos, Producción, Reino Unido
• Proceso de destino: tomcat
• Puerto: 8080
• Protocol: TCP
• Acción: Permitir

Conexión de registro de tráfico 3:

• Fuente: 10.0.1.5, 10.0.1.6,10.0.1.7
• Contexto de origen: Servidor de aplicaciones, Aplicación de pagos, Producción, Reino Unido
• Destino: 192.168.0.1
• Destino: Contexto: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido
• Proceso de destino: denominado
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Conexión 4 del registro de tráfico:

• Fuente: 10.1.0.1,10.1.0.2
• Contexto de origen: Servidor sitio web, Aplicación de pagos, Producción, Alemania
• Destino: 10.0.1.5,10.0.1.6,10.0.1.7
• Contexto de destino: Servidor de aplicaciones, Aplicación de pagos, Producción, Reino Unido
• Proceso de destino: httpd
• Puerto: 80
• Protocol: TCP
• Acción: Permitir

Conexión de registro de tráfico 5:

• Fuente: 10.1.2.1,10.1.2.2
• Contexto de origen: Servidor de base de datos, aplicación de pagos, producción, Alemania
• Destino: 10.0.1.5,10.0.1.6,10.0.1.7
• Contexto de destino: Servidor de aplicaciones, Aplicación de pagos, Producción, Reino Unido
• Proceso de destino: httpd
• Puerto: 80
• Protocol: TCP
• Acción: Permitir

Con esto, puede derivar rápidamente el mapa de dependencias de la aplicación.

Hasta ahora, bien.

Ahora, puede consultar el mapa de dependencias de la aplicación para determinar qué flujos desea permitir realmente. En función del conocimiento de la aplicación, sabrá que los siguientes son flujos necesarios, por ejemplo:

1. Servidor sitio web, Pagos, Producción, Reino Unido -> Respuesta DNS, Infraestructura DNS, Producción, Reino Unido en 53/udp
2. Servidor de aplicaciones, Pagos, Producción, Reino Unido -> Respondedor de DNS, Infraestructura DNS, Producción, Reino Unido en 53/udp
3. Servidor sitio web, Pagos, Producción, Reino Unido -> Servidor de aplicaciones, Pagos, Producción, Reino Unido en 8080/tcp

También sabe que los siguientes dos flujos no se ven bien y, por lo tanto, no deben incluir en sus reglas iniciales:

1. Servidor sitio web, Pagos, Producción, Alemania -> Servidor de aplicaciones, Pagos, Producción, Reino Unido en 80/tcp
2. Servidor de base de datos, Pagos, Producción, Alemania -> Servidor de aplicaciones, Pagos, Producción, Reino Unido en 80/tcp

El mapa de dependencias de la aplicación que usará para crear reglas terminará siendo así:

Ahora, ¿cómo expresas realmente estas reglas? Con los firewalls tradicionales, se vería obligado a definirlos empleando direcciones IP de origen y destino. Pero hacerlo de esta manera elimina por completo toda la información de contexto rica de la que se benefició al descubrir estos flujos y, peor aún, significa que este contexto debe volver a insertar cuando la regla se revisa. Además, ¿qué sucede cuando agrega un Respondedor DNS adicional o un nuevo servidor de aplicaciones o servidor sitio web para la aplicación de pagos?

Tengamos en cuenta que está tratando de crear una política que se adhiera a los principios de Zero Trust, es decir, garantizar que siempre sea el mínimo privilegio. Un enfoque basado en el contexto, con un motor de seguridad adaptativo que hace su magia en segundo plano, facilita exactamente esto. Por lo tanto, al igual que su política se expande para incorporar un nuevo servidor con el contexto existente, también querrá que su política se reduzca cuando retire un servidor. Si retira uno de sus respondedores DNS, por ejemplo, querrá que se actualicen todas las reglas que anteriormente permitían el acceso hacia / desde él para que este acceso ya no sea posible. Esto es exactamente lo que pretende hacer Policy Compute Engine (PCE) de Illumio: la política de microsegmentación se define mediante metadatos y el PCE determina qué cargas de trabajo coinciden con los metadatos en ese momento en individuo para luego calcular las reglas reales que deben aplicar en cada carga de trabajo para mantener su postura de seguridad Zero Trust. Cada vez que hay un cambio de contexto, el PCE adapta la directiva y notifica las cargas de trabajo de las actualizaciones.

Con esto en mente, su política de Confianza cero se reduce a las siguientes reglas:

Regla 1:

• Fuente: Servidor sitio web, Pagos, Producción, Reino Unido
• Destino: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido
• Servicio de destino: 53/udp
• Proceso de destino: denominado

Regla 2:

• Fuente: Servidor de aplicaciones, Pagos, Producción, Reino Unido
• Destino: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido
• Servicio de destino: 53/udp
• Proceso de destino: denominado

Regla 3:

• Fuente: Servidor sitio web, Pagos, Producción, Reino Unido
• Destino: Servidor de aplicaciones, Pagos, Producción, Reino Unido
• Servicio de destino: 8080/tcp
• Proceso de destino: tomcat

Y eso es todo.

¿Listo para dar el siguiente paso en su viaje hacia Zero Trust? Visite nuestra página sobre cómo poner en práctica su estrategia de Zero Trust con microsegmentación para obtener información privilegiada.