※本記事にはプロモーション（広告）を含みます。

AWS IAMでロールやポリシーを設計する際は、最初に「誰が」「何に対して」「どの操作を」必要とするかを洗い出し、必要最小限の権限だけを付与する最小権限の原則を起点にしてください。IAMユーザーに直接ポリシーをアタッチする運用を避け、EC2やLambdaなどのAWSリソースにはIAMロールを割り当てる構成にすると、認証情報の漏洩リスクを下げられます。本記事では、IAMの基本構成要素からポリシー設計の具体的な手順、実践的な設計パターン、陥りやすいミスまでを、AWS公式ドキュメントの考え方に沿って整理します。

  • IAMの基本構成要素
  • 最小権限の設計手順
  • ロール設計の実践例
  • 陥りやすい設計ミス
  • よくある質問
  • まとめ

IAMの基本構成要素

IAMを扱う前に、ユーザー・グループ・ロールという3つのエンティティと、ポリシーという権限定義の仕組みを分けて理解する必要があります。この2つを混同すると、設計段階で権限が過剰になったり、逆に必要な操作がブロックされたりする原因になります。

ユーザー・グループ・ロール

IAMユーザーは、個人やアプリケーションに割り当てる長期的な認証情報を持つエンティティです。パスワードやアクセスキーが紐づくため、漏洩すれば長期間悪用される恐れがあります。IAMグループは複数のユーザーをまとめてポリシーを一括適用する仕組みで、ユーザーが増えても権限管理の手間を抑えられます。一方IAMロールは、アクセスキーを持たず、一時的な認証情報（STSトークン）を発行して権限を委譲する仕組みです。EC2インスタンス、Lambda関数、他のAWSアカウント、外部のID連携先など、人ではないエンティティやセッション単位のアクセスに向いています。

実務では、恒久的な認証情報を持つIAMユーザーの数を最小限に抑え、可能な限りロールとSTSの一時的な認証情報に寄せる設計が推奨されています（出典: AWS公式ドキュメント「IAM のベストプラクティス」）。特にEC2やLambdaにアクセスキーを埋め込む運用は、キーローテーションの手間とリスクの両方を抱えるため避けるべき構成です。

ポリシーの3つの種類

IAMポリシーは、JSON形式でVersion・Statement・Effect・Action・Resource・Conditionの要素を組み合わせて権限を定義します。ポリシーには大きく分けてアイデンティティベースポリシー、リソースベースポリシー、境界を設定するポリシー（Permission Boundary、SCP）の3系統があります。アイデンティティベースポリシーはさらにAWS管理ポリシー、カスタマー管理ポリシー、インラインポリシーに分かれます。

種類適用対象主な用途設定場所
AWS管理ポリシーユーザー・グループ・ロール汎用的な権限の即時付与IAMコンソール
カスタマー管理ポリシーユーザー・グループ・ロール組織固有の権限を再利用IAMコンソール／IaC
インラインポリシー単一のユーザー・ロール特定エンティティ専用の権限各エンティティに直接記述
リソースベースポリシーS3バケット・SQSキュー等クロスアカウントアクセス許可対象リソース側
Permission Boundaryユーザー・ロール権限の上限を制限IAMコンソール

AWS管理ポリシーは汎用性が高い反面、実際に使う操作より広い範囲をカバーしていることが多く、そのまま本番環境で使い続けると権限が過剰になりがちです。カスタマー管理ポリシーで必要な操作だけを切り出し、複数のロールで再利用する設計が現実的な落としどころになります。

最小権限の設計手順

最小権限は一度設定して終わりではなく、利用状況に応じて継続的に見直す運用が前提になります。ここでは棚卸しからポリシー作成までの流れを分けて説明します。

権限棚卸しの進め方

既存のIAMユーザーやロールがどの権限を実際に使っているかを把握するには、IAM Access AdvisorのService Last Accessed情報が起点になります。これは各エンティティが過去にどのAWSサービスへアクセスしたかを一覧化する機能で、過去400日程度の履歴を確認できます（画面表示や保持期間は変更される場合があるため、最新仕様はAWS公式ドキュメントで確認してください）。加えてCloudTrailのイベント履歴を突き合わせると、Action単位・Resource単位での実際の呼び出しパターンが見えてきます。

IAM Access Analyzerを有効化すると、外部アカウントやパブリックからアクセス可能なリソースの検出に加え、CloudTrailログを元にした「未使用アクセス」の分析結果も得られます。棚卸しの段階でワイルドカード指定になっている箇所を洗い出し、実際に呼ばれているAction・Resourceのリストに置き換える準備を進めます。

ポリシー作成の流れ

棚卸しが終わったら、次の順序でポリシーを作成します。

  • 必要な操作をAction単位で列挙する（例: s3:GetObject、s3:PutObject）
  • Resourceを対象のARNまで絞り込む（バケット名やパスを固定する）
  • IAMポリシーシミュレーターで想定操作が許可され、想定外の操作が拒否されることを確認する
  • Permission Boundaryで、そのロールが将来取得できる権限の上限を併せて定義する
  • 本番適用後もAccess Analyzerの未使用アクセス分析を定期的に確認し、使われていない権限を削除する

ポリシーシミュレーターはコンソールから無料で利用でき、実際にAPIを呼ばずに許可・拒否の判定結果を確認できます。デプロイ前の検証として組み込んでおくと、想定外の権限不足によるトラブルを本番前に潰せます。

ロール設計の実践例

ここからは具体的な設計パターンを2つ取り上げます。実際のJSON例は環境ごとにARNやアカウントIDが異なるため、そのままコピーするのではなく、自分の環境の値に置き換えて検証してから適用してください。

EC2からS3への権限

EC2インスタンスからS3バケットへの読み取りアクセスを許可する場合、インスタンスプロファイル経由でロールを割り当て、対象バケットとプレフィックスまでResourceを絞り込みます。

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

Resourceを「arn:aws:s3:::example-app-data/*」ではなく「/logs/*」まで絞ることで、同一バケット内の別プレフィックスへの誤アクセスを防げます。書き込みが不要なロールにs3:PutObjectやs3:DeleteObjectを含めない点も、設計時にチェックすべき項目です。

クロスアカウント設計

複数のAWSアカウントを運用する組織では、ロールの信頼ポリシー（Trust Policy）でAssumeRoleを許可するアカウントを限定し、外部からの誤用を防ぐ設計が必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:root"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "unique-external-id-12345"
        }
      }
    }
  ]
}

第三者ベンダーにロールを引き受けさせる構成では、ExternalIdを条件に加えることで「混乱した代理人問題」と呼ばれる、第三者が別顧客のロールを誤って引き受けてしまうリスクを軽減できます（出典: AWS公式ドキュメント「サードパーティーアクセスの安全性」）。組織内の複数アカウントを一元管理する場合はAWS OrganizationsのService Control Policy（SCP）を併用し、アカウント単位で許可されるサービス自体を制限する構成も検討対象になります。

陥りやすい設計ミス

設計時に見落としやすいポイントを2つ挙げます。どちらも一見動作に問題がないため、監査やセキュリティレビューのタイミングまで放置されやすい傾向があります。

ワイルドカードの乱用

開発初期に動作確認を優先すると、Action: “*”、Resource: “*”という全許可のポリシーをそのまま本番へ持ち越してしまうケースがあります。検証段階でのワイルドカード利用自体は開発速度を上げる手段として理解できますが、本番移行前にIAM Access Analyzerの未使用アクセス分析を実行し、実際に呼ばれているAction・Resourceへ絞り込む工程を必ず挟んでください。特にIAM関連の操作（iam:CreateUser、iam:AttachRolePolicyなど）が広範囲に許可されたロールは、侵害された場合に権限昇格の起点になり得るため、優先的に見直す対象です。

ルートユーザー運用

AWSアカウント作成時に発行されるルートユーザーは、すべての操作を無制限に実行できる特権アカウントです。日常的な運用でルートユーザーを使い続けると、アクセスキーの発行有無にかかわらず、アカウント全体が乗っ取りリスクにさらされます。AWSはルートユーザーの利用を請求関連設定の変更やアカウント閉鎖など一部の操作に限定し、MFA（多要素認証）を必ず有効化することを推奨しています（出典: AWS公式ドキュメント「AWS アカウントのルートユーザー」）。日常業務は管理者権限を持つIAMロールを個別ユーザーがAssumeRoleで引き受ける構成に切り替え、ルートユーザーのアクセスキーは発行しない運用が基本方針になります。

よくある質問

IAMユーザーとロールの違い

IAMユーザーは長期的な認証情報を持つ個別のアカウントで、IAMロールは一時的な認証情報を発行して権限を委譲する仕組みです。EC2やLambdaなどAWSリソースへの権限付与にはロールを使い、アクセスキーの埋め込みを避けます。

インラインとマネージドの使い分け

複数のロールで同じ権限セットを再利用するならカスタマー管理ポリシー、特定のロール1つに固有の権限を紐づけるならインラインポリシーが適しています。管理対象を一覧で把握したい場合は、カスタマー管理ポリシーに寄せると棚卸しがしやすくなります。

最小権限を維持する運用

一度作成したポリシーは、IAM Access Analyzerの未使用アクセス分析やCloudTrailログの定期確認を通じて見直します。四半期など一定周期でレビューのタイミングを決めておくと、権限の肥大化を早期に検知できます。

JSON構文でのつまずき

ActionやResourceを配列ではなく単一文字列で書いてしまう記法ミス、ConditionキーとOperatorの組み合わせ誤り、末尾カンマの残存などが典型的なエラー要因です。IAMポリシーシミュレーターまたはIAMコンソールのポリシーエディタが持つ構文チェック機能で、適用前に検証できます。

クロスアカウントの注意点

信頼ポリシーのPrincipalを必要なアカウントIDに限定し、外部ベンダーが引き受けるロールにはExternalId条件を付与します。加えて、引き受け後のロールに付与する権限自体も最小限に絞り込み、Trust Policyと権限ポリシーの両面で範囲を制限します。

Permission BoundaryとSCPの違い

Permission Boundaryは個々のIAMユーザーやロール単位で権限の上限を設定する仕組みで、SCPはAWS Organizationsを通じてアカウントまたは組織単位で許可サービスの範囲を制限する仕組みです。両者は排他的ではなく、組織全体の制約にSCP、個別ロールの制約にPermission Boundaryを併用する構成が一般的です。

関連記事

まとめ

AWS IAMの設計は、ユーザー・グループ・ロールという3つのエンティティの役割を分け、恒久的な認証情報への依存を減らすところから始まります。ポリシー作成では棚卸し→Action・Resourceの絞り込み→シミュレーターでの検証→Permission Boundaryによる上限設定という手順を踏むと、過剰な権限を作り込みにくくなります。ワイルドカードの多用やルートユーザーの日常利用は、一見問題なく動作するために見過ごされやすい設計ミスです。IAMの仕様やコンソールUIはアップデートされる場合があるため、実装時は必ずAWS公式ドキュメントで最新の挙動を確認してください。また、セキュリティに関わる設定変更は自己の環境・責任のもとで検証を行い、本番適用前に必ずテスト環境で動作確認を実施してください。

【編集・制作ポリシー】
本記事はInfra Academy編集部が各ベンダー公式ドキュメント・エンジニア監修をもとに作成しています。インフラ・クラウド構築は環境により異なります。本番環境への適用前に必ずテストを実施してください。情報の正確性には万全を期していますが、最新情報は各公式ドキュメントをご確認ください。 編集ポリシーはこちら

おすすめ: Amazon技術書｜インフラ・クラウド・ネットワーク

ABOUT ME
たから
フリーランスIT講師/エンジニア。 ◆経験：IT講師/インフラエンジニア/PM/マネジメント/採用/運用・保守・構築・設計 ◆取得資格：CCNA/CCNP/LPIC-1/AZ-900//サーティファイC言語/情報処理技術者 ◆サイドビジネス：アパレル事業/複数のWEBメディアを運営