最小権限の原則と多層防御

最小権限とは何か（PoLP）

最小権限の原則（Principle of Least Privilege, PoLP）は、ユーザー・プログラム・サービスに対して「やるべき仕事を遂行できるギリギリの権限」だけを与え、それ以上は与えないという設計指針です。逆のアンチパターンが「面倒だから全部入り」――開発者アカウントに Administrator、アプリのDBユーザーに全テーブルへの全操作権、コンテナを root で起動、といった**過剰権限（over-privilege）**です。

なぜ問題かというと、権限は「もし漏れたら何ができるか」の上限そのものだからです。鍵が1本漏れたとき、その鍵が「自分の机の引き出し」しか開けないのか、「ビル全体のマスターキー」なのかで、事故の規模はまったく変わります。最小権限は、漏れる確率を下げるのではなく、漏れたときの被害の天井を下げる対策だと理解するのが肝心です。

なぜ効くのか：被害範囲（Blast Radius）の最小化

セキュリティの世界では「侵入されない」を100%保証することはできません。フィッシングでパスワードが抜かれる、ライブラリの脆弱性を突かれる、鍵を誤って公開する――どれかは起こり得ます。だからこそ「破られた後にどこまで広がるか」を設計で抑えます。これが**被害範囲（Blast Radius）**の最小化です。

最小権限が効くのは、まさにこの「広がり」を物理的に止めるからです。たとえば、あるWebアプリの認証情報が漏れたとして――

• 過剰権限の場合：そのアプリのDBユーザーが全テーブルにアクセスできれば、漏れた瞬間に全ユーザーの個人情報が抜かれます。
• 最小権限の場合：そのアプリが触れるのが「自分のスキーマの数テーブルだけ」なら、被害もそのテーブルの範囲に閉じます。

同じ「侵入」でも、結果が「全社データ流出」か「一部テーブルの参照」かは桁違いです。

多層防御（Defense in Depth）：壁は一枚にしない

最小権限が「1層の質」を上げる話なら、多層防御（Defense in Depth）は「層の数」を増やす話です。発想は「どんな単一の防御もいつかは破られる。なら独立した防御を直列に重ね、全部を同時には破れない状態にする」というもの。城の堀・城壁・門・天守を何重にも構えるのと同じ発想です。

重要なのは、各層が異なる原理で守っていることです。同じ仕組みを2回置いても、同じ攻撃で両方抜かれます。たとえばWebアプリなら、こんな層が重なります。

最小権限と多層防御の関係

混同しがちですが、両者は対立ではなく補完です。位置づけを整理します。

実務では両方を使います。多層防御という大きな設計の中に、各層を支える具体策として最小権限が組み込まれる、という関係です。次節からは、その最小権限を「IAM」「ネットワーク」「スコープ」の3つの代表的な場面で具体化します。

具体例1：IAM（クラウドの権限）

クラウドでの最小権限の主戦場が IAM（Identity and Access Management）です。ありがちなのは、S3 の1バケットを読みたいだけのアプリに、全 S3・全アクションを許してしまう例です。

// ❌ 悪い例：S3 に対して全アクション・全リソースを許可
// 鍵が漏れれば、全バケットの作成・読み取り・削除がやり放題
{
  "Effect": "Allow",
  "Action": "s3:*",
  "Resource": "*"
}

// ✅ 良い例：必要な「読み取り」だけを「特定バケット」に限定
// 漏れても、被害はこのバケットの参照に閉じる
{
  "Effect": "Allow",
  "Action": ["s3:GetObject"],
  "Resource": "arn:aws:s3:::my-app-assets/*"
}

ポイントは3つです。(1) アクションを絞る（s3:* ではなく s3:GetObject のように必要な動詞だけ）。(2) リソースを絞る（* ではなく対象のARNだけ）。(3) 人ではなくロールに権限を持たせる――アプリには長期アクセスキーを埋め込まず、サーバやコンテナにIAMロールを割り当て、自動で短期の一時認証情報を使わせます。これで「漏れる鍵」自体を減らせます。

具体例2：ネットワーク分離

権限は「データやAPIへのアクセス」だけでなく「ネットワーク的な到達可能性」にも適用できます。「触れる必要がないものには、そもそもネットワーク的に到達させない」――これも最小権限の一形態です。

典型は 3層構成です。インターネットに面するのはロードバランサ（公開サブネット）だけにし、アプリサーバとDBはプライベートサブネットに置いてインターネットから直接到達できなくします。さらにセキュリティグループ（仮想ファイアウォール）で「誰から・どのポートへ」を絞ります。

こうすると、仮にアプリサーバが乗っ取られても、攻撃者はDBの決まったポートにしか到達できず、外部への自由な通信（情報持ち出しや横展開）も制限できます。DBがインターネットに直接晒されていれば総当たりや既知脆弱性を直接突かれますが、プライベートに隔離してあれば、まず内部に侵入しないと届きません。**「到達できないものは攻撃できない」**という素朴な強さです。

具体例3：最小スコープ（DB・トークン）

最後は、より細かい単位での「スコープ（権限の範囲）」の最小化です。IAMやネットワークと同じ原則を、DBユーザーやアクセストークンに適用します。

DBユーザーの権限を例にとると、参照しかしないアプリに、テーブルを書き換え・削除できる権限まで渡す必要はありません。

-- ❌ 悪い例：アプリ用ユーザーに何でもできる権限を付与
-- SQLインジェクションを食らうと DROP TABLE まで通ってしまう
GRANT ALL PRIVILEGES ON app_db.* TO 'app_user'@'%';

-- ✅ 良い例：必要な操作だけを必要なテーブルに限定
-- 参照系サービスなら SELECT だけ。書き込みが要る機能は別ユーザーに分ける
GRANT SELECT ON app_db.products TO 'readonly_user'@'10.0.%';
GRANT SELECT, INSERT, UPDATE ON app_db.orders TO 'order_service'@'10.0.%';

権限を絞っておくと、万一 SQLインジェクションを許してもできることが SELECT の範囲に制限され、DROP TABLE や他テーブルの改ざんといった致命傷を防げます（もちろん SQLの基本を踏まえたプリペアドステートメントでの根本対策が大前提で、権限制限はその「次の壁」です）。

OAuth のアクセストークンのスコープも同じ発想です。プロフィール表示しかしないアプリが、メール送信や全データ削除の権限まで要求するのは過剰です。read:profile だけを要求すれば、トークンが漏れてもできるのはプロフィール参照だけ。認可の仕組みそのものは認証と認可・Web認証で扱うとおりですが、**「要求するスコープを最小にする」**こと自体が最小権限の実践です。

まとめ：絞って、重ねる

最小権限と多層防御は、別々の技で覚えるより「ひとつの設計思想の両輪」として捉えると腑に落ちます。

• 最小権限＝主体ごとに「できること」を必要最小限に絞る。狙いは破られた後の被害範囲（Blast Radius）の最小化。
• 多層防御＝性質の違う防御を直列に重ねる。狙いは全部を同時には破らせないこと。
• 両者は補完関係。多層防御の各層を、最小権限で堅くするのが現実的な強さになる。

実務での合言葉は「まず拒否、必要な分だけ許可（deny by default）」と「壁は一枚にしない」。IAMもネットワークもDBもトークンも、同じ原則の繰り返しです。次は、この「内側だから安全とは限らない」という前提を突き詰めたゼロトラスト、あるいは個々の攻撃面である SQLインジェクション・XSS・CSRFに進むと、各層が何から守っているのかがより立体的に見えてきます。