情報処理安全確保支援士 2014年 秋期 午後2 問01

解答の論理構成

1. 図1のシーケンス 12 で日本認証サーバが実行する処理が「a の発行」である。
2. 本文には、
   • 「日本認証サーバは、利用者認証が成功すると、認証Cookieを発行し、認証成功を示すメッセージと日本のポータルサーバ … へのリンクをブラウザに表示する。」
     と明記されている。
3. また、図1の後続シーケンス 17・22 では日本ポータル、日本社内システムが「a の検証」を行うが、本文には、
   • 「日本ポータル及び日本社内システムでの認証Cookieの検証では、… エージェント … が … 呼び出される。」
     とあり、検証対象が「認証Cookie」であることが示されている。
4. 発行対象・検証対象が共に一致する必要があるため、a に入る語は「認証Cookie」で確定する。

誤りやすいポイント

• SPNEGO に注目し過ぎて「サービスチケット（ST）」と誤答する。図1の 12 は ST の発行ではなく、日本認証サーバ自身が作るブラウザ用データである点に注意。
• 「Cookie」とだけ書き、「認証Cookie」と特定しない。本文引用にある正式語句は「認証Cookie」であり、省略は減点対象になりやすい。
• 図2・図3の類似フローと混同して「相互レルムチケット（CRT）」などを選んでしまう。図1は日本地域固有のフローである。

FAQ

解答の論理構成

1. 図3で b が登場する箇所
   ・ステップ3
   “アジアDS → アジア認証サーバ：HTTP要請（b のURI）”
   ・ステップ8
   “アジア認証サーバ → アジアポータル：HTTP要請（b のURI）”
2. ステップ8は送信元が“アジア認証サーバ”、送信先が“アジアポータル”です。したがって b の URI を持つサーバは “アジアポータル” でなければ整合しません。
3. さらに本文には、 “ブラウザは、ホームページとして設定されたアジアポータルにアクセスしようとする。”
   とあり、最初に呼び出されるリソースがアジアポータルの URI であることが示されています。
4. 以上より、b に入る語は “アジアポータル” となります。

誤りやすいポイント

• “アジア認証サーバ” と誤答するケース
  ステップ3の送信先がアジア認証サーバなので混同しやすいですが、URI の所有者は送信“先”ではなく、要求対象のリソース側（＝ポータル）です。
• “アジアLDS” と混同するケース
  LDAP 要求は別経路で行われるため、HTTP 要求の URI にはなりません。
• 図中のライフラインの方向を読み違え、送信先と要求対象を取り違えるミス。

FAQ

解答の論理構成

1. 問題文はアジア地域の ID 登録フローを
   「“正社員及び契約社員は…自らID とパスワードの登録をアジア地域の情報システム部に依頼している”」
   「“情報システム部は、依頼内容に沿ってアジア LDS に ID とパスワードを登録する”」
   と記述しています。
2. つまり登録依頼は本人→情報システム部で完結し、承認者（所属長など）のチェック工程が存在しません。
3. そのため「社内システムにアクセスする必要があるか」を客観的に判断・記録する仕組みがなく、依頼さえあれば誰でも ID を得られる状態になります。
4. よってセキュリティ上の問題は「承認不在で不要な ID が発行されるリスク」であり、模範解答の内容に帰結します。

誤りやすいポイント

• アジア DS とアジア LDS を混同し、DS 側に既に ID があるので安全と考えてしまう。
• 「依頼」は社内申請書などで上長承認があるはず、と思い込み本文にない手続きを補完してしまう。
• 問題点を「人事システムと連携していない」こと自体に置き、承認欠如のリスクに触れない。

FAQ

解答の論理構成

1. 本文の下線部には
   「①エージェント型の認証サーバを採用した場合、GポータルやGシステムに市販のパッケージ製品を採用する際に大きなカスタマイズが必要」
   と記載されています。
2. 日本の既存方式では
   「日本認証サーバと併せて開発された、エージェントと呼ばれるJavaプログラムがアプリケーションプログラムからメソッドとして呼び出される」
   とあり、アプリケーション側（ポータルや業務システム）がエージェントを呼び出すことで認証 Cookie を検証しています。
3. したがって、エージェント型を採るなら Gポータル／Gシステムの内部処理に「エージェント呼出し」を組み込む改修が必須です。
4. 上記より、必要なカスタマイズは「GポータルやGシステムからエージェントを呼び出すための変更」と整理できます。

誤りやすいポイント

• エージェント側の改修と誤解し、ポータル／システム側の改修だと気付かない。
• 認証 Cookie 形式の統一や HTTP ヘッダ挿入など、他の変更点を答えてしまう。
• 下線①が「大きなカスタマイズ」全般を指すと勘違いし、具体内容を掘り下げない。

FAQ

解答の論理構成

1. SPNEGO は Kerberos を利用して異なるドメイン（レルム）間の認証トークンをやり取りします。
   ―【問題文】「SPNEGOによるSSOを実現するためには、②GDSと各地域のDSに関する変更…」
2. Kerberos でレルムを越えてサービスチケット（ST）を取得するには、認証サーバ同士が“信頼関係”を結んでいる必要があります。
   ―【問題文】「欧米DS1及び欧米DS2には、お互いを信頼するという設定が行われている」
   ―【問題文】「現在、N社の中のDS間で信頼関係が結ばれているのは、欧米DS1と欧米DS2間だけである」
3. GIAM では GDS がグローバルレルムを担い、地域 DS とチケットを相互利用できなければ PC ログオン後に Gシステムへ SSO できません。
4. したがって、②で求められる変更内容は「GDS と各地域 DS との間に信頼関係を設定すること」と導けます。
   ―【模範解答】「GDSと各地域のDS間で信頼関係を結ぶ。」

誤りやすいポイント

• 「DNS やドメイン名の統一」を答えてしまう
  → 信頼関係がないと ST 交換ができず SSO が成立しません。
• 「ID の重複排除」と混同する
  → ID 体系は③の変更事項であり、②とは別です。
• “DS を統合する” と書いてしまう
  → 既存 DS を残したまま信頼関係を設定すれば十分です。

FAQ

解答の論理構成

1. 【問題文】には、欧米地域について「IDの体系は日本と同じであり、日本と重複しているIDがある」と明記されています。
2. GIAM システムでは、全世界で一意となる ID「GID」を使って認証・属性参照を行う設計です。そのため、ID が重複していると同一人物かどうかを特定できず、認証・アクセス制御に支障が生じます。
3. そこで Y さんは SPNEGO による SSO を全地域で実現するために「③ID体系に関する変更」を検討しました。これは ID 重複を解消し、各利用者を一意に識別できるようにする施策です。
4. 以上より、下線③で求められた変更は「日本と欧米地域の ID 重複」という現状の課題を解決するために必要であると結論付けられます。

誤りやすいポイント

• アジア地域の ID 改修と誤解する
  → アジアは「他の地域と重複している ID はない」とあり、問題は発生していません。
• ID 文字数や形式の変更と考える
  → 形式ではなく「同一 ID が複数利用者に使われている」ことが本質的問題です。
• SPNEGO 導入＝自動的に解決と考える
  → SPNEGO 自体は認証プロトコルであり、ID の一意性は別途保証しなければなりません。

FAQ

解答の論理構成

1. Yさんが設計したID管理サブシステムでは
   「日次で各地域の人事システムから正社員の利用者情報を収集」
   と明記されており、対象が正社員に限定されています。
2. しかし日本の現状について「契約社員は、支店ごとに…人事システムを使わずに管理している」と【問題文】に記載されています。同様にアジア地域でも「正社員及び契約社員は…自らIDとパスワードの登録を…依頼」とあり、人事システムには載りません。
3. よって人事システムからのみ情報を収集しても契約社員のデータは取得できず、GIAMシステムに登録されない利用者が発生します。
4. Z主任が「各地域の人事システムとは別のサーバから利用者情報を収集する必要がある」と助言したのは、この欠落を補うためです。
5. 以上より、不十分な点は「契約社員の利用者情報が取り込まれない点」と結論付けられます。

誤りやすいポイント

• 人事システムに全従業員が登録されていると早合点し、契約社員を見落とす。
• 「別のサーバ」をバックアップ系などと誤解し、本質が契約社員データ補完であることに気付かない。
• 地域間で運用が異なる事実（アジアでは自己申請など）を読み飛ばし、正社員と同じ流れだと思い込む。

FAQ

解答の論理構成

1. 収集対象に含めるべき利用者
   Z主任は下線④で「各地域の人事システムとは別のサーバから利用者情報を収集する必要がある」と助言しています。理由は、 ・日本と欧米では契約社員が人事システムに登録されない
   ・アジアでは人事システムとアジアLDSが「連携していない」
   ため、人事システムだけでは G システムを利用する全従業員（正社員＋契約社員）を把握できないからです。
2. 日本地域の適切なサーバ
   日本では「IDと証明書を日本DSに登録し、IDと証明書を格納したICカードを…貸与する」と明記されています。日本DSには正社員・契約社員双方の ID が必ず登録されているので、収集先は「日本DS」です。
3. 欧米地域の適切なサーバ
   欧米では「欧米地域の情報システム部は、新しい正社員又は契約社員のIDと初期パスワードを欧米DS1に登録し」と記載されています。契約形態を問わず全利用者が登録されるのは欧米DS1のみなので、「欧米DS1」が収集先になります。
4. アジア地域の適切なサーバ
   アジアでは「正社員及び契約社員は…自らIDとパスワードの登録をアジア地域の情報システム部に依頼している。情報システム部は…アジアLDSにIDとパスワードを登録する」とあります。G ポータル／G システムにログインするにはパスワードが必要なため、ID とパスワードを同時に保持する「アジアLDS」が最適です。
5. 以上より、収集元として三つ選ぶサーバは
   • 日本DS
   • 欧米DS1
   • アジアLDS

誤りやすいポイント

• 「アジアDS」を選択してしまう
  アジアDSにはパスワードが登録されないため、パスワード認証を行う G 認証サーバで扱えません。
• 「欧米DS2」を選択してしまう
  欧米DS2 には「欧米地域の各サーバのコンピュータ名」が登録されるだけで利用者情報は含まれていません。
• 人事システムを収集先に含めてしまう
  契約社員が登録されない地域があり要件を満たせません。

FAQ

解答の論理構成

1. Gポータルが生成するリンク
   – 設計では「Gポータル…ポータル画面を生成し、Gシステム及び当該利用者が所属する地域のポータルサーバへのリンクを表示する」とある。
   – つまり現状は “地域のポータルサーバ” そのもの（日本なら「日本ポータル」）の URI を掲載している。
2. 日本地域だけが“ポータルサーバ単独アクセス不可”
   – 日本では、まず「ブラウザは…日本の認証サーバ…にアクセス」し、そこで Cookie を受取り、続いて「日本ポータルは、認証Cookieの検証を行う」。
   – 逆に言えば、日本ポータルへ直接アクセスしても Cookie が無ければ検証が失敗し、「アクセスが失敗する」。
3. 欧米・アジアは問題にならない
   – 欧米は「リバースプロキシ型の認証サーバ製品 (P) を利用」しており、ポータルの URI 自体が認証サーバを経由。
   – アジアも「アジア認証サーバは…フォーム認証を利用…SSOの対象は、アジア地域のポータルサーバ」とあり、リンク先の URI が認証サーバ。
   – 従って“失敗”が起こるのは「日本」だけ。
4. 正しいリンク先
   – 日本で認証 Cookie を発行するのは「日本認証サーバ」であり、ここを経由して初めて日本ポータルに到達できる。
   – よって、Gポータルが載せるべき URI は「日本認証サーバ」。
5. まとめ
   – 地域: 日本
   – サーバ名（10字以内）: 日本認証サーバ

誤りやすいポイント

• 「日本ポータル」が失敗原因と考え、日本ポータルへのリンクを残したまま Cookie 設定を疑ってしまう。
• 欧米も日本と同様に“ポータル直接アクセス不可”と思い込む（欧米はリバースプロキシで統合されている）。
• 「サーバ名10字以内」の指示を読み落とし、“日本認証サーバのURI” など冗長表記にしてしまう。

FAQ

解答の論理構成

1. 二要素認証を導入した背景
   【問題文】には「インターネット経由の仮想デスクトップへのアクセスにおいては、二要素認証を実装したい。」と明記されています。ここで求められる“二要素”とは、異なるカテゴリーの認証要素を2種類組み合わせることを意味します。
2. 具体的な二つの認証要素
   同じ段落で「VPN接続用のID（以下、VPNIDという）とパスワード（以下、VPNパスワードという）が割り当てられ、ハードウェア型のワンタイムパスワード（以下、OTPという）トークンが貸与される。」と記載されています。
   • 「パスワード」は“知識要素”（利用者が知っている情報）
   • 「OTPトークン」は“所持要素”（利用者が持っているデバイスで生成される使い捨てコード）
     以上より、設問で求められる二要素は「パスワード」と「OTPトークン」になります。

誤りやすいポイント

• 「ID」や「VPNID」を要素に含めてしまう
  IDは公開情報であり認証要素には含まれません。
• 「ICカード」を選択してしまう
  ICカード方式は拡張GIAMシステムでは採用していないと【問題文】に示されています。
• 「パスワード」「OTP」の表記ゆれ
  解答欄は8字以内指定ですので「ワンタイムパス」など長い表記は不適。

FAQ

解答の論理構成

• 本文には、ICカード方式を採用しなかった理由として
  「⑥Yさんは、採用した場合、ICカードリーダの追加導入や持ち運びが必要になる上、テスト工程の期間と工数が大きくなると説明した」
  とあります。
• さらに要望2では、自宅などから「個人所有のPCやタブレット端末（以下、個人所有機器という）」を使う利用形態が提示されています。
• ICカード方式を導入すると、全ての個人所有機器に外付けICカードリーダを接続し、 ①デバイスごとにドライバが正しく動くか
  ②ICカード認証処理が各OS・ブラウザ上で正常に機能するか
  ③VPN・シンクライアント経路でも認証情報が正しく引き継がれるか
  を確認する必要が生じます。
• このように「多種多様な個人所有機器 × ICカードリーダ」の組合せを網羅的に試験するため、テスト工程が長期化・大規模化すると判断できます。
• したがって検証すべき機能は「多種の個人所有機器での利用者認証の動作」であり、模範解答と一致します。

誤りやすいポイント

• 「ICカードリーダ導入のハード費用が増える」とだけ捉え、テスト観点を答え忘れる。
• テスト対象を社内PCのみに限定し、個人所有機器を考慮しない。
• 「二要素認証の検証」と答えてしまい、ICカード固有の試験範囲を外してしまう。

FAQ

解答の論理構成

1. 前提条件
   • 本文には、利用者が所属する地域のシンクライアントサーバへ接続する方式を採った理由として、下線⑦が示されています。
   • その前段に「拡張GIAMシステムでは、自宅又は出張先にいる利用者は、個人所有機器から自分が所属する地域のVPNサーバ経由で自分が所属する地域のシンクライアントサーバにアクセスし…」とあり、地域をまたぐ接続を避けている設計が読み取れます。
2. 他地域に接続した場合の状況
   • 他地域のシンクライアントサーバにアクセスすると、表示データ・キーボード／マウス操作が広域ネットワークを横断して往復します。
   • 本文には広域ネットワークを示す「広域イーサネット」が登場しており、地域間は長距離回線で結ばれていることが分かります。
3. 起こり得る問題
   • 長距離回線では伝送遅延が増加します。通信単位の往復が操作の都度発生する仮想デスクトップでは、遅延＝レスポンス低下に直結します。
4. 解答導出
   • よって「ネットワーク遅延が大きいことから、仮想デスクトップの操作に対するレスポンスが悪化する。」という模範解答に至ります。

誤りやすいポイント

• 帯域不足と遅延を混同し、単に「トラフィック増大」と答えてしまう。
• VPNによる暗号化オーバヘッドのみを問題視し、本質の距離による遅延を見落とす。
• 「画面が粗くなる」など画質面を強調し、レスポンス（応答時間）を指摘しない。

FAQ

解答の論理構成

1. 下線⑧の指摘
   • 問題文には「⑧一部の地域の利用者は、PCにおける利用者認証の後、Gポータル及び地域のポータルサーバにアクセスしようとしたときにIDとパスワードの再入力が必要である」とあります。
   • どの地域かを特定するには、各地域のPC‐Web間のSSO設定を比較します。
2. 各地域のSSO状況
   • 日本：表1に「PCと社内システムにおけるシングルサインオン　―　“SPNEGOプロトコルによって実現”」とあり、PCログオン後はWebアクセス時に再入力は不要です。
   • 欧米地域：同表で空欄ですが本文に「“ブラウザ及び欧米認証サーバは、SPNEGOによるSSOを利用するように設定されている。”」とあり、再入力は発生しません。
   • アジア地域：本文に「“アジア認証サーバは、SPNEGOではなくフォーム認証を利用しており、アジア地域のPC…にSPNEGOの設定はされていない。”」と明示されています。また表1には「PCと社内システムにおけるシングルサインオン　―　“実現されていない”」とあります。
3. 論理的帰結
   • SPNEGOが未設定＝PCログオン情報をWebアクセスに引き継げず、Gポータルや地域ポータルに接続する際にID／パスワード再入力が必要になります。
   • 以上より、再入力が必要な地域は「アジア地域」と判断できます。

誤りやすいポイント

• 「表1」の空欄だけを見て欧米地域もSSOなしと誤解する。本文中でSPNEGO設定済みであることが補足されています。
• PCログオン方式（ICカード／パスワード）とWeb SSO方式（SPNEGO／フォーム認証）を混同しがちです。再入力要否は後者で決まります。
• “一部の地域”＝複数と思い込み、日本＋アジアや欧米＋アジアと答えてしまう。条件に合うのはアジアのみです。

FAQ

解答の論理構成

1. SSOが成立していない地域はどこか
   • 表1の“PCと社内システムにおけるシングルサインオン”欄には、アジア地域が“実現されていない”とあります。
2. SSOが成立しない理由の特定
   • アジア地域の説明に「アジア認証サーバは、SPNEGOではなくフォーム認証を利用しており、アジアPCにSPNEGOの設定はされていない」とあります。
3. どの構成要素を変更すれば日本・欧米と同等のSSO方式に統一できるか
   • 日本や欧米では「製品Pは、SPNEGOによるSSOを利用するように設定される」とし、対応するPCブラウザ側も「SPNEGOによるSSOを利用するように設定されている」と記述されています。
   • よって、アジアでも同様に(1)認証サーバ側（製品P）と(2)クライアントPC側をSPNEGO対応にすれば、Z主任が指摘した「IDとパスワードの再入力」問題は解消できます。
4. 最終的な設定対象と内容
   • 構成要素：「アジア認証サーバ」
     設定内容：SPNEGOの設定をする
   • 構成要素：「アジアPC」
     設定内容：SPNEGOの設定をする

誤りやすいポイント

• 「アジアDS」や「アジアLDS」を設定対象に選んでしまう
  SPNEGOはHTTP／Kerberos連携のため、ディレクトリサービス自体ではなく認証サーバとブラウザ設定が本丸です。
• GポータルやGLDSが原因と考える
  これらはSPNEGO後に動作するため直接の解決策になりません。
• “フォーム認証＋Cookie”のままでもSSOに見えるのでは？と誤解
  フォーム認証はブラウザ再訪問ごとに資格情報を送るためKerberosベースのSSOとは別物です。

FAQ