Logo

Livre blanc sur la sécurité et la confidentialité (présentation)Chapitre 10

Chapitre 10 : journalisation, surveillance et réponse aux incidents

L’observabilité de FileBolt doit respecter les limites de la connaissance nulle (zero-knowledge) : le système doit identifier les pannes, détecter les attaques et mesurer les performances sans créer de nouveaux vecteurs de fuite de données sensibles. Ce chapitre définit quels événements sont journalisés, interdit explicitement l’enregistrement de certaines informations, décrit les méthodes d’alerte et de détection d’anomalies, et détaille le processus de réponse aux incidents de sécurité (IR) ainsi que les principes de communication externe.

10.0 Résumé

  • DEVRAIT : les journaux et la surveillance ne couvrent que les événements opérationnels et de sécurité nécessaires, en recourant à l’agrégation et à l’échantillonnage pour limiter la conservation du détail brut.
  • NE DOIT PAS : aucun journal, outil d’APM ou rapport d’erreurs ne doit contenir de CEK, de fragments d’URL (location.hash) ni d’URL complètes comportant un fragment.
  • NE DOIT PAS : ne pas enregistrer de contenu en clair, de blocs déchiffrés ni d’éléments de clé dérivables.
  • DOIT : mettre en place la détection et l’alerte pour l’énumération, la force brute, les pics de trafic et les schémas anormaux, avec des mesures de confinement prêtes à l’emploi.
  • DOIT : maintenir un processus de réponse aux incidents (tri, confinement, analyse forensique, remédiation, retour d’expérience, communication).

10.1 Événements journalisés (minimalisme)

Les journaux système et la surveillance DEVRAIENT ne couvrir que l’ensemble des événements « nécessaires à l’exploitation et à la sécurité », en évitant d’introduire du contenu utilisateur ou des identifiants sensibles dans les systèmes d’observabilité. Les événements sont classés en cycle de vie, authentification, stockage/réseau et protection de sécurité, avec une agrégation recommandée.

10.1.1 Événements du cycle de vie d’un transfert

  • Création d’un transfert (génération du transferId)
  • Envoi d’un bloc terminé (journalisé au niveau du texte chiffré, jamais en clair)
  • Écriture ou mise à jour du manifeste
  • Nettoyage à l’expiration, suppression ou révocation par l’utilisateur (y compris le déclenchement et l’achèvement de la tâche de nettoyage)
  • Début et fin du téléchargement (mesurés au niveau du téléchargement du texte chiffré)

10.1.2 Événements d’authentification et d’autorisation

  • Émission d’un jeton de session, échec de validation (portée non conforme, expiré, révoqué, etc.)
  • Échec de validation d’un jeton de connexion de longue durée (action d’administration refusée)
  • Schémas d’accès suspects : pics anormaux de 401/403/404

Remarque : n’enregistrer que le « résultat et le code de motif ». Il NE DOIT PAS enregistrer le jeton en clair, l’en-tête Authorization en clair ni les paramètres de signature en clair.

10.1.3 Indicateurs de santé et de performance du système

  • Latence des requêtes (p50/p95/p99), taux d’erreur, débit
  • Taux d’échec de lecture/écriture du stockage d’objets, taux d’échec de récupération depuis l’origine, nombre de nouvelles tentatives
  • Anomalies des nœuds périphériques, files d’attente en retard, taux de réussite des tâches de nettoyage en arrière-plan
  • Tendances de bande passante et de trafic (dimensions agrégées)

10.1.4 Événements de protection de sécurité

  • Déclenchements de la limitation de débit, règles WAF/pare-feu activées
  • Dépassements de seuil indiquant une énumération ou une force brute présumée
  • Schémas anormaux de concurrence et de trafic (forte concurrence depuis une même source, activité anormale sur une ressource)

10.1.5 Agrégation et échantillonnage

  • DEVRAIT : agréger les compteurs et les quantiles de latence par minute ou par heure pour réduire les journaux détaillés.
  • DEVRAIT : échantillonner les requêtes réussies à haute fréquence et ne conserver le détail nécessaire que pour les erreurs et les chemins anormaux.
  • DEVRAIT : conserver des champs de classification stables (par exemple eventType, reasonCode) pour les événements anormaux afin de faciliter l’audit et l’analyse automatisée.

10.2 Informations interdites (CEK, fragment, identifiants)

Pour tenir l’engagement de connaissance nulle (zero-knowledge), il est essentiel d’appliquer strictement une politique d’« interdiction des données sensibles » dans tous les systèmes d’observabilité. Cette politique doit couvrir : les journaux serveur, l’APM, le suivi des erreurs, la surveillance tierce, les journaux client et la sortie de la console du navigateur.

10.2.1 Ce que le serveur NE DOIT PAS enregistrer

  • CEK (Content Encryption Key) et tout élément dérivable
  • Fragment d’URL (#...), location.hash et URL complètes comportant un fragment
  • Contenu en clair : contenu des fichiers en clair, contenu d’aperçu, blocs déchiffrés ou tout résumé en clair
  • Identifiants sensibles en clair : jetons de session, jetons de longue durée, en-tête Authorization en clair, champs de signature en clair dans les URL signées

Si la journalisation des URL est nécessaire au débogage : il DOIT les assainir (supprimer le fragment ; masquer ou supprimer les paramètres de requête sensibles) et l’imposer au niveau du code (sans s’en remettre à une convention manuelle).

10.2.2 Ce que le client NE DOIT PAS enregistrer

  • Ne pas afficher location.href (qui peut contenir un fragment) en production
  • Ne pas inclure d’URL comportant un fragment, de CEK ni de noncePrefix dans les rapports d’erreurs
  • Les journaux de débogage et les sorties des outils de développement devraient être désactivés ou réduits au minimum par défaut

DEVRAIT : encapsuler côté frontend une fonction unifiée de journalisation et de rapport qui assainit les URL et filtre les champs sensibles en interne avant toute sortie ou tout envoi.

10.3 Indicateurs de surveillance et alertes (disponibilité, performances, sécurité)

10.3.1 Alertes de disponibilité et de performance

  • Alertes de taux d’erreur : pics de 5xx, hausse anormale de 4xx (distinguer les échecs d’authentification des abus)
  • Alertes de latence : dépassements des seuils p95/p99, anomalies de récupération depuis l’origine par région
  • Alertes de stockage : hausse des échecs d’écriture et des délais de lecture dépassés du stockage d’objets
  • Alertes des tâches de nettoyage : retard du nettoyage à l’expiration, nombre excessif de nouvelles tentatives de suppression

10.3.2 Alertes de sécurité

  • Hausse anormale du taux de déclenchement de la limitation de débit
  • Fréquence élevée de 401/403/404 depuis une même source, énumération ou force brute présumée
  • Bande passante ou concurrence anormale sur le téléchargement d’une seule ressource, saturation de trafic ou hotlinking présumé
  • Les changements de politique critiques (par exemple règles WAF, modifications de la CSP ou des en-têtes) devraient déclencher des audits de changement et des alertes (le cas échéant)

10.3.3 Gouvernance des alertes

  • DEVRAIT : classer les alertes par niveau (P0/P1/P2) avec des chemins de rotation et d’escalade.
  • DEVRAIT : appliquer un anti-rebond ou une agrégation par fenêtre aux indicateurs bruyants pour éviter la fatigue d’alerte.
  • DEVRAIT : joindre à chaque alerte un minimum d’informations de diagnostic (code de motif, courbe de tendance, région ou route concernée), à l’exclusion de toute donnée sensible.

10.4 Détection d’anomalies et identification des abus

Les services de transfert de fichiers sont naturellement exposés aux risques d’énumération, de force brute, de saturation de trafic et d’abus de ressources. Cette section décrit les signaux détectables et les principes de réaction. Les seuils et stratégies précis doivent être ajustés dynamiquement selon l’échelle de l’activité et le coût des faux positifs.

10.4.1 Schémas d’anomalies courants

  • Énumération : sondage massif de transferId et de chemins de ressources sur une courte période, pics de 404/401/403.
  • Force brute : tentatives à haute fréquence sur des codes courts, mots de passe ou jetons, courbe anormale du taux d’échec.
  • Saturation de trafic : bande passante anormale pour une seule ressource, très grand nombre de connexions simultanées depuis une même source, téléchargements répétés.
  • Anomalies de protocole : ordre incohérent des blocs, envois en double, interruptions et reprises fréquentes, schémas d’UA anormaux.

10.4.2 Stratégies d’atténuation (principes)

  • DEVRAIT : limitation de débit, blocage progressif, mécanismes de défi (le cas échéant), politiques dynamiques fondées sur l’ASN, la région ou l’empreinte.
  • DEVRAIT : adopter des stratégies plus souples (par exemple délai, limitation par paliers) pour les chemins sensibles aux faux positifs (des utilisateurs normaux peuvent télécharger fréquemment).
  • DOIT : conserver les déclencheurs auditables (code de motif, catégorie de seuil) pour les mesures prises et prévoir des canaux d’assistance (le cas échéant).

10.5 Processus de réponse aux incidents

FileBolt DOIT établir un processus de réponse aux incidents de sécurité (IR) afin de garantir une maîtrise rapide des dégâts, une traçabilité à des fins de revue et une communication transparente. Les événements pouvant porter atteinte aux engagements de connaissance nulle (par exemple XSS, injection dans la chaîne d’approvisionnement, fuite de fragments dans les journaux) DEVRAIENT être traités en priorité maximale.

  1. Tri (triage) : classer selon l’étendue et la gravité de l’impact (par exemple P0/P1/P2), définir les chemins d’escalade et les responsables.
  2. Confinement : isoler rapidement les sources de risque (bloquer les sources d’attaque, désactiver temporairement des fonctionnalités, durcir les politiques, renouveler les clés et jetons).
  3. Analyse forensique et retour d’expérience : reconstituer la chronologie à partir de journaux et d’indicateurs minimaux ; documenter les décisions, l’impact, la remédiation et les améliorations.
  4. Remédiation et vérification : déployer les correctifs, effectuer des tests de non-régression et une vérification de sécurité, relancer si nécessaire une analyse par un tiers.
  5. Communication et divulgation : expliquer en toute transparence aux utilisateurs et au public sans élargir la surface d’attaque ; publier si nécessaire des rapports d’incident sur la page d’état.

La communication externe devrait préciser : si des éléments de clé ou des données en clair ont pu être exposés, l’étendue de l’impact, les mesures prises et les actions que les utilisateurs doivent mener (le cas échéant).

10.6 Conservation des données et contrôle d’accès

Les journaux et les données de surveillance sont eux-mêmes des actifs sensibles. Il convient d’appliquer les durées de conservation utiles les plus courtes et un contrôle d’accès au moindre privilège afin de limiter les risques de fuite et d’abus.

  • DEVRAIT : définir des durées de conservation différenciées selon les types de journaux (un peu plus longues pour les erreurs et les événements de sécurité, plus courtes ou nulles pour le détail des requêtes réussies).
  • DEVRAIT : appliquer un accès au moindre privilège (RBAC) aux plateformes de journalisation et de surveillance, et conserver les audits d’accès.
  • DEVRAIT : assainir et minimiser les données lors de l’export ou du partage des journaux (interdiction d’y inclure des identifiants sensibles et des données personnelles).

10.7 Principes de surveillance et d’intégration par des tiers

Les outils tiers d’APM et de suivi des erreurs peuvent collecter par défaut les URL, les en-têtes, les champs de formulaire et des informations sur l’appareil. En cas de surveillance tierce, il faut s’assurer que ses limites de collecte ne contredisent pas les engagements de connaissance nulle.

  • DOIT : ne pas charger de scripts tiers sur les pages de téléchargement et de déchiffrement (cohérent avec le chapitre 9).
  • DOIT : configurer explicitement la collecte tierce : aucun fragment, aucun en-tête sensible en clair, aucun contenu en clair.
  • DEVRAIT : unifier l’assainissement des URL dans les rapports ; interdire ou masquer fortement les charges utiles susceptibles de contenir des champs sensibles.
  • DEVRAIT : privilégier les indicateurs agrégés côté serveur plutôt qu’un suivi détaillé côté client, afin de réduire la surface de collecte sur les terminaux.

10.8 Identifiants d’affirmation associés (réservé)

Ce chapitre couvre « l’interdiction de journaliser des données sensibles, l’alerte et l’IR, ainsi que les contraintes de surveillance tierce ». Les identifiants d’affirmation correspondants seront ajoutés à l’ Annexe : liste de référence des identifiants d’affirmation, qui fait seule autorité.