IAMのベストプラクティス — 最小権限の原則から始めるAWSアクセス管理

概要

AWSを使い始めると必ず向き合うのが IAM（Identity and Access Management）です。IAMはAWSリソースへの「誰が・何に・どこまでアクセスできるか」を制御する仕組みで、設計を誤ると、権限が広すぎてインシデント時の被害が広がったり、狭すぎて運用が回らなくなったりします。

この記事では、IAMの中核である最小権限の原則（Principle of Least Privilege）を軸に、入門者が最初に押さえるべきベストプラクティスを、具体的なポリシー例とともに整理します。対象は「AWSを触り始めたが、IAMは何となくフルアクセスで済ませている」段階の方です。

IAMの基本要素

まず用語を整理します。

要素	役割
ユーザー（IAM User）	人間や個別のIDに紐づく長期認証情報
グループ（IAM Group）	ユーザーをまとめてポリシーを付与する単位
ロール（IAM Role）	一時認証情報を引き受ける仕組み。EC2・Lambda・他アカウント等が利用
ポリシー（Policy）	許可・拒否ルールをJSONで記述したもの

権限はポリシーで定義し、それをユーザー・グループ・ロールにアタッチする、という構造を理解しておくと以降が飲み込みやすくなります。

最小権限の原則とは

最小権限の原則とは、「その主体が業務を遂行するために必要な権限だけを与える」という考え方です。やりがちなアンチパターンが AdministratorAccess や *:* を付けてしまうことです。動きはしますが、次のリスクを抱えます。

• 認証情報が漏洩したとき、アカウント全体が乗っ取られる
• 誤操作で本来触れないリソースを削除・変更できてしまう
• 監査時に「なぜこの権限が必要なのか」を説明できない

最小権限は「最初から完璧に絞る」ことではなく、必要なものだけを足す／使われていないものを削るという継続的な運用プロセスとして捉えるのが現実的です。

実装例

アンチパターン: 何でもできるポリシー

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "*",
      "Resource": "*"
    }
  ]
}

これは避けたい典型例です。

良い例: 特定バケットの読み取りに限定

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadOnlySpecificBucket",
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::example-app-assets",
        "arn:aws:s3:::example-app-assets/*"
      ]
    }
  ]
}

• Action を s3:* ではなく必要な操作だけに絞る
• Resource を * ではなく対象ARNに限定する
• ListBucket（バケット対象）と GetObject（オブジェクト対象）でARNを書き分ける

条件（Condition）でさらに絞る

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-app-uploads/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

この例では「KMS暗号化を指定したPutObjectのみ許可」しています。暗号化なしのアップロードは拒否されます。

ユーザーではなくロールを使う

長期のアクセスキーは漏洩リスクが高く、ローテーションの手間もかかります。可能な限りロールによる一時認証情報を使うのがベストプラクティスです。

• EC2 / ECS / Lambda などにはIAMロールをアタッチし、コード内にキーを書かない
• 人間のアクセスは IAM Identity Center（旧AWS SSO） でフェデレーションし、短命な認証情報を発行する
• クロスアカウントアクセスも sts:AssumeRole によるロールの引き受けで行う

信頼ポリシー（Trust Policy）の例です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "lambda.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

そのほかの基本的なベストプラクティス

• ルートユーザーは日常運用で使わない。作成直後にMFAを有効化し、以降は封印する
• すべてのユーザーにMFAを必須化する
• 権限はグループ経由で付与し、ユーザー個別のインラインポリシーは避ける
• IAM Access Analyzer で外部公開・過剰権限を検出する
• CloudTrail で操作を記録し、追跡可能にする
• 未使用アクセスキーは削除し、定期的にローテーションする

確認方法

IAM Policy Simulator

マネジメントコンソールのPolicy Simulatorで、特定アクションが許可されるか／拒否されるかをシミュレートできます。

CLIで実際に叩いてみる

# 許可されているはずの操作
aws s3 ls s3://example-app-assets/

# 許可されていないはずの操作（AccessDeniedになることを確認）
aws s3 rm s3://example-app-assets/somefile

「できるはずのことができる」だけでなく、「できてはいけないことが拒否される」ことまで確認するのがポイントです。

Access Advisor

IAM Userやロールの「Access Advisor」タブでは、直近で実際に使われたサービスがわかります。使われていない権限を洗い出して削るときの根拠になります。

注意点

• ポリシー評価は明示的なDenyがAllowに優先します。Deny があれば必ず拒否されます
• 最小権限を意識しすぎて最初からガチガチにすると開発が止まるので、開発環境は緩め・本番は厳格と環境で分ける現実的な運用も有効です
• AWS管理の FullAccess 系マネージドポリシーは広すぎることが多いので、本番では中身を確認して使います

まとめ

• IAMの中心思想は最小権限の原則。必要な Action と Resource だけを許可する
• 長期キーよりもロール（一時認証情報）を優先する
• MFA・ルートユーザー封印・CloudTrail・Access Analyzer を最初に整えておく
• 作ったら Policy Simulatorや実操作で「拒否されること」まで確認する

最小権限は一度作って終わりではなく、継続的に見直す運用です。まずは *:* を1つ潰すところから始めてみてください。