要約
分析とトラブルシューティングのために、有効化されているすべての認証方法からの認証イベントを保存する標準化された認証ログシステムを Discourse に追加する必要があります。
詳細
すべての認証システムがフックしてイベントを送信するための認証ロギングプロバイダーを提供します。
例として、ローカルログインプロバイダーには、次の（完全ではない）イベントリストがある場合があります。
- IPアドレスからの、存在しないユーザー
fhqwhgadsとしてのログイン失敗 - IPアドレスからの、ユーザー
supermathieとしてのログイン失敗、レート制限がかかりました - IPアドレスからの、ユーザー
supermathieとしてのログイン失敗、無効なパスワードが提供されました - IPアドレスからの、ユーザー
supermathieとしてのログイン成功、有効なパスワードが提供されました - IPアドレスからの、ユーザー
supermathieとしてのログイン失敗、有効なパスワードが提供されましたが、続行するにはMFAが必要です - IPアドレスからの、ユーザー
supermathieとしてのログイン失敗、有効なパスワードが提供されましたが、無効なTOTPコードが提供されました - IPアドレスからの、ユーザー
supermathieとしてのログイン成功、有効なパスワードが提供され、vault-workトークンの有効なTOTPコードが提供されました
既存のログ（Webログ）に依存する問題は、レート制限されたものを除くすべてが まったく同じ に見えることです（[200] POST /session HTTP/1.1）。ログには 意味 が伝達されていません。
懸念事項
匿名イベントがログエントリを生成することと、パスワードスプレー攻撃などのSIEM分析の観点から興味深いイベントの検出とのバランスについての懸念があります。
すべてをログに記録すると、インターネット上の誰でもログをいっぱいにすることができます…しかし、これが実際に問題であるかどうかは議論の余地があります。以下の保持期間を参照してください。失敗は、アプリケーションログ内でより短い期間保持される可能性があります。
ワンタイムトークンベースのログ（例：メール経由のログイン）に関しても同様の疑問が生じます。無効なトークンはおそらくログに記録するほど「興味深い」ものではありませんが、再利用された トークンは、SIEMとユーザーサポートの両方の観点から絶対に興味深いものです。
質問
保持期間：すべて無期限？ 30日？ 90日？ 匿名イベントはより早く削除しますか？
APIキー認証：無効なユーザーまたは管理者APIキーを持つ呼び出しはここでログに記録されるべきですか？おそらく、デバッグに役立ちます。
どの程度設定可能にすべきですか？例えば、すべて のデバッグログをオンにするか、単一のプロバイダーのみにするか？
実装上の考慮事項
実装は、ログパイプラインに別のイベントストレージプロバイダーを追加できるように、十分に柔軟である必要があります。そのようなプロバイダーの例としては、生のログファイル、メッセージキュー、またはS3バケットが考えられます。このようなプロバイダーの正確な詳細はこのトピックの範囲外ですが、プラグインが生成されたログを受信するために登録できるように、実装は十分に柔軟である必要があります。
背景
顧客から、イベントをSIEMにフィードすることを意図してこの機能について依頼があり、Discourseの機能ギャップであることがわかりました。
内部議論中に、この情報がサイト管理者やサポート担当者にとっても役立つことがわかりました。認証ログはさまざまな場所にあり、それらを検索するにはどこを見ればよいかを知る必要があります。これは個人的な知識に依存しており、中央ログがあればその負担を大幅に軽減できます。
Railsコンソールからこれらのログを便利な方法で表示できることは、私たちとサイト管理者にとって有益でしょう。