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 s'aligner sur les limites du Zero-Knowledge : le système doit identifier les défauts, détecter les attaques et quantifier les performances. sans introduire 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) et les principes de communication externe.

10.0 Résumé

  • SHOULD: Les journaux et la surveillance couvrent uniquement les événements opérationnels et de sécurité nécessaires, en utilisant l'agrégation et l'échantillonnage pour minimiser la conservation des détails bruts.
  • NE DOIT PAS: Les journaux, APM ou rapports d'erreurs ne doivent pas contenir de CEK, de fragments d'URL (location.hash), ou des URL complètes contenant des fragments.
  • NE DOIT PAS: N'enregistrez pas le contenu en texte brut, les fragments déchiffrés ou les éléments de clé dérivables.
  • MUST: Établir une détection et une alerte en cas d'énumération, de force brute, de pics de trafic et de modèles anormaux, avec des mesures de confinement en place.
  • MUST: Maintenir un processus de réponse aux incidents (triage, confinement, criminalistique, remédiation, examen, communication).

10.1 Événements enregistrés (minimalisme)

Les journaux système et la surveillance DEVRAIENT couvrir uniquement l'ensemble des événements « nécessaires aux opérations et à la sécurité », en évitant l'ingestion de contenu utilisateur ou d'informations d'identification 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é, l'agrégation étant recommandée.

10.1.1 Événements du cycle de vie du transfert

  • Créer un transfert (générer un transferId)
  • Téléchargement du bloc terminé (enregistré au niveau du texte chiffré, pas en texte brut)
  • Écriture/mise à jour du manifeste
  • Nettoyage après expiration, suppression/révocation d'utilisateur (y compris le déclenchement et l'achèvement de la tâche de nettoyage)
  • Début/fin du téléchargement (mesuré au niveau de téléchargement du texte chiffré)

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

  • Émission du jeton de session, échec de validation (incompatibilité de portée, expiré, révoqué, etc.)
  • Échec de validation du jeton de connexion à long terme (action d'administrateur refusée)
  • Modèles d'accès suspects : pics anormaux dans 401/403/404

Remarque : Enregistrez uniquement le « code de résultat et de motif ». NE DOIT PAS enregistrer le texte en clair du jeton, le texte en clair de l’en-tête d’autorisation ou le texte en clair du paramètre de signature.

10.1.3 Mesures de santé et de performances 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 d'origine, nombre de nouvelles tentatives
  • Anomalies des nœuds Edge, retards dans les files d'attente, taux de réussite des tâches de nettoyage en arrière-plan
  • Tendances de la bande passante et du trafic (dimensions agrégées)

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

  • Déclencheurs de limitation de débit, atteintes de règles WAF/pare-feu
  • Déclencheurs de seuil pour un comportement suspecté d'énumération/de force brute
  • Concurrence anormale et modèles de trafic (concurrence élevée provenant de la même source, chaleur anormale des ressources)

10.1.5 Agrégation et échantillonnage

  • SHOULD: regroupez les décomptes et les quantiles de latence par minute/heure pour réduire les journaux granulaires.
  • SHOULD: échantillonnez les requêtes réussies à haute fréquence, en conservant les détails nécessaires uniquement pour les erreurs et les chemins anormaux.
  • SHOULD: Conservez les champs de classification stables (par exemple, eventType, ReasonCode) pour les événements anormaux afin de faciliter l'audit et l'analyse automatique.

10.2 Informations interdites (CEK, fragment, informations d'identification)

Une clé pour maintenir l'engagement Zero-Knowledge est d'appliquer strictement une politique d'« interdiction des données sensibles » dans tous les systèmes d'observabilité. Cette politique doit couvrir : les journaux du serveur, l'APM, les rapports d'erreurs, la surveillance tierce, les journaux des clients et la sortie de la console du navigateur.

10.2.1 Côté serveur NE DOIT PAS enregistrer

  • CEK (Content Encryption Key) et tout matériel dérivé
  • Fragment d'URL (#...), location.hash, et les URL complètes contenant des fragments
  • Contenu en texte brut: Fichier en texte brut, aperçu du contenu, morceaux déchiffrés ou tout résumé en texte brut
  • Texte brut des informations d'identification sensibles: jetons de session, jetons à long terme, texte brut de l'en-tête d'autorisation, texte brut du champ de signature dans les URL signées

Si la journalisation des URL est requise pour le débogage : MUST désinfectez (supprimez le fragment ; expurgez ou supprimez les requêtes sensibles) et appliquez cela au niveau du code (sans vous fier aux conventions manuelles).

10.2.2 Le côté client NE DOIT PAS enregistrer

  • Ne pas imprimer location.href (peut contenir un fragment) dans les environnements de production
  • N'incluez pas d'URL contenant des fragments, des CEK ou des noncePrefix dans les rapports d'erreurs.
  • Les journaux de débogage et les sorties de l'outil de développement doivent être désactivés ou réduits par défaut

SHOULD: Encapsulez une fonction de journal/rapport unifiée sur le frontend qui effectue la désinfection des URL et le filtrage des champs sensibles en interne avant la sortie/le rapport.

10.3 Surveillance des métriques et des alertes (disponibilité, performances, sécurité)

10.3.1 Alertes de disponibilité et de performances

  • Alertes de taux d'erreur : pics dans 5xx, augmentation anormale dans 4xx (distinguer l'échec d'authentification des abus)
  • Alertes de latence : dépassements de seuil p95/p99, anomalies de récupération d'origine régionale
  • Alertes de stockage : augmentation des échecs d'écriture du stockage d'objets et des délais d'attente de lecture
  • Alertes de tâches de nettoyage : retard de nettoyage à l'expiration, tentatives de suppression excessives

10.3.2 Alertes de sécurité

  • Augmentation anormale du taux d'atteinte de la limite de débit
  • Haute fréquence 401/403/404 provenant de la même source, dénombrement/force brute suspectée
  • Bande passante/concurrence anormale de téléchargement d'une seule ressource, suspicion d'inondation de trafic ou de hotlinking
  • Les changements de politique critiques (par exemple, les règles WAF, les changements de CSP/en-tête) doivent déclencher des audits de changement et des alertes (le cas échéant)

10.3.3 Gouvernance des alertes

  • SHOULD: Catégoriser les alertes (P0/P1/P2) avec des chemins de rotation/escalade.
  • SHOULD: appliquez l'agrégation anti-rebond/fenêtre aux métriques bruyantes pour éviter la fatigue des alertes.
  • SHOULD: Joignez des informations de diagnostic minimales (code de motif, graphique de tendance, région/itinéraire affecté) à chaque alerte, à l'exclusion des données sensibles.

10.4 Détection des anomalies et identification des abus

Les services de transfert de fichiers sont naturellement confrontés à des risques d’énumération, de force brute, d’inondation de trafic et d’abus de ressources. Cette section décrit les signaux détectables et les principes de réponse. Les seuils et stratégies spécifiques doivent être ajustés de manière dynamique en fonction de l’échelle de l’entreprise et des coûts des faux positifs.

10.4.1 Modèles d'anomalies courantes

  • Enumeration: Sondage massif des chemins transferId/ressource en peu de temps, pics en 404/401/403.
  • Force brute: Tentatives à haute fréquence sur codes courts/mots de passe/jetons, courbe de taux d'échec anormale.
  • Inondations de la circulation: Bande passante anormale pour une seule ressource, connexions simultanées massives depuis la même source, téléchargements répétés.
  • Anomalies de protocole: Ordre irrationnel des fragments, téléchargements en double, interruptions/tentatives fréquentes, modèles UA anormaux.

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

  • SHOULD: Limitation du débit, interdictions échelonnées, mécanismes de contestation (le cas échéant), politiques dynamiques basées sur l'ASN/la région/l'empreinte digitale.
  • SHOULD: Adoptez des stratégies plus douces (par exemple, retard, limitation segmentée) pour les chemins sensibles aux faux positifs (les utilisateurs normaux peuvent télécharger fréquemment).
  • MUST: Conservez les déclencheurs auditables (code de motif, catégorie de seuil) pour les actions entreprises et fournissez 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) pour garantir un contrôle rapide des dommages, une possibilité de révision et une communication transparente. Les événements affectant potentiellement les engagements Zero-Knowledge (par exemple, XSS, injection dans la chaîne d'approvisionnement, fuite de fragments de journaux) doivent être traités avec la plus haute priorité.

  1. Triage: Classez par étendue et gravité de l'impact (par exemple, P0/P1/P2), définissez les chemins d'escalade et les propriétaires.
  2. Containment: Isolez rapidement les sources de risques (bannir les sources d'attaques, désactiver temporairement les fonctionnalités, renforcer les politiques, alterner les clés/jetons).
  3. Forensique et examen: Reconstruire la chronologie basée sur un minimum de journaux et de métriques ; documenter les décisions, l’impact, les mesures correctives et les améliorations.
  4. Correction et vérification: Déployez des correctifs, des tests de régression, une vérification de sécurité, des tests d'analyse tiers si nécessaire.
  5. Communication et divulgation: Expliquer de manière transparente aux utilisateurs et au public sans étendre la surface d'attaque ; publier des rapports d'incident sur la page d'état si nécessaire.

La communication externe doit clarifier : si le matériel clé ou le texte brut a été potentiellement exposé, la portée de l'impact, les mesures prises et les actions que les utilisateurs doivent entreprendre (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. Les périodes de conservation utiles les plus courtes et le contrôle d’accès au moindre privilège doivent être appliqués pour minimiser les risques de fuite et d’abus.

  • SHOULD: définissez des périodes de conservation différenciées pour les types de journaux (légèrement plus longues pour les erreurs et les événements de sécurité, plus courtes ou aucune conservation pour les détails des demandes réussies).
  • SHOULD: Utilisez l'accès au moindre privilège (RBAC) pour les plates-formes de journalisation et de surveillance et conservez les audits d'accès.
  • SHOULD: effectuez une désinfection et une minimisation lors de l'exportation/partage de journaux (interdiction de transporter des informations d'identification sensibles et des informations personnelles).

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

Les outils tiers de suivi des erreurs/APM peuvent collecter par défaut des URL, des en-têtes, des champs de formulaire et des informations sur l'appareil. Si vous utilisez une surveillance tierce, assurez-vous que les limites de sa collection ne violent pas les engagements Zero-Knowledge.

  • MUST: Ne chargez pas de scripts tiers sur les pages de téléchargement/décryptage (conforme au chapitre 9).
  • MUST: Configurez explicitement la collection tierce : pas de fragments, pas de texte brut d'en-tête sensible, pas de contenu en texte brut.
  • SHOULD: Unifiez la désinfection des URL pour les rapports ; interdire ou masquer fortement les charges utiles contenant potentiellement des champs sensibles.
  • SHOULD: donnez la priorité aux métriques agrégées côté serveur par rapport au suivi granulaire côté client afin de réduire la surface de collecte des points de terminaison.

10.8 ID de réclamation associés (réservé)

Ce chapitre couvre « l'interdiction de l'enregistrement des données sensibles, des alertes et des contraintes de surveillance IR et tierces ». Les identifiants de réclamation correspondants seront ajoutés au Annexe : Liste principale des identifiants de réclamation comme seule source faisant autorité.