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

解答の論理構成

1. 方針1の確認
   【問題文】図3には
   ――「方針 1. PAN の業務上不要な利用や保存はしない。業務上の利便性だけの理由による利用や保存も禁止する。」――
   と明記されています。
2. 会員サポート課の実態
   【問題文】会員サポート課の記述では
   ――「VIP 会員担当は…VIP 会員の PAN、会員名、過去の問合せ履歴などを PC 内の VIP ファイルというファイルに記録している。」――
   とあります。
3. 業務上“不要”かどうか
   同じ段落で
   ――「会員管理システムでも同様の記録や管理は可能であるが…」――
   とあることから、正式システムで参照できる情報を個人作業用ファイルへ重複保存しているだけで、業務継続に不可欠ではありません。
4. 結論
   したがって「VIPファイル」に PAN を保存する行為は “業務上不要” かつ “利便性だけの理由” に該当し、方針1に反します。

誤りやすいポイント

• 電話受付時に本人確認のため「PAN」を聞く行為自体を違反と考えてしまう。これは業務上必要なので問題ありません。
• 「会員管理システムにPANが保存されているから全て違反」と早合点する。正式システム内での保存は必要業務で許容されています。
• 「VIPファイルには暗号化されていないから違反」と把握するだけで方針1との関係を記述しない。問われているのは保存の要否です。

FAQ

解答の論理構成

1. 方針の確認
   図3に示されているとおり、L社は
   • 「“必要最小限の利用者だけに、必要最小限のアクセス権限を設定する”」
   という取扱方針を掲げています。
2. 特別作業‐1 の業務内容
   表2より、特別作業‐1 は
   「“オーソリテーブルから、指示されたPANをキーに、該当する行の全てのカラムを表示する”」
   とあります。暗証番号変更前に PAN を閲覧して一致確認 する必要があるので、復号権限が不可欠です。
3. 特別作業‐2 の業務内容
   同じく表2で、特別作業‐2 は
   「“決済集計テーブルから…ステータスコードと最終処理日時を運用課に報告する”」
   だけで済みます。PAN の閲覧は業務上不要です。
4. 方式3 の特性
   表3より、方式3（列の暗号化）は
   「“DBの利用者IDごとに、復号可能な列を権限として設定できる”」
   ことが可能です。したがって、方針2の最小権限を具体化できます。
5. 権限付与の結論
   • 特別作業‐1 のDB利用者ID … PAN列を復号「与える」
   • 特別作業‐2 のDB利用者ID … PAN列を復号「与えない」
   以上より、解答群「イ」が方針に適合します。

誤りやすいポイント

• 「特別作業‐2 でも行全体を表示するので復号が要る」と誤解する。実際には業務報告項目にPANは含まれません。
• 方式3の説明を読み落とし、「列暗号化では索引が使えない＝検索できない」と混同する。索引を貼る列以外なら問題ありません。
• 「両作業を別チームが担当＝同じ権限でも良い」と早合点して最小権限を無視する。PCI DSS は職務分掌だけでなく列レベルの制限まで要求します。

FAQ

解答の論理構成

1. 方針の確認
   • 【図3】には「方針1. PAN の業務上不要な利用や保存はしない…業務上 PAN の表示が必要な場合を除き、PAN の表示はしない」とあります。
   • つまり、業務で不要な場面では PAN を表示しない ことが求められます。
2. 保守課の業務内容から不要な PAN を抽出
   • 【表2】の保守課欄に「特別作業-2: ステータスコード確認作業 … 決済集計テーブルから…ステータスコードと最終処理日時を運用課に報告する」とあります。
   • この作業で必要なのは「ステータスコード」と「最終処理日時」だけで、PAN は参照目的に含まれていません。
3. 暗号化方式3の効果
   • 方式3 は「DB の表の指定した列を暗号化…DB の利用者 ID ごとに、復号可能な列を権限として設定できる」と説明されています。
   • したがって、特別作業‐2 用の利用者 ID に PAN 列の復号権限を与えなければ、PAN は暗号化文字列のまま表示 されます。
4. Y 部長の指摘
   • 会話中の下線③で「当社の PAN の取扱方針により一層従った状態で、作業できるようになる」と述べられています。
   • これは、方式3 により PAN を表示せずにステータスコード確認作業を実施 できることを意味します。
5. 以上より
   • 「どの作業か」→ ステータスコード確認作業（特別作業-2）
   • 「どのような状態か」→ PAN を表示しない状態

誤りやすいポイント

• 暗証番号変更を行う「特別作業-1」と混同しやすい
• 「PAN を保存しない状態」と誤記しやすいが、設問は「表示」について問うている
• 方式3 の“列ごとの復号権限”を読み飛ばし、方式2 でも同じと誤解する

FAQ

解答の論理構成

1. 方式の仕様確認
   問題文の表3より、 “方式1…ハードディスク全体を暗号化する。OSの利用者IDのログインに成功すると、ハードディスクの全てのデータがアクセス時に自動的に復号されるようになる。”
   すなわち復号の開始条件は OS へのログイン成功であり、利用者 ID と復号キーが結び付いていることが分かります。
2. PCI DSS 要件との突合
   図4の“3.4.1”には、ディスク暗号化を使う場合は
   “論理アクセスはネイティブなオペレーティングシステムの認証…とは別に管理する必要”、“復号キーがユーザアカウントと関連付けられていない”
   と明言されています。
3. 不適合点の特定
   • 方式1 は OS へのログイン＝復号開始という動作をとるため、復号キーの使用可否が OS の利用者 ID によって決まります。
   • これは「復号キーがユーザアカウントと関連付けられていない」という要件に背反します。
4. 結論
   よって、要件3.4.1を満たさない方式は「方式1」と判断でき、設問が求める項目番号・該当動作・不適合内容も上記の通りとなります。

誤りやすいポイント

• 「3.4」と「3.4.1」を混同し、ディスク暗号化かファイル／列暗号化かを読み違える。
• “自動的に復号”の文言を見逃し、OS ログイン後のキー管理方法まで考慮しない。
• 方式2・方式3は DB の利用者 ID で復号可否を細かく制御できる点を見落とし、誤って不適合と判断する。

FAQ

解答の論理構成

• 【問題文】の方式3の説明には「DBの機能を利用した列の暗号化」として、 「索引を設定した列は暗号化できない。」と明記されています。
• 図2の会員管理テーブルは「会員管理（PAN、会員名、住所、…）」であり、注記1に「下線は主キーであることを表し、主キーには索引が設定される。」と記載されています。
• したがって会員管理テーブルの対象列「PAN」は主キーゆえ索引付きです。
• 索引付き列は方式3では暗号化できないため、「会員管理テーブルに方式3を採用することはできない」という結論になります。

誤りやすいポイント

• 方式3＝列暗号化は“全列暗号可”と早合点し、索引制限の記述を見落とす。
• 「主キーでも復号権限を付ければ暗号化可能」と誤解し、索引制限と主キー性の関係を混同する。
• 暗号化方式の選択を性能だけで判断し、機能制限（索引不可）を後回しに考える。

FAQ

解答の論理構成

1. 方式の特徴確認
   ・方式3は「DBの表の指定した列を暗号化する」「索引を設定した列は暗号化できない」
   ・方式2は「DBの表領域を暗号化する」だけで列単位の制御は不可
2. Y部長の指示の読み取り
   • Y部長は「②方式 3 を採用し、DB の利用者 ID ごとに権限を与えることで、③当社の PAN の取扱方針により一層従った状態で、作業できる」と述べ、可能なテーブルは方式3を選ぶ方針を示している。
   • ただし「④会員管理テーブルに方式 3 を採用することはできない」と明言。
3. 索引（主キー）の有無を確認
   図2に「下線は主キーであることを表し、主キーには索引が設定される」とある。
   • 決済集計テーブル：主キーは「決済処理番号」→ PAN に索引なし
   • ポイントテーブル：主キーは「PAN」→ PAN に索引あり
   • オーソリテーブル：主キーは「発行管理番号」→ PAN に索引なし
   • 会員管理テーブル：主キーは「PAN」→ PAN に索引あり
4. テーブルごとの最適方式決定
   (1) 決済集計テーブル
   ・PANに索引なし → 方式3使用可
   ・特別作業-2 で PAN を参照しない担当者にも列単位で復号権限を制御できる → 方式3
   (2) ポイントテーブル
   ・PANに索引あり → 方式3は不可
   ・列単位制御は不要（業務システムのみが参照） → 方式2
   (3) オーソリテーブル
   ・PANに索引なし → 方式3使用可
   ・特別作業-1 の担当者だけが復号権限を持てば方針1・2に合致 → 方式3
   (4) 会員管理テーブル
   ・Y部長が「方式3を採用できない」と指摘
   ・PAN に索引あり → 方式3不可 → 方式2

誤りやすいポイント

• 「索引を設定した列は暗号化できない」という制約を見落とし、ポイント／会員管理テーブルにも方式3を選んでしまう。
• Y部長の発言「方式3を採用し…」のみを読んで、全テーブル方式3と短絡的に判断する。
• 方式1（ディスク暗号化）がPCI DSS要件3.4.1で追加要件を求められる点を考慮せず選定してしまう。
• 特別作業-1/-2の担当者権限と列暗号化の関係を結び付けず、方式選択の根拠を作れない。

FAQ

解答の論理構成

1. 【問題文】には「L社のセキュリティポリシによって、…全システムで、無線LANの利用が禁止されている。」とあります。
2. さらに下線⑤では「セキュリティ上の問題につながる事象が幾つか想定される」と述べています。
3. 無線LANの使用自体が禁止されているため、もし社内にワイヤレスアクセスポイント（W-AP）が設置されると、その時点でポリシ違反となり、外部からの不正接続・盗聴・情報漏えいのリスクが発生します。
4. よって「セキュリティポリシに反してワイヤレスアクセスポイントが設置されること」が最も典型的かつ重大な事象であり、解答となります。

誤りやすいポイント

• 「電波傍受」や「通信の盗聴」だけを書くと設問が求める“事象”ではなく“結果”になり減点となりやすいです。
• 「不正端末接続」など具体的端末名を挙げた場合、アクセスポイント自体の設置を指していなければ趣旨がずれます。
• “ポリシ違反”を明示せずに「W-APが存在すること」とだけ書くと、なぜ問題なのかが不明瞭になるため注意が必要です。

FAQ

解答の論理構成

1. 無線 LAN スキャンで使用した規格を確認
   【問題文】図5の「無線LAN規格：IEEE802.11 b/g」とあり、検査対象は 2.4 GHz 帯だけです。
2. Y部長の指摘
   【問題文】「無線 LAN の規格を考えると、例えばeの検査ができていない。」
   2.4 GHz 以外で代表的な無線 LAN 規格は 5 GHz 帯を用いる「IEEE802.11a」です。
3. 要件 11.1 の趣旨
   【問題文】要件11.1は「四半期ごとにワイヤレスアクセスポイントの存在をテストし…すべての承認されているワイヤレスアクセスポイントと承認されていないワイヤレスアクセスポイントを検出し識別する」と規定しています。
   よってすべての周波数帯（2.4 GHz・5 GHz）をカバーする必要があり、5 GHz 帯（IEEE802.11a）未検査が問題となります。
4. 結論
   以上より e に入る適切な字句は「5GHz帯 又は IEEE802.11a」です。

誤りやすいポイント

• 802.11n/ac などの派生規格を思い浮かべてしまい、核心である「周波数帯」を答え忘れる。
• b/g のみ対応アダプタで「規格は全て網羅した」と誤解する。
• 2.4 GHz と 5 GHz の役割を逆に記憶してしまい、「2.4GHz帯」と回答して失点する。

FAQ

解答の論理構成

1. 【問題文】の会員サポート課の現行手順
   「会員を特定するために受付時に PAN、会員名、住所 を聞き、会員管理システムで PANをキー として検索」
   ─ 電話受付で必ず PAN を扱う運用となっています。
2. 【図3】方針1
   「PAN の業務上不要な利用や保存はしない。」
   ─ 現行手順はこの方針に反します。
3. 新システム提案で導入される仕組み
   ・【図6】お客様コード：「10桁の英数字で構成する」「クレジットカードごとに一意に採番する」
   ・【図7】会員管理テーブル：主キーを お客様コード に変更
   ─ PAN なしで会員検索が可能になります。
4. ⑥の発言
   「改修によって、会員サポート課の業務の一部の手順を、準拠計画書に含まれる方針に従って改善」
   ─ 具体的には、電話受付時に PAN を聞かずにお客様コードで本人特定 する手順変更が方針1に合致し、PAN 取扱を削減できます。
5. 以上より、模範解答のとおり「電話受付時の会員の特定をPANではなくお客様コードで行う」ことが最適な改善策となります。

誤りやすいポイント

• 「PAN を masked 表示にする」と答えると、依然 PAN を扱うため方針1違反になります。
• 「会員名や住所だけで特定」とすると同姓同名の誤判定など実務上の識別精度が不足します。
• 新コード導入＝自動的に PAN 不要と短絡し、システム改修後も旧手順が残る可能性を見落としがちです。

FAQ

解答の論理構成

1. 旧システムのテーブル構造を確認
   図2では、 ・ポイントDB：ポイント（PAN、ポイント値、最終更新日時）
   ・会員管理DB：会員管理（PAN、会員名、住所、電話番号、性別）
   とあり、どちらも主キーが「PAN」でした。
2. PANを極力保持しない方針への転換
   図3の「方針1. PAN の業務上不要な利用や保存はしない。」を実現するため、 Y部長は「PAN とお客様コードを相互に関係付けるテーブルをもつ変換 DB を作成」すると述べています。
   これにより各業務テーブルは PAN を持つ必要がなくなります。
3. 図8の読み取り
   図8には
   ・変換DB：変換（PAN、お客様コード）
   とだけ固定列が示され、ポイントDB と 会員管理DB は f と g が空欄です。
   つまり「PAN を除外し、お客様コードを主キーに据えた新たな列構成」を考える問題です。
4. ポイントDB（f）の決定
   旧ポイントテーブルの「PAN」を「お客様コード」に置換え、その他の列はそのまま残します。
   よって f は
   お客様コード、ポイント値、最終更新日時
5. 会員管理DB（g）の決定
   旧会員管理テーブルから PAN を除外し、主キーを「お客様コード」に変更します。
   よって g は
   お客様コード、会員名、住所、電話番号、性別
6. 主キー表記
   問題指示「なお、主キーには下線を引くこと。」に従い、上記いずれも「お客様コード」に下線を付けます。

誤りやすいポイント

• 「図7では PAN が残っているから会員管理テーブルにも PAN を残す」と早合点する。図8導入後は変換DBで紐付けるため PAN は不要です。
• ポイントテーブルの列として「お客様コード」と「PAN」を両方書いてしまう。方針1が禁止している「業務上不要な PAN 保存」に該当します。
• 主キーに下線を付け忘れる、または複数列に下線を付ける書式ミス。

FAQ