IAM (Identity and Access Management) とは - 認証・認可の設計原則と実装を解説

IAM とは

IAM (Identity and Access Management) とは、「誰が」「何に」「どのような操作を」できるかを管理する仕組みの総称です。認証 (Authentication: 本人確認) と認可 (Authorization: 権限付与) の 2 つの機能を中核とし、組織のリソースへのアクセスを制御します。

クラウド環境では IAM の重要性が特に高まります。オンプレミスではネットワーク境界が防御線として機能しましたが、クラウドではインターネット経由でリソースにアクセスするため、IAM が事実上の最前線の防御になります。AWS IAM、Azure AD (Entra ID)、Google Cloud IAM など、主要クラウドプロバイダーはそれぞれ独自の IAM サービスを提供しています。

最小権限の原則と実装パターン

IAM 設計の最も重要な原則が「最小権限の原則」(Principle of Least Privilege) です。ユーザーやサービスに対して、業務に必要な最小限の権限のみを付与します。

RBAC (Role-Based Access Control): 職務に応じたロールを定義し、ロール単位で権限を管理する。「開発者」「運用者」「監査者」などのロールに適切な権限セットを割り当てる
ABAC (Attribute-Based Access Control): ユーザーの属性 (部署、プロジェクト、環境タグ) に基づいて動的に権限を判定する。リソースが多い環境でロール爆発を防げる
一時的な権限昇格: 通常は読み取り権限のみを付与し、変更作業時にのみ書き込み権限を一時的に付与する。AWS の AssumeRole や Azure PIM (Privileged Identity Management) が該当する

ゼロトラストアーキテクチャでは、ネットワーク上の位置に関わらず、すべてのアクセスに対して IAM による認証・認可を要求します。SSO と組み合わせることで、ユーザー体験を損なわずにセキュリティを強化できます。

クラウド IAM の設計パターン

クラウド環境での IAM 設計には、以下のベストプラクティスがあります。

ルートアカウントの封印: クラウドのルートアカウント (最高権限) は MFA を設定した上で日常業務では使用しない。管理者であっても個別の IAM ユーザーまたはフェデレーション認証を使用する
サービス間認証にはロールを使用: アプリケーションやサービス間の認証には、アクセスキーではなく IAM ロール (AWS) やマネージド ID (Azure) を使用する。シークレット管理の負担を軽減し、認証情報の漏洩リスクを排除する
条件付きポリシー: IP アドレス制限、MFA 必須、時間帯制限などの条件をポリシーに組み込み、権限の行使条件を厳格化する
権限の定期棚卸し: 未使用の権限やユーザーを定期的に検出し、削除する。AWS IAM Access Analyzer や CloudTrail のログ分析で、実際に使用されている権限を可視化する

OAuth 2.0 や OIDC を活用した外部 IdP との連携も、エンタープライズ環境では標準的な構成です。

IAM の運用で陥りやすい落とし穴

IAM は設計時だけでなく、運用フェーズでの継続的な管理が不可欠です。

権限の肥大化: 「動かないから権限を追加する」を繰り返すと、いつの間にか過剰な権限が付与される。トラブルシューティング時に追加した権限は、解決後に必ず削除する
共有アカウント: 複数人で 1 つのアカウントを共有すると、操作の追跡が不可能になる。個人ごとに一意のアイデンティティを割り当てることが監査の前提条件
退職者アカウントの放置: 退職・異動した従業員のアカウントが残存すると、不正アクセスの経路になる。人事イベントと連動した自動無効化の仕組みを構築する
ポリシーの複雑化: 条件分岐が多すぎるポリシーは、意図しない許可や拒否を生む。ポリシーはシンプルに保ち、定期的にポリシーシミュレーターで検証する

クラウド共有責任モデルにおいて、IAM の設定は利用者側の責任です。クラウドプロバイダーは IAM の仕組みを提供しますが、適切な設定と運用は利用者が行う必要があります。

よくある誤解

管理者には全権限 (AdministratorAccess) を付与しておけば問題ない: 管理者であっても、日常業務に必要な権限のみを付与すべきです。全権限を持つアカウントが侵害されると、環境全体が危険にさらされます。通常は制限された権限で作業し、必要時のみ一時的に権限を昇格させる運用が推奨されます。
IAM ポリシーは一度設定すれば変更する必要がない: 組織の体制変更、新サービスの導入、セキュリティ要件の変化に応じて IAM ポリシーは継続的に見直す必要があります。未使用の権限は攻撃対象面を広げるため、定期的な棚卸しと不要権限の削除が不可欠です。

IAM (Identity and Access Management)