情報処理安全確保支援士 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行目と24行目では
  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