Algunas de las principales preocupaciones de nuestros clientes cuando descubren que cside opera como un proxy son "¿qué pasa si cside se cae?" o "¿añadirá latencia?"
Lo cierto es que diseñamos nuestros productos para distintos niveles de "mal día". Ante un incidente de caída global, la solución más sencilla es la correcta. Al apartarnos del camino, nos aseguramos de que nuestra interrupción no se convierta en la tuya. En este artículo explicaremos en detalle cómo construir un servicio en tiempo de ejecución para maximizar la disponibilidad del cliente.
TLDR:
- Normalmente hacemos los sitios web más rápidos. Esto depende de tus scripts y de cuántos son cacheables. Cside puede implementarse sin añadir latencia alguna dependiendo de la implementación híbrida. Operamos en muchas regiones distintas —este número cambia constantemente, pero al menos 9 ubicaciones geográficas es la norma—. Mientras que hacer proxy cerca del usuario reduce directamente la latencia potencial añadida, tener múltiples ubicaciones nos permite enrutar el tráfico de punto a punto por rutas más rápidas en lugar de las rutas BGP estándar.
- Si cside sufre un incidente, existen múltiples mecanismos de seguridad. Los incidentes rara vez generan impacto en el cliente, y mucho menos una caída real del servicio en tiempo de ejecución.
- Si cside se cae, detenemos el script que enruta tu tráfico a través de nosotros. Al eliminar cside del flujo de tráfico, no habría ningún impacto en el sitio del cliente. Imagina esta arquitectura como un interruptor de hombre muerto virtual.
¿Qué soluciones ofrece cside?
Cside ofrece 3 enfoques para la seguridad de dependencias del lado del cliente:
- Modo Direct - El más sencillo y bastante seguro
Caso de uso: Me importa la seguridad del lado del cliente, necesito algo fácil de explicar al resto del equipo y estoy dispuesto a hacer algunas concesiones para no generar confusión organizativa.
Modelo operativo: permitir que el script se sirva directamente desde fuentes de terceros en las que confío; los scripts en los que no confío reciben el tratamiento de seguridad completo. Los scripts propios se verifican en el lado del cliente y cside los obtiene.
Ventajas: La implementación más sencilla: solo añade un script. (Casi) Sin impacto en el rendimiento: envolver JS en el navegador puede añadir una cantidad insignificante de latencia (milisegundos de un solo dígito). Capacidad para detener acciones de scripts o bloquear por URL, hash o dominio.
Desventajas: No siempre garantiza verificar el mismo payload del script que recibió el usuario, aunque es muy aproximado. Sin mejoras de rendimiento en scripts estáticos u optimizables. Las acciones en el navegador quedan básicamente expuestas, incluso cuando están muy ofuscadas.
Implementación: Añade nuestro script a tu sitio web.
Aun así puedes colocar cside entre los scripts no confiables y el usuario final.
- Modo Gatekeeper - El más seguro
Caso de uso: Soy un objetivo de alto valor y necesito control de seguridad total.
Modelo operativo: todos los scripts de terceros pasan por cside excepto los que yo seleccione; los scripts propios se verifican en el lado del cliente y cside los obtiene.
Ventajas: Visibilidad total. Control total. Mejora de rendimiento en algunos scripts. Sabemos que lo que recibió el usuario es lo que verificamos. No tenemos que lidiar con las limitaciones de los navegadores; tenemos control sobre la entrega del script y visibilidad forense completa.
Desventajas: La palabra "proxy" viene a la mente y genera preocupación, pero a continuación explicamos por qué en este caso no debería importar. En scripts altamente dinámicos puede añadirse latencia. Los scripts estáticos normalmente se entregan más rápido.
Implementación: Añade nuestro script a tu sitio. Marca los scripts en los que confías y que no necesitas que cside sirva. Por defecto, no hacemos gatekeeper de algunos scripts que son incompatibles con ser servidos desde una URL diferente. Modelo operativo: todos los scripts pasan por cside excepto algunos.
- Modo Scan - El más rápido
Caso de uso: No tengo la posibilidad de añadir un script al sitio web.
Modelo operativo: Necesito mantener vigilancia; no puedo realmente añadir nada al sitio, así que la observabilidad es un buen punto de partida.
Ventajas: Económico. Rápido y fácil de configurar. Inteligencia de amenazas de cside recopilada por miles de otros sitios web con miles de millones de visitantes combinados.
Desventajas: Los ataques del lado del cliente son dinámicos; un escaneo estático tiene por diseño menos probabilidades de detectar un ataque. Un ataque muy dirigido podría evitar la detección.
Por qué adoptamos este enfoque
El equipo de cside lleva tiempo en seguridad del lado del cliente, trabajando con distintos proveedores.
Entendemos las limitaciones y contribuimos activamente a organismos de estándares como el W3C para ayudar a hacer técnicamente viable la seguridad del lado del cliente.
Las detecciones del lado del cliente son fáciles de aplicar ingeniería inversa y de eludir por especificación. Los navegadores, a diferencia de la mayoría de los sistemas operativos, no permiten que los proveedores de seguridad tengan más control o prioridad. Lo que hace esencialmente un script de seguridad del lado del cliente es envolver APIs que pueden ser utilizadas por actores maliciosos y monitorizar qué scripts las usan. Desafortunadamente, detecciones demasiado estrictas del lado del cliente podrían romper algunas bibliotecas del lado del cliente. El problema es que no todos los scripts funcionan bien con APIs envueltas.
Al combinar las detecciones en el navegador con las detecciones en nuestro propio motor, creamos un escenario equilibrado que aprovecha lo mejor de todos los mundos. Equilibramos la capacidad de detección con la facilidad de uso, la resiliencia y, en última instancia, damos al cliente la posibilidad de elegir el enfoque.
Por qué cside es diferente de los servicios de "proxy" tradicionales
Cuando la mayoría de la gente piensa en un proxy, inmediatamente piensa en Cloudflare, Akamai, Fastly, etc. Si bien estos son excelentes para CDN de propósito general y protección DDoS, cside.com representa un enfoque fundamentalmente diferente.
En lugar de hacer proxy del tráfico HTTP como los proxies y firewalls tradicionales, controlamos los componentes basados en el navegador y los JavaScripts que el usuario final cargaría en su navegador desde la internet pública al visitar tu sitio web o aplicación web. Esto permite una visibilidad completa de los scripts, ver lo que ve el usuario final y bloquear cualquier intento malicioso de robar o recopilar PII, datos de tarjetas de crédito o IDs de criptobilleteras. Los proxies tradicionales suelen operar bajo un principio de todo o nada. Esto crea un único punto de fallo y una flexibilidad operativa limitada. El enfoque híbrido de cside cambia las reglas del juego al permitir el proxy selectivo y tener control script por script, proxy completo o modo solo captura. Además, operamos con un diseño fail-open para no afectar nunca tu sitio web, páginas de pago o checkouts en caso de un incidente.
El tipo de incidente importa
Existen diversas causas posibles de interrupción:
- Cambios de código
- Carga sustancial inesperada
- Interrupciones de proveedores upstream
Para cada una, tenemos un runbook.
Para cada una, tenemos medidas preventivas.
Para cada una, tenemos redundancia.
No asumimos ningún riesgo.
Prevención de interrupciones causadas por cambios de código
Como la mayoría de las empresas de nivel enterprise, contamos con un riguroso proceso de pruebas y sometemos nuestro código a pruebas de presión antes de que llegue a producción.
Además, disponemos de entornos de "desarrollo" y "staging" donde probamos exhaustivamente nuestros cambios antes de que lleguen a producción. Nuestro entorno de staging es un espejo completo de producción, motor de gatekeeper incluido, por lo que cada actualización se prueba en la misma configuración en la que confían nuestros usuarios. Así nos aseguramos de que el proxy funcione completamente después de cada cambio.
Nuestro motor se ejecuta en una configuración completamente distribuida en múltiples regiones, por lo que los usuarios acceden a la instancia más cercana a ellos. Cuando estamos listos para pasar a producción, realizamos despliegues graduales en nuestras regiones. El nuevo código se despliega primero en una región y se expande progresivamente a las demás. En el improbable caso de que un cambio de código defectuoso llegue a este punto, queda contenido y se detecta de forma temprana en esa primera región antes de que el despliegue continúe globalmente.
Algo va mal, ¿qué hacemos ahora? Redundancia por protocolo.
Por diseño, cside es un proxy híbrido. Esto significa que puede implementarse para hacer proxy de algunos, todos o la mayoría de los scripts, excepto aquellos que explícitamente no hacemos proxy. Y eso es completamente configurable por nuestros clientes.
Por defecto, no hacemos proxy de scripts propios ni de scripts específicos que impiden el proxy por diseño. Eso no significa que los ignoremos. Simplemente los gestionamos de forma un poco diferente. Siguen fluyendo por nuestro pipeline para ser analizados, seguimos obteniendo su contenido aunque el proxy no los sirva y aún podemos notificar a nuestros clientes si algo parece sospechoso.
Y para los casos en que un script es realmente sensible y los clientes no quieren que pase por el proxy en absoluto, puede excluirse completamente.
Esta flexibilidad es muy valiosa para nosotros, ya que nos da opciones para ajustar rápidamente nuestros comportamientos en el sitio del cliente. Cuando ocurre un incidente o debemos depurar rápidamente, tenemos opciones para limitar el impacto de inmediato.
Por ejemplo: si el proxy tuviera alguna vez una interrupción, podríamos dejar de servir los scripts de inmediato mediante uno de los mecanismos mencionados anteriormente, para evitar que las páginas se rompan. Algunos de estos controles también están disponibles en el dashboard para que los clientes los configuren ellos mismos.
Normalmente, cuando algo empieza a ir mal, uno de nuestros servicios internos no públicos mostraría indicadores de un problema antes de que se vuelva crítico. En ese momento entraría en efecto nuestro sistema de alertas de incidentes. El equipo de cside mantiene una rotación de guardia global 24/7, con escalaciones a expertos en la materia. Planeamos publicar pronto un artículo sobre nuestros procesos de gestión de incidentes, ¡estate atento!
Además, hemos construido servicios secundarios de respaldo listos en nuestro back-end para que cualquier servicio mantenga alta disponibilidad, incluso en escenarios de desastre. Por ejemplo, en el caso del proxy, si el proxy principal no pudiera manejar la carga debido a un pico de tráfico inesperado, un servicio secundario está listo para tomar el relevo.
En un futuro próximo, cside planea usar IPs anycast para balancear la carga automáticamente hacia una ubicación alternativa por protocolo. Esto es más que un factor de redundancia; también es una decisión de diseño que mejora el rendimiento.
Cside se cae, ¿qué pasa después?
Buenas noticias: esto no ha ocurrido. Si alguna vez sucediera, significaría que toda una cadena de mecanismos de seguridad ha fallado. Aun así, estamos preparados.
Así es como funciona. En caso de que nuestro proxy se caiga, nuestro script del lado del cliente no enrutaría el tráfico hacia cside. En otras palabras, tu sitio simplemente continúa sin nosotros. Suena poco sofisticado, ¿verdad? Esto es intencionado. Ante un incidente de caída global, la solución más sencilla es la correcta. Al apartarnos del camino, nos aseguramos de que nuestra interrupción no se convierta en la tuya.
El único tráfico del que tenemos que preocuparnos en ese momento son los scripts con prefijo del lado del servidor. Esos también están cubiertos. Los gestionamos con un proxy de respaldo que redirige los scripts a su fuente original. Esto es mucho menos costoso computacionalmente y esta infraestructura se ejecuta en un servicio de terceros con escalabilidad infinita.
El resultado: ningún impacto en la disponibilidad del cliente. La única concesión es que, durante este incidente, no tendríamos visibilidad a través de nuestro servicio de proxy.
Dicho esto, un evento de caída global repentina es bastante raro y extremadamente improbable.
Normalmente, vemos señales de advertencia con mucha antelación, por lo que tenemos tiempo suficiente para reaccionar.
¡Los clientes siempre estarán disponibles!
Creamos cside porque sabíamos que todos los demás métodos existentes en el mercado daban una falsa sensación de seguridad y no tenían la visibilidad necesaria para proteger a sus clientes. Tener que construir y mantener un proxy distribuido y rápido no es una tarea menor. Conocíamos el riesgo y nos comprometimos a abordarlo. También es importante señalar que los scripts de terceros del lado del cliente hoy en día suelen estar sin monitorizar, incluyendo los SLA de disponibilidad. Encontramos URLs desactualizadas activas en sitios web cada hora. Esto es muy común. Te daremos visibilidad y garantías que antes no tenías. La disponibilidad importa y hoy no tienes visibilidad de disponibilidad sobre las dependencias de terceros del lado del cliente, pero si usaras cside, eso cambiaría.
Por diseño, nos aseguramos de evitar cualquier punto único de fallo y utilizamos mecanismos de seguridad sencillos y de baja tecnología. El método de seguridad de baja tecnología suele ser el más fiable en un incidente.
