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時にモバイルデバイスでサイトにアクセスし、その後午後12時にタブレットでアクセスした場合、「最終使用」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

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で2FAありでユーザー名/パスワードログインを使用する

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

追加リソース

「いいね！」 2