情報処理安全確保支援士 2024年 春期 午後 問04

解答の論理構成

1. CSVファイルの格納場所・パーミッションの確認
   【問題文】図1では「／var/dataディレクトリのオーナーはbatchappuserで、パーミッションは770」「CSVファイルのオーナーはbatchappuserで、パーミッションは660」と定義されています。
   770／660 はいずれも“グループ”にも読み取り権を与える設定です。
2. batchappuser の所属グループを確認
   【問題文】表2「batchappuser」の「所属グループ」は「operation」です。
3. “operation” グループに含まれる利用者を確認
   【問題文】表2「operator」は「所属グループ operation」で、「説明」に「システム運用担当者が利用する。」と記載されています。
   つまり「operation グループ ＝ システム運用担当者が属するグループ」です。
4. CSV ファイル閲覧が可能な人物を導出
   ① ディレクトリも CSV ファイルもグループに読み取り権がある（770／660）。
   ② そのグループは“operation”。
   ③ “operation”に属するアカウントは「operator」＝「システム運用担当者」。
   よって「システム運用担当者」が CSV ファイルを閲覧できてしまう問題が発生します。
5. 解答選択
   解答群のうち「システム運用担当者」に該当するのは「ア」。
   したがって a には「ア：システム運用担当者」が入ります。

誤りやすいポイント

• 「本番環境へのアクセス権がある」だけではファイルを読めるとは限らない点を見落としやすい。パーミッション（770／660）の具体的設定とグループ名の一致確認が必要です。
• 「重要情報取扱運用者」も本番環境にアクセスできるため誤答しやすいが、当該ディレクトリのグループが personal ではなく operation である点が決定的です。
• 「システム開発者」は本番ログサーバのみアクセス可（表3）で、本番バッチサーバにはアクセス権がないことを忘れがちです。

FAQ

解答の論理構成

1. CSV ファイルが置かれる /var/data ディレクトリは「パーミッションは770」と設計されています。
   770 は $rwxrwx---$ なので、 • 所有者 batchappuser … 読み書き実行可
   • 所属グループ … 読み書き実行可
   • その他 … 権限なし
2. 表2より、初期状態で batchappuser の「所属グループ」は operation です。

   「batchappuser」「operation」「本番バッチサーバ」

3. 表3より operation グループには

   「本番 AP サーバと本番バッチサーバへのアクセス権がある」
   と定義されており、一般ユーザー権限ながら本番バッチサーバへログインできます。

4. 役割定義（表1－18）ではシステム運用担当者について

   「重要情報にアクセスしてはならない。」
   とあり、operation グループはまさにそのシステム運用担当者が利用する OS アカウント operator の所属先です。

5. よって batchappuser が operation グループのままだと、 「システム運用担当者が /var/data の CSV ファイルを閲覧できてしまう」問題が発生します。
6. 重要情報を扱う権限があるのは表1－18(3) 重要情報取扱運用者 であり、その OS アカウント personal の所属先は personal グループです。表3では

   「personal」「一般ユーザー権限である。本番環境へのアクセス権がある。」
   と記載されています。

7. したがって batchappuser の所属グループを personal に変更すれば、 • システム運用担当者（operation）からのアクセス不可
   • 重要情報取扱運用者（personal）のみアクセス可能
   となり、要件を満たせます。
8. 以上より b に入る適切な所属グループは personal です。

誤りやすいポイント

• 「operation グループは監視だけだから読み取り権限は不要」という前提を見落とし、パーミッション 770 の意味を深掘りせずに root なら OK と考えてしまう。
• 「develop グループもログサーバへ入れる＝develop で良いのでは」と誤認し、CSV 連携先がバッチサーバであることを忘れる。
• 770 を 750 と読み間違え、「グループは読み取り不可」と勘違いする。

FAQ

解答の論理構成

1. 暗号化が施される箇所を確認
   • 問題文に「表4のNo.3 のプログラムに暗号化を行う処理を追加し」とあります。
   • 表4 No.3 は「注文データCSV出力バッチ処理」であり、Web受注システム側でCSVファイルを作成する処理です。
2. 復号が必要になるタイミングを整理
   • 暗号化されたCSVはHTTPSで業務システム側へ送られます（No.7「データ送信1バッチ処理」→No.10「データ受信2バッチ処理」）。
   • 受信後にCSVの内容をDBへ反映するのは表4 No.4「注文データCSV取り込みバッチ処理」です。
3. 復号を実装すべきプログラムを決定
   • 復号は「保存されたCSVファイルを読み込んで、業務システムのDBを更新する」処理の直前または処理内で行うのが最も自然です。
   • したがって、暗号化ファイルを読み取るNo.4に復号ロジックを追加することで整合が取れ、要件「CSV ファイルには重要情報が記録されるので…リスクを軽減」に合致します。
4. 結論
   • c に入るのは表4「注文データCSV取り込みバッチ処理」の番号、すなわち「4」です。

誤りやすいポイント

• 「データ受信2バッチ処理（No.10）」と混同する
  • No.10はファイルを“保存”するのみでDB操作を行わないため、復号をここで行うと保存用ディレクトリに平文が残ってしまいます。
• 「データ送信1バッチ処理（No.7）」を選んでしまう
  • No.7は送信側であり、暗号化と同じWeb受注システム側なので復号の対象外です。
• CSV出力・取込み双方で暗号化／復号を誤配置すると、後続処理がファイルを読めず障害が発生します。

FAQ

解答の論理構成

1. 図3の該当箇所を確認します。
   • 5: MessageDigest mdObj = MessageDigest.getInstance("SHA-1");
   • 6: byte[] hashByte = mdObj.digest(this.password.getBytes());
2. ハッシュ関数オブジェクトの生成に失敗すると NoSuchAlgorithmException が送出されます。
   【問題文】
   “今後、メンテナンスなどで実行環境を変更した場合に、d行目でeが発生すると、25、26行目では、パスワードが平文でユーザーマスタテーブルに保存されてしまう。”
3. ハッシュ化前に唯一例外が発生し得るのは行5の MessageDigest.getInstance("SHA-1") であり、ここで例外が発生すると行6以降のハッシュ処理は実行されません。
4. 例外捕捉後も this.password には平文が残るため、そのまま
   • 21: psObj.setString(3, this.password);
     で DB へ保存されることになります。
5. したがって d に入る行番号は “5” です。

誤りやすいポイント

• 行6で例外が発生すると考えてしまう。実際には行6は mdObj が null でなければ実行され、例外は原則発生しません。
• catch 節でログは出しているので安全と誤認し、平文保存リスクを見落とす。
• “ハッシュ化に失敗したら登録処理自体が止まる” と想定し、その後の処理を追跡しない。

FAQ

解答の論理構成

• 問題文には「今後、メンテナンスなどで実行環境を変更した場合に、d行目でeが発生すると、25、26行目では、パスワードが平文でユーザーマスタテーブルに保存されてしまう。」とあります。
• 図3のソースコードを確認すると、d行目に該当するのは
  5: MessageDigest mdObj = MessageDigest.getInstance("SHA-1");
  であり、この行で想定される障害は MessageDigest.getInstance() がアルゴリズムを見つけられない場合に送出される NoSuchAlgorithmException です。
• NoSuchAlgorithmException は Java における checked 例外であり、catch 句側にも catch (NoSuchAlgorithmException e) と明示されています。
• よって、e には「例外」が入るのが論理的に整合します。

誤りやすいポイント

• Error と混同する：Java の Error と Exception は別物。ここで問題にしているのは checked 例外です。
• 例外名をそのまま書く：設問は字句を尋ねており、「NoSuchAlgorithmException」ではなく汎用語「例外」を要求しています。
• try-catch 全体ではなく個別行に着目し忘れる：質問は “d行目で発生するもの” を指しているため、行単位の原因と結果を正確に追う必要があります。

FAQ

解答の論理構成

• 【問題文】表1の「重要情報(注1)に該当するデータ項目」には
  “氏名、住所、電話番号、メールアドレス、パスワード”
  が列挙されています。
• 図3の22～25行目では
  System.out.println("InsertData:" + this.toString()); log.debug("InsertData:" + this.toString());
  として、this.toString() が保持するインスタンス変数（図2参照）をそのまま出力しています。したがって上記5項目の値がログに記録されます。
• 表3で “develop” グループは
  “一般ユーザー権限である。開発環境と本番ログサーバへのアクセス権がある。”
  と規定されており、システム開発者（ユーザーID “developer”）は本番ログサーバを閲覧できます。
• 解答群「オ」は “本番ログサーバのAPログを保存したテキストファイル” なので、システム開発者が閲覧できてしまう場所に該当します。
• 以上より、アクセスされてしまう情報は
  “パスワード、氏名、住所、電話番号、メールアドレス”
  であり、出力先は解答群「オ」です。

誤りやすいポイント

• CSV ファイル（解答群「ウ」）を選んでしまう
  → CSV 出力はバッチサーバ上にあり、システム開発者（“developer”）はアクセス権がない。
• “ユーザーOID” や “ユーザーID” を含めてしまう
  → 下線①の指摘は「要件でアクセスが禁止されている情報」＝表1の重要情報のみが対象。
• ログ出力箇所を System.out.println() だけと判断
  → log.debug() も本番ログサーバへ転送される点を見落としやすい。

FAQ

解答の論理構成

1. 要件確認
   【問題文】表1 No.19 には
   「パスワードは、CRYPTREC暗号リスト（令和5年3月30日版）の電子政府推奨暗号リストに記載されているハッシュ関数でハッシュ化してDBに保存する。」
   と明記されています。
2. 現状の問題点
   図3の旧コード 5 行目は
   MessageDigest mdObj = MessageDigest.getInstance("SHA-1");
   としており、「SHA-1」は電子政府推奨暗号リストから除外されています。
3. 採用すべきハッシュ関数
   同リストでパスワードハッシュ用途に利用できる代表的な関数は
   「SHA-256」「SHA-384」「SHA-512」です。
4. コード修正箇所
   図4 5 行目の f には、上記いずれかを指定すれば要件を満たします。

誤りやすいポイント

• 「SHA-1 も Secure Hash だから可」と早合点してしまう。推奨リストにないため失格です。
• MD5 や RIPEMD-160 を選ぶ。どちらも現行リストには載っていません。
• bcrypt など派生アルゴリズムを直接指定しようとする。Java 標準 MessageDigest では扱えず問題の前提外です。

FAQ

解答の論理構成

1. 【問題文】には、初版ソースコードに対する指摘として
   “今後、メンテナンスなどで実行環境を変更した場合に、d行目でeが発生すると、25、26行目では、パスワードが平文でユーザーマスタテーブルに保存されてしまう。”
   とあり、例外発生後に処理を継続すると平文保存の危険があると明示されています。
2. 修正後コード（図4）の 8～10 行目には

誤りやすいポイント

• return; でメソッドを終了させるだけでは呼び出し側が異常を検知できず、上位層でコミット処理が行われる危険があります。
• System.exit() でプロセスを終了させると AP サーバ全体が停止し、可用性要件 “稼働率目標 99.9%” を損なう恐れがあります。
• SQLException など別の例外型で投げ直すと、呼び出し階層でキャッチ漏れが起きる可能性があります。ハッシュ関数取得失敗は DB とは無関係なため、汎用的な RuntimeException を用いるのが妥当です。

FAQ

解答の論理構成

1. 図4では
   　17：try { … }
   　27：} catch (SQLException e) { … }
   　28：} h {
   　という構造になっています。この形は Java の例外処理三部構成「try‐catch‐finally」を示唆します。
2. 23～24行目でログ出力、25～26行目で psObj.execute() と conn.commit() を行った後、33行目で psObj.close() を実行しリソースを確実に解放する意図が読み取れます。リソース解放は例外発生の有無にかかわらず実行する必要があるため、finally 節に置くのが適切です。
3. 問題文には「利用するAPサーバの実装では、変数psObjの指すメモリ領域においてメモリリークが発生する可能性がある。」とあります。メモリリーク防止には finally で close を呼び出すのが王道であり、これも finally 選択を裏付けています。
4. 以上より、h に入るキーワードは Java 構文の finally となります。

誤りやすいポイント

• try ブロック内で commit() に成功した場合だけ close すれば十分だと誤解し、finally ではなく catch 内に close を書いてしまう。
• Java7 以降の try-with-resources を連想して別解を探した結果、設問のコード構造（Java6 相当）と整合しない回答を書く。
• 例外発生時にロールバックを行うべきかどうかに気を取られ、設問が求めるキーワードを見落とす。

FAQ

解答の論理構成

• 図4の現行コードは
  6 行目 byte[] hashByte = mdObj.digest(this.password.getBytes());
  7 行目 this.password = String.format("%x"、new BigInteger(1, hashByte));
  となっており、入力パスワードをそのままハッシュ化してデータベースに保存します。
• 本文には「レインボーテーブル攻撃を受けたときに攻撃が成立してしまう」とあります。レインボーテーブルは“あらかじめ計算されたハッシュ値一覧”を用いる攻撃なので、パスワードに“salt”を付与してからハッシュ化し、かつ salt を保存しておくことで対策できます。
• 設問の前提は「変数saltには、addUserメソッドの呼出しごとに異なる32バイトの固定長文字列が入っている」。したがって
  ① salt + password を入力にしてハッシュ化
  ② ハッシュ結果と salt の両方を列「パスワード」に保存
  が必須条件です。
• 解答群を照合すると
  ア : hashByte = mdObj.digest((salt + this.password).getBytes());
  this.password = salt + String.format("%x"、new BigInteger(1, hashByte));
  は条件①②をいずれも満たします。
  イ・ウ・エ・オは salt を保存しない、あるいは salt をハッシュに含めていない、二重ハッシュなど要件外の動作を行うため不適切です。
• よって適切な修正はアとなります。

誤りやすいポイント

• salt をハッシュ後に連結する（エ）のような実装ではレインボーテーブル攻撃を防げません。salt は必ずハッシュの入力に含める必要があります。
• salt を保存し忘れる（イ）は検証時に salt が取り出せず、ログイン判定ができなくなります。
• 二重ハッシュや salt のハッシュ化（ウ・オ）は要件外の複雑化につながり、将来の保守で不整合を招きやすくなります。
• “ユニークな salt を生成”と“salt とハッシュを併せて保存”という二段階を混同しがちです。

FAQ