情報処理安全確保支援士 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

解答の論理構成

1. 問題文は、事前共有項目を列挙する文章の中で
   通信の方式や連携する属性情報などが記述されたメタデータ、eで生成して送出するURL、fにおいて必要なIdPのデジタル証明書などがある。
   と記述しています。
2. 表1を見ると、URLを生成して送出する処理は
   ・「IdP に認証を要求する SAML Request を生成する。」
   ・「エンコード結果を IdP のログイン画面の URL と組み合わせて，リダイレクト先 URL を生成する。」
   が含まれる「処理1」です。したがって e には「処理1」が入ります。
3. IdPのディジタル署名を検証する場面は表1の「処理4」に示されています。具体的には
   ・「SAML Response に含まれるディジタル署名を検証する」
   という行為でIdPのディジタル証明書が必要になります。よって f には「処理4」が入ります。
4. 以上より、解答は
   e：処理1
   f：処理4
   となります。

誤りやすいポイント

• 「URLを生成するから処理2」と早合点する
  → 処理2はSPからの認証要求の真正性を確認する段階であり、URL生成は行いません。
• 「ディジタル署名＝IdP側の処理だから処理3」と勘違いする
  → 署名付与は処理3ですが、検証に証明書が必要になるのは処理4です。問題文は「必要なIdPのデジタル証明書」と述べており、検証フェーズを指しています。
• 表1を読まずに図の流れだけで判断する
  → 表1が最も直接的なヒントになります。設問は表番号と連動している点を見逃さないことが重要です。

FAQ

解答の論理構成

1. 【問題文】では処理2について
   「URL 内の g から SAML Request を取得する。」と明示しています。
2. SAML の HTTP Redirect Bindings では、SAMLRequest パラメータを URL の「クエリ文字列」に付加して IdP へ転送します。
3. したがって、SP が IdP に対して SAML Request を渡す媒体は「URL のクエリ文字列」であり、IdP 側はそこから SAML Request を取り出して検証を行います。
4. 解答群を照合すると
   ・「ウ：クエリ文字列」だけが URL 内に含まれ、かつ値を受け渡す領域であるため条件を満たします。
5. よって g には「ウ：クエリ文字列」が入ります。

誤りやすいポイント

• 「Cookie」を選択してしまう
  SAML Request はブラウザ→IdP の 1 回限りのリダイレクトで渡されるため、Cookie に格納する必要がありません。
• 「リファラ」を選ぶ誤認
  Referer ヘッダは遷移元 URL を示すだけで、要求本体（SAML Request）の受け渡しには使われません。
• 「HTML」と「スキーム」の混同
  HTTP-POST Binding では HTML フォームを用いますが、本設問は HTTP Redirect Binding のフローなので該当しません。

FAQ

解答の論理構成

1. まず、空欄 h・i が登場する記述を確認します。
   引用：「・SAML Response に含まれるディジタル署名を検証することによって，ディジタル署名が h によって署名されたものであること，及びデータの i がないことを確認する。」
2. SAML の署名者
   • SAML Response を作成する主体は「IdP（Identity Provider）」です。
   • 表1「処理3」の引用：「・利用者の認証が成功した場合 … SAML Response を生成する。」
   • したがって署名を付与するのも IdP であり、検証時には「IdP によって署名された」ことを確かめる必要があります。
     ⇒ h ＝ IdP。
3. 検証対象の性質
   • ディジタル署名確認の目的は、真正性（誰が署名したか）と完全性（改ざんがないか）の二点です。
   • 完全性を表す代表的語句は「改ざん」や「改変」です。
   • 文脈では「データの［　］がないことを確認する」とあるため、「改ざんがないこと」が適切です。
     ⇒ i ＝ 改ざん。
4. 以上より
   • h ＝ IdP
   • i ＝ 改ざん

誤りやすいポイント

• 署名者を「SP」と勘違いする。SAML Response は IdP が発行するため、SP が署名者になることはありません。
• 「完全性＝改ざん防止」を連想できず、「漏えい」「消失」などと書いてしまう。
• SAML の用語（IdP／SP／利用者エージェント）の役割混同。特に Response と Request の生成主体を逆に覚えていると誤答しやすいです。

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