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-10-06.

Chiffrement des données #

Les champs sensibles de la base de données énumérés ci-dessous 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 des champs ne couvre ni les sauvegardes complètes de la base de données ni les pièces jointes ; celles-ci sont chiffrées séparément, comme décrit dans les sections pièces jointes et sauvegardes .

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.

Pièces jointes #

Les fichiers joints aux signalements, aux messages et aux notes internes, les enregistrements vocaux et les exports de données de dossier sont chiffrés au repos dans Hetzner Object Storage en AES-256, avec une clé aléatoire distincte pour chaque fichier (chiffrement côté serveur avec des clés fournies par le client). La clé est transmise avec chaque requête de stockage, et Hetzner refuse toute lecture effectuée sans elle. EthicsPortal la conserve dans la base de données sous le chiffrement ActiveRecord Encryption décrit ci-dessus ; les identifiants de stockage ne suffisent donc pas à eux seuls à lire un fichier : la base de données et les clés de chiffrement de l’application sont également nécessaires. Les fichiers parviennent aux utilisateurs autorisés par diffusion en flux via l’application, jamais par un lien direct vers le stockage.

Les fichiers téléversés avant le 6 octobre 2026 ont été rechiffrés à cette date, et leurs copies non chiffrées, y compris les versions antérieures conservées, ont été supprimées. Les fichiers qui ne sont pas des données de signalement, comme les photos de profil et les images de partage des organisations, ne sont pas chiffrés de cette manière. Rien de cela ne protège contre une compromission du serveur applicatif, qui détient à la fois les identifiants de stockage, la base de données et les clés.

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 :

La suppression des métadonnées est effectuée côté serveur avant le stockage. Pour les types de fichiers traités par exiftool, elle suppose la présence de l’outillage de production standard.

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’effectue côté serveur dans un processus en arrière-plan après le téléchargement. Les fichiers qui n’ont pas passé l’analyse sont bloqués à la diffusion, et les fichiers infectés sont supprimés automatiquement.

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 lui-même 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 la procédure d’achat. 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.
• 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 à deux facteurs basée sur TOTP avec n’importe quelle application d’authentification standard (Google Authenticator, 1Password, Authy et alternatives compatibles). Une fois activée, la connexion exige à la fois l’identifiant principal et un code tournant à 6 chiffres.

Les lanceurs d’alerte s’authentifient eux aussi avec deux facteurs : le code d’accès (ce qu’ils détiennent) et le code secret choisi lors de la soumission (ce qu’ils savent). Le code secret est stocké uniquement sous forme de condensat bcrypt et ne peut pas être récupéré. La boîte de suivi et l’envoi de messages sont conditionnés à une session ouverte après cette vérification ; un code d’accès divulgué ne permet donc pas à lui seul de lire le signalement ni d’usurper l’identité du lanceur d’alerte.

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 propriétaire de l’organisation, le dernier administrateur actif et le responsable conformité désigné du dispositif d’alerte 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.

Retirer un membre désactive son adhésion au lieu de la supprimer, afin que la piste d’audit et l’historique des signalements restent résolvables. Une adhésion n’est supprimée définitivement que lorsque le compte du membre lui-même ou l’organisation elle-même est effacé.

Effacement du compte #

Lorsqu’un membre ferme son propre compte, son adresse e-mail est remplacée par une valeur non routable et sa photo de profil, ses éléments d’authentification à deux facteurs, sessions, jetons d’API et préférences sont supprimés définitivement ; le compte ne peut plus s’authentifier ni être contacté. Si le compte n’a jamais agi dans une organisation, l’enregistrement est supprimé purement et simplement. Sinon, le nom du membre est conservé tandis que ses adhésions sont désactivées, afin que les notes de dossier, messages et entrées d’audit conservés restent attribuables. Le Responsable du traitement détermine la durée de conservation selon ses instructions documentées et le droit applicable ; les droits à l’effacement prévus par le RGPD restent soumis aux exceptions applicables au titre d’obligations légales ou de droits en justice.

Un compte nettoyé ne peut s’authentifier par aucune voie : lien magique, assertion SSO ou jeton d’API.

Limitation de débit #

Les points d’accès publics du dispositif d’alerte 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 #

Les événements définis relatifs aux signalements et aux comptes sont enregistrés avec :

• Horodatage (UTC)
• Acteur (quel utilisateur ou processus système a effectué l’action)
• Type d’action (par exemple signalement créé, statut modifié, message envoyé, gestionnaire assigné, signalement exporté ou signalement supprimé). Chaque consultation d’un signalement par un gestionnaire est enregistrée, dédupliquée à une entrée par gestionnaire et par signalement sur 24 heures, et les consultations de suivi par le lanceur d’alerte sont enregistrées de la même manière. Les lectures d’autres ressources ne sont pas enregistrées.

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, un processus en arrière-plan supprime le signalement et les données associées de la production ; les copies de sauvegarde expirent selon le cycle de vie distinct documenté.

Le Responsable du traitement reste tenu de choisir une durée conforme au principe de limitation de la conservation du RGPD et aux règles nationales applicables en matière de tenue de registres.

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 #

• Le stockage central des signalements et des données de dossiers se trouve dans l’Union européenne. La remise des e-mails et la télémétrie applicative reposent sur des chaînes de fournisseurs en aval distinctes ; voir le DPA .
• 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 envoie les notifications aux gestionnaires ainsi que, en option, les accusés de réception et avis de nouveau message aux lanceurs d’alerte. Les avis adressés aux lanceurs d’alerte contiennent l’adresse e-mail du destinataire, le code d’accès au signalement et le lien, mais pas le récit du signalement. La chaîne de support en aval de Mailjet peut impliquer des accès depuis l’extérieur de l’EEE ; voir le DPA .
• Le site de présentation est servi via Cloudflare (CDN, États-Unis) ; le dispositif d’alerte et l’interface 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é , et non dans la liste des sous-traitants ultérieurs du DPA client.

Sauvegardes et restauration #

EthicsPortal exploite trois couches de sauvegarde complémentaires, toutes 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 s’exécute automatiquement chaque mois via un flux CI, ainsi qu’à la demande, en restaurant la dernière sauvegarde dans un environnement jetable. Il déchiffre la sauvegarde, la restaure, compare chaque table avec la production en service, puis démarre l’application sur la base restaurée pour confirmer qu’une colonne chiffrée se déchiffre toujours, qu’une pièce jointe chiffrée s’ouvre avec la clé contenue dans la sauvegarde restaurée et que chaque pièce jointe de plus d’une heure dispose d’une copie intacte dans l’emplacement de sauvegarde — le seul nombre de lignes ne permet pas de distinguer une sauvegarde exploitable d’un texte chiffré dont la clé ne correspond plus. La fraîcheur des sauvegardes est surveillée en continu (alerte si la sauvegarde la plus récente date de plus de 36 heures).

Chiffrement. Selon 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 de la couche applicative chiffrés avec ActiveRecord Encryption de Rails restent chiffrés séparément à l’intérieur de chaque sauvegarde. Les pièces jointes sont chiffrées au repos avec une clé propre à chaque fichier (voir pièces jointes ). Ces clés n’existent que dans la base de données ; chaque sauvegarde chiffrée les contient donc. Les fichiers eux-mêmes ne sont pas copiés dans la sauvegarde. Chacun est stocké à Nuremberg et copié, sous la même clé, dans un second bucket à Falkenstein ; les deux conservent les versions antérieures pendant 30 jours.

Revue opérationnelle #

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é. La divulgation n’est pas rémunérée : nous ne payons 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: 12 octobre 2026