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-05-17.

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é #

Anonymisation des adresses IP #

EthicsPortal ne stocke jamais les adresses IP. Les routes du portail (soumission de signalement, consultation de dossier, messagerie) utilisent un hachage SHA256 à sens unique de l’adresse IP uniquement pour la limitation de débit. Le hachage n’est pas réversible — il est impossible de retrouver l’adresse IP d’origine à partir de la valeur stockée.

Cela s’applique à tous les points d’accès publics du portail. Aucune adresse IP n’est inscrite dans aucun journal, champ de base de données ou système d’analyse.

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 — sans cookies, sans collecte de données personnelles et entièrement conforme au RGPD. Le portail de signalement lui-même ne comporte aucune mesure d’audience.

Statut actuel d’assurance #

EthicsPortal ne revendique actuellement sur ce site ni ISO 27001, ni SOC 2, ni certification équivalente. 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.

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.

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 à sens unique de l’adresse IP décrit ci-dessus — aucune adresse IP réelle n’est stockée.

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. Une fois créées, elles ne peuvent être modifiées par aucun utilisateur, y compris les administrateurs de l’organisation. 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 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.

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.
• importmap audit analyse les imports JavaScript à la recherche de vulnérabilités connues à chaque modification.
• 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 principal des données 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. La liste complète et les garanties de transfert figurent sur la page sous-traitants ultérieurs .

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é au moins une fois par trimestre dans un environnement jetable. Dernier exercice : 2026-05-14.

Chiffrement. Les sauvegardes de la base de données sont chiffrées au repos par Hetzner Object Storage ; les champs chiffrés au niveau applicatif via Rails ActiveRecord Encryption restent chiffrés 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.

Dernière mise à jour: 25 mai 2026