IAM - Gestión de identidades y accesos
Lectura de 2 min aprox.
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 億人以上の個人情報が流出しました。
こうしたインシデントを防ぐには、IAM ポリシーの自動監査ツール (AWS IAM Access Analyzer、Azure AD Privileged Identity Management など) の 導入と、インフラのコード化 (IaC) による設定のバージョン管理が有効です。ゼロトラストセキュリティの 実装においても、IAM は最初に整備すべき基盤です。IAM とクラウドセキュリティの実践書 (Amazon)で体系的に学ぶことを推奨します。
¿Te resultó útil este artículo?