最小権限の原則

最小権限の原則とは

最小権限の原則 (Principle of Least Privilege, PoLP) は、ユーザー、プログラム、プロセスに対して、そのタスクの遂行に必要な最小限の権限のみを付与するセキュリティ原則である。Jerome H. Saltzer と Michael D. Schroeder が Proceedings of the IEEE 63 巻 9 号 (1975 年 9 月) に発表した論文「The Protection of Information in Computer Systems」が原典で、そこで挙げられた 8 つの設計原則の 1 つとして整理されている。原典の言い方は「システムのすべてのプログラムとすべての利用者は、仕事を完了するために必要な最小の権限の集合で動作すべきである」だ。

万が一アカウントが侵害されても、被害範囲を最小限に抑える。これは多層防御の一環であり、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 のログを読んでポリシーを組み立てるのがポリシー生成、最後にアクセスされた日時の情報を見て使われていない権限を洗い出すのが未使用アクセスの検出である。

ポリシー生成は、指定した期間の CloudTrail のログから、その IAM ユーザーまたはロールが実際に呼び出したサービスとアクションを拾い、それだけを許可するポリシーを作る。ログを読むためのサービスロールと、対象となる証跡 (trail) の指定が要る。

# CloudTrail の記録からポリシーを生成する
aws accessanalyzer start-policy-generation \
  --policy-generation-details '{
    "principalArn": "arn:aws:iam::123456789012:role/my-lambda-role"
  }' \
  --cloud-trail-details '{
    "trails": [
      {
        "cloudTrailArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/my-trail",
        "allRegions": true
      }
    ],
    "accessRole": "arn:aws:iam::123456789012:role/AccessAnalyzerPolicyGenerationRole",
    "startTime": "2026-05-20T00:00:00Z",
    "endTime": "2026-08-16T00:00:00Z"
  }' \
  --region ap-northeast-1

accessRole に渡すサービスロールには、証跡の情報を読む cloudtrail:GetTrail、最後にアクセスされた情報を扱う iam:GetServiceLastAccessedDetails と iam:GenerateServiceLastAccessedDetails、ログの置かれたバケットを読む s3:GetObject と s3:ListBucket が必要になる。

生成結果には知っておくべき癖がある。

参照できる期間は最大 90 日で、その外側の呼び出しは無かったものとして扱われる。四半期に 1 回しか動かないバッチの権限は落ちる
アクション単位まで特定できるのは対応済みのサービスに限られ、それ以外はサービス単位の結果になる。Amazon S3 のデータイベントのようなデータイベントはアクション単位では識別されない
iam:PassRole は CloudTrail に記録されないため生成されたポリシーに現れない。Lambda や ECS にロールを渡す構成では手で足す
拒否されたリクエストも含めて記録を見るので、生成物をそのまま適用してよいとは限らない。公式ドキュメントも、監査目的にはこの機能ではなく CloudTrail を直接調べるよう案内している
IAM コンソールで生成できるポリシーは一度に 1 つで、生成したポリシーを確認できるのは 7 日間

使われていない権限の棚卸しは、未使用アクセス用のアナライザーを別に作って行う。見ているのは CloudTrail の生ログではなく最後にアクセスされた情報で、使われていないロール、IAM ユーザーの使われていないアクセスキーとパスワード、稼働中のロールやユーザーが使っていないサービスとアクションが検出結果として出る。外部からのアクセスを調べるアナライザーが追加料金なしなのに対し、こちらは分析対象の IAM ロールとユーザーの数に応じて、アナライザーごとに月単位で課金される。リージョンごとに作れば作った数だけ課金されるが、未使用アクセスの検出結果はリージョンによって変わらないため各リージョンに置く必要はない。サービスリンクロールは分析の対象外で、課金対象の数にも入らない。

SAM テンプレートでの最小権限

SAM テンプレートでは、Policies プロパティで Lambda の権限を宣言的に定義できる。

SAM のポリシーテンプレート (DynamoDBCrudPolicy, S3ReadPolicy など) は、リソースを限定した最小権限ポリシーを自動生成する。* を手書きするよりも安全で簡潔だ。

よくある誤解

「開発環境なら広い権限でよい」: 開発環境でも最小権限を意識すべきだ。開発環境のポリシーがそのまま本番にコピーされるリスクがある
「マネージドポリシーは安全」: AmazonS3FullAccess はマネージドポリシーだが、全バケットの全操作を許可する。マネージドポリシーでも権限の範囲を確認する必要がある
「一度設定すれば終わり」: アプリケーションの機能追加に伴い、必要な権限は変化する。定期的に未使用アクセス用のアナライザーで未使用権限を棚卸しする

最小権限の原則については関連書籍でも詳しく扱われている。

サイト情報