Este guia explica quais informações de identificação pessoal (PII) o Discourse armazena por padrão, onde são armazenadas, quem pode acessá-las e como você pode minimizar a coleta de PII usando o DiscourseConnect.
Nível de usuário necessário: Administrador
O Discourse armazena certas informações de identificação pessoal (PII) para suportar funcionalidades centrais como moderação, gerenciamento de contas e autenticação de usuários. Entender quais dados são coletados e como são armazenados ajuda você a tomar decisões informadas sobre privacidade e conformidade.
Resumo
O Discourse armazena vários tipos de PII, incluindo endereços IP, endereços de e-mail e credenciais de login social. Essas informações são usadas principalmente para moderação, detecção de contas duplicadas e autenticação de usuários. Os administradores do site podem minimizar o armazenamento de PII implementando o DiscourseConnect (SSO), que permite controlar quais informações são passadas para o Discourse.
Que PII o Discourse armazena?
Endereços IP
O Discourse armazena os seguintes endereços IP para cada usuário para auxiliar sua equipe de moderação na detecção de contas duplicadas:
- Endereço IP de registro - O endereço IP usado quando a conta foi criada
- Último endereço IP usado - O endereço IP mais recente do qual o usuário acessou o site
Por exemplo, se você visitar seu site em seu dispositivo móvel às 11:00 e depois em seu tablet às 12:00, apenas o endereço IP do tablet será armazenado como o endereço IP “último usado”.
Quem pode acessar endereços IP
- Administradores - Acesso total a todas as informações de IP
- Moderadores - Podem visualizar endereços IP por padrão (pode ser desativado com a configuração do site
moderators_view_ips) - O sistema - Usa endereços IP internamente para detecção de spam e identificação de contas duplicadas
Endereços de e-mail
Os endereços de e-mail são armazenados como texto simples no banco de dados, visíveis para qualquer pessoa com acesso ao banco de dados. Isso inclui:
Quem pode acessar endereços de e-mail
- Administradores - Acesso total a todos os endereços de e-mail
- Moderadores - Podem visualizar endereços de e-mail por padrão (pode ser desativado com a configuração do site
moderators_view_emails) - Administradores de banco de dados - Qualquer pessoa com acesso direto ao banco de dados
Nomes completos (nomes reais)
O Discourse pode coletar e armazenar os nomes completos dos usuários (também referidos como “nomes reais”), que são separados de seus nomes de usuário. Os nomes completos são armazenados como texto simples no banco de dados, juntamente com outras informações do usuário.
Como os nomes completos são coletados
Os nomes completos podem ser fornecidos de várias maneiras:
- Durante o registro - Os usuários podem inserir seu nome completo durante o processo de inscrição (dependendo da configuração)
- Via SSO/DiscourseConnect - O provedor de autenticação externo pode passar o nome completo (campo
name) ao criar ou atualizar um usuário, e pode substituir o nome local se configurado. - Através da edição de perfil - Os usuários podem adicionar ou atualizar seu nome completo em suas preferências de perfil
- De logins sociais - Quando os usuários se autenticam por meio de provedores sociais, o nome de exibição deles é frequentemente usado como o nome completo
Quem pode acessar nomes completos
Os nomes completos são armazenados como texto simples na coluna name da tabela users no banco de dados e podem ser acessados por:
- Administradores - Acesso total a todos os nomes completos
- Moderadores - Podem visualizar nomes completos por padrão (controlado pelas mesmas permissões de acesso a e-mail)
- Administradores de banco de dados - Qualquer pessoa com acesso direto ao banco de dados.
- Usuários públicos - Podem ver nomes completos dependendo das configurações de exibição
enable_namese relacionadas
Opções de configuração
Os administradores podem controlar como os nomes completos são coletados e exibidos usando estas configurações do site:
-
full_name_requirement- Controla se o campo de nome completo aparece durante a inscrição e se é obrigatório -
auth_overrides_name- Quando ativado, o nome do seu provedor SSO/DiscourseConnect não pode ser alterado pelos usuários- Útil para manter a identidade consistente em seus sistemas
-
use_name_for_username_suggestions- Quando ativado, o Discourse usará o nome completo ao sugerir nomes de usuário durante o registro -
enable_names- Chave mestra que mostra o nome completo do usuário em seu perfil, cartão de usuário e e-mails. Desative para ocultar o nome completo em todos os lugares- Padrão: ativado
As seguintes configurações de exibição só entram em vigor quando enable_names está ativado:
display_name_on_posts- Mostra o nome completo de um usuário em suas postagens, além do seu @nome de usuárioprioritize_username_in_ux- Controla se o nome de usuário ou o nome completo aparece com mais destaque na interface- Padrão: ativado (o nome de usuário tem prioridade)
display_name_on_email_from- Usa o nome completo nos campos “De” em notificações por e-mail, se ativado.
O Discourse tem deduplicação inteligente; se o nome completo e o nome de usuário de um usuário forem muito semelhantes (ignorando espaços, sublinhados e capitalização), apenas um será exibido para evitar redundância. Você pode desativar esse comportamento usando o componente de tema Remove Name Suppression on Posts, que força tanto o nome completo quanto o nome de usuário a serem sempre exibidos nas postagens.
Informações de login social federado
Quando os usuários se autenticam por meio de provedores de login social (Google, Facebook, GitHub, etc.), o Discourse armazena vários pedaços de informação:
- ID da conta do provedor
- Nome
- Avatar
- [Esta lista pode mudar dependendo do provedor ou com o tempo]
Os dados específicos armazenados dependem do provedor e das informações que eles compartilham.
Exemplo: Google OAuth2
Quando um usuário faz login com o Google, o Discourse retém as seguintes informações no banco de dados:
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"
}
Exemplo: Facebook OAuth
Um exemplo redigido para login no Facebook mostra:
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"
}
Os campos específicos armazenados podem mudar dependendo do provedor ou com o tempo, à medida que os protocolos de autenticação evoluem.
Quem pode acessar informações de login social
- Administradores - Acesso total às informações da conta associadas por meio do painel de administração e do banco de dados
- Moderadores - Podem ter acesso limitado dependendo da configuração do site
- Usuários individuais - Podem visualizar e gerenciar suas próprias contas associadas a partir de suas preferências de usuário
Minimizando o armazenamento de PII com DiscourseConnect
Para evitar o armazenamento de certas informações de identificação pessoal no Discourse, você pode usar o DiscourseConnect para lidar com o processo de login de seus usuários integralmente.
Como o DiscourseConnect reduz a exposição de PII
Com o DiscourseConnect, você controla totalmente as informações do usuário passadas de volta ao Discourse. Como você gerencia a implementação, pode criar alternativas focadas em privacidade aos identificadores tradicionais.
Abordagem de exemplo: Em vez de fornecer ao Discourse o endereço de e-mail real do usuário, você pode criar um endereço de e-mail exclusivo, mas livre de PII.
Por exemplo, se o ID exclusivo interno de um usuário for U123456, você pode retornar um endereço de e-mail como:
user-U123456@example.com
Benefícios adicionais de privacidade
O uso do DiscourseConnect também oculta do Discourse qualquer conexão com logins sociais federados. Da perspectiva do Discourse, o tipo de login que o usuário usa (social, móvel, etc.) é irrelevante, pois isso é tratado do seu lado. O Discourse sabe apenas o que o provedor de login informa a ele.
MFA e autenticação externa
O MFA pode ser imposto sobre a autenticação externa?
Esta combinação não é atualmente suportada da maneira esperada.
O Discourse tem a configuração do site enforce_second_factor_on_external_auth, que impede que usuários com MFA ativado usem métodos de autenticação externos, como logins sociais. Quando ativada, isso impedirá que usuários façam login com métodos de autenticação externos se tiverem a autenticação de dois fatores ativada.
Esta configuração efetivamente faz com que os usuários escolham entre:
- Usar autenticação externa (logins sociais) sem 2FA no Discourse
- Usar login de nome de usuário/senha com 2FA no Discourse
Para a configuração mais segura com SSO, implemente o MFA em seu provedor de identidade em vez de dentro do Discourse.