Bloque 3 — Deploy the Endpoint
Objetivo del Bloque 3
Al finalizar este bloque, el participante comprenderá las diferentes formas de llevar consultas DNS hacia Infoblox Threat Defense y podrá desplegar BloxOne Endpoint para conectar su dispositivo con el servicio.
Además, podrá validar que su endpoint pertenece al scope esperado y que las consultas DNS son evaluadas por la Security Policy asignada específicamente a su entorno de laboratorio.
3.1 De la política al tráfico real
En los bloques anteriores diseñamos una política y entendimos cómo Threat Defense puede tomar una decisión:
Pero todavía falta algo.
Una Security Policy almacenada en el CSP no protege por sí sola a un usuario o dispositivo.
Las consultas DNS que queremos proteger necesitan llegar al punto donde Infoblox Threat Defense pueda evaluarlas.
Por tanto, necesitamos conectar dos mundos:
La pregunta deja de ser solamente: ¿Qué debe hacer nuestra política?
Ahora también debemos preguntarnos:
3.2 Diferentes caminos hacia Infoblox Threat Defense
Endpoint no es la única forma de utilizar Infoblox Threat Defense. Dependiendo de la arquitectura, las consultas DNS pueden incorporarse al servicio de diferentes maneras.
Para este curso consideraremos cuatro caminos principales:
External Network
Una red externa permite identificar consultas que provienen de una ubicación o red conocida.
Este modelo resulta útil cuando queremos aplicar protección al tráfico DNS de una red sin instalar necesariamente un agente en cada dispositivo.
La protección está asociada al origen de red.
DNS Forwarding
La infraestructura DNS existente puede reenviar consultas hacia Infoblox Threat Defense.
En este modelo, el servicio se integra con la arquitectura DNS de la organización y las consultas llegan a Threat Defense a través de los componentes DNS que ya existen.
La protección está integrada al flujo DNS de la infraestructura.
Endpoint
BloxOne Endpoint lleva la protección hasta el dispositivo.
Esto permite aplicar políticas al endpoint incluso cuando el usuario se encuentra fuera de la red corporativa, dependiendo de la arquitectura y configuración utilizada.
La protección acompaña al dispositivo.
Estas opciones no deben entenderse simplemente como: ¿Cuál es mejor?
La pregunta arquitectónica es:
3.3 ¿Por qué utilizaremos Endpoint?
En este curso utilizaremos BloxOne Endpoint para facilitar los laboratorios.
No lo utilizamos porque sea la única forma de implementar Threat Defense. Lo utilizamos porque nos permite proporcionar a cada participante un entorno de experimentación independiente.
Nuestro modelo será:
Cada participante tendrá acceso al Cloud Services Portal (CSP) y podrá crear y modificar las Security Policies necesarias para los ejercicios.
Pero existe una condición fundamental:
Esto nos permitirá experimentar posteriormente con:
Podremos modificar reglas y precedencias sin alterar el comportamiento DNS de los demás participantes.
Volvemos entonces al concepto introducido en el Bloque 2:
3.4 Del scope al Endpoint
Ahora el primer elemento de nuestro modelo deja de ser abstracto.
En el laboratorio:
Cuando un participante modifica su política, no buscamos simplemente comprobar que el CSP aceptó la configuración.
Queremos poder demostrar:
Esto es especialmente importante porque durante los siguientes ejercicios varios participantes estarán utilizando simultáneamente el mismo entorno de Threat Defense.
El scope es lo que nos permite separar sus experimentos.
3.5 Instalado no significa validado
Una instalación exitosa del software no demuestra todavía que la arquitectura esté funcionando correctamente.
Necesitamos validar tres cosas:
Connectivity
El Endpoint puede comunicarse con los servicios necesarios de Infoblox.
Scope
El dispositivo pertenece al grupo o contexto esperado y tiene asignada la Security Policy correcta.
Policy behavior
Las consultas DNS producen el comportamiento esperado de acuerdo con esa política.
Nuestro objetivo será completar una cadena:
Si cualquiera de estos pasos falla, todavía no estamos preparados para utilizar ese endpoint como instrumento de nuestros siguientes laboratorios.
Siguiente paso — Lab 1
Ya entendemos por qué necesitamos llevar el tráfico DNS hasta Threat Defense y por qué el scope es fundamental cuando varios participantes utilizan el mismo entorno.
Ahora vamos a desplegar BloxOne Endpoint y demostrar que el dispositivo está conectado, correctamente identificado y recibiendo la política que le corresponde.