Step 5の入口——安全性の本丸を開ける
ここからはStep 5、安全性の学習に入ります。カテゴリAの最後、A-09で危険な変更を扱ったとき、認証や権限の詳細は「カテゴリQで」とお伝えしました。いよいよその本丸を開きます。安全性を支える柱はいくつもありますが、最初に押さえるべきは、すべての土台となる認証と認可の区別です。この2語が曖昧なままだと、この先に積み上げる対策が、どれも空回りしてしまいます。
このスライドのポイント
- ここからStep 5、安全性の学習に入る
- A-09で「詳細はカテゴリQで」と送った、危険な変更の中心がここ
- 最初に押さえるのは、すべての土台となる認証と認可の区別
- この2語が曖昧だと、この先の対策がすべて空回りする
定義——誰か（認証）と、してよいか（認可）
まず定義です。認証、英語でAuthenticationとは、あなたは誰か、を確認することです。ログインがこれにあたります。認可、英語でAuthorizationとは、その確認できた人が、何をしてよいか、を判断することです。A-08で決めた権限を、実行時に判定する工程だと考えてください。順序は必ず認証が先、認可が後です。誰かを確かめてからでないと、その人に何を許すかは決められないからです。そしてD-06で学んだ401は認証の失敗、403は認可の失敗でした。この2つの応答コードは、まさにこの2段階に対応していたのです。
このスライドのポイント
- 認証（Authentication）＝あなたは誰か、の確認（ログイン）
- 認可（Authorization）＝その人は何をしてよいか、の判断（A-08で決めた権限の実行時判定）
- 順序は必ず認証→認可（誰かを確かめてからでないと、何を許すか決められない）
- D-06の401＝認証の失敗、403＝認可の失敗
なぜ必要か——「ログインさえあれば安全」の誤解
なぜこの区別が重要なのでしょうか。最も多い誤解は「ログインさえあれば安全」というものです。認証だけを実装して認可を忘れると、ログインした人であれば誰でも、あらゆるデータを見られる状態になってしまいます。しかも、AIに生成させたコードには、この認証だけで認可が抜けた形が非常に多く現れます。自分の中に認証と認可の区別がないと、その抜けを見抜くことができません。だからこそ、コードを書く前に、まず言葉の区別を持っておくことが守りの第一歩になります。
このスライドのポイント
- 最頻出の誤解＝「ログインさえあれば安全」
- 認証だけで認可がないと、ログインした誰もが全データを見られる
- AIが生成するコードにも、この認可の抜けが非常に多い
- 区別を持っていないと、その抜けに気づけない
構造——2段の門
構造を、2段の門としてイメージしてください。第1の門が認証で、本人確認をします。第2の門が認可で、操作ごとに許可してよいかを判定します。第1の門を通ったからといって、第2の門を素通りできるわけではありません。第2の門は、操作のたびに別途チェックが必要です。J-05で見たミドルウェアは、この第1の門である認証にあたります。J-06で学んだ検証6点のうちの「権限」の確認が、第2の門である認可にあたります。すでに学んだ道具が、ここで安全性の言葉に置き換わるわけです。
このスライドのポイント
- 第1の門: 認証＝本人確認
- 第2の門: 認可＝操作ごとの許可判定
- 第1の門を通っても、第2の門は操作のたびに別途チェックが必要
- J-05のミドルウェア＝認証、J-06の検証6点の「権限」＝認可
処理の流れ——経費アプリで見る認可の抜け
経費アプリで具体化します。ログイン済み、つまり認証を通った一般社員がいるとします。この社員が、他人の申請を承認するためのAPIを、画面を経由せず直接呼び出したらどうなるでしょうか。D-03で学んだとおり、リクエストは画面のボタンがなくても送れます。J-06の信頼境界を思い出してください。もし承認のAPIに認可の判定がなければ、この承認リクエストは通ってしまいます。I-01で確認したように、画面に承認ボタンを表示しないことは、防御にはなりません。ボタンの有無ではなく、サーバー側で認可を判定しているかどうかが、唯一の守りになります。
このスライドのポイント
- ログイン済み（認証OK）の一般社員が、他人の申請を承認するAPIを直接呼ぶ
- D-03のとおり、リクエストは画面のボタンが無くても送れる（J-06の信頼境界）
- 認可の判定が無ければ、この承認は通ってしまう
- 「画面にボタンが無い」は防御ではない（I-01）。サーバー側の認可判定だけが守り
技術サンプル——エンドポイント別の認証・認可監査
スライドのサンプルは、2段の門と401、403の対応を表した構成図です。目的は、各エンドポイントで認証と認可がそれぞれどこで行われているかを可視化することです。読み方の要点は2つあります。1つ目は、認証を通っても認可は操作ごとに別だという点。2つ目は、401と403が、その2段の失敗をそれぞれ表す点です。AIには「このAPIの各エンドポイントについて、認証の確認と認可の判定がそれぞれどこで行われているか表にしてください」と聞いてみましょう。表にすると、認可が抜けているエンドポイントが一目でわかります。
混同しやすい概念——認証と認可
混同しやすい点を対比します。認証は「誰か」を確かめること、認可は「してよいか」を判断することです。ログイン機能を実装した、という状態は、認証だけができた状態にすぎません。認可は、承認・閲覧・削除といった操作ごとに、別途つくり込む必要があります。ログインを作ったから安全、ではなく、操作ごとの認可があってはじめて守られる、と覚えてください。
バイブコーディングでの確認点
バイブコーディングでの確認点です。AIに機能を作らせたら、必ず「この操作の認可判定はどこですか。ログインだけで通ってしまいませんか」を、すべてのエンドポイントで確認してください。これは、J-06で学んだ6点監査のうち「権限」の確認そのものです。とくに、データを変更したり、他人の情報に触れたりするAPIでは、この一問を決して省かないでください。認可の抜けは、AIが最も作り込み忘れやすい箇所だからです。
このスライドのポイント
- AIに機能を作らせたら、全エンドポイントで「この操作の認可判定はどこですか。ログインだけで通りませんか」を確認
- これはJ-06の6点監査の「権限」の本体
- とくにデータ変更・他人の情報に触れるAPIでは、この一問を省かない
一問一答とまとめ
最後に一問一答です。401と403は、それぞれ何の失敗を表すでしょうか。……答えは、401が認証の失敗、403が認可の失敗です。30秒でまとめます。認証は「誰か」の確認、認可は「してよいか」の判断で、順序は必ず認証が先です。401と403はその2段の失敗の応答であり、ログインだけでは認可の代わりにはなりません。次回は、その認証の土台であるパスワードを、どう安全に守るかを学びます。関連資料は「AIアプリのセキュリティ超入門」と「セキュリティ用語50」です。
このスライドのポイント
- 一問一答: 401と403はそれぞれ何の失敗？
- 30秒まとめ: 認証＝誰か、認可＝してよいか、順序は認証→認可。401/403はその2段の失敗
- 次回: 認証の土台、パスワードの守り方へ
- 関連資料: 「AIアプリのセキュリティ超入門」「セキュリティ用語50」
