Saltar al contenido principal

Bienvenido a tu nueva red segura

Tarea​

Examinar el lab y cómo está configurado

Por qué​

En este taller, empezaremos con un entorno de lab parcialmente configurado. Hemos creado dos máquinas virtuales. Una representa el servidor de aplicaciones y tiene algunos contenedores docker en ejecución, además de un Cloudflare Tunnel que ya conecta este servidor a nuestra red. La segunda máquina es un escritorio Windows y no tiene nada configurado salvo nuestro device agent instalado y listo para que inicies sesión. Este escritorio simula a un usuario remoto trabajando fuera de la oficina.

También hemos configurado un IdP basado en SAML que tiene un usuario que usaremos durante el taller. Ese usuario es alice@company.com y la contraseña es Savetheinternet!1

Lab architecture

Pasos​

Vamos a ver cómo está configurada la cuenta de Cloudflare y nuestro lab. Abre el dashboard de Cloudflare yendo a labs.cloudflare.com, seleccionando tu lab y haciendo clic en el enlace "Open CF Dashboard" en la barra de navegación superior.

  • Ve a Networks > Connectors
    • Puedes ver que tenemos un tunnel configurado hacia el servidor de aplicaciones. Haz clic en el nombre del tunnel Application Server y selecciona Edit
    • Haz clic en Published application routes y verás que tenemos la intranet en tu dominio apuntando a un contenedor docker que se ejecuta en el servidor y escucha en el puerto HTTP 8000.
    • Haz clic en CIDR y también verás que hemos expuesto la dirección IP del servidor local.
  • Ve a Traffic policies > Resolver policies, haz clic y edita "Application Network"
    • Estamos usando nuestro propio servicio de DNS interno, de forma que cualquier solicitud DNS para el dominio company.internal desde una red o dispositivo conectado a Cloudflare pueda resolverse con tu propio dominio interno alojado en Cloudflare.
    • Baja hasta Step 3 y haz clic en el enlace Manage DNS views, que abrirá una nueva pestaña del navegador
    • Selecciona la pestaña Internal zones y haz clic en la zona company.internal.
    • Aquí puedes ver que solo tenemos un registro A que apunta a la misma dirección IP de nuestro servidor de aplicaciones.
  • Ahora veamos cómo gestionamos el acceso a la intranet. Cierra la pestaña y vuelve a Access controls > Policies.
    • Aquí tenemos políticas centralizadas que podemos usar en muchas aplicaciones y otras áreas. Haz clic en la pestaña Rule groups, selecciona y configura el rule group Employees.
    • Un rule group es un elemento pequeño que se puede usar en muchas políticas. Este define qué es un empleado e incluye a cualquiera que forme parte del grupo all-employees del IdP SAML.
    • Vuelve a la sección Policies y en la pestaña Reusable policies, selecciona View more para la política Employees,
      • Baja hasta Policy details y verás que el rule group Employees está en esta política.
      • Sube un poco y verás en la sección Applications dónde se está usando esta política. No solo para la intranet, sino también para determinar quién puede registrar dispositivos (Warp Login App) y quién puede iniciar sesión en la interfaz web para acceder a todas sus apps. (https://grateful-terminal.cloudflareaccess.com)
      • Haz clic en el botón Configure en la parte superior,
    • La combinación de rule groups y policies permite una combinación muy potente de elementos simples, como un rule group que se combina en políticas complejas con muchos rule groups y otros atributos.
      • Haz clic en Add include y abre el desplegable Selector. Recorre las diferentes formas en que podemos definir una política. Puedes leer más sobre los distintos tipos de selector aquí.
  • Ahora vuelve a Access controls > Applications, selecciona y configura la aplicación Intranet.
    • Esto define la política de acceso para el sitio de la intranet expuesto a través del tunnel.
    • Selecciona la pestaña Policies y podemos ver que, para esta aplicación, se aplica la política Employees. Ahora sabemos que todos los usuarios autenticados que son miembros del grupo all-employees en el IdP tienen acceso a la intranet de la empresa.
    • Cambia a la pestaña Login methods. Ten en cuenta que el acceso a esta aplicación es válido tanto desde el IdP como usando un One Time Pin por email. Exploraremos esto más adelante en el taller.
  • En las políticas que crearemos más adelante, usaremos atributos del dispositivo conectado además del usuario autenticado. Veamos dónde se configuran, navega a Reusable components > Posture checks.
    • Aquí podemos ver los checks de Warp y Gateway. Se usan para comprobar si el tráfico hacia una aplicación o hacia Internet en general viene a través de Cloudflare. Warp comprueba específicamente si ese tráfico proviene de un dispositivo con nuestro agent, en lugar de simplemente tráfico conectado a Cloudflare a través de una conexión de red. Ten en cuenta que muchos de estos posture checks requieren que el device agent esté instalado, ya que es lo que informa a Cloudflare sobre el estado del dispositivo.
    • Como el check Windows firewall enabled, que informa si el firewall de software local está activo en el dispositivo.
    • Haz clic en el check Latest version of Windows, aquí podemos ver un check que podemos usar en una regla que requiere que el dispositivo conectado tenga una versión 10 o superior.
  • Ahora examinemos los controles de acceso para Internet en general. Ve a Traffic policies > Firewall policies > DNS
    • Aquí puedes ver que solo tenemos una política sencilla. Haz clic y edita la política
    • Puedes ver que usa categorías predefinidas, gestionadas por Cloudflare, para asegurar que los usuarios en la red no puedan visitar sitios web peligrosos o inapropiados.
    • Vuelve a Firewall policies y cambia a la pestaña HTTP. Aquí tenemos una regla HTTP coincidente, pero también una regla de isolation que permite el acceso a sitios de redes sociales, pero los ejecuta en nuestro servicio de navegador aislado. Aquí, en lugar de que el sitio de redes sociales se cargue y renderice directamente en el navegador local, ejecutamos un navegador headless en la red de Cloudflare y el sitio se carga ahí, enviando los resultados al navegador del usuario. Esto garantiza que cualquier código malicioso que se ejecute en el navegador solo afecte a una instancia de navegador aislada y segura.
    • A diferencia de las políticas DNS, las políticas HTTP nos permiten inspeccionar el contenido de la solicitud. Por eso, también podemos aprovechar nuestros perfiles DLP para detectar y filtrar ciertos tipos de datos que van hacia y desde aplicaciones web.
      • Navega a Data loss prevention > Profiles. Haz clic y edita AI Prompt: PII.
      • Tenemos perfiles DLP predefinidos, y por ejemplo este coincide con cualquier prompt a un agente de IA que contenga información de identificación personal (PII).

Ahora que hemos visto cómo está configurada esta cuenta de Cloudflare, conectemos el dispositivo de un usuario remoto y comprobemos cómo esta configuración habilita e impacta su acceso.