最小権限の原則
ユーザーやプログラムに、タスクの遂行に必要な最小限の権限のみを付与するセキュリティ原則
最小権限の原則とは
最小権限の原則 (Principle of Least Privilege, PoLP) は、ユーザー、プログラム、プロセスに対して、そのタスクの遂行に必要な最小限の権限のみを付与するセキュリティ原則である。1975 年に Jerome Saltzer と Michael Schroeder が論文「The Protection of Information in Computer Systems」で提唱した、情報セキュリティの基本原則の 1 つだ。
万が一アカウントが侵害されても、被害範囲を最小限に抑える。これは「防御の深層化 (Defense in Depth)」の一環であり、1 つの防御層が突破されても、権限が限定されていれば攻撃者の行動範囲を制約できる。
なぜ最小権限が守られないのか
原則としては誰もが同意するが、実務では以下の理由で違反が常態化する。
- 開発速度の優先: 「とりあえず動かしたい」ので広い権限を付与し、後で絞る予定が永遠に来ない
- 権限エラーの回避: IAM ポリシーの設計が面倒で、
*を指定して権限エラーを回避する - コピー & ペースト: 既存の Lambda のポリシーをコピーし、不要な権限がそのまま引き継がれる
- 権限の蓄積: 役割変更や異動後も、以前の権限が削除されずに残る (権限クリープ)
AWS IAM での実践
良い例: 必要最小限のポリシー
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": ["dynamodb:GetItem", "dynamodb:PutItem", "dynamodb:Query"],
"Resource": [
"arn:aws:dynamodb:ap-northeast-1:123456789012:table/orders",
"arn:aws:dynamodb:ap-northeast-1:123456789012:table/orders/index/*"
]
}
]
}
Actionを必要な操作のみに限定 (dynamodb:*ではない)Resourceを特定のテーブルとそのインデックスに限定 (*ではない)DeleteItemやUpdateItemが不要なら含めない
悪い例: よくある違反パターン
| 違反 | リスク | 正しい対応 |
|---|---|---|
Lambda に AdministratorAccess |
Lambda が侵害されると AWS アカウント全体が危険 | 必要な Action と Resource のみ許可 |
Resource: "*" |
全リソースにアクセス可能 | 対象リソースの ARN を明示 |
Action: "s3:*" |
バケット削除まで可能 | s3:GetObject, s3:PutObject のみ |
| 開発者に本番の管理者権限 | 誤操作で本番データを破壊 | 読み取り専用 + JIT 昇格 |
最小権限を実現するための段階的アプローチ
いきなり完璧な最小権限を設計するのは難しい。以下の段階的アプローチが現実的だ。
- まず広めの権限で開発する: 開発環境では
AmazonDynamoDBFullAccessのようなマネージドポリシーで素早く動かす - CloudTrail で実際の API 呼び出しを記録する: 2〜4 週間の運用データを蓄積する
- IAM Access Analyzer でポリシーを生成する: 実際に使用された API のみを許可するポリシーを自動生成する
- 生成されたポリシーをレビューして適用する: 不要な権限が含まれていないか確認し、本番環境に適用する
IAM Access Analyzer の活用
IAM Access Analyzer は、CloudTrail の API 呼び出し履歴を分析し、使用されていない権限を特定する。過剰な権限を検出し、最小権限に絞り込んだポリシーを自動生成する機能がある。
# IAM Access Analyzer でポリシー生成を開始
aws accessanalyzer start-policy-generation \
--policy-generation-details '{
"principalArn": "arn:aws:iam::123456789012:role/my-lambda-role"
}' \
--region ap-northeast-1
SAM テンプレートでの最小権限
SAM テンプレートでは、Policies プロパティで Lambda の権限を宣言的に定義できる。
SAM のポリシーテンプレート (DynamoDBCrudPolicy, S3ReadPolicy など) は、リソースを限定した最小権限ポリシーを自動生成する。* を手書きするよりも安全で簡潔だ。
よくある誤解
- 「開発環境なら広い権限でよい」: 開発環境でも最小権限を意識すべきだ。開発環境のポリシーがそのまま本番にコピーされるリスクがある
- 「マネージドポリシーは安全」:
AmazonS3FullAccessはマネージドポリシーだが、全バケットの全操作を許可する。マネージドポリシーでも権限の範囲を確認する必要がある - 「一度設定すれば終わり」: アプリケーションの機能追加に伴い、必要な権限は変化する。定期的に IAM Access Analyzer で未使用権限を棚卸しする
Jerome Saltzer と Michael Schroeder の 1975 年の論文が原典であり、AWS の IAM ベストプラクティスドキュメントで具体的な実装方法が解説されている。
最小権限の原則については関連書籍でも詳しく扱われている。