Logo

Informe técnico sobre seguridad y privacidad (descripción general)Capítulo 10

Capítulo 10: Registro, monitoreo y respuesta a incidentes

La observabilidad de FileBolt debe alinearse con los límites del conocimiento cero: el sistema debe identificar fallas, detectar ataques y cuantificar el rendimiento. sin introducir nuevos vectores de fuga de datos sensibles. Este capítulo define qué eventos se registran, prohíbe explícitamente el registro de cierta información, describe los métodos de alerta y detección de anomalías, y detalla el proceso de Respuesta a Incidentes de Seguridad (IR) y los principios de comunicación externa.

10.0 Resumen

  • SHOULD: Los registros y el monitoreo cubren solo los eventos operativos y de seguridad necesarios, utilizando agregación y muestreo para minimizar la retención de detalles sin procesar.
  • NO DEBE: Cualquier registro, APM o informe de error no debe contener CEK ni fragmentos de URL (location.hash), o URL completas que contienen fragmentos.
  • NO DEBE: No registre contenido de texto sin formato, fragmentos descifrados ni material de clave derivable.
  • MUST: Establecer detección y alertas para enumeración, fuerza bruta, picos de tráfico y patrones anómalos, con medidas de contención implementadas.
  • MUST: Mantener un proceso de Respuesta a Incidentes (Triaje, Contención, Análisis Forense, Remediación, Revisión, Comunicación).

10.1 Eventos registrados (minimalismo)

Los registros y el monitoreo del sistema DEBEN cubrir solo el conjunto de eventos "necesarios para las operaciones y la seguridad", evitando la ingestión de contenido del usuario o credenciales confidenciales en los sistemas de observabilidad. Los eventos se clasifican en ciclo de vida, autenticación, almacenamiento/red y protección de seguridad, y se recomienda su agregación.

10.1.1 Eventos del ciclo de vida de transferencia

  • Crear transferencia (generar transferId)
  • Carga del fragmento completa (registrada a nivel de texto cifrado, no en texto sin formato)
  • Escritura/actualización de manifiesto
  • Limpieza de caducidad, eliminación/revocación de usuarios (incluido el desencadenador y la finalización de la tarea de limpieza)
  • Descarga iniciada/completada (medida en el nivel de descarga de texto cifrado)

10.1.2 Eventos de autenticación y autorización

  • Emisión de token de sesión, error de validación (no coincide el alcance, caducado, revocado, etc.)
  • Error de validación del token de inicio de sesión a largo plazo (acción del administrador denegada)
  • Patrones de acceso sospechosos: picos anómalos en 401/403/404

Nota: Registre únicamente el "código de motivo y resultado". NO DEBE texto sin formato del token de registro, texto sin formato del encabezado de autorización o texto sin formato del parámetro de firma.

10.1.3 Métricas de rendimiento y estado del sistema

  • Solicitud de latencia (p50/p95/p99), tasas de error, rendimiento
  • Tasas de error de lectura/escritura del almacenamiento de objetos, tasas de error de recuperación del origen, recuentos de reintentos
  • Anomalías en los nodos perimetrales, atrasos en las colas, tasas de éxito de las tareas de limpieza en segundo plano
  • Tendencias de ancho de banda y tráfico (dimensiones agregadas)

10.1.4 Eventos de protección de seguridad

  • Activadores de limitación de velocidad, aciertos de reglas WAF/firewall
  • Desencadenantes de umbrales para sospechas de comportamiento de enumeración/fuerza bruta
  • Patrones de tráfico y concurrencia anómalos (alta concurrencia de la misma fuente, calor anormal de recursos)

10.1.5 Agregación y muestreo

  • SHOULD: Recuentos agregados y cuantiles de latencia por minuto/hora para reducir los registros granulares.
  • SHOULD: muestra de solicitudes exitosas de alta frecuencia, conservando los detalles necesarios solo para errores y rutas anómalas.
  • SHOULD: Conserve campos de clasificación estables (por ejemplo, tipo de evento, código de motivo) para eventos anómalos para facilitar la auditoría y el análisis de la máquina.

10.2 Información prohibida (CEK, Fragmento, Credenciales)

Una clave para mantener el compromiso de conocimiento cero es hacer cumplir estrictamente una política de "prohibición de datos confidenciales" en todos los sistemas de observabilidad. Esta política debe cubrir: registros del servidor, APM, informes de errores, monitoreo de terceros, registros del cliente y salida de la consola del navegador.

10.2.1 El lado del servidor NO DEBE grabar

  • CEK (Clave de cifrado de contenido) y cualquier material derivable
  • fragmento de URL (#...), location.hashy URL completas que contienen fragmentos
  • Contenido de texto sin formato: Archivo de texto sin formato, vista previa de contenido, fragmentos descifrados o cualquier resúmenes de texto sin formato
  • Texto sin formato de credenciales confidenciales: Tokens de sesión, tokens a largo plazo, texto sin formato del encabezado de autorización, texto sin formato del campo de firma en URL firmadas

Si es necesario registrar las URL para la depuración: MUST desinfectar (eliminar fragmentos; redactar o eliminar consultas confidenciales) y aplicar esto a nivel de código (sin depender de la convención manual).

10.2.2 El lado del cliente NO DEBE registrar

  • no imprimir location.href (puede contener fragmentos) en entornos de producción
  • No incluya URL con fragmentos, CEK o noncePrefix en los informes de errores
  • Los registros de depuración y las salidas de las herramientas de desarrollo deben deshabilitarse o minimizarse de forma predeterminada.

SHOULD: encapsula una función de registro/informe unificada en la interfaz que realiza la desinfección de URL y el filtrado de campos sensibles internamente antes de generar/informar.

10.3 Monitoreo de métricas y alertas (disponibilidad, rendimiento, seguridad)

10.3.1 Alertas de disponibilidad y rendimiento

  • Alertas de tasa de error: picos en 5xx, aumento anormal en 4xx (distinga el error de autenticación del abuso)
  • Alertas de latencia: incumplimiento del umbral p95/p99, anomalías en la recuperación del origen regional
  • Alertas de almacenamiento: aumento de los errores de escritura en el almacenamiento de objetos y tiempos de espera de lectura
  • Alertas de tareas de limpieza: acumulación de tareas pendientes de caducidad, reintentos excesivos de tareas de eliminación

10.3.2 Alertas de seguridad

  • Aumento anormal en la tasa de aciertos del límite de tasa
  • Alta frecuencia 401/403/404 de la misma fuente, sospecha de enumeración/fuerza bruta
  • Ancho de banda/concurrencia anormal de descarga de un solo recurso, sospecha de inundación de tráfico o hotlinking
  • Los cambios críticos de política (por ejemplo, reglas WAF, cambios de CSP/encabezado) deben desencadenar auditorías y alertas de cambios (si corresponde).

10.3.3 Gobernanza de alertas

  • SHOULD: Clasifique las alertas (P0/P1/P2) con rutas de rotación/escalamiento.
  • SHOULD: aplique eliminación de rebotes/agregación de ventanas a métricas ruidosas para evitar la fatiga de alertas.
  • SHOULD: adjunte información de diagnóstico mínima (código de motivo, gráfico de tendencias, región/ruta afectada) a cada alerta, excluyendo datos confidenciales.

10.4 Detección de anomalías e identificación de abusos

Los servicios de transferencia de archivos naturalmente enfrentan riesgos de enumeración, fuerza bruta, inundaciones de tráfico y abuso de recursos. Esta sección describe las señales detectables y los principios de respuesta. Los umbrales y estrategias específicos deben ajustarse dinámicamente en función de la escala del negocio y los costos de falsos positivos.

10.4.1 Patrones de anomalías comunes

  • Enumeration: Sondeo masivo de transferId/rutas de recursos en poco tiempo, picos en 404/401/403.
  • Fuerza bruta: Intentos de alta frecuencia con códigos cortos/contraseñas/tokens, curva de tasa de falla anormal.
  • Inundaciones de tráfico: Ancho de banda anormal para un solo recurso, conexiones simultáneas masivas desde la misma fuente, descargas repetidas.
  • Anomalías de protocolo: Orden de fragmentos irracional, cargas duplicadas, interrupciones/reintentos frecuentes, patrones UA anormales.

10.4.2 Estrategias de mitigación (Principios)

  • SHOULD: Limitación de tarifas, prohibición escalonada, mecanismos de desafío (si corresponde), políticas dinámicas basadas en ASN/Región/Huella digital.
  • SHOULD: adopte estrategias más suaves (por ejemplo, retraso, limitación segmentada) para rutas sensibles a falsos positivos (los usuarios normales pueden descargar con frecuencia).
  • MUST: Conservar activadores auditables (código de motivo, categoría de umbral) para las acciones tomadas y proporcionar canales de soporte (si corresponde).

10.5 Proceso de respuesta a incidentes

FileBolt DEBE establecer un proceso de respuesta a incidentes de seguridad (IR) para garantizar un control rápido de daños, capacidad de revisión y comunicación transparente. Los eventos que potencialmente afecten los compromisos de conocimiento cero (por ejemplo, XSS, inyección en la cadena de suministro, fuga de fragmentos de registros) deben tratarse como la máxima prioridad.

  1. Triage: Clasificar por alcance y gravedad del impacto (p. ej., P0/P1/P2), definir rutas de escalada y propietarios.
  2. Containment: Aísle rápidamente las fuentes de riesgo (prohíba las fuentes de ataque, deshabilite temporalmente las funciones, ajuste las políticas, rote claves/tokens).
  3. Análisis forense y revisión: Reconstruir la línea de tiempo basada en registros y métricas mínimos; documentar decisiones, impacto, remediación y mejoras.
  4. Remediación y verificación: Implementar parches, pruebas de regresión, verificación de seguridad, volver a probar análisis de terceros si es necesario.
  5. Comunicación y Divulgación: Explicar de forma transparente a los usuarios y al público sin ampliar la superficie de ataque; publicar informes de incidentes en la página de estado si es necesario.

La comunicación externa debe aclarar: si material clave o texto sin formato estuvo potencialmente expuesto, el alcance del impacto, las medidas tomadas y las acciones que los usuarios deben tomar (si corresponde).

10.6 Retención de datos y control de acceso

Los registros y los datos de monitoreo son activos confidenciales en sí mismos. Se deben aplicar períodos de retención útiles más cortos y un control de acceso con privilegios mínimos para minimizar los riesgos de fugas y abuso.

  • SHOULD: establezca períodos de retención diferenciados para los tipos de registros (un poco más largos para errores y eventos de seguridad, más cortos o nulos para los detalles de la solicitud exitosa).
  • SHOULD: Utilice el acceso con privilegios mínimos (RBAC) para plataformas de registro y monitoreo y conserve las auditorías de acceso.
  • SHOULD: Realizar desinfección y minimización al exportar/compartir registros (prohibir llevar credenciales confidenciales e PII).

10.7 Principios de integración y monitoreo de terceros

Las herramientas de seguimiento de errores/APM de terceros pueden recopilar URL, encabezados, campos de formulario e información del dispositivo de forma predeterminada. Si utiliza el monitoreo de terceros, asegúrese de que los límites de su recopilación no violen los compromisos de conocimiento cero.

  • MUST: No cargue scripts de terceros en páginas de descarga/descifrado (de conformidad con el Capítulo 9).
  • MUST: Configure explícitamente la colección de terceros: sin fragmentos, sin texto sin formato de encabezado confidencial, sin contenido de texto sin formato.
  • SHOULD: Unificar la desinfección de URL para informes; prohibir o enmascarar fuertemente las cargas útiles que potencialmente contengan campos sensibles.
  • SHOULD: Priorice las métricas agregadas del lado del servidor sobre el seguimiento granular del lado del cliente para reducir la superficie de recopilación de puntos finales.

10.8 ID de reclamaciones relacionadas (reservadas)

Este capítulo cubre "Prohibición de registro de datos confidenciales, alertas e IR, restricciones de monitoreo de terceros". Los ID de reclamo correspondientes se agregarán a la Apéndice: Lista maestra de ID de reclamaciones como única fuente autorizada.