セッションが盗まれたとき、token を検証するだけでは不十分です;セッションのコンテキストも検証する必要があります。
Session hijacking はクラシックですが依然として重大な問題です。ユーザーのセッション cookie が奪われると、攻撃者は同じ token でセッションを乗っ取ろうとします。システムが token の存在だけを見ているなら、その token がどの IP、デバイス、ブラウザ、ユーザーのコンテキストで生成されたかを確認しません。この場合、セッション ID 単独でセキュリティ境界になってしまいます。
Cookie セキュリティフラグの忘却も一般的な弱点です。HttpOnly がなければクライアント側のスクリプトが cookie にアクセスできます;Secure がなければ伝送層が弱まります;SameSite がなければクロスサイトリクエストがよりリスキーになります。これらの設定を各アプリケーションチームが一貫して適用することを期待するのは、大規模な組織では現実的ではありません。
Timeout 管理もしばしば不完全に構築されます。Idle timeout は最後のアクティビティの後どれだけセッションが開いたままになるかを定めます;absolute timeout はユーザーがアクティブでも、ログイン時点からの最大寿命を制限します。特に金融、ヘルスケア、エンタープライズポータルでは、これら 2 つの境界を別々に管理する必要があります。
同時セッション制御は標準の cookie システムでは自動的に解決しません。一人のユーザーが何台のデバイスからログインできるか、新規ログインは古いセッションを切るべきか、それとも新規ログインを拒否すべきか、といった判断には中央 session store とアクティブセッション追跡が必要です。複数ノード構成ではこの状況はさらに重大になります。
TR7 セッション保護はこのニーズを単一の policy graph の下にまとめます:session ID 生成、cookie セキュリティフラグ、IP / IP+UA / composite binding、idle および absolute timeout、最大同時セッション、オプションの cookie 暗号化が同じ管理モデルで統合されます。
私たちのアプローチ
TR7 はセッション保護を単一の cookie 設定としてではなく、生成から検証、更新から終了まで及ぶ多層的なポリシーとして適用します。
SAM 層が cookie と session ID の生成を管理する
SAM は session affinity、cookie 名、cookie ソース、session フォーマット、セキュリティフラグを一体で管理します。TR7 は session ID を生成することも、backend が生成した cookie で動作することもできます;UUID、IP+timestamp+random、IP+random、または custom フォーマットの選択肢を使用できます。
Session binding がログイン後のコンテキスト変化を捉える
セッションが開いた後、IP、IP+UA、composite、none の binding モードの一つを適用できます。コンテキストの変化が検出されると session mismatch がフラグされ、アプリケーションは再検証または追加チェックを要求できます。
オプションの cookie 暗号化が tampering と replay のリスクを軽減する
AES-256-CBC ベースの cookie 暗号化が有効化されると、選択された cookie はクライアント側で読み取れなくなります。IP+UA コンテキストから派生する追加のバインディングにより、token が別のクライアントで再使用されることが困難になります。
Redis ベースのアトミックな session refresh が timeout を安全に管理する
Session refresh 処理は Redis Lua 関数でアトミックに実行されます。Idle timeout は各アクティビティで更新できます;absolute timeout はログイン時刻に紐づいたままです。最大同時セッション制御も中央 session state を通じて適用できます。
ケイパビリティ
セッション保護は、異なるセキュリティおよびユーザー体験のニーズのために、即座に使えるプロファイル、binding の選択肢、timeout 管理、cookie セキュリティを提供します。
4 つの built-in policy preset が異なるセッションセキュリティプロファイルを提供する
default プロファイルは IP binding、8 時間 idle timeout、7 日 absolute timeout で、エンタープライズ標準利用向けに設計されます。session_strict プロファイルは IP+UA binding、30 分 idle、8 時間 absolute timeout、単一同時セッションでより厳格なセキュリティを提供します。session_relaxed プロファイルは binding なしで 7 日 idle、90 日 absolute timeout により長期 SaaS セッションに適しています。session_singleDevice プロファイルは IP binding と単一同時セッションポリシーで、ライセンスまたはデバイス制限を要するアプリケーションに使用されます。
Session ID フォーマットがアプリケーションとセキュリティのニーズに応じて選ばれる
TR7 は session ID フォーマットを単一の固定モデルに強制しません。ipTimestampRandom フォーマットは IP、時刻、random 値の組み合わせでデフォルトの強力なフォーマットを提供します;uuid フォーマットは不透明で IP を含まない値を生成します。ipRandom フォーマットは IP と random 値を使用します;custom フォーマットはオペレーターが header、cookie、またはカスタム変数から session キーを構築することを許可します。この柔軟性は異なるアプリケーションアーキテクチャに適応します。
Cookie security flags が中央で適用され標準化される
SAM 層で HttpOnly を最小セキュリティフラグとして構成できます。Secure、SameSite=Strict、SameSite=Lax などの追加フラグもポリシーレベルで加えられます。Cookie Max-Age 値は absolute timeout と関連付けられます。これにより各アプリケーションチームが cookie セキュリティ設定を個別に誤りなく行うことが期待されなくなります。
Cookie ソースを TR7 または backend として選べる
samCookieSource 値が TR7 のとき、session cookie は ADC 層で生成されます。backend が独自の cookie を生成し続けるなら、backend 由来の cookie を使用できます。ハイブリッドモデルでは backend の cookie があればその値で続行し、なければ TR7 が新しい session 値を生成できます。このアプローチは新しいアプリケーションにも古いシステムにも適応します。
4 つの binding モードが異なるセキュリティとモビリティのバランスを構築する
ip binding はユーザーがログインしたソース IP コンテキストを保ちます;エンタープライズオフィスや VPN シナリオで強力です。ip+ua binding は IP と User-Agent のペアを一体で評価してより厳格な制御を提供します。composite binding は Accept-Language、カスタム header、TLS fingerprint などの追加コンポーネントで拡張できます。none モードは長期セッションと頻繁なネットワーク変化のある SaaS 利用でより柔軟に振る舞います。
AES-256-CBC cookie 暗号化が選択された cookie で opt-in で動作する
Cookie 暗号化はデフォルトで有効とは見なされません;選択された cookie のために有効化されるオプションの保護です。有効なとき、response 側で cookie_encrypt、request 側で cookie_decrypt のフローが適用されます。各 cookie に salt、padding、base64 フォーマットを使用してクライアント側の値が無意味になります。Decryption が失敗したとき、その値は信頼できるセッションデータとして扱われず、アプリケーションは再検証または拒否の判断を下せます。
Idle と absolute timeout が別々に管理される
sessionIdleTimeout は最後のアクティビティの後どれだけセッションが有効なままになるかを定めます。sessionAbsoluteTimeout はログイン時点からの最大セッション寿命を制限し、アクティビティで継続的に延長されません。この区別は特にバンキング、エンタープライズポータル、機密データを含むアプリケーションで重要です。ユーザー体験とセキュリティ境界が同じポリシーでバランスされます。
最大同時セッションがユーザー単位で制限できる
maxConcurrentSessions 値で一人のユーザーが同時に持てるアクティブセッション数を定めます。制限を超えたとき、logout_oldest で最も古いセッションを切るか、deny_new で新規ログインを拒否できます。この構造は単一デバイスライセンス、バンキングセキュリティ、エンタープライズアクセス制御に使用できます。アクティブセッションリストは中央 session state 上で追跡されます。
Session lifecycle イベントが create、refresh、mismatch、logout として監視される
ログイン時に session が作成され、各 request 時に idle refresh が行われ、binding mismatch のときにセッションが疑わしい状態にフラグされ、logout 時に session が無効化されます。このライフサイクルは、セッションが開始時だけでなく全利用期間を通じて管理されることを保証します。SIEM と監査のフローはこれらのイベントからセキュリティシグナルを生成できます。特にアカウント乗っ取り調査では session 履歴が重要です。
Multi-node 構成でセッション継続性が peer sync と Redis で保たれる
複数の TR7 ノードで session state を保つため、peer 同期と Redis ベースの中央 store を併用できます。Failover や rolling restart のシナリオで session 継続性が保たれるよう設計されます。Redis 側の replication と永続性の選択肢で session state の耐久性を高められます。この構造はセッション保護が単一ノードに縛られることを防ぎます。
運用上の深さ
セッション保護は、cookie 名、attribute 生成、composite binding、監査カテゴリ、session store、timeout fallback の動作とともに運用されます。
構成可能な cookie 名
デフォルトの cookie 名は TR7SID として使用できます。各 pool に samCookieName で異なる名前を定義できます。これはブランド整合、アプリケーション標準、または既存の cookie アーキテクチャとの整合のために使用されます。
Runtime cookie attribute 生成
Cookie 値の生成時に HttpOnly、Secure、SameSite、Max-Age などの attribute がポリシー設定に応じて加えられます。これらの attribute は新しい session が生成されたときにのみ set できます。これにより cookie セキュリティが中央ポリシーで標準化されます。
Composite binding コンポーネント
Composite binding はデフォルトでソース IP と User-Agent などのコンポーネントで構築できます。オペレーターは Accept-Language、Accept-Encoding、カスタム header、TLS fingerprint などの追加コンポーネントを含められます。この計算は、関連する変数が生成された後の遅い段階で行われるべきです。
監査カテゴリ
セッションとアクセスのイベントは whitelisted、authorized、unauthorized などのカテゴリでログに記録できます。この情報は SIEM 側でアカウント乗っ取り、不正利用、不正アクセスの調査を容易にします。各 request についてユーザーとセッションのコンテキストがより見えやすくなります。
Redis session store
AAM session state は Redis 上に保持でき、session refresh 処理は Lua 関数でアトミックに実行されます。このモデルはクラシックなデータベースの遅延を session 制御経路から取り除きます。AOF や replication などの Redis 機能で永続性と耐久性を高められます。
安全な fallback 値
Idle timeout 構成が欠けている場合、1 時間の fallback を使用できます。Absolute timeout が欠けている場合、24 時間の fallback 値を適用できます。これらの値は、構成が欠けているときに無制限のセッションが生成されることを防ぐ安全な前提を提供します。
どのようなシナリオで使われるか
バンキングでの厳格な binding と単一デバイスセッション
バンキングアプリケーションはユーザーを単一デバイスに保ち、30 分の非アクティブでセッションを閉じたいことがあります。session_strict プロファイルは IP+UA binding、30 分 idle、8 時間 absolute timeout、単一同時セッションポリシーで適用されます。盗まれたセッションが異なるコンテキストで使用されると mismatch シグナルが生成されます。
SaaS アプリケーションでの長期で柔軟なセッション
B2B SaaS ユーザーはラップトップ、スマートフォン、タブレットから同じアカウントにアクセスしたいことがあります。session_relaxed プロファイルは binding なしで長い idle と absolute timeout 値によりユーザー体験を保ちます。IP の変化やデバイスの多様性が不要な再検証を生みません。
エンタープライズポータルでの IP binding と業務日セッション
従業員ポータルでユーザーはオフィスまたは VPN ネットワーク経由でログインし、業務日を通じて再ログインなしで作業します。default プロファイルは IP binding、8 時間 idle timeout、7 日 absolute timeout で適用できます。IP コンテキストが変化すると、アプリケーションは再検証を要求できます。
単一デバイスライセンスのための同時セッション制限
プレミアムアプリケーションまたはライセンス制のサービスは、アカウントを同時に単一デバイスで使用させたいことがあります。session_singleDevice プロファイルは max 1 concurrent session と logout_oldest 動作で、新規ログイン時に古いセッションを切ります。ライセンス共有と無制御な複数利用が困難になります。
よくある質問
Session binding mismatch が検出されたとき何が起こりますか?
Idle timeout と absolute timeout の違いは何ですか?
AES-256-CBC cookie 暗号化はデフォルトで有効ですか?
CSRF と JWT 保護はこのページの範囲ですか?
最大同時セッション制限を超えたとき何が起こりますか?
Multi-node TR7 構成でセッション継続性はどのように保たれますか?
セッションセキュリティをアプリケーションコードから取り出す
Session ID 生成、cookie セキュリティフラグ、IP+UA binding、timeout ポリシー、同時セッション制限を単一の policy graph の下に。お客様のサービスでのライブセットアップでご案内します。