Discourse における PII の保存の理解

ドキュメント サイト管理
1

:bookmark: このガイドでは、Discourse がデフォルトで保存する個人識別情報（PII）の内容、保存場所、アクセス権限、および DiscourseConnect を使用して PII の収集を最小化する方法について説明します。

:person_raising_hand: 必要なユーザーレベル：管理者

Discourse は、モデレーション、アカウント管理、ユーザー認証などのコア機能をサポートするために、特定の個人識別情報（PII）を保存します。収集されるデータの内容と保存方法を理解することで、プライバシーとコンプライアンスに関する情報に基づいた意思決定を行うことができます。

概要

Discourse は、IP アドレス、メールアドレス、ソーシャルログイン認証情報など、いくつかの種類の PII を保存します。これらの情報は主にモデレーション、重複アカウントの検出、ユーザー認証に使用されます。サイト管理者は、DiscourseConnect（SSO）を実装することで PII の保存を最小化できます。これにより、Discourse に渡される情報を制御することが可能になります。

Discourse はどのような PII を保存しますか？

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 フィールド）を渡すことができ、設定次第ではローカル名を上書きできます。
  • プロフィール編集 - ユーザーはプロフィール設定から本名を追加または更新できます
  • ソーシャルログイン - ユーザーがソーシャルプロバイダーを介して認証する場合、表示名が本名として使用されることが多いです

本名へのアクセス権限

本名は、データベース内の users テーブルの name 列にプレーンテキストとして保存され、以下の人がアクセスできます。

  • 管理者 - すべての本名に完全なアクセス権があります
  • モデレーター - デフォルトで本名を表示できます（メールアドレスアクセスと同じ権限で制御されます）
  • データベース管理者 - 直接データベースにアクセスできる人
  • 一般ユーザー - enable_names および関連する表示設定に応じて、本名を表示する場合があります

設定オプション

管理者は、以下のサイト設定を使用して本名の収集と表示方法を制御できます。

  • full_name_requirement - サインアップ時に本名フィールドが表示されるかどうか、および必須かどうかを制御します
    *

  • auth_overrides_name - 有効にすると、外部認証プロバイダー（SSO/DiscourseConnect やソーシャルログインを含む）からの名前はユーザーによって変更できません

    • システム全体で一貫したアイデンティティを維持するのに役立ちます

  • use_name_for_username_suggestions - 有効にすると、Discourse は登録時にユーザー名の提案に本名を使用します

  • enable_names - ユーザーのプロフィール、ユーザーカード、メールに本名を表示するマスタースイッチです。無効にすると、すべての場所で本名が非表示になります

    • デフォルト：有効

:information_source: 以下の表示設定は、enable_names が有効な場合にのみ有効になります。

  • display_name_on_posts - @username に加えて、投稿にユーザーの本名を表示します
  • prioritize_username_in_ux - インターフェースでユーザー名と本名のどちらがより目立つかを制御します
    • デフォルト：有効（ユーザー名が優先されます）
  • display_name_on_email_from - 有効な場合、メール通知の「From」フィールドに本名を使用します

:information_source: Discourse にはインテリジェントな重複排除機能があります。ユーザーの本名とユーザー名が非常に似ている場合（スペース、アンダースコア、大文字小文字を無視）、冗長性を避けるために一方のみが表示されます。この動作を無効にするには、Remove Name Suppression on Posts テーマコンポーネントを使用し、投稿に本名とユーザー名の両方を常に表示させるように強制できます。

フェデレーテッドソーシャルログイン情報

ユーザーがソーシャルログインプロバイダー（Google、Facebook、GitHub など）を介して認証する場合、Discourse は以下の情報を保存します。

  • メール
  • プロバイダーアカウント ID
  • 名前
  • アバター
  • [このリストはプロバイダーや時間の経過とともに変更される場合があります]

保存される具体的なデータは、プロバイダーと共有される情報によって異なります。

例：Google OAuth2

Google でサインインすると、Discourse はデータベースに以下の情報を保持します。

image
image690×228 22.8 KB

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

:information_source: 保存される特定のフィールドは、プロバイダーや認証プロトコルの進化に伴い、時間の経過とともに変更される場合があります。

ソーシャルログイン情報へのアクセス権限

  • 管理者 - 管理パネルとデータベースを介して、関連するアカウント情報に完全なアクセス権があります
  • モデレーター - サイト設定に応じて、限定的なアクセス権を持つ場合があります
  • 個々のユーザー - ユーザー設定から、自身の関連アカウントを表示および管理できます

DiscourseConnect を使用した PII 保存の最小化

特定の個人識別情報を Discourse に保存しないようにするには、DiscourseConnect を使用して、ユーザーのログインプロセスを完全に処理します。

DiscourseConnect による PII の露出削減

DiscourseConnect を使用すると、Discourse に返されるユーザー情報を完全に制御できます。実装を管理しているため、従来の識別子の代わりにプライバシーに配慮した代替案を作成できます。

アプローチ例：ユーザーの実メールアドレスを Discourse に渡す代わりに、一意だが PII を含まないメールアドレスを作成できます。

例えば、ユーザーの内部一意 ID が U123456 の場合、以下のようなメールアドレスを返すことができます。

user-U123456@example.com

追加のプライバシー上の利点

DiscourseConnect を使用すると、Discourse 側からフェデレーテッドソーシャルログインとの接続が隠蔽されます。Discourse の視点では、ユーザーが使用するログインの種類（ソーシャル、モバイルなど）は関係ありません。これはあなたの側で処理されるためです。Discourse が知ることは、ログインプロバイダーが伝える情報のみです。

MFA と外部認証

外部認証の上に MFA を強制できますか？

:warning: この組み合わせは、期待される方法では現在サポートされていません。

Discourse には enforce_second_factor_on_external_auth というサイト設定があり、MFA を有効にしているユーザーがソーシャルログインなどの外部認証方法を使用するのを防ぎます。これを有効にすると、二要素認証が有効になっているユーザーは、外部認証方法でのログインができなくなります。

この設定により、ユーザーは以下のどちらかを選択せざるを得なくなります。

  • Discourse 上で 2FA なしで外部認証（ソーシャルログイン）を使用する
  • Discourse 上で 2FA ありでユーザー名/パスワードログインを使用する

:information_source: SSO を使用した最も安全な設定については、Discourse 内ではなくアイデンティティプロバイダーで MFA を実装してください。

追加リソース

「いいね！」 5
Where in Discourse can users publicly share PII?