# Security from Zero — 第5回ワークブック

教材：https://secopsnomad.si/ja/blog/security-from-zero-05-accounts-authentication-access/
演習ファイル：https://secopsnomad.si/downloads/security-from-zero-topic-05-lab.json

目標：識別、認証、認可、セッションを区別し、10件の要求を判断して、根拠付きのアカウント・セッション調査メモを作る。

教材はすべて架空です。製品のエクスポート、実事件、本番のポリシーエンジンではありません。オフラインで進め、本物のパスワード、OTPの秘密、Cookie、Bearerトークン、復旧コード、個人の識別子を記入しないでください。

## 1. 範囲を決める

学習日：
元の教材ファイル名と、変更せずに保存した場所：
時刻帯：
取り組むのは演習A（ポリシー）か、演習B（イベント）か：
演習Bが演習Aのポリシーを完全に再現すると考えてはいけない理由：

それぞれ1文で説明：
- ID／アカウント：
- 識別：
- 認証：
- 認可：
- セッション：
- ロール／グループ：

穴埋め：サインイン成功は______を示すが、______は示さない。

## 2. MFAとパスキー

| 例 | 要素の種類／重要な限界 |
| --- | --- |
| パスワードと秘密の質問 | |
| パスワードとTOTP | |
| 必須のローカルPINで有効にするセキュリティキー | |
| 身に覚えのないプッシュ要求の到着 | |

単純化したパスキー登録でサービスが保存するもの：
認証器が管理するもの：
サインイン時にサービスが検証するもの：
指紋やローカルPINをサイトのパスワードとして送らない理由：
端末に結び付く設計と同期する設計の違い：
パスキーでも除去されないリスクを2つ：
個人アカウントを変更する前に復旧経路をどう確認するか：

## 3. 演習A：ポリシーをたどる

規則：有効なアカウント、許可された経路、グループのロールと有効な期限付きロール、操作と対象範囲の完全一致、自分のプロフィールは所有者も一致。許可は加算され、明示的な拒否や入れ子のグループはない。終了時刻は有効期間に含めない。この教材だけの規則です。

| 要求 | 有効なロール／経路／関係する時刻 | 許可・拒否 | 決め手 |
| --- | --- | --- | --- |
| R1 | | | |
| R2 | | | |
| R3 | | | |
| R4 | | | |
| R5 | | | |
| R6 | | | |
| R7 | | | |
| R8 | | | |
| R9 | | | |
| R10 | | | |

許可／拒否の合計：
R3がR2と異なる理由：
R5をadminという単語だけで決められない理由：
ID管理者が将来の割り当てを変更できる場合のリスク：
同じ操作でもR7とR8が異なる理由：
R9が示す対象の所有者の重要性：

## 4. 演習B：根拠を読む

利用者の報告を、侵害の結論に変えずに記録：
アカウントID／セッション参照（資格情報ではない）：
日付と時刻帯：
ある出典／重要だが不足している出典：

| 参照 | UTC | 出典 | 記録された操作・結果 | 事実、解釈、不足情報のどれか |
| --- | --- | --- | --- | --- |
| E01 | | | | |
| E02 | | | | |
| E03 | | | | |
| E04 | | | | |
| E05 | | | | |
| E06 | | | | |
| E07 | | | | |
| E08 | | | | |
| E09 | | | | |
| E10 | | | | |

サインイン記録：件数／結果／記録された方法：
アプリ監査：件数／成功／拒否：
パスワード変更後の成功した閲覧の参照番号：
失効要求後の成功した閲覧の参照番号：
出力開始だけで完了や量を証明できるか：
1件の拒否だけで全アプリの封じ込めを証明できるか：
IP変更の説明になり得るものを2つ：
侵害を断定せず、上位担当に伝える理由になる観測：

## 5. 1ページの引き継ぎメモ

問いと範囲：
観測事実（E参照とUTC時刻を含める）：
解釈（事実と区別して記す）：
不明点：
次に求める根拠と、その理由：
封じ込めを変更できる権限を持つ担当：
関係するリソースで結果をどう確認するか：
扱いと理由：

パスワード変更の成功だけで安全とせず、export.startの成功だけでデータ窃取としないでください。

## 6. ライフサイクルの点検表

参加：所有者、承認、ロール、認証、復旧、期限：
異動：追加だけでなく、削除すべき以前の権限：
離任：ID、アプリのセッション、委任、ワークロードの所有者：
復旧：承認された確認経路、方法の変更、セッションの点検：
whoami／idが示すものと、示さないクラウド権限：
任意のローカル確認を実施したか。本物の出力は公開しない：

## 解答例：自分で終えてから確認

演習A：R1許可、R2許可、R3拒否、R4拒否、R5拒否、R6許可、R7許可、R8拒否、R9拒否、R10許可。許可5件、拒否5件。

R3は失効時刻2026-10-27T09:15:00Zちょうどです。R5に請求書を読む許可はなく、R8は経路が合いません。R9は自分用の許可で他人のプロフィールを求めています。将来の権限を変更できる能力自体は強い権限ですが、静的な演習ではその変更を再現しません。

演習B：サインインはE01とE04の2件で、成功1件（password+totp）、拒否1件。アプリ監査はE02、E05、E07、E09、E10の5件で、成功4件、拒否1件。E07とE09はE06のパスワード変更後で、E09はE08の失効要求後でもあります。E04は既存セッションのE05を止めていません。E10は1件のアプリの拒否で、ほかのセッションの状態は示しません。E05に完了や量の情報はありません。

身に覚えのない要求、復旧方法の変更、出力の状況を所定の手順で相談し、証跡を保全して想定された活動かを確認します。人物、出力完了、全体のセッション状態は不明です。IPは文書用の例なので、脅威の指標として遮断・照会してはいけません。

実績の表現：架空のロールと対象範囲のポリシーを評価し、IDとアプリの観測を照合し、セッションの封じ込めの限界を説明した。実環境の管理・調査を行ったという表現は、実際に経験した場合だけにしてください。