Ce guide explique quelles informations personnellement identifiables (PII) Discourse stocke par défaut, où elles sont stockées, qui peut y accéder et comment vous pouvez minimiser la collecte de PII en utilisant DiscourseConnect.
Niveau d’utilisateur requis : Administrateur
Discourse stocke certaines informations personnellement identifiables (PII) 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 de PII, y compris les adresses IP, les adresses e-mail et les informations d’identification de connexion sociale. Ces informations sont principalement utilisées pour la modération, la détection des comptes dupliqués et l’authentification des utilisateurs. Les administrateurs de site peuvent minimiser le stockage des PII en implémentant DiscourseConnect (SSO), ce qui vous permet de contrôler les informations transmises à Discourse.
Quelles PII 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 dupliqués :
- Adresse IP d’inscription - L’adresse IP utilisée lors de la création du compte
- Dernière adresse IP utilisée - L’adresse IP la plus récente à partir de laquelle l’utilisateur a accédé au site
Par exemple, si vous visitez votre site depuis votre appareil mobile à 11h00, puis depuis votre tablette à 12h00, seule l’adresse IP de la tablette sera stockée comme 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 de site
moderators_view_ips) - Le système - Utilise les adresses IP en interne pour la détection des spams et l’identification des comptes dupliqués
Adresses e-mail
Les adresses e-mail sont stockées en texte brut dans la base de données, visibles par toute personne ayant 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 - Peuvent voir les adresses e-mail par défaut (peut être désactivé avec le paramètre de site
moderators_view_emails) - Administrateurs de base de données - Toute personne ayant un accès direct à la base de données
Noms complets (vrais noms)
Discourse peut collecter et stocker les noms complets des utilisateurs (également appelés « vrais noms »), qui sont distincts de leurs noms d’utilisateur. Les noms complets sont stockés en texte brut dans la base de données avec d’autres informations utilisateur.
Comment les noms complets sont collectés
Les noms complets peuvent être fournis de plusieurs manières :
- Pendant l’inscription - Les utilisateurs peuvent saisir 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 du profil - Les utilisateurs peuvent ajouter ou mettre à jour leur nom complet à partir de leurs préférences de profil
- À partir des 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 dans la base de données et sont 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 en fonction des paramètres d’affichage
enable_nameset associés
Options de configuration
Les administrateurs peuvent contrôler la manière dont les noms complets sont collectés et affichés à l’aide des paramètres de site suivants :
-
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 SSO/DiscourseConnect ne peut pas être modifié par les utilisateurs- Utile pour maintenir une identité cohérente sur tous 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 lors de l’inscription -
enable_names- Commutateur principal qui affiche le nom complet de l’utilisateur sur son profil, sa carte utilisateur et ses e-mails. Désactivez pour masquer le nom complet partout- Par défaut : activé
Les paramètres d’affichage suivants n’entrent en vigueur 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 proéminente dans l’interface- Par défaut : activé (le nom d’utilisateur est prioritaire)
display_name_on_email_from- Utilise le nom complet dans les champs « De » des notifications par 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 tirets bas et la casse), un seul sera affiché pour éviter la redondance. Vous pouvez désactiver ce comportement à l’aide du composant de thème Remove Name Suppression on Posts, qui force l’affichage 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 divers éléments d’information :
- ID de compte du fournisseur
- Nom
- Avatar
- [Cette liste peut changer en fonction du 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 : Connexion Facebook OAuth
Un exemple expurgé 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 en fonction du 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é en fonction de la configuration du site
- Utilisateurs individuels - Peuvent visualiser et gérer leurs propres comptes associés à partir de leurs préférences utilisateur
Minimiser le stockage des PII 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 aux PII
Avec DiscourseConnect, vous contrôlez entièrement les informations utilisateur renvoyées à Discourse. Comme vous gérez l’implémentation, vous pouvez créer des alternatives axées sur la confidentialité aux identifiants traditionnels.
Approche d’exemple : Au lieu de fournir à Discourse l’adresse e-mail réelle de l’utilisateur, vous pouvez créer une adresse e-mail unique mais sans PII.
Par exemple, si l’ID unique interne d’un utilisateur est U123456, vous pourriez renvoyer une adresse e-mail comme :
user-U123456@example.com
Avantages supplémentaires pour la confidentialité
L’utilisation de DiscourseConnect masque également toute connexion aux connexions sociales fédérées depuis 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
Le MFA peut-il être appliqué en plus de l’authentification externe ?
Cette combinaison n’est actuellement pas prise en charge de la manière attendue.
Discourse dispose du paramètre de site enforce_second_factor_on_external_auth, qui empêche les utilisateurs ayant le MFA activé d’utiliser des méthodes d’authentification externes telles que les connexions sociales. Lorsqu’il est activé, cela empêchera les utilisateurs de se connecter avec des méthodes d’authentification externes s’ils ont activé l’authentification à deux facteurs.
Ce paramètre oblige effectivement 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, implémentez le MFA dans votre fournisseur d’identité plutôt que dans Discourse.