Demostración del Producto: Cloudflare Access

Hola, buen día. Gracias por acompañarnos hoy en Cloudflare TV. Yo soy Marianne y hoy me encuentro con Steven Kettlewell, Director de Iniciativas Estratégicas aquí en Cloudflare y Adrián Vattuone, nuestro Ingeniero de Soluciones. Y hoy tenemos un segmento especial, un demo del producto Cloudflare Access. Perfecto. Muchas gracias, Marianne. Como decía, mi nombre es Steven. Yo estoy en el grupo aquí de Cloudflare de Iniciativas Estratégicas. Y como bien mencionaba, Marianne, el propósito del día de hoy es enfocarnos más a una demo para que ustedes puedan ver realmente el producto en acción. Yo solamente les voy a dar una introducción muy, muy breve, alto nivel, para poner un poco en contexto la charla del día de hoy. Y también para comentarles un poquito el tema de tendencias en el mercado como lo estamos viendo actualmente. Y obviamente que nos pueden compartir su experiencia, darnos un poquito de retro de cómo lo han estado sintiendo ustedes también. Pero bueno, hablando un poco así alto nivel, a nivel de introducción, yo creo que la charla realmente se enfoca en... Ya estamos un año después de que empezó la pandemia. Obviamente se incrementó el trabajo desde la casa como un resultado. Pero ahora, ¿qué pasa después? Entonces ahí viene la gran incógnita. ¿Qué vamos a hacer? Y que nos tiene a todos que nos movemos en este medio un poco pensando en cuál va a ser el siguiente paso. Entonces nosotros hemos estado hablando con organismos independientes y obviamente con muchos clientes en la región. Y lo que recuperamos de todo este esfuerzo es que, si bien hay una clara tendencia que obviamente se ve un pico en la gráfica que estoy mostrando aquí, a nivel del trabajo desde casa con la pandemia. Estamos hablando de incremento casi al 60% de la fuerza de trabajo remota. Pues obviamente después del pico viene un periodo de estabilización donde probablemente todo mundo empezamos a entrar ya en un modelo más híbrido, donde mucha de la gente regresa a la oficina conforme se va vacunando y se va pudiendo hacer más interacción cara a cara. Pero la realidad, y eso es lo que vemos del lado de Cloudflare y lo que hemos experimentado a nivel de interacciones con clientes en la región, es que este modelo llegó para quedarse. O sea, obviamente se destapó, digamos, un tabú que había en la región de que no se podía hacer un trabajo productivo desde casa. Y actualmente se ve como que sí hay alguna forma que se puede llegar a este compromiso donde la gente que maneja, digamos, el capital intelectual dentro de las empresas puede seguir trabajando de una forma, si bien no es remota 100%, a lo mejor con cierta flexibilidad. Ahora, en términos de tecnología, pues eso nos pone un tema enorme, un peso enorme encima, ¿no? Que es, bueno, ahora yo había solucionado este tema durante la pandemia de una forma rápida, porque no tuve mucha preparación, mucha antelación para prepararme para este evento. Y ahora viene la gran pregunta de cómo puedo hacer para que esto sea sostenible en el largo plazo, ¿no? Estamos hablando que hacia el 2024, en dos, tres años más, vamos a tener más de la mitad de la fuerza de trabajo de una forma definitiva fuera de la oficina. Y las soluciones que están actualmente implementadas a nivel de tecnología, a nivel de seguridad, no están diseñadas para aguantar ese nivel de tráfico, ¿no? Entonces, un poquito hablando con ustedes mismos, con nuestro público, lo que hemos visto es, hay tres riesgos que son fundamentales, ¿no? Está el tema de la visibilidad. Ahora que la red corporativa realmente es Internet, la gran incógnita es, bueno, ¿cómo puedo volver a construir algún tipo de perímetro cuando mi red ahora es Internet, ¿no? Entonces, tengo un problema muy grande del lado de visibilidad, porque no puedo ver qué están haciendo mis empleados como cuando estaban en la oficina. No puedo saber qué están haciendo a nivel de logs dentro de cada una de las aplicaciones. Tengo un tema de riesgo enorme también, porque una vez que les permito entrar a las aplicaciones, no sé exactamente qué están haciendo con esa información. No sé si hay ciertos archivos que no deberían de tener acceso, que están bajando de alguna forma, no sé, a USBs, etcétera, y eso pues obviamente genera riesgos a nivel de data loss prevention, etcétera. Y por último, hay un tema de complejidad bastante grande, ¿no? Que, como bien dije, el tema fue, este tipo de soluciones se armaron muy sobre la marcha para resolver el problema en la pandemia, pero se hizo una mezcla de tecnologías que probablemente no estaban diseñadas para ser integradas, con tal de resolver el problema de una forma temporal, y ahora es si hay que definirlo de una forma definitiva, ¿no? Entonces, ahí voy a dejar que mi colega Adrián hable un poco más en detalle ahora en el demo, no le voy a robar la oportunidad de darles más detalle de esto, pero, a muy grandes rasgos, eso es lo que vamos a hablar el día de hoy. El tema es, entra el concepto de Zero Trust como la solución para restablecer el perímetro, ya no alrededor de la red corporativa, porque la red corporativa es Internet, sino más bien establecer el perímetro alrededor del individuo. Entonces, si lo quieren ver hasta cierto punto, es como cómo puedo construir un firewall individual para cada persona, y decir qué políticas de acceso tiene Steven, que está en la casa, y Marian, que está en otro sitio geográfico totalmente distinto, y si Marian mañana viaja, por ejemplo, a Europa, y tiene que acceder a la red corporativa desde allá, cómo le puedo dar esa misma política desde un punto centralizado, y que yo pueda configurarla sobre una misma plataforma, independientemente si Marian se está metiendo a un website de Salesforce, por ejemplo, o de Workday, que está en la nube, o está accesando a aplicaciones en la premisa dentro de mi datacenter. Entonces, ese es el gran reto, y específicamente lo que vamos a ver el día de hoy es lo que ven aquí en esta lámina como Secure Access, es la solución de acceso hacia aplicativos no solamente en la nube, sino on-premise, también como mencionaba, y bueno, vamos a estar comentando cómo nos integramos con todo el ecosistema existente de ustedes, a nivel de Identity Providers, etc. Muy rapidito, un caso de éxito. Nosotros somos el mejor caso de éxito que representa, porque hacemos el consumo interno de esta solución. Entonces, les quería hablar del beneficio que ha tenido la solución a nivel de Cloudflare. Básicamente, nuestro propio grupo de IT ha logrado reducir aproximadamente 80% la cantidad de tickets generados por VPN, al reemplazar gran parte de nuestra VPN con el producto que les vamos a estar mostrando el día de hoy. Y para aquellos que están en el público buscando quick wins de cómo entrar al tema de SASE, de Secure Access Service Edge, este es uno principal. O sea, la configuración son no más de 30 minutos para la parte inicial, digamos, de la aplicación, y el beneficio es casi instantáneo. Entonces, con esto lo que pretendemos es reducir la superficie de ataque significativamente, y bueno, con eso a nivel de introducción, paramos y le paso la palabra a mi colega Adrián para que ya veamos la demo como prometimos. Adelante, Adrián. Gracias, Steven. Adrián Batones, Solutions Engineer, parte del equipo de LATAM de Cloudflare. Segundo, vamos a compartir mi pantalla. Antes de mostrarles el demo, una pequeña, tengo solamente dos láminas para compartir en cómo funciona, para que tengamos un entendimiento generalizado de cómo funciona nuestro producto Access. Como la mayoría de ustedes estarán al tanto, tenemos una red que tiene más de 200 POPs globales, y la idea es que el servicio nuestro corre sobre nuestra plataforma. Conceptualmente es lo que se puede llamar un reverse proxy, o en este caso un forward proxy. Nuestra solución se inserta en el medio entre el cliente y la aplicación. No importa si la aplicación es interna o externa. La forma que tenemos para proteger desde el lado de la aplicación, tenemos algo que se llama hoy Cloudflare Tunnel. Lo pueden encontrar, le cambiamos el nombre hace poquito tiempo, en la documentación todavía figura como algo. El nuevo nombre que tenemos es Cloudflare Tunnel. Lo que esto nos permite es un pequeño daemon que corre sobre Linux o Windows, o como un servicio de Windows. Permite crear un túnel saliente desde la aplicación hasta nuestra plataforma, protegiendo completamente el acceso. El túnel se genera desde adentro hacia afuera, o sea que no hay que abrir puertos en el firewall. Es una aplicación muy segura. Se puede compartir esto sin tener ningún tipo de cambios en los firewalls existentes. Del lado del cliente, también las aplicaciones HTTP o HTTPS en este caso, nuestra plataforma genera un proxy y lo que hacemos es enviar la autenticación hacia un IDP, hacia un Identity Provider. Soportamos algunos más que los que están aquí. Esto lo voy a mostrar en el dashboard. Ahora pasando a lo que lanzamos también hará un mes más o menos. En nuestra plataforma tenemos no solamente la habilidad de autenticar usuarios a través de Identity Providers. Ahora también tenemos la habilidad de consultar Endpoint Providers como Carbon Black o CrowdStrike. De la misma forma que hoy se puede autenticar un usuario. Esta es una funcionalidad que tenemos hace bastante tiempo. La plataforma no es nueva. La nueva funcionalidad es también la validación de dispositivos. Y lo que generamos es un JSON Web Token que nos dará acceso a la aplicación que estamos protegiendo. Ahora pasando rápidamente, ahora sí vamos a pasar al demo. La idea del demo es mostrar la experiencia de un usuario. La plataforma está diseñada para ser lo más transparente posible y no obtrusiva para el usuario. Este es el landing page. Se puede customizar. Mis credenciales están calladas, así que no me van a ver escribiendo mi password y mi usuario. Si tenemos más de un método de autenticación no necesitamos reducirlo a solo uno. Podemos tener distintos métodos de autenticación. Lo que van a ver ahora, las credenciales, como dije, están en caché. Así que no me las va a pedir. Esto es el landing page que tenemos. Para el usuario que se lo vea recibe un link para cada una de las aplicaciones que tenga disponibles. Por ejemplo, esto es un portal. Lo que pasó y que fue transparente para el usuario es, sin volver a introducir ningún tipo de autenticación, accedo a la aplicación. Las credenciales pasan en el background transparentemente. No tengo que volver a autenticarme. Otro ejemplo de esto podría ser lo que tenemos como sobre... Esto también es un nuevo servicio que lo voy a mostrar un poco más en detalle. Lo que acaba de ocurrir es, sin volver a autenticarme, estoy validando dentro de un servidor SSH. Como pueden ver, está en Google Cloud. Y de vuelta, tengo 100% de funcionalidad. Es un host de Linux. No tuve que introducir credenciales. La tecnología que usamos en este caso en particular son dos cosas. Una es el rendering del browser. Lo hacemos en nuestra plataforma. Usamos lo que se llama short-lived certificates. Certificados de corta duración para autenticar al usuario dentro de las sesiones SSH. Volviendo al... Volviendo al dashboard, a la plataforma de las aplicaciones, no es necesario utilizar este landing page. Cada una de estas aplicaciones puede ser accesada directamente con su propio URL. Por ejemplo, no necesito al usuario tener que pasar por el landing page. Si no estuviera autenticado, la cadena de autenticación empezaría en este momento y el usuario recibiría todo lo que necesite para poder completar esa autenticación. Ahora, pasando a la... Este era el demo y si tenemos alguna pregunta, Marian, me hace saber si tenemos que volver a mostrarlo. Lo que voy a mostrar en este momento es cómo configurar, cómo se configura nuestra plataforma. Vamos a empezar de atrás para adelante. Lo primero que tenemos que definir es un grupo para saber qué clase de usuarios son los que van a ser autenticados. Tengo definido un grupo, se llama grupo 1. Lo que defino es simplemente qué usuarios van a ser los que van a poder pasar por esta autenticación y puedo agregar excepciones. Como es muy genérico agregar todo lo que te sea arroba .Cloudflare.com, por seguridad hay algunas direcciones que seguramente voy a querer tener restringidas que nunca se puedan autenticar. Podemos agregar más reglas para incluir o más reglas para excepciones también. No tenemos límite en concatenación. Pueden ser todas las que sean necesarias. Podemos seleccionar no solamente los emails, podemos seleccionar por país, por direcciones IP, por certificados, por token. Es muy flexible la plataforma y podemos configurarlo de la forma que lo necesitemos. Una vez que tenemos definidos los grupos, el siguiente paso va a ser configurar la autenticación. Las que soportamos hoy están aquí en la pantalla. Soportamos Azure AD, por ejemplo, Google Suite completo. También soportamos cualquier XAML 2.0, XAML 2.0, tipo de autenticaciones. Es muy simple de configurar. Volviendo a lo que mencionó Steven de los 30 minutos. Para cada una de ellas tenemos una guía paso por paso de cómo configurarlas. Así que es muy simple, por más, no hace falta ser un experto en Azure AD para hacerlo funcionar. Lo mismo si nos pasamos a Google Suite. Tenemos también un paso, una instrucción, un instructivo paso por paso de cómo configurarlo. Una vez que tenemos el grupo para definir los usuarios, el método de autenticación, la nueva funcionalidad que queríamos mostrar es lo que mencionamos de Endpoint Protection. Soportamos Tanyo, SentinelOne, Carbon Black y CloudStrike. De la misma forma que configuramos el IDP, podemos configurar cómo acceder a la plataforma de estos Endpoint Services para que sea una postura antes de llegar al acceso a la aplicación. Ahora pasando a lo que sería la configuración de la aplicación en sí. Vamos a agregar una aplicación. Tenemos dos formas. Lo primero que tenemos que decidir es si es una aplicación que es SaaS o si es una aplicación hosteada por nosotros. No importa si sea on-premise o si sea en algún tipo de cloud, pero no es un servicio de cloud. Vamos a mostrar primero el de SaaS, que es más simple. Elegimos el tipo de aplicación. Soportamos si para la gente del público se encuentran alguna que necesiten y todavía no soportamos, por favor háganos saber. Estamos siempre agregando, como ven, es bastante extensa. Por ejemplo, vamos a elegir Zoom. Lo único que tengo que aplicar es la URL donde está la autenticación y el ID para este service provider en particular. Podemos cambiar el logo y definimos cuáles de los IDPs que configuramos originalmente, cuáles van a estar soportados o no para este tipo de aplicación. Solamente vamos a tener aquí los que los que configuramos previamente. Y también se puede saltear la pantalla. Esta opción es para saltear el landing page para que no aparezca y no pregunte cuál es. Vamos a volver por atrás y ahora lo que voy a hacer es lo mismo pero con una aplicación que esté hosteada por nosotros. El único requerimiento que tenemos es que la aplicación tiene que estar con lo que se llama nube naranja, tiene que estar proxiada al servicio DNS, tiene que ser de Cloudflare. Este es el dominio que tengo. Podemos usar cualquier tipo de host dentro de este dominio y podemos usar cualquier path. Así que no tenemos ninguna restricción sobre si tiene que ser un dominio tiene que ser un path, puede ser una combinación de ambos. Solamente le tenemos que poner un nombre. Podemos definir la duración de esta sesión. Y lo otro, vamos a ponerle un nombre. Vamos a ponerle aquí tiene que ser uno que esté configurado. Elegimos el servicio de autenticación. Vamos al paso siguiente y aquí lo que definimos es quién de los grupos que tengo cuáles son los que voy a habilitar para que puedan usar esta aplicación en particular. Y también podemos customizarlos de la misma forma que creamos este grupo. Podemos empezar a incluir excepciones o a grupos adicionales manualmente. De la misma forma que lo vimos dentro del grupo aquí si hay algo en particular que queremos saltear o que queremos denegar también lo podemos agregar de esta forma. Esto es todo. Esto es todo lo que necesitamos. Ya tenemos la aplicación configurada. Volviendo un poco vamos a mostrar la que tenemos con el SSH porque es la única diferencia que tenemos. Como dije originalmente este es el dominio, este es el host. Este dominio es el que está terminando un Cloudflare Tunnel y está apuntando a esta dirección, a este host que se llama SSHW. Tenemos un logo que es el que le asigné. Gracias a la gente de Wikimedia. Creamos una regla para qué grupos pueden autenticarse en esta aplicación. Son los mismos que ya vimos. Las autenticaciones que están configuradas, que están disponibles para esta aplicación en particular. Y la única diferencia es que tenemos el bránding. A recordarle a la gente que nos está mirando que esta funcionalidad está todavía en modo beta pero funciona muy bien así que lo pueden probar tranquilamente. No sé Mariana si tenemos alguna pregunta. Si no tenía un slide más para compartir. Sí, sí tenemos una pregunta. Dime. ¿Cuál es la diferencia entre manejando un VPN y manejando Access? La diferencia, vamos a volver, vamos a utilizar el slide que estábamos viendo antes. Cuando se usa una VPN tradicional lo que se establece siempre es una conexión de un dispositivo hacia una red. Y se hace, tradicionalmente se utiliza IPsec o algún tipo de encripción en particular que encripta todo el tráfico del dispositivo hasta el servidor de origen. En el caso de Access lo que hacemos es poner frente a la aplicación en sí un proxy que solamente autentica a los usuarios que nosotros aprobamos para que sean autenticados y que también en este caso podemos controlar que el dispositivo que se esté usando sea un dispositivo corporativo. Hacemos lo mismo que sería la comparación sería una VPN sobre Internet, donde el tráfico pasa por Internet pero el servicio está encriptado sobre HTTPS. No sé si eso ayudó a la persona que hizo la pregunta o lo confundió más. Esperemos que haya ayudado pero... ¿Hay alguna otra pregunta, Marian? Sí, gracias, Adrián. Si tienes otra pregunta ¿Cloudflare se puede integrar con Octa? Sí, es una de las opciones y lo podemos mostrar en el dashboard. Por ahí lo hice un poquito rápido pero... Cuando venimos aquí a la parte de autenticación solamente mostré el Azure AD y el Google Suite pero también podemos usar Octa como el autenticador y tenemos una guía en cómo configurarlo paso por paso así que es muy simple, muy sencillo de implementar. ¿Alguna otra pregunta, Marian? Sí, por ahorita no. No sé, Steven, si tienes alguna pregunta. Un punto que quería ver si podíamos ahondar un poquito, Adrián es la parte, veo que en el dashboard está la parte de los logs y como mencionaba yo en la introducción, bueno, es uno de los retos que estamos viendo ahorita a nivel de qué está haciendo cada individuo con las aplicaciones a nivel de acceso. No sé si nos puedes mostrar un poquito más de esa parte. Tenemos tres tipos de logs disponibles. El log de admin es el log de administración de la plataforma en sí. Queda registrado todos los cambios que se hayan hecho en la plataforma. Está tardando un poquito, esperemos. Ahí está. Como pueden ver, cada valor que se cambió queda registrado, se sabe quién lo hizo, de dónde vino, etcétera. Para la parte de access lo que tenemos es a nivel de usuario, qué usuario accedió a qué aplicación y cuándo. O sea, que esto queda registrado por un tema de compliance o lo que sea necesario está disponible. Excelente, excelente. Y bueno, ahí también recalcar el tema de que todo esto que estamos mostrando el día de hoy son políticas que están centralizadas, lo que nosotros llamamos el single pane a nivel de administración en un solo sitio, ¿correcto? En este sentido el público se puede preguntar, bueno, yo ya tengo cierta flexibilidad de control de acceso, sobre un Salesforce puedo enforzar políticas de acceso sobre alguna base de datos en especial que tenga la nube, también tengo algunas políticas de seguridad, pero yo creo que un poquito rescatar acá sería el tema de que esto es una capa que aplica para todos esos a nivel central. Entonces de nuevo el enfoque es más sobre el individuo, sobre qué tipo de servicios y qué tipo de aplicaciones puede accesar cada persona individual. Y si algún día necesito hacer un cambio, si contrato o sale personal de la empresa, pues obviamente ese control se puede realizar de una forma en un solo sitio. No sé Adrián si tú tengas un comentario. Para extender un poco lo que decía Steven, el grupo que mostré que se definía en el dashboard, ese grupo aplica a cualquier aplicación que se agregue, no tengo que volver a crear cualquier IDP que configura la plataforma. Uno de los casos de uso más comunes es cuando tengo algún tercero o alguna otra empresa que tengo algún partner me sale, perdón que no me sale el español, pero alguna empresa que necesito otros usuarios darle acceso temporal a alguna plataforma, se puede crear una autenticación con el IDP de la otra empresa, del partner, y de esa forma poder darle acceso sin tener que controlar usuarios, crear usuarios y administrar usuarios de terceros por ejemplo. Ahí podemos controlarlos con un simple clic, la política desaparece o cuando se expiran las credenciales, se pierde el acceso. Lo que quería tenemos un par de minutos quería mostrar esto tenemos un blog un blog post muy interesante que explica lo que mostré del SSH sobre la terminal volviendo a lo que decía anteriormente lo único que necesitamos es correr el Cloudflare Tunnel está actualizado con el nombre correcto de vuelta lo puede encontrar todavía en la documentación como Argo pero es la misma tecnología lo único que es necesario es configurar el Cloudflare D, que es el nombre del daemon en el servidor se apunta al Tunnel, se genera automáticamente desde adentro hacia afuera hasta nuestra plataforma nuestra plataforma genera la conversión a HTTP para que pueda ser utilizado desde un browser lo que mencionó Steven tenemos logs, report y reportes sobre esto no es necesario configurar nada más en el dispositivo, es solamente un browser lo otro que tenemos que en lo que estamos trabajando es poder hacer lo mismo sobre RDP y así que muy pronto lo vamos a tener disponible y esto significa un cambio de vuelta, nuestra plataforma con más de 100 países más de 200 data centers, el usuario se conecta al más cercano, de la misma forma que el servidor se conecta al más cercano y nosotros nos convertimos de alguna forma en la red corporativa, en el reemplazo a la red corporativa, para cerrar un poco la pregunta original del Zero Trust Para complementar tu, ese mensaje Adrián, un poquito recapitulando el tema que mencioné yo en la introducción a nivel de lo que es SASE, que seguramente todo el público ya conoce, es el concepto este de Secure Access Service Edge que lo han visto mucho a nivel de marketing, al final es un modelo aspiracional, no todo el mundo queremos ir en esa dirección, es un conjunto de herramientas, llámese el CASB, llámese Zero Trust, etc. Entonces, con el propósito un poquito de hoy es enseñarles como se puede iniciar en esa dirección con Quick Wins, digamos siguiendo la tendencia del gran modelo de tener toda la seguridad perimetral como la define un modelo de SASE, pero más bien empezando por puntos de aplicaciones muy específicas que les puedan dar a ustedes también un retorno de inversión que justifique los demás proyectos a su vez, ¿no? Entonces, tomando eso en cuenta, digamos que hoy nos enfocamos a hablar un poco más del tema de Access, seguramente en sesiones posteriores también vamos a estar hablando un poquito más del tema de Gateway, que son las otras soluciones que yo mostré en mi lámina de alto nivel y de Remote Browsing, que digamos son los tres grandes componentes dentro de la solución de Cloudflare a nivel de Zero Trust y bueno, ahí podríamos hablar más detalles de qué pasa con el tráfico del usuario que va hacia Internet, digamos ya no directamente hacia las aplicaciones corporativas y en la nube, sino hacia tráfico de websites, Internet, etc. Entonces yo estoy sentado en mi casa el día de hoy, cómo hace, cómo asegura la empresa que yo no me voy a meter a un website malicioso y que a raíz de eso después yo llegue al modelo híbrido, me vaya a la oficina de Cloudflare aquí en Florida y realiza algún tipo de ataque lateral, el malware que bajó de mi máquina desde algún sitio en Internet. Entonces eso es para darles un preview de lo que puede venir en otra sesión posterior. No sé Adrián si quieres complementar algo para finalizar. Sí, para cerrar lo que decía Steven, la solución se llama Cloudflare One, tiene dos componentes, vimos la parte de access, la otra parte que se llama gateway es la parte del tráfico saliente, sería para proteger el tráfico saliente desde el usuario hacia Internet. Cuando hablamos de access siempre es proteger la entrada hacia las aplicaciones. Excelente, yo creo que con eso nos queda suficiente tiempo para dar las gracias. Por mi parte, mil gracias por el tiempo, por escucharnos y esperamos poderlos apoyar en cualquier tipo de proyecto que tengan activo o cualquier charla que quieran tener adicional en esto, por favor no duden en contactarnos. Mil gracias por el tiempo.