IAMとは

IAMは「Identity and Access Management」の略。簡単に言えば、「誰が」「何に」「どんな操作を」できるのか、AWSの中でそのアクセス権限をしっかり管理する仕組みのことです。

目次

• IAMユーザー
• IAMグループ
• IAMポリシー
• IAMロール

IAMユーザー：AWSを利用する「人」や「アプリケーション」

AWSを利用する際、最初に登場するのが「IAMユーザー」です。

ルートユーザー：AWSアカウントの「最高責任者」

AWSアカウントを作成した際に最初にできるのが「ルートユーザー」です。これは、AWSの全てのサービスとリソースに対して、文字通り「ルート（根源）」となる全ての権限を持つユーザー。例えるなら、会社の社長さんのような存在です。

注意点として、日常的な操作には絶対にルートユーザーを使わないようにしましょう。万が一情報が漏洩したりすると、アカウント全体が危険にさらされてしまいます。

IAMユーザー：日常業務をこなす「実務担当者」

私たちが普段AWSの操作をする際には、この「IAMユーザー」を使います。それぞれのユーザーに対して、必要な権限だけを付与することで、もしもの時にも被害を最小限に抑えられます。まるで、各部署の実務担当者が、自分の業務に必要な範囲で会社のシステムにアクセスするイメージです。

パワーユーザー：なんでもできる「部署のリーダー」

「パワーユーザー」は、IAMユーザーやグループの管理以外の、ほぼ全てのAWSサービスにフルアクセスできる権限を持つユーザーです。これは、部署のリーダーやプロジェクトマネージャーのような存在で、大半の作業はこなせるけれど、人事権（ユーザー管理）は持たない、といったイメージです。

IAMグループ：ユーザーをまとめて「部署」のように管理

個々のIAMユーザーに毎回権限を付与していくのは大変ですよね。そこで便利なのが「IAMグループ」です。

IAMグループは、複数のIAMユーザーをひとまとめにする機能です。例えば、「開発部グループ」や「運用部グループ」のように、部署や役割ごとにグループを作成し、そのグループにまとめて権限を設定することで、管理の手間を大幅に削減できます。

IAMポリシー：権限を「ルールブック」として定義する

「IAMポリシー」は、「誰が」「何に」「どんな操作を許可/拒否するか」を具体的に記述したルールブックです。これは、JSON形式というデータフォーマットで記述されます。

具体的には、以下の3つの要素を定義します。

• どのAWSリソースか：S3バケットなのか、EC2インスタンスなのかなど
• どのサービスか：S3、EC2、Lambdaなど
• どのような操作を許可/拒否するか：ファイルの読み取り、サーバーの起動、データの削除など

ポリシーの種類：誰が作った「ルールブック」か

IAMポリシーには、大きく分けて2種類あります。

• AWS管理ポリシー：AWSが作成・管理している、汎用的なポリシーです。例えば、「S3への読み取り専用アクセス」といった、よくある権限セットが用意されています。
• カスタム管理ポリシー：自分たちのAWSアカウントで、用途に合わせて自由に作成・管理するポリシーです。よりきめ細やかな権限設定が可能です。

そして、もう一つ「インラインポリシー」というものがあります。これは、特定のIAMユーザーやグループ、ロールに直接「埋め込まれた」固有のポリシーです。例えるなら、特定の個人や部署にだけ適用される、その場限りの特例ルールのようなものです。

ポリシーの適用方法：ルールブックを「誰に/何に」渡すか

ポリシーは、大きく2つの方法で適用されます。

• ユーザーベースのポリシー適用：IAMユーザー、IAMグループ、IAMロールにポリシーをアタッチ（紐付け）します。これが最も一般的な使い方です。
• リソースベースのポリシー適用：特定のAWSリソース（例えばS3バケットなど）にポリシーを直接アタッチします。これにより、そのリソースへのアクセスを制御できます。

IAMロール：AWSサービスやユーザーの「役割」を定義する

「IAMロール」は、AWSサービスやIAMユーザーの「役割」を定義し、アクセス権限を管理する概念です。これは、特定の「役割」を持たせることで、一時的に必要な権限を付与する仕組みと考えると分かりやすいでしょう。

AWSサービスロール：AWSサービスが「代理人」として動く

「AWSサービスロール」は、AWSリソースに付与されるロールのことです。

例えば、EC2インスタンスからS3バケットにファイルをアップロードしたい場合、EC2インスタンスに直接アクセスキーとシークレットキーを設定するのはセキュリティ上良くありません。そこで、EC2インスタンスにS3へのアクセス権限を持つ「IAMロール」を付与します。

このIAMロールは、**AWS STS（Security Token Service）**というサービスから一時的なアクセスキーを取得し、それを使って別のAWSリソースにアクセスします。これにより、**アクセスキーとシークレットキーのペアをインスタンス内に保存する必要がなくなり、セキュリティが大幅に向上します。**まるで、特定の業務を依頼された代理人が、一時的に鍵を借りて作業をするようなイメージです。

クロスアカウントアクセス用ロール：別アカウントへの「一時的な通行許可証」

「クロスアカウントアクセス用ロール」は、AWSアカウントをまたいで、別のAWSアカウント内のAWSサービスへのアクセスを一時的に許可するためのロールです。例えば、別の会社のアカウントにあるデータに、一時的にアクセスする必要がある場合などに利用します。

AWSの外部ユーザー用ロール：社外の人にも「限定的なアクセス権」

「AWSの外部ユーザー用ロール」は、「IDフェデレーション」という仕組みを利用して、AWSアカウントの外部にいるユーザー（例えば、自社システムにログインしているユーザーなど）に対して、AWSアカウント内のAWSリソースへのアクセスを許可できるロールです。これにより、AWSユーザーを個別に作成することなく、外部のユーザーにも必要なアクセス権限を与えることができます。

まとめ：IAMはAWSの「セキュリティの要」

IAMは、AWSを安全に、そして効率的に利用するための基盤となる非常に重要なサービスです。一見すると複雑に見えるかもしれませんが、

• 誰が (IAMユーザー、グループ)
• 何に (IAMポリシー)
• どんな操作をできるか (IAMポリシー)
• その権限を一時的に与える役割 (IAMロール)

という形で役割が分かれています。