Понимание хранения PII в Discourse

[Discourse]

В этом руководстве объясняется, какие лично идентифицируемые данные (PII) Discourse хранит по умолчанию, где они хранятся, кто имеет к ним доступ и как можно минимизировать сбор PII с помощью DiscourseConnect.

Требуемый уровень пользователя: Администратор

Discourse хранит определенные лично идентифицируемые данные (PII) для поддержки основных функций, таких как модерация, управление учетными записями и аутентификация пользователей. Понимание того, какие данные собираются и как они хранятся, поможет вам принимать обоснованные решения в вопросах конфиденциальности и соответствия требованиям.

Краткое содержание

Discourse хранит несколько типов PII, включая IP-адреса, адреса электронной почты и учетные данные для входа через социальные сети. Эта информация в основном используется для модерации, обнаружения дубликатов учетных записей и аутентификации пользователей. Администраторы сайта могут минимизировать хранение PII, внедрив DiscourseConnect (SSO), что позволит вам контролировать, какая информация передается в Discourse.

Какие PII хранит Discourse?

IP-адреса

Discourse хранит следующие IP-адреса для каждого пользователя, чтобы помочь вашей команде модераторов в обнаружении дубликатов учетных записей:

• IP-адрес регистрации — IP-адрес, использованный при создании учетной записи
• Последний использованный IP-адрес — самый последний IP-адрес, с которого пользователь заходил на сайт

Например, если вы посетите свой сайт на мобильном устройстве в 11:00, а затем на планшете в 12:00, только IP-адрес планшета будет сохранен как «последний использованный» IP-адрес.

Кто имеет доступ к IP-адресам

• Администраторы — полный доступ ко всей информации об IP-адресах
• Модераторы — могут просматривать IP-адреса по умолчанию (можно отключить с помощью параметра сайта moderators_view_ips)
• Система — использует IP-адреса внутренне для обнаружения спама и идентификации дубликатов учетных записей

Адреса электронной почты

Адреса электронной почты хранятся в виде простого текста в базе данных и доступны любому, у кого есть доступ к базе данных. Это включает:

Кто имеет доступ к адресам электронной почты

• Администраторы — полный доступ ко всем адресам электронной почты
• Модераторы — не могут просматривать адреса электронной почты по умолчанию (можно включить с помощью параметра сайта moderators_view_emails)
• Администраторы базы данных — любой, у кого есть прямой доступ к базе данных

Полные имена (реальные имена)

Discourse может собирать и хранить полные имена пользователей (также называемые «реальными именами»), которые отличаются от их имен пользователей. Полные имена хранятся в виде простого текста в базе данных вместе с другой информацией о пользователе.

Как собираются полные имена

Полные имена могут быть предоставлены несколькими способами:

• При регистрации — пользователи могут ввести свое полное имя в процессе регистрации (в зависимости от конфигурации)
• Через SSO/DiscourseConnect — внешний провайдер аутентификации может передать полное имя (поле name) при создании или обновлении пользователя и может переопределить локальное имя, если это настроено.
• Через редактирование профиля — пользователи могут добавить или обновить свое полное имя в настройках профиля
• При входе через социальные сети — когда пользователи аутентифицируются через провайдеров социальных сетей, их отображаемое имя часто используется в качестве полного имени

Кто имеет доступ к полным именам

Полные имена хранятся в виде простого текста в столбце name таблицы users в базе данных и могут быть доступны:

• Администраторам — полный доступ ко всем полным именам
• Модераторам — могут просматривать полные имена по умолчанию (управляется теми же правами, что и доступ к электронной почте)
• Администраторам базы данных — любой, у кого есть прямой доступ к базе данных.
• Публичным пользователям — могут видеть полные имена в зависимости от параметра enable_names и связанных настроек отображения

Варианты конфигурации

Администраторы могут контролировать, как собираются и отображаются полные имена, используя следующие параметры сайта:

• full_name_requirement — контролирует, появляется ли поле полного имени при регистрации и является ли оно обязательным

• auth_overrides_name — при включении имя от вашего внешнего провайдера аутентификации (включая SSO/DiscourseConnect и вход через социальные сети) не может быть изменено пользователями

  • Полезно для поддержания последовательной идентичности во всех ваших системах

• use_name_for_username_suggestions — при включении Discourse будет использовать полное имя при предложении имен пользователей во время регистрации

• enable_names — главный переключатель, который отображает полное имя пользователя на его профиле, карточке пользователя и в электронных письмах. Отключите, чтобы скрыть полное имя везде

  • По умолчанию: включено

Следующие настройки отображения действуют только при включенном параметре enable_names:

• display_name_on_posts — отображает полное имя пользователя в его сообщениях в дополнение к его @имену пользователя
• prioritize_username_in_ux — контролирует, какое имя — имя пользователя или полное имя — отображается более заметно в интерфейсе
  • По умолчанию: включено (имя пользователя имеет приоритет)
• display_name_on_email_from — использует полное имя в полях «От» в уведомлениях по электронной почте, если включено.

В Discourse реализовано интеллектуальное устранение дубликатов: если полное имя и имя пользователя пользователя очень похожи (игнорируя пробелы, подчеркивания и регистр), будет отображаться только одно из них, чтобы избежать избыточности. Вы можете отключить это поведение, используя компонент темы Remove Name Suppression on Posts, который принудительно отображает и полное имя, и имя пользователя в сообщениях.

Информация о федеративном входе через социальные сети

Когда пользователи аутентифицируются через провайдеров входа через социальные сети (Google, Facebook, GitHub и т. д.), Discourse хранит различные данные:

• Электронная почта
• Идентификатор учетной записи провайдера
• Имя
• Аватар
• [Этот список может изменяться в зависимости от провайдера или со временем]

Конкретные хранимые данные зависят от провайдера и той информации, которой он делится.

Пример: Google OAuth2

Когда пользователь входит через Google, Discourse сохраняет следующую информацию в базе данных:

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"
}

Пример: Facebook OAuth

Пример с удаленными данными для входа через Facebook показывает:

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"
}

Конкретные хранимые поля могут изменяться в зависимости от провайдера или со временем по мере развития протоколов аутентификации.

Кто имеет доступ к информации о входе через социальные сети

• Администраторы — полный доступ к связанной информации об учетной записи через панель администратора и базу данных
• Модераторы — могут иметь ограниченный доступ в зависимости от конфигурации сайта
• Отдельные пользователи — могут просматривать и управлять своими связанными учетными записями в настройках пользователя

Минимизация хранения PII с помощью DiscourseConnect

Чтобы избежать хранения определенных лично идентифицируемых данных в Discourse, вы можете использовать DiscourseConnect для полной обработки процесса входа для ваших пользователей.

Как DiscourseConnect снижает риск раскрытия PII

С помощью DiscourseConnect вы полностью контролируете информацию о пользователе, передаваемую обратно в Discourse. Поскольку вы управляете реализацией, вы можете создать альтернативы традиционным идентификаторам, ориентированные на конфиденциальность.

Пример подхода: Вместо того чтобы передавать Discourse реальный адрес электронной почты пользователя, вы можете создать уникальный, но не содержащий PII адрес электронной почты.

Например, если внутренний уникальный идентификатор пользователя — U123456, вы можете передать адрес электронной почты вида:

user-U123456@example.com

Дополнительные преимущества конфиденциальности

Использование DiscourseConnect также скрывает от Discourse любую связь с федеративными входами через социальные сети. С точки зрения Discourse тип входа, который использует пользователь (социальный, мобильный и т. д.), не имеет значения, так как это обрабатывается на вашей стороне. Discourse знает только то, что ему сообщает провайдер входа.

MFA и внешняя аутентификация

Можно ли принудительно применять MFA поверх внешней аутентификации?

Эта комбинация в настоящее время не поддерживается ожидаемым образом.

В Discourse есть параметр сайта enforce_second_factor_on_external_auth, который предотвращает использование внешних методов аутентификации, таких как вход через социальные сети, пользователями, у которых включен MFA. При включении это предотвратит вход пользователей с внешними методами аутентификации, если у них включена двухфакторная аутентификация.

Этот параметр фактически заставляет пользователей выбирать между:

• Использованием внешней аутентификации (вход через социальные сети) без 2FA в Discourse
• Использованием входа по имени пользователя/паролю с 2FA в Discourse

Для наиболее безопасной настройки с SSO реализуйте MFA в вашем провайдере идентификации, а не внутри Discourse.

Дополнительные ресурсы

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