情報処理安全確保支援士 2017年 春期 午後1 問03

解答の論理構成

1. 抽出の目的確認
   問題文では、暫定対策として「①F社以外からのログインがあった利用者IDを特定し」と指示されています。
   したがって、抽出条件は“F社以外”かどうかを判別できる項目に着目する必要があります。
2. 判別に使えるログ項目
   「F社で利用しているクラウドサービスではログイン記録として、アクセス日時、利用者ID、接続元IPアドレス、接続先URLが記録されている。」とあるため、接続が社内・社外のどちらかは「接続元IPアドレス」で判断できます。
3. “F社以外”の定義
   同じく問題文に「接続元IPアドレスとして、F社のIPアドレス以外に、海外のIPアドレスが一つあった。」という具体例が挙げられており、社内アクセスはF社の固定グローバルIPアドレスで記録されることが示唆されています。
4. 結論
   以上より、抽出すべきログイン記録は「接続元IPアドレスがF社のグローバルIPアドレスではない」ものとなります。

誤りやすいポイント

• 接続先URLで社外判定しようとする
  URLはクラウドサービス側のドメインで固定のため、社内外の判別には使えません。
• プロキシサーバの内部アドレスを条件に入れてしまう
  ログにはグローバルIPアドレスが記録される想定なので、内部アドレスでの絞り込みは不適切です。
• アクセス日時を条件に含める
  “社外から”という要件には日時は直接関係しません。

FAQ

解答の論理構成

1. 【問題文】には「利用者にサービスを提供するサービスプロバイダ（以下、SPという）と、IDプロバイダ（以下、IdPという）との間で…」とあります。図1の「処理4」でSAML Responseの署名検証を行い「サービスを提供すべきか決定」している主体はサービス提供側、すなわち SP です。図1ではこの処理を行うインスタンスが a なので、
   ⇒ a ＝ SP（ウ）。
2. 図1で最初に「サービス要求」を発し、その後IdPのログイン画面を要求・応答し、最終的にサービス提供を受けるのは利用者のブラウザです。よって
   ⇒ b ＝ 利用者端末のWebブラウザ（エ）。
3. 「処理2」「処理3」でSAML Requestの検証やSAML Responseの生成を行う主体は【問題文】が「IDプロバイダ（以下、IdPという）」と定義しているIdPです。したがって
   ⇒ c ＝ IdP（ア）。
4. 図1キャプション中に「IdPとLDAPサーバ間はLDAP」と明記されており、図の “認証要求” が c → d、“認証結果” が d → c となっています。これはIdPが社内のディレクトリサービスに対して認証を問い合わせている動きで、対象は LDAPサーバ です。よって
   ⇒ d ＝ LDAPサーバ（イ）。

誤りやすいポイント

• SPとIdPを逆に覚えてしまう
  「サービス要求が来る＝IdP」と早合点しがちですが、実際にサービス提供を行うのはSPです。
• 「LDAPサーバ」が表のどこに当たるかを見落とす
  図1では d だけLDAPプロトコルで通信していることが決め手です。
• ブラウザとSPの役割混同
  処理1が a 側で発生するため「利用者側で生成？」と誤読しがちですが、生成主体はSP。

FAQ

解答の導き方

誤りやすいポイント

• 処理3と処理4を混同しないようにします。処理3はIdPがSAML Responseを生成して署名する処理で、処理4はSPがその署名を検証する処理です。IdPのデジタル証明書が必要なのは、署名を検証する処理4です。
• 処理1で生成するのは、IdPのログイン画面へ利用者を誘導するためのリダイレクト先URLです。ログイン画面の応答や認証結果そのものではありません。
• SAML Responseに署名が付いていることと、署名の検証にIdPのデジタル証明書が使われることを、ひと続きの流れとして捉えます。

FAQ

解答の導き方

誤りやすいポイント

• Cookieは、ブラウザがサーバとの間で送受信する状態情報などを保存する仕組みです。URL内のパラメータ部分ではありません。
• HTMLは、Webページの構造や内容を記述する形式です。URL内でSAML Requestを取得する部分を指す語ではありません。
• スキームは、URLの先頭にある「http」や「https」など、通信方式を示す部分です。
• リファラは、アクセス元となった直前のページを示す情報です。URL内のパラメータ部分ではありません。

FAQ

解答の導き方

誤りやすいポイント

• [h]に、認証を受ける利用者やサービスを提供するSPを入れないようにしましょう。表1の処理3でSAML Responseを生成して署名する主体はIdPです。
• ディジタル署名の検証を、データを暗号化して内容を隠す処理と混同しないようにしましょう。ここで確認するのは、署名者とデータが改ざんされていないことです。
• [i]には「機密性」ではなく「改ざん」が入ります。データの内容を第三者に読まれないようにすることと、変更されていないことを確認することは別の性質です。

FAQ

解答の論理構成

• 本文では、「②IdPを社内ネットワークに設置しても認証情報の連携が成立する」と述べられています。
• 「図1中の各通信のプロトコルは、IdPとLDAPサーバ間はLDAPであり、それ以外はHTTP over TLSである。」という記述から、SPとIdPがHTTP over TLSで直接やり取りしていないことが分かります。
• 代わりに、処理シーケンスで次の流れが示されています。
  ・処理1：SPが「SAML Request」を生成し、リダイレクト先URLを生成
  ・処理2：「URL内の g からSAML Requestを取得」
  ここで、利用者端末のブラウザがSPからIdPへリダイレクトを実行し、SAML Requestを運搬します。
• さらに処理3でIdPが「SAML Response」を生成し、処理4でSPがその署名を検証しますが、両者の間でもブラウザがSAML ResponseをPOSTします。
• つまり、SPとIdPの間の認証情報（SAML Request／SAML Response）は「利用者端末のWebブラウザ」が搬送役を担うため、直接通信できなくても連携が成立します。
• よって模範解答「認証に関する情報を利用者端末のWebブラウザが中継するから」となります。

誤りやすいポイント

• 「HTTP over TLSなら直接通信している」と早合点し、ブラウザ経由のリダイレクト／POSTメカニズムを見落とす。
• 「IdPは社内ネットワークにある＝外部と通信できない」と考え、シーケンス全体を確認せずに不正解の理由を捻り出してしまう。
• SAMLの用語を混同し、「SAML Request」と「SAML Response」の流れを逆に覚えてしまう。

FAQ

解答の論理構成

1. 社外利用時に行われる最初の処理を整理
   • 利用者がクラウドサービス（SP）へアクセスすると、図1中「(1) サービス要求」が送信されます。
   • SPはSAML Requestを作成し、利用者をIdPのログイン画面へリダイレクトします（図1「処理1」→通信(2)）。
   • 利用者端末はIdPへログイン画面を要求します（図1「(3) ログイン画面要求」）。
2. 交通費精算サービスが失敗する理由
   • IdPを内部に設置：「IdPは社内ネットワークに設置し、IdPのログイン画面のURLのFQDNには、社内のFQDNを割り当てることにした。」
   • 社外から内部への通信は遮断：「社外から社内ネットワークへの通信はファイアウォールによって禁止されている。」
     → 社外端末は図1の通信(3)でIdPに到達できず、結果としてログインに失敗します。
   • よって答は「番号：(3)」、理由は「社外からIdPへの通信がファイアウォールによって遮断されるから」。
3. グループウェアサービスが失敗する理由
   • IP制限を有効化：「グループウェアサービスだけは、接続元IPアドレスを制限する機能を備えていたので、その機能を有効化し、社内からだけログインできるように設定した。」
   • 社外端末は最初のアクセス時点で拒否されるため、図1の通信(1)が成立しません。
   • よって答は「番号：(1)」、理由は「クラウドサービス側で接続元IPアドレスの制限が行われているから」。

誤りやすいポイント

• 「社外アクセス不可＝全部ファイアウォール遮断」と早合点し、グループウェア側のIP制限を見落とす。
• 図1の通信番号と処理番号（処理1〜4）を混同する。
• IdPが内部に置かれたことで失敗する通信を(2)と誤答する（実際に遮断されるのはIdPへのリクエストである(3)）。

FAQ