ログイン保護

このページで解決すること

ログイン画面は外に開いた唯一の入口で、パスワードの推測やアカウントの存在確認に使われます。このページでは三つを扱います。推測をどう止めるか、応答がなぜどこを間違えたか教えないのか、そして利用者のログイン状態をどこに置くのか。

補い合う二つの防御

送信元のレート制限

ログインのエンドポイントは送信元アドレスごとにレート制限をかけ、アカウントを替えながら試すパスワードスプレーを止めます。超えると 429 を返します。応答は残りの回数もリセットの時刻も明かしません。送信元アドレスはシステムの信頼するプロキシの設定から取り、リクエストヘッダーを無条件には信じません。リバースプロキシの後ろに置くときは .env の TRUSTED_PROXIES を埋めます。

シングルサインオン関連のエンドポイントには、送信元ごとの速度と全体の容量の上限が別に付いています。

アカウントロック

ロックの閾値と時間はセキュリティポリシーが決めます。出荷時は 10 回連続の失敗で 30 分のロックです。パスワードの失敗と多要素認証の失敗は同じカウンターを共有し、ログインに成功すると 0 に戻ります。ディレクトリのアカウントも同じカウンターに入ります。ロック中の応答は一時的にロックされているとだけ伝え、あと何分かも、何回試したかも伝えません。管理者は「ユーザー管理」で手動でロックを解除できます。

応答がよく似ている理由

アカウントが存在しない、パスワードが違う、アカウントが停止されていてパスワードも違う。この三つは同じステータスコードと同じエラーコードを返し、アカウントの状態の判定は資格情報の検証のあとに行います。これは意図した設計です。資格情報を持たない人が、ログイン画面をアカウント名簿の照会に使えないようにしています。

資格情報は正しいがアカウントが停止されている場合だけは例外で、専用のエラーコードを返します。利用者は管理者に連絡すべきだと知る必要があるからです。

トークンをどこに置くか

アクセストークンの有効期間は 15 分の固定で、タブのメモリ上にだけ置きます。 localStorage、sessionStorage、IndexedDB、cookie のいずれにも書きません。再発行に使うリフレッシュトークンの入れ物は HttpOnly cookie だけで、SameSite を付け、パスは認証のエンドポイント群に絞ります。

ページを読み込むとき、ナビゲーションガードは保護されたページを通す前に、この cookie でアクセストークンを一度受け取ります。タブの間ではイベントだけをやりとりし、トークン自体は渡しません。どれか一つのタブでログアウトすると、同じブラウザの他のタブもすぐに空になります。

cookie を暗号化された接続でだけ送るかどうかは、セキュリティポリシーの「ログイン状態は https 接続でのみ保持する」で決めます。出荷時は有効です。設定のしかたは TLS と証明書にあります。

セッションの扱い

再発行には四つの条件がすべて要ります。トークンが取り消されていないこと、絶対の寿命（出荷時 12 時間）を超えていないこと、最後の活動からの間隔が休眠の上限（出荷時 60 分）を超えていないこと、送信元アドレスがそのアカウントの許可リストに入っていることです。

再発行に成功するたびにトークンを入れ替えます。古いトークンが再送されたときは、そのアカウントのリフレッシュトークンをすべて取り消します。ログアウトは現在のトークンを取り消します。パスワード変更、アカウントの停止、アカウントのロックはすべてのトークンを取り消し、アカウントの停止は進行中の接続も切ります。ロールの変更はトークンの世代を進め、古いトークンを無効にします。

アクセストークンは Authorization ヘッダーからだけ受け取り、URL には載せません。

監査で見えること

ログインの成功と失敗をそれぞれ一件ずつ残し、アカウント、送信元アドレス、結果を含みます。
レート制限は集約した一行として記録し、理由、送信元アドレス、回数、開始と終了の時刻を含みます。
トークンの再発行は三つの状態で記録に残ります。通常の入れ替え、拒否、再送の検知です。
送信元アドレスによる拒否は記録に残り、アドレスと判定の根拠を含みます。失敗ログインの回数には入りません。
アカウントがある送信元アドレスから初めてログインしたときは、観測の記録が別に一件残ります。