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

解答の論理構成

1. 状態値の候補は【問題文】に示された
   “仮パスワード”、“有効”、“無効”、“一時利用停止” の4種類のみである。
   引用：

   “UIDの状態”の値（以下、状態値という）としては、“仮パスワード”、“有効”、“無効”、“一時利用停止”を定義した。

2. 休職者の扱い
   引用：

   休職者については、セキュリティの観点からすべてのサブシステムについて、アカウント管理者が利用者ID … を利用停止に変更することになっている。
   休職＝利用停止 ⇒ ログイン不許可が望ましい。ログイン不許可を示す状態値は “無効” である。

3. 復職者の扱い
   復職後は通常業務に戻るためログイン許可が必要。ログイン許可を示す状態値は “有効” である。
4. 以上より
   a：休職時 → “無効”
   b：復職時 → “有効”

誤りやすいポイント

• “休職＝一時利用停止” と考えてしまう
  “一時利用停止” は【問題文】(5) の「UIDのパスワードを連続して5回間違えた場合」に適用される別ルール。
• “復職＝仮パスワード” と誤解する
  “仮パスワード” は新規発行や初期化時にのみ設定される。
• “無効＝削除済み” と混同する
  “削除” はUID自体が存在しない状態、“無効” はUIDは残るがログインできない状態。

FAQ

解答の論理構成

1. 【問題文】では“仮パスワードの発行を受けた従業員は、72時間以内にパスワードを設定しなければならない。パスワードを設定するまでは、各サブシステムを利用することはできない。”と記述されています。
   • 「利用することはできない」＝ログイン不可であるため、状態遷移図の“各サブシステムに対するログインの認可”欄には「不許可」と入るのが自然です。
   ⇒ c ＝ “不許可”
2. 同じ引用文に続き、利用者がやるべきことは「パスワードを設定」することだと明示されています。
   • 状態遷移図では“利用者への表示メッセージ”欄が設けられており、仮パスワード状態の利用者には次の行動を促す案内が必要です。
   • したがって “パスワードを設定してください。” という内容が最適です。
   ⇒ d ＝ “パスワードを設定してください。”

誤りやすいポイント

• “仮パスワード”という語から「一時的にでもログインできる」と早合点し、c に “許可” を入れてしまう。
• メッセージ d に「変更してください」や「初期化してください」など不要な語句を混ぜてしまう。
• 規程 (ウ) を見落とし、72時間ルールとログイン不可を結び付けられない。

FAQ

解答の論理構成

1. 図中のeは、「状態：有効」から「状態：一時利用停止」に遷移する矢印上に置かれた補足情報です。
2. 該当矢印の遷移条件は【問題文】の「(5) UIDのパスワードを連続して5回間違えた場合、状態値を“一時利用停止”にする。」に該当します。
3. さらに、一時利用停止の解除条件は【問題文】の「(エ) “一時利用停止”の状態は、24時間後に自動的に解除される。」と定義されています。
4. 遷移図では、解除条件（24時間経過）を視覚的に示すために矢印上の小矩形に記載する方式が採られており、これがeの役割です。
5. したがって、eに入る字句は「24時間を超えた」となります。

誤りやすいポイント

• 「72時間を超えた」は仮パスワード保持や一時利用停止状態からの削除条件であり、解除条件ではないため混同しやすいです。
• 「100日を超えた」は無効化の条件です。回数制限解除とは無関係です。
• “一時利用停止”の解除は「アカウント管理者による初期化」も存在しますが、これは別矢印で明示されておりeとは関係ありません。

FAQ

解答の論理構成

• 第 2 案の説明には、次の記述があります。
  「“第 2 案は、UID の発行申請時に設定する①属性を追加して、UID 管理システムが毎日その値を点検して自動的に UID を削除する運用”」
  → ここで追加する属性は「いつ削除するか」を示す日付であると読み取れます。
• そもそも派遣社員 UID の削除タイミングは “契約満了” に合わせるのが目的です。本文には、 「“契約開始日は月初日、満了日は月末日に限定すること”」
  とあり、契約満了日が明確に管理されています。
• UID 管理システムが毎日点検するためには、具体的な日付を属性として保持し、当日になれば削除フラグを立てるのが最もシンプルです。
• 以上より、①属性は「契約満了日を示す項目」、すなわち
  「契約満了予定日」
  とするのが妥当です。模範解答の「UID削除予定日」「アカウント終了予定日」も、同じ意味で日付を保持する点が共通しています。

誤りやすいポイント

• 「派遣社員は、人事管理システムで管理されていない」という前提を見落とし、人事イベント用の属性（所属部門名など）を流用すれば済むと早合点してしまう。
• 「許容無使用期間は 100 日とする。」との記述に引きずられ、「最終利用日」だけで判定できると誤解し、日付属性の追加不要と判断してしまう。
• 「毎月初日に一括削除する運用」を第 2 案にも適用できると考え、削除予定日ではなく「無効化日」など別のフラグを提案してしまう。

FAQ

解答の論理構成

1. 派遣社員の契約満了後、UID がただちに削除されるわけではありません。第1案では「“無効”状態にある UID を、情報システム部が毎月初日に一括削除する運用」と定められています。
   引用：【問題文】「第 1 案は、“無効”状態にある UID を、情報システム部が毎月初日に一括削除する運用である。」
2. UID が “無効” になるのは、利用されない期間が「許容無使用期間」である「100 日」を超えたときです。
   引用：【問題文】「UID は、利用されない期間が、ある日数（以下、許容無使用期間という）を超えた場合に状態値を “無効” にする。許容無使用期間は 100 日とする。」
3. 契約満了日から UID 削除までの最大遅延を考えます。
   ① 契約満了翌日から数えて「100 日」経過すると “無効” になります。
   ② その後、次の「毎月初日」に一括削除されます。
   ③ “無効” になった日が月末付近であれば、次の「毎月初日」までほぼ「1 か月」待つことになります。
4. よって、契約満了日から数えて
   ・“無効” になるまで：およそ 3 か月強（100 日 ≒ 3.3 か月）
   ・“無効” になってから削除されるまで：最大 1 か月
   合計で約 4 か月となります。
5. 以上より、下線②「一定の時間」は「4 か月」です。

誤りやすいポイント

• 「100 日」をそのまま 3 か月と短絡的に捉え、月初の一括削除運用を考慮しない。
• “無効” から削除までの期間を平均値で考え、最長ケースを見落とす。
• 「毎月初日」を“毎月末”と勘違いし、計算がずれる。

FAQ

解答の論理構成

1. 契約解除を最も早く把握できるのは契約内容を統括する部署
   • 問題文では「契約開始時には、契約管理部の承認を得ている。」とあり、契約の変更・解除情報も同部が把握するのが自然です。
2. 満了前解除は自動削除ロジック（契約満了日＝属性値）だけでは検知できない
   • 「満了前解除ケースに対しても確実に UID が削除できるような運用を追加」と記載されています。契約管理部による人手でのトリガが必要です。
3. したがって契約管理部が解除を確認した時点で削除依頼を発行する運用を定める
   • 具体策として「契約管理部が、契約解除を確認し、UID削除依頼を行う。」が最短・確実であり、下線④への回答となります。

誤りやすいポイント

• 「各事業部」が解除を伝えると考えてしまう
  → 本文は「契約満了者の UID を確実に削除できる運用」を契約管理部視点で検討しており、事業部任せでは漏れが生じます。
• 自動削除機構だけで満了前解除も処理できると思い込む
  → 属性値には満了日しか入らないため、途中解除は検出不能です。
• 「情報システム部」が直接契約解除を監視すると勘違い
  → 契約情報は情報システム部にはありません。解除を知る部門が依頼する流れが合理的です。

FAQ

解答の論理構成

1. まず規程(5)には
   “UIDのパスワードを連続して5回間違えた場合、状態値を“一時利用停止”にする。”
   とあります。ここでロックが掛かる対象は“他者のUID”であっても構いません。
2. 状態“一時利用停止”に対して(エ)は
   “緊急に利用しなければならない場合は、…アカウント管理者に…初期化依頼する”
   と規定しています。依頼者の真正性確認方法が明示されていないため、電話などで名乗るだけでも依頼が通る恐れがあります。
3. 以上より、攻撃者は
   “パスワードを5回連続して間違え”て対象UIDを“一時利用停止”とし、続けて“アカウント管理者に…初期化依頼”すれば、新しい仮パスワードを得ることができます。
4. この手口が本文の下線“③何者かがなりすまして他者の UID のパスワードを不正取得できるリスク”になるため、設問の答えは
   「他人のUIDのパスワードを5回連続して間違え一時利用停止状態とし、アカウント管理者にパスワード初期化を依頼する場合」
   となります。

誤りやすいポイント

• 「利用者本人でなければ５回連続ミスできない」と思い込み、第三者が入力可能な事実を見落とす。
• “24時間後に自動的に解除”に意識が向きすぎ、初期化依頼経路のリスクを忘れる。
• 一時利用停止の解除＝本人の再ログインと誤解し、アカウント管理者が仮パスワードを発行する点を読み落とす。

FAQ

解答の論理構成

1. リスクの特定
   • 情報システム部長は、現行運用に「“③何者かがなりすまして他者の UID のパスワードを不正取得できるリスク（以下、パスワード不正取得リスクという）”」があると指摘しています。
2. 対策方針
   • プロジェクトチームは、「“⑤具体的な手続を定めることで解決”」と決定しました。したがって、回答は“手続”＝具体的な運用フローを示す必要があります。
3. 手続設計の要件
   • なりすましを防ぐには「①依頼者が正しい利用者本人かどうかの確認」と「②仮パスワードの安全な伝達」が不可欠です。
4. 解答例との合致
   • 「パスワード初期化依頼の際には、上司からメールで依頼する。」
     • 上司という第三者承認を必須にして本人確認を強化。
   • 「仮パスワードの連絡は、あらかじめ登録された電話番号だけに限定する。」
     • 事前登録済みの連絡先へ通知することで盗聴・転送リスクを軽減。
   • 以上の二段階により、指摘された「パスワード不正取得リスク」を具体的手続で抑止できるため、模範解答が導かれます。

誤りやすいポイント

• 「多要素認証を導入する」など大がかりな技術対策のみを記述し、手続（運用）になっていない。
• 入力フォームに本人情報を再入力させるだけなど、第三者の承認や別経路通知がなく、なりすましを防げない。
• 「メールで送信」だけに言及し、メール盗聴・誤送信対策が欠けている。

FAQ