Este guia explica quais informações de identificação pessoal (PII) o Discourse armazena por padrão, onde elas 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 principais como moderação, gerenciamento de contas e autenticação de usuários. Compreender 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), o que permite controlar quais informações são transmitidas ao 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 a partir do qual o usuário acessou o site
Por exemplo, se você visitar seu site no seu dispositivo móvel às 11:00 e depois no 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 - Não podem visualizar endereços de e-mail por padrão (pode ser ativado 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 cadastro (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 do perfil - Os usuários podem adicionar ou atualizar seu nome completo nas preferências do perfil
- De logins sociais - Quando os usuários autenticam-se por meio de provedores sociais, seu nome de exibição é frequentemente usado como 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 que o acesso ao 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 da configuração
enable_namese outras configurações de exibição 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 o cadastro e se é obrigatório -
auth_overrides_name- Quando ativado, o nome do seu provedor de autenticação externo (incluindo SSO/DiscourseConnect e logins sociais) não pode ser alterado pelos usuários- Útil para manter uma 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- Interruptor mestre 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ó têm efeito quando enable_names está ativado:
display_name_on_posts- Mostra o nome completo de um usuário em suas postagens, além de seu @usernameprioritize_username_in_ux- Controla se o nome de usuário ou o nome completo aparece mais proeminentemente na interface- Padrão: ativado (o nome de usuário tem prioridade)
display_name_on_email_from- Usa o nome completo nos campos “De” nas notificações por e-mail, se ativado.
O Discourse possui 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 a exibição constante do nome completo e do nome de usuário 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árias informações:
- ID da conta do provedor
- Nome
- Avatar
- [Esta lista pode mudar dependendo do provedor ou ao longo do 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 censurado para login do 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 ao longo do tempo, conforme os protocolos de autenticação evoluem.
Quem pode acessar informações de login social
- Administradores - Acesso total às informações da conta associada através do painel de administração e 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 nas preferências do 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 dos seus usuários inteiramente.
Como o DiscourseConnect reduz a exposição de PII
Com o DiscourseConnect, você controla totalmente as informações do usuário transmitidas de volta ao Discourse. Como você gerencia a implementação, pode criar alternativas focadas na 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 único, mas livre de PII.
Por exemplo, se o ID único interno de um usuário for U123456, você pode passar de volta um endereço de e-mail como:
user-U123456@example.com
Benefícios adicionais de privacidade
O uso do DiscourseConnect também oculta qualquer conexão com logins sociais federados do Discourse. Do ponto de vista do Discourse, o tipo de login que o usuário usa (social, móvel, etc.) é irrelevante, pois isso é tratado do seu lado. O Discourse só sabe o que o provedor de login lhe diz.
MFA e autenticação externa
É possível impor MFA sobre autenticação externa?
Esta combinação não é atualmente suportada da maneira esperada.
O Discourse possui 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 externa, como logins sociais. Quando ativado, isso impedirá que usuários que fazem login com métodos de autenticação externa se autentiquem se tiverem autenticação de dois fatores ativada.
Essa configuração efetivamente faz com que os usuários escolham entre:
- Usar autenticação externa (logins sociais) sem 2FA no Discourse
- Usar login com 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.