AWS IAMとは？初心者向けに基本を徹底解説

この記事では、AWSを利用する上で避けては通れない重要なサービス、AWS Identity and Access Management (IAM) について、初心者の方にもわかりやすく徹底的に解説します。AWSを安全に使い始めるために、IAMの基本概念から具体的な使い方、ベストプラクティスまで、この記事一本でマスターできることを目指します。AWSの学習を始めたばかりの方や、IAMの概念がよく理解できていないという方は、ぜひ最後までお読みください。

AWS IAMとは？なぜ必要なのか？

AWSを使い始めると、様々なサービス（例えば、仮想サーバーであるEC2やストレージサービスのS3など）を利用することになります。これらのサービスは、インターネット経由でアクセスし、操作することが可能です。しかし、誰でも自由にこれらのサービスを操作できてしまうと、セキュリティ上の大きな問題が発生します。

IAMが必要な理由

IAMが必要な理由は、主に以下の点にあります。

• セキュリティの確保: 不正アクセスや意図しない操作を防ぎ、AWSリソースを保護します。
• 最小権限の原則の実践: ユーザーやアプリケーションが必要最低限の権限のみを持つように設定することで、万が一のインシデント発生時の被害範囲を最小限に抑えます。
• コンプライアンスと監査: アクセス権限を適切に管理・記録することで、企業のコンプライアンス要件を満たし、監査に対応できます。
• 複数のユーザー管理: チームでAWSを利用する際に、各メンバーに適切な権限を付与し、一元管理できます。

AWSアカウントを作成した直後は、すべての権限を持つ「ルートユーザー」が存在します。しかし、日常的な作業にルートユーザーを使用することは、セキュリティリスクが非常に高いため推奨されません。IAMを使って個別のユーザーを作成し、必要最小限の権限を付与して利用することが、AWSにおけるセキュリティの基本となります。

IAMの主要な構成要素

IAMを理解するためには、いくつかの重要な構成要素を知る必要があります。これらはIAMのポリシー（権限設定）を作成・管理する上で、中心的な役割を果たします。

IAMユーザー

ルートユーザーとは異なり、新しく作成されたIAMユーザーは、デフォルトでは何の権限も持っていません。AWSリソースにアクセスさせるためには、後述するポリシーをユーザーにアタッチする必要があります。

IAMグループ

IAMグループは、複数のIAMユーザーをまとめるための集合です。例えば、「開発者グループ」や「運用担当者グループ」といったように、職務や役割に応じてユーザーをグループ化します。

グループに対してポリシーをアタッチすると、そのグループに所属する全てのユーザーが、そのポリシーで許可された権限を持つことになります。これにより、ユーザー一人ひとりに個別にポリシーを設定する手間が省け、権限管理を効率化できます。

IAMロール

IAMロールは、特定のAWSサービスや、別のAWSアカウント、あるいはオンプレミス環境からAWSにアクセスするエンティティ（実体）に権限を付与するためのものです。ユーザーとは異なり、特定の個人に恒久的に紐づくものではありません。

ロールは、必要なときに引き受けて（AssumeRole）、一時的な認証情報（アクセスキー、シークレットアクセスキー、セッショントークン）を取得して使用します。これにより、ユーザーやアプリケーションが長期的な認証情報を持つ必要がなくなり、セキュリティリスクを低減できます。

ロールの一般的な利用例：

• EC2インスタンスがS3バケットにアクセスする。
• Lambda関数がDynamoDBテーブルに書き込む。
• 別のAWSアカウントのユーザーに、自分のアカウントのリソースへの一時的なアクセスを許可する。
• 企業のActive Directoryユーザーが、フェデレーションを通じてAWSにログインする。

IAMユーザーは「特定の個人」や「特定のアプリケーションインスタンス」など、恒常的にAWSにアクセスする必要がある場合に適しています。一方、IAMロールは「特定のサービスが別のサービスにアクセスする場合」や「一時的なアクセスが必要な場合」、「異なるアカウント間でのアクセス」などに適しています。恒久的な認証情報を持たせない運用が可能になる点が、ロールの大きなメリットです。

IAMユーザーとIAMロールの比較

情報を整理するために、IAMユーザーとIAMロールの主な違いを以下のテーブルにまとめました。

IAMポリシー

IAMポリシーは、AWSリソースに対するアクセス権限を定義するドキュメントです。JSON形式で記述され、「誰が」、「何を」、「どこに」、「どのような条件で」実行できるかを詳細に指定します。

ポリシーは、以下の要素で構成されます。

• Effect: 許可 (Allow) するか、拒否 (Deny) するかを指定します。
• Action: 許可または拒否するAPIアクションを指定します（例: s3:GetObject, ec2:RunInstances）。ワイルドカード (*) も使用可能です。
• Resource: ポリシーが適用されるAWSリソースを指定します（例: 特定のS3バケット、特定のEC2インスタンス）。Amazonリソースネーム (ARN) 形式で指定するのが一般的です。ワイルドカードも使用可能です。
• Condition (Optional): ポリシーが有効になる条件を指定します（例: 特定のIPアドレスからのみアクセスを許可、特定の時間帯のみ操作を許可）。

ポリシーの種類

IAMポリシーには、主に以下の2種類があります。

1. アイデンティティベースのポリシー: IAMユーザー、グループ、ロールにアタッチされるポリシーです。「このユーザー（またはグループ、ロール）は、〇〇という操作を、△△というリソースに対して行うことができる（またはできない）」という形式で権限を定義します。
2. リソースベースのポリシー: 特定のAWSリソース（S3バケット、SQSキュー、KMSキーなど）にアタッチされるポリシーです。「このリソースに対して、〇〇というプリンシパル（アカウント、ユーザー、ロールなど）は、△△という操作を行うことができる（またはできない）」という形式で権限を定義します。

どちらのタイプのポリシーも、AWSリソースへのアクセス制御に利用されますが、権限を定義する主体が異なります。アイデンティティベースのポリシーは「誰に何を許可するか」、リソースベースのポリシーは「このリソースに誰からのアクセスを許可するか」を定義すると考えると分かりやすいでしょう。

アイデンティティベースポリシーとリソースベースポリシーの比較

管理ポリシーとインラインポリシー

アイデンティティベースのポリシーは、さらに「管理ポリシー」と「インラインポリシー」に分けられます。

• 管理ポリシー: AWSが事前に定義しているポリシー（AWS管理ポリシー）と、ユーザー自身が作成・管理するポリシー（カスタマー管理ポリシー）があります。複数のユーザーやグループ、ロールに再利用できるため、一貫性のある権限管理が可能です。
• インラインポリシー: 特定のIAMエンティティ（ユーザー、グループ、ロール）に直接埋め込まれるポリシーです。そのエンティティ以外からは参照・再利用できません。特定のエンティティ固有の、他のポリシーと共有しない権限を設定する場合に使用します。

特別な理由がない限り、カスタマー管理ポリシーを使用することが推奨されます。再利用性が高く、変更管理が容易になるためです。インラインポリシーは、特定のエンティティに固有のごく限られた権限設定が必要な場合に検討しましょう。

権限の評価ロジック

ユーザーやサービスがAWSリソースに対して何らかの操作をリクエストした際、IAMはどのようにしてその操作を許可するか拒否するかを決定するのでしょうか？ これには特定の評価ロジックがあります。

基本的な考え方は以下の通りです。

1. デフォルトでは、すべてのリクエストは暗黙的に拒否されます。
2. リクエストを許可するためには、関連するポリシーの中で明示的に許可 (Allow) されている必要があります。
3. 関連するポリシーの中に明示的な拒否 (Deny) が含まれている場合、そのリクエストは拒否されます。明示的な拒否は、明示的な許可よりも優先されます。

つまり、「許可されなければ拒否される」が基本であり、「拒否は許可に勝る」というルールで評価が行われます。

この評価ロジックは、アイデンティティベースのポリシーとリソースベースのポリシーの両方が存在する場合にも適用されます。あるリクエストが、アイデンティティベースのポリシーでは許可されているが、リソースベースのポリシーでは拒否されている場合、そのリクエストは拒否されます。逆に、アイデンティティベースのポリシーで拒否されている場合、リソースベースのポリシーで許可されていても拒否されます。両方で明示的に許可されている場合のみ、許可されます。

ポリシー設定を行う際は、意図しない権限を付与したり、必要な権限を与えられなかったりしないよう、この評価ロジックをしっかり理解しておくことが非常に重要です。特に、ワイルドカード (*) の使用には細心の注意が必要です。

多要素認証 (MFA)

多要素認証 (Multi-Factor Authentication, MFA) は、ログイン時にパスワードだけでなく、もう一つの認証要素（例えば、スマートフォンの認証アプリやハードウェアトークン）を要求することで、セキュリティを大幅に向上させる仕組みです。

特に、AWSアカウントのルートユーザーや管理者権限を持つIAMユーザーに対しては、必ずMFAを有効にすることが強く推奨されています。これにより、万が一パスワードが漏洩しても、不正ログインを防ぐことができます。

IAMのベストプラクティス

AWSを安全かつ効率的に運用するために、IAMではいくつかのベストプラクティスが推奨されています。これらを実践することで、セキュリティリスクを低減し、管理の手間を省くことができます。

• ルートユーザーは日常的に使用しない: ルートユーザーはアカウントの全権限を持つため、設定作業やごく限られたタスク以外では使用せず、安全に保管してください。日常的な作業には、適切な権限を持つIAMユーザーを使用します。
• 最小権限の原則に従う: ユーザー、グループ、ロールには、そのタスクを実行するために必要最低限の権限のみを付与します。必要以上の権限を与えないことで、セキュリティリスクを最小化します。
• IAMグループを使用して権限を管理する: 個々のユーザーに直接ポリシーをアタッチするのではなく、役割に応じたグループを作成し、グループにポリシーをアタッチします。これにより、ユーザーの追加や削除、役割変更時の権限管理が容易になります。
• IAMロールを使用してAWSサービスに権限を付与する: EC2インスタンスやLambda関数などが他のAWSサービスにアクセスする必要がある場合は、アクセスキーを埋め込むのではなく、IAMロールを使用します。ロールは一時的な認証情報を提供するため、認証情報漏洩のリスクを低減できます。
• 強力なパスワードポリシーを設定し、MFAを有効にする: すべてのIAMユーザーに対して、推測されにくい強力なパスワードの使用を義務付け、MFAを有効にすることを推奨します。特に特権ユーザーには必須です。
• アクセスキーを定期的にローテーションする: プログラムからのアクセスに使用するアクセスキーは、定期的に新しいものに更新し、古いキーを無効化します。
• 使用されていない認証情報を削除する: 不要になったIAMユーザー、グループ、ロール、ポリシー、アクセスキーなどは速やかに削除します。
• IAMアクティビティを監視する: AWS CloudTrailと連携し、IAMユーザーやロールによるAPIコールのログを記録・監視します。これにより、不審なアクティビティを検知できます。
• IAM Access Analyzerを利用する: 外部のエンティティ（他のAWSアカウント、外部アカウントのIAMユーザーなど）が、自分のアカウントのリソースにアクセスできるかどうかを分析し、意図しない公開設定などを特定できます。

これらのベストプラクティスを継続的に実践することで、AWS環境のセキュリティレベルを高く保つことができます。

IAMの具体的な設定例（概念）

ここでは、IAMコンソールやAWS CLIを使ってどのようにIAMを設定するのか、概念的な例をいくつか紹介します。

例1：特定のS3バケットへの読み取り専用アクセスを許可するユーザーを作成する

1. ポリシーの作成: S3の特定のバケット (my-data-bucket) 内のオブジェクトに対するs3:GetObjectアクションのみを許可するカスタマー管理ポリシーを作成します。
   json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-data-bucket/*"
}
]
}
2. ユーザーの作成: 新しいIAMユーザー (data-reader-user) を作成します。
3. ポリシーのアタッチ: 作成したカスタマー管理ポリシーを data-reader-user にアタッチします。

これで、data-reader-user は my-data-bucket 内のオブジェクトを読み取ることのみが可能となり、それ以外のS3操作（書き込み、削除など）や他のAWSサービスへのアクセスは拒否されます。

例2：EC2インスタンスから特定のDynamoDBテーブルにアクセスさせる

1. ポリシーの作成: 特定のDynamoDBテーブル (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 は実際の値に置き換えます。
2. ロールの作成: 新しいIAMロール (EC2-DynamoDB-Access-Role) を作成し、信頼ポリシーでEC2サービスがこのロールを引き受けられるように設定します。
   json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Service": "ec2.amazonaws.com"
},
"Action": "sts:AssumeRole"
}
]
}
3. ポリシーのアタッチ: 作成したDynamoDBアクセス用のカスタマー管理ポリシーを EC2-DynamoDB-Access-Role にアタッチします。
4. EC2インスタンスへのアタッチ: EC2インスタンス起動時、または起動後に、作成した EC2-DynamoDB-Access-Role をインスタンスプロフィールとしてアタッチします。

これにより、そのEC2インスタンス上で実行されるアプリケーションは、IAMロールを通じて一時的な認証情報を取得し、my-app-data テーブルに対して許可された操作を実行できるようになります。インスタンス内にアクセスキーをハードコーディングする必要はありません。

IAM Identity Center (旧AWS SSO) とは？

IAM Identity Center (旧称 AWS Single Sign-On) は、複数のAWSアカウントやサードパーティのアプリケーション（Salesforce, Microsoft 365など）へのアクセスを一元的に管理できるサービスです。

IAM Identity Centerは、多数のAWSアカウントを運用している組織や、オンプレミス環境のActive Directoryと連携してユーザー管理を行いたい場合に非常に有効です。IAMユーザーやロールと組み合わせて使用することで、より高度で一元化されたアクセス管理を実現できます。

IAMのトラブルシューティング

IAMの設定は強力である反面、誤った設定をすると意図しない「アクセス拒否」や、逆に「過剰な権限付与」を引き起こす可能性があります。IAM関連のトラブルシューティングに役立つツールや考え方を紹介します。

• AWS CloudTrail: AWSアカウント上で行われたAPI操作のログを記録します。特定の操作が誰によって、いつ、どこから行われたか、そしてその結果（成功/失敗）を確認できます。「Access Denied」エラーが発生した場合、CloudTrailログを確認することで、どのプリンシパル（ユーザーやロール）が、どのリソースに対して、どのActionを実行しようとして拒否されたのかを特定するのに役立ちます。
• IAM Policy Simulator: IAMポリシーが、指定したアクションとリソースに対して期待通りに機能するかをテストできます。実際の環境に適用する前に、ポリシーの動作を確認するのに非常に便利なツールです。特定のユーザーやロールが、特定のアクションを実行できるか/できないかをシミュレーションできます。
• IAM Access Analyzer: 前述の通り、外部エンティティからのアクセス設定を分析し、意図しないアクセスパスを特定します。
• 最小権限からのスタート: ポリシーを作成する際は、必要最低限の権限から始め、必要に応じて徐々に権限を追加していくのが安全なアプローチです。最初から広すぎる権限を付与すると、気づかないうちにセキュリティホールを作ってしまう可能性があります。

「アクセス拒否」エラーに遭遇した場合、まずはCloudTrailログでエラーイベントの詳細を確認し、次にIAM Policy Simulatorで関連するポリシーをテストしてみるのが一般的なトラブルシューティングの流れです。

まとめ

この記事では、AWSのセキュリティにおいて最も基本的ながら最も重要なサービスであるIAMについて、その概要、主要な構成要素（ユーザー、グループ、ロール、ポリシー）、権限評価ロジック、ベストプラクティス、そして関連サービスであるIAM Identity Centerについて解説しました。

IAMは、AWSリソースへのアクセスを安全に制御し、最小権限の原則を実践するための基盤となります。ルートユーザーの適切な管理から始まり、IAMユーザー、グループ、ロール、そしてポリシーを組み合わせて使用することで、組織のセキュリティ要件を満たしつつ、効率的なアクセス管理を実現できます。

• ルートユーザーのパスワードとMFAを厳重に管理する。
• 日常的な作業にはIAMユーザーを作成し、適切な権限を付与する。
• 権限管理にはグループとカスタマー管理ポリシーを積極的に利用する。
• サービス間連携や一時的な権限にはIAMロールを使用する。
• 最小権限の原則を常に意識し、必要な権限のみを付与する。
• IAM Policy Simulatorでポリシーをテストする習慣をつける。
• CloudTrailでIAMアクティビティを監視する体制を整える。

IAMはAWSの学習初期につまずきやすいポイントの一つですが、その概念と使い方をしっかりと理解することで、AWSをより安全に、そして自信を持って利用できるようになります。この記事が、皆様のIAM理解の一助となれば幸いです。

さあ、今日からIAMのベストプラクティスを実践し、あなたのAWS環境のセキュリティを一層強化しましょう！