Wall-E
(Raphael)
1
招待システムに深刻なセキュリティ問題が発生しました。再現も容易だと思われます。当サイトは招待制です。さらに、設定で「ユーザーの承認が必要」にチェックを入れています。
スタッフの一人が、特定の一つのメールアドレスに限定されない、使用回数上限が1より大きい招待（下記参照）を発行しました。
その招待リンクが拡散され、それを使って登録することができました。しかし、「ユーザーの承認が必要」が設定でチェックされている場合、スタッフはこれらの「メールアドレス制限なし」の招待を使用するすべての人を承認する必要があると考えていました。それにもかかわらず、そのリンクを持っていれば誰でも自動的に受け入れられてしまいました。つまり、そのリンクは誰でも使用でき、誰がそれを使って参加したかを確認できません。承認後（確認後）に求める、必須項目であるメールアドレス、氏名、その他のフィールドの組み合わせを使用して、スタッフが「バックグラウンドチェック」できるようにする必要があります。
これにより、厳しく禁止されている外国組織の人物がそのリンクを入手し、登録してしまったため、深刻な問題が発生しました。すぐにそのアカウントを削除しなければなりませんでした。これは私たちにとって深刻な抜け穴です。
したがって、「ユーザーの承認が必要」という設定は、非常に誤解を招くものだと感じています。現在、サイトが招待制の場合、そのオプションは無意味です。
メールアドレスに制限のない招待リンクを使用するユーザーを、スタッフが承認できるようにする方法はありますか？サイトが招待制の場合、「ユーザーの承認が必要」を有効にする論理的な方法のように思えます。
「いいね！」 4
問題を再現できます。一括招待が生成されると、そのリンクでサインアップしたユーザーは、承認が必要なユーザー設定の影響を受けなくなります。
「いいね！」 6
Wall-E
(Raphael)
3
これを修正することに興味はありますか？対処されない場合、最終的にはこの問題により、組織内のDiscourseプロジェクトが停止することになります。
「いいね！」 2
Stephen
(Stephen)
4
これはバグではないかもしれません。
グローバル招待コードと承認をバイパスする招待に関する以前のトピックを読むと、これは意図した動作である可能性があります。ただし、チームの誰かがコメントする必要があるでしょう。
@Wall-E さんは、メールに紐づいていない招待が承認ステップを追加すると信じるに至った、ドキュメントの何かを見ましたか？
「いいね！」 4
david
(David Taylor)
5
ここで重要なのは、スタッフが招待を発行したということです。Discourse はそれを、招待を利用するユーザーの暗黙の承認とみなします。
スタッフ以外のユーザーが招待を生成した場合、招待を償還するユーザーはスタッフの承認待ちのキューに追加されます。
「いいね！」 5
スタッフ以外のユーザーアカウントを使用して招待を作成した場合、その招待を通じて行われたサインアップはレビューキューに入れられますか？もしそうなら、それは完全に許容される動作です。また、@Wall-E は、回避策としてダミーの通常アカウントを使用して招待を生成できます。
「いいね！」 3
RGJ
(Richard - Communiteq)
9
スタッフユーザーには少なくとも警告が表示されるべきだと思います。また、新規メンバーがどのように扱われるかを選択できると素晴らしいでしょう。2番目の「通常の」ユーザーを使用するのは、見栄えの悪い回避策になります。
「いいね！」 7
このトピックと以前のトピックを読んだところ、現在の機能は「意図したとおり」ですが、招待システムへの新しい変更を反映していないことがわかりました。知らない人が使用できる招待リンクを作成することがはるかに簡単になりました。また、招待リンクは、サイトのセキュアなカテゴリにアクセスできるグループに招待者を追加できるスタッフによって危険な方法で作成される可能性もあります。
@Wall-E あなたの招待リンクが、あなたのサイトへのアクセスを許可されるべきではない人々の手に渡っているのは、どのようにしてですか？おそらく、あなたのサイトのスタッフは、誰でも使用できる招待リンクを作成して、それを公開したり、間違った人々が使用できる設定で共有したりしないように注意する必要があることを知っているでしょう。ある程度、あなたが直面している問題はスタッフのトレーニングの問題です。機密性の高い詳細が含まれている場合は、PMで回答してください。
現在存在する招待リンクが何らかの形で侵害されている場合は、それらを削除して、将来より慎重に新しいものを生成して共有できます。管理者として、招待ページでユーザーを確認して、誰が招待を利用したかを確認することもできます。信頼できないスタッフがいる場合は、モデレーターに近い権限を持つTL4に権限を下げることができます。
3つの可能な行動方針が考えられます。
- 何もしない。招待システムは意図したとおりに機能しており、スタッフは招待リンクに注意するだけで済みます。このルートを取る場合は、
must approve users 管理者設定の説明を変更して、管理者が作成した招待リンクはこの設定をバイパスし、承認を必要としないことを明確にすることをお勧めします。
スタッフは、新しいユーザーアカウントがサイトにアクセスする前に、すべて承認する必要があります。注：スタッフが作成した招待は、この設定をバイパスし、承認を必要としません。
この変更のプルリクエストはここにあります：clarify that invites by staff bypass user approval by tobiaseigen · Pull Request #16966 · discourse/discourse · GitHub
-
(1) を実行するが、承認が必要なサイトでのみ、管理者がサイトへの即時アクセスを許可する招待リンクを作成する際に、「本当に確認しますか」という追加の警告ステップを追加する。
-
管理者が作成した招待リンクが、非管理者からの招待と同様に、承認が必要な設定を尊重するように動作を変更する。
OPが同意するように、現在の動作は誤解を招くものであり、承認が必要なサイトで問題を引き起こす可能性があります。この設定が有効になっているサイトは、特に注意深く、誰がアクセスできるかについて、この追加の偏執的なレベルの制御を必要とします。
したがって、私の推奨事項は、ドア番号3を選択することです。つまり、すべての招待リンクが同じように機能し、must approve users 設定を尊重するようにすることです。
ただし、これはバグではなく、意図したとおりに機能していると思います。機能リクエストとして再分類します。
「いいね！」 5
私もオプション3に強く賛成です。感情についてより深く内省できるコミュニティを構築しており、匿名招待リンクにその追加のゲートレベル（メールアドレスやIDに紐付かないため）を追加することで、私が望む人だけが参加することをより安心して確認できると考えています。
招待メールを使用し、匿名招待リンクを使用しないようにすることもできますが、リンクがあればWhatsAppなどのコミュニケーションプラットフォームで共有するのがはるかに簡単です。
そのため、匿名招待リンクが「ユーザーの承認が必要」設定を尊重することにも賛成です。
また、もし3番が実現すれば、招待システムは招待制フォーラムの応募システムとしてほぼ機能できると思います。現在、Googleフォームなどを別途用意せずに、どのようにメンバーを募集すればよいかわかりません。これは、カスタムユーザーフィールドが応募フォームになることで、ある程度効率化できる可能性があります。これは@Wall-Eがやろうとしていることだと思います。
「いいね！」 1
Wall-E
(Raphael)
12
私のトピックはそれとは関係ありません。招待制インスタンスでは must_approve_users が効果がないことについて話しています。オンにしても、オフにしても、効果が同じであるべきではありません。もしそうでないなら、招待制インスタンスにはこの動作が適用されないと文書化されるべきです。もし私がドキュメントを見落としていたなら、それは確かに私たちのスタッフの責任です。しかし、そうでないなら、その機能は誤解を招くものであり、修正されるか、少なくとも文書化されるべきです。なぜなら、それは私たちのスタッフ全員を誤解させてきたからです。
Wall-E
(Raphael)
14
まったくその通りです。文書化されていたとしても、見落としていた可能性があります。文書化されていた場合、スタッフを誤解させたのは私の責任となります。人々/スタッフは忘れることがあるため、警告があっても損はありません。
Wall-E
(Raphael)
15
はい、見ました。承知しました。
組織のセキュリティ問題と見なされるため、私たちをシャットダウンできる権力者に引用します。「このシステムで、許可されていない組織の誰かが侵入できる場合、あなたの注意にもかかわらず、最終的にはそうなるだろうと仮定しなければなりません」。まさにそれが起こったことです。「must_approve_user」は招待専用の場合には効果がないため、その「機能」（機能ではないと言うべきか）が有効になり、招待したいまさにその人々に無制限の招待を発行しました。そして明らかに、これらの人々の一人がその無制限の招待リンクを別の組織と共有しました。
これにより、@tobiaseigen にも回答します。
会議やカンファレンスがあり、時には許可された組織から数百人の人々が参加しますが、その中には、私たちの管理外の包括的なポリシーにより、フォーラムへの参加が許可されていない他の組織の人々も含まれることがあります。
その招待リンクは、スタッフの注意にもかかわらず「緩んで」しまいました。なぜなら、リンクを持つ「暗黙的に承認された」人々が何をするかを制御できないからです。定義上、そのリンクは「無制限」なので、彼らは望むなら誰にでも転送できます。もしそれが「設計どおり」であり、暗黙の承認があると言うなら、この無制限の招待リンクはどこにでも行く可能性があることを意味します。つまり、最終的にはそうなるということです。これはまさに、IT部門の責任者が正当な理由で話していたことです。私たちはそれを知っていたので、「must_approve_users」を、それがセキュリティレイヤーであると信じていたものとして有効にしました。
これが機能なのかバグなのかについては、質問があることは承知しています。私はプロのプログラマーではありません。それはあなたが決めることです（私は天体物理学者です）。私は単に、この素晴らしいプラットフォームを使い続けられるように対処されることを願って、私たちに引き起こされた深刻な「問題」を報告しているだけです。
私はオプション3を全面的に支持します。私たちの研究センターと私のフォーラムのスタッフも同様です。それまでの間、スタッフは招待したい人々の個々のメールアドレスすべてを追加する必要があるため、無制限の招待を使用しないように指示されています（カンファレンスでは、参加者は数百人を超えます…）。各会議、イベントなどでこれを行うことは、成長に大きな障害となり、追加のワークロードによりスタッフの一人が辞めることも予想できます（ほとんどがボランティアであり、他の職務で手一杯です）。
「いいね！」 2
Stephen
(Stephen)
16
オプション3が実施された場合、既存の動作に一致するオプションが何らかの形で提供されると仮定しても安全でしょうか？
私たちが急いで作成したトレーニングサイトは、一括で招待されたグループの承認をバイパスする機能なしでは、実行がはるかに困難だったでしょう。
「いいね！」 1
Stephen
(Stephen)
17
CSV の参加者リストを生成できる場合は、それを使用して全員を直接招待できるため、一括招待もオプションであることを忘れないでください。
そうでない場合は、Web フォームへの URL を共有して CSV に入力し、そこでユーザーを検証してから一括招待を送信することもできます。
Wall-E
(Raphael)
18
残念ながら、通常のイベントではそのような情報にアクセスできません。これらの連絡先リストは、会議/ミーティングを主催するホスト組織によって個人情報（PII）として扱われます。アクセスできたとしても、その機能を使用する余裕はありません。常に過労状態にある担当者（情報へのアクセスが許可されている場合でも）に連絡を取る必要があります。そのため、またしても、招待リンクを入手する頃にはイベントは終了しており、勢いを失っています（スタッフにとっても、潜在的な招待客にとっても）。
「いいね！」 1
Wall-E
(Raphael)
19
承知しました。それは回避策になり得ます。しかし、それは私たちのスタッフにとって追加の作業負荷となり、彼らはその追加の手順を処理するのに十分な帯域幅を持っていません。したがって、それは理想的ではありません。
「いいね！」 1
ご迷惑をおかけしたこと、またコミュニティにご迷惑をおかけしたことをお詫び申し上げます。
今後、この仕組みがどのように機能するかをご理解いただけたので、あなたや他の管理者、モデレーターが招待システムを賢明に使用できると確信しています。
機能かバグかという質問は優先順位に関するものです。私たちはバグを迅速に修正しようと努めています。特にセキュリティバグの場合はそうです。しかし、この場合、機能は何年も前から同じであり、意図的にそのようになっています。変更すべきだと思いますが、今すぐすべてを中断して修正するという種類の事柄ではありません。
他の人の意見を聞き、どちらの方向へ進むべきかを決定するために、この件に時間をかけます。
「いいね！」 2
ガーディアンがこのプロセスのさまざまな要素にどのように関与するかによって、はるかに複雑な変更になる可能性がありますが、別のオプション（これも3に依存します）は次のとおりです。
- 招待自体に、ユーザーの承認をバイパスするためのブールプロパティを追加します。このプロパティはデフォルトでオフになり、
must_approve_users が有効な場合にのみ、招待作成UIで表示されます。
編集: 実際、Davidが参照したコードを再度見ると、ガーディアンは招待されたユーザーが承認を必要とするかどうかを決定することには全く関与していないようです。この部分は、invite.invited_by.staff? を invite.bypass_approval? のようなものに単純に置き換えることになるようです。
「いいね！」 1
Wall-E
(Raphael)
22
優先順位付けの制約については、完全に理解しています。私たちのインスタンスは珍しい状況にあると思います。私が知っているすべてのDiscourseインスタンスは、私たちが従わなければならない厳格なセキュリティポリシーを持っていない組織からのものです。例えば、招待制は私たちの組織によって課せられた制約であり、セルフサインアップではインスタンスが存在できませんでした。セルフサインアップがあれば、より簡単になり、「緩んでしまう」可能性のある無制限の招待を使用する必要がなくなります。
「いいね！」 2
