Entendendo o armazenamento de PII no Discourse

[Discourse]

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 utilizado - O endereço IP mais recente a partir 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 de “último uso”.

Quem pode acessar os 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 os 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 via provedores sociais, seu nome de exibição é frequentemente usado como o nome completo

Quem pode acessar os 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_names e 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 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 - 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 de seu @nome de usuário
• prioritize_username_in_ux - Controla se o nome de usuário ou o nome completo aparece de forma mais proeminente 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 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 dados:

• E-mail
• 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 as 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 em 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 totalmente com o processo de login de seus usuários.

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 para 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 qualquer conexão com logins sociais federados do Discourse. 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?

Essa combinação não é suportada atualmente da maneira esperada.

O Discourse tem a configuração de 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.

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.

Recursos adicionais

• Setup DiscourseConnect - Official Single-Sign-On for Discourse (sso)