最小権限の原則

概要

最小権限の原則（Principle of Least Privilege）は、ユーザー・プログラム・システムに対して「その仕事を果たすのに必要な最小限の権限だけを与える」という設計原則です。読み取りだけでよいなら書き込み権限を与えない、このテーブルだけでよいならデータベース全体への権限を与えない、今日だけでよいなら無期限の権限を与えない — 対象・操作・期間のすべてで「必要な分だけ」に絞ります。

核心はひとつの等式に集約できます。被害範囲 = 権限範囲。アカウントが乗っ取られたとき、プログラムが乗っ取られたとき、あるいは単に操作を間違えたとき、起こりうる被害はその主体が持っていた権限の範囲にぴったり一致します。攻撃を完全に防ぐことはできなくても、権限を絞っておけば「起きたときの最悪」を設計時点で小さくできる。防御的セキュリティの中で最も費用対効果が高く、最も普遍的に適用できる原則です。

なぜ生まれたか

この原則は1975年、Saltzer と Schroeder の論文 “The Protection of Information in Computer Systems” で、セキュアな設計の基本原則のひとつとして定式化されました。半世紀前のメインフレーム時代の論文ですが、挙げられた原則群（最小権限、フェイルセーフなデフォルト、多層防御など）は現代のクラウドやコンテナの設計にそのまま通用します。技術は移り変わっても、「守る」ことの構造は変わらないからです。

背景にあった問題意識は、複数の利用者・プログラムが一台の計算機を共有する時代に、「全員がすべてに触れる」状態では一人のミスや一つの悪意がシステム全体を壊してしまう、というものでした。認可の仕組み（誰に何を許すかを制御する機構）が整備されるにつれ、「では、どれだけ許すべきか」という設計方針が必要になり、その答えとして「必要最小限」が原則化されたのです。逆に言えば、認可機構がどれだけ精巧でも、運用で全員に管理者権限を配ってしまえば機構は無意味になります。最小権限は、認可という機構に魂を入れる運用原則だと言えます。

詳細

権限範囲がそのまま被害範囲になる

抽象的な原則なので、まず「権限を絞る」ことが何を変えるのかを図で押さえます。

左のように「面倒だから admin で」運用していると、フィッシング一通・SQLインジェクション一箇所・サプライチェーン攻撃による依存汚染一件が、そのまま全システムの侵害に直結します。右のように役割ごとに権限を絞っていれば、同じ侵害が起きても攻撃者が到達できるのは許可済みの範囲だけです。防げなかった攻撃の被害を設計で限定する — これが最小権限の価値です。

実践の場面 — 人・プログラム・インフラ

この原則は、権限という概念があるあらゆる場所に適用できます。人に対しては RBAC（ロールベースアクセス制御）が代表で、個人に個別権限を配るのではなく「経理」「開発者」「閲覧者」といった役割に権限を束ね、人には役割を割り当てます。クラウドの IAM ではさらに細かく、「このサーバは、このストレージバケットの読み取りだけができる」というリソース単位のポリシーを書きます。

プログラムに対しても同様です。アプリケーションが使うデータベースユーザーには、RDBMS の GRANT で必要なテーブルへの必要な操作だけを許可します。参照系のバッチに DROP 権限は要りません。これは SQLインジェクションを食らったときの被害を直接左右します。コンテナは root で実行せず専用の非特権ユーザーで動かし、Kubernetes では ServiceAccount の権限を RBAC で絞ります。OS 上のプロセスを専用ユーザーで動かすのも、CI/CD のジョブに絞ったデプロイ権限だけを与えるのも、すべて同じ原則の適用です。

過剰権限が生まれる力学と、棚卸し

原則としては誰も反対しないのに、現実のシステムは過剰権限だらけです。それには構造的な理由があります。権限が足りないとエラーが出て仕事が止まるため、すぐ気づいて広げられます。一方、権限が余分でもエラーは出ないため、誰も気づかず永遠に残ります。「とりあえず admin を付けたら動いた」「退職者のアカウントが残っていた」「一時対応で付けた権限を戻し忘れた」— 権限は一方向にしか動かない力学の中にあり、放置すれば単調に増えていきます。

だからこそ、最小権限は一度の設定ではなく継続的な運用です。定期的な権限の棚卸し（アクセスレビュー）で「この権限は直近◯か月使われたか」を確認し、未使用権限を削ります。クラウドの監査ログから実際に使われた操作を集計し、ポリシーを実績ベースに絞り込むツールも各社が提供しています。さらに進んだ形が JIT（Just-In-Time）アクセスで、強い権限は常時付与せず、必要になったときに申請して短時間だけ借り、自動で失効させます。「常時 admin を持つ人はゼロ」を現実にする仕組みです。

ゼロトラストと多層防御の土台

最小権限は単独の技術ではなく、他の防御の前提になる考え方です。ゼロトラストは「すべてのアクセスを毎回検証する」モデルですが、検証の結果として与える権限が過剰では意味がなく、最小権限はその土台にあたります。シークレット管理における短命な動的シークレットは、最小権限を「期間」の軸に適用したものです。設計レビューで「この権限は本当に要るのか」と問い続けること — 地味ですが、それがこの原則の実践のすべてです。