ログアウトしても残るセッション。期限・更新・失効を分けて設計する

編集部の実務提案

失効とは何か。「使えなくなる状態」を定義する

失効の設計は、言葉の定義から始める。ログアウトしたとき、そのセッションは具体的にどうなるのか。画面がログイン画面に戻ることと、サーバーがそのセッションIDを二度と受け付けなくなることは、別の事象である。前者だけが実装され、後者が抜けている設計は珍しくない。OWASPは、期限切れやログアウトの際、アプリケーションはサーバー側で能動的にセッションを無効化しなければならないと明記する。

無効化の対象も定義が要る。セッションそのもの、紐づくリフレッシュトークン、同じ利用者の他端末のセッション、「ログイン状態を保持する」ための長期トークン。これらが連動して失効するのか、個別なのか。利用者の期待と実装がずれる箇所は、たいていこの連動の設計にある。

失効のきっかけも列挙しておく。本人のログアウト、期限切れ、パスワード変更、権限変更、管理者による強制失効、アカウント停止や削除、漏洩の疑い。きっかけごとに、失効範囲と即時性が違う。一覧にしておくことで、実装とテストの観点が定まる。

テスト可能性も定義に含める。失効したセッションIDでAPIを叩けば拒否されること、を自動テストで確認できる状態が、設計の完成条件である。目視や手動確認に頼る失効は、変更のたびに静かに壊れる。失効は仕様であり、仕様はテストに落とす。

利用者への見せ方も設計対象である。「すべての端末からログアウトする」ボタンの有無、セッション一覧の表示、異常なログインの通知。これらは失効の仕組みを利用者が操作できる形にしたもので、セキュリティ機能であると同時に信頼の表現でもある。

逆に、失効させない判断も存在する。業務継続の観点で、閲覧系の軽いセッションと、変更系の強い操作で、失効の即時性を使い分けることはあり得る。ただし、それは無自覚な残存ではなく、リスクを言語化した上での選択として記録されるべきものである。

定義の言語化は、問い合わせ対応の品質にも効く。「ログアウトしたのにログイン状態が残っている」という報告は、定義が曖昧な組織では再現確認から迷走する。どの操作が何を失効させるかが表になっていれば、報告の切り分けは表を引くだけで済む。失効の定義は、セキュリティ文書であると同時にサポートの判断表である。

出典：[1]

編集部の実務提案

期限は2種類。アイドルタイムアウトと絶対タイムアウト

セッションの期限は2種類を併用するのが原則である。アイドルタイムアウトは、最終利用からの無操作時間で切る。絶対タイムアウトは、操作が続いていても発行からの総時間で切る。OWASPは両方の実装を求め、アイドルは価値の高いアプリケーションで2〜5分、低リスクでは15〜30分、絶対は就業時間に合わせた4〜8時間が一般的な目安と示す。

2種類が必要な理由は、守るものが違うからである。アイドルは、席を外した端末や置き忘れのリスクを絞る。絶対は、盗まれたセッションが使われ続けられる総時間を制限する。片方だけでは、盗難への上限がないか、放置への防御がないかのどちらかになる。

期限の判定はサーバー側で行う。クライアント側のタイマーや表示上の自動ログアウトは、利便性の演出であって防御ではない。OWASPも、タイムアウトの強制はサーバー側で実装すべきだと明言する。セッションの生成時刻と最終利用時刻をサーバーが保持し、リクエストごとに判定する構造が前提である。

期限切れの掃除も設計に含める。期限切れや無効化されたセッションをサーバー側のストアから実際に削除する仕組みがなければ、死んだセッションが溜まり、監査や調査のノイズになる。OWASPは、期限切れセッションの破棄と掃除の仕組みの必要性を指摘する。

値の決め方は、業務のリズムに合わせる。会議や現場作業で画面を開きっぱなしにする業務では、短すぎるアイドルは再ログインの摩擦を生み、正規の利用者を疲弊させる。逆に決済や管理操作は短く切る。画面や操作の重要度で期限を変える多段設計は、現実的な落としどころである。

再認証との組み合わせも有効である。絶対タイムアウトで全面ログアウトさせる代わりに、重要な操作の前だけ再認証を求める設計は、利便性と安全の両立に使われる。期限は「切る」ためだけのものではなく、確認の頻度を調整するつまみとして設計する。

期限の例外も設計しておく。長時間の処理や大容量のアップロードのように、正当な理由で長く生きるセッションが要る場面では、例外を認める範囲と条件を明記する。例外の無秩序な許可は期限設計を骨抜きにするが、実務を無視した一律の期限も、回避策としての危険な実装を招く。例外は一覧で管理し、棚卸しの対象にする。

出典：[1]

編集部の実務提案

権限が変わればセッションIDを更新する

セッションIDは、権限レベルの変更のたびに作り直す。これがOWASPの示す明確な原則である。認証の前後、パスワード変更、権限やロールの変更といった節目で新しいIDを発行し、古いIDは破棄する。ログイン前のIDを引き継ぐ設計は、セッション固定化の攻撃に弱い。

早期生成の罠にも注意が要る。認証前にセッションを発行するアプリケーションでは、攻撃者が自分用に取得したセッションIDを被害者に使わせ、認証後にそのIDで乗り込む余地が生まれる。認証の成功時点でIDを更新することは、この古典的な攻撃への直接の防御である。

更新の実装では、新旧の切り替えの扱いを決める。新しいIDを発行した瞬間に旧IDを無効化するのが原則だが、並行リクエストの競合で正規利用者が弾かれることがある。短い猶予を持たせる実装も現実にはあるが、その猶予は攻撃の窓にもなる。猶予を設けるなら、期間と理由を設計として明記する。

ID自体の強度も前提である。OWASPは、セッションIDに暗号論的に安全な乱数生成器による最低64ビット、推奨128ビットのエントロピーを求める。失効の設計が正しくても、推測可能なIDでは意味がない。生成、更新、失効は一組の設計として見る。

権限変更の範囲は、ロール変更だけではない。メールアドレスの変更、多要素認証の有効化やリセット、連携サービスの追加のような、 accountの安全状態を変える操作も更新のきっかけに含める。何を「権限レベルの変更」とみなすかの定義を、操作の一覧として持つことが実装の抜けを防ぐ。

更新時には、セッションに紐づく状態の引き継ぎも確認する。カートや下書きのような業務状態は新しいセッションへ移し、セキュリティに関わる状態、たとえば再認証の済み具合は引き継がない。何を引き継ぎ、何を捨てるかの線引きが、更新の設計の細部である。

多要素認証の節目も更新の対象である。ログイン後のステップアップ認証、たとえば重要な操作の直前の追加認証を通過した時点で、セッションの保証レベルは上がっている。この変化をセッションに記録し、IDを更新するかどうかを設計する。保証レベルをセッションの属性として持つと、操作ごとの要求水準と突き合わせた制御ができる。

出典：[1]

編集部の実務提案

サーバー側で無効化する。ストアと伝播の設計

失効の実体は、サーバー側のセッションストアの操作である。ログアウト時にセッションを無効化する、という一行の仕様の裏では、ストアからの削除や無効フラグ、複数台構成での伝播、キャッシュの扱いが問われる。OWASPが例示するように、フレームワークの無効化APIを正しく呼ぶことが出発点であり、「Cookieを消したから終わり」ではない。

分散構成では伝播遅延が論点になる。失効したはずのセッションが、別ノードのキャッシュに残って数秒から数分使える状態は、設計として許容するかを決める問題である。強制失効のような強い要件では、検証のたびにストアを引く設計や、失効イベントの即時配信が必要になる。利便と即時性のトレードオフを、要件として言語化する。

セッションの検証方式も関係する。署名付きトークンをクライアントに持たせ、サーバーは状態を持たない方式では、「失効」の意味が変わる。サーバー側の参照情報なしには、個々のトークンを途中で殺すことができない。方式の選択時点で、失効要件をどこまで満たせるかがほぼ決まる。

全端末ログアウトは、この設計の応用である。利用者の全セッションを列挙し、一括で無効化できること。そのためには、利用者からセッションを引けるインデックスがストアに要る。発行時に利用者IDとセッションを紐づけて記録する設計が、漏洩対応の速度を決める。

無効化の記録も残す。いつ、どのセッションが、どのきっかけで失効したか。この記録は、不正利用の調査で「攻撃者のセッションを止めた時刻」を特定する証跡になる。失効させて終わりではなく、失効の事実を監査ログに残すところまでが設計である。

ストレージの実装詳細も軽視できない。セッションストアへのアクセス権限、暗号化、バックアップからの復旧時に失効状態がどう扱われるか。復旧によって失効済みセッションが蘇るような設計は、障害対応の場面で静かに牙をむく。復旧手順の確認項目に、失効状態の扱いを含めておく。

キャッシュとの付き合い方も決めておく。セッション検証の結果を短時間キャッシュする設計は性能に効くが、失効の即時性と引き換えである。キャッシュの保持時間を失効要件の許容範囲として明示し、強制失効のときだけキャッシュを迂回する経路を用意する、といった折衷も設計のうちである。暗黙のキャッシュは、暗黙の遅延になる。

出典：[1]

編集部の実務提案

JWTの失効問題。短命化とデナイリストで補う

JWTは失効と相性が悪い。OWASPのJWTチートシートは、JWTには利用者がトークンの有効性を明示的に取り消す組み込みの仕組みがなく、失効は期限切れまで待つしかない、という問題を正面から扱っている。盗まれたトークンを止める術がないことは、ステートレスであることの裏面である。

現実的な補完策の筆頭は、トークンを短命にすることである。アクセス用のJWTの有効期間を短く保ち、更新はリフレッシュ側の管理に寄せる。短命化すれば、盗難時の悪用可能時間はその分だけ縮む。チートシートの実装例でも、トークンの有効期間は15分といった短さで示されている。

即時の失効が必要なら、デナイリストという設計がある。失効させたトークンのダイジェスト（SHA-256）と失効日を保持し、検証時に照合する。保持期間は、そのトークンの期限が切れるまでで足りる。チートシートは、データベースにデナイリストを置き、ログアウト時に登録して即時無効化を模倣する実装を示している。

もう一つの補完は、トークンと利用者コンテキストの結びつけである。認証時に生成した乱数を強化されたCookieに持たせ、そのハッシュをトークン側に埋める方式では、トークン単体が盗まれても再現が難しい。チートシートのサイドジャッキング対策として示されるこの方式は、デナイリストを持たない構成での現実解の一つである。

設計の判断軸は明確である。即時失効の要件が強いなら、サーバー側セッションか、検証のたびにデナイリストを引くJWTにする。要件が弱く規模の要請が強いなら、短命JWTとリフレッシュ管理で割り切る。どちらを選ぶかは流行ではなく、漏洩時の被害と運用コストの見積もりで決める。

リフレッシュトークン側の設計も忘れてはならない。ローテーション、再利用検知、ファミリー単位の失効。アクセス側が短命でも、リフレッシュ側が緩ければ全体の失効は効かない。トークンの種類ごとの役割と寿命と失効方法を、表にして設計する。

デナイリストの照合コストにも目を配る。検証のたびに照合する設計では、デナイリストの肥大化がそのまま性能劣化になる。期限切れの記録を速やかに掃除すること、照合を高速なストアに置くこと、アクセス頻度の低い検証はサンプリングにしないこと。失効の仕組みは、性能と運用の持続可能性まで含めて成立する。

出典：[2][1]

編集部の実務提案

保管場所とCookie属性が失効の前提になる

セッションIDやトークンの置き場所は、失効以前の問題として重要である。OWASPは、認証トークンやセッションIDをlocalStorageやsessionStorageに保存しないよう明確に求める。スクリプトから読み出せる場所に置けば、XSSひとつで持ち出され、失効の設計以前に盗難が成立する。HttpOnly、Secure、SameSiteを備えたCookieか、BFFパターンが推奨の置き場所である。

Cookie属性は個別に意味を持つ。HttpOnlyはスクリプトからの読み取りを防ぎ、Secureは暗号化された接続でのみ送らせ、SameSiteは他サイト起因の送信を絞る。属性の欠けは、そのまま攻撃経路の開きである。設定の監査では、属性の一覧確認を定型項目にする。

置き場所が決まれば、ログアウト時の掃除の範囲も決まる。サーバー側の無効化と、クライアント側の資格情報の除去はセットである。どちらか片方だけでは、画面上はログアウトしていても実際の再利用が可能だったり、逆にサーバーに残骸が溜まったりする。

モバイルアプリやSPAでは、保管場所の選択肢が変わる。安全なストレージの利用、端末紛失時の遠隔失効との連動、OSのキーストアの活用。ウェブの原則をそのまま持ち込むのではなく、プラットフォームごとの保管と失効の手段を対応づけて設計する。

サードパーティ連携のトークンも射程に入る。連携先のアクセストークンを自社で保持している場合、その失効や削除は連携解除の手順に含める。利用者のアカウント削除時には、自社のセッションだけでなく、保持している外部トークンの破棄までが完了条件になる。

保管と失効は、プライバシーの観点からも結びつく。不要になったセッション情報やトークンの記録をいつ消すかは、保持期間の設計の問題である。セキュリティのための記録と、持ち続けること自体のリスクの間で、期間の根拠を言語化しておく。

端末側の事情も保管設計に入れる。共有端末やキオスク端末では、ブラウザを閉じた時点でセッションを終わらせる設計や、資格情報を残さない設定が要る。利用環境の多様性を棚卸しし、環境ごとに保管と終了の既定を変える。個人端末前提の設計を共有環境に流用することは、古典的な事故のパターンである。

出典：[1]

編集部の実務提案

運用としての失効。強制失効・棚卸し・監査

失効は機能であると同時に、運用の手順である。漏洩の疑いがあるときに、誰が、どの画面や手順で、対象者のセッションを強制失効できるか。サポート現場でアカウントの乗っ取り相談を受けたとき、失効の実行権限と手順が整備されているかどうかが、被害の広がりを決める。

強制失効の権限は、濫用の防止とセットで設計する。失効操作そのものの認証と記録、実行前後の本人への通知、二重化された承認の要否。強い権限には強い統制を、という原則はセッション管理でも同じである。

セッションの棚卸しも運用に含める。長期間生きているセッション、通常と異なる地域や端末からのセッション、退職者や契約終了者の残存セッション。これらを定期的に洗い出して失効させる運用は、個別の期限設計を補完する。発行の統制だけでは、組織変更に伴う残存は防げない。

監査ログの設計も要る。ログイン、ID更新、期限切れ、ログアウト、強制失効といったイベントを、利用者とセッションの識別子付きで記録する。調査の場面では、「いつ、どのセッションが、どう終わったか」を辿れることが、事実関係の確定に直結する。

利用者向けの見える化は、運用の負荷も下げる。ログイン中の端末一覧と、見覚えのないセッションを自分で失効できる画面があれば、異常の発見は利用者自身が担ってくれる。通知とセルフサービスの設計は、サポートへの相談を「異常の早期報告」に変える。

まとめると、セッションの設計は発行の設計と同じ重さで、終わり方の設計を持つべきものである。2つの期限、権限変更での更新、サーバー側の無効化、短命化とデナイリスト、保管場所、そして運用手順。この輪が閉じていれば、セッションは盗まれても、時間と範囲の両面で被害を限定できる。

出典：[1][2]