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

解答の導き方

誤りやすいポイント

• inetOrgPersonを「スキーマ」とする誤答：inetOrgPersonはオブジェクトクラスであり、オブジェクトクラスや属性タイプを定義するのがスキーマです。用語を取り違えると誤答になります。
• 図7を見て「単なる例示のテキスト」と判断する誤り：dn: で始まり属性: 値 が続く形式はLDIFの特徴的書式です。形式に着目してください。
• SAMLをJSONや他の表現形式と混同する誤り：SAMLはXMLベースの仕様です。SAMLRequest/SAMLResponseがメッセージ名として出ている点で判断できます。
• 「認可」と「属性情報」を混同する誤り：SAMLがやり取りする「属性」と「認可（アクセス許可の判定）」は別概念です。設問文の語順（認証及び〜）から「認可」が自然です。

FAQ

解答の論理構成

1. 【問題文】では「①DCが生成した疑似乱数をチャレンジ」と明記され、C-CR認証はチャレンジ値と利用者の「利用者ID、パスワード」を連結してハッシュ化したレスポンスを返します。
2. DCが毎回同じ疑似乱数を生成してしまうと、チャレンジ値が固定値になります。
3. 固定値であれば、攻撃者はネットワーク上を盗聴して「チャレンジとレスポンスのペア」を取得できます。
4. 次回以降の認証時もチャレンジ値は同じなので、攻撃者は盗んだレスポンスを再送（リプレイ）するだけで認証を通過できます。
5. したがって脅威は「リプレイ攻撃によるなりすまし」であり、模範解答の内容となります。

誤りやすいポイント

• 「パスワード自体が漏えいする」と勘違いしがちですが、実際にはハッシュ化されたレスポンスだけで認証を突破できることが問題です。
• 「乱数が同じ＝衝突攻撃」と混同しやすいですが、本設問はハッシュ衝突ではなくチャレンジ値の再利用が焦点です。
• Kerberos認証のチケット再利用と混同し、回答をKerberosのリプレイ防御策として書いてしまうミスが目立ちます。

FAQ

解答の論理構成

1. 【問題文】では、Kerberos認証を利用する際の運用方法として「②有効期限切れのチケットが悪用されないように、DCとサーバをaさせて運用している。」と示されています。
2. Kerberosでは、チケットの有効期限を超えた再利用（リプレイ攻撃）を防ぐために、クライアント・KDC（ここではDC）・サービスサーバ間で時刻が一致していることが前提です。
3. 時刻がずれると、
   • 期限内の正規チケットが「期限切れ」と誤判定される
   • 逆に期限切れチケットが「期限内」と誤判定される
     可能性が生じるため、必ず「時刻同期」を行います。
4. 以上より、空欄 a にはKerberosの安全性を確保する運用要件である「時刻同期」が入ります。

誤りやすいポイント

• Kerberos認証＝暗号化通信と連想し、「暗号鍵共有」「証明書検証」などを入れてしまう。
• NTPがインフラ系に記載されていることから「NTPサーバ連携」と具体名を書いてしまう（設問は“字句”を問うため抽象化が必要）。
• 「チケット更新」「有効期限管理」といった類義語を選び、時刻同期という根本要件を見落とす。

FAQ

解答の論理構成

1. 認証統合前のシステム状況
   ・A‐SSOシステムは「A‐SSOサーバ及びA‐SSO用のディレクトリ」で構成され、認証後に「トリプルDESを用いて暗号化」したクッキーを発行します。
   ・「すべてのA-Webアプリには、クッキーを復号するために暗号化鍵を配布している」と明記されています。
2. 脆弱性判定のための前提条件
   ・図1の(5)は「A-SSOシステムには脆弱性がある」とだけ述べ、具体的内容は利用者に委ねています。
   ・A-Webアプリは「製品サポート部」「製品開発部」「研究部」「基幹業務系」など複数の所管部門にまたがります。
3. 暗号鍵配布方式の問題点
   ・クッキーを復号できるということは、暗号鍵を保持する全アプリが同一鍵でクッキーを解読・改ざんできる状態にあることを意味します。
   ・部門ごとの運用レベルは図1(3)で「同じレベルのセキュリティが確保されていない」と指摘済みです。
   ・低い管理レベルの部門で鍵が漏えいすれば、他部門のA-Webアプリにも影響が及ぶため、組織横断で深刻な脅威となります。
4. 以上より導かれる脆弱性
   「所管部門の異なるA-Webアプリのすべてに同一の暗号化鍵を配布していること」が脆弱性である、との結論に至ります。

誤りやすいポイント

• クッキー自体が脆弱と勘違いし、暗号鍵の「共有」部分を見落とす。
• 図1(5)の“脆弱性”をA-SSOの「インターネットドメイン制約」だと思い違いする。これは本文中で番号付き課題「③」として別に扱われています。
• 暗号方式（「トリプルDES」）の強度に焦点を当てる誤答。問題は鍵管理であり、アルゴリズムの強度ではありません。

FAQ

解答の論理構成

1. ③の課題
   【問題文】では、下線③として「A-SSO用のクッキーの利用が原因となり、A-SSOサーバとA-Webアプリが同じインターネットドメイン上にないとシングルサインオンを実現できない」という制約が示されています。ブラウザのクッキーはドメイン外に送信されないため、異なるドメイン間ではSSOが機能しないのが原因です。
2. SAML型SSOの仕組み
   図9の(d)には「IdPは、利用者IDなどの属性を暗号化及びディジタル署名したSAMLResponseメッセージを発行し、ブラウザ上のJavaScriptを用いて、それをSPに転送する」と明記されています。
3. 課題への対処
   SAML型SSOは「SAMLResponseメッセージ」を介してIdPとSPが認証情報をやり取りし、クッキーのドメイン制約に依存しません。したがって、異なるインターネットドメイン間でもIdPが発行した「暗号化及びディジタル署名したSAMLResponseメッセージ」をSPが検証することでSSOを実現できます。
4. 以上より、「暗号化及びディジタル署名したSAMLResponseメッセージを用いて、IdPからSPへ認証情報を転送している」という模範解答が導かれます。

誤りやすいポイント

• クッキーを完全に廃止すると誤解しやすいですが、SP側では「SP用のクッキー」を発行します。課題は“ドメイン依存のクッキー”であり、クッキーそのものの是非ではありません。
• 「IdPが直接SPに情報を送る」と短絡的に書き、図9(d) の「ブラウザ上のJavaScriptを用いて、それをSPに転送する」を見落としがちです。
• 「暗号化」と「ディジタル署名」の両方を記述し忘れると減点対象になります。

FAQ

解答の論理構成

1. 図1の(2)は、システムごとにパスワードの運用基準がばらばらで強度が揃わないことを問題視しています。
2. 統合認証システムでは、アカウント情報を「一元的に管理することとした」と明記されており、中心に据えたのが「IDM」です。
3. IDMについて本文では
   　 「利用者がパスワードを変更したい場合は、IDMのWebインタフェースを通して、利用者が自ら変更することが可能で、C-DIR又はLDAPサーバなどに、即時反映される仕組みとした。」
   　 とあり、パスワード更新が常にIDM経由で実施される設計であると読み取れます。
4. さらにIDMから「C-DIRのディレクトリ及びLDAPにアカウント情報を即時反映」するため、各システムが参照する最新パスワードは常に同一になります。
5. よって「管理フォーマットを一つにし、IDMでパスワードを一元的に管理し、それを各情報システムが参照する仕組み」が対策として妥当であると結論づけられます。

誤りやすいポイント

• SAML型SSOの導入＝パスワード統一と誤認し、IDMの役割を書き漏らす。
• 図1の(1)（IDの多重管理）と(2)（パスワードルール不統一）を混同し、解答をID統合の説明にしてしまう。
• 「一元化」は書いても「各情報システムが参照」という運用面の仕組みまで触れずに減点される。

FAQ

解答の論理構成

1. 【問題文】では「IdPを顧客のイントラネットに構築する」と明記されています。SAML型SSOでは、
   • IdP（Identity Provider）が“認証”を担当
   • SP（Service Provider）が“サービス提供”を担当
     という役割分担が行えます。
2. SAMLは「認証及びeに関する情報を交換するための標準規格」であり、IdPが発行するSAMLResponseをSPが受信するだけで利用者を識別できるため、SP側（＝A社側）は個別のアカウント情報やパスワードを保持する必要がなくなります。
3. したがって、顧客企業ごとにIdPを任せれば、利用者追加・削除、パスワード失効対応などの運用を顧客側で完結でき、「A社にとっても、IdPを顧客のイントラネットに構築することは運用管理上のメリット」となるわけです。
4. 以上より、模範解答は「SaaS型サービスのアカウント管理と運用を、必要に応じて、A社から切り分けることが可能となる」と導かれます。

誤りやすいポイント

• 「IdPを顧客側に置く＝セキュリティ責任を放棄」と誤解し、メリットを“責任逃れ”と書いてしまう。
• SPとIdPの役割を逆に捉え、「A社がIdPを運用するからメリット」と解答してしまう。
• SAMLの利点を可用性やスループットに結び付けるなど、運用管理から離れた観点で述べてしまう。

FAQ

解答の論理構成

1. A-SSOを利用している情報システムの把握
   • 表より「勤怠管理と施設予約はA-SSOシステムで認証」など、基幹業務系を含む複数システムがA-SSO連携であることが分かります。
2. それらのリプレース完了時期の確認
   • 本文に「2012年にはインフラ系のリプレースが予定されており、2013年には基幹業務系のリプレースが予定されている。」とあります。
   • リプレースは着手年の翌年末に本稼働すると図10で示されています（リプレース期間＝1年）。
3. A-SSO廃止の判断条件
   • 本文に「A-SSOシステムの廃止が可能になるのは、早くても、f年の末である。」と記載。
   • 基幹業務系はA-SSO依存度が高く、かつ最も遅くまで残るため、これが本稼働する “翌年末” がA-SSO全廃の最短時期となります。
4. 年度の導出
   • 基幹業務系リプレース開始：2013年
   • 本稼働（完了）：2013年の翌年末 → 2014年末
   • 従って f＝2014
5. 理由のまとめ
   • A-SSO連携システムがすべて置き換わる時点＝2014年末だから、という結論になります。

誤りやすいポイント

• 「2013年に基幹業務系リプレース予定」だけを見て2013と答えてしまい、実稼働開始が翌年末である点を見落とす。
• インフラ系リプレース（2012〜2013）でA-SSOを刷新することを “廃止” と読み違え、年を早めに設定してしまう。
• A-SSO利用範囲を基幹業務系以外（部署運用系など）と勘違いし、最遅リプレース年を取り違える。

FAQ

解答の論理構成

1. まずインフラ系サーバのサポート期限
   – 表中の備考に「インフラ系のサーバマシン群のベンダサポートは2012年末に終了する」とあります。
2. A社の運用ポリシー
   – 注(1)に「ベンダのサポートが終了する前に、情報システムをリプレースすることになっている」と明記されています。
3. A-SSOシステムの位置付け
   – A-SSOはインフラ系に含まれるシステムであり、同じタイミングでリプレース対象になります。
4. 結論
   – サーバマシンのサポートが2012年末で切れるため、期限内にリプレースしなければ運用ポリシーに反します。
   – よって g には「A-SSOシステムが稼働するサーバマシンのベンダサポートが2012年末で切れる」という理由が入ります。

誤りやすいポイント

• 「A-SSOの脆弱性」だけに注目しサポート期限を見落とす。
• インフラ系全体のリプレース条件を理解せず、A-SSOを単独で延命できると思い込む。
• 「2012年末」はサポート終了であってクッキーの技術的限界ではない点を混同する。

FAQ