Suscríbete para recibir notificaciones de nuevas publicaciones:

Cómo sacamos partido al caos en las oficinas de Cloudflare

2024-03-08

12 min de lectura
Esta publicación también está disponible en English, 繁體中文, Français, Deutsch, 日本語, 한국어 y 简体中文.

En el libro infantil El caracol y la ballena, este regresa tras una aventura imprevista al fin del mundo, y escucha a sus conocidos decirle "¡Cómo pasa el tiempo!" y "¡Cómo has crecido!". Han pasado unos cuatro años desde la última vez que escribimos sobre LavaRand y, durante ese tiempo, la historia de cómo Cloudflare utiliza fuentes físicas de entropía para aumentar la seguridad de Internet ha seguido su camino y siendo fuente de interés para muchos. Lo que inicialmente era una sola especie de fuente física de entropía (las lámparas de lava) ha crecido y se ha diversificado. Queremos ponerte al día sobre la historia de LavaRand. Esta publicación del blog aborda las nuevas fuentes de "caos" añadidas a LavaRand y cómo puedes utilizar ese caos sacándole partido en tu próxima aplicación. Hablaremos de cómo la aleatoriedad pública puede ampliar los casos de uso de la aleatoriedad de confianza pública: imagina no tener que creer en la palabra de los defensores de un "sorteo aleatorio" cuando afirman que el resultado no está manipulado de ninguna manera. Y, por último, explicaremos la encriptación temporalizada (timelock), que es una forma de garantizar que un mensaje no pueda desencriptarse hasta un determinado momento en el futuro.

Harnessing chaos in Cloudflare offices

Orígenes de LavaRand

La entropía procedente de nuestra pared de lámparas de lava de San Francisco lleva mucho tiempo desempeñando un papel en el carácter aleatorio que protege las conexiones establecidas mediante Cloudflare.

Lámparas de lava con cera fluida.

Lava lamps with flowing wax.

Los servidores de Cloudflare gestionan en conjunto más de 55 millones de solicitudes HTTP por segundo, la gran mayoría de las cuales están protegidas mediante el protocolo TLS para garantizar su autenticidad y confidencialidad. A nivel técnico, los protocolos criptográficos como TLS requieren una fuente subyacente de aleatoriedad segura; de lo contrario, las garantías de seguridad se desmoronan.

La aleatoriedad segura utilizada en criptografía debe ser indistinguible, en términos computaciones, de la aleatoriedad "verdadera". Para ello, debe superar pruebas estadísticas de aleatoriedad, y el resultado debe ser impredecible para cualquier adversario limitado por el cálculo, independientemente del número de resultados anteriores que ya haya visto este adversario. La forma típica de conseguirlo es tomar una "semilla" aleatoria e introducirla en un generador de números pseudoaleatorios criptográficamente seguro (Cryptographically Secure PseudoRandom Number Generator, CSPRNG) que puede producir un flujo básicamente infinito de bytes impredecibles previa solicitud. Las propiedades de un CSPRNG garantizan que todos los resultados sean prácticamente indistinguibles de los resultados verdaderamente aleatorios para cualquiera que no conozca su estado interno. Sin embargo, todo esto depende de tener una semilla aleatoria segura para empezar. Consulta esta publicación para obtener más detalles sobre la aleatoriedad real frente a la pseudoaleatoriedad, y esta publicación para ver algunos ejemplos de lo que puede ir mal con una aleatoriedad no segura.

Durante muchos años, los servidores de Cloudflare han dependido de fuentes locales de entropía (como el momento preciso de la llegada de paquetes o de eventos de teclado) para alimentar sus reservas de entropía. Aunque no hay ninguna razón para creer que las fuentes locales de entropía de esos servidores no sean seguras o puedan verse fácilmente en riesgo, queríamos protegernos contra esa eventualidad. Nuestra solución fue crear un sistema en el que nuestros servidores pudieran refrescar periódicamente sus reservas de entropía con elementos verdaderamente aleatorios procedentes de una fuente externa.

Esto nos lleva a LavaRand. Durante mucho tiempo, "Lavarand" ha sido el nombre que se ha dado a los sistemas utilizados para la generación de elementos aleatorios (en primer lugar por Silicon Graphics en 1997). Cloudflare lanzó su instanciación de un sistema LavaRand en 2017. Este sistema recoge entropía que genera la pared de lámparas de lava de nuestra oficina de San Francisco y hace que esté disponible través de una API interna. A continuación, nuestros servidores consultan periódicamente la API para recuperar datos aleatorios frescos de LavaRand e incorporarlos a sus reservas de entropía. Puedes considerar las contribuciones de LavaRand como un condimento que se añade a la mezcla de las reservas de entropía. (Para conocer más detalles técnicos, lee nuestra publicación anterior del blog).

Lámparas de lava en la oficina de Cloudflare en San Francisco.

Lava lamps in Cloudflare’s San Francisco office.

Aumentar el caos en la oficina

Nuestras lámparas de lava de San Francisco llevan años trabajando incansablemente para suministrar entropía fresca a nuestros sistemas, ¡pero ahora tienen hermanos en todo el mundo que les ayudan en su tarea! La variedad de fuentes de entropía que se encuentran en nuestras oficinas y que proceden de ellas ha seguido el crecimiento de Cloudflare. El equipo Places de Cloudflare trabaja duramente para garantizar que nuestras oficinas reflejen los diversos aspectos de nuestros valores y nuestra cultura. Varias de nuestras oficinas más grandes incluyen instalaciones de sistemas físicos de entropía, y son estas instalaciones las que nos hemos esforzado por incorporar a LavaRand con el tiempo. El atractivo tangible y emocionante de estos sistemas reside en que se basan en mecanismos físicos que consideramos intuitivamente aleatorios. Las bolas de "lava" que flotan dentro de las lámparas (las gotas más calientes suben, mientras que las gotas más frías se hunden) nos llaman la atención, del mismo modo que otros sistemas dinámicos impredecibles (y a menudo bellos) captan nuestro interés.

Los imprevisibles péndulos de Londres

Los visitantes de nuestra oficina de Londres pueden ver un pared de péndulos dobles cuyas bellas oscilaciones se traducen en otra fuente de entropía para LavaRand y para la reserva de aleatoriedad de la que se benefician los servidores de Cloudflare.

Primer plano de la instalación de péndulos dobles de la oficina de Cloudflare en Londres.

Close-up of double pendulum display in Cloudflare’s London office.

Para el ojo inexperto, las sombras de los soportes de los péndulos y las proyectadas por los brazos giratorios en la pared trasera podrían parecer caóticas. Si es así, ¡esta instalación debería considerarse un gran éxito! Las diferentes condiciones de luz y esas sombras se suman al caos que se capta de esta fuente de entropía.

Instalación de los péndulos en la oficina de Cloudflare en Londres con condiciones de luz cambiantes.

Double pendulum display in Cloudflare’s London office with changing light conditions.

De hecho, incluso con estos brazos restringidos al movimiento en dos dimensiones, la trayectoria trazada por los brazos es hipnotizantemente variada, y puede demostrarse que es matemáticamente caótica. Incluso si olvidamos la resistencia del aire, la temperatura y el entorno, y suponemos que la mutación es completamente determinista, el movimiento resultante a largo plazo sigue siendo difícil de predecir. En concreto, el sistema es muy sensible a las condiciones iniciales. Este estado inicial (es decir, cómo se pone en movimiento), asociado a un comportamiento determinista, produce una trayectoria única que se traza hasta la detención del péndulo y hasta que el sistema vuelve a ser puesto en movimiento por un empleado de Cloudflare en Londres.

Los fascinantes móviles de Austin

La nueva y magnífica oficina de Cloudflare en Austin, Texas, ha celebrado recientemente el primer aniversario de su apertura. Esta oficina aporta su propia contribución a la entropía física: una instalación de móviles arcoíris translúcidos suspendida sobre la entrada de la oficina de Cloudflare en el centro de Austin. Al girar sobre sí mismos, reflejan la luz cambiante y proyectan dibujos de colores en las paredes que los rodean. La visualización de los móviles colgantes y sus sombras son muy sensibles a un entorno físico que incluye la apertura y cierre de puertas, los cambios de climatización y la luz ambiental. La escena hipnótica y cambiante de este sistema caótico se captura periódicamente y se introduce en el flujo de aleatoriedad de LavaRand.

Instalación de móviles arcoíris en la oficina de Cloudflare en Austin.

Hanging rainbow mobiles in Cloudflare’s Austin office.

Integrar nuevas fuentes en LavaRand

Incorporamos las nuevas fuentes de caos de oficina al sistema LavaRand (que sigue llamándose LavaRand a pesar de incluir mucho más que lámparas de lava) del mismo modo que las lámparas de lava existentes, que ya hemos descrito anteriormente en detalle.

Para resumir, a intervalos repetidos, una cámara capta una imagen del estado actual de la instalación de aleatoriedad. Puesto que el sistema subyacente es realmente aleatorio, la imagen generada tiene un carácter verdaderamente aleatorio. Incluso las sombras y las condiciones cambiantes de la luz contribuyen a generar algo único e impredecible. Hay otro secreto que deberíamos compartir: a un nivel básico, los sensores de imágenes del mundo real suelen ser una fuente de ruido suficiente como para que incluso las imágenes captadas sin quitar la tapa del objetivo puedan funcionar bien como fuente de entropía. Consideramos que este ruido añadido es una adición serendípica al bello movimiento caótico de estas instalaciones.

Primer plano de los móviles arcoíris colgados en la oficina de Cloudflare en Austin.

Close-up of hanging rainbow mobiles in Cloudflare’s Austin office.

Una vez que tenemos una imagen fija que capta el estado de la instalación de aleatoriedad en un momento determinado, calculamos una representación compacta (un hash) de la imagen para obtener un resultado de tamaño fijo de bytes verdaderamente aleatorios.

Proceso de conversión de instalaciones de entropía física en cadenas de bytes aleatorios.

Process of converting physical entropy displays into random byte strings.

A continuación, los bytes aleatorios se utilizan como entrada (junto con la semilla anterior y cierta aleatoriedad de las fuentes de entropía locales del sistema) en una función de derivación de clave (KDF) para calcular una nueva semilla de aleatoriedad que se introduce en un generador de números pseudoaleatorios criptográficamente seguro (CSPRNG) que puede producir un flujo básicamente infinito de bytes impredecibles previa solicitud. Las propiedades de un CSPRNG garantizan que todos los resultados sean prácticamente indistinguibles de los resultados verdaderamente aleatorios para cualquiera que no conozca su estado interno. A continuación, LavaRand expone este flujo de aleatoriedad mediante una sencilla API interna en la que los clientes pueden solicitar nuevos elementos aleatorios.

¿Cómo puedo utilizar LavaRand?

seed = KDF(new image || previous seed || system randomness)
rng = CSPRNG(seed)
…
rand1 = rng.random()
rand2 = rng.random()

Las aplicaciones suelen utilizar elementos aleatorios de una de estas dos variantes: privada y pública.

La aleatoriedad privada se utiliza para generar contraseñas, claves criptográficas, identificadores de usuario y otros valores que siempre deben mantenerse en secreto. Como hemos descrito anteriormente, nuestros servidores solicitan periódicamente nuevos elementos aleatorios privados a LavaRand para ayudar a actualizar sus reservas de entropía. Por ello, ¡la aleatoriedad de LavaRand está básicamente disponible para el mundo exterior! Una forma sencilla de que los desarrolladores accedan a la aleatoriedad privada de LavaRand es utilizar la función getRandomValues de la API Web Crypto de Cloudflare Worker, o utilizar un elemento aleatorio ya creado, como por ejemplo csprng.xyz (source).

La aleatoriedad pública consta de valores aleatorios impredecibles e imparciales que se ponen a disposición de todo el mundo una vez que se publican, y por este motivo no deben utilizarse para generar claves criptográficas. Los números ganadores de la lotería y el lanzamiento de la moneda al comienzo de un acontecimiento deportivo son algunos ejemplos de valores aleatorios públicos. Una moneda de dos caras no sería una fuente imparcial e impredecible de entropía y tendría repercusiones importantes en el mundo de las apuestas deportivas.

Además de ser impredecible e imparcial, también es deseable que la aleatoriedad pública sea digna de confianza, para que los consumidores de la aleatoriedad tengan la seguridad de que los valores se han producido fielmente. Poca gente compraría lotería si creyera que el número ganador va a ser elegido de forma injusta. De hecho, se conocen casos de delitos cometidos por miembros del personal que han subvertido la aleatoriedad pública en beneficio propio, como el de un empleado de la lotería del Estado que cooptó el generador de números aleatorios de la lotería para que sus amigos y familiares ganaran millones de dólares.

Uno de los principales problemas de la aleatoriedad pública es que es necesario confiar en la autoridad que produce los resultados aleatorios. El hecho de confiar en una autoridad conocida como el NIST puede ser suficiente para muchas aplicaciones, pero podría ser problemático para otras (especialmente para las aplicaciones en las que la descentralización es importante).

drand: aleatoriedad pública distribuida y verificable

Para ayudar a resolver este problema de confianza, Cloudflare se asoció en 2019 con otras siete organizaciones independientes y distribuidas geográficamente para formar la Liga de la Entropía a fin de lanzar una baliza de aleatoriedad pública utilizando el protocolo drand (pronunciado di-rand). Cada organización contribuye con su propia fuente única de aleatoriedad a la reserva conjunta de entropía utilizada para sembrar la red drand, y Cloudflare utiliza la aleatoriedad de LavaRand, por supuesto.

Aunque la Liga de la Entropía empezó como una red experimental, con la orientación y el apoyo del equipo de drand en Protocol Labs, se ha convertido en un servicio básico de Internet fiable y listo para la producción, en el que confían aplicaciones que van desde el almacenamiento distribuido de archivos a los videojuegos en línea, pasando por las pruebas con fecha y hora  y la encriptación temporizada (de la que hablaremos más abajo). La Liga de la Entropía también ha crecido, y ahora hay 18 organizaciones de cuatro continentes que participan en la red drand.

Cada una de las balizas de aleatoriedad de la Liga de la Entropía funciona con parámetros distintos, como la frecuencia con que se producen los valores aleatorios y si la aleatoriedad está encadenada (más detalles a continuación). Tienen dos propiedades importantes que contribuyen a su fiabilidad: son descentralizadas y verificables. La descentralización garantiza que uno o dos actores maliciosos no puedan subvertir o sesgar la baliza de aleatoriedad, y la verificabilidad permite que cualquiera compruebe que los valores aleatorios se producen según el protocolo drand y con la participación de un umbral (al menos la mitad, pero normalmente más) de los participantes en la red drand. Así, con cada nuevo miembro, la confianza y fiabilidad de la red drand sigue aumentando.

A continuación te presentamos una breve descripción general de cómo drand consigue estas propiedades utilizando la generación de claves distribuidas y las firmas de umbral. Si deseas información más detallada, consulta nuestra publicación anterior del blog y algunas de las excelentes publicaciones del equipo de drand.

Generación de claves distribuidas y firmas de umbral

Durante la configuración inicial de una baliza drand, los nodos de la red ejecutan un protocolo de generación de claves distribuidas (DKG) basado en el esquema de compromiso de Pedersen, cuyo resultado es que cada nodo posee una "parte" (un par de claves) de una clave de grupo distribuida, que se mantiene fija durante la vida de la baliza. Para utilizar la clave secreta de grupo con algún fin útil, como firmar un mensaje, al menos un umbral de nodos de la red (por ejemplo, 7 de 9) deben participar en la construcción de una firma de umbral BLS. A continuación se muestra la información de grupo de la baliza quicknet ubicada en la red principal drand de la Liga de la Entropía:

(El valor hexadecimal 52db9b... en la URL anterior es el hash de la configuración de la baliza. Visita https://drand.cloudflare.com/chains para ver todas las balizas admitidas por los nodos drand de nuestra red principal).

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/info | jq
{
  "public_key": "83cf0f2896adee7eb8b5f01fcad3912212c437e0073e911fb90022d3e760183c8c4b450b6a0a6c3ac6a5776a2d1064510d1fec758c921cc22b0e17e63aaf4bcb5ed66304de9cf809bd274ca73bab4af5a6e9c76a4bc09e76eae8991ef5ece45a",
  "period": 3,
  "genesis_time": 1692803367,
  "hash": "52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971",
  "groupHash": "f477d5c89f21a17c863a7f937c6a6d15859414d2be09cd448d4279af331c5d3e",
  "schemeID": "bls-unchained-g1-rfc9380",
  "metadata": {
    "beaconID": "quicknet"
  }
}

Los nodos de la red están configurados para trabajar juntos periódicamente (cada 3 s en el caso de quicknet) a fin de producir una firma sobre algún mensaje acordado, como el número de ronda actual y la firma de la ronda anterior (más información a continuación). Cada nodo utiliza su parte de la clave de grupo para producir una firma parcial sobre el mensaje de la ronda actual, y la difunde a otros nodos de la red. Una vez que un nodo tiene suficientes firmas parciales, puede agregarlas para generar una firma de grupo para la ronda determinada.

La firma de grupo de una ronda es la aleatoriedad (en el resultado anterior, el valor de la aleatoriedad es simplemente el hash sha256 de la firma, para las aplicaciones que prefieran un resultado más corto y de tamaño fijo). La firma es impredecible de antemano siempre que un número suficiente (al menos una mayoría, pero puede configurarse para que sea mayor) de los nodos de la red drand sean honestos y no se confabulen. Además, cualquiera puede validar la firma de una ronda determinada utilizando la clave pública de grupo de la baliza. Se recomienda que los desarrolladores utilicen las librerías de cliente drand o la CLI para realizar la verificación de cada valor obtenido de la baliza.

curl -s https://drand.cloudflare.com/52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971/public/13335 | jq
{
  "round": 13335,
  "randomness": "f4eb2e59448d155b1bc34337f2a4160ac5005429644ba61134779a8b8c6087b6",
  "signature": "a38ab268d58c04ce2d22b8317e4b66ecda5fa8841c7215bf7733af8dbaed6c5e7d8d60b77817294a64b891f719bc1b40"
}

Elementos aleatorios encadenados frente a no encadenados

Cuando la Liga de la Entropía lanzó su primera generación de balizas drand en 2019, el mensaje por ronda sobre el que se calculaba la firma del grupo incluía la firma de la ronda anterior. Esto crea una cadena de rondas de aleatoriedad hasta la primera ronda de "génesis". La aleatoriedad encadenada proporciona algunas propiedades interesantes para las balizas de aleatoriedad de fuente única, y se incluye como requisito en la especificación del NIST para balizas de aleatoriedad públicas interoperables.

Sin embargo, en 2022 el equipo de drand introdujo la noción de aleatoriedad no encadenada, en la que el mensaje a firmar es predecible y no depende de ninguna aleatoriedad de rondas anteriores, y demostró que proporciona las mismas garantías de seguridad que la aleatoriedad encadenada para la red drand (ambas requieren un umbral honesto de nodos). En la implementación de la aleatoriedad no encadenada en la quicknet, el mensaje a firmar consiste simplemente en el número de ronda.

La aleatoriedad no encadenada ofrece eficaces propiedades y mejoras de la facilidad de uso. En términos de usabilidad, un consumidor de la baliza de aleatoriedad no necesita reconstruir la cadena completa de aleatoriedad hasta la ronda de génesis para validar completamente una ronda concreta: la única información necesaria es el número de ronda actual y la clave pública del grupo. Esto ofrece mucha más flexibilidad al cliente, ya que puede elegir con qué frecuencia consume rondas de aleatoriedad sin necesidad de seguir continuamente la cadena de aleatoriedad.

# chained randomness
signature = group_sign(round || previous_signature)

# unchained randomness
signature = group_sign(round)

Puesto que los mensajes a firmar se conocen de antemano (ya que son sólo el número de ronda), la aleatoriedad no encadenada también desbloquea una nueva propiedad especialmente útil: la encriptación temporizada (timelock).

Péndulos dobles giratorios.

Rotating double pendulums.

Encriptación temporizada

La encriptación temporizada (o "liberación temporizada") es un método para encriptar un mensaje de modo que no se pueda desencriptar hasta que haya transcurrido un plazo determinado. Dos enfoques básicos de la encriptación temporizada descritos por Rivest, Shamir y Wagner:

- Utilizar "problemas temporizados", es decir, problemas de cálculo que no puedan resolverse sin hacer funcionar un ordenador de forma continua durante al menos cierto tiempo.

- Utilizar agentes de confianza que prometan no revelar cierta información hasta una fecha determinada.

La utilización de agentes de confianza plantea el problema evidente de garantizar que los agentes sean dignos de confianza. Para atenuar este problema, pueden utilizarse diversos enfoques relativos a la compartición de secretos.

La red drand es un grupo de agentes independientes que utilizan la compartición de secretos para ser dignos de confianza, y el principio de tener "cierta información" que no debe revelarse hasta una fecha determinada ¡se parece mucho a la aleatoriedad por ronda! A continuación describimos cómo puede implementarse la encriptación temporizada sobre una red drand con aleatoriedad no encadenada, y terminamos con una demostración práctica. Aunque no profundizamos en los grupos bilineales y la criptografía basada en emparejamientos que hacen esto posible, si te interesa te animamos a leer la publicación tlock: Practical Timelock Encryption from Threshold BLS, de Nicolas Gailly, Kelsey Melissaris y Yolan Romailler.

Integrar una liberación temporizada en tus secretos

En primer lugar, identifica la ronda de aleatoriedad que, una vez revelada, permitirá descifrar tu mensaje con encriptación temporizada. Una observación importante es que, dado que las redes drand producen aleatoriedad a intervalos fijos, cada ronda de una baliza drand está estrechamente ligada a una marca de tiempo específica (módulo de pequeños retardos de la red para producir realmente la baliza) que puede calcularse fácilmente tomando la marca de tiempo de génesis de la baliza y añadiendo a continuación el número de ronda multiplicado por el periodo de la baliza.

Una vez decidida la ronda, las propiedades de los grupos bilineales te permiten encriptar tu mensaje a alguna ronda con la clave pública de grupo de la baliza drand.

Después de que los nodos de la red drand cooperen para obtener la aleatoriedad de la ronda (en realidad, sólo la firma del número de ronda utilizando la clave secreta de grupo de la baliza), cualquiera puede descifrar el texto cifrado (aquí es donde interviene la magia de los grupos bilineales).

Para que resulte práctico, el mensaje temporizado es en realidad la clave secreta de un esquema simétrico. Esto significa que encriptamos el mensaje con una clave simétrica y encriptamos esta clave con una clave temporal, a fin de permitir un descifrado en el futuro.

ciphertext = EncryptToRound(msg, round, beacon_public_key)

Ahora, para una demostración práctica de la encriptación temporizada, utilizamos una herramienta que uno de nuestros propios ingenieros desarrolló sobre Cloudflare Workers. El código fuente está disponible públicamente si quieres echar un vistazo a su funcionamiento.

random = Randomness(round)
message = Decrypt(ciphertext,random)

¿Y después?

Esperamos que hayas disfrutado revisitando la historia de LavaRand tanto como nosotros, y que te sientas inspirado para visitar una de las oficinas de Cloudflare en el futuro para ver de primera mano las instalaciones de aleatoriedad, y para utilizar la aleatoriedad pública verificable y la encriptación temporizada de drand en tu próximo proyecto.

# 1. Create a file
echo "A message from the past to the future..." > original.txt

# 2. Get the drand round 1 minute into the future (20 rounds) 
BEACON="52db9ba70e0cc0f6eaf7803dd07447a1f5477735fd3f661792ba94600c84e971"
ROUND=$(curl "https://drand.cloudflare.com/$BEACON/public/latest" | jq ".round+20")

# 3. Encrypt and require that round number
curl -X POST --data-binary @original.txt --output encrypted.pem https://tlock-worker.crypto-team.workers.dev/encrypt/$ROUND

# 4. Try to decrypt it (and only succeed 20 rounds x 3s later)
curl -X POST --data-binary @encrypted.pem --fail --show-error https://tlock-worker.crypto-team.workers.dev/decrypt

El caos lo exige la encriptación que protege Internet. LavaRand en Cloudflare seguirá convirtiendo la belleza caótica de nuestro mundo físico en un flujo de aleatoriedad (incluso después de añadir nuevas fuentes) para que le podamos encontrar nuevos usos que nosotros, los exploradores (al igual que ese caracol), ni siquiera hemos aún imaginado.

Y contempló el cielo, el mar, la tierra, las olas, las cuevas y la arena dorada. Miró y miró, asombrado por todo ello. Y le dijo a la ballena: "Me siento tan pequeño".

Un caracol sobre una ballena.

Descubre más noticias, anuncios y debates que invitan a la reflexión. Consulta la página de Security Week.

A snail on a whale.
Protegemos redes corporativas completas, ayudamos a los clientes a desarrollar aplicaciones web de forma eficiente, aceleramos cualquier sitio o aplicación web, prevenimos contra los ataques DDoS, mantenemos a raya a los hackers, y podemos ayudarte en tu recorrido hacia la seguridad Zero Trust.

Visita 1.1.1.1 desde cualquier dispositivo para empezar a usar nuestra aplicación gratuita y beneficiarte de una navegación más rápida y segura.

Para saber más sobre nuestra misión para ayudar a mejorar Internet, empieza aquí. Si estás buscando un nuevo rumbo profesional, consulta nuestras ofertas de empleo.
Security Week (ES)Randomness (ES)LavaRand (ES)

Síguenos en X

Luke Valenta|@lukevalenta
Thibault Meunier|@thibmeu
Cloudflare|@cloudflare

Publicaciones relacionadas

08 de marzo de 2024, 14:05

Log Explorer: monitor security events without third-party storage

With the combined power of Security Analytics + Log Explorer, security teams can analyze, investigate, and monitor for security attacks natively within Cloudflare, reducing time to resolution and overall cost of ownership for customers by eliminating the need to forward logs to third-party SIEMs...