Least Privilege

最小権限の原則（Principle of Least Privilege：PoLP）とは、ユーザー、プロセス、システムに対して、その業務やタスクの遂行に必要最小限のアクセス権限のみを付与するというセキュリティの基本原則です。不要な権限を排除することで、万が一アカウントが侵害された場合や内部不正が発生した場合の被害範囲（Blast Radius）を最小化します。

最小権限の原則は、情報セキュリティの世界で最も古く、最も重要な原則の一つです。1975年にSaltzerとSchroederが提唱したこの概念は、現在ではゼロトラストアーキテクチャの中核要素として位置づけられています。NIST SP 800-53やISO 27001をはじめとする主要なセキュリティフレームワークにおいても、必須の管理策として明記されています。

しかし、多くの組織では権限の蓄積（Privilege Creep）が深刻な課題となっています。部署異動やプロジェクト変更の際に、以前のアクセス権限が削除されずに蓄積していく現象であり、時間の経過とともにユーザーは業務上不要な権限を大量に保有することになります。最小権限の原則を実効的に維持するには、継続的なアクセスレビューと自動化された権限管理の仕組みが不可欠です。

権限の蓄積（Privilege Creep）の問題

権限の蓄積（Privilege Creep）とは、ユーザーが役職変更や部署異動、プロジェクト参加などを経る中で、以前のアクセス権限が取り消されずに蓄積していく現象です。典型的な例として、開発部門からマーケティング部門に異動した従業員が、開発環境へのアクセス権限を保持し続けるケースがあります。

権限の蓄積は、セキュリティリスクを著しく増大させます。侵害されたアカウントが広範な権限を持っていれば、攻撃者は横方向の移動（ラテラルムーブメント）をより容易に行えます。また、内部不正のリスクも高まります。組織の規模が大きいほど権限の蓄積は深刻化しやすく、定期的なアクセスレビューと自動化された権限棚卸しが対策の要です。

Just-In-Time（JIT）アクセス

JITアクセス（Just-In-Time Access）は、特権アクセスを必要な時だけ一時的に付与し、タスク完了後に自動的に取り消すアプローチです。常時特権を保有する代わりに、承認されたリクエストに基づいて短時間のアクセスウィンドウを提供します。

JITアクセスの実装では、ユーザーがセルフサービスポータルからアクセスを申請し、承認者がリアルタイムで承認、承認後に一定時間（例：4時間）だけ権限が付与され、時間経過後に自動的に権限が取り消されるというフローが一般的です。Microsoft Entra IDのPIM（Privileged Identity Management）やCyberArk、HashiCorp Vaultなどが代表的な実装例です。

Just-Enough Access（JEA）

JEA（Just-Enough Access）は、ユーザーに対してタスクの遂行に必要な最小限の操作権限のみを付与するアプローチです。例えば、サーバー管理者に完全なroot権限を付与する代わりに、特定のサービスの再起動やログファイルの閲覧のみが可能な制限付き権限を付与します。

WindowsのJEA機能やLinuxのsudoersの細粒度設定、AWS IAMのアクションレベルポリシーなどが、JEAの実装手法として利用されます。JITアクセスが「いつ」権限を付与するかを制御するのに対し、JEAは「何を」許可するかを細かく制御する点で補完的な関係にあります。

クラウドIAMにおける最小権限

AWS、Azure、Google Cloudなどのクラウドプラットフォームでは、IAMポリシーを通じてきめ細かなアクセス制御が可能です。しかし、クラウドIAMの複雑さゆえに、過剰な権限が付与されるケースが非常に多く見られます。多くの組織では、開発の迅速化を優先してAdministratorAccessのような広範な権限を付与しがちです。

AWS IAM Access Analyzer、Google Cloud IAM Recommender、Azure Advisor等のツールは、実際の使用状況に基づいて過剰な権限を検出し、最適なポリシーへの縮小を推奨します。CIEM（Cloud Infrastructure Entitlement Management）ソリューションは、マルチクラウド環境における権限の可視化と最適化を専門的に支援します。

実装戦略とベストプラクティス

最小権限の実装は段階的に進めることが推奨されます。まず、現在のアクセス権限の棚卸しと可視化を行い、過剰な権限の全体像を把握します。次に、最もリスクの高い特権アカウント（管理者権限、データベースアクセス）から優先的に最小権限化を進めます。

最小権限を持続的に維持するためには、「デフォルトで拒否（Default Deny）」の原則を採用し、明示的に許可された操作のみを許可する設計とすることが重要です。また、権限のリクエスト・承認・レビューのワークフローを自動化し、組織文化として最小権限の意識を定着させることが、長期的な成功の鍵となります。

• 01
  定期的なアクセス権限の棚卸しと削減：少なくとも四半期ごとに全ユーザーのアクセス権限をレビューし、業務上不要になった権限を速やかに削除してください。特に異動・昇進後のユーザーについては、旧ポジションの権限が残存していないかを重点的に確認しましょう。
• 02
  JITアクセスによる特権の時限付与：管理者権限や機密データへのアクセスなど、高リスクな権限についてはJITアクセスを導入し、必要な時だけ一時的に権限を付与する仕組みを構築してください。常時特権を保有するアカウント数を最小化することが重要です。
• 03
  デフォルト拒否ポリシーの採用：アクセス制御のデフォルトを「すべて拒否」とし、業務に必要な権限のみを明示的に許可する方式を採用してください。新規ユーザーには最小限の権限からスタートし、必要に応じて権限を追加するアプローチが効果的です。
• 04
  クラウドIAMポリシーの定期的な分析と最適化：AWS IAM Access AnalyzerやGoogle Cloud IAM Recommenderなどのツールを活用して、過剰な権限を検出し、実際の使用状況に基づいたポリシーの縮小を実施してください。未使用の権限は積極的に削除しましょう。
• 05
  サービスアカウントと技術アカウントの権限最小化：アプリケーションやバッチ処理で使用するサービスアカウントにも最小権限の原則を適用してください。サービスアカウントは人間の監視が行き届きにくいため、特に権限の範囲を厳格に制限することが重要です。
• 06
  権限昇格パスの定期的な監査：低権限のアカウントから高権限への昇格パス（Privilege Escalation Path）が存在しないかを定期的に監査してください。ロールの継承関係やグループメンバーシップの連鎖による意図しない権限拡大を検出し、排除することが重要です。