DE{CODE}: Por qué Edge no es un caso Edge

Cuando está en el perímetro, la velocidad, la seguridad y el estado del servidor no pueden ser una idea de último momento. En esta sesión, el vicepresidente de productos de Cloudflare, Sergi Isasi, y el gerente de productos de WP Engine, Pavan Tirupati, analizan por qué tener una mentalidad de vanguardia es esencial para el éxito de cada sitio web que crea o mantiene.

Diapositivas de la sesión

Transcripción de texto completo

PAVAN TIRUPATI : Hola a todos. Gracias por acompañarnos en esta sesión sobre cómo la edad no es realmente un caso extremo. Soy Pavan Tirupati, Gerente de Producto en WP Engine con el equipo de The Outreach, y soy el principal responsable de la seguridad, el rendimiento y la confiabilidad del borde para hacer crecer y empoderar a los clientes de WP Engine.

Y hoy se une a nosotros desde Cloudflare Sergi, vicepresidente de gestión de productos. Sergi, ¿quieres presentarte?

SERGI ISASI : Claro. Gracias por recibirme, Pavan. Y gracias a todos por unirse a nuestra sesión. Entonces, como dijo Pavan, soy vicepresidente de productos para rendimiento de aplicaciones en Cloudflare, centrado en el rendimiento y la confiabilidad de nuestro perímetro. Queremos hacer las cosas rápidas y confiables para todos nuestros clientes. Los productos que cubro son cómo Cloudflare recibe y procesa el tráfico en el perímetro, tanto en la capa 4 como en la 7. Eso incluye nuestro caché, nuestro proxy, espectro FL, tecnología fundamental para Cloudflare como nuestros sistemas DNS, nuestros sistemas de gestión de certificados y nuestro Los sistemas de administración de direcciones IP, y luego también las nuevas aplicaciones perimetrales, el equilibrio de carga, nuestro nuevo producto Sala de espera y nuestros próximos productos Web3.

He estado en Cloudflare durante aproximadamente 4 años y medio. Y de nuevo, feliz de estar aquí hoy.

PAVAN TIRUPATI: Impresionante. Y hoy, tenemos una sesión maravillosa para ustedes mientras profundizamos en qué es exactamente edge y cómo es útil, y como dice el título, por qué edge ya no es un caso edge. La agenda que tenemos para ustedes es profundizar en lo que es edge y cuáles son sus beneficios. Y dados estos tiempos, es fundamental centrarse más en la seguridad.

Y vamos a hablar de algunos ejemplos y hablar de algunas amenazas de seguridad. También veremos cómo Edge será beneficioso para la audiencia que está aquí y para todos los que tienen presencia digital en el mundo. Y también veremos algunos ejemplos específicos que podrían ser beneficiosos para las personas que podrían estar pasando por algunas de estas amenazas y problemas de seguridad.

Así que va a ser emocionante, ingenioso y perspicaz. Entonces, comencemos estableciendo un poco de contexto aquí. Quiero establecer una línea de base de lo que es el borde. Y creo que no es una sorpresa para nadie cuando digo que las empresas están experimentando un cambio hacia una cultura de creación, una que se basa en la capacidad de los desarrolladores para crear y controlar directamente las experiencias digitales.

A medida que los sitios y las aplicaciones pasan de construcciones monolíticas a una arquitectura de microservicios, la capacidad de entregar contenido de diversas fuentes se vuelve cada vez más importante. Y sabemos y entendemos que el borde es parte de Internet que en realidad está más cerca de nuestros usuarios finales, a veces también conocido como la última milla. Pero antes de entrar en detalles, Sergi, quiero aclararle a la audiencia cuál es la ventaja y por qué es crítica.

SERGI ISASI: Claro. Así que hay un viejo dicho en la computación en la nube, que es "la nube es solo la computadora de otra persona". Me gusta mucho este dicho. Significa que es lo mismo que tendría en su computadora de escritorio o portátil, pero es solo que alguien más lo está administrando. Y el borde es exactamente lo mismo, solo que está más cerca del usuario.

¿Por qué es eso importante? Queremos que las cosas estén, en Cloudflare, lo más cerca posible del usuario. Y todo se reduce a esa afirmación que dijiste, que es la última milla. Así que no importa qué tan rápido haga su software, qué tan eficiente pueda hacerlo, incluso si responde a algo, si su software puede ejecutarse en submilisegundos, todavía está obligado a la velocidad de la luz. Y si su software no está en el dispositivo del usuario o lo más cerca posible del usuario, el usuario experimentará esa pequeña latencia. Y a veces esa latencia está bien ya veces es muy, muy discordante para el usuario final. Entonces, el punto es optimizar lo que tiene sentido para estar cerca del usuario final en el borde o lo que está cerca del núcleo.

Y lo que hace Cloudflare es que tratamos de poner todo al límite. Creo que una de las razones por las que me pediste que hiciera este chat es porque posiblemente manejamos una de las redes perimetrales más grandes del mundo y obviamente estamos increíblemente orgullosos de ello. Cloudflare tiene poco más de 10 años y hemos estado construyendo esta red todo este tiempo. Ha crecido para estar en 250 ciudades, 100 países diferentes, con el objetivo, y de hecho hemos logrado este objetivo, de estar dentro de los 50 milisegundos del 95% de los usuarios de Internet en todo el mundo. Y eso, nuevamente, última milla: si podemos estar dentro de los 50 milisegundos, podemos ser mucho más rápidos para cada uno de esos usuarios finales.

La otra parte es conectarse a otras redes. Así que nos conectamos a otras 10 000 redes en todo el mundo, muchos ISP locales, por ejemplo, y luego también operamos nuestra propia red troncal, así que hacemos el backhauling de ese tráfico para cuando necesitemos ir al núcleo o al origen, hacer eso aun más rápido. Terminamos 2021 con un poco más de 100 terabits por segundo de capacidad. Y eso es importante cuando se trata de escalamiento horizontal tanto para aumentos en el tráfico para nuestros clientes como para aumentos de ataques a nuestros clientes y también en nuestra propia red.

Una de las cosas que ha sido interesante acerca de la computación en los últimos 30 o 40 años es su transición, de ida y vuelta, del borde al núcleo y al cliente, dependiendo de dónde tenía sentido y dónde estaba todo el poder de cómputo en ese momento. Entonces, si piensa en todo el camino de regreso a la Internet prepública, tenía mainframes. Tenía mucha potencia de cómputo en el núcleo y muy poca potencia de cómputo en el borde y cantidades realmente pequeñas de ancho de banda para hacer la transición de un lado a otro. Entonces estaba enviando comandos al mainframe y le enviaría los resultados de esos comandos en texto.

Hicimos la transición desde allí a muchos avances en el punto final, por lo que obtuvo muchos clientes pesados: Windows, Microsoft Word, todas esas cosas en las que ahora hizo una gran cantidad de cómputo en el punto final y luego lo envió de vuelta a, por lo general, el core para compartir ese contenido.

A medida que el borde y el núcleo se fortalecieron, comenzó a ver aplicaciones en la nube. Entonces, en lugar de hacer ese cambio en su dispositivo, hizo el cambio en un navegador web y eso se propagó a través de otros dispositivos para compartir. Y esto se volvió realmente importante cuando teníamos dispositivos móviles, especialmente los primeros dispositivos móviles que tenían menos cómputo pero mucho más ancho de banda.

Entonces, ¿por qué es esto crítico? Realmente se trata de las expectativas de velocidad del usuario. Entonces, el usuario siempre quiere una buena experiencia de usuario. Y especialmente hoy en día, la idea de una buena experiencia de usuario es una especie de interacción instantánea. Hago clic en un enlace, presiono un botón, sucede algo y realmente no me importa dónde sucedió. Puede que ni siquiera sepa dónde sucedió, pero quiero que sea rápido.

La otra cosa que ha cambiado es el entorno en el que nos encontramos. Por lo tanto, hay muchos más ataques, en gran parte porque esos dispositivos se han vuelto más poderosos. Y luego vemos muchas regulaciones cambiantes a medida que la seguridad y la privacidad no solo se vuelven una prioridad para los usuarios sino también para los gobiernos. Y es por eso que Cloudflare sigue agregando POP. Vemos más usuarios, vemos más tráfico, vemos más ataques y vemos más casos de uso que podríamos poner al límite y volverlos poderosos para esos usuarios finales.

PAVAN TIRUPATI: Impresionante. ¿Podemos profundizar un poco en el pop? ¿Qué es POP? ¿Y qué ha cambiado en los COP a lo largo del tiempo? Y profundizando específicamente en la implementación de Cloudflare de POP, ¿qué es único?

SERGI ISASI: Así que gracias por traer eso de vuelta. Hablo mucho de COP y debo especificar lo que significa. Es un Punto de Presencia en Internet. Y en el caso de Cloudflare y en la mayoría de los otros casos, cuando escuchas a alguien hablar sobre un POP, lo que significa es una pila de servidores, ubicados en algún lugar, que ejecutan software.

En cuanto a lo que ha cambiado con el tiempo, en realidad es más fácil hablar de lo que ha cambiado que de lo que no. Y vamos a entrar en eso un poco. Así que estamos en nuestra 11ª generación de servidores. Escribimos sobre cada una de esas iteraciones en nuestro blog. Así que seguimos obteniendo computadoras más rápidas en el borde, lo cual es genial. Significa costos más bajos, significa más capacidades, significa simplemente mejores cosas para los usuarios finales.

Una de las cosas interesantes que ha cambiado con el tiempo es que en realidad hemos implementado tres arquitecturas de CPU diferentes, o en realidad dos arquitecturas de CPU diferentes, tres fabricantes. Así que usamos Intel y AMD, y también usamos ARM en nuestro perímetro.

La otra cosa que ha cambiado con el tiempo es que seguimos agregando ubicaciones. No tengo claro cuántos teníamos cuando lanzamos hace más de 10 años. Estaba en el rango de la docena. Pero hay una historia divertida de nuestro CTO que fue uno de los primeros fanáticos de Cloudflare, conocía a nuestros fundadores, pero se negó a unirse a Cloudflare hasta que consiguió un POP cerca de donde estaba en Europa. Él dijo, ¿cuándo se acerca esto? Y luego me uniré.

Nuestras ubicaciones crecieron primero en función de la demanda. Así que ves mucho tráfico en una región, en realidad es menos costoso, en general, colocar hardware en una región y atender el tráfico allí. Así que empezamos a hacer eso al principio.

Una vez que crecimos, comenzamos a ver socios locales o ISP que comenzaron a pedirnos que construyéramos hardware en la región para que las cosas fueran más eficientes para ellos y sus usuarios finales. Así que ese fue un tipo de cambio radical interesante en el mundo de Cloudflare.

Nuestro objetivo original era estar dentro de los 100 milisegundos de los usuarios finales. Y luego nos dimos cuenta de que podíamos hacerlo mejor. Así que ahora tenemos el objetivo de 50 milisegundos. Y no me sorprendería si ves que se reduce aún más a medida que pasan los años.

Lo que no ha cambiado es que, muy pronto, tomamos una decisión única y bastante fatídica: ejecutaríamos el mismo software en todos los servidores perimetrales en todas las ubicaciones. Esto terminó siendo una opción más fácil para la mayoría de nuestros equipos de ingeniería. Sabemos lo que se está ejecutando en cada dispositivo y puede solucionar problemas y ejecutar las cosas de manera un poco más eficiente allí. Algunos de nuestros equipos de ingeniería también tienen mucho más trabajo debido a esto.

Hace que las cosas sean mucho más fáciles de escalar, tanto a largo como a corto plazo. A corto plazo, nos permite mover recursos a diferentes servicios según sea necesario según la carga y lo que esté sucediendo en ese lugar en ese momento. Podemos escalar horizontalmente en cada máquina.

A largo plazo, nos permite decidir de manera proactiva a dónde deben ir las nuevas máquinas porque sabemos que necesitamos ejecutar toda la pila. La otra gran ventaja, para nuestros equipos de ingeniería y específicamente para nuestros equipos de ingeniería de productos, es que tenemos desempeños consistentes en todos los servicios. No nos preocupa que alguna ubicación esté más cerca de ciertos tipos de usuarios y, por lo tanto, sea más rápida y tenga una experiencia diferente. Va a ser consistente en todos los servidores y en todo el mundo.

Y uno de los grandes cambios que hemos tenido, probablemente tenga tres años en este momento, es que ahora permitimos que nuestros clientes ejecuten su código en nuestro perímetro a través de nuestro producto Workers. Y la gran ventaja que existe cuando ese cliente elige implementar su producto, en realidad selecciona la región del mundo. No los obligamos a decir, quiero correr en el oeste de EE. UU. o lo que sea. Su software se implementa en todas las ubicaciones y se ejecuta lo más cerca posible de su globo ocular.

PAVAN TIRUPATI: Genial. Entonces, ¿cómo se compara el borde con el núcleo?

SERGI ISASI: Claro. Así que depende de tu arquitectura. Y para algunas arquitecturas, el borde es el núcleo y el núcleo es el borde. Si solo tienes un lugar, estás haciendo todo a la vez.

Sin embargo, en general, el perímetro será más rápido y más eficiente para la computación y el núcleo es donde se guardan los secretos y la configuración y se envían los datos desde el núcleo hasta el perímetro.

PAVAN TIRUPATI: ¿Y Cloudflare tiene un núcleo? Y si lo hace, ¿cómo se implementa?

SERGI ISASI: Desde el primer día, sí. Y no hablamos mucho de eso. Es un poco interesante. Pero si lo piensas bien, nos fundamos en 2009, por lo que ejecutar todo al límite era increíblemente poco práctico en 2009 y, para algunas cosas, poco práctico ahora.

Entonces, ¿qué ejecutamos en el núcleo? Gestión de la configuración, por lo que tenemos que sacar el software. y tenemos que hacerlo desde algún lugar, por lo que aún impulsamos el software Cloudflare, todas nuestras nuevas versiones, impulsamos nuestro código, todos los días, desde nuestro núcleo hasta nuestro borde. Y luego también ejecutamos la configuración del cliente que aún se comunica con nuestros centros de datos centrales. Y va desde allí hasta el borde. Y en realidad es una historia interesante aquí de WP Engine y nuestro software DNS.

Entonces, en los primeros días, Cloudflare ejecutó PowerDNS, un software de DNS de código abierto. Y comenzamos a desarrollar algo que internamente llamamos RR DNS, nuestro propio software de DNS, en 2013. Y un software muy eficiente. Teníamos algunas zonas que tenían cientos de miles de registros y todo avanzaba relativamente bien con esos requisitos. Y luego apareció WP y dijeron que posiblemente tenemos más de un millón de registros en nuestra zona. Y la velocidad de actualización, por lo que la capacidad de hacer un cambio y llevar eso a nuestro límite, fue increíblemente crítico porque significaba que un cliente se estaba incorporando y que necesitaba tener esa experiencia. Y este fue un caso límite real para nosotros. Así que analizamos eso y dijimos, OK, obviamente necesitamos reelaborar la forma en que administramos nuestro núcleo y enviamos ese tráfico al borde para manejar tanto el tamaño de ese contenido como la velocidad y la frecuencia con la que lo actualiza.

Entonces, en 2016, uno de nuestros ingenieros de DNS, Tom Arnfeld, preguntó si podía sentarse con WP Engine para comprender realmente lo que quería y por qué lo quería, y cómo se vería en 2017 y cómo se vería en 2022, ahora que llevamos cinco años en esto. Entonces, lo que hicimos en 2017 fue reescribir todas las estructuras de datos de nuestro software de DNS para que, a pedido de nuestro director ejecutivo, moviera los datos desde el borde como por arte de magia. Y en realidad fue una de esas cosas en las que teníamos un cliente con una necesidad, queríamos satisfacer esa necesidad, pero tuvimos que repensar cómo movemos los datos desde el núcleo hasta el borde.

Otra cosa que todavía hacemos en el centro es el análisis. Entonces, la telemetría viene desde el borde hasta el núcleo. Nuestros clientes, cuando ven sus análisis, van a un tablero o una API, y todo se sirve desde el núcleo.

Con el tiempo, el tamaño del cliente y la mayor sofisticación de los ataques nos hicieron replantearnos cómo hacíamos la telemetría. Solíamos ejecutar previamente, por ejemplo, todo nuestro software de detección DDoS en el núcleo. Entonces, la telemetría vendría desde el borde, diría el núcleo, eso parece un DDoS, y enviaría datos al borde para mitigar. Eso es suficiente para algunos ataques DDoS, pero para otros, debemos tomar esa decisión en el borde. Así que aumentamos nuestro sistema Gatebot original, que ejecuta el núcleo con un par de sistemas nuevos, a mediados del año pasado, que en realidad se ejecutan en el perímetro y toman decisiones independientemente del núcleo, y luego informan, de modo que se adaptan continuamente al ataque. superficie.

Lo último de lo que hablaré en el núcleo es que hacemos la mayor parte de nuestro aprendizaje automático en el núcleo hoy. Nos apoyamos mucho en el aprendizaje automático para, específicamente, productos de seguridad. Pero queremos hacer más de eso en el borde porque vemos, probablemente, un patrón similar con el sistema DDoS. Así que nos asociamos con NVIDIA para comenzar a ejecutar más de nuestro ML también en el perímetro.

PAVAN TIRUPATI: Sergi, mencionaste DDoS y seguridad. Quiero profundizar un poco en eso, específicamente porque la seguridad es muy crítica. ¿Cuáles son algunas de las tendencias y cosas que estás viendo?

SERGI ISASI: Claro, es un récord un poco roto por nuestra parte, pero los ataques DDoS están rompiendo récords. Batimos ese récord año tras año. La razón de esto es que las botnets en realidad están creciendo en tamaño y aprovechando dispositivos más potentes. Entonces, si piensa en lo rápido que es su teléfono celular ahora o su computadora en comparación con el año anterior, solo tiene sentido que cada vez tengan más y más capacidad para lanzar grandes ataques, por lo que un rendimiento significativo, luchamos contra un Ataque de "2 terabytes por segundo" hace un rato, es el segundo más grande del que hemos oído hablar, y luego también ataques más inteligentes que pueden hacer cosas sin mucho rendimiento, pero tal vez con muchas solicitudes y solicitudes costosas.

Realmente de lo que estamos hablando aquí es de más sofisticación de los ataques. Y la estadística que creo que es más interesante, algo que

de lo que acabamos de hablar es que se mitiga el 8 % del tráfico en nuestro perímetro. Entonces, antes de que hagamos cualquier tipo de regla o algo por el estilo, el 8% simplemente se elimina por completo, lo que significa que, para un cliente que está pensando en hacer seguridad en el perímetro, puede deshacerse rápidamente de muchas transacciones e interacciones con su aplicación. que simplemente no quieren o necesitan porque es una especie de ataque.

PAVAN TIRUPATI: Sí, y en WP Engine, estamos tratando de hacer que Advanced Network, que es una de nuestras ofertas de red, sea predeterminada para todos nuestros clientes para que puedan aprovechar esta capa adicional de seguridad. Y también estamos presenciando un crecimiento nunca antes visto con nuestra oferta de seguridad, GES, que está relacionada, más en sintonía con los clientes que buscan niveles y capas de seguridad adicionales. Y viene con: GES es algo que viene con un firewall de aplicaciones web y Argo Smart Routing.

Pero una cosa que quiero resaltar aquí es que el 65% de los clientes de WP Engine actualmente no están en ninguna de estas redes. Argo Smart Routing y WAF es algo con lo que definitivamente podrían beneficiarse. Entonces, ¿le importaría ampliar un poco la forma en que el enrutamiento inteligente y el WAF funcionan desde la perspectiva de Cloudflare?

SERGI ISASI: Claro. Entonces Argo es un producto muy interesante. Es muy exclusivo de Cloudflare y es algo que es un poco alucinante si no estás tan familiarizado con él. Entonces, Argo toma esa telemetría de la que estaba hablando, la telemetría perimetral, y en realidad busca mejores rutas a través de Internet. Hay un dicho, internamente, es como Waze para Internet, que supongo que funciona. No es mi analogía favorita, pero es razonable.

Porque a veces las rutas son ineficientes y no son consistentes. Entonces, hoy puede ser más rápido ir directo al origen y, a veces, no lo es. A veces, tiene más sentido para nosotros pasar de un borde de Cloudflare a otro para sortear la congestión de Internet.

El gran punto de Argo es que reduce la eficiencia de la última milla tanto desde el usuario hasta el perímetro como desde el perímetro hasta el origen, porque probablemente no esté sirviendo todo su contenido desde el perímetro hoy en día, en un 40 %. Y eso es un aumento masivo básicamente al presionar un botón y no requerir ningún tipo de cambio de código para la aplicación.

PAVAN TIRUPATI: En realidad, eso es bastante perspicaz. Gracias, Sergio. ¿Qué cambios ha visto en su base de clientes? ¿Cuál es el impacto práctico del aumento de los ataques y la superficie real de los ataques?

SERGI ISASI: Entonces, creo que el gran cambio en 2020 y en 2021 es que comenzamos a ver el aumento de los ataques de ransomware y un tipo diferente de ransomware, por lo que no uno que se apoderó del punto final y lo cifró, sino que vamos a atacar. y derribarte si no nos pagas.

En 2020, vimos un poco de eso. En 2021, vimos un aumento pero un cambio de patrón. Y el cambio de patrón fue, en lugar de encontrar un objetivo genéricamente, fue encontrar un objetivo en la misma industria. Entonces, lo interesante es que vimos que muchas empresas de voz sobre IP y teleconferencias fueron atacadas. Tiene sentido, ¿verdad? Entonces, como todos trabajaban más de forma remota, estos servicios eran críticos. Y era importante que tanto los usuarios como los proveedores permanecieran en línea, por lo que el atacante tenía allí un objetivo muy evidente.

Una cosa que sigue siendo cierta es que la inteligencia compartida es importante. Mientras veíamos que todos y cada uno de los clientes eran atacados, veíamos los mismos patrones y el mismo patrón de ataque que se dirigía a esas aplicaciones, lo que hace que sea más fácil para alguien como nosotros que ve ese tráfico, nos facilita el bloqueo.

PAVAN TIRUPATI: Sí, la previsibilidad o los patrones son realmente buenos para comprender los datos, así que lo entiendo. Pero, ¿cómo y dónde deberían pensar los desarrolladores en esta llamada sobre la protección en general? ¿Cuál es el peor de los casos que ha visto en el pasado que puede compartir aquí?

SERGI ISASI: Claro. Entonces, el peor de los casos es un ataque enfocado. Entonces, si alguien realmente quiere desconectarte, es extremadamente difícil manejar ese tipo de atacante motivado. Por lo tanto, es algo a considerar si está ejecutando una aplicación que de alguna manera es controvertida o puede tener algún tipo de enemigo. Y eso es un montón de cosas en estos días.

El ataque que tengo aquí es un ejemplo de que Adidas tuvo 17,2 millones de solicitudes por segundo. Entonces, esto no es rendimiento, es solo una solicitud HTTP legítima real. Estos no fueron amplificados o falsificados. Entonces, este atacante tenía acceso a suficientes dispositivos que podían hacer estas conexiones y hacer que parecieran legítimas, o en realidad, eran legítimas. Ataque extremadamente distribuido. Tuvo cierta concentración en algunas regiones, pero se vio en la gran mayoría de nuestras ubicaciones.

Y el peor de los casos es que la mitigación fuera costosa. Se hizo en la capa 7. Así que tuvimos que aceptar la conexión. Tuvimos que finalizar SSL, por lo que se trata de una serie de apretones de manos que van y vienen, antes de que pudiéramos defendernos e identificar el ataque frente al tráfico legítimo. Entonces, este es el tipo de cosas que, si está tratando de ejecutar esto en un WAF local o algo así, será muy, muy costoso incluso encontrar el tráfico, y mucho menos mitigarlo.

PAVAN TIRUPATI: Genial. Gracias Sergi Siguiendo con la seguridad, durante los tiempos de guerra, como estamos presenciando con Rusia y Ucrania en este momento, se espera un aumento en los ataques cibernéticos. De hecho, la CIA y el FBI han emitido un aviso conjunto sobre la naturaleza destructiva de estos ataques y cuán vulnerables pueden ser los activos y datos críticos durante estos tiempos. Recomiendan que todas las organizaciones, independientemente de su tamaño, adopten una mayor postura de seguridad. Y en WP, también estamos viendo esta tendencia alcista en los ataques.

¿Cuál es su opinión sobre la preparación para eventos como este? ¿Y cómo podemos prepararnos para tales situaciones? Aparte de la guerra entre Rusia y Ucrania, algunos de los otros grandes eventos que me vienen a la mente son el evento Log4shell que presenciamos el año pasado, que afectó a muchas de las aplicaciones en todo el mundo.

SERGI ISASI: Sí, quiero decir, tenemos que responder. Ese es el mundo en el que estamos. Suceden cosas, y suceden cosas realmente terribles, y tenemos que reaccionar ante ellas. En lo que respecta a Ucrania, no podemos compartir mucha información, pero una de las cosas que podemos compartir es que, si bien el tráfico en Ucrania se ha mantenido relativamente constante desde la perspectiva general del usuario, hemos visto que las mitigaciones de firewall aumentan considerablemente.

Así que ha pasado del típico 8 % del que hablamos antes a un 30 % del total de solicitudes. Y eso significa que hay más tráfico de ataque mezclado con el tráfico de usuarios regulares. Y nuevamente, al igual que en el ejemplo anterior, estas son mitigaciones costosas, cosas que deben hacerse en la capa 7 porque es difícil identificarlas de los ataques regulares solo basados ​​en la capa 4.

Hablamos de Log4shell, ese fue probablemente el evento más grande que puedo recordar en mucho tiempo. Así que esto golpeó bastante fuerte a la industria. Recuerdo a muchas personas, tanto en Cloudflare, leyendo la discusión interna, y recuerdo simplemente decir, oh, oh Dios, esto es enorme.

Y era una vulnerabilidad y un software muy común que permitía al atacante insertar algunos caracteres arbitrarios, y luego la presencia de esos caracteres hacía que el software fuera y emitiera una solicitud git para una URL que insertó el atacante. Así que todos estaban revueltos. Es posible que no conozca sus dependencias. Esa es una especie de lección uno, conocer sus dependencias, saber qué software está ejecutando y qué software está ejecutando ese software.

Pero lo más importante fue que hubo muchas hazañas realmente inteligentes aquí. Entonces, cuando estábamos mitigando esto para nuestros clientes, y para sus clientes, teníamos muchas variaciones diferentes de nuestras reglas de firewall que seguían teniendo que implementarse porque había presencia de contenido y diferentes formas de codificar ese contenido.

Una de las cosas que pensé que era lo más interesante de Log4j es que lo vimos en la tubería de registro. Entonces, incluso si pensaba que su aplicación estaba lo suficientemente bloqueada como para no recibir una conexión del mundo exterior, si extraía un evento de registro que tenía estos caracteres, igual iría y haría esa solicitud. Entonces, un simple firewall no fue suficiente.

Edge es importante aquí y muy útil porque le permite tener una forma rápida y fácil de iniciar controles independientemente de si está seguro de si es vulnerable o no. No hay inconveniente en implementar los controles, que es otra razón por la que lo implementamos incluso para nuestros clientes gratuitos. Entonces, el punto de control único es realmente muy útil en ese escenario.

PAVAN TIRUPATI: ¿Y cuáles son algunas de las herramientas o técnicas que están disponibles para que los clientes escalen el tráfico en este escenario?

SERGI ISASI: Claro, para cualquier escenario, tenemos trabajadores en Cloudflare. Esto le permite ejecutar su código en nuestro borde y puede construir lo que quiera y no preocuparse por escalar horizontalmente.

También presentamos un producto, a principios de 2021, llamado Sala de espera. La sala de espera es algo con lo que probablemente estés familiarizado. Ibas a comprar algo y te ponían en una cola para decidir si había suficiente de esa cosa para comprar. También puede funcionar para una aplicación. ¿Puedes conectarte al sitio y tener una buena experiencia? ¿O deberías esperar?

Este es realmente un producto realmente interesante que construimos. Lo construimos en el perímetro y usamos trabajadores de Cloudflare. Y eso fue difícil. Probablemente sea un producto más simple de construir en el núcleo. Ese no es el ADN de Cloudflare. Podemos construir cosas al límite, y realmente estábamos buscando escalar. Si intenta escalar algo en el centro, se vuelve mucho más difícil.

El gran problema que tuvimos cuando estábamos construyendo la sala de espera es compartir el estado. Así que quería que los usuarios tuvieran una experiencia de sala de espera, globalmente. Y estábamos hablando de más de 200 ubicaciones. Eso no es fácil.

Así que te daré un ejemplo. Digamos que hay un concierto aquí en el Área de la Bahía. La mayoría de los compradores de ese concierto estarán en el Área de la Bahía y probablemente se conectarán a nuestro centro de datos de San José. Sin embargo, algunos no lo son. Vas a tener un puñado o un porcentaje de compradores que estarán en todo el mundo que volarán para el concierto o tal vez estén viajando en ese momento.

Entonces, ¿cómo lo haces justo? No puede tener una cola para usuarios en el Área de la Bahía y hay una cola para usuarios en cualquier otra ubicación. Eso nos obligó a pensar cómo podemos compartir el estado a través del borde. Y creo que aquí es donde el futuro va a la vanguardia.

Y usamos nuestro propio producto Durable Objects (puede verlo aquí en la diapositiva) para sincronizar y compartir el estado en todas las ubicaciones. Pero a medida que nosotros, como industria, buscamos resolver más de estos problemas en el perímetro, creo que comenzarán a ver muchos más casos de uso de software en el perímetro donde compartir el estado aún es difícil, y ¿qué hacer? sobre la consistencia, ya sea algo eventual o inmediato? Y creo que ese es el futuro de nuestro software.

PAVAN TIRUPATI: Genial. Gracias Sergi Lo sé, en WP Engine, tenemos esta mentalidad de vanguardia para garantizar que estamos brindando rendimiento y seguridad a nuestros clientes. Sergi, ¿cuáles son tus pensamientos finales o palabras de consejo o principales consideraciones o sugerencias para los desarrolladores en la llamada que están construyendo en el perímetro?

SERGI ISASI: Creo que, en primer lugar, estás construyendo en el lugar correcto. Y en segundo lugar, creo que es ser creativo. Hay muchas cosas que si me hubieran preguntado, hace un año, si podíamos hacerlas en el borde, hubiera dicho, eh, no sé. No me parece. Y hay un ritmo más rápido de innovación que está encontrando aquí y muchos desarrolladores creativos que están pensando en los problemas en los que está pensando y presentando soluciones tanto en el lado del cliente como del producto.

Otra cosa interesante es el tipo de comunicar y compartir. Hemos visto mucho movimiento, particularmente en el desarrollador Discords, de encontrar formas nuevas y creativas de resolver problemas y construir más cosas al límite. Creo que, por último, como complemento de Cloudflare, si hay algo que no puede hacer, busque un administrador de productos de Cloudflare. Envíenos un correo electrónico, búsquenos en Twitter, o lo que sea, y háganos saber lo que está buscando construir y veremos si podemos ayudarlo a construirlo.

PAVAN TIRUPATI: Eso es increíble. Y creo que es justo decir que Edge ya no es un caso de Edge, porque si su enfoque es la seguridad y el rendimiento, entonces Edge es el lugar para estar.

Así que gracias, Sergi, por esas maravillosas palabras sobre edge. Espero que hayan encontrado útil esta sesión. Gracias por tomarse el tiempo y unirse a nosotros. Espero que tengas un buen resto del día.

PRESENTADOR: Y eso es un final para DE{CODE} 2022. Espero que lo haya encontrado inspirador y se vaya con más experiencia en WordPress y nuevas conexiones con la comunidad. Esté atento al contenido grabado en el sitio desde el viernes para ponerse al día con cualquier cosa que se haya perdido o ver un video nuevamente.

Quiero dar las gracias por última vez a nuestros socios patrocinadores: Amsive Digital, Box UK, Candyspace, Draw, Elementary Digital, Illustrate Digital, Kanopi Studios, Springbox, Studio Malt, StrategiQ, WebDev Studios y 10Up. Muchas gracias por donar a nuestra recaudación de fondos DECODE. Realmente apreciamos su generosidad.

Ahora, para todos los que han estado interactuando con nosotros en nuestro Centro de asistentes y nuestras sesiones, elegiremos a los tres ganadores principales y les informaremos cómo pueden reclamar su premio al final de DE{COD}E. Esperamos verlo nuevamente en nuestros eventos futuros, ya sea en persona o virtualmente. Estamos ansiosos por brindarle más información sobre las últimas tendencias de desarrollo de WordPress y cómo puede implementarlas para crear sitios de WordPress más rápido. Eso es todo de mi parte. Muchas gracias por acompañarnos y cuidarse.