最小権限の原則

最小権限の原則とは

最小権限の原則(Principle of Least Privilege)は、利用者やプログラムには、業務に必要な最小限の権限だけを与えるという考え方です。セキュリティ設計でもっとも古く、もっとも効果の高い原則のひとつです。

ねらいは攻撃を防ぐことだけではありません。むしろ本命は被害範囲を小さくすることです。

• アカウントが乗っ取られても、そのアカウントにできる範囲までしか荒らされない
• 操作ミスによる削除も、権限のない領域には及ばない
• 脆弱性を突かれても、そのプロセスの権限以上のことはできない

「全員が管理者権限」の環境では、1件の事故がそのまま全損につながります。

権限を絞る3つの軸

「誰に」の実装としてよく使われるのが RBAC(ロールベースアクセス制御)です。個人に直接権限を付けず、役割に権限をまとめて、人には役割を割り当てます。異動時の付け替えが楽になり、権限の棚卸しもしやすくなります。

実務での適用例

• [[認証と認可]] — ログインできること(認証)と、何をしてよいか(認可)は別。認可の設計で本原則を適用します
• OSのユーザー — 常駐プロセスを root で動かさず、専用ユーザーで動かす([[ファイルシステムとパーミッション]])
• データベース — アプリ用アカウントに DROP TABLE の権限を与えない。参照だけの処理には読み取り専用アカウントを使う([[データベースのユーザーと権限管理]])
• クラウドとAPIキー — [[AWS IAM]] のようにリソースと操作を細かく指定し、[[シークレット管理]] と組み合わせて用途別に権限を絞ったキーを発行する

つまずきやすいところ

権限を絞ると、当然ながら「動かない」場面が増えます。ここで安易に全権限を付けてしまうのが典型的な失敗です。

• とりあえず全許可 — 動作確認のために全権限を付け、そのまま本番へ。あとから絞る作業はまず行われません
• 権限クリープ — 異動や兼任を繰り返すうちに古い権限が消されず積み上がる現象。定期的な棚卸しが必要です
• 共有アカウント — 誰が操作したか追えなくなり、監査もできません。個人アカウント+役割の割り当てが基本です
• 一時的な昇格の放置 — 特権が必要な作業は期限付きで昇格し、終わったら必ず戻します

権限は「足りなければ足す」方向で設計するのが原則です。最初から広く与えて後で削るのは、実際にはほぼ実行されません。なお [[ゼロトラスト]] は「場所を信頼の根拠にせず、アクセスのたびに検証する」という設計思想で、最小権限はその中核をなす要素のひとつです。検証したうえで必要な範囲だけを許可するからこそ、侵入後の横移動を止められます。

初学者向けポイント

• 自分の開発PCでも、日常作業は管理者権限なしのアカウントで行うのが安全です
• 「権限がなくて不便」と感じたら、全権限を求めるのではなく必要な操作だけを申請する癖をつけましょう
• 設計時は「このプログラムが乗っ取られたら何ができるか」を想像すると、絞るべき範囲が見えてきます

関連技術とのつながり

• [[認証と認可]] — 認可の設計指針として最小権限を適用する
• [[ゼロトラスト]] — 最小権限を中核要素として組み込んだ設計思想
• [[ファイルシステムとパーミッション]] — OSレベルでの権限の絞り込み
• [[シークレット管理]] — 用途別に権限を絞ったキーを発行する
• [[AWS IAM]] — ポリシーによるクラウド上の細かな権限設計

Q: 最小権限の原則の主なねらいはどれ?
- [ ] 権限申請の手続きをなくして作業を速くする
- [x] 事故や侵害が起きたときの被害範囲を小さくする
- [ ] サーバーの処理速度を上げる
解説: 攻撃の防止だけでなく、乗っ取りや操作ミスの影響を権限の範囲内に閉じ込めることが主眼です。

Q: 個人に直接権限を付けず、役割に権限をまとめて割り当てる方式はどれ?
- [x] RBAC(ロールベースアクセス制御)
- [ ] CDN
- [ ] OSI参照モデル
解説: RBAC は役割に権限をまとめる方式で、異動時の付け替えや権限の棚卸しがしやすくなります。

Q: 権限運用の失敗例として本文で挙げられているのはどれ?
- [ ] 役割ごとに権限を分ける
- [x] 複数人で同じアカウントを共有する
- [ ] 特権作業を期限付きの昇格で行う
解説: 共有アカウントは誰が操作したか追跡できず、監査もできなくなります。