Sécurité #

EthicsPortal traite des données sensibles de lanceurs d’alerte. Cette page documente les mesures techniques et organisationnelles spécifiques que nous avons mises en place. Elle est rédigée à l’attention des responsables conformité, des DPO et des équipes juridiques évaluant la plateforme.

Dernière mise à jour : 2026-08-28.

Chiffrement des données #

Tous les champs sensibles sont chiffrés au repos à l’aide du chiffrement ActiveRecord Encryption de Rails avec un chiffrement non déterministe (chaque opération de chiffrement produit un texte chiffré unique, empêchant l’analyse de motifs).

Le chiffrement non déterministe signifie que ces champs ne peuvent pas être interrogés par valeur au niveau de la base de données. Même avec un accès complet à la base de données, un attaquant ne peut pas rechercher un nom de lanceur d’alerte spécifique dans l’ensemble des enregistrements.

Toutes les connexions à EthicsPortal utilisent HTTPS/TLS. Les requêtes HTTP non chiffrées sont redirigées.

Anonymat et confidentialité #

Adresses IP #

EthicsPortal n’enregistre pas l’adresse IP d’un lanceur d’alerte avec les signalements, les messages ou les enregistrements d’audit, et les journaux de l’application pour le dispositif d’alerte ne contiennent aucune adresse IP.

La limitation de débit sur le dispositif d’alerte (soumission de signalement, consultation de dossier, messagerie) repose sur un hachage SHA-256 à clé et tronqué de l’adresse IP de la requête. Ce hachage est pseudonyme, et non anonyme : il ne peut pas être relu comme une adresse, mais toute personne détenant le secret de l’application pourrait tester des adresses candidates. Il n’est utilisé que pendant la fenêtre de limitation (10 minutes au plus) et conservé dans un cache de taille plafonnée.

Le proxy TLS placé devant l’application tient ses propres journaux de connexion, qui contiennent des adresses IP. Ils ne sont pas liés aux signalements. Ils sont conservés dans un fichier journal unique de 10 Mo, écrasé en continu, actuellement en quelques heures ; les instantanés de serveur de 7 jours décrits dans la section sauvegardes peuvent en contenir une copie.

Suppression des métadonnées des fichiers #

Les fichiers téléchargés sont automatiquement nettoyés de leurs métadonnées d’identification avant le stockage :

Les lanceurs d’alerte n’ont pas besoin de faire confiance quant à la sécurité de leurs fichiers — les métadonnées sont supprimées côté serveur, quel que soit le contenu du fichier.

Analyse antivirus #

Tous les fichiers téléchargés sont automatiquement analysés à la recherche de logiciels malveillants à l’aide de ClamAV , un moteur antivirus open source. L’analyse s’effectué côté serveur dans un processus en arrière-plan après le téléchargement. Les fichiers infectés sont supprimés automatiquement et n’atteignent jamais les gestionnaires de dossiers.

Les fichiers sont analysés sur l’infrastructure d’EthicsPortal — aucune donnée de fichier n’est envoyée à des services d’analyse tiers.

Anonymat du gestionnaire #

Les lanceurs d’alerte ne voient jamais les noms réels ni les adresses e-mail des personnes qui traitent leur signalement. Tous les messages des gestionnaires sont affichés sous le nom « Gestionnaire du dossier ». Cela protège l’identité du gestionnaire et empêche l’ingénierie sociale.

Aucun traçage #

EthicsPortal n’utilise pas de cookies de traçage tiers, de pixels publicitaires ni de scripts d’empreinte numérique. Nous utilisons Cloudflare Web Analytics uniquement sur les pages marketing. Il ne dépose pas de cookies d’analyse, mais Cloudflare peut traiter des métadonnées de requête, notamment des adresses IP, comme décrit dans la Politique de confidentialité . Le dispositif d’alerte ne comporte aucune mesure d’audience.

Statut actuel d’assurance #

EthicsPortal ne revendique actuellement sur ce site aucune certification ISO 27001 accréditée. Il ne publie pas non plus actuellement d’audit tiers indépendant de l’architecture d’anonymat. Si cela change, le périmètre et la date seront publiés ici.

Documents pour la revue de sécurité #

Les clients qui ont besoin de documents pour une validation par le service achats ou juridique peuvent les demander pendant l’évaluation. Les éléments disponibles peuvent inclure un DPA contresigné, des justificatifs d’immatriculation et fiscaux, un questionnaire de sécurité complété et des réponses écrites sur les procédures de sauvegarde et de restauration, les accès privilégiés à la production et la réponse aux incidents.

Contrôle d’accès #

L’autorisation est appliquée au niveau applicatif à l’aide de politiques Pundit .

• Les gestionnaires ne peuvent pas voir les signalements qui ne leur sont ni assignés ni partagés en tant que participants. Les participants sont ajoutés explicitement par un administrateur ou par le responsable principal (par exemple pour impliquer le service juridique ou les RH).
• Les lanceurs d’alerte n’ont pas de compte utilisateur — ils accèdent à leur signalement à l’aide d’un code d’accès (WB-XXXX-XXXX) et d’un code secret à 6 chiffres qu’ils choisissent au moment de la soumission. Les deux sont requis. Le code secret est stocké uniquement sous forme de condensat bcrypt et ne peut pas être récupéré.
• Chaque action de contrôleur vérifie l’autorisation. Les tentatives d’accès non autorisées sont bloquées et enregistrées.

Authentification à deux facteurs #

Les comptes de gestionnaire et d’administrateur peuvent activer l’authentification TOTP avec une application d’authentification standard. Une fois activée, la connexion exige le lien magique et un code temporaire à six chiffres. Les lanceurs d’alerte utilisent séparément l’identifiant du dossier et le code d’accès choisi lors de l’envoi ; le code est conservé uniquement sous forme de condensat bcrypt.

Cycle de vie des sessions #

Chaque session authentifiée enregistre last_seen_at à chaque requête (avec antirebond). Les utilisateurs peuvent consulter leurs sessions actives, voir la date de dernière activité de chacune, révoquer une session individuellement ou se déconnecter de toutes les autres sessions en une seule action depuis les paramètres de leur compte.

Les sessions expirent automatiquement après 14 jours d’inactivité. La requête suivante d’une session inactive détruit l’enregistrement côté serveur, efface le cookie et impose une nouvelle authentification via un lien magique. Un job nocturne nettoie les sessions abandonnées selon le même délai, de sorte que user_agent et ip_address ne sont pas conservés au-delà de la fenêtre d’inactivité, même si l’utilisateur ne revient jamais.

L’authentification par lien magique limite la portée des sessions de longue durée : un cookie de session volé ne fournit pas d’identifiant réutilisable, et la ré-authentification exige l’accès à la messagerie.

Accès et départ des membres #

L’accès à l’organisation est appliqué au niveau de la requête. Lorsqu’un membre est désactivé :

• L’accès à l’organisation est refusé immédiatement, y compris sur les URL précédemment mises en favoris.
• Les signalements ouverts qui lui étaient assignés sont retirés.
• Ses participations sont supprimées.
• L’historique du journal d’audit qui lui est attribuable est préservé.
• Le membre désactivé est notifié.
• Une réactivation ne rétablit pas automatiquement l’accès aux dossiers antérieurs.

Le dernier administrateur actif et le propriétaire de l’organisation ne peuvent pas être désactivés. Tous les événements de désactivation et de réactivation sont inscrits dans le journal d’audit en ajout seul.

Les adhésions sans empreinte de conformité (aucune entrée dans le journal d’audit, aucune assignation, aucune participation) sont supprimées définitivement à la suppression ; les adhésions ayant une empreinte sont désactivées en mode logique afin que la piste d’audit reste résolvable.

Effacement du compte #

Lorsqu’un membre ferme son propre compte, son adresse e-mail est remplacée par une valeur non routable et ses éléments d’authentification à deux facteurs, sessions, jetons d’API et préférences sont supprimés définitivement. S’il n’a jamais agi dans une organisation, l’enregistrement est supprimé. Sinon, son nom et sa photo restent associés aux dossiers et au journal d’audit, tandis que ses adhésions sont désactivées, afin de préserver l’attribution exigée par les obligations de conservation.

Limitation de débit #

Les points d’accès publics du portail sont limités en débit pour prévenir les abus et les attaques par énumération :

La limitation de débit utilise le hachage à clé de l’adresse IP décrit ci-dessus — aucune adresse IP n’est conservée à cette fin.

Audit et conformité #

Journal d’audit en ajout seul #

Chaque action dans EthicsPortal est enregistrée avec :

• Horodatage (UTC)
• Acteur (quel utilisateur ou processus système a effectué l’action)
• Type d’action (signalement créé, statut modifié, message envoyé, gestionnaire assigné, signalement consulté, signalement exporté, signalement supprimé, etc.)

Les entrées du journal d’audit sont en ajout seul. Aucun utilisateur, y compris un administrateur de l’organisation, ne peut modifier une entrée ni en supprimer une de façon sélective : des déclencheurs PostgreSQL rejettent la modification et le truncate au niveau de la base de données. Les entrées ne sont supprimées que par le cycle de conservation ou lors de la suppression de l’organisation elle-même, et une intervention privilégiée en base reste un risque résiduel documenté (registre des risques R-08 ). Le journal d’audit complet est inclus dans les exports PDF des dossiers pour l’examen réglementaire.

Conservation des données #

Les organisations configurent leur propre durée de conservation : 12, 24, 36, 48 ou 60 mois après la clôture d’un signalement. Lorsque la durée de conservation expire, le signalement et toutes les données associées (messages, pièces jointes, entrées du journal d’audit) sont automatiquement et définitivement supprimés par un processus en arrière-plan.

Cela satisfait les exigences de limitation de la conservation du RGPD (Art. 5(1)(e)) et les obligations de tenue de registres de la Directive 2019/1937 (Art. 17–18).

Protection CSRF #

Toutes les soumissions de formulaires sont protégées contre les attaques de falsification de requêtes intersites grâce aux jetons CSRF intégrés de Rails.

Cycle de développement sécurisé #

EthicsPortal suit un cycle de développement documenté pour toute modification touchant le Service. Les étapes sont exposées ici afin qu’un évaluateur achats puisse les rattacher aux mesures A.8.25–A.8.29 de la norme ISO/IEC 27001:2022 (voir la cartographie des mesures pour la correspondance complète).

Gestion des dépendances et des correctifs #

EthicsPortal ne déploie aucun composant logiciel en fin de vie. L’application s’exécute sur des versions activement maintenues de Rails, Ruby, PostgreSQL et du système d’exploitation sous-jacent ; les correctifs de sécurité amont sont appliqués en continu.

Les dépendances sont analysées en continu dans l’intégration continue :

• Brakeman signale les vulnérabilités spécifiques à Rails à chaque modification.
• bundler-audit vérifie le Gemfile face à la Ruby Advisory Database à chaque modification et de nouveau chaque jour selon une planification, afin que les vulnérabilités nouvellement divulguées soient détectées même sans modification du code.
• importmap audit analyse les imports JavaScript à la recherche de vulnérabilités connues à chaque modification et de nouveau chaque jour selon une planification.
• Dependabot ouvre chaque semaine des pull requests pour les gems Ruby et les GitHub Actions obsolètes, regroupées par mises à jour mineures/correctives.

Les composants atteignant leur fin de vie amont sont remplacés ou mis à niveau avant la clôture de leur fenêtre de support.

Infrastructure #

• Tout le traitement central des signalements et des données de dossiers a lieu au sein de l’Union européenne.
• Aucun numéro de carte de crédit ni identifiant de paiement n’est stocké sur les serveurs d’EthicsPortal. Toutes les données de paiement sont gérées par Stripe.
• Mailjet est utilisé pour les e-mails transactionnels (notifications aux gestionnaires, pas aux lanceurs d’alerte). Mailjet est basé en France et traite toutes les données au sein de l’UE.
• Le site de présentation est servi via Cloudflare (CDN, États-Unis) ; le portail de signalement et le portail des gestionnaires ne le sont pas. Ce traitement distinct du site public et ses garanties de transfert sont décrits dans la Politique de confidentialité .

Sauvegardes et restauration #

EthicsPortal exploite deux couches de sauvegarde complémentaires, toutes deux conservées au sein de l’UE :

Objectifs de reprise. L’objectif de point de reprise (RPO) est de 24 heures. L’objectif de temps de reprise (RTO) est de 4 heures. Ces objectifs figurent également dans l’accord de niveau de service .

Tests de restauration. Un exercice de restauration est exécuté automatiquement chaque mois via un flux CI dans un environnement jetable. La fraîcheur des sauvegardes est surveillée en continu.

Chiffrement. Hetzner Object Storage ne chiffre pas les objets au repos par défaut ; les sauvegardes de la base sont donc chiffrées avant de quitter le serveur : GnuPG symétrique AES-256, la phrase secrète n’étant détenue que par le processus de sauvegarde et déposée hors de la machine. Les champs chiffrés par l’application le restent séparément à l’intérieur de la sauvegarde. Les pièces jointes demeurent une lacune ouverte : elles sont téléversées sans chiffrement côté serveur et ne figurent pas dans la sauvegarde.

Revue opérationnelle #

Cette page est un résumé public de la sécurité. Une partie des documents opérationnels est partagée pendant la validation par le service achats plutôt que publiée intégralement sur le web ouvert, car elle contient des détails d’infrastructure et de réponse mieux adaptés à une diffusion contrôlée.

Les sujets disponibles sur demande pendant la validation par le service achats incluent notamment :

• Synthèse des accès privilégiés à la production
• Procédure de réponse aux incidents et contacts d’escalade
• Réponses sur la continuité d’activité et la résiliation / restitution des données client

Divulgation responsable #

Si vous découvrez une vulnérabilité de sécurité dans EthicsPortal, veuillez la signaler à security@ethicsportal.eu . Nous vous demandons de :

1. Ne pas divulguer publiquement la vulnérabilité avant que nous ayons eu l’occasion de la corriger.
2. Fournir suffisamment de détails pour que nous puissions reproduire et résoudre le problème.
3. Ne pas accéder aux données d’autres clients ni les modifier.

Nous accuserons réception de votre signalement dans un délai de 2 jours ouvrés et nous nous efforcerons de résoudre rapidement les vulnérabilités confirmées.

Pas de programme de bug bounty rémunéré. Nous ne rémunérons pas les signalements de vulnérabilités et nous ne signons pas d’accord de confidentialité, n’acceptons pas de conditions commerciales et ne tenons pas d’appel comme préalable à la réception d’un signalement. Envoyez l’actif concerné, les étapes de reproduction et l’impact que vous avez établi à l’adresse ci-dessus.

Dernière mise à jour: 30 septembre 2026