いつか必ず聞かれる問い

• 「この求人を消したのは誰ですか」
• 「私の情報を見た人はいますか」
• 「漏れたトークンで、何をされましたか」

どれも、事が起きる前から記録していなければ答えられません。記録はあとから足せますが、足す前の分は戻りません。だから、認証・認可を作るときに一緒に決めます。

何を残すか

naminori の例：AI 接続の操作ログ

naminori の管理者向け・会員向けの AI 接続では、操作ログを次のように残しています。

• リクエストごとに1件。認証の失敗や権限による拒否も記録する
• 操作の種類・対象・件数・結果・接続元を残す
• 個人情報に触れた操作かどうかを記録する
• 引数の中の個人情報や秘密の値は伏せて残す。メールを送る操作は、引数そのものを残さない
• 接続（鍵）を消しても、ログは消えずに残る

後から困ること

• 成功した操作だけを残す。 拒否された試みが見えないので、誰かが権限の外を探っていても気づけません
• 中身をそのまま書く。 パスワード・トークン・個人情報がログに残ると、ログが漏れたときの被害がそのまま大きくなります。ログは本番のデータより多くの人が見ることが多いので、なおさらです
• アカウントを消すとログも消える作りにする。 一番調べたいとき（不正なアカウントを止めたあと）に、記録が消えています
• 本人に知らせない。 「自分はやっていない」と気づけるのは本人だけです。naminori では、二段階認証の有効・無効が切り替わったら本人にメールで知らせています（第4回）

この講座のまとめ

• 認証と認可を分け、入ってくる主体と入口を最初に数える
• トークンは有効期限と止め方を先に決める。JWT の中身は読める
• パスワードは後から強くできる形で保存し、試行の制限で本人を締め出さず、登録の有無を漏らさない
• 多要素認証は、全部の入口と、失くした日の復旧まで決めてから出す
• 外部のアプリには、パスワードではなく範囲を絞った鍵を、認可コード＋PKCEで渡す
• 判定は「操作をしてよいか」を1か所で聞き、既定は拒否
• 特権は普通の権限と分け、代理ログインは本人と区別する
• 誰が・いつ・何をしたかを、拒否も含めて、中身を伏せて残す

• 後から聞かれる問いと、記録が要る理由
• 監査ログに残す項目
• naminori の AI 接続の操作ログ
• 記録の作り方で後から困ること
• 講座のまとめ