IAMとは
この記事は約 2 分で読めます
IAM (Identity and Access Management) とは、「誰が」「何に」「どのような操作を」できるかを一元的に管理する仕組みです。認証 (本人確認) と認可 (権限付与) を統合的に制御し、組織のリソースへの適切なアクセスを保証します。クラウド環境の普及により、IAM は単なるユーザー管理ツールから、ゼロトラストアーキテクチャの中核を担うセキュリティ基盤へと進化しました。IAM の設定ミスはデータ漏洩やシステム侵害の最大の原因の一つであり、セキュリティチェックリストの最優先項目に位置づけられます。
認証と認可の違い
IAM を理解する上で最も重要な概念が、認証 (Authentication) と認可 (Authorization) の区別です。この 2 つは密接に関連しますが、まったく異なるプロセスです。
- 「あなたは誰か?」を確認
- パスワード、生体認証、MFA
- ログイン時に実行
- ID トークンを発行
- 「何をしてよいか?」を判定
- ロール、ポリシー、スコープ
- リソースアクセス時に実行
- アクセストークンを検証
よくある誤解として、「ログインできた = すべての操作が許可されている」と考えるケースがあります。認証は入口の門番、認可は各部屋の鍵と考えるとわかりやすいでしょう。OAuth は認可の、SSO は認証の代表的なプロトコルです。
アクセス制御モデルの比較
IAM における認可の実装方式には複数のモデルがあり、組織の規模や要件に応じて選択します。アクセス制御の設計は、セキュリティと運用効率のバランスが問われる領域です。
| モデル | 判定基準 | 適用例 | 課題 |
|---|---|---|---|
| RBAC | ロール (役割) | 管理者、編集者、閲覧者 | ロール爆発 (組み合わせ増大) |
| ABAC | 属性 (部署、時間帯、IP) | AWS IAM ポリシーの Condition | ポリシーの複雑化 |
| PBAC | ポリシー (ルールエンジン) | OPA (Open Policy Agent) | 導入・運用コストが高い |
実務では RBAC を基盤としつつ、細かい制御が必要な箇所に ABAC を組み合わせるハイブリッドアプローチが主流です。AWS IAM はまさにこのハイブリッドモデルを採用しており、ロールベースの基本構造に Condition 要素で属性ベースの条件を追加できます。
最小権限の原則
最小権限の原則は IAM 設計の根幹をなす考え方です。ユーザーやサービスには、業務遂行に必要最小限の権限だけを付与し、不要な権限は一切与えません。しかし、実務では「とりあえず広い権限を付与して動くようにする」という誘惑に負けがちです。企業のパスワードポリシーと同様に、IAM ポリシーも定期的な棚卸しと不要権限の削除が不可欠です。
IAM 設定ミスによるインシデント
IAM の設定ミスは、クラウド環境におけるセキュリティインシデントの主要な原因の一つです。S3 バケットのパブリックアクセス許可、過剰な IAM ロール権限、アクセスキーのハードコードなど、設定ミスのパターンは多岐にわたります。2019 年の Capital One 事件では、WAF の設定ミスと過剰な IAM ロール権限の組み合わせにより、1 億人以上の個人情報が流出しました。
こうしたインシデントを防ぐには、AWS IAM Access Analyzer や Microsoft Entra Privileged Identity Management (旧 Azure AD Privileged Identity Management) といった IAM ポリシーの自動監査ツールの導入と、インフラのコード化 (IaC) による設定のバージョン管理が有効です。ゼロトラストセキュリティの実装においても、IAM は最初に整備すべき基盤です。
この記事は役に立ちましたか？