Ce guide explique quelles informations personnellement identifiables (IPI) Discourse stocke par défaut, où elles sont stockées, qui peut y accéder et comment vous pouvez minimiser la collecte d’IPI en utilisant DiscourseConnect.
Niveau d’utilisateur requis : Administrateur
Discourse stocke certaines informations personnellement identifiables (IPI) pour prendre en charge les fonctionnalités de base telles que la modération, la gestion des comptes et l’authentification des utilisateurs. Comprendre quelles données sont collectées et comment elles sont stockées vous aide à prendre des décisions éclairées concernant la confidentialité et la conformité.
Résumé
Discourse stocke plusieurs types d’IPI, notamment les adresses IP, les adresses e-mail et les identifiants de connexion sociale. Ces informations sont principalement utilisées pour la modération, la détection de comptes en double et l’authentification des utilisateurs. Les administrateurs de site peuvent minimiser le stockage d’IPI en mettant en œuvre DiscourseConnect (SSO), ce qui vous permet de contrôler quelles informations sont transmises à Discourse.
Quelles IPI Discourse stocke-t-il ?
Adresses IP
Discourse stocke les adresses IP suivantes pour chaque utilisateur afin d’aider votre équipe de modération à détecter les comptes en double :
- Adresse IP d’inscription - L’adresse IP utilisée lors de la création du compte
- Dernière adresse IP utilisée - La dernière adresse IP à partir de laquelle l’utilisateur a accédé au site
Par exemple, si vous visitez votre site sur votre appareil mobile à 11h00, puis sur votre tablette à 12h00, seule l’adresse IP de la tablette sera stockée en tant qu’adresse IP « dernière utilisée ».
Qui peut accéder aux adresses IP
- Administrateurs - Accès complet à toutes les informations IP
- Modérateurs - Peuvent voir les adresses IP par défaut (peut être désactivé avec le paramètre du site
moderators_view_ips) - Le système - Utilise les adresses IP en interne pour la détection de spam et l’identification de comptes en double
Adresses e-mail
Les adresses e-mail sont stockées en texte brut dans la base de données, visibles par toute personne ayant un accès à la base de données. Cela inclut :
Qui peut accéder aux adresses e-mail
- Administrateurs - Accès complet à toutes les adresses e-mail
- Modérateurs - Ne peuvent pas voir les adresses e-mail par défaut (peut être activé avec le paramètre du site
moderators_view_emails) - Administrateurs de base de données - Toute personne ayant un accès direct à la base de données
Noms complets (noms réels)
Discourse peut collecter et stocker les noms complets des utilisateurs (également appelés « noms réels »), qui sont distincts de leurs noms d’utilisateur. Les noms complets sont stockés en texte brut dans la base de données, aux côtés des autres informations utilisateur.
Comment les noms complets sont collectés
Les noms complets peuvent être fournis de plusieurs manières :
- Lors de l’inscription - Les utilisateurs peuvent entrer leur nom complet lors du processus d’inscription (selon la configuration)
- Via SSO/DiscourseConnect - Le fournisseur d’authentification externe peut transmettre le nom complet (champ
name) lors de la création ou de la mise à jour d’un utilisateur, et peut remplacer le nom local si configuré. - Via l’édition de profil - Les utilisateurs peuvent ajouter ou mettre à jour leur nom complet dans leurs préférences de profil
- À partir de connexions sociales - Lorsque les utilisateurs s’authentifient via des fournisseurs sociaux, leur nom d’affichage est souvent utilisé comme nom complet
Qui peut accéder aux noms complets
Les noms complets sont stockés en texte brut dans la colonne name de la table users de la base de données et peuvent être accessibles par :
- Administrateurs - Accès complet à tous les noms complets
- Modérateurs - Peuvent voir les noms complets par défaut (contrôlé par les mêmes autorisations que l’accès aux e-mails)
- Administrateurs de base de données - Toute personne ayant un accès direct à la base de données.
- Utilisateurs publics - Peuvent voir les noms complets selon les paramètres
enable_nameset les paramètres d’affichage connexes
Options de configuration
Les administrateurs peuvent contrôler la manière dont les noms complets sont collectés et affichés en utilisant ces paramètres du site :
-
full_name_requirement- Contrôle si le champ du nom complet apparaît lors de l’inscription et s’il est obligatoire -
auth_overrides_name- Lorsqu’il est activé, le nom provenant de votre fournisseur d’authentification externe (y compris SSO/DiscourseConnect et les connexions sociales) ne peut pas être modifié par les utilisateurs- Utile pour maintenir une identité cohérente dans vos systèmes
-
use_name_for_username_suggestions- Lorsqu’il est activé, Discourse utilisera le nom complet lors de la suggestion de noms d’utilisateur pendant l’inscription -
enable_names- Interrupteur principal qui affiche le nom complet de l’utilisateur sur son profil, sa carte utilisateur et les e-mails. Désactivez pour masquer le nom complet partout- Par défaut : activé
Les paramètres d’affichage suivants ne prennent effet que lorsque enable_names est activé :
display_name_on_posts- Affiche le nom complet d’un utilisateur sur ses publications, en plus de son @nomdutilisateurprioritize_username_in_ux- Contrôle si le nom d’utilisateur ou le nom complet apparaît de manière plus visible dans l’interface- Par défaut : activé (le nom d’utilisateur a la priorité)
display_name_on_email_from- Utilise le nom complet dans les champs « De » des notifications e-mail, si activé.
Discourse dispose d’une déduplication intelligente ; si le nom complet et le nom d’utilisateur d’un utilisateur sont très similaires (en ignorant les espaces, les underscores et la casse), un seul sera affiché pour éviter la redondance. Vous pouvez désactiver ce comportement en utilisant le composant de thème Remove Name Suppression on Posts, qui force l’affichage permanent du nom complet et du nom d’utilisateur sur les publications.
Informations de connexion sociale fédérée
Lorsque les utilisateurs s’authentifient via des fournisseurs de connexion sociale (Google, Facebook, GitHub, etc.), Discourse stocke diverses informations :
- ID de compte du fournisseur
- Nom
- Avatar
- [Cette liste peut changer selon le fournisseur ou au fil du temps]
Les données spécifiques stockées dépendent du fournisseur et des informations qu’il partage.
Exemple : Google OAuth2
Lorsqu’un utilisateur se connecte avec Google, Discourse conserve les informations suivantes dans la base de données :
provider_name: "google_oauth2",
provider_uid: "11791234567812345",
info: {
"name" => "Bilbo Baggins",
"email" => "bilbo.baggins@gmail.com",
"image" => "https://lh3.googleusercontent.com/a/ACg8ocJD5vR-JuZZ16mGf51uYH0KyKGoKXF36U3inbh4Bzne0CpuTlH23g=s96-c",
"last_name" => "Baggins",
"first_name" => "Bilbo",
"email_verified" => true,
"unverified_email" => "bilbo.baggins@gmail.com"
}
Exemple : Facebook OAuth
Un exemple masqué pour la connexion Facebook montre :
provider_name: "facebook",
provider_uid: "123456789",
info: {
"name" => "Bilbo Baggins",
"email" => "bbaggins@shire.net",
"image" => "https://graph.facebook.com/v5.0/123456789/picture?access_token=swordfish&width=480&height=480",
"last_name" => "Baggins",
"first_name" => "Bilbo"
}
Les champs spécifiques stockés peuvent changer selon le fournisseur ou au fil du temps à mesure que les protocoles d’authentification évoluent.
Qui peut accéder aux informations de connexion sociale
- Administrateurs - Accès complet aux informations de compte associées via le panneau d’administration et la base de données
- Modérateurs - Peuvent avoir un accès limité selon la configuration du site
- Utilisateurs individuels - Peuvent voir et gérer leurs propres comptes associés depuis leurs préférences utilisateur
Minimiser le stockage d’IPI avec DiscourseConnect
Pour éviter de stocker certaines informations personnellement identifiables dans Discourse, vous pouvez utiliser DiscourseConnect pour gérer entièrement le processus de connexion de vos utilisateurs.
Comment DiscourseConnect réduit l’exposition des IPI
Avec DiscourseConnect, vous contrôlez entièrement les informations utilisateur renvoyées à Discourse. Puisque vous gérez la mise en œuvre, vous pouvez créer des alternatives axées sur la confidentialité aux identifiants traditionnels.
Approche exemple : Au lieu de donner à Discourse l’adresse e-mail réelle de l’utilisateur, vous pouvez créer une adresse e-mail unique mais sans IPI.
Par exemple, si l’ID unique interne d’un utilisateur est U123456, vous pouvez renvoyer une adresse e-mail telle que :
user-U123456@example.com
Avantages supplémentaires en matière de confidentialité
L’utilisation de DiscourseConnect masque également toute connexion aux connexions sociales fédérées de Discourse. Du point de vue de Discourse, le type de connexion utilisé par l’utilisateur (social, mobile, etc.) est sans importance, car cela est géré de votre côté. Discourse ne sait que ce que le fournisseur de connexion lui indique.
MFA et authentification externe
La MFA peut-elle être imposée par-dessus l’authentification externe ?
Cette combinaison n’est actuellement pas prise en charge de la manière attendue.
Discourse dispose du paramètre du site enforce_second_factor_on_external_auth, qui empêche les utilisateurs ayant la MFA activée d’utiliser des méthodes d’authentification externe telles que les connexions sociales. Lorsqu’il est activé, cela empêchera les utilisateurs de se connecter avec des méthodes d’authentification externe s’ils ont l’authentification à deux facteurs activée.
Ce paramètre oblige essentiellement les utilisateurs à choisir entre :
- Utiliser l’authentification externe (connexions sociales) sans 2FA sur Discourse
- Utiliser la connexion nom d’utilisateur/mot de passe avec 2FA sur Discourse
Pour la configuration la plus sécurisée avec SSO, mettez en œuvre la MFA dans votre fournisseur d’identité plutôt que dans Discourse.