最小権限の原則
Principle of Least Privilege ・ さいしょうけんげんのげんそく
必要最小限の権限だけを与えるという原則。被害の範囲を権限の範囲に閉じ込める。
✦ 30秒で試す — 航海侵入の手口より先に、被害の大きさは決まっている攻撃者が手を出せる資源はいくつ？予想してみる概要
最小権限の原則（Principle of Least Privilege）は、ユーザー・プログラム・システムに対して「その仕事を果たすのに必要な最小限の権限だけを与える」という設計原則です。読み取りだけでよいなら書き込み権限を与えない、このテーブルだけでよいならデータベース全体への権限を与えない、今日だけでよいなら無期限の権限を与えない — 対象・操作・期間のすべてで「必要な分だけ」に絞ります。
核心はひとつの等式に集約できます。被害範囲 = 権限範囲。アカウントが乗っ取られたとき、プログラムが乗っ取られたとき、あるいは単に操作を間違えたとき、起こりうる被害はその主体が持っていた権限の範囲にぴったり一致します。攻撃を完全に防ぐことはできなくても、権限を絞っておけば「起きたときの最悪」を設計時点で小さくできる。防御的セキュリティの中で最も費用対効果が高く、最も普遍的に適用できる原則です。
なぜ生まれたか
この原則は1975年、Saltzer と Schroeder の論文 “The Protection of Information in Computer Systems” で、保護機構を設計するための8つの原則のひとつとして定式化されました。8つとは、機構の経済性（仕組みは小さく単純に）、フェイルセーフなデフォルト（既定は拒否）、完全な仲介（すべてのアクセスを毎回確かめる）、公開設計（秘密を設計の隠蔽に頼らない）、権限の分離（鍵を2本に分ける）、最小権限、最小共通機構（利用者間で共有する仕組みを減らす）、心理的受容性（使いやすくなければ迂回される）です。半世紀前のメインフレーム時代の論文ですが、どれもクラウドやコンテナの設計にそのまま通用します。技術は移り変わっても、「守る」ことの構造は変わらないからです。
背景にあった問題意識は、複数の利用者・プログラムが一台の計算機を共有する時代に、「全員がすべてに触れる」状態では一人のミスや一つの悪意がシステム全体を壊してしまう、というものでした。認可の仕組み（誰に何を許すかを制御する機構）が整備されるにつれ、「では、どれだけ許すべきか」という設計方針が必要になり、その答えとして「必要最小限」が原則化されたのです。論文は軍の「知る必要のある者だけが知る（need to know）」という考え方を、計算機のプログラムと利用者に当てはめたものだと説明しています。逆に言えば、認可機構がどれだけ精巧でも、運用で全員に管理者権限を配ってしまえば機構は無意味になります。最小権限は、認可という機構に魂を入れる運用原則だと言えます。
詳細
権限範囲がそのまま被害範囲になる
抽象的な原則なので、まず「権限を絞る」ことが何を変えるのかを図で押さえます。
左のように「面倒だから admin で」運用していると、フィッシングによるアカウントの乗っ取り・SQLインジェクション一箇所・サプライチェーン攻撃による依存汚染一件が、そのまま全システムの侵害に直結します。右のように役割ごとに権限を絞っていれば、同じ侵害が起きても攻撃者が到達できるのは許可済みの範囲だけです。防げなかった攻撃の被害を設計で限定する — これが最小権限の価値です。侵入の経路は何でもかまいません。どこから入られても、到達できる範囲は権限の範囲で決まります。
過剰権限が生まれる力学
原則としては誰も反対しないのに、現実のシステムは過剰権限だらけです。それには構造的な理由があります。権限が足りないとエラーが出て仕事が止まるため、すぐ気づいて広げられます。一方、権限が余分でもエラーは出ないため、誰も気づかず永遠に残ります。「とりあえず admin を付けたら動いた」「退職者のアカウントが残っていた」「一時対応で付けた権限を戻し忘れた」— 権限は一方向にしか動かない力学の中にあり、放置すれば単調に増えていきます。
下の部品で確かめてください。「とりあえず」7つの権限を持たされたバッチを攻撃者に乗っ取らせ、権限の線を1本ずつ外していきます。外すたびに夜の業務が試運転されるので、どの線が本当に要るのか、余分な線を外したときに何が起きないのかが分かります。
夜間集計バッチには、作った人が「とりあえず動くように」と7つの権限を付けました。依存ライブラリの汚染でこのバッチが乗っ取られたとします。攻撃者の駒をドラッグして、バッチのアカウントに落としてください。
部品で見たとおり、必要な権限を外すと業務はその場で止まり、余分な権限を外しても何も起きません。この非対称こそが、放っておくと権限が増える一方になる理由です。
実践の場面 — 人・プログラム・インフラ
この原則は、権限という概念があるあらゆる場所に適用できます。人に対しては RBAC（ロールベースアクセス制御）が代表で、個人に個別権限を配るのではなく「経理」「開発者」「閲覧者」といった役割に権限を束ね、人には役割を割り当てます。ロールごとに与える権限を必要最小限に絞ることで、原則が組織の規模でも保たれます。クラウドの IAM ではさらに細かく、「このサーバは、このストレージバケットの読み取りだけができる」というリソース単位のポリシーを書きます。
プログラムに対しても同様です。アプリケーションが使うデータベースユーザーには、RDBMS の GRANT で必要なテーブルへの必要な操作だけを許可します。参照系のバッチに DROP 権限は要りません。これは SQLインジェクションを食らったときの被害を直接左右します。コンテナは root で実行せず専用の非特権ユーザーで動かし、Kubernetes ではワークロードに割り当てるサービスアカウント（ServiceAccount）の権限を RBAC で絞ります。OS 上のプロセスを専用ユーザーで動かすのも、CI/CD のジョブに絞ったデプロイ権限だけを与えるのも、すべて同じ原則の適用です。
棚卸しと JIT アクセス
権限が放っておくと増える一方である以上、最小権限は一度の設定ではなく継続的な運用です。定期的な権限の棚卸し（アクセスレビュー）で「この権限は直近◯か月使われたか」を確認し、未使用権限を削ります。クラウドの監査ログから実際に使われた操作を集計し、ポリシーを実績ベースに絞り込むツールも各社が提供しています。さらに進んだ形が JIT（Just-In-Time）アクセスで、強い権限は常時付与せず、必要になったときに申請して短時間だけ借り、自動で失効させます。「常時 admin を持つ人はゼロ」を現実にする仕組みです。
ゼロトラストと多層防御の土台
最小権限は単独の技術ではなく、他の防御の前提になる考え方です。ゼロトラストは「すべてのアクセスを毎回検証する」モデルですが、検証の結果として与える権限が過剰では意味がなく、最小権限はその土台にあたります。シークレット管理における短命な動的シークレットは、最小権限を「期間」の軸に適用したものです。設計レビューで「この権限は本当に要るのか」と問い続けること — 地味ですが、それがこの原則の実践のすべてです。
試問
夜間集計バッチ（毎晩自動で動くプログラム）から、作った人が「とりあえず動くように」付けた7つの権限の線が、7つの資源へ伸びています。攻撃者の駒をバッチに落とすと乗っ取られ、線か資源のカードをタップすると権限を外せます（もう一度タップで戻ります）。外すたびに、夜の3つの業務が試運転されます。
夜間集計バッチには、作った人が「とりあえず動くように」と7つの権限を付けました。依存ライブラリの汚染でこのバッチが乗っ取られたとします。攻撃者の駒をドラッグして、バッチのアカウントに落としてください。