【入門編】 SAML Replay Attack対策とInResponseTo、NotOnOrAfterの検証条件 – ゼロトラスト＆エンタープライズセキュリティ実践ガイド

認証の「なりすまし」を防げ！SAMLの安全性を支える「使い捨てチケット」の仕組み

こんにちは！ネットワークセキュリティの世界へようこそ。
日々、膨大なパケットが飛び交うネットワークの最前線でトラブルシューティングをしていると、「認証って、実は物理的な手紙のやり取りと全く同じだな」と感じることがよくあります。

今日は、企業システムのログインの要である「SAML（サムル）」についてお話しします。特に、「一度使ったはずのログインチケットを、悪意ある誰かが使い回そうとする」という恐ろしい攻撃――SAMLリプレイ攻撃をどう防ぐか、その知恵を紐解いていきましょう。

—

1. SAMLは「身分証明書付きの紹介状」

まず、SAMLの仕組みを現実世界に例えてみます。

あなたが新しいオフィスビルに入るとき、受付（サービスプロバイダ：SP）で「このビルの入居者である〇〇会社の人です」と証明したいとします。でも、あなたは名刺を持っていません。そこで、あなたの会社の信頼できる総務部（アイデンティティプロバイダ：IdP）が、「この人は正真正銘、うちの社員です」という「公式の紹介状」を発行してくれます。

あなたはそれを持って受付に行き、「はい、これが会社の紹介状です」と提示します。受付は「なるほど、会社からの封印もあるし、間違いありませんね」といって、あなたをビルの中へ通します。

これがSAMLの基本です。しかし、ここで一つ大きなリスクが生まれます。

—

2. もし、その「紹介状」が盗まれたら？

もし誰かが、あなたの持つその「紹介状」をコピーして、こっそり後から受付に持っていったらどうなるでしょう？ 受付は「さっきも同じ書類を見た気がするけど…まあ、本物っぽいし通しちゃえ」となってしまいますよね。これがリプレイ攻撃（再送攻撃）です。

これを防ぐために、SAMLには「使い捨て」にするための強力なガードレールが用意されています。それが以下の2つです。

① NotOnOrAfter：紹介状の「賞味期限」

この封筒には「発行日時」だけでなく「これ以降は無効」という期限が書かれています。
もし、悪意ある人が数日前に盗んだ紹介状を今さら持ってきたとしても、受付は「あ、これもう期限切れですね。ごめんなさい」と門前払いできます。

② InResponseTo：チケットの「紐付け」

これは「誰からのリクエストに対する返事か」を記す項目です。
あなたが受付に行くとき、あらかじめ受付に「今から〇〇という社員を向かわせますから、その準備をしてください」と予約を入れるようなものです。この予約番号（ID）が紹介状に書かれていないと、受付は「頼んでもいない紹介状なんて受け取れません」と拒否するのです。

—

3. 実装の現場で気をつけるべき「防御の要」

では、実際にシステムを構築する際、私たちは何をチェックすべきでしょうか？ 現場でよくある設定の勘所をまとめました。

認証設定のチェックリスト（XMLのイメージ）

SAMLレスポンスの構造は複雑に見えますが、注目すべきはここだけです。

<!-- 
  この部分は、SAMLレスポンスの「条件（Conditions）」セクションです。
  ここで厳密なチェックを行います。
-->
<Conditions
    NotBefore="2023-10-27T10:00:00Z"
    NotOnOrAfter="2023-10-27T10:05:00Z"> <!-- ここで賞味期限を管理！ -->
</Conditions>

<!-- 
  この部分は、受付が発行したリクエストIDとの照合に使います。
-->
<SubjectConfirmationData
    InResponseTo="_abc1234567890"  <!-- 予約番号が一致するか確認する -->
    Recipient="https://service.example.com/acs">
</SubjectConfirmationData>

現場のエンジニアが守るべき3つの鉄則

1. 時刻同期を疎かにしない
NotOnOrAfter は非常に短い時間（通常は数分程度）に設定します。もしサーバーの時計がズレていると、正常なユーザーまでログインできなくなります。必ず NTP 等で全サーバーの時刻を厳密に同期させてください。
2. ID（リクエストID）を必ず保存する
SP側で「ログインリクエストを出した際に発行したID」をセッションに一時保存し、返ってきたSAMLアサーションの InResponseTo と必ず突き合わせてください。これが一致しないものは、即座に「不正アクセス」としてログに記録しましょう。
3. 使い回し防止（Replay Cache）の実装
一度処理したSAMLレスポンスの「固有ID（Assertion ID）」を、一定時間データベースやキャッシュ（Redisなど）に保持し、「同じIDで二度目のアクセスが来たら無視する」という実装を加えると、さらに鉄壁になります。

—

最後に：セキュリティは「疑うこと」から始まる

ネットワークのパケットは、時に善意のエンジニアが送ったものか、悪意ある攻撃者が複製したものか、見た目だけでは判断がつきません。だからこそ、こうした「期限」や「紐付け」といった、泥臭いけれど確実な仕組みが重要になります。

初めてこの設定に触れるときは、XMLのタグの多さに圧倒されるかもしれません。でも、「これは誰からの手紙で、いつまで有効なのか？」という視点さえ忘れなければ、SAMLの複雑なパケットも、きっと手に取るように理解できるようになるはずです。

皆さんのシステムが、今日も安全に稼働し続けますように。また現場でお会いしましょう！

スポンサーリンク

コメント

タイトルとURLをコピーしました