IAM入門。登場人物を整理してIAMユーザー作成までやってみた

#AWS #GAWS

こんにちは～　浮田です。

■ TL;DR

IAM は AWS の「誰が（認証）・何をできるか（認可）」を管理する無料のサービス
登場人物は 4 人だけ。ユーザー＝人、グループ＝箱、ロール＝借り物の腕章、ポリシー＝ルールブック
ただし 2026 年現在、人間のログインには IAM ユーザーより IAM Identity Center が公式推奨。それでも IAM ユーザーが要る場面はある
作成手順は 6 ステップ。初期パスワード画面とシークレットアクセスキーは閉じたら二度と見られないのが最初の罠
結論：IAM は「最小権限」と「長期認証情報を持たない」の 2 原則さえ押さえれば怖くない

■ 目次

はじめに
そもそも IAM って？（認証と認可）
登場人物は 4 人だけ — ユーザー・グループ・ロール・ポリシー
ポリシー JSON の読み方（3 行で読める）
ここだけは守りたいベストプラクティス
ところで、今どき IAM ユーザーって作っていいの？
やってみた: IAM ユーザー作成の 6 ステップ
初心者がハマりがちなポイント
まとめ

■ はじめに

AWS を触りはじめて最初にぶつかる壁、それが IAM だと思っています。

ユーザー、グループ、ロール、ポリシーなど似たような言葉が 4 つも出てきて、正直なところ私も最初は「とりあえず権限つけとけば動くでしょ」くらいの感覚で乗り切っていました。

でも、なんとなくで権限を渡していると、あとで必ず「これ誰がなんで持ってるの？」を調べる時間が発生します（しました）。

結論を先に言うと、登場人物は 4 人だけで、それぞれの役割さえ掴めばポリシーの JSON も実質 3 行で読めるようになります。後半では実際に IAM ユーザーを作る手順まで通します。

■ そもそも IAM って？（認証と認可）

IAM（Identity and Access Management）は、ひとことで言うと AWS の入館証システムです。

無料で、すべての AWS アカウントに最初から入っています。

やっていることは 2 つだけです。

認証（Authentication）: 「あなたは本当に浮田さんですね？」の本人確認。パスワードや MFA がここ
認可（Authorization）: 「浮田さんはサーバールームには入れません」のできること制限。ポリシーがここ

会社の入館証でたとえると分かりやすいです。

ゲートでカードをかざして本人確認されるのが認証、そのカードでどの部屋のドアが開くかが認可。

「入館できること」と「金庫室に入れること」は別の話。これが IAM の全てです。

＜補足：英語だとどちらも Auth で始まるので混同しやすいですが、AuthN（認証）/ AuthZ（認可）と略し分ける習慣があります。＞

■ 登場人物は 4 人だけ

IAM の用語が覚えにくいのは、役割ではなく名前で覚えようとするからだと思っています。

まず対応表を置きます。

登場人物	たとえ	役割	認証情報
IAMユーザー	社員本人	個人・アプリの ID	持つ（パスワード / アクセスキー）
IAMグループ	部署	ユーザーをまとめる箱	持たない
IAMロール	借り物の腕章	一時的な権限の貸し出し	持たない（一時認証情報）
IAMポリシー	ルールブック	許可 / 拒否の定義（JSON）	—

● IAMユーザー＝社員本人

コンソールにログインする個人や、プログラムからアクセスするアプリケーションに割り当てる ID です。パスワード（コンソール用）とアクセスキー（CLI / SDK 用）という長期の認証情報を持てるのが特徴で、あとで書きますが、実はこの「長期」というところが現在の AWS 的には悩ましいポイントになっています。

● IAMグループ＝部署

ユーザーをまとめる箱です。グループにポリシーをアタッチすると、所属メンバー全員に権限が適用されます。「Developers 部署に入った人は自動的に開発用の部屋に入れる」感覚ですね。人が増えるたびに個別に権限を配るのは辞令を一人ずつ手書きするようなものなので、権限は原則グループに付けるのがラクです。

● IAMロール＝借り物の腕章

ロールは「一時的に借りる権限の腕章」です。EC2 や Lambda がこの腕章を借りて仕事をし、終わったら（正確には有効期限が切れたら）自動的に返します。

何がすごいかというと、ロールはパスワードもアクセスキーも持ちません。腕章を借りている間だけ有効な一時認証情報が発行されるだけ。

つまり「サーバーにアクセスキーをベタ書きして、それが漏れて大惨事」というお約束の事故が、構造的に起きようがないんです。

● IAMポリシー＝ルールブック

「何を許可 / 拒否するか」を JSON で書いた文書です。ユーザー・グループ・ロールにアタッチして初めて効きます。AWS があらかじめ用意している AWS 管理ポリシー（AmazonS3ReadOnlyAccess など）と、自分で書くカスタマー管理ポリシーの 2 種類があります。最初は管理ポリシーで十分です。

■ ポリシー JSON の読み方（実質 3 行）

JSON と聞くと身構えますが、読むのは実質 3 行です。S3 の読み取りだけを許可するポリシーを貼ります。

{

"Version": "2012-10-17",

"Statement": [

{

"Effect": "Allow",

"Action": ["s3:GetObject", "s3:ListBucket"],

"Resource": "*"

}

]

}

▲ 読むのは Effect / Action / Resource の 3 つだけ。Version の日付は固定のおまじないです（自分で今日の日付に変えないでください。私は最初変更してました）

行	意味	この例では
Effect	許可か拒否か	Allow（許可）
Action	何を	S3 のオブジェクト取得と一覧
Resource	どれに対して	*（すべてのバケット）

ここで最初の勘違いポイントを 1 つ。

この JSON のどこにも「誰が」は書いてありません。

「誰が」はポリシーの中身ではなく、どこにアタッチしたかで決まります。

同じルールブックでも、渡す相手によって効く相手が変わる、というだけの話です。

■ ここだけは守りたいベストプラクティス

細かい推奨事項は山ほどありますが、最初に守るのは 4 つで十分だと思っています。

ルートユーザーは日常利用しない — アカウント作成時のメールアドレスでログインするアレです。全権限を持つマスターキーなので、MFA を設定したら金庫にしまう感覚で。請求設定など、ルートでしかできない作業のときだけ取り出します
最小権限の原則 — 最初から AdministratorAccess を配らない。必要になったら足す。「面倒だから全部許可」は未来の自分への借金です
MFA を全員に — パスワード認証だけのコンソールユーザーは、家の鍵を 1 個しか付けていないのと同じです
アクセスキーより一時認証情報（ロール）を優先 — 腕章方式で済むところにマスターキーを増やさない

3 と 4 は要するに同じことを言っています。

「長期の認証情報を、なるべくこの世に存在させない」

AWS の推奨は全部この一本の軸で読めると思ってます。

■ ところで、今どき IAM ユーザーって作っていいの？

ここからが手順……の前に、但し書きを 1 つ。

2026 年現在、AWS は人間のコンソールアクセスには IAM ユーザーではなく IAM Identity Center（旧 AWS SSO）を推奨しています。

IAM ユーザー作成画面にもその旨の案内が出ます。

「これから IAM ユーザーの作り方を解説する記事」としてはやや気まずい事実ですが、隠しても仕方ないので先に整理しておきます。

ケース	IAM ユーザー
社員が日常的にコンソールへログイン	❌ Identity Center 推奨
Identity Center が使えない環境・組織	✅
サードパーティツール連携（長期キーが必須のもの）	✅（ただし定期ローテーション）
個人の検証・学習用アカウント	✅ 現実的な選択

なぜ推奨が変わったのか。ちょっと考えてみます。

IAM ユーザーの本質は「長期の認証情報を持てる ID」で、それはつまり漏えいリスクの塊を常設するということだからです。

Identity Center なら人間のログインも一時認証情報ベースになる。

さっきの「長期の認証情報をこの世に存在させない」そのままですね。

とはいえ、個人の学習用途やツール連携では IAM ユーザーが現実解であることも多いです。

「使ってはいけない」ではなく「使いどころを選ぶ」が正しい理解だと思います。

■ やってみた: IAM ユーザー作成

ここからは手を動かします。マネジメントコンソールでの手順です。

● ① IAM コンソールを開く

1 IAM コンソールを開

コンソール上部の検索で「IAM」を検索 → 左メニュー「ユーザー」→「ユーザーの作成」をクリック。

2 ユーザー名とアクセス種別を決める

● ② ユーザー名とアクセス種別を決める

ユーザー名を入力します。

コンソールにログインさせたい場合は「AWS マネジメントコンソールへのユーザーアクセスを提供する」にチェックを入れ、「IAM ユーザーを作成します」を選択。

ここで例の「Identity Center を推奨します」の案内が出ますが、今回は学習用途なので IAM ユーザーで進めます。

パスワードは自動生成か手動設定を選び、「次回サインイン時に新しいパスワードの作成を要求する」は他人用に作るならチェック推奨です。

2 ユーザー名とアクセス種別を決める

● ③ 許可を設定する

方式は 3 つから選べます。

ユーザーをグループに追加（推奨）
許可のコピー（既存ユーザーから複製）
ポリシーを直接アタッチ

推奨はグループ経由です。

理由は単純で、直接アタッチを重ねると「この人なんでこの権限持ってるんだっけ？」の棚卸しが地獄になるからです。

今回はコミュニティのGAWSに参加するひと向けに作成するので、すでに作成されてるユーザーグループを選択します。

方式は 3 つから選べます。

● ④ 確認して作成

内容を確認して「ユーザーの作成」。

完了画面にコンソールのサインイン URL・ユーザー名・初期パスワードが表示されます。
人のユーザーを作成したときはこれらを安全な方法で共有してください。

注意：この画面を閉じると、パスワードは二度と表示できません。 csvファイルをダウンロードしておくと安心です。

完了画面にコンソールのサインイン URL・ユーザー名・初期パスワードが表示されます。

csvファイルをダウンロードせずに画面を閉じようとすると警告してくれます。
パスワードは二度と表示できません！ご注意ください。

csvファイルをダウンロードせずに画面を閉じようとすると警告してくれます。

● ⑤ MFA を設定する

同じ「セキュリティ認証情報」タブから MFA デバイスを割り当てます。

認証アプリ、パスキー、ハードウェアトークンから選べます。

コンソールログインするユーザーなら必須と思ってください。

同じ「セキュリティ認証情報」タブから MFA デバイスを割り当てます。

デバイス名を入力し、認証方法を選択します。今回は認証アプリで認証する方法を選択します。

デバイス名を入力し、認証方法を選択します。

QRコードを表示をクリックした後に、アプリを開き、QRコードを読み込みます。
MFAコードを２つ入力します。
（Authenticatorでは30秒ごとに番号が変わります）

(Authenticatorでは30秒ごとに番号が変わります)

■ 初心者がハマりがちなポイント

症状	原因	対処
完了画面を閉じてパスワードが分からない	初期パスワードは再表示不可	ユーザー詳細 → セキュリティ認証情報 →「コンソールアクセスを管理」からパスワードをリセット（再発行）できます。
ログインできたのに「アクセスが拒否されました」だらけ	ポリシー未アタッチ or グループ入れ忘れ	ユーザー詳細の「許可」タブで、グループ経由の許可も含めて何が付いているか確認。
アクセスキーを Git に push しかけた	~/.aws/credentials ではなくコードにベタ書きした	そもそもコードに書かない。git-secrets などの検知ツールを入れておくと、うっかりを機械が止めてくれます。漏らした場合は即座にキーを無効化