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

解答の論理構成

1. 問題文では、Rグループが情報資産を「情報セキュリティの3要素」に照らして分類したと記載しています。

   “HSSで取り扱う情報資産を特定し、情報セキュリティの3要素に照らして情報資産の分類を行った。”

2. 情報セキュリティの3要素は、一般に「機密性・完全性・可用性（Confidentiality, Integrity, Availability）」です。
3. 表3の見出しを確認すると、

   “aに係る分類／完全性に係る分類／可用性に係る分類”
   と並んでおり、「完全性」「可用性」は既に記載済みです。

4. 残る1要素は「機密性」であり、これが a に入るべき語句となります。

誤りやすいポイント

• CIAの順番に惑わされる
  「C → I → A」の順序を覚えていても、表3では「完全性」「可用性」が後ろに並んでいるため、先頭が「機密性」であることを見落としがちです。
• “安全性”や“秘匿性”といった類義語を解答に書いてしまう
  設問は「字句」を求めており、情報セキュリティの標準用語である「機密性」を使わないと誤答になります。
• リスクアセスメント＝可用性重視と短絡的に考える
  可用性を重視しても、3要素のうち欠けているものを補完する問題であると気付かなければなりません。

FAQ

解答の論理構成

1. 表4を見ると、リスク No.1 と 7 では脅威がそれぞれ
   「インターネット経由のHSSへの不正アクセス」
   「美容室従業員による不正アクセス」
   となっており、いずれも “不正アクセス” がテーマです。これらの脆弱性欄には同じ b が入ります。
2. 不正アクセスの典型的な脆弱性は、平易で当てやすいパスワードの使用です。解答群で該当するのは「イ：推測可能なパスワード」です。
3. リスク No.5 と 6 の脅威は「美容室従業員による物品持ち去り」で、被害は「情報へのアクセス不能」です。ここでは機器や記録媒体が持ち去られる物理的リスクを示しています。
4. 物理的持ち去りを招く脆弱性は施錠管理の甘さに起因します。選択肢で対応するのは「オ：美容室の施錠管理不良」です。
5. 以上より
   ・b ＝ 「イ：推測可能なパスワード」
   ・c ＝ 「オ：美容室の施錠管理不良」
   となります。

誤りやすいポイント

• 「エ：データセンタの施錠管理不良」を選ぶと、物理リスク対象が美容室ではなくデータセンタである点を見落としてしまいます。
• リスク No.1,7 を“ネットワーク機器の設定不備”と誤解し「ア：管理端末の保守体制の不備」を選ぶケースがありますが、表4の被害欄は「情報漏えい」であり、パスワード強度との関連が濃厚です。
• 「カ：防火体制の不備」「ウ：耐震性能の不足」は可用性の低下に直結するものの、持ち去りという行為とは結び付かないため不適切です。

FAQ

解答の論理構成

1. 表5の要求箇所を確認
   • 「顧客の認証」の仕様には、 「パスワードの入力を所定回数連続して誤った場合、d。」
     と明示されています。
2. リスクとのひも付け
   • 同じ行の「リスク No.」欄に “1, 4” とあり、表4より
     ・リスク1：『インターネット経由のHSSへの不正アクセス』
     ・リスク4：『脆弱な認証とアクセス権管理の仕組み』
     が対象であると分かります。
   • これらはいずれも総当たりや辞書攻撃など多数回のログイン試行を想定した脅威です。
3. 適切な対策を導く
   • パスワードポリシだけでは試行回数を抑止できないため、連続失敗時に追加の遅延やロックを行い、攻撃効率を下げる必要があります。
   • 「所定回数連続して誤った場合」に続く動作としては、 ・一定時間のアカウントロック
     ・次の認証処理で待ち時間を入れる
     が代表的です。
   • 本設問は「認証時に行う動作」を尋ねており、待ち時間の挿入が自然な記述となります。
4. 結論
   • よってdには
     「当該アカウントの認証時に待ち時間を挿入する」
     が入るのが妥当です。

誤りやすいポイント

• 「アカウントを即時無期限ロック」と答える
  → 正当利用者まで締め出し、DoS を招く恐れがあるため要件オーバー。
• 「パスワードをリセットさせる」と誤記
  → リセットは本人確認手続きが別途必要で、ここで求める“連続失敗への即時対応”とずれる。
• “CAPTCHA を表示”とする
  → CAPTCHA はブラウザ側 UI 変更を伴い、「認証時に待ち時間を挿入する」より実装負荷が高い。

FAQ

解答の論理構成

1. 表5の該当箇所
   • 「Web画面入出力」の仕様には
     「Web画面からの入力については、全て値チェックを行う。」
     「Web画面の出力時には、エスケープ処理を行う。」
     とあります。これは入力値検証や出力エスケープにより XSS・SQL インジェクションなど “Webアプリケーションの脆弱性” を防ぐための対策です。
2. 表4で “Webアプリケーションの脆弱性” が原因となっているリスク No. を探すと、次が該当します。
   • 「2　インターネット経由のHSSへの不正アクセス／Webアプリケーションのセキュリティホール」
3. 他のリスク No. と照合
   • No.1・4・7・8 は認証やアクセス権管理に関する脆弱性。
   • No.3 は「Webサーバ基盤のセキュリティホール」。
   • 従って、入力値チェックとエスケープ処理で直接対応するのは「Webアプリケーションのセキュリティホール」を示す「2」のみです。
4. 以上より、e には「2」を入れるのが妥当です。

誤りやすいポイント

• 「インターネット経由のHSSへの不正アクセス」という脅威名だけを見てリスク No.1 を選んでしまう。No.1 の脆弱性は b（認証・アクセス制御系）であり、入力値チェックとは対応がずれます。
• 「Webサーバ基盤のセキュリティホール」である No.3 を選択してしまう。表5が対処するのは“アプリケーション層”の脆弱性であり、基盤層とは別です。
• XSS＝情報漏えいと短絡し、深刻度の高い番号を機械的に選ぶミス。対策対象の“原因”を読むことが大切です。

FAQ

解答の論理構成

1. 対象箇所の把握
   表6の該当行は
   「インターネットからのアクセスを受け付ける回線」に対し、 ・「ファイアウォールを設置し、最小限のアクセスだけを許可する。」
   ・「IPSを設置し、不正アクセスの検出と、自動遮断を行う。」
   ・「Webアプリケーションファイアウォールを設置し、不正なHTTPアクセスを遮断する。」
   と記載されています。
2. 防御対象となる脅威の特定
   これら 3 つの対策はいずれも“インターネット越しに届く攻撃パケット”を遮断・検知する仕組みです。
   表4でインターネット経由の技術的攻撃に該当するリスクは次の 2 つです。
   • リスク No.「2」：脆弱性「Webアプリケーションのセキュリティホール」
   • リスク No.「3」：脆弱性「Webサーバ基盤のセキュリティホール」
3. リスク―対策の対応付け
   ・「Webアプリケーションファイアウォール」は不正な HTTP リクエストを遮断し、リスク No.「2」に直接対応します。
   ・「ファイアウォール」および「IPS」は OS や Web サーバに対する攻撃コードをブロックし、リスク No.「3」に直接対応します。
4. 他候補の除外理由
   リスク No.「1」は脆弱性が「b」となっており、後段の表5でパスワード強化やアカウントロックなど“認証強化”で対処しているため、本行のネットワーク機器ではなく表5側でカバーされています。したがって f には含めません。
5. 結論
   よって f に入るリスク No. は「2, 3」となります。

誤りやすいポイント

• 「ファイアウォール＝何でも防げる」と考え、リスク No.「1」も含めてしまう。実際は認証強化で対処するリスクのため別行で管理されている。
• 「IPS=侵入後検知」と誤解し、Webアプリケーションの脆弱性専用と判断してしまう。本問では OS／Web サーバ層の攻撃を想定している。
• 対策とリスクを“脅威”で合わせようとしてミスをする。リスク管理では“脆弱性”との対応関係でマッピングする方が確実。

FAQ

解答の論理構成

1. 【問題文】の「表 4　顧客データに対するリスク分析の結果（抜粋）」で、リスク No.3 の脅威は
   ――「Webサーバ基盤のセキュリティホール」――
   と明記されています。
2. 同じく【問題文】の「表6　HSSの運用管理に関する要件（抜粋）」には、 ――「インターネットからのアクセスを受け付けるWebサーバ」――
   の欄に要件として「・g」が空欄で示され、右端の列にはリスク No.3 が対応付けられています。
3. リスク No.3 の脅威「Webサーバ基盤のセキュリティホール」を低減する典型的な管理策は「セキュリティ修正プログラム（パッチ）の迅速な適用」です。
4. したがって、空欄gには、パッチマネジメントを示す具体策を記述すれば、リスク低減策とリスクの対応付けが一貫します。

誤りやすいポイント

• 「ウイルス対策ソフトを導入する」と勘違いする。リスク No.3 は Web サーバ基盤そのものの脆弱性であり、マルウェア対策とは主眼が異なります。
• 「定期的に OS を再起動する」「アクセスログを監視する」などを挙げるケース。どちらも重要ですが、脅威「Webサーバ基盤のセキュリティホール」の主因（未適用パッチ）を直接低減していません。
• ファイアウォールや IPS で外部攻撃を防ぐ施策を書いてしまう。これらは同じ表の上段（回線側）の要件で既に列挙されており、重複になります。

FAQ

解答の論理構成

• 【問題文】の「顧客αと顧客βが、画面2で空き状態であった同一の予約枠をほぼ同時に選択した場合、表7に示す順序で各処理が完了すると、顧客αの仮予約がデータベースに反映されない」とあるように、表7は“競合状態”の発生手順を示しています。
• まず顧客αが psSel.executeQuery() を実行して予約枠を読み取ります。これは【図5】の「42行目」に該当し、表7の順序1に指定済みです。
• 次に顧客βも同じ空き枠を読み取る必要があります。βが実行する処理も psSel.executeQuery() であり、行番号は同じく【図5】の「42行目」です。したがって
  h：42
• その後、αが先に psUp.executeUpdate()（仮予約更新）を行います。executeUpdate は【図5】の「60行目」に位置しています。対象顧客はαなので
  i：α j：60
• 最後にβも psUp.executeUpdate() を行い、βの仮予約情報で上書きされるためαの予約が失われます。βが実行する行番号も「60行目」です。よって
  k：β l：60

誤りやすいポイント

• 42行目と60行目の役割を混同し、SELECT と UPDATE を逆に割り当ててしまう。
• 「αとβのどちらが先にUPDATEするか」で結果が変わることに気づかず、順序3と順序4の顧客を逆に書いてしまう。
• 「同じSQLを実行＝行番号も同じ」と気づかず、βのSELECT行を別番号にしてしまう。

FAQ

解答の論理構成

1. まず、表8の「対象の顧客 β」が実行している処理は、画面2で予約枠をクリックしたときに呼び出されるサーブレット “WakuClick” であることが【問題文】
   「○を選択すると、サーブレット“WakuClick”が呼び出される。」
   から分かります。したがって図番号は「図5」と決定できます。
2. “WakuClick” 内で予約枠の現在状態を調べる最初の SQL は【図5】
   42行目 ResultSet rs = psSel.executeQuery();
   です。従って
   m：5、n：42
3. αが本予約を確定する処理は、画面3で “予約する” ボタンを押したときに呼び出されるサーブレット “KakuteiClick” で行われます（【問題文】「サーブレット“KakuteiClick”が呼び出される」）。
   本予約へ更新する SQL は【図6】
   55行目 psUp.executeUpdate();
   なので
   o：6、p：55
4. βが仮予約に書き換える UPDATE は “WakuClick” の 60 行目【図5】
   psUp.executeUpdate();
   で実行されるため
   q：5、r：60
5. 以上より、表8の空欄を埋めると
   m：5、n：42、o：6、p：55、q：5、r：60
   となります。

誤りやすいポイント

• “WakuClick” と “KakuteiClick” の役割を取り違え、図番号を入れ替えてしまう。
• UPDATE を実行している行を executeQuery と勘違いし、行番号を 42 ↔ 60 で誤答する。
• 並行処理の時系列を追わずに「SELECT→UPDATE→SELECT」の順序を理解せず、どの顧客がどの処理を行ったかを混同する。

FAQ

解答の論理構成

1. 更新対象行を特定する追加条件
   • 図9の25行目では、従来の WHERE rsvDate=? AND rsvTime=? AND Biyoshi=? AND CustID=? AND s という形で 4 つの主キー相当列に加えて s が必要です。
   • 42行目で読み込んだ直後の行状態を 52～58 行目で再度 UPDATE するため、読み込み時と同じ値が残っていることを確認する 楽観的ロックが目的です。
   • 楽観的ロックに使える列は、読み込み時点で値が分かっており、その後の並行トランザクションが変更する可能性がある列です。図5の48行目では rsvStatus、44行目では lastDateTime を取得しています。
2. 具体的な 2 つのロック方法
   ① 状態列ロック
   • s に Status=? を置き、54 行目以前に psUp.setInt(10, rsvStatus)（t）で 読み込み時の状態を埋め込む。
   • これにより、他の取引で Status が変更されていた場合 executeUpdate の戻り値は 0 行となり、59 行目の比較で失敗扱いになります。
   ② タイムスタンプロック
   • s に LastUpdate=? を置き、58 行目の直後で psUp.setLong(10, lastDateTime)（t）を設定します。
   • LastUpdate は図8「ある行のいずれかの列に更新があった場合、その時刻をLastUpdateに設定する。」とあるとおり確実に変わるため衝突検知が可能です。
3. 更新件数判定
   • executeUpdate の戻り値は「更新した行数」です（問題文記載）。
   • 衝突がなければ 1 行更新されるので u には 1 を置きます。
   • 0 行であれば他トランザクションと衝突しており、62～63 行目の予約失敗画面へ遷移します。
4. 結論
   上記 2 通りの実装いずれも要件を満たすため、模範解答は
   • パターンA:
     • s：Status=?
     • t：psUp.setInt(10, rsvStatus)
     • u：1
   • パターンB:
     • s：LastUpdate=?
     • t：psUp.setLong(10, lastDateTime)
     • u：1

誤りやすいポイント

• CustID だけでは他ユーザとの衝突を検知できても、同一ユーザの二重操作を防げないことに気付きにくい。
• executeUpdate の戻り値を boolean だと勘違いし、== true などで比較してしまう。
• タイムスタンプ列を使う場合、LastUpdate を SET 句で上書きしているため WHERE 句にも同値を入れなければ意味がないことを忘れやすい。

FAQ

解答の論理構成

1. 事象の要諦
   【問題文】では下線①として
   「空き状態であった予約枠を、顧客αが画面2で選択して画面3に進むのと並行して、同一の予約枠を顧客βが画面2で選択した場合…顧客βの個人情報が顧客αの画面4に表示されてしまう」
   とあり、同一予約枠に対する2つのリクエストが“ほぼ同時”に発行される状況を再現する必要があります。
2. 技術的背景
   ・顧客α側のサーブレット “WakuClick” では 60行目で psUp.executeUpdate() を実行し仮予約を記録します。
   ・顧客β側の同処理もほぼ同時刻で走るため、レースコンディションにより α・β の CustID が入れ替わる可能性があります。
   ・それを意図的に起こすには、2スレッドの処理タイミングを人為的に揃える必要があります。
3. 再現手順の要点
   デバッガで「SQL発行直前」に停止させ、2ブラウザから該当予約枠を操作した状態でスレッドを交互に再開すれば、【問題文】表8に示された「α 60行目 → α 42行目 → β …」という順序を擬似的に構築できます。
   よって模範解答の
   「デバッグで、SQL文の発行直前にブレークポイントを設定して、二つの予約処理を並行して実行する。」
   が妥当となります。

誤りやすいポイント

• 手動クリックを高速に繰り返すだけではタイミングが一定せず、表8の順序を再現しにくいです。
• ネットワーク遅延を人工的に挿入しても JDBC 実行直前のスレッド制御まではできません。
• ブレークポイントを psUp.executeUpdate() ではなく psSel.executeQuery() に置くと、後続ロジックがずれ再現に失敗します。

FAQ

解答の論理構成

1. 予約枠の同時選択で発生した不具合は、表7の「顧客αの仮予約がデータベースに反映されない」や表8の「顧客βの個人情報が顧客αの画面4に表示」など、読込後に別スレッドが同一行を変更したことが原因です。
2. これを受けＴ主任は、図9 25行目でUPDATE文の WHERE 句に「CustID=?」などの読込時点の値を追加し、さらに図9 59行目で「psUp.executeUpdate() の戻り値」をチェックして更新競合を検知する楽観ロック方式を導入しました。
3. 上記対策が成り立つための開発規約は「読込時点の元データが他スレッドで変更されていないことを、更新時に必ず検証し、差分があれば処理を中断する」と要約できます。
4. よって模範解答の「データベースから読み込んだデータを更新する際に、そのデータが他のスレッドによって変更されていないことを確認する。」が適切となります。

誤りやすいポイント

• 「トランザクションを使えば十分」と考え、行レベルロックで長時間の占有を許してしまう。
• SELECT ... FOR UPDATE を安易に用いてスケーラビリティを下げる。
• executeUpdate の戻り値を確認せずに「更新成功」と判断し、競合を見逃す。
• WHERE句に主キーだけを指定し、読込時点の列値（状態コードなど）を条件に含めない。

FAQ