La proporción de aciertos de caché como métrica de seguridad
Principal Software Engineer, Fastly
La proporción de aciertos de caché (CHR) es una métrica clave de todo sistema que incluya una memoria caché. A menudo es la única métrica y se mide analizando las comprobaciones del contenido que esté almacenado en caché. El cálculo consiste en dividir el número de aciertos de caché entre el número total de comprobaciones de caché. Si cada comprobación puede dar un acierto (contenido encontrado) o un fallo (contenido no encontrado), la proporción es la siguiente:
Hasta ahora, la CHR solo se consideraba una métrica de rendimiento. Es importante prestarle atención porque, cuanto más almacenas en caché, más dinero ahorras y más rápido funciona tu sitio. Un aumento en el porcentaje de proporción de aciertos arroja las siguientes ventajas:
se necesita menos capacidad de hardware en el origen;
se necesita una arquitectura menos compleja en el origen;
se reducen de manera importante los costes de tráfico de salida;
se reduce la latencia al distribuir el contenido desde la caché.
Pero el rendimiento no lo es todo. De hecho, mejorar la CHR también supone grandes ventajas en materia de seguridad que suelen pasar desapercibidas. Por ejemplo, en un estudio reciente,* una persona entrevistada afirmó que los incidentes de seguridad se habían reducido en un 40 % desde que su empresa empezó a distribuir con la CDN de Fastly (puedes leer el estudio completo aquí</u>). Por esa razón, creemos que conviene tratar la CHR como una métrica de rendimiento y seguridad.
La proporción de aciertos de caché como métrica de seguridad
Antes de explicar las formas en que las mejoras en la CHR pueden traducirse en una reducción del riesgo, veamos qué factores pueden poner en peligro la seguridad.
Mayores superficies de ataque
Cuantos más servidores utilices, más puntos críticos tendrás que gestionar. Aunque puedas permitirte el lujo de ampliar en horizontal para satisfacer una demanda de capacidad cada vez mayor y todos los servidores estén protegidos siguiendo las prácticas recomendadas, las probabilidades de que alguien pueda aprovecharse de una vulnerabilidad o un error de configuración aumentan con el número de servidores.
Aplicaciones más complejas
Si no puedes ampliar en horizontal y la escalabilidad del sistema requiere una mayor complejidad, entonces tienes problemas por partida doble, dado que un sistema complejo es más difícil de gestionar y proteger porque tiene más componentes propensos a vulnerabilidades.
Además, las aplicaciones se vuelven más complicadas a medida que aumenta la carga en el origen. Por ejemplo, es posible que necesites equilibrar la carga en varios servidores o añadir réplicas de tu base de datos principal conforme vaya subiendo el tráfico. Si puedes gestionar esta carga en tu CDN en el edge, la capacidad general podrá aumentar con más independencia respecto a la capacidad en el origen y, como resultado, las aplicaciones en el origen serán más simples y seguras.
Modelos de despliegue más complejos
La mayor complejidad de los modelos de despliegue es otro de los riesgos que acechan a tu arquitectura. Esto puede deberse a varios factores, como un mayor número de regiones o zonas de disponibilidad, la compatibilidad con arquitecturas multinube o de nube híbrida y el uso de más servicios en la nube de grandes proveedores, ya sea para la gestión de identidades y accesos (IAM), las bases de datos o las redes de distribución. Cuantas más regiones, zonas y herramientas forman parte de la ecuación, mayor es la complejidad y más recursos de seguridad debes dedicar a estos proveedores y utilidades, y esto aumenta el riesgo de problemas de configuración porque existen más barreras no solo entre las herramientas y tus sistemas de origen, sino también entre una herramienta y otra.
Aunque todos estos elementos aportan una gran seguridad por su cuenta, la interacción que se produce entre ellos dentro de tu lógica siempre supone un riesgo. Nuestra intención no es ponernos catastrofistas, pero si quieres proteger tu sistema, debes saber a qué pueden afectar los riesgos y cómo mitigarlos.
Mayor probabilidad de errores humanos
Más allá de las vulnerabilidades en los propios sistemas, no podemos olvidarnos de los errores humanos. Cuanto mayor es la complejidad de la arquitectura, la cantidad de hardware que se debe mantener o gestionar y el número de procesos que se deben tener en cuenta, más probabilidad hay de que alguien cometa un error. Además, cuanto menos comprensible resulta un sistema, más difícil es diagnosticar, reducir o poner fin a este tipo de riesgo. Si hay que darle muchas vueltas a un problema para solucionarlo, el remedio puede ser peor que la enfermedad. Al fin y al cabo, un grifo que gotea no se arregla cambiando las tuberías de sitio.
Un nivel de complejidad elevado aumenta la probabilidad de errores humanos, lo cual siempre es un riesgo. Puede parecer que todo va bien, pero cuando algo se tuerce, salta la alerta roja y no hay manera de identificar la causa del problema, puedes encontrarte en una situación muy comprometida.
El tiempo de inactividad como problema de seguridad
El tiempo de inactividad afecta negativamente a la seguridad de varias maneras. En primer lugar, los ataques de DDoS se consideran amenazas de seguridad, por lo que la falta de protección frente a ellos es un error de seguridad. En segundo lugar, siempre que se producen interrupciones en los mecanismos de seguridad habituales y hay que acudir a métodos o procesos alternativos con un menor nivel de protección, con el revuelo que ello conlleva, un ataque que se habría interceptado en condiciones normales puede causar estragos. Por último, cada vez que un equipo de SecOps debe ocuparse de detener un ataque de DDoS que debería haberse resuelto de forma automática, sus integrantes desperdician un tiempo muy valioso que podrían estar dedicando a otras tareas y prioridades de la organización.
¿Cómo ayuda la CHR con los problemas de seguridad?
Estas son las ventajas de una mayor CHR:
menor capacidad de hardware y, por tanto, menor superficie de ataque;
aplicaciones y arquitectura con un menor nivel de complejidad;
facilidades para gestionar y mantener la infraestructura en el origen;
transferencia de tráfico del origen a una plataforma resiliente, automatizada y ultrasegura en el edge.
Hay ciertos elementos que aumentan los riesgos, como una gestión complicada del hardware, una mayor complejidad de las aplicaciones, la arquitectura y el despliegue, el uso de sistemas que no siguen una lógica sencilla y el tiempo de inactividad. Un aumento en la CHR es indicativo de una simplificación efectiva del hardware utilizado, una reducción de la complejidad de las aplicaciones, la arquitectura y los despliegues, el uso de sistemas más sencillos que siguen una lógica comprensible y la garantía de más fiabilidad y tiempo de actividad de la mano de un proveedor de CDN que aporta experiencia y capacidad de respuesta.
La CHR no implica seguridad de por sí, pero toda mejora en tu CHR pone de manifiesto que estás avanzando hacia una mayor seguridad del sistema. Las distintas aplicaciones tendrán diferentes topes en cuanto a la CHR y, por ejemplo, habrá contextos complejos en los que apenas se superará el 80 % o 90 %, pero muchos clientes de Fastly alcanzan o rebasan el 95 %, lo cual es todo un logro tanto para la seguridad como para el rendimiento o la reducción de costes.
Ahora que comprendemos la relación que existe entre la seguridad y la CHR, vamos a profundizar en ella y a aprender cómo mejorarla.
La proporción de aciertos de caché, a fondo
Los aciertos y los fallos se contabilizan en positivo, por lo que la CHR está comprendida en un rango que va de 0 a 1. No obstante, suele expresarse como un porcentaje entre el 0 y el 100 %. Cuando la CHR es del 0 %, eso significa que todo es un fallo de caché, por lo que los contenidos se obtienen o se calculan bajo demanda. Cuando la CHR es del 100 %, todo se envía directamente desde la caché.
En líneas generales, las operaciones relacionadas con los fallos consumen más ancho de banda, CPU o ambas, por lo que una CHR elevada suele ser sinónimo de un buen rendimiento del sistema. No obstante, cada aplicación tiene su propia CHR en estado estable que depende de los patrones de acceso y los tiempos de vencimiento de los contenidos. Por ejemplo, es posible que los contenidos a los que se accede con menos frecuencia se expulsen antes de su vencimiento para dejar sitio a otros nuevos. En cualquier caso, la idea es que una CHR elevada agiliza los procesos.
Ejemplo: Proporción de aciertos de caché en estado estable
Veamos lo que ocurre cuando cambia la CHR. Para estos primeros ejemplos, supondremos que las operaciones en caché (aciertos y fallos) se mantienen más o menos igual y que la aplicación se encuentra en un estado estable, por lo que está funcionando con normalidad.
Si la CHR disminuye por cualquier motivo, eso quiere decir que algunos aciertos se han convertido en fallos. Pongamos que una aplicación registra 50 aciertos y 50 fallos por segundo.
En este caso, su CHR sería de 0,5 o, lo que es lo mismo, el 50 %. Si la mitad de los aciertos se convirtieran en fallos, tendríamos 25 aciertos y 75 fallos; es decir, una CHR de 0,25:
¿Cuáles serían los efectos de semejante reducción en la CHR?
Para empezar, los fallos han aumentado en un 50 %. En otras palabras, el origen recibirá un 50 % más de peticiones de contenidos, ya que estos no se han encontrado en la caché, y hará falta utilizar un 50 % más de hardware en el origen.
La pregunta es qué pasaría en caso contrario.
Si la mitad de los fallos se convirtieran en aciertos, la CHR sería del 75 %. El origen recibiría la mitad de peticiones y se usaría un 50 % menos de hardware. Esto también podría traducirse en una arquitectura de software más sencilla y la posibilidad de reducir las zonas de disponibilidad en el origen. La superficie de ataque de la aplicación se reduciría en ambos casos.
La proporción de aciertos de caché como indicador de la protección en el origen
La CHR se puede contemplar como una métrica de la protección de los servidores del origen. Cuanto mayor es la CHR, menos tráfico llega a tu infraestructura con la misma frecuencia de peticiones. Cuando se trata de la protección del origen, solemos pensar en los picos de tráfico, no en los atacantes. Sin embargo, sus ventajas también aportan beneficios en materia de seguridad general.
Al atender las peticiones desde la caché de Fastly en lugar de tu infraestructura, la superficie de ataque se limita a nuestra plataforma, que es más resiliente y se actualiza constantemente con lo último en seguridad.
Proporción baja de aciertos de caché
Si la CHR es baja, eso significa que pasa más tráfico por el origen, lo cual disminuye la protección si se produce un ataque o un pico de tráfico fuera de lo común. Eso puede afectar a la disponibilidad y dar pie a un tiempo de inactividad o, lo que es lo mismo, un riesgo para la seguridad. Sin embargo, una CHR baja también afecta a la protección en estado estable. Atender un mayor volumen de peticiones en el origen implica disponer de más infraestructura e incluso una arquitectura más compleja. Y, como hemos dicho anteriormente, un aumento en la complejidad y la probabilidad de errores humanos supone un riesgo para la seguridad.
Más proporción de aciertos de caché, menos superficie de ataque
La superficie de ataque se reduce a medida que la CHR aumenta porque los aciertos se gestionan por completo en la arquitectura de Fastly; a diferencia de los fallos, cuyos contenidos se deben obtener en el origen. Cuanto mayor es la CHR, mayor es el porcentaje de aciertos y menor es la cifra de peticiones que llegan a tus servidores.
Cómo aumentar la proporción de aciertos de caché
Veamos algunas de las técnicas que permiten mejorar la CHR. Algunas de ellas solo se pueden poner en práctica con Fastly, ya que diseñamos nuestra plataforma desde el primer momento para que almacenara en caché más información que las CDN antiguas. El objetivo es que las organizaciones actuales puedan distribuir más contenidos con una velocidad y una eficiencia superiores para ofrecer una gran experiencia de uso.
Aumentar los TTL para que el contenido se pueda expulsar más tarde
El principal parámetro del que dispones para controlar la duración posible del almacenamiento en caché de un objeto es el TTL o tiempo de vida, que determina durante cuánto tiempo puede Fastly reutilizar el contenido para atender futuras peticiones. Un TTL más corto implicará que tu contenido quedará expulsado antes, por lo que se producirán más fallos de caché y más recuperaciones hasta el origen.
Si crees que tu contenido es demasiado dinámico o cambia demasiado a menudo como para usar un TTL largo, podemos decirte con casi total seguridad que te equivocas (y deberías reservar un rato para hablar con nosotros). Una de las herramientas que ofrecemos para dar cabida al contenido dinámico es Instant Purge.
Usar TTL largos y expulsar contenido cuando cambie con Instant Purge
La API de Instant Purge de Fastly te permite expulsar contenido de tu red bajo demanda y a la velocidad de la luz: una purga a nivel mundial tarda, de media, 150 ms en ejecutarse. Haciendo algo de integración en tu aplicación, podrás sacar partido de TTL muy largos (¿qué tal un año?) incluso en contenido muy cambiante, como respuestas de API o marcadores deportivos en vivo, y verás que puedes almacenar mucho más contenido en caché de lo que pensabas.
Habilitar la protección del origen
La funcionalidad Origin Shield de Fastly permite designar un POP concreto para que actúe como origen de nuestros otros POP, lo cual aumenta en gran medida las posibilidades de encontrar tu contenido en caché, que a su vez reduce la carga en tu origen. Puedes obtener más información sobre la protección del origen aquí →
Ofrecer contenido obsoleto por un tiempo
Si configuras tu servicio de Fastly para que ofrezca contenido obsoleto, el servicio seguirá disponible aun cuando falle el origen.
Elegir una CDN con menos POP pero más potentes y con más almacenamiento
Puede parecer contradictorio, pero cuantos menos POP tenga una CDN, más probable será que cualquiera de ellos disponga del contenido en su memoria caché. A cambio, claro está, cada POP tiene que contar con mucha más capacidad de almacenamiento para poder distribuir un conjunto de contenidos más amplio, y ahí radica uno de los principios clave de la arquitectura de la CDN de Fastly. Puedes obtener más información sobre las ventajas de los POP modernos aquí →
Adoptar otras soluciones de Fastly que se integren con el almacenamiento en caché
Al habilitar Image Optimizer, podrás liberar a tu origen de la lógica de las imágenes y pasarla al edge junto con su transformación y optimización. Este producto se integra a la perfección con la memoria caché de Fastly, lo cual garantiza que, incluso cuando hay una gran variedad de imágenes específicas de dispositivos, sacamos todo el partido al almacenamiento disponible.
Asimismo, está integrado con Instant Purge, de modo que una purga de los originales de alta resolución también purgará las imágenes derivadas de los mismos. Con todo, puedes seguir disfrutando de TTL largos aun en el caso de contenido cambiante.
En nuestras prácticas recomendadas encontrarás información e ideas que te ayudarán a mejorar la cobertura de caché.
¿Qué más puedes hacer para alejar las peticiones de tu origen?
Un atacante concienzudo siempre logrará abrirse paso hasta tu origen. Si trasladas lógica del origen al edge, reducirás aún más la superficie de ataque. Una vez que hayas mejorado la CHR tanto como sea posible, podrás producir contenido sintético con Compute, nuestra plataforma de informática en el edge, para que lleguen todavía menos peticiones al origen.
Cada petición de Compute se ejecuta en un entorno aislado que se crea y se destruye cuando esta entra y sale de la plataforma. Esto limita el alcance de los errores de código o de configuración procedentes de otros usuarios y puede reducir la superficie de ataque. Se trata de una funcionalidad de seguridad muy potente con la que puedes trasladar más lógica a un entorno diseñado para ofrecer un nivel de seguridad imposible de alcanzar en el origen. Por un lado, disfrutas de protección adicional en el origen con más lógica en el edge. Y por otro, esa lógica se ejecuta en un entorno informático más seguro. Puedes obtener más información sobre el desarrollo de aplicaciones modernas en el edge descargando nuestro ebook aquí →
Si pasas tu lógica al edge de Fastly, no solo reducirás la superficie de ataque en el origen, sino que también notarás una mejora de rendimiento. Hace poco lanzamos Core Cache, una API que permite trasladar contenido parcial o sintético generado con Compute a la memoria caché. De esta forma, disfrutas de una mayor seguridad y la baja latencia del contenido almacenado en caché.
*«The Total Economic Impact™ Of Fastly Network Services» es un estudio elaborado por Forrester Consulting a petición de Fastly en julio de 2023.
