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

解答の論理構成

1. 【問題文】では
   “パスワードを用いる利用者認証では、ログインする人のaを確認していました。”
   とあります。パスワードは「知っていること」に基づく認証要素であり、英語では knowledge‐based factor、日本語では「記憶」に該当します。よって
   a＝ウ：記憶
2. 続いて
   “認証カードを利用する利用者認証では、認証カードのbを確認することになりますね。”
   ICカードは「持っていること」を示す認証要素なので
   b＝オ：所持
3. R主任の発言
   “認証カードの利用時にPINを入力させることで、2種類の方法を組み合わせたc認証にすることができる。”
   「持ち物＋知識」の組合せは multi‐factor、和訳で「複数要素認証」です。
   c＝ス：複数要素
4. 失効情報の説明
   “1点目は、認証が成立するためには、鍵がkしていないことが必要であることだ。”
   PKI では鍵が危殆化（きたいか）＝漏えい・推測・破壊などで安全でなくなる状態を指します。
   k＝エ：危たい化
5. 同じ説明内
   “失効情報は、CRLの配布により、又はlを使って提供されることが多い。”
   CRL の代替としてリアルタイム失効確認を行うのは OCSP（Online Certificate Status Protocol）が標準です。
   l＝イ：OCSP

誤りやすいポイント

• 「多要素」と「複数要素」の混同
  “二つの方法を組み合わせ”とあるため「複数要素認証」が正解。選択肢「キ：多機能」は無関係。
• 「危殆化」の読み違え
  まれに「危機化」「棄損化」と誤記憶し、不正解を選択してしまう。
• OCSP を TLS ハンドシェイクの拡張とだけ覚えていると、PKI 全体の失効管理との関連付けができず選べない。

FAQ

解答の論理構成

1. 問題文には、利用者認証を強化するために「認証カードの利用時にPINを入力させることで、2種類の方法を組み合わせたc認証にすることができる」とあります。
2. しかし直後にR主任は「ただし、①認証対象者が不適切な行為をすると、その効果は望めない」と述べています。ここでいう“効果”とは二要素認証が備える強固な本人確認能力です。
3. 二要素認証は「モノ（認証カード）」＋「知識（PIN）」の両方を同一人物が保持することを前提に安全性を確保します。
4. したがって認証対象者自身がカードとPINを第三者に渡してしまえば、攻撃者は二要素の両方を取得でき、二要素認証は単なる「共有認証情報」に成り下がります。
5. 以上より、R主任が示す「不適切な行為」とは「認証対象者が認証カードとPINを他人に貸与してしまう行為」であると導けます。

誤りやすいポイント

• 「PINを書いたメモをカードとは別に保管する」等を想像しがちですが、PIN情報自体が漏えいしていない限り二要素性は残ります。本設問は“貸し出し”が焦点です。
• 認証カードのみの貸与やPINのみの漏えいと誤解するケースがありますが、R主任は「二要素認証の効果が望めない」状態を指摘しているため、両要素の同時提供が問題になります。
• 「カード複製」等の技術的攻撃へ思考が向きがちですが、発言文脈は利用者側の運用リスク（社会的技術的要因）に限定されています。

FAQ

解答の論理構成

1. 検証者Bに該当するもの
   引用：
   「公開鍵暗号技術を用いてエンティティ認証を行うプロトコルを、図2に示す。これは片方向認証の場合で、検証者Bが要求者Aを認証している。Jシステムでは、検証者Bはdに相当し…」
   認証を“受け取って判定”する側は、実際には各種の「事業用システム」である。したがって
   d ＝ 「ウ：事業用システム」
2. 要求者Aに該当するもの
   同じ引用の続き：
   「…要求者Aはeに相当する。」
   要求する側は、IC カードを持つ“人”＝「認証対象者」です。したがって
   e ＝ 「カ：認証対象者」
3. f に入る要素
   図2の手順1より
   「要求者Aの鍵（Kp, Ks）及び f を用意する。」
   鍵ペアとセットで用意するのは、その公開鍵に対する証明書＝「利用者証明書」です。したがって
   f ＝ 「ク：利用者証明書」

誤りやすいポイント

• 検証者Bを「オ：認証局」と誤解する
  認証局は証明書を発行する主体であり、日常的なログイン認証を“検証”するわけではありません。
• 要求者Aを「キ：秘密鍵」と対応付けてしまう
  要求者Aは“人”であり、秘密鍵はその人が保持するデータの一部にすぎません。
• f に「ア：共通鍵」を選ぶミス
  公開鍵基盤(PKI)を前提とするプロトコルなので共通鍵は登場しません。

FAQ

解答の論理構成

1. 問題文は、暗号技術選定の際に「米国国立標準技術研究所（NIST）や②CRYPTRECの文書などを参考に、適切な暗号技術を利用するようにしなければならない」と指示しています。この②が示す“電子政府推奨暗号リスト”に含まれるか否かが判定基準となります。
2. 平成28年3月29日版の“電子政府推奨暗号リスト”には以下が掲載されています。
   ・共通鍵暗号：AES、Camellia
   ・公開鍵暗号：RSA（PKCS #1 v1.5／RSA-OAEP）、ECDSA
   ・ハッシュ関数：SHA-256、SHA-512 など
3. 一方、同リストには掲載されていない又は既に推奨対象外となった技術もあります。
   ・DES：56 bit 鍵は安全性不足のため除外
   ・MD4／MD5：衝突攻撃が現実的で推奨外
4. したがって、解答群からリスト掲載技術のみを抽出すると
   ア：AES
   イ：Camellia
   エ：ECDSA
   キ：RSA-OAEP
   ク：SHA-256
   ケ：SHA-512
    が該当します。

誤りやすいポイント

• 「DES は古いが今も使われているから掲載されているのでは？」と早合点する。実際は安全性不足で推奨外です。
• MD5/SHA-1 の混同。SHA 系列でも SHA-1 は条件付き利用、MD5 は完全に推奨外です。
• RSA を“方式”ではなく“パディング方式”で区別せずに判断し、RSA-OAEPの掲載を見落とす。
• 共通鍵暗号のうち、日本発の Camellia を忘れがち。

FAQ

解答の論理構成

1. 【問題文】図2の注記に
   “sign(x, y)：ディジタル署名生成関数。秘密鍵 x と署名対象データ y を受け取り、署名値を返す。”
   とあります。したがって g には秘密鍵である “Ks” が入ります。解答群で “Ks” は “イ” です。
2. 同じく図2で X の計算式が
   “X = sign( g、h )”
   と示され、署名対象データ h は後段の検証ステップで再利用されることが分かります。
3. 図2ステップ7には
   “verify( i、j、Ra ∥ Rb ∥ Sn )”
   が記載されています。verify 関数は “公開鍵 s、署名値 t 及び署名対象データ u” を取ります（同じく注記より）。
   ・署名値 u に当たるデータが “Ra ∥ Rb ∥ Sn” であるため h も同内容でなければ整合しません。
   ・したがって h = Ra||Rb||Sn。解答群でこれは “オ” です。
4. verify の第1引数は公開鍵なので i = Kp（解答群 “ア”）。
   第2引数は署名値そのもの、つまりステップ5で作成した “X” です。よって j = X（解答群 “セ”）。
5. 以上より
   g：イ　h：オ　i：ア　j：セ　が導かれます。

誤りやすいポイント

• “sign” の第1引数に公開鍵を入れてしまう誤答。定義に “秘密鍵 x” と明記されています。
• 署名対象を “Ra||Rb” と短縮してしまう誤答。ステップ7の検証式と完全一致させる必要があります。
• verify の引数順を取り違え、第1引数に署名値を置くミス。
• j に誤って “Ra” や “Rb” を選び、署名値 X を忘れるケース。

FAQ

解答の論理構成

1. 【問題文】図3‐Step2には「システム部は、…本人による申請であることの確認及び③他の必要な確認を行う。」とあります。ここで求められる“他の確認”は、Jシステムの基本要件を満たすうえで必須のチェックポイントです。
2. Jシステムの目的は、本人を一意に識別できる認証カードを用いて事業用システムを安全に利用させることです。重複貸与は同一人物を複数 ID として扱うことになり、ログ追跡や失効管理が破綻します。したがって「申請者に認証カードを貸与済みでないこと」を確認する必要があります。
   • 【問題文】図3‐Step3「認証カードにはそれぞれ固有の識別番号を付与する。」
3. 認証カードは“業務上、事業用システムを利用する必要がある”人だけが対象です。無関係な従業員に発行すればカード紛失 ・ 不正貸与のリスクが増大し、失効作業の負荷も膨らみます。よって「申請者が事業用システムの利用を業務上必要としていること」を確認しなければなりません。
   • 【問題文】「D社の子会社が実施するプロジェクトに参加するD社グループ及び取引先のプロジェクトメンバには、必要に応じて事業用システムのアカウントが付与される。」──利用が業務前提であることを示す記述。
4. 以上より、システム部が行う“他の確認”は
   ・申請者に既発行のカードが無いか
   ・申請者が業務上カードを必要とするか
   という二点になります。これが模範解答①②に対応します。

誤りやすいポイント

• 「本人確認だけで十分」と考え、重複貸与チェックを忘れる。
• 業務利用要否を人事部門任せにし、IT 側で裏付けを取らずに承認してしまう。
• 認証カード≒入退室カードと早合点し、物理入退室の要否で判断してしまう。
• 申請時点では未貸与でも、過去に失効したカードの有無を確認せず再発行してしまう。

FAQ

解答の論理構成

1. 利用者証明書のsubjectフィールドには、事業用システムがその人物を一意に識別できる情報を入れる必要があります。
2. 問題文では「D社グループの従業員…には、D社グループ内で一意となる番号（以下、グループ従業員番号という）が付与されている。」と明記されています。
   ‐ “一意となる”という性質は、証明書識別子として最も重要な要件です。
3. 氏名・所属会社・部署・役職などは
   ① 同姓同名の重複可能性がある
   ② 異動・昇格・転籍などで変化しやすい
   ③ 変更のたびに証明書を再発行するのは運用負荷を高める
   ため「必要不可欠」とは言えません。
4. 従って、変動せず重複もない「グループ従業員番号」だけを入れておけば、長期にわたり同一人物を確実に識別できます。
5. 以上より、解答は
   　ア：グループ従業員番号
   のみとなります。

誤りやすいポイント

• 氏名や所属を入れないと「誰だか分からない」と考えてしまう
  → システム的には一意識別子さえあれば十分。可読性より一貫性を優先します。
• 電話番号や役職も入れた方が便利と思いがち
  → 連絡先・役職は変動が激しいため証明書記載には不向きです。
• 「複数会社を跨ぐので所属会社名も必須」と誤解する
  → 番号がグループ全体で一意と決まっているため不要です。

FAQ

解答の論理構成

• 失効情報は「事業用システムの不正利用を防ぐため、失効申請後すぐに公開されていなければならない」という運用上の要請があります。
• ところが N さんが作成した手順では、申請を受け付けてから失効情報を公開するまでを週次バッチで処理しており、最短でも2日間の空白期間が生じます。
• この遅延中は、すでに失効すべき認証カードが依然として有効とみなされるため、不正利用のリスクが残ります。
• 特にリスクが高いのは、 ・「退職又は事業用システムの利用終了」に相当する [affiliationChanged]
  ・「認証カードの紛失」や「鍵の不正利用のおそれ」に相当する [keyCompromise]
  です。失効情報の公開が遅れることで、退職者や第三者がカードを保持している間に不正ログインが可能になるからです。
• したがって、改善すべき不備は「失効申請から失効情報公開までの時間が長過ぎる」ことであり、該当する失効事由の値はア、ウとなります。

誤りやすいポイント

• 失効事由を“危険度”でなく“文字列の似ている／いない”で選び誤答する。
• 失効情報の遅延を「最大○日」と考え、最短でも2日空く点を見落とす。
• [cessationOfOperation] と [superseded] も不正利用につながると早合点し、選択肢を増やしてしまう。

FAQ

解答の論理構成

1. 【問題文】では、サーバ証明書を発行する認証局として「CA-3」が設定され、その上位に「D社ルートCA」が位置付けられています。
   引用：「図6　D社の認証局の階層案」
2. Webブラウザが TLS 通信時にサーバ証明書を検証する手順は、 (1) サーバが提示した証明書チェーンを受け取る
   (2) チェーンのルート証明書がブラウザの信頼ストアに存在するか確認
   (3) 存在しなければ“未検証”と判断し、警告を表示
   という流れです。
3. ⑤の措置は「グループ従業員が利用するPCにD社ルートCAの公開鍵証明書を登録する」ことです。これは上記 (2) の“信頼ストアに存在する”状態を作る作業に相当します。
4. したがって⑤を行わない場合、グループ従業員の PC には「D社ルートCA」の証明書が登録されていません。ブラウザは CA-3 のサーバ証明書チェーンを完結できず、ルートを信頼できないため“証明書エラー”を警告します。
5. 以上から、不都合は「サーバ証明書の正当性を確認できず警告が表示される」ことになります。

誤りやすいポイント

• 「通信ができなくなる」と断言しがちですが、多くのブラウザは接続自体を遮断せず“警告画面”を出します。
• 「CA-3 の証明書を登録」と混同するミス。実際に必要なのは上位の「D社ルートCA」の登録です。
• ⑤が「PC 側の設定」である点を忘れ、「サーバ側の証明書再発行」などと誤判断するケース。

FAQ

解答の論理構成

1. 問題文は、取引先に対し
   「“D社の認証局が万が一何らかの原因で不正操作される可能性を想定し、⑥取引先においては、D社ルートCAの公開鍵証明書を、当該サーバだけにアクセスする専用のPCにインストールするよう要請する”」
   と記述しています。
2. つまり、取引先の汎用 PC には D 社ルート CA を登録させず、限定用途の PC にのみ登録させる運用を求めています。
3. その理由は、ルート CA を信頼ストアに登録すると、同 CA が発行したあらゆるサーバ証明書を自動的に信頼してしまう点にあります。
4. 問題文でも「“D社の認証局が万が一…不正操作される可能性”」を想定しており、不正操作により攻撃者が不正なサーバ証明書を発行するリスクを示唆しています。
5. 取引先が汎用 PC でこれらを信頼すると、攻撃者が用意した偽装サーバへ誘導されても警告なしに接続してしまう恐れがあります。
6. そこで専用 PC への限定登録とすることで、業務対象サーバ以外には D 社ルート CA を信頼させず、被害範囲を必要最小限に抑えます。
7. 以上より、⑥は「不正なサーバ証明書を誤って信頼し、偽サーバへ接続するリスク」を軽減するためと結論づけられます。

誤りやすいポイント

• 「ルート CA の秘密鍵漏えいリスク」と答え、利用者側の“誤信頼”という観点を落とす。
• “専用 PC”を「物理的盗難対策」と誤解し、証明書の信頼範囲制御の意図を見逃す。
• 「MITM 攻撃防止」とだけ書き、取引先がブラウザ警告を無視せずに済むという具体性を欠く。

FAQ

解答の論理構成

1. 方式Ａの仕様には
   “事業用システムの利用権限は、プロジェクト責任者の要請に従い、事業部門で登録及び解除。事業部門は、プロジェクトへの参加期間だけ有効な権限をシステムに登録”
   とあります。方式Ｂでも同趣旨で、プロジェクト期間が終われば権限（利用許可）が外れます。
2. したがって、認証カードが手元に残っていても、プロジェクト期間終了後はシステム側で「登録解除」されているため“利用権限”がありません。
3. つまり、利用者が認証カード＋ＰＩＮで本人確認（認証）に成功しても、システムは権限チェック（認可）段階で拒否します。
4. 以上より、管理責任者がカードを回収し損ねても「認証を成功させても、事業用システムの利用の認可が得られないから」という理由で不正利用の影響を抑えられると導けます。

誤りやすいポイント

• 認証カード未回収＝すぐに不正利用と決め付け、システム側の権限制御を見落とす。
• 「失効」処理と「権限解除」を混同し、権限が残っていると誤解する。
• 認証と認可を同義に扱い、2段階で制御している事実を忘れる。

FAQ

解答の論理構成

1. まず非機能要件を確認します。問題文に
   ― 「優先される非機能要件は、第1に事業部門での管理工数が少ないこと、第2にシステム部での管理工数が少ない」
   とあります。
2. 表3の「管理責任者」を比較すると
   ・方式A：「プロジェクト責任者」
   ・方式B：「システム部（ただし、プロジェクト責任者は、プロジェクトへの参加期間を届け出る。）」
   したがって方式Bでは事業部門（＝プロジェクト責任者）がカードの発行・回収管理を行わず、工数が削減されます。
3. 次に「貸与枚数」「貸与期間」を比較します。
   ・方式Aの「貸与枚数」は「貸与対象者に対してプロジェクトごとに1枚」、 「貸与期間」は「プロジェクトへの参加期間」。
   ・方式Bの「貸与枚数」は「貸与対象者ごとに1枚」、 「貸与期間」は「いずれかのプロジェクトへの参加期間（ただし、半年以内に次のプロジェクトへの参加が見込まれる場合は貸与を継続）」。
   方式Bは複数プロジェクトを横断して同じカードを使えるので、配布・回収の回数が大幅に減り、両部門の工数が小さくなります。

誤りやすいポイント

• 「システム部の工数削減」を理由にする際、方式Bでも一部システム部が管理責任者になる点を見落としやすいです。
• 方式Aが「業務上の役割と認証カードを結び付け」られる点をメリットと勘違いし、非機能要件（工数）との優先順位を取り違えるケースがあります。
• 「操作履歴の取得」行だけを見て方式Aが優れていると誤判断することがありますが、本設問は非機能要件が評価軸です。

FAQ

解答の論理構成

1. 不正の内容を確認
   本文では試験フェーズ2で次の二つの不正が発生しています。
   ・「グループ従業員が認証カードをオフィスに置き忘れ、現場事務所で同僚に認証カードを借りて利用するケースが複数あった。」
   ・「グループ従業員が現場事務所に認証カードを保管し、本人以外に利用させているケースがあった。」
2. 不正を抑止する施策を確認
   両ケースに対し、「当初から計画されていた、⑦『認証カードを入退室カードとしても利用するという措置』が一定の効果をもつ」と記されています。
3. 入退室カードとしての利用がもつ意味
   入退室時にカードが必須になれば、 ・カードをオフィスへ置き忘れると入室できず業務が開始できない。
   ・カードを現場事務所へ放置すると退室ができなくなる。
   結果として「置き忘れ」「現場事務所内での保管」が利用者自身に直接不利益を及ぼすため、カードは常に持ち歩く行動が定着します。
4. 借用・貸与への牽制
   カードを他人に貸すと、自分が入退室できなくなるため、不正な貸し借りも抑止されます。
5. よって、本設問の模範解答
   「入退室に必要なため、認証カードの置き忘れ及び現場事務所内での保管がなくなる。」
   が導かれます。
   これは「入退室という物理的行為に必須化することで、携行を強制し貸与・放置を防ぐ」という論理に基づきます。

誤りやすいポイント

• 「入退室カードとしても利用」による効果を、システム上の多要素認証強化と混同する。
• 不正の内容が「カードの置き忘れ・保管」であることを見落とし、PIN漏えいなど別のリスクと結び付けてしまう。
• 効果を説明する際に「カードを常時携帯する必要がある」ことを明示せず、説得力を欠く表現になる。

FAQ