Trainer 25: Practical Simulation Answers

目的

Trainer 24 の8ケースに対する模範解答と、1文理由の基準を提供する。

使い方

先に trainer-24-practical-simulation-set.md を自力で解く
本ファイルで「答え」よりも「理由の型」を照合する
理由が弱い場合は Error Code を振って Fix Rule を更新する

模範解答一覧

Case	Model Answer	1文理由（模範）	主な誤答パターン
01	要件確認と報告ライン確立を先に実施	`first` 問題では実装より先に法令/契約要件と責任分界を確定しないと統治不備になるため。	先に設定変更・先に導入
02	JML即時反映 + 証跡自動化	退職者アカウント残存はライフサイクル統制不全なので、認証強度より無効化遅延の解消が優先。	パスワード強化のみ
03	鍵管理基盤の分離（HSM等）と鍵運用統制	暗号強度より鍵管理が破綻していると機密性は成立しないため、鍵の保護とライフサイクル統制が最重要。	アルゴリズム変更のみ
04	共有ID禁止維持 + 緊急時PAM/JIT	例外恒常化は監査不能なため、緊急性と統制を両立する一時的特権付与がDefensible。	共有IDを条件付きで容認
05	失敗要因は評価ラベル過信と要件未整合	EAL等は保証の深さを示す指標であり、自組織要件適合を確認しない導入は失敗確率が高い。	高評価=万能と判断
06	RBAC + ABACのハイブリッド化	部署横断の動的条件はRBAC単体で表現しづらく、属性条件を重ねることで過剰権限を抑制できる。	ロール追加だけで対応
07	委託先事故でも自組織で監督・報告・是正を実施	責任の外部委譲はできないため、ベンダー責任条項があっても説明責任は自組織に残る。	ベンダー任せで縮退対応
08	Root of Trust と鍵チェーン整合の確認を最優先	改ざん疑い時に再インストール先行は証跡と原因分析を損ない、信頼起点確認が初動として妥当。	先に再構築

採点の目安

満点基準:
- 答えが合っている
- 理由が「主語・時制・統治/統制」を含む
減点基準:
- 技術名のみで理由を書いている
- first で順序理由がない

Error Codeマッピング例

ケース	出やすいError	Fix Rule例
01/04/07	E2, E4	`firstは確認->評価->報告、技術は最後`
02/06	E1, E3	`認証と認可、主体と権限を分離`
03/05/08	E1, E4, E5	`原則先行、鍵管理/信頼境界/証跡を先に確認`

次アクション

8ケース中、理由が弱かったケースだけ翌日再演習
連続2回弱いケースは該当ドリル（D1/D3/D5）へ戻して補強