IAM講座

この講座では、AWSの認証・認可サービスであるIAMについて学びます。

• 認証と認可の違い
• IAMの4大要素（IAMユーザ・IAMポリシー・IAMグループ・IAMロール）
• ルートユーザとIAMユーザの使い分け
• アクセスキーとマネジメントコンソールへのアクセス
• IAMポリシーの書き方（Effect・Action・Resource）

1. 認証と認可の違い

IAMを理解するための第一歩として、「認証」と「認可」という2つの概念の違いを明確にしておきましょう。

1.1 認証

まず「認証（Authentication）」とは、システムにアクセスしてきた相手が「誰なのか」を特定し、本当にその本人であるかを確認するプロセスのことです。もっとも身近で具体的な例としては、IDやパスワードを入力して行う「ログイン」という行為そのものが、この認証にあたります。

1.2 認可

これに対して「認可（Authorization）」とは、認証を済ませた相手に対して「具体的に何をしてよいか」、あるいは「何をしてはいけないか」という権限を与えるプロセスを指します。たとえログイン（認証）には成功しても、システム内のすべてのデータを見られるわけではありません。管理者には全ての操作を許し、一般利用者には閲覧だけを許すといったように、特定の操作だけを許可するのが認可であり、一般的には「権限設定」という言葉でイメージされる機能です。

つまりAWSにおけるIAMとは、この「認証（本人確認）」と「認可（権限管理）」の2つの機能を組み合わせ、誰がどのリソースをどのように使えるのかを、安全かつ厳密にコントロールするための仕組みです。

2. IAMの4大要素

IAMの4大要素であるIAMユーザ、IAMポリシー、IAMグループ、IAMロールについて解説します。

IAMの4大要素の関係を以下に示します。

graph TD
    Policy["IAMポリシー<br>（権限の定義）"]
    User["IAMユーザ<br>（個人・アプリ）"]
    Group["IAMグループ<br>（ユーザの集合）"]
    Role["IAMロール<br>（一時的な権限）"]

    Policy -- "アタッチ" --> User
    Policy -- "アタッチ" --> Group
    Policy -- "許可ポリシー" --> Role
    User -- "所属" --> Group
    Role -. "信頼ポリシーで<br>引き受けを許可" .-> User

2.1 IAMユーザ

IAMユーザとは、個人やアプリケーションに対して割り当てられる、IAMのユーザです。IAMが管理する「誰が」の部分に該当します。

ルートユーザとの違い

IAMの具体的な機能に入る前に、まず「ルートユーザ」と「IAMユーザ」という、2種類のユーザの違いについて整理しておきましょう。

ルートユーザとは、AWSアカウントを開設した時点で作られる、いわば「特権的なオーナー」です。このユーザは、すべてのサービスへのアクセスはもちろん、契約の解除や課金情報の変更に至るまで、AWS内のありとあらゆる操作が可能な、非常に強力な権限を持っています。ログイン画面ではどちらかを選択できますが、日常的な作業でルートユーザを使うことは、AWS公式からも強く非推奨とされています。

その最大の理由は、セキュリティリスクの大きさにあります。もし万が一、何でもできてしまうルートユーザの認証情報が外部に漏れてしまった場合、攻撃者にアカウント全体を完全に支配され、高額な不正利用やシステムの破壊など、取り返しのつかない被害を受ける可能性があるからです。

そのため、最初の設定が終わったらルートユーザは厳重に保管して封印し、普段の運用では、必要な権限だけを与えた「IAMユーザ」を別途作成して操作を行うのが、AWSにおけるセキュリティの鉄則となっています。

マネジメントコンソールの操作

IAMユーザを利用する大きな目的の一つに、ブラウザ画面であるAWSマネジメントコンソールへのログインがあります。ただし、作成したすべてのIAMユーザが必ずしもログインできるわけではありません。あくまで、マネジメントコンソールへのアクセス権限を与えられたユーザのみが、ログインして画面操作を行うことが可能です。

また、ログイン認証には一般的にIDとパスワードを用いますが、現代のセキュリティ基準ではそれだけでは不十分であり、多要素認証（MFA）を組み合わせることが強く推奨されています。このMFAの具体的な手段としては、Google Authenticatorなどのスマートフォン上の認証アプリや、YubiKeyのような物理的なセキュリティキーなどが利用できます。

アクセスキー

IAMユーザには、人間が管理画面で操作する以外にもう一つ、システムやアプリケーションが利用するという重要な役割があります。これは、コマンドラインツールであるCLIや、プログラムコードであるSDKなどを通じて、システムが自動的にAWSリソースを操作する場合などが該当します。

このようなプログラムによるアクセスを行う際には、通常のログインパスワードの代わりに「アクセスキー」という認証情報を使用します。これは、「アクセスキーID」と「シークレットアクセスキー」という2種類の長い文字列がペアになったもので、これをプログラム側に設定することで認証を行います。

このアクセスキーの注意点として、これらにはパスワードのような「有効期限」が自動的には設定されないという特徴があります。つまり、一度発行すると、意図的に削除しない限り永久に使用可能な状態が続きます。そのため、セキュリティを高めるためには、定期的に新しいキーに作り変える「ローテーション」という運用が推奨されています。

また、万が一アクセスキーが外部に漏洩してしまった場合や、その疑いがある場合の対処法も知っておく必要があります。アクセスキーは、AWSの管理画面から即座に「無効化」あるいは「削除」することが可能です。漏洩に気づいた時点で速やかにそのキーを無効化すれば、それ以降、そのキーを使った不正アクセスは一切できなくなります。ユーザそのものを削除する必要はなく、問題のあるキーだけを停止できるため、緊急時の初動対応として非常に重要です。

アクセスキーは非常に強力な権限を持ちうるため、プログラム操作の予定がないユーザには発行しないこと、そして発行する場合でも必要最小限の権限に絞ることが鉄則です。

2.2 IAMポリシー

ユーザに対して具体的にどのような権限を与えるかを定義するIAMポリシーについて解説します。

IAMポリシーとは

IAMポリシーとは、一言で言えば「許可証」や「ルールブック」のようなものです。先ほど、IAMユーザを作っただけでは何もできないと説明しましたが、それはこのポリシーがまだ設定されていないからです。AWSのセキュリティには「明示的に許可されていない操作は、すべて拒否される」という「デフォルト拒否」の大原則があります。つまり、生まれたばかりのIAMユーザは、真っ白な状態で何も権限を持っていません。そこにIAMポリシーというルールブックを関連付けることで初めて、特定の操作が可能になります。

ポリシーの実態

このポリシーの実体は、JSON（ジェイソン）と呼ばれる形式で記述されたテキストデータです。中身には大きく分けて、「Effect（許可するか拒否するか）」「Action（どの操作を）」「Resource（どのリソースに対して）」という3つの要素が書かれています。例えば、「S3の（Resource）、一覧表示操作を（Action）、許可する（Effect）」といった具合です。

ポリシーの種類

また、IAMポリシーには、AWSがあらかじめ用意してくれている「AWS管理ポリシー」と、利用者が自分で細かく記述する「カスタマー管理ポリシー」があります。初心者のうちは、AWSが用意した既存のポリシーを使うことが多いですが、よりセキュリティを高めるためには、自分で記述して必要最小限の権限を作ることも重要になってきます。

このように、IAMユーザという「人」に対して、IAMポリシーという「許可証」を渡すことで、適切な権限管理が実現されるのです。

2.3 IAMグループ

IAMユーザとIAMポリシーを効率的に管理するための仕組みであるIAMグループについて解説します。

これまで説明した通り、権限を与えるには「ユーザ」に「ポリシー」をアタッチ（関連付け）する必要があります。しかし、もし社員が10人、100人と増えた場合、一人ひとりのユーザに対して毎回同じポリシーを設定していくのは非常に手間がかかりますし、設定ミスや漏れが発生するリスクも高まります。

そこで登場するのが「IAMグループ」です。これは文字通り、複数のIAMユーザをまとめて管理するための「箱」や「部署」のようなものです。

IAMグループの最大の特徴は、「ポリシーをグループに対してアタッチできる」という点です。例えば、「開発部」というグループを作成し、そこに「開発に必要な権限（ポリシー）」をまとめて設定します。あとは、個々のIAMユーザをこのグループに追加するだけで、そのユーザは自動的にグループに設定された権限を継承します。

この仕組みを使うと、運用が劇的に楽になります。例えば、新しいメンバーが入社したときは、その人のユーザを作成して「開発部グループ」に入れるだけで権限設定が完了します。また、開発チーム全体の権限を変更したい場合も、グループについたポリシーを一つ変更するだけで、所属する全員に即座に反映されます。

なお、注意点として、IAMグループはあくまで管理上の枠組みであり、ユーザのような「ID（アイデンティティ）」ではありません。そのため、グループ自体としてログインしたり、グループに対してアクセスキーを発行したりすることはできません。あくまで、ユーザを束ねて権限を配るための便利な機能だと覚えておいてください。

2.4 IAMロール

最後に、IAMの中で最も重要であり、多くの初学者がつまずきやすいIAMロールについて解説します。

IAMロールとは

IAMロールは、これまでのIAMユーザとは概念が少し異なります。IAMユーザが「特定の人物やシステム」に紐づくIDだとすれば、IAMロールは「特定の役割」そのものを指します。わかりやすい例えとして、IAMロールはよく「帽子」や「制服」に例えられます。この帽子をかぶる（ロールを引き受ける）ことで、一時的にその役割に応じた権限を行使できるようになる、という仕組みです。

2つのポリシー

このIAMロールを正しく理解するためには、ロールが「2つのポリシー」によって構成されていることを知っておく必要があります。

一つ目は「許可ポリシー (Permissions Policy)」です。これは、これまで説明してきたIAMポリシーと同じもので、「帽子をかぶっている間に何ができるか」を定義します。「S3のデータを読める」「EC2を操作できる」といった具体的な権限の中身です。

二つ目が、IAMロール特有の「信頼ポリシー (Trust Policy)」です。これは、「誰にその帽子をかぶることを許可するか」を定義する重要なルールです。強力な権限を持つ帽子が誰でもかぶれる状態にあると危険なため、「このロールはEC2インスタンスだけが使用できる」「特定のユーザだけが使用できる」といった具合に、ロールを使用できる対象（プリンシパル）を厳密に指定します。

IAMロールの使い方

EC2がIAMロールを使ってS3にアクセスする流れを以下に示します。

sequenceDiagram
    participant EC2 as EC2インスタンス
    participant STS as AWS STS
    participant S3 as S3バケット

    EC2->>STS: IAMロールの引き受けを要求
    STS->>STS: 信頼ポリシーを検証
    STS->>EC2: 一時的な認証情報を発行
    EC2->>S3: 一時的な認証情報でアクセス
    S3->>S3: 許可ポリシーを検証
    S3->>EC2: アクセス許可・データ返却

また、IAMロールのもう一つの大きな特徴として、「パスワードやアクセスキーといった長期的な認証情報を持たない」という点があります。IAMユーザはずっと同じパスワードを使い続けますが、IAMロールを使用する場合は、信頼ポリシーで許可された対象だけが「一時的なセキュリティ認証情報」を受け取ることができます。この一時的な鍵は時間が経つと自動的に無効になるため、万が一漏洩しても被害を最小限に抑えることができ、非常にセキュアです。

この仕組みが最も活躍するのは、EC2などのAWSリソースから他のサービスを操作する場合です。例えば、EC2に「S3を操作できるIAMロール」を割り当てたとします。これは、信頼ポリシーで「このEC2ならOK」と許可し、許可ポリシーで「S3操作」を与えた状態です。これにより、EC2はアクセスキーを管理することなく、安全にS3へアクセスできるようになります。

このように、IAMロールは「許可ポリシー（何ができるか）」と「信頼ポリシー（誰ができるか）」をセットで定義し、AWSのリソースなどに一時的かつ安全に権限を貸し出すための仕組みなのです。

3. IAMポリシーの書き方

3.1 IAMポリシーの基本文法

IAMユーザやIAMロールの権限を具体的に記述する「IAMポリシー」の書き方について見ていきましょう。

IAMポリシーは、実際にはJSON（ジェイソン）という形式で記述されます。まずは、実際のポリシーの例を見てみましょう。以下は、「特定のS3バケットの中身（ファイル一覧）を見ることを許可する」という、非常にシンプルなポリシーです。

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "s3:ListBucket",
            "Resource": "arn:aws:s3:::example-bucket"
        }
    ]
}

少し難しそうに見えるかもしれませんが、重要なのは Statement の中にある3つの要素だけです。これらが権限の「3点セット」になっています。

3.2 Effect（効果）

まず、1つ目の要素である Effect（効果）についてです。ここには、例えば "Effect": "Allow" のように記述し、その操作を「許可（Allow）」するのか、それとも「拒否（Deny）」するのかを指定します。AWSには基本的に「何も書かれていなければすべて拒否される」というルールがあるため、通常はここに Allow と記述して、特定の操作ができるように許可を与えていきます。

3.3 Action（操作）

次に、2つ目の要素である Action（操作）についてです。ここには、具体的に「どのような操作」を許可したいのかを記述します。例えば "Action": "s3:ListBucket" のように、基本的には「サービス名:操作内容」という形式で指定します。この例であれば、「S3サービスの、バケット一覧を表示する（ListBucket）」という操作を指しています。また、ここには一つの操作だけでなく、カンマで区切って複数の操作をまとめて記述することも可能です。

3.4 Resource（対象）

最後に、3つ目の要素である Resource（対象）についてです。ここには、その操作を「どのリソース（対象）」に対して行わせるかを指定します。例えば "Resource": "arn:aws:s3:::example-bucket" と記述した場合、これは example-bucket という特定のバケットだけを操作の対象にする、という意味になります。一方で、もし特定のバケットに限らず「すべてのS3バケット」を対象にしたい場合は、アスタリスク（ワイルドカード）を使って "Resource": "*" と記述します。

つまり、IAMポリシーを書くということは、これら3つをつなぎ合わせて「どのリソース（Resource）に対して、何の操作（Action）を、許可する（Effect）」という短い文章を作成する作業に他なりません。この基本構造さえ理解しておけば、複雑に見えるポリシーもスムーズに読み解けるようになります。

4. 主なユースケース

IAMは、AWSを利用するすべての場面で必要となる基盤サービスです。以下に代表的なユースケースを紹介します。

4.1 チームメンバーのアクセス管理

開発チームのメンバーそれぞれにIAMユーザを作成し、役割に応じた権限を付与します。開発者には開発環境のみ、運用担当者には本番環境の参照権限、管理者には全権限といった具合に、職務に応じた適切なアクセス制御を実現できます。

4.2 EC2やLambdaからのAWSリソース操作

IAMロールを使用して、EC2インスタンスやLambda関数からS3やDynamoDBなどの他のAWSサービスに安全にアクセスします。アクセスキーをコードに埋め込む必要がなく、一時的な認証情報で安全に操作できます。

4.3 外部サービスとの連携（OIDC）

GitHub ActionsなどのCI/CDツールからAWSリソースを操作する際に、OIDCプロバイダを使用した一時的な認証を行います。長期的なアクセスキーを外部に保存する必要がなく、セキュリティリスクを大幅に低減できます。

5. 設計のポイント

IAMを設計する際の主要な検討項目を以下にまとめます。

6. まとめ

この講座では、AWSの認証・認可を担うIAMについて学びました。

• 認証（Authentication）は「誰なのか」を確認するプロセス、認可（Authorization）は「何ができるか」を決めるプロセス
• IAMユーザはログインやAPI操作のためのIDで、ルートユーザとは異なり必要最小限の権限で運用する
• IAMポリシーはJSON形式で記述され、Effect・Action・Resourceの3要素で権限を定義する
• IAMグループは複数のユーザをまとめて権限管理するための仕組み
• IAMロールは「信頼ポリシー」と「許可ポリシー」を持ち、EC2などのリソースに一時的な権限を付与する