Pocket Bundle シリーズ : AWS IAM ~ AWS リソースへの認証と認可を一元管理

AWS Identity and Access Management (IAM) は、AWS リソースへのアクセスを安全に制御するためのサービスです。AWS で行われるあらゆる操作は、まず IAM による「認証」と「認可」を通過してから実行されます。いわば、すべての API リクエストを最初に受け止める門番のような存在で、AWS セキュリティの土台を担っています。

IAM が扱うのは 2 つの問いです。1 つは「認証 (Authentication）」、つまりリクエストの送信者が名乗ったとおりの相手かどうか。もう 1 つは「認可 (Authorization）」、つまりその相手にこの操作を許可してよいかどうかです。リクエストが届くたびに、IAM は保存されたアイデンティティとポリシーに照らして可否を判定します。

IAM は特定のリージョンに属さないグローバルサービスです。作成したユーザー・ロール・ポリシーはすべてのリージョンで共通して使えます。内部的には、設定変更を受け付ける「コントロールプレーン」が米国東部 (バージニア北部) リージョンに 1 つ存在し、その内容が各リージョンの「データプレーン」（読み取り専用のレプリカ) へ伝播する構造になっています。各リージョンのデータプレーンが独立して認証・認可を行うため、IAM は高い可用性を保てるよう設計されています。

そして IAM 本体 (ユーザー・グループ・ロール・ポリシー・MFA など) は追加料金なしで利用できます。料金体系の詳細は後述の「IAM の利用料金」で扱います。

詳しくは、公式ドキュメントの「IAM とは」をご覧ください。

X ポスト » | Facebook シェア » | はてブ »

IAM がセキュリティの土台たりうる理由は、大きく 3 つの特徴に集約されます。きめ細かなアクセス制御、一時的な認証情報、そして追加料金なしであることです。

AWS リソースにアクセスするユーザーには「ルートユーザー」「IAM ユーザー」があり、複数の IAM ユーザーをまとめる仕組みとして「IAM グループ」があります (IAM ロールも主体の一種で、こちらは次のセクションで扱います)。

IAM ロールは、ユーザーや AWS サービスが一時的に「引き受ける (AssumeRole)」ことで、期限付きの認証情報を取得する仕組みです。IAM ユーザーと違って、ロール自体にはパスワードや長期的なアクセスキーが紐付いていません。誰か特定の人に固定されるのではなく、必要とする相手が一時的に身にまとう「役割」だと考えると分かりやすいでしょう。

ロールを引き受けると、AWS Security Token Service (AWS STS) が一時的な認証情報を発行します。これは「アクセスキー ID」「シークレットアクセスキー」「セキュリティトークン」の 3 点セットです。ここでの「アクセスキー ID」は、IAM ユーザーが持つ長期的なアクセスキーとは別物で、そのセッション限りの一時的なもの。長期キーと違ってセキュリティトークンに有効期限が含まれ、期限が来れば自動的に失効するのが特徴です。

IAM ポリシーは「誰が・どのリソースに・何をできるか」を JSON 形式で定義する仕組みです。1 つ以上のステートメントで構成され、基本要素に加えて任意の要素を組み合わせて権限を記述します。

MFA (Multi-Factor Authentication：多要素認証) は、サインイン時にパスワードに加えてもう 1 つの認証要素を求める仕組みです。パスワードは記憶している「知識要素」ですが、これに「所持要素 (セキュリティキーなど手元にあるもの)」や「生体要素 (指紋など本人そのもの)」を組み合わせることで、パスワードが漏えいしても不正サインインを防げます。MFA は最もシンプルかつ効果的なセキュリティ対策の 1 つです。

最小権限の原則とは、ユーザーやロールごとに業務に必要な権限「だけ」を付与する考え方です。最初から広い権限を与えてしまうと、後から絞り込むのは困難です。まずは最小限で設計し、IAM Access Analyzer で継続的に権限範囲を見直すのが安全な進め方です (詳細は IAM Access Analyzer のセクションを参照)。さらに、付与しうる権限の「上限」を別途定めたい場合は、Permissions Boundary (アクセス許可の境界) という高度な機能も使えます。これはアイデンティティベースポリシーが付与できる最大権限を制限するもので、実際の権限は「アイデンティティベースポリシーと境界の積集合」になります (境界自体は権限を付与しません)。

詳しくは、公式ドキュメントの「管理ポリシーとインラインポリシー」をご覧ください。

外部・内部アクセスの分析は「ゾーン オブ トラスト (信頼ゾーン)」という考え方が鍵です。分析対象に組織やアカウントを指定すると、その範囲内のアクセスは「信頼できる」とみなされ、範囲の外からのアクセスだけが検出対象になります。外部アクセスの検出は、リソースベースポリシーを論理的に分析し、信頼ゾーン外 (パブリックや他アカウント)に共有されているリソースを洗い出します (無料)。未使用アクセスの特定は、一定期間使われていない IAM ロール・アクセスキー・コンソールパスワード・権限を検出します (有料)。内部アクセスの可視化は、組織・アカウント内のどのプリンシパルが重要リソースにアクセスできるかを明らかにします (有料)。

ポリシーの生成・検証には、CloudTrail の操作履歴から実際に使われた権限だけのポリシーを自動生成する機能 (無料)と、100 を超えるチェック項目でポリシーの妥当性を確認するポリシー検証 (無料)があります。これらの分析の多くは、数学的証明に裏付けられた「自動推論 (provable security)」によって行われます。さらに、自社のセキュリティ基準への準拠をデプロイ前に検証するカスタムポリシーチェックは有料機能です。

⚠ 未使用アクセス分析は IAM ロール・ユーザー単位で課金されます。ロールとユーザーはグローバルなため、重複課金を避けるにはアカウントごと (または組織ごと)に 1 つのアナライザーに集約し、アナライザーの削除・再作成を繰り返さないことが推奨されます。また、内部アクセスの可視化は組織内の IAM ユーザー・ロールの合計が 70,000 を超える場合は分析結果を生成できないため、大規模組織では対象範囲の分割を検討してください。

詳しくは、公式ドキュメントの「IAM Access Analyzer の使用」をご覧ください。

AWS はリクエストごとに「認証 → ポリシー評価」を行い、アクセスの可否を判断します。複数のポリシーが関わっても結果が一意に定まるよう、可否は決まった優先順位で判定されます。

明示的 Deny (最優先)> 明示的 Allow > 暗黙的 Deny (デフォルト拒否)

判定の流れはこうです。まず、適用されるすべてのポリシー (SCP / RCP、リソースベース、アイデンティティベース、Permissions Boundary、セッションポリシー)の中に Deny が 1 つでもあれば、その時点で拒否が確定します。明示的 Deny は他のどんな Allow よりも優先されます。Deny がなければ次に Allow を探し、見つからなければ拒否 (暗黙的 Deny) になります。デフォルトはすべて拒否なので、許可するには明示的な Allow が必要です。Deny がなく Allow があれば、ようやく許可されます。

1 つ目のユースケースは、人によるアクセス管理です。職務ごとに IAM グループを作り、業務に必要な最小限の権限だけを付与します。職務単位で分けておくと、担当外の操作を防げるうえ、誤操作やインシデント時の影響範囲も小さく抑えられます。

2 つ目は、アプリケーションや AWS サービスからのアクセスです。EC2 や Lambda などに IAM ロールを付与すると、アクセスキーを埋め込まずに他の AWS リソースへ安全にアクセスできます。認証情報は自動で発行・更新されるため、キーの管理から解放されます。
EC2 インスタンスから S3 バケットへアクセスする場合、流れは次のようになります。

1. EC2 インスタンスに、インスタンスプロファイルを通じて IAM ロールを付与する
2. インスタンスはロールを引き受け、一時的な認証情報を取得する
3. その認証情報を使って S3 バケットにアクセスする

インスタンスプロファイルは、IAM ロールの情報を EC2 インスタンスに渡すためのコンテナです。コンソールで EC2 用のロールを作成すると、同名のインスタンスプロファイルが自動作成されます。インスタンス内のアプリケーションは、インスタンスメタデータサービス (IMDS) から認証情報を取得します。この認証情報は AWS によって自動的にローテーションされ、古いものが失効する 5 分以上前に新しい認証情報が用意されるため、アプリ側で更新を意識する必要はありません。なお、認証情報の取得には、SSRF (サーバーを悪用して、本来は外部から見えない内部情報を引き出す攻撃)などに強い IMDSv2 (セッショントークンを使う方式)の利用が推奨されています。新しい AMI やコンソールからの起動では IMDSv2 が使われることが多いものの、これはアカウントレベルの IMDS デフォルト設定に依存するため、起動方法だけで無条件に IMDSv2 が強制されるわけではない点には留意してください。

Lambda では「実行ロール」、ECS では「タスクロール」というように、サービスごとに同様の仕組みでロールを付与できます。いずれの場合も、アプリケーションのコードや設定ファイルにアクセスキーを書き込む必要はありません。

⚠ アクセスキーのハードコード (コードや設定ファイルへの直接埋め込み)は厳禁です。リポジトリへの誤コミットなど、漏えいの最大の原因になります。AWS サービスからのアクセスには必ず IAM ロールを使いましょう。

詳しくは、公式ドキュメントの「Amazon EC2 インスタンスで実行されるアプリケーションに IAM ロールを使用してアクセス許可を付与する」、IMDSv2 については「インスタンスメタデータサービスを使用してインスタンスメタデータにアクセスする」をご覧ください。

1. IAM は結果整合性です。ユーザー・グループ・ロール・ポリシーの作成や変更が、世界中のすべてのエンドポイントへ即座に反映されるとは限りません。サーバー間・リージョン間のデータ伝播やキャッシュにより、変更が見えるまで時間差が生じることがあります。そのため、IAM の変更はアプリケーションの重要な処理経路 (クリティカルパス)には組み込まず、初期化やセットアップの処理にまとめ、反映を確認してから本番ワークフローを動かすことが推奨されます。

2. ポリシーにはサイズ上限があります。管理ポリシーは 1 つあたり最大 6,144 文字です。上限に達した場合は、ポリシーを複数に分割するか、ロールを分けて権限を分散させて対応します。

詳しくは、公式ドキュメントの「IAM と AWS STS クォータ」をご覧ください。

IAM ユーザーは長期的な認証情報を持つため、漏えい時のリスクが相対的に高くなります。そこで AWS は、組織の規模を問わず、人によるサインインには IAM Identity Center を使うことを推奨しています。Identity Center を使うと、社内の既存 IdP (Microsoft Entra ID、Okta、Active Directory など) と一度連携するだけで、従業員は使い慣れた認証情報で複数の AWS アカウントやアプリケーションにシングルサインオンできます。各アカウントへのアクセスは「許可セット (Permission Set)」で定義し、その実体はアカウント側に作られる IAM ロール (＝一時的な認証情報)として動作します。これにより、長期的な認証情報を持つ IAM ユーザーを各アカウントに作らずに済みます。

では IAM ユーザーは不要かというと、そうではありません。IAM Identity Center や OIDC / SAML フェデレーションに対応していない外部ツール、長期的な認証情報を前提とする一部のオンプレミス連携など、限定的な用途では今も有効です。重要なのは使い分けで、人のアクセスには Identity Center、アプリケーションなどのプログラム (ワークロード) のアクセスには IAM ロール (一時的な認証情報)を使う、というのが現在の基本方針です。

詳しくは、公式ドキュメントの「IAM Identity Center とは何ですか?」をご覧ください。

IAM 本体 (ユーザー・ロール・ポリシー・グループ・MFA など)は追加料金なしで使えます。従量課金が発生するのは、IAM Access Analyzer の一部機能だけです。

無料で使えるもの

• IAM 本体: ユーザー・ロール・ポリシー・グループ・MFA
  
• Access Analyzer の外部アクセス分析 : パブリック / クロスアカウント共有の検出
• Access Analyzer のポリシー検証・生成 : 100 を超えるチェックと、CloudTrail からのポリシー自動生成

料金は変更される場合があります。詳しくは、「AWS IAM Access Analyzer の料金」でご確認ください。
 

IAM についてさらに学ぶための公式リソースです。QR コードから各リソースにアクセスできます。

各リソースの使い分け：

• 公式ドキュメント : IAM の全機能・API・設定値の正確な確認
• ベストプラクティス : 最小権限・一時的な認証情報・MFA などの設計指針
• AWS Black Belt : 体系的な学習や機能の深掘り
• AWS ブログ : 新機能の GA 情報やセキュリティ強化の最新情報

なお、英語版の公式ドキュメントは日本語版より更新が早い場合があります。最新の仕様確認には英語版も参照することをおすすめします。

⚠ 本記事は 2026 年 8 月時点の情報です。料金や仕様は変更される場合があるため、最新情報は公式ドキュメントをご確認ください。

米倉 裕基
アマゾン ウェブ サービス ジャパン合同会社
テクニカルライター・イラストレーター

日英テクニカルライター・イラストレーター・ドキュメントエンジニアとして、各種エンジニア向け技術文書の制作を行ってきました。趣味は娘に隠れてホラーゲームをプレイすることと、暗号通貨自動取引ボットの開発です。現在、AWS や機械学習、ブロックチェーン関連の資格取得に向け勉強中です。