IAM (概念)

IAM とは

IAM (Identity and Access Management) は、「誰が (認証)」「何に (リソース)」「何をできるか (認可)」を管理する仕組みの総称である。AWS IAM は AWS 固有の実装だが、IAM の概念はクラウド、OS、アプリケーション全般に適用される。

認証 vs 認可

認証 (Authentication) は「あなたは誰？」を確認する仕組みで、ログインや MFA が該当する。認可 (Authorization) は「何をしていい？」を制御する仕組みで、管理者は削除可能、一般ユーザーは閲覧のみといった権限管理が該当する。

認証の方式

認証の方式を以下に整理する。

方式	説明	用途
パスワード	知識ベース	Web ログイン
MFA	知識・所持・生体から 2 種類以上	パスワード漏洩後の防波堤
OIDC (OAuth 2.0 上の認証層)	ID トークン	SSO、ソーシャルログイン
API キー	静的トークン (自動失効しない)	サーバー間通信
IAM ロール	一時的な認証情報	AWS サービス間
mTLS	証明書ベース	マイクロサービス間

この表でまぎれやすいのが OAuth 2.0 と OIDC の関係である。RFC 6749 が定める OAuth 2.0 は、第三者のアプリに限定的なアクセス権を渡すための認可の枠組みで、「誰がログインしたか」を伝える仕組みは含まない。その上に利用者の同一性を確認する層を載せたのが OIDC で、ソーシャルログインが成り立っているのは OIDC が発行する ID トークンによる。アクセストークンが取れたことを本人確認できたと読み替える実装は、認可の結果を認証の代わりに使っている状態で、別の用途に発行されたトークンを持ち込まれたときに区別できない。

認可のモデル

認可のモデルを以下にまとめる。

モデル	説明	例
RBAC (Role-Based)	ロールに権限を割り当て	管理者、編集者、閲覧者
ABAC (Attribute-Based)	属性に基づく動的な権限	部署=営業 AND 地域=東京
PBAC (Policy-Based)	ポリシーで権限を定義	AWS IAM ポリシー

最小権限の原則

最小権限の原則を図で示す。

❌ 全権限を付与
{ "Effect": "Allow", "Action": "*", "Resource": "*" }

✅ 必要最小限の権限
{ "Effect": "Allow", "Action": "dynamodb:GetItem", "Resource": "arn:aws:dynamodb:...:table/users" }

最小権限は机の上で書き切れるものではない。動かしながら足りない権限を足していく進め方だと、切り分けが面倒な段階で付けた * がそのまま残る。実務では逆向きに、実際に呼ばれた操作の記録を集めてからその範囲へ絞り込む。絞ったあとも、権限の広い開発環境で通ったものが本番で落ちる形になりやすいので、環境ごとに同じ粒度で当てておく。

Web アプリケーションでの IAM

Web アプリケーションでの IAM を図で示す。

ユーザー → Cognito (認証) → API Gateway → Lambda
              ↓ JWT トークン
           API Gateway が JWT を検証 (署名・有効期限)
              ↓ 有効なトークン
           Lambda が実行

この流れで抜けやすいのは、JWT の署名と有効期限を確かめる工程が「トークンが本物か」の確認までで終わる点である。このユーザーがこのリソースに触っていいかは別の判定で、スコープやロールのクレームを見るだけでも足りない。対象データの所有者がトークンの主体と一致するかは、データを知っているアプリ側しか判定できない。

ゼロトラストとの関係

従来: ネットワーク境界で信頼 (VPN 内は安全) ゼロトラスト: 全リクエストを検証 (ネットワーク位置に関係なく認証・認可)

違いは検査の回数ではなく、信頼の根拠をどこに置くかである。境界防御は「内側にいる」ことを根拠にするため、一歩入られた後の横移動を止める手立てがない。ゼロトラストは根拠を身元と端末の状態へ移し、リクエストごとに評価する。誤解されやすいのは、ネットワーク制御をやめる話ではないことで、境界は境界として残したまま信頼の根拠を差し替えるのが実際の移行になる。

現場での応用を知るには関連書籍も役立つ。