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

10.1.1 Eventos del ciclo de vida de la transferencia

• Creación de la transferencia (generación del transferId)
• Subida de fragmento completada (se registra a nivel de texto cifrado, no de texto plano)
• Escritura/actualización del manifiesto
• Limpieza por caducidad, eliminación/revocación por parte del usuario (incluidos el inicio y la finalización de la tarea de limpieza)
• Inicio/finalización de la descarga (se mide a nivel de descarga de texto cifrado)

10.1.2 Eventos de autenticación y autorización

• Emisión de tokens de sesión, fallos de validación (ámbito no coincidente, caducado, revocado, etc.)
• Fallo de validación del token de inicio de sesión de larga duración (acción de administración denegada)
• Patrones de acceso sospechosos: picos anómalos de 401/403/404

Nota: se registra únicamente el «resultado y el código de motivo». NO DEBE registrarse el texto plano de los tokens, del encabezado Authorization ni de los parámetros de firma.

10.1.3 Métricas de estado y rendimiento del sistema

• Latencia de las solicitudes (p50/p95/p99), tasas de error, rendimiento
• Tasas de fallo de lectura/escritura del almacenamiento de objetos, tasas de fallo al obtener del origen, número de reintentos
• Anomalías en los nodos edge, acumulación 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

• Activaciones de la limitación de frecuencia, coincidencias con reglas de WAF/cortafuegos
• Superación de umbrales por sospecha de enumeración o fuerza bruta
• Patrones anómalos de concurrencia y tráfico (alta concurrencia desde el mismo origen, actividad anormal sobre un recurso)

10.1.5 Agregación y muestreo

• DEBERÍA: agregar recuentos y cuantiles de latencia por minuto/hora para reducir los registros granulares.
• DEBERÍA: muestrear las solicitudes correctas de alta frecuencia y conservar los detalles necesarios solo para los errores y las rutas anómalas.
• DEBERÍA: conservar campos de clasificación estables (p. ej., eventType, reasonCode) en los eventos anómalos para facilitar la auditoría y el análisis automático.

10.2.1 Lo que el servidor NO DEBE registrar

• La CEK (clave de cifrado de contenido) y cualquier material derivable
• El fragmento de URL (#...), location.hash y las URL completas que incluyan fragmentos
• Contenido en texto plano: texto plano de archivos, contenido de vistas previas, fragmentos descifrados o cualquier resumen en texto plano
• Texto plano de credenciales sensibles: tokens de sesión, tokens de larga duración, texto plano del encabezado Authorization, texto plano de los campos de firma de las URL firmadas

Si es necesario registrar URL para depurar: DEBE sanearse (eliminar el fragmento; ocultar o eliminar las consultas sensibles) y aplicarse a nivel de código (sin depender de una convención manual).

10.2.2 Lo que el cliente NO DEBE registrar

• No imprimir location.href (puede contener el fragmento) en entornos de producción
• No incluir URL con fragmentos, la CEK ni el noncePrefix en los informes de errores
• Los registros de depuración y la salida de las herramientas de desarrollo deberían estar desactivados o reducidos al mínimo de forma predeterminada

DEBERÍA: encapsular en el frontend una función unificada de registro/informe que realice internamente el saneamiento de URL y el filtrado de campos sensibles antes de emitir o enviar la información.

10.3.1 Alertas de disponibilidad y rendimiento

• Alertas de tasa de error: picos de 5xx, aumento anómalo de 4xx (distinguir los fallos de autenticación del abuso)
• Alertas de latencia: superación de umbrales de p95/p99, anomalías al obtener del origen en una región
• Alertas de almacenamiento: aumento de los fallos de escritura en el almacenamiento de objetos y de los tiempos de espera de lectura
• Alertas de las tareas de limpieza: acumulación de limpiezas por caducidad pendientes, reintentos excesivos de las tareas de eliminación

10.3.2 Alertas de seguridad

• Aumento anómalo de la tasa de activaciones de la limitación de frecuencia
• 401/403/404 de alta frecuencia desde el mismo origen, con sospecha de enumeración o fuerza bruta
• Ancho de banda o concurrencia de descarga anómalos en un solo recurso, con sospecha de saturación de tráfico o hotlinking
• Los cambios críticos de políticas (p. ej., reglas de WAF, cambios de CSP o de encabezados) deberían activar auditorías de cambios y alertas (si procede)

10.3.3 Gobernanza de las alertas

• DEBERÍA: clasificar las alertas (P0/P1/P2) con rutas de guardia y escalado.
• DEBERÍA: aplicar antirrebote o agregación por ventanas a las métricas ruidosas para evitar la fatiga de alertas.
• DEBERÍA: adjuntar a cada alerta la información de diagnóstico mínima (código de motivo, gráfico de tendencia, región/ruta afectada), sin datos sensibles.

10.4.1 Patrones de anomalía habituales

• Enumeración: sondeo masivo de transferId o rutas de recursos en poco tiempo, picos de 404/401/403.
• Fuerza bruta: intentos de alta frecuencia con códigos cortos, contraseñas o tokens, curva anómala de tasa de fallos.
• Saturación de tráfico: ancho de banda anómalo en un solo recurso, gran número de conexiones simultáneas desde el mismo origen, descargas repetidas.
• Anomalías de protocolo: orden irracional de fragmentos, subidas duplicadas, interrupciones/reintentos frecuentes, patrones anómalos de user agent.

10.4.2 Estrategias de mitigación (principios)

• DEBERÍA: limitación de frecuencia, bloqueo escalonado, mecanismos de desafío (si procede) y políticas dinámicas según ASN/región/huella digital.
• DEBERÍA: adoptar estrategias más suaves (p. ej., retraso, limitación de ancho de banda por tramos) en las rutas sensibles a los falsos positivos (los usuarios normales pueden descargar con frecuencia).
• DEBE: conservar los desencadenantes auditables (código de motivo, categoría de umbral) de las acciones realizadas y ofrecer canales de soporte (si procede).