# Sécuriser les identifiants d’un compte Sentry partagé entre 30 sites > Un même DSN Sentry copié sur trente projets clients d'une agence : la checklist de cloisonnement et de rotation avant qu'un incident sur l'un ne compromette les vingt-neuf autres. - Auteur : Clément Hadrot - Publié le : 2024-04-21 - Mis à jour le : 2024-04-21 - Catégorie : Sécurité - URL : https://wpmoderne.dev.wordpress-developpement.fr/securite/securiser-identifiants-compte-sentry-partage-30-sites/ ## L’essentiel - Un DSN Sentry partagé mélange les événements de tous les projets dans un même flux - Un compte par projet limite l'impact d'une compromission à un seul client - La rotation planifiée réduit la fenêtre d'exposition d'un identifiant ancien Un compte de monitoring d'erreurs mutualisé entre plusieurs projets clients d'une même agence pose une question rarement posée au moment de sa mise en place initiale : que se passe-t-il si l'un des trente sites qui y remontent ses erreurs est compromis, et que l'attaquant met la main sur le DSN Sentry utilisé pour cette remontée ? Sur ce compte particulier, la réponse était préoccupante : le même DSN, littéralement copié-collé d'un projet client à l'autre lors de leur mise en place respective, donnait accès en écriture au même flux d'événements pour l'ensemble des trente sites du parc. Cette checklist a été construite à la suite d'un audit de sécurité de routine sur ce compte de monitoring mutualisé, avant qu'un incident réel ne survienne, et couvre à la fois le cloisonnement structurel entre projets clients et la rotation périodique des identifiants utilisés. ## Le problème du DSN unique copié entre projets Un DSN Sentry (Data Source Name) est la chaîne de connexion qui permet à l'agent installé sur un site d'envoyer ses événements d'erreur vers un projet Sentry précis. Sur ce parc, l'agence avait initialement créé un seul projet Sentry pour l'ensemble de ses sites clients, par simplicité de mise en place, et distribuait le même DSN à chaque nouveau site pris en charge : ``` define( 'SENTRY_DSN', 'https://exemplecledsn@o123456.ingest.sentry.io/1' ); // identique sur les 30 sites ``` Ce choix initial avait deux conséquences problématiques. D'une part, les événements d'erreur de tous les clients se mélangeaient dans un même flux, rendant le triage quotidien plus difficile pour l'équipe technique de l'agence. D'autre part, et c'est le point qui a motivé l'audit, la compromission d'un seul site suffisait à exposer ce DSN partagé, avec un impact qui dépassait largement le site initialement touché : un DSN compromis permet en théorie d'envoyer des événements arbitraires vers le projet Sentry, y compris des événements construits pour semer la confusion sur les trente sites du parc simultanément. ## Checklist de cloisonnement retenue > L'essentiel à retenir : Un DSN Sentry partagé mélange les événements de tous les projets dans un même flux ; Un compte par projet limite l'impact d'une compromission à un seul client ; La rotation planifiée réduit la fenêtre d'exposition d'un identifiant ancien 1. **Créer un projet Sentry distinct par client**, chacun avec son propre DSN, plutôt qu'un projet unique partagé pour l'ensemble du parc. 2. **Restreindre les accès en lecture** au tableau de bord de chaque projet aux seuls membres de l'équipe réellement en charge du client concerné, via les rôles d'équipe proposés par Sentry. 3. **Documenter, pour chaque site, le DSN qui lui est propre** dans le gestionnaire de secrets de l'agence, sans jamais le recopier d'un site à l'autre lors d'une nouvelle mise en place. 4. **Vérifier qu'aucun DSN historique partagé ne reste actif** une fois la migration vers des projets distincts terminée, ce qui suppose sa révocation explicite côté Sentry. ### La migration technique, site par site La migration d'un DSN partagé vers des DSN individuels ne demande qu'un changement de constante côté chaque site, mais la coordination de trente migrations distinctes a nécessité un suivi rigoureux pour éviter qu'un site ne se retrouve temporairement sans remontée d'erreurs pendant la transition : ``` // avant, sur les 30 sites define( 'SENTRY_DSN', 'https://exemplecledsn@o123456.ingest.sentry.io/1' ); // après, propre à chaque site define( 'SENTRY_DSN', 'https://cledsn-client-precis@o123456.ingest.sentry.io/48' ); ``` Chaque migration a été suivie d'un test de remontée d'erreur volontaire, déclenchée manuellement sur le site concerné, pour confirmer que le nouveau projet Sentry recevait bien l'événement avant de désactiver l'ancien DSN partagé pour ce site précis. ## La rotation périodique, complément indispensable Le cloisonnement par projet ne suffit pas à lui seul : un DSN individuel resté inchangé pendant des années, même correctement cloisonné, reste une cible statique. La checklist intègre donc une rotation planifiée, tous les douze mois, pour chaque projet client : - Génération d'un nouveau DSN côté Sentry pour le projet concerné. - Déploiement de la nouvelle valeur sur le site, avec une courte période de recouvrement où l'ancien DSN reste actif le temps de confirmer le bon fonctionnement du nouveau. - Révocation explicite de l'ancien DSN une fois le nouveau confirmé opérationnel. > Un identifiant qui donne accès à un flux de données, même à un simple flux d'erreurs applicatives, mérite le même traitement qu'un mot de passe : cloisonnement par usage, et rotation régulière plutôt que permanence par défaut. ## Ce que cette checklist ne couvre pas Cette checklist porte exclusivement sur le cloisonnement et la rotation des identifiants d'accès au compte de monitoring. Elle ne traite volontairement pas de la lecture et de l'exploitation des erreurs elles-mêmes une fois remontées, ni du contenu potentiellement sensible que ces erreurs pourraient elles-mêmes véhiculer si elles ne sont pas correctement filtrées à la source, un sujet distinct qui mérite sa propre checklist dédiée. ## En résumé Un compte de monitoring mutualisé entre plusieurs projets clients d'une même agence est une pratique répandue et raisonnable pour des raisons de coût et de simplicité de gestion, à condition que le cloisonnement entre projets soit réel dès la création de chaque site, et non ajouté après coup à la suite d'un audit. La rotation périodique des identifiants complète ce cloisonnement en réduisant, dans la durée, la fenêtre d'exposition de chaque DSN individuel.