「IAMってセキュリティの設定？難しそう……」「ポリシーとかロールとか、用語が多すぎてわからない」
AWSを使い始めると、必ず設定することになるのがIAM（アイアム）です。セキュリティに関わる重要な機能ですが、用語が多くて最初は混乱しがちです。
この記事では、IAMの基本を会社の組織に例えながら、わかりやすく解説します。
IAMとは？一言でいうと「AWSの入館証・権限管理システム」
IAM（Identity and Access Management）とは、AWSリソースへのアクセスを安全に管理するためのサービスです。
もっと身近な例えで言うと、「会社の入館証と権限カードを管理するシステム」です。
会社では、社員証がないと建物に入れませんよね。さらに、部署や役職によって「この部屋には入れる」「この情報にはアクセスできる」という権限が決まっています。IAMは、まさにこれをAWS上で実現するサービスです。
IAMでできること
- 誰がAWSにアクセスできるかを管理（認証）
- 何ができるかを管理（認可）
- どのリソースに対して操作できるかを制限
- いつ・どこからアクセスできるかを制限
なぜIAMが重要なの？
AWSアカウントには、EC2やS3など、企業にとって重要なリソースがたくさんあります。もし誰でも自由にアクセスできたら、大変なことになりますよね。
- 重要なデータを削除されてしまう
- 高額なリソースを勝手に作られて、請求が跳ね上がる
- 機密情報が外部に漏洩する
IAMを適切に設定することで、これらのリスクを防ぐことができます。
IAMの4つの主要コンポーネント
IAMには、理解しておくべき4つの主要なコンポーネントがあります。会社組織に例えながら、ひとつずつ見ていきましょう。
1. IAMユーザー
IAMユーザーは、AWSを利用する個人やアプリケーションを表します。会社でいえば「社員一人ひとり」にあたります。
IAMユーザーには以下の認証情報を設定できます。
| 認証情報 | 用途 |
|---|---|
| パスワード | AWSマネジメントコンソール（Web画面）へのログイン |
| アクセスキー | AWS CLIやSDKからのプログラムによるアクセス |
重要な注意点として、ルートユーザー（AWSアカウント作成時のユーザー）は日常的に使わないようにしましょう。ルートユーザーはすべての権限を持つため、万が一乗っ取られると大変危険です。日常業務にはIAMユーザーを作成して使用します。
2. IAMグループ
IAMグループは、IAMユーザーをまとめるための仕組みです。会社でいえば「部署」や「チーム」にあたります。
例えば「開発チーム」「運用チーム」「経理チーム」のようなグループを作成し、グループに権限を付与します。そのグループに所属するユーザーは、自動的にその権限を持つことになります。
ユーザー一人ひとりに権限を設定するより、グループで管理した方が効率的で、ミスも減らせます。
3. IAMロール
IAMロールは、一時的に権限を付与するための仕組みです。会社でいえば「一時的に渡す特別な権限カード」のようなものです。
IAMユーザーとの大きな違いは以下の通りです。
| 項目 | IAMユーザー | IAMロール |
|---|---|---|
| 対象 | 特定の人やアプリケーション | 信頼されたエンティティ（AWSサービス、他のアカウントなど） |
| 認証情報 | 長期的（パスワード、アクセスキー） | 一時的（自動的に発行・期限切れ） |
| 利用例 | 開発者がコンソールにログイン | EC2からS3にアクセス、Lambda関数の実行など |
例えば、EC2インスタンスからS3にアクセスしたいとき、IAMロールをEC2にアタッチします。すると、EC2は一時的な認証情報を自動取得し、S3にアクセスできるようになります。
4. IAMポリシー
IAMポリシーは、「何ができるか・できないか」を定義したルールです。会社でいえば「権限規程」や「アクセス権限リスト」にあたります。
ポリシーはJSON形式で記述され、ユーザー、グループ、ロールにアタッチして使います。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "s3:GetObject",
"Resource": "arn:aws:s3:::my-bucket/*"
}
]
}
上記の例は「my-bucketというS3バケットからオブジェクトを取得することを許可する」というポリシーです。
ポリシーの種類
IAMポリシーにはいくつかの種類があります。
| 種類 | 説明 | 使いどころ |
|---|---|---|
| AWS管理ポリシー | AWSが用意した既製のポリシー | 一般的な権限設定に便利 |
| カスタマー管理ポリシー | 自分で作成するポリシー | 細かい権限制御が必要なとき |
| インラインポリシー | ユーザー/グループ/ロールに直接埋め込むポリシー | 特定のエンティティ専用の権限 |
まずはAWS管理ポリシーを使うことをおすすめします。「AmazonS3ReadOnlyAccess」「AmazonEC2FullAccess」など、よく使う権限の組み合わせがあらかじめ用意されています。
最小権限の原則（Least Privilege）
IAMを設定するうえで、最も重要な考え方が「最小権限の原則」です。
これは、「必要な権限だけを、必要な人に、必要な期間だけ与える」という考え方です。
なぜ最小権限が大切なの？
「面倒だから全員に管理者権限（AdministratorAccess）を与えておこう」という運用は危険です。
- 誤操作で重要なリソースを削除してしまうリスク
- アカウントが乗っ取られた場合の被害が最大化
- 誰が何をしたか追跡しにくくなる
実践のコツ
最小権限を実践するためのコツを紹介します。
- 最初は必要最低限の権限から始める：足りなければ後から追加
- AWS管理ポリシーの「ReadOnly」系から始める：参照のみなら安全
- IAM Access Analyzerを活用する：未使用の権限を検出できる
- 定期的に権限を見直す：不要になった権限は削除
MFA（多要素認証）を設定しよう
MFA（Multi-Factor Authentication）は、パスワードに加えて、もう一つの認証要素を追加するセキュリティ機能です。
銀行のワンタイムパスワードと同じ仕組みで、スマートフォンのアプリ（Google Authenticatorなど）に表示される6桁のコードを入力します。
MFAを設定すべきユーザー
- ルートユーザー：必ず設定すべき（最重要）
- 管理者権限を持つIAMユーザー：強く推奨
- 本番環境にアクセスできるユーザー：推奨
特にルートユーザーへのMFA設定は、AWSのセキュリティベストプラクティスで強く推奨されています。
IAM Identity Center（旧AWS SSO）
複数のAWSアカウントを管理する場合は、IAM Identity Centerの利用がおすすめです。
IAM Identity Centerを使うと、以下のようなメリットがあります。
- シングルサインオン：一度のログインで複数のAWSアカウントにアクセス
- 一元管理：ユーザーと権限を中央で管理
- 既存のIDプロバイダーと連携：Active DirectoryやOktaなどと統合可能
個人や小規模なプロジェクトではIAMユーザーで十分ですが、企業での利用ではIAM Identity Centerの検討をおすすめします。
よくある設定パターン
実際によく使われるIAMの設定パターンを紹介します。
パターン1：開発者用の権限設定
開発者には、開発に必要なサービスへのアクセス権限を付与し、本番環境へのアクセスは制限します。
- EC2、S3、RDS、Lambdaなどへの読み書き権限
- 本番環境のリソースには「ReadOnly」のみ
- IAMの変更権限は付与しない
パターン2：EC2からS3へのアクセス
EC2インスタンスからS3バケットにアクセスする場合は、IAMロールを使用します。
- S3へのアクセス権限を持つIAMロールを作成
- EC2インスタンスにIAMロールをアタッチ
- EC2内のアプリケーションは、自動的にS3にアクセス可能に
アクセスキーをEC2内に保存するのはアンチパターンです。必ずIAMロールを使用しましょう。
パターン3：Lambda関数の実行権限
Lambda関数が他のAWSサービスにアクセスする場合も、IAMロールを使用します。
- Lambda関数に必要な権限を持つIAMロールを作成
- Lambda関数の「実行ロール」として設定
- Lambda関数は、ロールに定義された権限の範囲でAWSサービスにアクセス可能
2025年のIAMトピック
IAMに関連する機能も日々進化しています。2025年の主なトピックをいくつか紹介します。
IAMベースのアカウント名更新
2025年4月、AWS Organizationsを利用している場合、ルートユーザーを使わずにIAMプリンシパルでアカウント名を更新できるようになりました。ルートユーザーの日常利用を避けるベストプラクティスに沿った改善です。
サービス参照情報の拡張
2025年7月、IAMの最終アクセス情報やポリシー生成でサポートされるサービスアクション情報が拡張されました。これにより、最小権限の実現がより容易になっています。
IAM Access Analyzerの機能強化
IAM Access Analyzerでは、ポリシーの文法チェックやベストプラクティス違反の検出を自動化する機能が強化されています。VS Code連携も追加され、開発段階でセキュリティリスクを検出できるようになりました。
IAMのベストプラクティス
AWSが推奨するIAMのベストプラクティスをまとめます。
| ベストプラクティス | 説明 |
|---|---|
| ルートユーザーを日常的に使わない | ルートユーザーはMFAを設定し、緊急時のみ使用 |
| 個々のIAMユーザーを作成 | 共有アカウントは使わず、一人一つのユーザーを作成 |
| グループを使って権限を管理 | ユーザー個別ではなく、グループに権限を付与 |
| 最小権限の原則を適用 | 必要な権限のみを付与し、定期的に見直す |
| MFAを有効化 | 特にルートユーザーと管理者には必須 |
| アクセスキーを共有しない | アクセスキーは個人ごとに発行し、定期的にローテーション |
| IAMロールを活用 | EC2やLambdaからのアクセスにはロールを使用 |
| 強力なパスワードポリシー | 長さ、複雑さ、有効期限などのルールを設定 |
まとめ
この記事で解説した内容をまとめます。
| 項目 | ポイント |
|---|---|
| IAMとは | AWSリソースへのアクセスを安全に管理するサービス |
| IAMユーザー | AWSを利用する個人やアプリケーション |
| IAMグループ | ユーザーをまとめて権限を管理する仕組み |
| IAMロール | 一時的に権限を付与する仕組み（EC2やLambdaで使用） |
| IAMポリシー | 何ができるか・できないかを定義したルール |
| 最小権限の原則 | 必要な権限だけを、必要な人に、必要な期間だけ与える |
| MFA | パスワード＋もう一つの認証で安全性を高める |
IAMはAWSセキュリティの基盤です。最初は難しく感じるかもしれませんが、「会社の入館証と権限管理」という例えで考えると理解しやすくなります。
まずは自分用のIAMユーザーを作成し、MFAを設定するところから始めてみましょう。
SKサービスでは未経験からのエンジニア転職をサポート
SKサービス株式会社では、完全未経験からエンジニアを目指す方を積極採用しています。
正社員として安定した環境で働きながら、さまざまなプロジェクトで実践経験を積むことができます。受託開発も手掛けており、スキルアップに応じてキャリアの幅を広げていける環境です。
「AWSのセキュリティ設計ができるようになりたい」「クラウドエンジニアとしてキャリアを築きたい」という方、まずはお気軽にご相談ください。