> ## Documentation Index
> Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt
> Use this file to discover all available pages before exploring further.

# 最小権限の原則

> 最小権限の原則は、利用者やサービスに業務遂行に必要な最小限の権限のみを与え、侵害拡大と誤操作の影響を抑える考え方です。

<Info>
  **カテゴリ**: 原則<br />
  **タイプ**: セキュリティとシステム設計の原則<br />
  **起源**: 計算機セキュリティ研究。Saltzer と Schroeder により1970年代に体系化<br />
  **別名**: PoLP、minimum necessary access
</Info>

<Note>
  **先に答えると** — **最小権限の原則**（Principle of Least Privilege）は、利用者・サービス・プロセスに対して、現在の業務に必要な最小限の権限だけを付与する設計思想です。これにより、侵害時の横展開、誤操作による重大障害、内部不正の影響範囲を大きく縮小できます。
</Note>

## 最小権限の原則とは？

**最小権限の原則**（Principle of Least Privilege）は、すべての主体のアクセス権を「正当な作業に必要な最小集合」に限定するルールです。

> 安全なシステムは、誰も失敗しない前提ではなく、失敗しても被害が広がらない前提で設計されます。

この原則は、攻撃者の権限昇格だけでなく、通常運用での誤操作リスクも同時に抑えます。実務では [関心の分離](/ja/principles/separation-of-concerns)、[フェイルファスト](/ja/principles/fail-fast)、[可逆性の原則](/ja/principles/reversibility-principle) と組み合わせると効果が高まります。

### 最小権限の原則の3段階の理解

* **入門**: 今日の作業に必要なアクセスだけを付与する。
* **実践**: ロール設計、承認フロー、定期棚卸しを運用に組み込む。
* **上級**: JIT権限、細粒度ポリシー、継続監視で権限ライフサイクルを管理する。

## 起源

最小権限の原則は、1970年代の基礎的セキュリティ設計論で明確化されました。Saltzer と Schroeder は、権限境界を狭めることが攻撃面縮小と障害封じ込めに有効だと示しました。

その後、分散システムとクラウドの普及により、原則はOS権限管理から、ID管理、アクセス政策、ゼロトラスト実装へ拡張されました。NIST などの実務指針でも「最小必要アクセス」は中核制御として扱われています。

本質的価値は、侵害そのものをゼロにすることではなく、侵害後の被害半径を小さく保つ点にあります。

## 要点

最小権限は、設定項目ではなく継続運用すべき仕組みです。

<Steps>
  <Step title="職務名ではなく作業単位で権限を定義する">
    実際に必要な操作を列挙し、権限をタスクに紐づけて過剰付与を避けます。
  </Step>

  <Step title="範囲を狭くし、有効期限を短くする">
    恒久的な広権限より、短時間・限定範囲の資格情報を優先します。
  </Step>

  <Step title="高リスク操作を分離して保護する">
    削除、外部送信、課金変更などは追加承認や緊急手順で保護します。
  </Step>

  <Step title="定期レビューと自動剥奪を徹底する">
    権限は時間とともに膨らみます。定期見直しと自動回収が不可欠です。
  </Step>
</Steps>

## 応用場面

最小権限は、技術基盤から組織運用まで横断的に適用できます。

<CardGroup cols={2}>
  <Card title="クラウド基盤">
    ワイルドカード権限を廃止し、リソース単位のポリシーへ置き換えます。
  </Card>

  <Card title="データ基盤">
    データ機密度に応じて読み書きを分離し、持ち出し権限を厳格に制御します。
  </Card>

  <Card title="管理者ツール">
    日常作業と不可逆操作を分離し、重要変更には追加確認を必須化します。
  </Card>

  <Card title="個人・チーム運用">
    日常アカウントと管理者アカウントを分け、誤操作の確率を下げます。
  </Card>
</CardGroup>

## 事例

2013年の Target 侵害は、過剰権限とセグメント不足が被害拡大を招いた事例として広く分析されています。外部接続点の侵害後、攻撃者が横方向に移動できたことが問題でした。

測定可能な影響として、公開報告では復旧費、法的対応、運用損失を含むコストが巨額になりました。最小権限だけで全侵害を防げるわけではありませんが、横展開余地を狭めることで被害規模を大幅に抑えられることが示されています。

## 限界と失敗パターン

最小権限は、実装を誤ると現場負荷だけが増えます。

* **業務停止リスク**: 例外処理経路が遅いと、正当な作業まで止まる。
* **回避行動の発生**: 申請が重すぎると、共有アカウント等の非公式運用が生まれる。
* **静的ロールの陳腐化**: 組織変更に追随しないロール設計は、見えない過剰権限を残す。

## よくある誤解

最小権限は、監査対応のためだけの作業ではありません。

<AccordionGroup>
  <Accordion title="誤解：最小権限は必ず開発速度を落とす">
    **訂正**: 遅くなるのは設計不良の場合です。JITアクセスは安全性と速度の両立に有効です。
  </Accordion>

  <Accordion title="誤解：IT部門だけが対応すればよい">
    **訂正**: 財務、人事、運用、委託先管理にも権限リスクは存在し、同じ原則が必要です。
  </Accordion>

  <Accordion title="誤解：RBACを導入すれば完了">
    **訂正**: RBACは土台です。棚卸し、文脈制御、迅速な権限剥奪まで含めて成立します。
  </Accordion>
</AccordionGroup>

## 関連概念

最小権限は、運用設計の他原則と合わせると実効性が高まります。

<CardGroup cols={3}>
  <Card title="関心の分離" href="/ja/principles/separation-of-concerns">
    責務境界を明確にすると、権限範囲を過不足なく設計しやすくなります。
  </Card>

  <Card title="フェイルファスト" href="/ja/principles/fail-fast">
    権限設定ミスを早期検知し、潜在リスクの蓄積を防ぎます。
  </Card>

  <Card title="可逆性の原則" href="/ja/principles/reversibility-principle">
    重大変更を巻き戻せる設計により、権限ミス時の被害を抑えます。
  </Card>
</CardGroup>

## 一言で言うと

<Tip>最小権限とは、アクセス権を広い常設権限ではなく、最小・短期・監査可能な能力として扱う原則です。</Tip>