「登録後のメール編集」が無効の場合でも、管理者が常にメールを編集できるようにする

貢献 特徴
1

重要な明確化と、よりよく練られた提案基準を盛り込むために編集しました。これにより、コミュニティの仲間がこの機能改善の利点を理解しやすくなります。

「メールアドレス編集可能」設定を更新し、誰がメールアドレスを編集できるかについて追加のオプションを設けることを提案します。この設定は、以下のように設計されています。

  • 全ユーザー
  • ユーザーのみ [通常、管理者やモデレーターは、Rails コンソールを使用するか設定を変更しない限り編集できません。]
  • スタッフのみ
  • 管理者のみ

この設定がオンになっている場合（デフォルトではオン）、管理者としてこのアクションを実行するためにSudo モードのガードレールを導入します（編集対象のアカウントの所有者ではなく、管理者として動作します）。これにより、後述する重要なポイントを踏まえ、不要な変更からこの設定を保護しながら導入することが可能になります。

理由/なぜこれが必要か

この設定をオフにしたい場合、変更を自分で管理したい（例：変更を申請してもらう）、セキュリティ慣行のため、またはその他の理由があるかもしれません。しかし、何らかの理由でメールアドレスを編集する必要があるとします。この設定がオフの場合、管理者であってもメールアドレスを編集できません。

これが新たな問題を引き起こします。1 つ以上のユースケースが該当する場合です。

現在、ユーザーのメールアドレスを編集するには、1) 別のタブで設定をオンにして素早く編集する、または 2) Rails コンソールを開いて手動でメールアドレスを変更する、のいずれかしかありません。

通常の日常業務を行う管理者にとって、これは望ましくない技術的課題につながる可能性があります。 設定が存在しているにもかかわらず、すべてを Rails コンソールで行うことに依存しすぎている場合です。

追加のガードレールがこの機能を現実のものにするのに役立つ理由：

  • 技術的な影響により設定がオンのまま放置されている場合、侵害されたユーザーのメールアドレスが変更される可能性があります。
  • 管理者が誤操作や不正な変更を行う可能性があります。
  • ユーザーは、そのようなアクセス権限を持つ者による悪意のある変更から保護されていると感じるでしょう。

この件については最後に 2015 年 に議論されました。確かにメールアドレスを編集することは可能ですが、管理者ビューでは編集できません。「ユーザー設定ビューへ移動してください」と表示されます。私もそうしましたが、この設定の制約により、管理者であっても編集できませんでした。

image
image1025×291 11.5 KB

「いいね！」 1
2

ええ、ここには強く反対します。あなたの特定のユースケースはあなたにとってはシンプルに見えるかもしれませんが、UI で単純なオーバーライドを実装することは、わずかな利便性の向上に対して、重大なセキュリティリスクをもたらします。

その「手間」こそがセキュリティ機能なのです!

Rails コンソールを使用するか、サイト全体の設定を切り替える必要があるという不便さは、実際には重要なセキュリティ機能です。これは「セキュリティブレーキ」として機能し、管理者に極めて敏感な操作を行う際に、意図的で手間のかかるプロセスを強いるからです。

ユーザーのメールアドレスを変更することは、そのアカウントの鍵を差し出すことに等しく、新しいメールアドレスでパスワードリセットをトリガーして、元のユーザーを完全にロックアウトし、新しいメール所有者に完全な制御権を与えることができます。

この「手間」が防ぐ主な攻撃ベクトル:

  • 管理者アカウントの侵害! - これが最も重大なリスクです。攻撃者がフィッシングやパスワードの使い回しなどを通じて管理者アカウントにアクセスした場合、単純な UI ボタンや切り替え機能があれば、他のスタッフを含む任意のユーザーのアカウントを静かに、かつ容易に乗っ取れてしまいます。Rails コンソールを介したシェルアクセスが必要という要件は、強力なセキュリティ層を提供します。

  • ソーシャルエンジニアリング! - これによりソーシャルエンジニアリングの扉が開きます。悪意のあるユーザーが正当なユーザーになりすまし、管理者にメールアドレスの変更を説得する可能性があります。やはり、現在の「手間のかかる」プロセスは、管理者がリクエストの真正性を確認したり、慎重に検討したりする可能性を大幅に高めます。

  • 内部犯行の脅威 - 悪意のある管理者がこの機能を悪用してアカウントを乗っ取る可能性があります。

このような稀でリスクの高い管理操作においては、Rails コンソールが適切です。なぜなら、これにより操作を行う人物がセッションの侵害ではなく、サーバーへのアクセス権を持っていることが保証されるからです。さらに、この操作は意図的であり、特定の技術的知識を必要とし（シェル履歴に記録されます）。

「いいね！」 1
3

ご心配いただきありがとうございますが、おそらく全体像を誤解されているようです。また、「セキュリティ」に関するご主張には重大な見落としがあります。

この設定がオンになっている場合（デフォルトではオンです）、すでにメールを編集できます。

管理者アカウントの侵害！ - これが最も重大なリスクです。攻撃者がフィッシングやパスワードの使い回しなどを通じて管理者アカウントにアクセスした場合、単純な UI ボタンやトグル操作だけで、他のスタッフを含むあらゆるユーザーのアカウントを静かに、かつ容易に乗っ取ることができます。Rails コンソールを介したシェルアクセスが必要という要件は、強力なセキュリティ層を提供します。

もし管理者アカウントが侵害された場合、侵入者は現在存在する設定を有効化するだけで、あなたが挙げたような行為を実行できてしまいます。

ユーザーのメールアドレスを変更することは、そのアカウントの鍵を渡すことに等しく、新しいメールアドレスでパスワードリセットをトリガーできるため、結果として元のユーザーをロックアウトし、新しいメールアドレスの所有者に完全な制御権を渡すことになります。

このような稀でリスクの高い管理者操作については、Rails コンソールが適切です。なぜなら、これにより操作を行う人物がサーバーアクセス権を持ち、侵害されたセッションではないことを保証できるからです。さらに、この操作は意図的であり、特定の技術的知識を必要とし（かつシェル履歴にログとして残ります）。

常にそうとは限りません。冒頭の投稿でも述べた通り、設定をオンとオフに切り替えるだけで編集機能を有効化できます。唯一の問題は、デフォルトでオンになっている（本来はオフであるべき）設定を切り替えることで、管理者ではないユーザーがメールアドレスを編集できるようになってしまう点です。これは単なる編集が行われている最中の問題です。

「いいね！」 1
4

なるほど、その設定を切り替えた場合の点については理解できました。

それでも、やはりここでは Rails コンソールを使うのが最善だと強く思います。プラグインで実現できる可能性もゼロではないかもしれません。

5

設定がONの場合

「登録後にユーザーがメールアドレスを変更できるようにする」

これにより、すべてのユーザー（および管理者）が編集可能になります。シンプルな機能リクエストは以下の通りです：この設定を「管理者のみ」「管理者＋ユーザー」「ユーザーのみ」のように選択可能にすること。

単に**「オンにする」と、サイト全体で誰でも**（または管理者のみ）ユーザーのメールアドレスを変更できる機能が有効になります。

すでに部分的に存在している設定を「管理者のみ」に適用することで、すでに存在するシンプルな機能を、単なるすべてまたはなしの状況に留めずに活用できるようになります。

「いいね！」 1
6

より深く考えてみると、この設定は編集ウィンドウでは「不安全」であり、またすべての管理者が Rails コンソールにアクセスできるわけではない（ホスト型サイトなどを想定）ため、sudo による高摩擦な UI 方式が妥当かもしれません。

例えば、管理者が新しいメールアドレスの保存を試みると、モーダルダイアログが表示され、操作を確認するために自身のパスワードを再入力することを強制する（または有効化されている場合は 2 段階認証のチャレンジを行う）といった仕組みはいかがでしょうか。言うまでもなく、この操作はスタッフログに詳細に記録される必要があります。 legitimate なユーザーがアカウント乗っ取りを報告する機会を与えるため、何らかの形で必須のユーザー検証が必要だと考えられます。また、変更を承認する通知を新しいメールアドレスにも送信すべきでしょうか？:thinking:

「いいね！」 1
7

はい、この機能は確かに手直しと更新が必要です。現在、管理者として有効にすると、追加の制限なしに任意のユーザーアカウントのメールアドレスを編集できてしまいます。2FAまたはパスワードに関するアイデアは気に入りました。

「いいね！」 1
8

「メールの編集可能」機能について考えさせてくれてありがとう。これは興味深く、やや複雑な議論ですね！:slight_smile:

「いいね！」 1
9

元の投稿を編集して表現を大幅に改善し、変更への対処に関する追加の提案も加えました :wink: 全体として状況が大幅に改善されると思います。

「いいね！」 1
10

これがいつ変更されたのか気になります。長年、管理者としてメンバーのアカウントのメールアドレスを変更することで修正を行ってきました。モデレーターが不正に、あるいは誤ってメンバーを匿名化してしまった場合のアカウント修正には非常に便利です。

そこで、app.yml を修正して UI からの管理者アクセスを復元することは可能でしょうか？管理者アカウントは、注意深く管理されていれば適切に保護されるはずです。

とはいえ、Discourse は管理者機能のよりきめ細かい制御のために、管理者の階層化（Admin Tiering）を導入すべきです（過去の議論）。最上位の管理者アカウントは、完全な権限・制御を保有するのに理想的です。一方で、一部の管理者にはテーマ設定へのアクセスのみが必要という場合もあるでしょう。

「いいね！」 1
11

これは「なりすまし」機能が明らかになった際に提起された懸念事項です。確かに、ユーザーの問題解決に役立つという主張もできます。あるいは、通常のユーザーとして機能をテストするためにテストアカウントに切り替える用途もあるでしょう。しかし、タブやウィンドウを切り替えるだけで、テストユーザーとしてログインした状態を維持するのは非常に簡単です。

ここで賢明な対応としては、Linux のようなガードレールを単純に追加し、特定の管理者機能（例えばユーザーのメールアドレスの変更など）を実行する際に、追加のサイトパスワードを要求するようにすることです。

「いいね！」 1
12

あなたのサイトでは email_editable サイト設定が有効になっていますか？デフォルトでは有効になっているため、メールアドレスの変更は問題ありません。ただし、この設定が無効になっている場合は問題が発生します。

「いいね！」 1
13

確認しました。私のサイトでは、すべて管理者による編集が許可されていません。何かの更新でこの動作が変更されたようです。通常ユーザーはメールアドレスの変更ができませんでしたが、以前は管理者として、メールアドレスを紛失したアカウントや、意見が合わなかったモデレーターによる匿名化処理（この問題は、その方が他社へ移ったことで解決しています）のために変更したことがあります。

管理者によるメールアドレスの変更は、全ユーザーに対して有効化する設定とは別に設定されるべきです。少なくとも初期段階では、管理者を有効化するためにコンソールで変更する必要があるかもしれません。

14

この提案が表面化したのは、メンバーが自分でメールアドレスを編集できるようにしたくないからです。私は管理者による監視を維持したいと考えています。ただし、この編集機能を無効にすると、メンバーだけでなく管理者にも適用されてしまいます。

当初は、設定に関係なく管理者が変更できるように単純に提案しましたが、初期の返信に基づいて、より構造化された形に修正しました。

「いいね！」 1