WHITE HACKERACADEMY

start-02 リスクを減らすという考え方

コードを直す前に、何を確かめるか

下の説明と処理図を読み、入力した値がどの判断を通って結果になるかを確認します。実行後は「入力」「途中の値」「期待結果と実際の結果」を比較します。最初から正しく動く必要はありません。

演習 start-02 予防が失敗しても復旧経路を残す

架空の予約システムで、侵入予防だけの計画が採用されました。事故後の検知と復元まで含め、欠けている防御を一覧にしてください。

範囲: 入力に与えた条件から防御段階を判定する模型です。数値のリスク予測や現実の侵入確率は計算しません。

処理図と読み方

処理の流れ
  1. 想定した事故
  2. 各対策の役割
  3. 欠けた工程
  4. 残余リスク

想定した事故 → 各対策の役割 / 各対策の役割 → 欠けた工程 / 欠けた工程 → 残余リスク

独自の説明図。入力に与えた条件から防御段階を判定する模型です。数値のリスク予測や現実の侵入確率は計算しません。

  1. 想定した事故:侵入の成否と、・バックアップの状態を受け取ります。

  2. 各対策の役割:予防・検知・復旧を別々の条件で評価します。

  3. 欠けた工程:予防があっても、監視や復元できるコピーがなければ不足を残します。

  4. 残余リスク:足りない段階と、事故を見つけて戻せるかを返します。

input → policy:事故と対策の有無。

policy → process:予防・検知・復旧の成立条件。

process → result:不足段階と復元の準備状態。

観測順序:

  1. input:侵入の成否と、・バックアップの状態を受け取ります。

  2. policy:予防・検知・復旧を別々の条件で評価します。

  3. process:予防があっても、監視や復元できるコピーがなければ不足を残します。

  4. result:足りない段階と、事故を見つけて戻せるかを返します。

誤解しやすい点: 侵入予防があれば復旧準備は不要、ではありません。の監視と復元確認は、それぞれ異なる失敗に備える独立した仕事です。

このコードで確かめること

事故への備えを点検します。logs は記録を残すこと、review はその記録を確認することです。backup はコピーを残すこと、restoreTest はコピーから戻せるか試すことです。攻撃を防ぐ設定があるだけで、発見や復旧までできると判定しないでください。

プログラムが満たす条件

予防の有無で検知・復旧まで成功としないでください。検知はlogsとreview、復旧はbackupとrestoreTestが両方必要です。

初めてコードを編集する方へ:入力・記号・実行の読み方
  1. 入力は教材がケースごとに自動で渡します。例えば input.name は入力の name という項目を読む記述です。下の編集欄に実名や本物のパスワードを入力する必要はありません。
  2. JSONの {} は項目の組、[] は順番のある一覧です。例えば {"name":"A"} は name が文字列 A の入力です。true は「はい」、false は「いいえ」、null は値がないことを表します。false が必ず失敗という意味ではありません。
  3. const は値に名前を付ける記述、=== は同じかの比較、&& は両方、|| はどちらか、! は反対です。return が最後の結果を返し、trace は途中の値を記録します。
  4. まず変更せず「コードを実行し、結果を比較する」を押します。「見直す」のケースを1つ選び、違う項目を確認します。編集欄の「修正対象」の近くを一か所変えて、同じボタンでもう一度実行します。
  5. ヒントと参考実装は編集欄の下で開けます。答えを写す前に、どの入力で結果が変わるはずか予想してください。一致したら、修正した条件がなぜ必要かを自分の言葉で説明します。

「修正対象」と書かれた部分を探します。まず変更せず実行し、期待結果と違う箇所を確かめてから、条件や計算を変更してください。

このコードは外部のWebサイトやファイルには接続しません。図の各段階で trace に渡された値を表示します。文字列や計算などのコードは実行しますが、実際の攻撃・送信・削除は行いません。

この説明文は振り返り用に保存します。文章の内容そのものを自動で正誤判定することはありません。

条件を1つ変えて試す

下の入力は最初のケースのコピーです。課題で扱う範囲の値を1つだけ変え、結果を予想してから実行してください。いつもの全ケースに、この入力を1件追加して比較します。入力の意味は上の課題と処理図で確認できます。

修正する課題

修正する課題

予防の有無で検知・復旧まで成功としないでください。検知はlogsとreview、復旧はbackupとrestoreTestが両方必要です。

初期コード(修正対象)

初期コード(修正対象)

async function run(input, trace) {
  trace("input", input);
const prevention = input.prevention;
  const detection = input.logs && input.review;
  /* 修正対象:予防の有無で検知・復旧まで成功としないでください。検知はlogsとreview、復旧はbackupとrestoreTestが両方必要です。 */
  const recovery = input.prevention || input.backup;
  trace("policy", {prevention, detection, recovery});
  const gaps = [];
  if (!prevention) gaps.push("予防");
  if (!detection) gaps.push("検知");
  if (!recovery) gaps.push("復旧");
  trace("process", {gaps, incident:input.incident});
  const output = {gaps, incidentDetected:input.incident && detection, recoverable:recovery};
  trace("result", output);
  return output;
}
ケースごとの入力・期待結果・理由

ケースごとの入力・期待結果・理由

ケース1:正常:三段階がそろう

入力:

{"prevention":true,"logs":true,"review":true,"backup":true,"restoreTest":true,"incident":true}

期待結果:

{"gaps":[],"incidentDetected":true,"recoverable":true}

理由:侵入予防があっても事故の検知と復元を独立に確認。

ケース2:異常:コピーを試していない

入力:

{"prevention":true,"logs":true,"review":false,"backup":true,"restoreTest":false,"incident":true}

期待結果:

{"gaps":["検知","復旧"],"incidentDetected":false,"recoverable":false}

理由:保管とコピーの存在だけでは足りない。

ケース3:境界:事故がまだない

入力:

{"prevention":false,"logs":true,"review":true,"backup":true,"restoreTest":true,"incident":false}

期待結果:

{"gaps":["予防"],"incidentDetected":false,"recoverable":true}

理由:事故未発生でも復旧の準備は評価できる。

段階的なヒント

段階的なヒント

  1. 対策の名前が似ていても目的が違います。

  2. バックアップの存在と、復元検証の結果を分けます。

  3. incidentは検知済みの意味ではありません。

参考実装

参考実装

async function run(input, trace) {
  trace("input", input);
const prevention = input.prevention;
  const detection = input.logs && input.review;
  const recovery = input.backup && input.restoreTest;
  trace("policy", {prevention, detection, recovery});
  const gaps = [];
  if (!prevention) gaps.push("予防");
  if (!detection) gaps.push("検知");
  if (!recovery) gaps.push("復旧");
  trace("process", {gaps, incident:input.incident});
  const output = {gaps, incidentDetected:input.incident && detection, recoverable:recovery};
  trace("result", output);
  return output;
}

別の状況へ適用する

医療予約:停止時間の影響が大きく、復元後の業務確認を追加する。

検証:予約の重複や欠落まで検査する。

公開資料サイト:より改ざん検知の比重が高い場合がある。

検証:改変検出と原本への復元時間を測る。

到達確認

  • 各条件がどの段階に効くか説明する。

  • 全対策ありでも事故発生を不可能とはしない。

  • 実測していない復旧能力を成功にしない。