AWS IAMとは？初心者向けに基本を徹底解説
この記事では、AWSを利用する上で避けては通れない重要なサービス、AWS Identity and Access Management (IAM) について、初心者の方にもわかりやすく徹底的に解説します。AWSを安全に使い始めるために、IAMの基本概念から具体的な使い方、ベストプラクティスまで、この記事一本でマスターできることを目指します。AWSの学習を始めたばかりの方や、IAMの概念がよく理解できていないという方は、ぜひ最後までお読みください。
AWSを使い始めると、様々なサービス（例えば、仮想サーバーであるEC2やストレージサービスのS3など）を利用することになります。これらのサービスは、インターネット経由でアクセスし、操作することが可能です。しかし、誰でも自由にこれらのサービスを操作できてしまうと、セキュリティ上の大きな問題が発生します。
IAMが必要な理由は、主に以下の点にあります。
AWSアカウントを作成した直後は、すべての権限を持つ「ルートユーザー」が存在します。しかし、日常的な作業にルートユーザーを使用することは、セキュリティリスクが非常に高いため推奨されません。IAMを使って個別のユーザーを作成し、必要最小限の権限を付与して利用することが、AWSにおけるセキュリティの基本となります。
IAMを理解するためには、いくつかの重要な構成要素を知る必要があります。これらはIAMのポリシー（権限設定）を作成・管理する上で、中心的な役割を果たします。
ルートユーザーとは異なり、新しく作成されたIAMユーザーは、デフォルトでは何の権限も持っていません。AWSリソースにアクセスさせるためには、後述するポリシーをユーザーにアタッチする必要があります。
IAMグループは、複数のIAMユーザーをまとめるための集合です。例えば、「開発者グループ」や「運用担当者グループ」といったように、職務や役割に応じてユーザーをグループ化します。
グループに対してポリシーをアタッチすると、そのグループに所属する全てのユーザーが、そのポリシーで許可された権限を持つことになります。これにより、ユーザー一人ひとりに個別にポリシーを設定する手間が省け、権限管理を効率化できます。
IAMロールは、特定のAWSサービスや、別のAWSアカウント、あるいはオンプレミス環境からAWSにアクセスするエンティティ（実体）に権限を付与するためのものです。ユーザーとは異なり、特定の個人に恒久的に紐づくものではありません。
ロールは、必要なときに引き受けて（AssumeRole）、一時的な認証情報（アクセスキー、シークレットアクセスキー、セッショントークン）を取得して使用します。これにより、ユーザーやアプリケーションが長期的な認証情報を持つ必要がなくなり、セキュリティリスクを低減できます。
ロールの一般的な利用例：
IAMユーザーは「特定の個人」や「特定のアプリケーションインスタンス」など、恒常的にAWSにアクセスする必要がある場合に適しています。一方、IAMロールは「特定のサービスが別のサービスにアクセスする場合」や「一時的なアクセスが必要な場合」、「異なるアカウント間でのアクセス」などに適しています。恒久的な認証情報を持たせない運用が可能になる点が、ロールの大きなメリットです。
情報を整理するために、IAMユーザーとIAMロールの主な違いを以下のテーブルにまとめました。
| 特徴 | IAMユーザー | IAMロール |
|---|---|---|
| 利用主体 | 特定の個人、または恒常的に稼働するアプリケーション | AWSサービス、別アカウント、フェデレーションユーザーなど |
| 認証情報 | パスワード（コンソール用）、アクセスキー（プログラム用）。 恒久的。 | 一時的な認証情報（アクセスキー、シークレットアクセスキー、セッショントークン）。 ロールを引き受けた際に発行され、有効期限がある。 |
| 利用方法 | 直接ログインまたはアクセスキーを使用して操作 | ロールを引き受けて一時的な認証情報を取得し、その認証情報を使用して操作 |
| 権限付与 | ユーザーまたはユーザーが所属するグループにポリシーを直接アタッチ | ロールにポリシーをアタッチし、信頼ポリシーでそのロールを引き受けられるエンティティを指定 |
| 主な用途 | 個人のAWSアカウントへのアクセス、特定のアプリケーションからのアクセス | サービス間連携、クロスアカウントアクセス、一時的な権限付与、IDフェデレーション |
IAMポリシーは、AWSリソースに対するアクセス権限を定義するドキュメントです。JSON形式で記述され、「誰が」、「何を」、「どこに」、「どのような条件で」実行できるかを詳細に指定します。
ポリシーは、以下の要素で構成されます。
Allow) するか、拒否 (Deny) するかを指定します。s3:GetObject, ec2:RunInstances）。ワイルドカード (*) も使用可能です。IAMポリシーには、主に以下の2種類があります。
どちらのタイプのポリシーも、AWSリソースへのアクセス制御に利用されますが、権限を定義する主体が異なります。アイデンティティベースのポリシーは「誰に何を許可するか」、リソースベースのポリシーは「このリソースに誰からのアクセスを許可するか」を定義すると考えると分かりやすいでしょう。
| 特徴 | アイデンティティベースのポリシー | リソースベースのポリシー |
|---|---|---|
| アタッチ先 | IAMユーザー、グループ、ロール | S3バケット、SQSキュー、KMSキーなどの対応リソース |
| 権限の定義主体 | 権限を持つエンティティ（ユーザー、グループ、ロール） | 保護されるリソース |
| 主な用途 | AWSアカウント内のユーザーやサービスに権限を付与 | リソースへのクロスアカウントアクセス制御、リソースへのパブリックアクセス制御 |
| ポリシー例の抜粋 | “`json { “Effect”: “Allow”, “Action”: “s3:GetObject”, “Resource”: “arn:aws:s3:::my-bucket/*” }“` （このポリシーを持つエンティティは、my-bucketのオブジェクトを取得できる） | “`json { “Effect”: “Allow”, “Principal”: { “AWS”: “arn:aws:iam::123456789012:user/Alice” }, “Action”: “s3:GetObject”, “Resource”: “arn:aws:s3:::my-bucket/*” }“` （my-bucketのオブジェクトは、アカウント123456789012のユーザーAliceから取得できる） |
アイデンティティベースのポリシーは、さらに「管理ポリシー」と「インラインポリシー」に分けられます。
特別な理由がない限り、カスタマー管理ポリシーを使用することが推奨されます。再利用性が高く、変更管理が容易になるためです。インラインポリシーは、特定のエンティティに固有のごく限られた権限設定が必要な場合に検討しましょう。
ユーザーやサービスがAWSリソースに対して何らかの操作をリクエストした際、IAMはどのようにしてその操作を許可するか拒否するかを決定するのでしょうか？ これには特定の評価ロジックがあります。
基本的な考え方は以下の通りです。
Allow) されている必要があります。Deny) が含まれている場合、そのリクエストは拒否されます。明示的な拒否は、明示的な許可よりも優先されます。つまり、「許可されなければ拒否される」が基本であり、「拒否は許可に勝る」というルールで評価が行われます。
この評価ロジックは、アイデンティティベースのポリシーとリソースベースのポリシーの両方が存在する場合にも適用されます。あるリクエストが、アイデンティティベースのポリシーでは許可されているが、リソースベースのポリシーでは拒否されている場合、そのリクエストは拒否されます。逆に、アイデンティティベースのポリシーで拒否されている場合、リソースベースのポリシーで許可されていても拒否されます。両方で明示的に許可されている場合のみ、許可されます。
ポリシー設定を行う際は、意図しない権限を付与したり、必要な権限を与えられなかったりしないよう、この評価ロジックをしっかり理解しておくことが非常に重要です。特に、ワイルドカード (*) の使用には細心の注意が必要です。
多要素認証 (Multi-Factor Authentication, MFA) は、ログイン時にパスワードだけでなく、もう一つの認証要素（例えば、スマートフォンの認証アプリやハードウェアトークン）を要求することで、セキュリティを大幅に向上させる仕組みです。
特に、AWSアカウントのルートユーザーや管理者権限を持つIAMユーザーに対しては、必ずMFAを有効にすることが強く推奨されています。これにより、万が一パスワードが漏洩しても、不正ログインを防ぐことができます。
AWSを安全かつ効率的に運用するために、IAMではいくつかのベストプラクティスが推奨されています。これらを実践することで、セキュリティリスクを低減し、管理の手間を省くことができます。
これらのベストプラクティスを継続的に実践することで、AWS環境のセキュリティレベルを高く保つことができます。
ここでは、IAMコンソールやAWS CLIを使ってどのようにIAMを設定するのか、概念的な例をいくつか紹介します。
my-data-bucket) 内のオブジェクトに対するs3:GetObjectアクションのみを許可するカスタマー管理ポリシーを作成します。json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-data-bucket/*"
}
]
}data-reader-user) を作成します。data-reader-user にアタッチします。これで、data-reader-user は my-data-bucket 内のオブジェクトを読み取ることのみが可能となり、それ以外のS3操作（書き込み、削除など）や他のAWSサービスへのアクセスは拒否されます。
my-app-data) に対する dynamodb:PutItem, dynamodb:GetItem, dynamodb:UpdateItem アクションなどを許可するカスタマー管理ポリシーを作成します。json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"dynamodb:PutItem",
"dynamodb:GetItem",
"dynamodb:UpdateItem"
],
"Resource": "arn:aws:dynamodb:REGION:ACCOUNT-ID:table/my-app-data"
}
]
}REGION と ACCOUNT-ID は実際の値に置き換えます。EC2-DynamoDB-Access-Role) を作成し、信頼ポリシーでEC2サービスがこのロールを引き受けられるように設定します。json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}EC2-DynamoDB-Access-Role にアタッチします。EC2-DynamoDB-Access-Role をインスタンスプロフィールとしてアタッチします。これにより、そのEC2インスタンス上で実行されるアプリケーションは、IAMロールを通じて一時的な認証情報を取得し、my-app-data テーブルに対して許可された操作を実行できるようになります。インスタンス内にアクセスキーをハードコーディングする必要はありません。
IAM Identity Center (旧称 AWS Single Sign-On) は、複数のAWSアカウントやサードパーティのアプリケーション（Salesforce, Microsoft 365など）へのアクセスを一元的に管理できるサービスです。
IAM Identity Centerは、多数のAWSアカウントを運用している組織や、オンプレミス環境のActive Directoryと連携してユーザー管理を行いたい場合に非常に有効です。IAMユーザーやロールと組み合わせて使用することで、より高度で一元化されたアクセス管理を実現できます。
IAMの設定は強力である反面、誤った設定をすると意図しない「アクセス拒否」や、逆に「過剰な権限付与」を引き起こす可能性があります。IAM関連のトラブルシューティングに役立つツールや考え方を紹介します。
「アクセス拒否」エラーに遭遇した場合、まずはCloudTrailログでエラーイベントの詳細を確認し、次にIAM Policy Simulatorで関連するポリシーをテストしてみるのが一般的なトラブルシューティングの流れです。
この記事では、AWSのセキュリティにおいて最も基本的ながら最も重要なサービスであるIAMについて、その概要、主要な構成要素（ユーザー、グループ、ロール、ポリシー）、権限評価ロジック、ベストプラクティス、そして関連サービスであるIAM Identity Centerについて解説しました。
IAMは、AWSリソースへのアクセスを安全に制御し、最小権限の原則を実践するための基盤となります。ルートユーザーの適切な管理から始まり、IAMユーザー、グループ、ロール、そしてポリシーを組み合わせて使用することで、組織のセキュリティ要件を満たしつつ、効率的なアクセス管理を実現できます。
IAMはAWSの学習初期につまずきやすいポイントの一つですが、その概念と使い方をしっかりと理解することで、AWSをより安全に、そして自信を持って利用できるようになります。この記事が、皆様のIAM理解の一助となれば幸いです。
さあ、今日からIAMのベストプラクティスを実践し、あなたのAWS環境のセキュリティを一層強化しましょう！