Operacionalización de la confianza cero — Paso 5: Diseñar la política

Esta serie de blogs amplía las ideas introducidas en mi publicación de marzo,”La confianza cero no es difícil... Si eres pragmático.”

En ese post, describo seis pasos para lograr Zero Trust, y aquí me gustaría ampliar uno de esos pasos, a saber, diseñar la política. Te mostraré cómo este paso puede apoyar la implementación de un marco sólido que puede ser utilizado por cualquier practicante de microsegmentación para que sus proyectos sean más exitosos, independientemente del tamaño de la organización.

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

‍

Paso 5: Diseñar la política

En el ultimo mensaje de esta serie, me fijé en “prescribir qué datos se necesitan”. Dentro de este artículo, hice el siguiente punto:

“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 la 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 las cargas de trabajo, los metadatos mínimos fuera de un informe 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”.

En base a esta afirmación, los tres bits clave de datos 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ía de un sistema de registro, como una CMDB, y también información como detalles del proceso de comunicación que se obtiene directamente de la carga de trabajo. '
3. Un mapa de dependencia de aplicaciones (derivado de los elementos 1 y 2) que permite al propietario de una aplicación o a un profesional de segmentación visualizar rápidamente las dependencias ascendentes y descendentes de una aplicación específica.

Poniéndolo todo junto

Entonces ahora ya casi estás listo para construir esa política, pero déjame recordarte 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 deben permitir únicamente el acceso dentro y fuera de las cargas de trabajo que se necesitan para realizar su función de negocio.

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 1 del registro de tráfico:

• Fuente: 10.0.0.1, 10.0.0.2
• Contexto de origen: Servidor 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: nombrado
• Puerto: 53
• Protocolo: UDP
• Acción: Permitir

Conexión 2 del registro de tráfico:

• Fuente: 10.0.0.1,10.0.0.2
• Contexto de origen: Servidor 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: App Server, Aplicación de pagos, Producción, Reino Unido
• Proceso de Destino: tomcat
• Puerto: 8080
• Protocolo: TCP
• Acción: Permitir

Conexión 3 del registro de tráfico:

• Fuente: 10.0.1.5, 10.0.1.6,10.0.1.7
• Contexto de origen: App Server, 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: nombrado
• 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 Web, Aplicación de Pagos, Producción, Alemania
• Destino: 10.0.1.5,10.0.1.6,10.0.1.7
• Contexto de destino: App Server, Aplicación de pagos, Producción, Reino Unido
• Proceso de Destino: httpd
• Puerto: 80
• Protocolo: TCP
• Acción: Permitir

Conexión 5 del registro de tráfico:

• 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: App Server, Aplicación de pagos, Producción, Reino Unido
• Proceso de Destino: httpd
• Puerto: 80
• Protocolo: TCP
• Acción: Permitir

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

Hasta ahora, todo bien.

Ahora, puede mirar el mapa de dependencia de su aplicación para determinar qué flujos realmente desea permitir. Con base en el conocimiento de su aplicación, sabe que los siguientes son flujos requeridos, por ejemplo:

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

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

1. Servidor Web, Pagos, Producción, Alemania -> App Server, Pagos, Producción, Reino Unido en 80/tcp
2. DB Server, Pagos, Producción, Alemania -> App Server, Pagos, Producción, Reino Unido en 80/tcp

El mapa de dependencia de la aplicación que utilizará para crear reglas terminará luciendo así:

Ahora bien, ¿cómo expresa realmente estas reglas? Con los firewalls tradicionales, se vería obligado a definirlos utilizando direcciones IP de origen y destino. Pero hacerlo de esta manera elimina por completo toda la rica información de contexto de la que se ha beneficiado al descubrir estos flujos y, peor aún, significa que este contexto debe ser reinsertado cuando la regla se encuentra en revisión. Además, ¿qué sucede cuando agrega un Respondedor DNS adicional o un nuevo App Server o Web Server para la aplicación de pagos?

Tengamos en cuenta que está tratando de construir una política que se adhiera a los principios de confianza cero, es decir, asegurar que siempre sea de menor 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 de DNS, por ejemplo, querrá que todas las reglas que anteriormente permitían el acceso a/desde él se actualicen para que este acceso ya no sea posible. Esto es exactamente lo que Illumio Motor de computación de políticas (PCE) está destinado a hacer: la política de microsegmentación se define mediante metadatos y, a continuación, el PCE determina qué cargas de trabajo coinciden con los metadatos en ese momento en particular para luego calcular las reglas reales que deben aplicarse en cada carga de trabajo para mantener su postura de seguridad de confianza cero. Cada vez que hay un cambio de contexto, el PCE adapta la política y notifica las cargas de trabajo de las actualizaciones.

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

Regla 1:

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

Regla 2:

• Fuente: App Server, Pagos, Producción, Reino Unido
• Destino: Respondedor DNS, Infraestructura DNS, Producción, Reino Unido
• Servicio de Destino: 53/udp
• Proceso de Destino: nombrado

Regla 3:

• Fuente: Servidor 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 de Zero Trust? Visita nuestra pagina sobre cómo poner en marcha su estrategia Zero Trust con microsegmentación para obtener información privilegiada.