前回との接続——外からの攻撃から、内なる秘密へ
前回のQ-07では、XSS・CSRF・SQLインジェクションという、入力が命令として作動してしまう攻撃を見ました。あれは、外から来る入力への守りでした。今回向き合うのは、アプリ自身が内側に抱える秘密、たとえば外部サービスを呼び出すためのAPIキーです。B-09で環境変数、K-05でAPIキー、O-07でpush前の確認を積み上げてきましたが、この講義でそれらを、一本の運用の型としてまとめ上げます。
このスライドのポイント
- Q-07: XSS・CSRF・SQLインジェクションは「外から来る入力」への守りだった
- 今回向き合うのは、アプリ自身が内側に抱える秘密（外部サービスを呼ぶAPIキー等）
- B-09の環境変数・K-05のAPIキー・O-07のpush前確認を、一本の運用の型にまとめる
秘密管理の4原則
秘密管理には4つの原則があります。第一に、コードに書かないこと。鍵の値はB-09で学んだ環境変数へ逃がします。第二に、履歴に入れないこと。O-02のgitignoreで対象外にし、O-07のpush前確認で混入を止めます。第三に、権限最小化です。そのキーができることを必要最小限に絞り、読み取りだけでよいなら読み取り専用の鍵を使います。第四に、失効とローテーションです。漏れたときに即座に無効化できる手順を用意し、平時も定期的に交換します。この4つが揃って初めて、秘密は守られます。
このスライドのポイント
- ①コードに書かない → 値はB-09の環境変数へ逃がす
- ②履歴に入れない → O-02のgitignoreで対象外にし、O-07のpush前確認で混入を止める
- ③権限最小化 → そのキーができることを必要最小限に絞る（読み取りだけでよいなら読み取り専用の鍵）
- ④失効（ローテーション） → 漏れたら即無効化できる手順を持ち、平時も定期的に交換する
なぜ必要か——漏れた瞬間に被害が広がる
これを知らないと、鍵が漏れた瞬間に何をすべきか分からず、被害だけが広がります。公開された場所に置かれた鍵は、数分のうちに悪用されるといわれる世界です。とくに権限最小化を知らないまま、何でもできる万能な鍵を一本だけ使っていると、その一本が漏れただけで、全ての操作を他人に許すことになります。鍵の管理は、作るときの便利さよりも、漏れたときの被害の小ささで考える必要があります。
このスライドのポイント
- 知らないと: 鍵が漏れた瞬間に何をすべきか分からず、被害だけが広がる
- 公開された場所に置かれた鍵は、数分で悪用されるといわれる世界
- 権限最小化を知らず「何でもできる万能な鍵1本」だと、その1本の漏えいで全操作を許す
構造——4原則と、漏えい時の初動フロー
構造を整理します。4つの原則は、コードの外、履歴の外、最小の権限、失効の手順、という4枚の守りです。そして、それでも漏れてしまったときのために、初動の流れを決めておきます。順番は、まず即座に失効させ、次に新しい鍵を発行し、それから影響を調査し、最後に再発を防ぐ、の4段です。影響調査では、いつから使われ何ができたのかを確かめますが、その記録の仕組みはカテゴリSで扱います。ここでは、漏れたら真っ先に失効、という順番だけ体に入れてください。
このスライドのポイント
- 4原則＝コードの外・履歴の外・最小の権限・失効の手順、という4枚の守り
- それでも漏れたときの初動フロー: ①即失効 → ②新キー発行 → ③影響調査 → ④再発防止
- 影響調査（いつから・何ができたか）の記録の仕組みはカテゴリSで扱う
具体例——誤ってpushした鍵は「消すコミット」では消えない
経費アプリで具体的に見ましょう。レシートを読み取るために使う、K-05のOCR用APIキーを、誤ってコミットしてpushしてしまったとします。ここで多くの人が、その鍵を消す新しいコミットを重ねれば安全だと考えます。しかしO-01で見たとおり、gitの履歴は過去を書き換えず積み上げる性質を持つため、消したはずの鍵は過去のコミットの中に残り続けます。つまり、消すコミットでは消えません。漏れた鍵に対して有効な手はただ一つ、その鍵そのものを失効させ、新しい鍵に取り替えることだけです。
このスライドのポイント
- 経費アプリのOCR用APIキー（K-05）を、誤ってコミットしてpushした場合
- 「消す新しいコミット」を重ねても、O-01のとおりgit履歴は過去を書き換えず積み上げる
- 消したはずの鍵は過去のコミットに残り続ける＝消すコミットでは消えない
- 有効な手はただ一つ: その鍵を失効させ、新しい鍵に取り替える
技術サンプルカード——秘密の棚卸し表
サンプルは、秘密の棚卸しに使う確認表です。種別は表、目的は、自分のアプリの秘密が4原則を満たすかを点検することです。表には、4原則それぞれに対応する確認の質問と、漏えい時の初動フローを並べています。読み方のポイントは二つ。原則ごとに「はい」と即答できない項目が、いま危ない箇所だということ。そして初動フローは、事故後に考えるのでは遅いので、平時に眺めておくものだということです。
混同しやすい概念——「履歴から削除」と「失効」
混同しやすいのが、履歴から削除したことと、失効したことの違いです。履歴から削除した、あるいは消すコミットを重ねたというのは、見えにくくなっただけで、鍵そのものはまだ使える状態です。一方、失効したというのは、その鍵を発行元で無効化し、もう誰が使っても通らなくした状態です。漏れた秘密の対処は、失効一択です。見えにくくする対処は、対処になっていないと覚えてください。
バイブコーディングでの確認点——月次の棚卸し
バイブコーディングでの確認点です。秘密は放っておくと増え、古くなります。そこで、このアプリが持つ秘密は何本あり、それぞれ最後に交換したのはいつか、という棚卸しを、AIとともに月に一度おこないます。これはO-09で学んだ依存関係の点検とセットにすると、運用の習慣として定着します。質問例は、このプロジェクトの秘密を一覧にして、最終交換日と権限の範囲を表にして、というものです。指定がなければAIは万能な鍵を使いがちなので、最小権限を明示するのも忘れないでください。
このスライドのポイント
- 秘密は放置すると増え、古くなる → 月に一度、AIと棚卸しする
- 定型質問「このアプリが持つ秘密は何本で、それぞれ最後に交換したのはいつか」
- O-09の依存点検とセットにして運用習慣に
- 指定がなければAIは万能な鍵を使いがち → 最小権限を明示する
一問一答とまとめ
最後に一問一答です。鍵が漏えいしたときの、最初の一手は何でしょうか。……答えは、失効です。無効化することであり、削除やコミット消しでは防げません。30秒でまとめます。秘密管理の4原則は、コードに書かない、履歴に入れない、権限を最小化する、失効の手順を持つ、そして漏れたら失効一択です。B-09の環境変数、K-05のAPIキー、O-07のpush前確認が、ここで一つの運用の型に完成しました。次回Q-09では、預かる側の責任、個人情報の扱いへ進みます。
このスライドのポイント
- 一問一答: 「キーが漏えいしたときの最初の一手は？」→ 失効（無効化。削除やコミット消しでは防げない）
- 30秒まとめ: 4原則＝コード外・履歴外・最小権限・失効手順／漏れたら失効一択
- 縦串の完成: B-09（環境変数）→K-05（APIキー）→O-07（push前確認）が運用の型に
- 次回Q-09: 預かる側の責任、個人情報へ
- 関連資料: 「環境変数・APIキー管理入門」「AIアプリのセキュリティ超入門」
