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時にモバイルデバイスでサイトにアクセスし、その後正午にタブレットでアクセスした場合、「最終使用」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 プロバイダーからの名前をユーザーが変更できなくなります

    • システム全体で一貫したIDを維持する場合に便利です

  • use_name_for_username_suggestions - 有効にすると、Discourseは登録時にユーザー名の候補を提案する際にフルネームを使用します

  • enable_names - ユーザーのフルネームをプロファイル、ユーザーカード、メールに表示するマスター切り替えスイッチ。無効にすると、フルネームはどこにも表示されなくなります

    • デフォルト: 有効

:information_source: 次の表示設定は、enable_names が有効な場合にのみ適用されます。

  • display_name_on_posts - ユーザーの投稿に、@ユーザー名に加えてフルネームを表示します
  • 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には、MFAが有効になっているユーザーがソーシャルログインなどの外部認証方法を使用するのを防ぐ enforce_second_factor_on_external_auth サイト設定があります。有効にすると、2要素認証が有効になっているユーザーは外部認証方法を使用してログインできなくなります。

この設定により、ユーザーは実質的に次のいずれかを選択する必要があります。

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

:information_source: 最も安全なSSOセットアップについては、Discourse内ではなく、IDプロバイダーでMFAを実装してください。

追加リソース

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