情報処理安全確保支援士過去問題 令和6年春期 午後 問4
⇄問題PDFと解説を画面2分割で開く⇱問題PDF
設問1
解答入力欄
解答例・解答の要点
解説
- 〔aについて〕
重要情報が記録されたCSVファイルを閲覧できてしまうユーザーについて問われています。重要情報とは、表1のNo.5にある、氏名、住所、電話番号、メールアドレス、パスワード、銀行口座情報、決済情報のことです。
まず表1を確認すると、No.18にシステムのユーザーと役割について記載されています。(1)～(5)のうち重要情報にアクセスしてはならないユーザーは、(2)システム運用担当者と(4)システム開発者の2つです。本問は、重要情報にアクセスしてはならないユーザーが、重要情報が記録されたCSVファイルを閲覧できてしまうことが問題となっているので、(2)システム運用担当者と(4)システム開発者のどちらか、または両方が解答の候補となります。
次に、図1でCSVファイルの出力動作を確認します。CSVファイルは /var/data ディレクトリに出力され、CSVファイルのオーナーはbatchappuser、パーミッションは660と記載があります。パーミッションとは、ファイルやディレクトリに対するアクセス権（読取り・書込み・実行）のことです。Linuxにおいては、誰（オーナー・グループ・その他）に、何の権限（読取り・書込み・実行）を設定するかを3桁の数値で定義します。3桁の数値は左から順にオーナー・グループ・その他が定義されます。読取り権限は4、書込み権限は2、実行権限は1とし、その合計値で権限を表します。本問では660なので、オーナー（左）とグループ（中）に読取り[4]・書込み[2]の権限を設定し、その他グループには権限を与えないことを意味します。CSVファイルのオーナーはbatchappuserですので、batchappuser自身と、batchappuserが属するoperationグループにCSVファイルの読取り・書込みの権限が付与されていることがわかります。
ここで、表2と表3を確認すると、システム運用担当者とシステム開発者のOSアカウント設定は次のようになっています。- システム運用担当者
- ユーザーID：operator、所属グループ：operation
- システム開発者
- ユーザーID：developer、所属グループ：develop
所属グループoperationには、ユーザーIDがoperatorのアカウント、すなわちシステム運用担当者を含むため、システム運用担当者がCSVファイルを読取り・書込みをできることになります。これは表1のNo.18の要件に反する動作です。一方、システム開発者はdevelopグループ所属であり、問題文を見る限りでは、CSVファイルにアクセスできる権限は付与されていません。
したがって、重要情報が記録されたCSVファイルを閲覧できてしまうことが問題となるユーザーは「システム運用担当者」です。システム開発者はCSVファイルを閲覧できないため、重要情報取扱運用者は重要情報にアクセスできても問題ないためそれぞれ誤りです。
∴a＝ア：システム運用担当者
なお、問題文の状況においては、重要情報取扱運用者がCSVファイルへアクセスする権限が設定されていないように思います。実務上も、CSVファイルに直接アクセスするのではなく、システムを通して重要情報にアクセスできるようにすべきでしょう。ただし、仮にアクセスできたとしても、本問におけるユーザーの役割上は問題ありません。
- 〔bについて〕
システム運用担当者がCSVファイルにアクセスできないようにするために、batchappuserをどのグループに変更すべきかについて問われています。本問では、batchappuserが所属する operationグループがCSVファイルに読取り権限と書込み権限が与えられていることにより、同グループ所属のシステム運用担当者もCSVファイルを閲覧できてします点が問題となっています。したがって、batchappuser の所属グループを変更することで、この問題を解消できます。
所属グループはroot、operation、personal、developの4つがあります。このうち、rootは特権ユーザーであり、rootグループに所属させるのは最小権限の観点から適切ではありません。operationグループは現状と同じなので論外です。developグループに所属させた場合、developer（システム開発者）にもアクセス権限が付与されること、本番バッチサーバへのアクセスができなくなることから適切ではありません。personalグループに所属させた場合、同グループに所属するユーザーはpersonal（重要情報取扱運用者）であるため、CSVファイルへのアクセス件が付与されても問題はありません。以上より、personalグループが適切と判断できます。
∴b＝personal
- 〔cについて〕
CSVファイルを暗号化する場合に、プログラムの修正内容について問われています。
問題文では、表4のNo.3「注文データCSV出力バッチ処理」で暗号化を行う処理を追加するとあります。これにより、出力されたCSVファイルは暗号化された状態で保存されます。暗号化されたままでは読み込めませんので、その後、注文データCSVファイルを読み込む際に復号を行う必要があります。続くNo.4で「保存されたCSVファイルを読み込んで…」と記載されているため、復号が行われるのはこのタイミングであると判断できます。したがって、空欄cには「4」が当てはまります。
∴c＝4
設問2
解答入力欄
解答例・解答の要点
- システム運用担当者・アクセスできてしまう情報：パスワード，氏名，住所，電話番号，メールアドレス
- システム運用担当者・出力される場所：エ
- システム開発者・アクセスできてしまう情報：パスワード，氏名，住所，電話番号，メールアドレス
- システム開発者・出力される場所：オ
- f：・SHA-256
・SHA-384
・SHA-512
- g：・throw new RuntimeException(e)
・ランタイムエラーを例外としてthrowする。
解説
- 〔dについて〕
図3を見ると、5行目～7行目でユーザーが入力したパスワードをSHA-1でハッシュ化していることがわかります。SHA-1は160ビット（16進数40文字）のハッシュ値を生成するアルゴリズムですが、すでに危殆化してるため使用は推奨されません。当面は大丈夫かと思いますが、将来的に実行環境側でSHA-1のサポートが終了する可能性があり、その状況で"SHA-1"を引数にして呼び出すと、5行目でエラーが発生します。本処理はtry-catch文の中に記述されているため、エラーが発生するとcatchブロックに飛んでtry文を抜けます。この場合、this.passwordにはハッシュ化前のパスワードが格納されているため、このままSQL文を実行するとプレースホルダには平文のパスワードが割り当てられ、そのままデータベースに登録されてしまいます。したがって、空欄dには「5」が入ります。
∴d＝5
- 〔eについて〕
5行目で発生するエラーとは、NoSuchAlgorithmExceptionという例外です。JavaSEドキュメントによれば、この例外は、ある暗号アルゴリズムが要求されたにもかかわらず、現在の環境では使用可能でない場合にスローされます。NoSuchAlgorithmExceptionでも正解になると思いますが、IPAの公式解答例では「例外」とされているため、本解説でもそれに倣います。
∴e＝例外
- システム運用担当者とシステム開発者が、それぞれアクセスが禁止されているのにアクセスできてしまう情報について問われています。
〔システム運用担当者について〕
表1のNo.16によると「APサーバの標準出力と標準エラー出力は，リダイレクトしてAPサーバの/var/log/serverlogディレクトリは以下のテキストファイルに出力する」とあります。ここでいう標準出力とはプログラムの実行結果の出力先をいい、標準エラー出力とはプログラムにエラーが発生した場合のエラーコードなどの出力先をいいます。
/var/log/serverlogディレクトリのオーナーはwebappuserであり、パーミッションは775（問題訂正後）となっていますので、webappuserが所属するpersonalグループ以外のグループに属するユーザーは、同ディレクトリに対して読込み[4]と実行権限[1]を有します。また、同ディレクトリ配下のテキストファイルのオーナーはwebappuserであり、パーミッションは664とあるので、personalグループ以外のグループに属するユーザーは、同テキストファイルに対して読取り権限を有します。システム運用担当者が所属するoperationグループは、本番APサーバと本番バッチサーバへのアクセス権があり、かつ、/var/log/serverlogディレクトリ配下のテキストファイルにアクセスできるため、APサーバの標準出力と標準エラー出力にアクセスすることが可能です。
図3の22行目では、System.out.printlnによりデータベースに挿入したデータの一覧を標準出力に記録しています。図2によると、ユーザーマスターテーブルの列名は「ユーザーOID，ユーザーID，パスワード，氏名，郵便番号，住所，電話番号，メールアドレス，作成日時，更新日時」とあり、これらは全て標準出力に記録されます。このうち、表1のNo.5の重要情報に該当し、システム運用担当者がアクセスしてはならないのは、パスワード、氏名、住所、電話番号、メールアドレスの5つのデータです。
∴アクセスできてしまう情報＝パスワード、氏名、住所、電話番号、メールアドレス
出力される場所＝エ
【補足】
なお、本試験時は/var/log/serverlogディレクトリのオーナーはwebappuserであり、パーミッションは774となっていました。この場合、システム運用担当者を含めたpersonalグループ以外のグループに所属するユーザーは、同ディレクトリに対する実行権限がなく、同ディレクトリ配下のテキストファイルにアクセスすることができなくなります。その結果、設問が成立しなくなります。
〔システム開発者について〕
図3の24行目のlog.debugは、ログサーバへのAPログの出力を行う命令です。APログには、上記と同じく、データベースに挿入したデータの一覧がテキストファイルとして記録されるので、本番ログサーバへのアクセス権を有するシステム開発者は「ユーザーOID，ユーザーID，パスワード，氏名，郵便番号，住所，電話番号，メールアドレス，作成日時，更新日時」を閲覧することができます。このうち、システム運用担当者がアクセスしてはならない重要情報に該当するのは、パスワード、氏名、住所、電話番号、メールアドレスの5つのデータです。
∴アクセスできてしまう情報＝パスワード，氏名，住所，電話番号，メールアドレス
出力される場所＝オ
- 表1のNo.13には「開発環境は，…重要情報は保管されない」とあります。開発ログサーバには重要情報は存在しないので誤りです。
- sbinディレクトリは、Linux OSがシステム管理に必要なシステムファイルを格納するディレクトリです。問題文中に/sbinディレクトリについて言及はありませんが、/sbinディレクトリにログを出力するという記述はないので誤りです。
- 下線①の指摘は図3のソースコードに関するものです。図3のプログラムではCSVファイルを取り扱っていないため誤りです。
- 〔fについて〕
図3のソースコードでは同命令の引数がSHA-1となっていることから、この命令は引数で指定したハッシュ関数を取り扱うオブジェクトを生成していることがわかります。表1のNo.19には「パスワードは，CRYPTREC暗号リスト（令和5年3月30日版）の（中略）ハッシュ関数でハッシュ化してDBに保存する」という要件があります。CRYPTREC暗号リスト（令和5年3月30日版）で電子政府推奨暗号リストに指定されているハッシュ関数には、SHA-256、SHA-384、SHA-512、SHA3-256、SHA3-384、SHA3-512などがあるので、このうちいずれかを指定することになります。前述のとおりSHA-1はすでに推奨すべき状態ではなくなっているため、運用監視暗号リストに移されています。
なお、SHA-2という解答も想定されますが、SHA-2は第2世代セキュアハッシュアルゴリズムという意味で、SHA-256、SHA-384、SHA-512を総称したものです。特定のハッシュ関数の名称ではないので注意しましょう。
∴f＝SHA-256 / SHA-384 / SHA-512
- 〔gについて〕
修正前のUserDataクラスのソースコードでは、NoSuchAlgorithmExeptionが発生した際はlog.debug("error:"+e)により、エラーコードを出力するのみとなっています。しかし、その後の処理が記載されておらず、ハッシュ化に失敗しても後続のプログラムが動作するので、パスワードが平文のまま登録されるという問題がありました。そこで、修正後のプログラムでは、NoSuchAlgorithmExeptionが発生した際は処理を継続せず、終了する必要があります。今回で言えば、ランタイムエラーとして処理すればプログラムは終了します。
∴・throw new RuntimeException(e)
・ランタイムエラーを例外としてthrowする。
- 〔hについて〕
E氏の指摘によると、修正前のプログラムでは、変数 psObj の指すメモリ領域においてメモリリークが発生する可能性があるとされています。そこで、修正前のプログラムを見ると、変数 psObj がcloseされていません。PreparedStatementオブジェクトは、明示的に閉じられるまでリソースを解放しないので、これがメモリリークを引き起こします。そこで、修正後のプログラムでは変数 psObj をcloseする処理が追加されています。この解放処理は、エラー発生の有無にかかわらず必ず実行しなければなりません。このような場合、try-finally文のfinallyブロックに記述することなります。したがって、空欄hには「finally」が入ります。
∴f＝finally
- レインボー攻撃は、ハッシュ値からパスワードを特定するための逆引き表（レインボーテーブル）を用いて、パスワードを高速に解読する手法です。不正に取得したハッシュ化パスワードから元となったパスワードを解析するために使用されます。
レインボーテーブルは、使用される文字種と文字数の組合せごとに作成されます。解読対象となるパスワードの長さが長くなったり、使用可能な文字種が増えたりすると、全ての組合せを網羅するためのレインボーテーブルのサイズも当然大きくなります。このため、十分な長さのソルト値（ランダムデータ）を加えてからハッシュ化することが、レインボー攻撃への対策として有効です。選択肢の各ソースコードもsaltを使って耐性を高めようとするものです。- 正しい。ソルトとパスワードを連結した後に、ハッシュ化しています。その後、ソルトとハッシュ値を連結しています。DBに格納されているハッシュ値を再現するためにはソルトが必要となるため、通常はデータベースにソルトを格納しておきます。しかし、本問ではユーザーマスターテーブルの定義に変更はないという条件があるため、ソルトの保存方法としてハッシュ化パスワードの前に付ける運用になっています。ソルトは32文字の固定なので、検証時に分離することが可能です。
- 「ア」と異なるのは生のソルトを連結していない点です。加えたソルトをどこにも保存していないので、ハッシュ値の再現ができず、パスワードの検証を行うことができません。
- ハッシュ値とソルトを別々にハッシュ化し、それぞれを連結しています。攻撃者は、後半のソルト部分を除いた、パスワード部分を対象としてレインボー攻撃を試行することができるので対策にはなりません。また、ソルトが保存されないので、パスワードの検証をすることができません。
- ハッシュ化したパスワードに生のソルトを加えています。攻撃者は、前半のソルト部分を除いた、パスワード部分を対象としてレインボー攻撃を試行することができるので対策にはなりません。
- パスワードに2回のハッシュ化を行い、2回目にソルトを加えています。ソルトが保存されないので、パスワードの検証をすることができません。
