最小権限の原則
利用者・プログラム・プロセスに、仕事に必要な最小限の権限だけを与えるという、セキュリティ設計の基本原則です（英語では Principle of Least Privilege）。
定義
NIST の用語集は、複数の文書の定義を載せています。
- システムは、利用者（とその代わりに動くプロセス）のアクセス権限を、割り当てられた業務を果たすのに必要な最小限に制限すべきだとする原則（CNSSI 4009-2022、NIST SP 800-12 Rev. 1）
- セキュリティアーキテクチャを、各主体に最小限の資源と権限だけを与えるように設計するという原則（NIST SP 800-53 Rev. 5、NIST SP 800-171r3）
なぜ大事か
権限は、侵害されたときの被害の上限を決めます。
- 乗っ取られたアカウントや、悪用されたプログラムは、持っている権限の範囲でしか動けない
- 内部の人による誤操作や不正も、権限の範囲に閉じ込められる
- 責任追跡性：権限が役割ごとに分かれていれば、誰が何をしたかを追いやすい
実装のしかた
- 役割で与える：人ではなく役割に権限を結びつける（RBAC）。属性で細かく決める方法もある（ABAC）
- 普段使いと管理用を分ける：管理者権限は、作業のときだけ使う別のアカウントにする
- 必要なときだけ引き上げる：普段の管理作業では、作業の間だけ権限を与えて期限が来たら戻す（Just-In-Time）。障害時などの緊急用には、別に厳しく管理した手順を用意する（break-glass）。どちらも記録を残し、事後に点検する
- 定期的に見直す：異動・退職・役割の変更で、不要になった権限を外す（棚卸し）
- プログラムにも適用する：サービス用のアカウントや API キー、コンテナ、そして AI に渡すツールの権限も最小にする（AIを悪用した攻撃）
つまずきやすい点
- 「念のため」の広い権限は、平時には問題に見えないが、侵害されたときに被害を大きくする
- 最小権限は「権限をなくす」ことではない。業務が止まるほど絞ると、例外の運用が増え、かえって管理が崩れる
- 知る必要性（need to know）は、最小権限をデータの単位まで細かくした考え方
関連するページ
出典
確認日：2026年10月14日
最終更新：2026年10月15日 09:54
