developersIO
【SAA資格勉強】初学者がIAMについてまとめました

【SAA資格勉強】初学者がIAMについてまとめました

AWS IAMAWS
2026.05.29

はじめに

こんにちは、ykです。現在SAA資格取得に向けて勉強中です。
このエントリでは、IAMについて学んだ内容を自分なりにまとめて記していきます。

IAMの概要

IAM（AWS Identity and Access Management）はAWSリソースへのアクセスを安全に管理するためのウェブサービスです。

AWSアカウントを作成すると、最初はAWSサービス及びAWSリソースに対して完全なアクセス権を持つルートユーザーとしてAWSにアクセスします。
しかし、あらゆる権限を持っているという状態は、第三者に不正アクセスされた際のリスクが極めて高いです。
また操作ミスなどにより、本番環境のAWSリソースを停止してしまうといった可能性も考えられます。
したがって、ルートユーザーは日常的な作業には使用せず、ルートユーザーでしか実行できないタスクに限定して使用することがベストプラクティスとしても定められています。

IAMによるアクセス管理

具体的にどのようにしてアクセス管理をしていくのかというと、まずはIAMユーザーを作成します。
新規作成されたIAMユーザーは、ルートユーザーと異なりすべてのAWSサービスへの権限を持っていない状態です。
そのIAMユーザーにIAMポリシーを付与することで、権限を持たせることができます。
IAMポリシーには、AWSサービスやAWSリソースに対するアクセスの許可・拒否を記述します。
ユーザーがすべてを記述するポリシーをカスタマー管理ポリシー、AWSによりあらかじめ用意されているポリシーをAWS管理ポリシーと呼びます。この二種類のポリシーは異なるIAMユーザーに対して何度でも使用することができますが、一つのIAMユーザーに直接埋め込む形でのみ使用されるインラインポリシーというものも存在しています。

IAMポリシーを付与できる対象はIAMユーザーだけではありません。IAMユーザー、IAMグループ、IAMロールの三種類があります。これらはIAMアイデンティティと呼ばれ、IAMアイデンティティに付与するポリシーをアイデンティティベースのポリシーと呼びます。

一方で、AWSリソース自体にもポリシーを付与できる場合があり、こちらはリソースベースのポリシーと呼ばれます。
例として、Amazon S3にはリソースベースのポリシーであるバケットポリシーがあります。

IAMグループは複数のIAMユーザーをひとまとめにして、IAMポリシーをグループに付与することで一括で権限を与えることが可能です。
IAMロールは、IAMユーザーやAWSサービスに一時的な権限の委任をする仕組みです。
IAMポリシーが付与されたIAMロールを、対象に設定することで権限が与えられます。
サービス自体に権限を与えたり、クロスアカウントアクセスをする際に用いられます。

なお、単一のAWSアカウント環境であれば、IAMユーザーに恒久的な権限・アクセスキーを持たせるのではなく、IAMロールを使って一時的な認証情報で作業させることが、ベストプラクティスに記載されています。基本的にはIAMユーザーではなくIAMロールを使用することが推奨されていることは覚えておきましょう。

IAMロールとリソースベースポリシー

IAMロールにアタッチするアクセス許可ポリシーでは、「そのロールを引き受けたプリンシパルが、どのAWSサービス・リソースに対して、どの操作をできるか」を定義します。
一方、リソースベースポリシーでは、「そのリソースに対して、どのプリンシパルが、どの操作をできるか」をリソース側で定義します。代表例として、S3バケットポリシーやSQSキューポリシーがあります。

AWSサービスにIAMロールを関連付ける場合、そのサービスは信頼ポリシーで許可されたロールを引き受け、一時的な認証情報を使ってAWS APIを実行します。たとえば、EC2インスタンスやLambda関数では、AWS側が一時的な認証情報の取得・更新を行うため、通常はアプリケーションコード内でAssumeRoleを直接呼び出す必要はありません。
ただし、IAMロールを利用するAWSサービスは、コードを実行するサービスに限られません。より正確には、「AWSサービスがユーザーに代わって他のAWS APIを実行する必要がある場合」に、そのサービスが引き受けるIAMロール、つまりサービスロールを使います。

一方、S3バケットやSQSキューのようなリソース自体には、EC2インスタンスやLambda関数の実行ロールのようにIAMロールを直接アタッチして「そのリソースがAPIを呼ぶ主体になる」わけではありません。そのようなリソースに対しては、バケットポリシーやキューポリシーなどのリソースベースポリシーを使って、誰がそのリソースへアクセスできるかを制御します。

IAMロールの信頼ポリシー

IAMロールを引き受けるには、AWS STSのAssumeRoleなどのAPIによって一時的な認証情報を取得します。
IAMロールには信頼ポリシーが設定されます。信頼ポリシーは、そのロールをどのプリンシパルが引き受けられるかを定義するポリシーです。AWSサービスにロールを引き受けさせる場合は、信頼ポリシーのPrincipalに対象サービスのサービスプリンシパルを指定し、Actionにsts:AssumeRoleを許可します。
なお、IAMユーザーやIAMロールなどのプリンシパルがAssumeRoleを呼び出す場合、引き受けられる側のロールの信頼ポリシーで許可されているだけでなく、呼び出し側にもsts:AssumeRoleの権限が必要です。また、AWSサービスにロールを使わせる場合は、利用者側にiam:PassRole権限が必要になるケースがあります。
信頼ポリシーは、IAMロールに設定されるリソースベースポリシーの一種です。ただし、S3バケットポリシーやSQSキューポリシーのように「そのリソースへのデータ操作を許可する」ものではなく、IAMロールというリソースに対して「誰がこのロールを引き受けられるか」を定義するための特殊なリソースベースポリシーです。

IAMポリシーの記法

IAMポリシーはJSON形式で記述します。
以下にIAMポリシー（アイデンティティベースのポリシー）の記述例を示します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:ListAllMyBuckets",
      "Resource": "*",
      "Condition": {
        "IpAddress": {
          "aws:SourceIp": "xxx.xx.xxx.xx/32"
        }
      }
    }
  ]
}

  • Effect
    Allowで許可権限、Denyで拒否権限の設定ができる。

  • Action
    権限を設定する操作を指定する。複数の操作を指定可能。

  • Resource
    権限を設定するAWSリソースをARNで指定する。複数のリソースを指定可能。

  • Condition
    権限が発動する条件を指定する。

なお、リソースベースポリシーにはPrincipalという項目が存在し、サービスを呼び出す主体を指定します。

アクセス許可境界

あらかじめポリシーで設定できる権限の上限を決めるための仕組みとして、アクセス許可境界（Permissions boundary）と呼ばれるものがあります。

このアクセス許可境界でA、Bという権限が許可されていて、実際にIAMアイデンティティに付与されたIAMポリシーではA、B、Cという権限が許可されていた場合、両方に書かれているA、Bという権限のみが許可されるという仕組みです。

このアクセス許可境界は、IAMユーザーまたはIAMロールに設定できます。IAMグループには設定できません。
また、アクセス許可境界自体は権限を付与しないということに注意してください。

さらに、AWSアカウントがAWS Organizationsに属している場合、サービスコントロールポリシー（SCP）と呼ばれるポリシーでもアクセス許可境界と同様にあらかじめ権限の上限が設定されます。

ルートユーザーでしかできないこと

IAMユーザーは権限を付与されればAWSサービスやリソースへのアクセスが可能になりますが、付与できる権限には限界があります。以下にルートユーザーでしかできない操作を挙げていきます。

  • AWSアカウント設定（Eメールアドレス、ルートユーザーパスワード、ルートユーザーアクセスキー）を変更する
  • AWSアカウントを閉鎖する
  • IAM管理者が誤って自身のIAM権限を失った場合に、ルートユーザーでIAMユーザーやロールの権限を復旧する
  • 請求情報とコスト管理コンソールへのIAMアクセスをアクティブにする
  • リザーブドインスタンスマーケットプレイスに出品者として登録
  • Amazon S3バケットでMFA Deleteを有効化する

おわりに

今回IAMについて学習してみて、地味ではあるけどかなり大事なサービスだという印象を持ちました。記事内でも書いた通り、権限周りはしっかりと設定しなければ不正アクセス時に被害が甚大になることが予想されます。
IAMでは、必要以上の権限を付与せず、利用者やサービスに必要な最小限の権限だけを与える「最小権限の原則」が重要だと感じました。
そういった意味でも、もっと理解を深めていく必要があると感じました。

参考リンク

クラスメソッドオペレーションズ株式会社について

クラスメソッドグループのオペレーション企業です。
運用・保守開発・サポート・情シス・バックオフィスの専門チームが、IT・AIをフル活用した「しくみ」を通じて、お客様の業務代行から課題解決や高付加価値サービスまでを提供するエキスパート集団です。
当社は様々な職種でメンバーを募集しています。
「オペレーション・エクセレンス」と「らしく働く、らしく生きる」を共に実現するカルチャー・しくみ・働き方にご興味がある方は、クラスメソッドオペレーションズ株式会社 コーポレートサイトをぜひご覧ください。
※2026年1月 アノテーション㈱から社名変更しました。

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

特定のEC2のみアクセス権限を付与する方法
イドンホ
2025.12.20
[入門] AWS IAMの基本のキ
武田隆志
2025.05.26
SCPと許可セットを設計するベストプラクティスについて
Lee Sujae
2026.02.28
AWS Security Agent のWebアプリへの認証方式「ユーザーアクセスの管理」を設定してみた #AWSreInvent
あしざわ
2025.12.10