カテゴリ: 原則
タイプ: セキュリティとシステム設計の原則
起源: 計算機セキュリティ研究。Saltzer と Schroeder により1970年代に体系化
別名: PoLP、minimum necessary access
タイプ: セキュリティとシステム設計の原則
起源: 計算機セキュリティ研究。Saltzer と Schroeder により1970年代に体系化
別名: PoLP、minimum necessary access
先に答えると — 最小権限の原則（Principle of Least Privilege）は、利用者・サービス・プロセスに対して、現在の業務に必要な最小限の権限だけを付与する設計思想です。これにより、侵害時の横展開、誤操作による重大障害、内部不正の影響範囲を大きく縮小できます。
最小権限の原則とは？
最小権限の原則（Principle of Least Privilege）は、すべての主体のアクセス権を「正当な作業に必要な最小集合」に限定するルールです。安全なシステムは、誰も失敗しない前提ではなく、失敗しても被害が広がらない前提で設計されます。この原則は、攻撃者の権限昇格だけでなく、通常運用での誤操作リスクも同時に抑えます。実務では 関心の分離、フェイルファスト、可逆性の原則 と組み合わせると効果が高まります。
最小権限の原則の3段階の理解
- 入門: 今日の作業に必要なアクセスだけを付与する。
- 実践: ロール設計、承認フロー、定期棚卸しを運用に組み込む。
- 上級: JIT権限、細粒度ポリシー、継続監視で権限ライフサイクルを管理する。
起源
最小権限の原則は、1970年代の基礎的セキュリティ設計論で明確化されました。Saltzer と Schroeder は、権限境界を狭めることが攻撃面縮小と障害封じ込めに有効だと示しました。 その後、分散システムとクラウドの普及により、原則はOS権限管理から、ID管理、アクセス政策、ゼロトラスト実装へ拡張されました。NIST などの実務指針でも「最小必要アクセス」は中核制御として扱われています。 本質的価値は、侵害そのものをゼロにすることではなく、侵害後の被害半径を小さく保つ点にあります。要点
最小権限は、設定項目ではなく継続運用すべき仕組みです。応用場面
最小権限は、技術基盤から組織運用まで横断的に適用できます。クラウド基盤
ワイルドカード権限を廃止し、リソース単位のポリシーへ置き換えます。
データ基盤
データ機密度に応じて読み書きを分離し、持ち出し権限を厳格に制御します。
管理者ツール
日常作業と不可逆操作を分離し、重要変更には追加確認を必須化します。
個人・チーム運用
日常アカウントと管理者アカウントを分け、誤操作の確率を下げます。
事例
2013年の Target 侵害は、過剰権限とセグメント不足が被害拡大を招いた事例として広く分析されています。外部接続点の侵害後、攻撃者が横方向に移動できたことが問題でした。 測定可能な影響として、公開報告では復旧費、法的対応、運用損失を含むコストが巨額になりました。最小権限だけで全侵害を防げるわけではありませんが、横展開余地を狭めることで被害規模を大幅に抑えられることが示されています。限界と失敗パターン
最小権限は、実装を誤ると現場負荷だけが増えます。- 業務停止リスク: 例外処理経路が遅いと、正当な作業まで止まる。
- 回避行動の発生: 申請が重すぎると、共有アカウント等の非公式運用が生まれる。
- 静的ロールの陳腐化: 組織変更に追随しないロール設計は、見えない過剰権限を残す。
よくある誤解
最小権限は、監査対応のためだけの作業ではありません。誤解：最小権限は必ず開発速度を落とす
誤解：最小権限は必ず開発速度を落とす
訂正: 遅くなるのは設計不良の場合です。JITアクセスは安全性と速度の両立に有効です。
誤解：IT部門だけが対応すればよい
誤解：IT部門だけが対応すればよい
訂正: 財務、人事、運用、委託先管理にも権限リスクは存在し、同じ原則が必要です。
誤解：RBACを導入すれば完了
誤解：RBACを導入すれば完了
訂正: RBACは土台です。棚卸し、文脈制御、迅速な権限剥奪まで含めて成立します。
関連概念
最小権限は、運用設計の他原則と合わせると実効性が高まります。関心の分離
責務境界を明確にすると、権限範囲を過不足なく設計しやすくなります。
フェイルファスト
権限設定ミスを早期検知し、潜在リスクの蓄積を防ぎます。
可逆性の原則
重大変更を巻き戻せる設計により、権限ミス時の被害を抑えます。