情報処理安全確保支援士 2011年 秋期 午後1 問02
販売システムへの機能追加設計に関する次の記述を読んで、設問1~5に答えよ。
A社は、部品製造を営む従業員数250名の中堅会社である。インターネットを介した販売システム(以下、Nシステムという)を利用し、企業向けに自社製品を販売している。Nシステムは、A社の販売部が3年前に開発し、運用している。
Nシステムの利用者は、利用者ID(以下、UIDという)を保有しており、ブラウザからインターネット経由でNシステムにアクセスし、ログイン画面でUID名とパスワードを入力することによってログインした上で、製品の在庫確認、注文を行う。Nシステムを利用する企業(以下、契約企業という)は、Nシステムの利用契約時に、利用責任者を1名登録する。利用責任者は、ヘルプデスクに対して、UIDの新規登録の他、UIDの削除、パスワード初期化、サスペンド解除を申請できる。申請の際は、利用責任者が申請書を電子メール(以下、メールという)でヘルプデスクに送付する。
Nシステムでは、UIDに対して表1に示す属性を定義し、その値をログイン処理に利用している。NシステムのUID及びログイン処理に関する、セキュリティ要件は図1のとおりである。
ヘルプデスクでは、図2に示す運用手順でUIDを管理している。ヘルプデスクによるUIDの設定変更時には、表2に示す値をUIDの属性に設定する。サスペンド設定は、バッチ処理で行う。バッチ処理は、毎日00:00に実行し、現在時刻がlastlogin_tの値から90日以上経過した全てのUIDに対して、表2の設定変更(e)に示す各属性値を設定する。
また、Nシステムのログイン画面で、UID名とパスワードが入力された場合のログイン処理の流れを図3に示す。ログイン成功時とロックアウト発生時に、利用者にメールで通知することで、不正ログイン及びその試行を利用者が把握できるようにしている。

〔契約企業からの要望〕
Nシステムの利用者数と利用頻度が増えるにつれて、利用者がパスワードを忘れた場合のパスワード初期化に要する期間を短縮してほしいという要望が、利用責任者からヘルプデスクに多く寄せられるようになった。パスワード初期化の申請から完了までの期間に利用者がNシステムを利用できないことで、契約企業によっては業務に悪影響が発生していることが背景にあった。
販売部では、Nシステムの利便性向上を目的として、利用責任者とヘルプデスクを介さずに、利用者自身がパスワード初期化を短時間で行えるパスワード初期化機能をNシステムに追加することを決定した。
販売部のH部長は、新人のF君に対して、G主任の支援を受け、パスワード初期化機能を設計するように指示した。また、H部長は、アプリケーションへの不用意な機能追加が原因で、セキュリティ上の問題が発生する事例が一般的に少なくないことを挙げ、現状のNシステムの仕様を十分に理解した上で検討を進め、社内の有識者によるレビューを受けるようF君とG主任に伝えた。
〔パスワード初期化機能の設計〕
F君は、図1に示すセキュリティ要件に従って、Nシステムのパスワード初期化機能を検討した。F君が作成した設計案を、図4に示す。

G主任はF君の設計案に対して、次の点を指摘した。
指摘1:この設計案では、ある状態のUIDに対してパスワード初期化を行った場合に、図1に示すセキュリティ要件が満たされなくなる。
F君はG主任の支援を受け、指摘1の問題点に対して図4の設計案を修正した。その後、社内の有識者による設計案のレビューが実施された。そのレビューでは、指摘1とは別に、次の2点が指摘された。
指摘2:今回設計したパスワード初期化機能によって仮パスワードを発行した場合には、図1のセキュリティ要件のうち、(エ)に記されているログイン処理中の強制的なパスワード変更ページへの遷移は不要ではないか。
指摘3:現行のヘルプデスクによるパスワード初期化運用と比較した場合に、図4の設計案に示す(i)〜(v)の手順には、攻撃者に不正に仮パスワードを取得されるリスクがある。
指摘2については、販売部での検討の結果、今回の機能追加においては図1のセキュリティ要件を変更しないという判断に基づき、指摘対象となったログイン処理中の強制的なパスワード変更ページへの遷移は残すこととした。
指摘3については、今回予定していた開発予算を考慮すると、これ以上のセキュリティ強化は困難であると販売部では判断した。また、設計したパスワード初期化機能の利用を契約企業単位で選択できるようにした。その後、販売部では、F君の設計に基づいてパスワード初期化機能の開発に着手した。
設問1:
問題文を見る表1中のaに入れる適切な字句を解答群の中から選び、記号で答えよ。
解答群
ア:AES
イ:RC4
ウ:RSA
エ:SHA-256
模範解答
a:エ
解説
解答の導き方
設問は表1の「ソルトを付加したパスワードの、ハッシュ関数 a によるハッシュ値を表す。」の a に入る語を選ぶ問題です。ここから次が分かります。まずパスワードはソルトと組にしてハッシュ化して保管する設計であること、つまり保管側のハッシュ関数には「不可逆であること(逆算耐性)」と「総当たり攻撃に対する実効的な耐性」が求められます。
考え方を段階的に示します。
-
必要な性質を整理する
- 逆算(preimage)耐性:攻撃者がハッシュ値から元のパスワードを復元できないことが最も重要です。ログイン認証で狙われるのは「ハッシュから原文パスワードを得る」あるいは「ハッシュと一致する別の入力を見つけて認証を通す」ことだからです。
- 総当たり(ブルートフォース)対策:ハッシュ計算を意図的に重くする(ストレッチング)ことで、試行速度を下げさせることが実務上重要です。ソルトはレインボーテーブル等の事前計算攻撃を無効化します。
- 既知の実用的脆弱性がないこと:既に実用的な攻撃が知られているハッシュは避けるべきです(例:MD5やSHA-1は衝突やその他の問題が指摘されています)。
-
問題文中の条件との整合を見る
- 図1の(エ)に「仮パスワードは十分に長いランダムな文字列」とあるため、仮パスワードも同様にハッシュで保管され得ること、かつハッシュが元の文字列を露呈しては困ることが読み取れます。したがってハッシュには強い逆算耐性が必要です。
- 表1が「ソルトを付加したパスワード」を扱う設計になっていることから、ソルト+ハッシュの組合せでレインボー攻撃を防ぐ想定です。
-
選択肢の評価(設問の選択肢の中で比較する)
- MD5やSHA-1のように実用上問題が指摘されているものは避けるべきです。
- 単にメッセージ認証用のHMACや可逆暗号はパスワード保管には不適切です(検証の仕組みが異なる)。
- 一方で、現実的に「逆算耐性が高く既知の実用的脆弱性がない」標準的ハッシュとしてはSHA-256が妥当です(ただし実務ではさらにPBKDF2/bcrypt/scrypt/Argon2のようなストレッチング/KDFを使うのが望ましい)。選択肢の中で最も適切なのはSHA-256です。
以上より、a にはSHA-256が入るのが適切で、問題の選択肢記号では エ が正解となります。
誤りやすいポイント
- 衝突耐性ばかり重視して選ぶ:パスワード保管では衝突より逆算(preimage)耐性と総当たり耐性が重要です。衝突が起きても攻撃者が直接パスワードを得られるとは限りません。
- HMACや可逆暗号を選ぶ誤り:HMACはメッセージ認証、可逆暗号は平文の復元が前提であり、パスワード照合の要件とは用途が異なります。
- ソルトだけで十分と考える:ソルトはレインボー表対策ですが、ハッシュ計算が高速だとGPU等で大量に試されてしまうためストレッチングも必要です。
- 古いハッシュ(MD5/SHA-1)を選ぶ:これらは既知の攻撃や短期的な安全性低下の報告があり、推奨されません。
FAQ
Q: SHA-256単体で完璧ですか?
A: 選択肢に限りがある試験問題ではSHA-256が最適な選択ですが、実務ではSHA-256をそのまま高速に反復せず使うのは望ましくありません。PBKDF2/bcrypt/scrypt/Argon2のようなストレッチング(反復・メモリ負荷)を組み合わせることを推奨します。
A: 選択肢に限りがある試験問題ではSHA-256が最適な選択ですが、実務ではSHA-256をそのまま高速に反復せず使うのは望ましくありません。PBKDF2/bcrypt/scrypt/Argon2のようなストレッチング(反復・メモリ負荷)を組み合わせることを推奨します。
Q: 衝突耐性と逆算耐性はどう違いますか?
A: 衝突耐性は「異なる入力が同じハッシュになることを見つけにくい」性質、逆算耐性(preimage)は「与えられたハッシュ値から元の入力を見つけにくい」性質です。パスワード保管で重要なのは後者(および総当たり対策)です。
A: 衝突耐性は「異なる入力が同じハッシュになることを見つけにくい」性質、逆算耐性(preimage)は「与えられたハッシュ値から元の入力を見つけにくい」性質です。パスワード保管で重要なのは後者(および総当たり対策)です。
Q: なぜソルトが必要ですか?
A: ソルトを付けると同じパスワードでもユーザごとに異なるハッシュになり、レインボー表や事前計算攻撃を無効化できます。ただしソルトはストレッチングの代替ではありません。
A: ソルトを付けると同じパスワードでもユーザごとに異なるハッシュになり、レインボー表や事前計算攻撃を無効化できます。ただしソルトはストレッチングの代替ではありません。
関連キーワード: 逆算耐性、ソルト、ストレッチング、SHA-256、パスワードハッシュ
設問2:
問題文を見る模範解答
b:statusの値が0
c:lockout_tの値から60分以上経過している
d:failsの値が4以下
e:temppassの値が0
解説
解答の論理構成
- 表1でstatusは “0:ログイン可能 1:ロックアウト状態 2:サスペンド状態” と定義されています。ログインを続行できるのは “ログイン可能” のときだけなので、判定②では「statusの値が0」を確認します。
- “ロックアウト状態は、60分以上経過した後の最初のログイン時に解除される” という図1の要件から、ロックアウト中(status=1)であった場合はlockout_tと現在時刻の差が60分以上かどうかを調べる必要があります。したがって判定④は「lockout_tの値から60分以上経過している」になります。
- パスワード誤り時にはfailsを1加算し、5回連続で誤るとロックアウトに移行します。加算後にfailsが4以下であればまだロックアウトさせずに再試行させるので、判定⑥は「failsの値が4以下」です。
- 仮パスワード状態(temppass=1)でログインした場合は強制的にパスワード変更ページへ遷移させる仕様です。そのため、通常のログイン成功か強制変更かを分ける判定⑦ではtemppassが0(仮パスワードではない)かどうかを確認します。
以上より
b:statusの値が0
c:lockout_tの値から60分以上経過している
d:failsの値が4以下
e:temppassの値が0
b:statusの値が0
c:lockout_tの値から60分以上経過している
d:failsの値が4以下
e:temppassの値が0
誤りやすいポイント
- statusは「ログイン可能=0」を見落としがちで、つい “2” と答えてしまうケースがあります。
- failsのカウントは “加算後” に判定される点に注意が必要です。加算前と勘違いすると誤答の原因になります。
- ロックアウト解除判定は “60分以上経過+最初のログイン” という二つの条件があるため、時間だけで解除されると早合点しやすいです。
- 仮パスワード判定ではpasswordではなくtemppassを使う点、そして0/1の意味を取り違えるミスが多発します。
FAQ
Q: failsを0にリセットするタイミングはどこで起きますか?
A: ログイン成功時、パスワード初期化時、ロックアウト解除時の3か所で0に戻すと図1に記載されています。
A: ログイン成功時、パスワード初期化時、ロックアウト解除時の3か所で0に戻すと図1に記載されています。
Q: サスペンド状態(status=2)のときはどの判定で弾かれますか?
A: 判定②でstatusの値が0を満たさないためNO分岐に入り、その後の判定で最終的にログイン失敗となります。
A: 判定②でstatusの値が0を満たさないためNO分岐に入り、その後の判定で最終的にログイン失敗となります。
Q: 仮パスワードでログインした場合に強制変更ページへ遷移するのはなぜですか?
A: 仮パスワードは一時的なものであり、利用者本人が安全な本来のパスワードへ直ちに変更するよう図1で義務づけられているからです。
A: 仮パスワードは一時的なものであり、利用者本人が安全な本来のパスワードへ直ちに変更するよう図1で義務づけられているからです。
関連キーワード: ロックアウト、サスペンド、仮パスワード、ハッシュ関数、連続失敗回数
設問3:指摘1について(1)、(2)に答えよ。
問題文を見る(1)図1のセキュリティ要件がどのように満たされなくなるか。45字以内で具体的に述べよ。
模範解答
サスペンド状態のUIDに対するパスワード初期化によって利用者がサスペンドを解除できる。
解説
解答の論理構成
- サスペンド状態の設定方法
- 問題文には「バッチ処理は、毎日00:00に実行し、現在時刻がlastlogin_tの値から90日以上経過した全てのUIDに対して、表2の設定変更(e)に示す各属性値を設定する。」とあります。
- 表2の設定変更(e)ではstatusに “2” を設定し、これがサスペンド状態であることが読み取れます。
- サスペンド解除が許可されている主体
- 「利用責任者は、ヘルプデスクに対して、UIDの新規登録の他、UIDの削除、パスワード初期化、サスペンド解除を申請できる。」とあり、解除はヘルプデスク経由で実施することが前提です。
- 設計案が行うパスワード初期化処理
- 図4の手順(iii)では「UIDの各属性に対して、表2の設定変更bに示す値を設定する。」と記述されています。
- 表2の設定変更bはstatusに “0” を設定する仕様です。
- 要件違反が発生する流れ
- サスペンド状態(status=2)のUIDが自力で手順(i)~(v)を実行すると、手順(iii)でstatusが “0” へ上書きされます。
- その結果、本来ヘルプデスクだけが行えるはずのサスペンド解除が、利用者自身の操作で行えてしまいます。
- よって、図1のセキュリティ要件「サスペンド解除は利用者自身では行えない」という条件を満たさなくなるため、指摘1の内容として「サスペンド状態のUIDに対するパスワード初期化によって利用者がサスペンドを解除できる。」が成立します。
誤りやすいポイント
- サスペンド状態とロックアウト状態を混同し、「status=1」か「status=2」かを取り違える。
- 表2の「設定変更b」がstatus=0を設定することを見落とし、パスワード初期化が状態を解除しないと誤解する。
- 「利用責任者→ヘルプデスク→解除」という手続上の制約が機能追加後も維持されるかを確認し忘れる。
FAQ
Q: ロックアウト状態もパスワード初期化で解除されますが、これは問題にならないのですか?
A: ロックアウト状態は元々「パスワード初期化時に解除される」と設計済みであり、既存運用と矛盾しません。問題になるのは“利用者自身では解除不可”と定められたサスペンド状態だけです。
A: ロックアウト状態は元々「パスワード初期化時に解除される」と設計済みであり、既存運用と矛盾しません。問題になるのは“利用者自身では解除不可”と定められたサスペンド状態だけです。
Q: 設計案でstatusを変更しなければ良いのでは?
A: statusを変更しないと仮パスワードを入力してもサスペンド状態のままでログインできません。解除方法を別に用意しない限り利便性が得られず、設計の趣旨と矛盾します。
A: statusを変更しないと仮パスワードを入力してもサスペンド状態のままでログインできません。解除方法を別に用意しない限り利便性が得られず、設計の趣旨と矛盾します。
Q: 仮パスワード発行時にfailsを0にするのは安全ですか?
A: ロックアウト解除と同様に連続失敗回数をリセットする既存仕様(設定変更b)と整合するため問題ありません。ただし別の攻撃面が無いかは総合的に評価が必要です。
A: ロックアウト解除と同様に連続失敗回数をリセットする既存仕様(設定変更b)と整合するため問題ありません。ただし別の攻撃面が無いかは総合的に評価が必要です。
関連キーワード: アカウントロック、認証状態管理、サスペンド、権限分離、セッション制御
設問3:指摘1について(1)、(2)に答えよ。
問題文を見る(2)上記(1)の問題点の発生を防止するためには、パスワード初期化機能にどのような修正が必要か。表1中の属性名を用いて、35字以内で述べよ。
模範解答
statusの値が2のUIDはパスワード初期化を実行しない。
解説
解答の論理構成
- 図1のセキュリティ要件には「(カ)90日間ログインに成功していないUIDは、ログイン不可能になる。このUIDの状態をサスペンド状態と呼ぶ。サスペンド状態は、契約企業の利用責任者からのサスペンド解除申請によってだけ解除でき、利用者自身では解除できないようにする。」とあります。
- 表2の「設定変更b」はパスワード初期化時にstatusの値を 0 にします。
- 図4の設計案では、(iii) でサスペンド状態かどうかを確認せずに表2の設定変更bを適用しています。結果として statusが2 → 0 に変わり、利用者自身でサスペンド解除が起こり得ます。
- これは前掲の要件「利用者自身では解除できないようにする」と矛盾します。
- よって、「statusの値が 2 のUIDにはパスワード初期化を実行しない」という修正で要件不一致を防げます。
誤りやすいポイント
- 「ロックアウト状態(status=1)はパスワード初期化で解除してよい」とあるため、サスペンド状態(status=2)も同じ扱いと誤解しがちです。図1の(オ)と(カ)は別の状態です。
- 表2のstatus列だけを見て、「常に0に更新すれば良い」と短絡すると要件違反になります。
- サスペンド解除は「利用責任者の申請のみ」という運用ルール(図2‐5.)も見落とされがちです。
FAQ
Q: サスペンド状態でも仮パスワードを発行し、ログイン後に強制パスワード変更させても問題ないのでは?
A: 図1(カ)が「利用者自身では解除できない」と明記しています。仮パスワード発行だけでstatusが0になれば解除と同義になり、要件違反です。
A: 図1(カ)が「利用者自身では解除できない」と明記しています。仮パスワード発行だけでstatusが0になれば解除と同義になり、要件違反です。
Q: status=2を維持したままtemppassやpasswordだけ更新すればよいのでは?
A: その場合でも利用者はログインできません。目的が「短時間で初期化し再利用させる」ことなので要件と機能要望を同時に満たせません。運用上は利用責任者経由での解除が先です。
A: その場合でも利用者はログインできません。目的が「短時間で初期化し再利用させる」ことなので要件と機能要望を同時に満たせません。運用上は利用責任者経由での解除が先です。
Q: サスペンド状態を考慮してアクセス拒否のエラーメッセージを変える必要がありますか?
A: メッセージ内容は問題文に触れられていませんが、サスペンドであることを明確に表示すると攻撃者に有用な情報を与える恐れがあります。具体的な実装は情報開示方針に従って決定します。
A: メッセージ内容は問題文に触れられていませんが、サスペンドであることを明確に表示すると攻撃者に有用な情報を与える恐れがあります。具体的な実装は情報開示方針に従って決定します。
関連キーワード: アカウントロック、サスペンド状態、パスワード初期化、アクセス制御、セキュリティ要件
設問4:
問題文を見る指摘2の内容が指摘された理由を、図2のヘルプデスクによる運用手順との違いを踏まえて、30字以内で述べよ。
模範解答
仮パスワードを知っているのが利用者だけであるから
解説
解答の論理構成
- 図2の運用手順③では
「設定した仮パスワードは、ヘルプデスク担当者が利用責任者に電話し、読み上げて通知する。」
とあり、ヘルプデスク担当者が仮パスワードを把握します。 - 一方、図4の手順(iii)では
「プログラムが仮パスワードを発行し、ブラウザに表示する。」
とあり、仮パスワードは利用者のブラウザにのみ提示され、ヘルプデスク担当者は介在しません。 - したがって、図1のセキュリティ要件(エ)が求める強制パスワード変更は、ヘルプデスクが仮パスワードを知る旧方式を前提にした措置であり、新機能では不要と判断されました。
- 以上より「仮パスワードを知っているのが利用者だけであるから」という理由が導かれます。
誤りやすいポイント
- 図1(エ)の「強制パスワード変更」を形式的に残す理由を誤解し、ヘルプデスクの関与有無を見落とす。
- 図4(iii)の「ブラウザに表示」をメール送信と混同し、第三者の閲覧可能性を誤判定する。
- 図2③の電話通知を「安全」と評価し過ぎて、担当者が内容を把握している事実を軽視する。
FAQ
Q: なぜヘルプデスクが仮パスワードを知っていると強制変更が必要なのですか?
A: 第三者である担当者が知ることで漏えいリスクがあるため、利用者本人に早期変更を強制して安全性を確保します。
A: 第三者である担当者が知ることで漏えいリスクがあるため、利用者本人に早期変更を強制して安全性を確保します。
Q: 図4の方式で強制変更を残す判断は誤りですか?
A: 試験シナリオでは「図1のセキュリティ要件を変更しない」との方針が示されており、要件維持のため残されています。
A: 試験シナリオでは「図1のセキュリティ要件を変更しない」との方針が示されており、要件維持のため残されています。
Q: メールでURLを送るだけで安全ですか?
A: 取得ページURLが「十分に長いランダムな文字列」かつ「10分以内未アクセスで無効化」される設計でリスクを低減していますが、完全に消せるわけではありません。
A: 取得ページURLが「十分に長いランダムな文字列」かつ「10分以内未アクセスで無効化」される設計でリスクを低減していますが、完全に消せるわけではありません。
関連キーワード: 仮パスワード、強制パスワード変更、ロールベース運用、URLトークン、セキュリティ要件
設問5:
問題文を見る指摘3について、攻撃者が不正に仮パスワードを取得する手口を45字以内で述べよ。
模範解答
取得ページURLを通知するメールを盗聴し、利用者より先に取得ページにアクセスする手口
解説
解答の論理構成
- 攻撃対象は「図4」で追加されたパスワード初期化機能です。
− 「(ii)入力されたUID名が存在する場合は、プログラムがパスワード取得ページのURL…を発行し、利用者にメールで通知する」と記載されています。 - 取得ページURLさえ先に押さえれば、誰でも「(iii)…プログラムが仮パスワードを発行し、ブラウザに表示する」段階へ進めます。
- URLはメールで配布されるだけで、本人確認や追加認証はありません。
- よってメールを途中で傍受・盗聴できる攻撃者は、正規利用者より先に該当URLへアクセスして仮パスワードを取得できます。
- 以上から、設問が求める「不正に仮パスワードを取得する手口」は、取得ページURLを含むメールの盗聴→早期アクセスという流れになります。
誤りやすいポイント
- 取得ページURLが「十分に長いランダムな文字列」であることから安全と思い込み、配送経路の盗聴リスクを見落とす。
- 「(v)一度アクセスされた取得ページURLは無効」という仕様だけを根拠に、先取りアクセスの可能性を軽視する。
- SSL通信の言及はブラウザ‐サーバ間のみであり、メール配送経路を保護していない点を混同する。
FAQ
Q: URL生成にランダム文字列を含めているのに、なぜ危険なのですか?
A: URL自体が漏えいすれば誰でもアクセスできるためです。配送手段が暗号化されていないメールであれば、盗聴や転送ミスで漏えいする可能性があります。
A: URL自体が漏えいすれば誰でもアクセスできるためです。配送手段が暗号化されていないメールであれば、盗聴や転送ミスで漏えいする可能性があります。
Q: 「10分以内にアクセスがない場合は無効」でも防げませんか?
A: 攻撃者がリアルタイムにメールを盗聴できる場合、10分は十分な猶予です。したがって完全な対策にはなりません。
A: 攻撃者がリアルタイムにメールを盗聴できる場合、10分は十分な猶予です。したがって完全な対策にはなりません。
Q: 追加の対策例はありますか?
A: 取得ページアクセス時にワンタイムコードや本人確認質問を要求する、多要素認証を導入するなどが考えられます。
A: 取得ページアクセス時にワンタイムコードや本人確認質問を要求する、多要素認証を導入するなどが考えられます。
関連キーワード: メール盗聴、URLトークン、リプレイ攻撃、ランダム文字列、認証強化







