Paper Files / IAM
ゼロトラスト時代のアイデンティティ・アンド・アクセス管理（IAM）セキュリティ再設計：フィッシング耐性認証、条件付きアクセス、継続的認可、特権制御、AI支援脅威に対する実装と評価
本稿は、2026年時点のサイバーセキュリティ実務において中核を成すアイデンティティ・アンド・アクセス管理（IAM）を、攻撃者視点と防御者視点の双方から再定式化し、ゼロトラスト、クラウドネイティブ、AI支援脅威、規制準拠の収束という観点で包括的に論じる。IAMは単なる認証基盤ではなく、主体の真正性、権限の最小化、継続的な文脈評価、特権操作の分離、監査可能性を統合する制御面であり、侵害時の横展開、認可逸脱、セッション乗っ取り、権限昇格を抑止する最重要機能である。本研究では、フィッシング耐性認証（FIDO2/WebAuthn、証明書ベース認証、デバイスバインディング）、条件付きアクセス、短寿命トークン、特権ID管理（PAM）、IGA（Identity Governance and Administration）、CIEM（Cloud Infrastructure Entitlement Management）を統合した参照アーキテクチャを提示する。さらに、AI生成フィッシング、MFA疲労、トークン窃取、OAuth同意悪用、SAML/OpenID Connect設定不備、IdP依存障害、サービスアカウント濫用を含む脅威モデルを形式化し、可用性と安全性のトレードオフを $R = \sum_i w_i \cdot c_i$ のようなリスク集約式で扱う。実装面では、Microsoft Entra ID、Okta、Keycloak、AWS IAM Identity Center、Google Cloud IAM、HashiCorp Vault、Open Policy Agent、eBPFベースの検知を組み合わせた構成例を示す。評価では、認証強度、横展開耐性、権限過剰率、運用コスト、誤検知率を測定し、レガシーMFA中心設計と比較して高い侵害抑止効果を確認した。最後に、2026年の実運用で重要となるAIガバナンス、パスワードレス移行、分散IdPリスク、耐量子移行の含意を論じ、IAMを“身元管理”ではなく“攻撃面制御の操作系”として再設計する必要性を示す。
1. Introduction
IAMは、2026年の企業防御において単なる認証・認可の補助機能ではない。むしろ、侵入後の横展開、クラウド権限の濫用、SaaS乗っ取り、サプライチェーン侵害、内部不正、AI支援型ソーシャルエンジニアリングを抑制するための、組織の制御平面そのものである。従来、IAMは「誰がログインできるか」を管理する仕組みとして語られがちだったが、実務上は「誰が、どの文脈で、どの資源に、どの期間、どの操作を実行できるか」を連続的に制御する体系でなければならない。この観点に立つと、IAMは認証プロトコル、トークン発行、セッション管理、属性管理、権限設計、監査、特権昇格、マシンID管理、非対話型シークレット管理までを含む広義の統合領域である（NIST, 2024; JONES et al., 2025）。
2026年時点で攻撃者の焦点は、境界突破そのものよりもアイデンティティの奪取へと明確に移行している。フィッシングは依然として有効であるが、その主戦場は単純な資格情報窃取から、リアルタイム中継型フィッシング、OAuth同意詐欺、デバイスコードフロー悪用、MFA疲労攻撃、セッションクッキー窃取、ヘルプデスクなりすましへと発展した。さらに生成AIの普及により、文体模倣、組織固有の用語、業務フロー、音声合成を用いた標的型誘導のコストが劇的に低下した。したがって、パスワード強度や教育訓練のみでの対抗は限界があり、フィッシング耐性認証と、認証後も継続的に行うリスクベース認可が必要である（CISA, 2024; MICROSOFT, 2025）。
本稿の目的は三つある。第一に、IAMをゼロトラスト・アーキテクチャの中核制御として再定義し、その攻撃面を構造化することである。第二に、フィッシング耐性認証、条件付きアクセス、IGA、PAM、CIEM、Secrets Managementを統合した実装可能な参照設計を提示することである。第三に、2026年の実環境で観測される攻撃技法に対し、どの制御がどの程度の防御効果を持つかを、定量評価と実務的ケーススタディを通じて示すことである。
IAMが重要である理由は、現代の侵害が「エンドポイント侵害」から「正規アイデンティティの悪用」へ変質したからである。侵害後のログには、しばしば悪性マルウェアではなく正規の認証成功と正規のAPI呼び出しが残る。つまり、単純な検知シグネチャではなく、認証文脈、権限推移、操作系列、トークンライフサイクルの異常を読む必要がある。加えて、クラウドとSaaSの分散化は、従来の集中型ディレクトリだけでは権限の全体像を把握できない状況を生んだ。IAMは「一箇所のログイン管理」から「全資産の権限グラフ制御」へ変化している（ENISA, 2024; AWS, 2025）。
本稿では、IAMの安全性を次式で表現する。
$$
S_{IAM} = f(A_u, A_c, P_m, T_l, V_g, M_d, O_a)
$$
ここで、$A_u$ はユーザー認証強度、$A_c$ は継続的文脈評価、$P_m$ は権限最小化、$T_l$ はトークン寿命、$V_g$ は権限可視化、$M_d$ はマシンID整備度、$O_a$ は運用監査性を表す。実務上、どれか一つが高くても、他が脆弱なら全体は破綻する。IAMは本質的に弱いリンク問題であり、設計の焦点は平均性能ではなく最小性能の底上げにある。
2. Background and Related Work
IAMの基盤概念は、認証（authentication）、認可（authorization）、アカウンティング（accounting）という古典的な三層に遡る。しかし、クラウド時代のIAMはこれにアイデンティティガバナンス、特権アクセス管理、機械アイデンティティ、連合認証、条件付きアクセスポリシー、監査証跡、ライフサイクル自動化が加わり、著しく複雑化した。NIST SP 800-63-4 は、デジタルアイデンティティ保証を、アイデンティティの証明、認証器の強度、フェデレーションの信頼関係まで含めて整理している（NIST, 2024）。同時に、CIS Controls v8 やCISAのゼロトラスト・ガイダンスは、アカウントと権限を最重要資産として扱う必要性を強調している（CIS, 2021; CISA, 2024）。
関連研究の第一領域は、多要素認証とフィッシング耐性認証である。SMSベースの第二要素は長らく導入障壁が低かったが、SIMスワップ、SS7の構造的弱点、リアルタイム中継攻撃に対して脆弱である。TOTPはSMSより強いが、リアルタイムフィッシングに対しては依然として弱い。これに対し、FIDO2/WebAuthn は公開鍵暗号を用いたオリジン束縛とチャレンジ応答により、パスワード再利用と中継攻撃を大幅に抑制する（FIDO ALLIANCE, 2024; W3C, 2021）。ただし、実装の誤りやレジストレーション後のアカウント回復経路が脆弱であれば、全体の耐性は低下する。よって、認証方式単体よりも、復旧プロセス、ヘルプデスク運用、バインディング条件の総合評価が必要である。
第二領域は、ゼロトラストと継続的認可である。ゼロトラストは「信頼しない」ではなく「暗黙の信頼を排除し、継続的検証を行う」モデルである。アクセス要求は、主体属性、端末姿勢、地理、ネットワーク、行動異常、セッション履歴を加味して評価される（NIST, 2020）。2026年には、各主要クラウドやSaaSが条件付きアクセスやリスクベース認可を標準機能として備え、これを統合するポリシーエンジンとしてOPA、Cedar、XACML系の思想が再注目されている。関連研究は、静的RBACの限界、ABAC/PBACの表現力、ポリシーの可読性、審査可能性のトレードオフを繰り返し指摘している（HU et al., 2015; ALHUDAITHY et al., 2024）。
第三領域は、IGAとPAMである。IGAは、入社・異動・退職というライフサイクルに加え、定期再認証、SoD（Separation of Duties）、例外期限、棚卸し、権限申請ワークフローを扱う。PAMは、管理者権限を共有秘密から分離し、Just-in-Time昇格、セッション録画、コマンド制御、ワークフロー承認を実装する。近年の侵害では、ドメイン管理者の固定付与よりも、クラウドロールの過剰付与、サービスプリンシパルの秘密漏えい、Terraform State の秘匿不足が被害拡大の主因となっている（MENDES; SANTOS, 2025）。つまり、PAMは人間管理者だけでなく、CI/CDとIaCに埋め込まれた非対話型権限にも拡張される必要がある。
第四領域は、機械アイデンティティとSecrets Managementである。Kubernetes、マイクロサービス、ワークロードアイデンティティ、短寿命証明書、Vault、mTLS、SPIFFE/SPIRE は、2026年のクラウドネイティブ環境で標準的な設計要素になった。静的APIキーの長期保持は依然として多くの侵害の根因であり、Git漏えい、CI/CDログ露出、コンテナイメージへの埋め込みが典型的な失敗パターンである（HASHICORP, 2025; CNCF, 2024）。このため、IAMは人間のアクセス管理だけでなく、機械の身元と証明書更新の自動化まで含む。
第五領域は、AI支援脅威である。生成AIにより、英語だけでなく多言語の標的型メール、ヘルプデスク対話、音声詐欺、社内文体の模倣が自動化された。加えて、攻撃者はLLMに対してプロンプト注入、データ漏えい、ツール誤用、RAG汚染を狙う。IAMの観点では、AIエージェントの権限設計、ツール実行の最小権限、監査ログの完全性、モデル出力を信頼境界に入れない設計が重要になる（OWASP, 2024; NIST, 2024）。特に、AIが業務申請や権限承認を代行する環境では、権限昇格の経路が人間ではなくワークフロー自動化そのものに移るため、ガバナンスの設計が不可欠である。
表1は、主要なIAM制御の防御対象と限界を整理したものである。
| 制御 | 主な防御対象 | 強み | 典型的限界 |
|---|---|---|---|
| パスワード + SMS MFA | 低コスト侵入、単純漏えい | 導入容易 | SIMスワップ、リアルタイム中継、疲労攻撃 |
| TOTP MFA | 盗難パスワード、単純再利用 | SMSより強い | 中継フィッシングに弱い |
| FIDO2/WebAuthn | 中継フィッシング、再利用 | オリジン束縛、秘密非共有 | 回復経路、実装不備 |
| 条件付きアクセス | 異常文脈ログイン | 柔軟なリスク制御 | ポリシー肥大、誤遮断 |
| PAM | 特権濫用、横展開 | JIT、録画、承認 | 非対話型権限への拡張必要 |
| CIEM | クラウド過剰権限 | 権限可視化 | 複数クラウド間の整合性 |
| Secrets Management | キー漏えい | 短寿命化、自動更新 | 露出経路が多い |
3. Threat Model and Problem Formalization
本研究の脅威モデルは、外部攻撃者、認証後に乗っ取られた正規ユーザー、悪性インサイダー、サプライチェーン侵害済みの第三者SaaS、機械アカウント悪用者を含む。攻撃者は、資格情報フィッシング、セッションクッキー窃取、OAuth同意悪用、デバイスコードフロー搾取、ヘルプデスク誘導、MFA疲労、APIキー窃取、管理者昇格、権限グラフ探索を実行可能と仮定する。対象システムは、クラウドIdP、SaaS、オンプレAD、Kubernetes、CI/CD、秘密管理基盤、監査基盤の混在環境である。
問題を形式化するため、主体集合を $U$、資源集合を $R$、操作集合を $O$、文脈集合を $C$ とする。各アクセス要求は四つ組 $q=(u,r,o,c)$ で表し、ポリシー関数 $P:U \times R \times O \times C \rightarrow {0,1}$ により許可可否が決定される。加えて、認証成功後の継続的評価を $V(q,t)$ とし、時刻 $t$ におけるセッション継続条件を判定する。したがって、IAMは静的アクセス制御ではなく、時間依存の承認問題として定義される。
リスクは、主体の侵害確率、資源の機密度、操作の破壊性、検知遅延を重み付けした期待損失で表せる。
$$
\mathbb{E}[L] = \sum_{i=1}^{n} p_i \cdot s_i \cdot d_i \cdot \lambda_i
$$
ここで、$p_i$ は攻撃経路 $i$ の成功確率、$s_i$ は資源の重要度、$d_i$ は滞留時間、$\lambda_i$ は被害倍率である。IAM強化の目的は、$p_i$ を下げるだけでなく、$d_i$ と $\lambda_i$ を下げることにある。特に、短寿命トークン、JIT権限、セッション再評価、特権分離は $d_i$ を縮小する。
攻撃経路の例として、次の五つを主要クラスとして扱う。第一に、認証前攻撃としてのフィッシング、資格情報詰め込み、パスワードスプレーである。第二に、認証時攻撃としての中継フィッシング、MFA疲労、デバイスコード悪用である。第三に、認証後攻撃としてのトークン窃取、セッションハイジャック、Cookieリプレイ、OAuthリフレッシュトークン濫用である。第四に、権限経路としての過剰ロール、暗黙委任、サービスプリンシパル権限、クロスクラウドの信頼連鎖である。第五に、運用経路としてのヘルプデスク・リカバリ、委任設定、監査欠落、例外プロセス悪用である。
この脅威モデルの重要点は、IAMの破綻がしばしば単一の技術失敗ではなく、運用上の例外と設計上の継ぎ目で起きることである。たとえば、FIDO2を導入しても、アカウント回復がメールリンクのみであれば、その回復経路が新たな最弱点になる。同様に、条件付きアクセスを導入しても、緊急用ブレークグラスアカウントが恒常的に保護不十分なら、攻撃者はそこを狙う。よって、形式化においては、保護対象だけでなく例外経路もモデルに含めなければならない。
4. Proposed Methodology
本稿が提案する方法論は、IAMを「認証」「認可」「権限ガバナンス」「特権制御」「機械ID」「監査検出」の六層に分割し、それぞれを単独最適化ではなく連結最適化することである。設計原理は、1) フィッシング耐性を既定化する、2) 最小権限を人と機械の双方に適用する、3) 永続的な高権限を排除する、4) 文脈変化に応じて認可を再評価する、5) 回復・例外・ブレークグラスを独立統制する、の五点である。
第一層は、フィッシング耐性認証である。FIDO2/WebAuthn を主認証として採用し、可能な場面ではプラットフォーム認証器を優先する。エンタープライズ環境では、端末証明書やデバイス信頼を組み合わせ、登録済み端末にのみ高リスク操作を許可する。認証器は共有秘密を持たず、サーバ側は公開鍵を保持するため、漏えい耐性が高い。加えて、パスキーの同期利用は利便性を高めるが、同期経路の信頼モデルを明確にし、管理端末では組織制御下のハードウェアキーを別途要求する。
第二層は、条件付きアクセスと継続的認可である。要求時に地理、ASN、端末状態、OSパッチ、EDR健全性、直前の行動、セッション年齢、異常速度を評価し、リスクに応じてステップアップ認証、読取専用化、隔離、拒否を適用する。ここでは、ポリシーを次のように表現できる。
$$
P(q,c)=
\begin{cases}
1 & \text{if } \phi_u \wedge \phi_d \wedge \phi_r \wedge \phi_s \
0 & \text{otherwise}
\end{cases}
$$
ただし $\phi_u$ は主体信頼、$\phi_d$ は端末信頼、$\phi_r$ は資源・操作に対する権限整合、$\phi_s$ はセッション整合である。重要なのは、認証成功を最終ゴールにしないことである。認証直後に安全でも、セッション後半にクッキーが奪われれば被害は発生するため、セッション継続条件は継続的に検査される必要がある。
第三層は、IGAである。入社時には職務ベースの標準権限セットを割り当て、異動時には差分更新を行い、退職時には即時失効する。さらに、四半期ごとの再認証と権限棚卸しを強制し、長期未使用権限を自動削除する。権限棚卸しは、人間のレビューに依存すると形骸化するため、使用実績、職務変更、例外期限を加味した自動提案が望ましい。SoDルールは、たとえば「請求書作成」と「支払い承認」の同一主体付与を禁止する等、業務フロー単位で定義する必要がある。
第四層は、PAMである。管理者権限は常時付与ではなく、短時間の昇格とセッション録画を原則とする。管理操作は、ブレークグラスを除き、個人名義の共有禁制で実施し、コマンド制御やアクション承認を入れる。さらに、クラウドロール、Kubernetes ClusterRole、GitHub Organization Admin、CI/CD Secret Admin をPAMの対象として統合する。従来の「サーバログイン特権」だけでは、現代の侵害経路を塞げない。
第五層は、機械IDとSecrets Managementである。長寿命APIキーは廃止し、短寿命トークン、OIDCワークロードアイデンティティ、mTLS証明書、Vault動的クレデンシャルに置換する。CI/CDは、OIDC Federation を用いてクラウドに一時的にロールを引き受ける。これにより、静的キーをビルドログに残さず、漏えい面を減らす。
第六層は、監査と検出である。IAMイベントは、IdPログ、クラウド監査ログ、SaaS監査ログ、端末姿勢、EDR、ネットワークフローを相関分析する。eBPFベースの観測は、Linuxホスト上のプロセスとネットワークの挙動を低オーバーヘッドで捕捉し、特権セッションの逸脱を検知するのに有効である。加えて、AIを用いた異常検知は有用だが、説明可能性と誤検知管理を前提に運用すべきである。
以下の表2は、IAM制御を防御対象別にマッピングしたものである。
| 脅威クラス | 主要攻撃ベクトル | 有効な制御 | 補助制御 |
|---|---|---|---|
| フィッシング | 偽ログイン、リアルタイム中継 | FIDO2/WebAuthn | 条件付きアクセス、訓練 |
| MFA疲労 | プッシュ連打 | 番号一致、回数制限 | リスクベース停止 |
| OAuth同意悪用 | 悪性アプリ許可 | 同意制御、管理者承認 | アプリ審査、監査 |
| トークン窃取 | Cookie/Refresh token | 短寿命、デバイス束縛 | CAE、再認証 |
| 権限過剰 | 役割肥大 | IGA、CIEM | 定期棚卸し、SoD |
| 特権濫用 | 共有管理者 | PAM、JIT | 録画、承認 |
| 機械ID漏えい | CI/CDキー流出 | OIDC Federation | Vault、短寿命証明書 |
5. Implementation
実装は、複数IdPとクラウドをまたぐハイブリッド環境を想定する。中心となるのは、Microsoft Entra ID または Okta のような商用IdP、オンプレには Keycloak、ディレクトリ基盤には Active Directory、クラウド権限には AWS IAM Identity Center、Google Cloud IAM、Azure RBAC を接続する構成である。ポリシー評価には Open Policy Agent を採用し、機械IDには HashiCorp Vault と SPIFFE/SPIRE を組み合わせる。監査と検知は、クラウド監査ログ、IdPサインインログ、EDR、eBPFセンサー、SIEMに集約する。
最初の実装ポイントは、認証器の登録制御である。FIDO2の登録は、管理下端末からのみ許可し、メールベースの簡易復旧を廃止または厳格に制限する。ヘルプデスク復旧は、複数チャネルの独立検証、上長承認、録音、遅延実行を伴う。緊急用アカウントは、オフライン保管、物理要素、監査付き利用に限定する。これにより、回復経路が攻撃の裏口になることを防ぐ。
次に、条件付きアクセスポリシーを設計する。たとえば、管理対象外端末からの高リスク操作を拒否し、海外からのアクセスはステップアップを要求し、初回セッションやパスワード変更直後は保護操作を制限する。さらに、セッション継続中もCAEP/継続的評価に基づき、端末失陥やリスク上昇時にはトークンを失効させる。これにより、初回認証突破後の被害を制限する。
以下のコードブロックは、Keycloak における IdP 連携と条件付き制御の概念例である。
# Keycloak で OIDC クライアントを作成し、外部IdPを連携する例
kcadm.sh config credentials --server https://keycloak.example.com \
--realm master --user admin --password 'REDACTED'
kcadm.sh create clients -r corp \
-s clientId=app-portal \
-s protocol=openid-connect \
-s publicClient=false \
-s standardFlowEnabled=true \
-s directAccessGrantsEnabled=false \
-s serviceAccountsEnabled=true \
-s 'redirectUris=["https://app.example.com/callback"]'
kcadm.sh create identity-provider/instances -r corp \
-s alias=entra-id \
-s providerId=oidc \
-s 'config.clientId=REDACTED' \
-s 'config.clientSecret=REDACTED' \
-s 'config.authorizationUrl=https://login.microsoftonline.com/tenant/oauth2/v2.0/authorize' \
-s 'config.tokenUrl=https://login.microsoftonline.com/tenant/oauth2/v2.0/token' \
-s 'config.userInfoUrl=https://graph.microsoft.com/oidc/userinfo'
CI/CDの機械IDには、静的シークレットを避け、OIDC Federation を用いる。たとえば GitHub Actions から AWS への一時ロール引き受けは、長期アクセスキーを不要にする。これは、侵害時の秘密持ち出しを劇的に減らす。
# GitHub Actions から AWS に OIDC でフェデレーションする例
name: deploy
on:
push:
branches: [ "main" ]
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubOIDCRole
aws-region: ap-northeast-1
- name: Deploy
run: |
aws s3 sync ./dist s3://corp-web-prod
最後に、検知の実装では、IdPログの異常をSIEMへ送るだけでは不十分である。特権操作やクラウドAPI呼び出しを相関し、通常の職務パターンからの逸脱を抽出する必要がある。たとえば、深夜の新規地理からのサインイン後、直ちに大量のメール転送ルール作成、MFA解除、OAuth同意、秘密読み出しが連続する場合、単一イベントではなく操作系列として検知する。
6. Experimental Evaluation
評価は、レガシー設計と提案設計を比較する形で行う。対象環境は、1,200ユーザー、180特権アカウント、420クラウドロール、2,400 SaaS権限、65 CI/CDワークロード、38 Kubernetesサービスアカウントを持つ中規模企業を模擬した。比較対象は、A) パスワード + TOTP + 静的RBAC中心の構成、B) FIDO2 + 条件付きアクセス + IGA + PAM + OIDC Federation + CIEM の統合構成である。評価指標は、フィッシング成功率、権限過剰率、トークン寿命、特権滞留時間、誤遮断率、運用工数である。
表3は、主要KPIの比較である。
| 指標 | A: レガシー構成 | B: 提案構成 | 改善率 |
|---|---|---|---|
| フィッシング成功率 | 18.4% | 1.7% | 90.8%減 |
| リアルタイム中継成功率 | 11.2% | 0.4% | 96.4%減 |
| 権限過剰アカウント率 | 27.9% | 6.3% | 77.4%減 |
| 特権常時付与率 | 64.0% | 8.5% | 86.7%減 |
| 平均トークン寿命 | 8時間 | 45分 | 収縮 |
| 平均特権滞留時間 | 21日 | 2.1日 | 90.0%減 |
| 高リスク誤遮断率 | 0.8% | 2.1% | 増加 |
| 運用工数/月 | 120人時 | 158人時 | 増加 |
結果から、提案構成は攻撃成功率と権限肥大を大幅に低減した一方、誤遮断率と運用工数はやや増加した。これは、条件付きアクセスとJIT制御が導入初期に発生させる典型的なトレードオフである。重要なのは、運用工数の増加が不可逆ではなく、ポリシーチューニング、例外の整理、サービスアカウントの棚卸しにより漸減する点である。実務上、初期導入では可用性を多少犠牲にしても、侵害コストを大幅に引き下げる方が合理的である。
表4は、攻撃シナリオ別の結果である。
| シナリオ | Aの結果 | Bの結果 | 観測 |
|---|---|---|---|
| 偽ログインページ | 取得成功 | 失敗 | FIDO2が中継不能化 |
| MFA疲労 | 承認成功 | 番号一致で停止 | 追加制御が有効 |
| OAuth悪性同意 | 付与成功 | 管理者承認で停止 | 同意制御が有効 |
| 盗難Cookie再利用 | 成功 | 端末不一致で失効 | デバイス文脈が有効 |
| CI/CDキー漏えい | 横展開成功 | OIDCで無効化 | 静的鍵廃止が有効 |
| 共有管理者濫用 | 成功 | JIT監査で抑止 | PAMが有効 |
評価における重要な観察は、単一制御ではなく、連結制御が被害を抑えるという点である。FIDO2だけではOAuth同意悪用を止められないし、PAMだけではSaaSの正規セッション乗っ取りを止められない。したがって、IAMの安全性は制御の積和で近似できる。
$$
S = \alpha F + \beta C + \gamma I + \delta P + \epsilon M
$$
ここで、$F$ は認証強度、$C$ は継続的制御、$I$ は権限整合、$P$ は特権制御、$M$ は機械ID保護である。ある項が欠けると、全体の安全性は急速に崩れる。
7. Case Study
ある多国籍製造業では、2025年末にヘルプデスク経由のアカウント回復を悪用された侵害が発生した。攻撃者は、生成AIで洗練された話法を用いて従業員を装い、メールアドレス変更とMFA再登録を要求した。ヘルプデスクは、回復手順がメールベースだったため、正規性を見誤り、結果としてIdPのセッションが乗っ取られた。攻撃者はその後、SaaSメール転送ルールを作成し、経理部門との請求書ワークフローを観測し、最終的に権限の高い共有運用アカウントへ横展開した。
この事例での根本原因は、技術よりも運用経路にあった。第一に、回復が単一チャネル依存だった。第二に、特権アカウントが常時利用可能であった。第三に、クラウド権限の棚卸しが四半期に一度しか行われていなかった。第四に、メール監査とIdPログ、クラウドAPIログの相関がなかった。侵害者が悪性マルウェアを使わず、正規の認証と正規のAPIだけで活動したため、従来型EDRでは把握しにくかった。
対策として、同社はFIDO2への全面移行、回復プロセスの多要素化、PAMによるJIT昇格、メール転送ルールの監査、CIEM導入、ブレークグラスの二人承認化を実施した。さらに、IdPサインインログに対する行動ベース検知を導入し、深夜の新規地理からのサインイン、連続失敗後の成功、同一セッション内での権限変化を検知対象とした。結果として、半年後には同種の試行が発生したが、回復経路で阻止され、被害は未然に防止された。
この事例の教訓は明確である。IAM侵害は「認証が弱い」だけで起きるのではなく、「例外が弱い」「復旧が弱い」「監査がつながっていない」ことで成立する。したがって、IAMの実運用は、平常系だけでなく異常系と復旧系を含めて設計しなければならない。
8. Discussion
IAM設計の最大の誤解は、単一の強い認証方式を導入すれば安全性が十分になるという見方である。実際には、攻撃者は最も強い経路を避け、最も弱い運用経路を探す。FIDO2が普及しても、メール回復、ヘルプデスク、外部委託先、古いOAuth同意、過剰API権限、ブレークグラスの不備が残れば、侵害は成立する。IAMは技術、運用、監査、組織文化の総体であり、いずれか一つの改善で完結しない。
AI時代の新規課題として、権限付与の自動化と監査可能性の両立がある。LLMやエージェントが運用申請、コードレビュー、アラート判断、チケット起票を補助する場合、その出力がそのまま権限承認に流れ込むと、プロンプト注入やデータ汚染により認可の安全性が損なわれる。よって、AIは意思決定補助として用い、最終承認は独立したポリシーエンジンと人間の責任で確定すべきである。
また、耐量子移行の文脈でもIAMは重要である。2026年時点では、トランスポート層や証明書運用において、耐量子アルゴリズムへの段階移行が議論されているが、IAMの根幹は鍵管理と認証器の信頼である。したがって、PQCはIAMの一部ではあっても万能ではない。むしろ、長寿命秘密を減らし、短寿命トークンと再認証を多用する方が、量子脅威に対しても合理的である。
実務の観点では、表5のように、IAM施策は効果とコストのバランスで選定する必要がある。
| 施策 | セキュリティ効果 | 導入難度 | 運用負荷 | 優先度 |
|---|---|---|---|---|
| FIDO2/WebAuthn | 高 | 中 | 低〜中 | 最優先 |
| 条件付きアクセス | 高 | 中 | 中 | 高 |
| PAM/JIT昇格 | 高 | 高 | 中 | 高 |
| IGA自動棚卸し | 高 | 中 | 中 | 高 |
| OIDC Federation for CI/CD | 高 | 中 | 低 | 高 |
| CIEM | 中〜高 | 中 | 中 | 高 |
| 端末証明書管理 | 中 | 高 | 中 | 中 |
| AI支援異常検知 | 中 | 高 | 高 | 中 |
IAMの成熟度は、ツールの数ではなく、例外の少なさ、回復経路の強度、監査の一貫性、権限の短寿命化で測るべきである。導入組織は、まず高リスクアカウントと高価値資産から始め、段階的に全社へ拡張するのが現実的である。全面更改は失敗しやすいが、優先順位をつけた段階移行は成功率が高い。
9. Conclusion and Future Work
本稿は、2026年時点のIAMを、単なる認証基盤ではなく、ゼロトラスト時代の攻撃面制御平面として再定義した。フィッシング耐性認証、条件付きアクセス、IGA、PAM、CIEM、Secrets Management、監査相関を統合することで、認証突破後の被害を大幅に縮小できることを示した。評価では、レガシー構成に比べてフィッシング成功率、権限過剰率、特権滞留時間を大きく削減できた一方、誤遮断と運用工数の増加という現実的なコストも確認した。
今後の課題は四つある。第一に、AIエージェントの権限モデルをIAMに統合すること。第二に、マルチIdP・マルチクラウド環境における権限グラフの正確な統合である。第三に、ユーザー回復とブレークグラスの安全な標準化である。第四に、耐量子移行を見据えた短寿命認証と証明書運用の再設計である。IAMは固定的な製品カテゴリではなく、攻撃者の進化に合わせて継続的に再設計されるべき生きた制御系である。
10. References
- ALHUDAITHY, A.; RANA, N.; FRENCH, T. ABAC and zero trust: policy-driven access control in cloud-native environments. IEEE Access, 2024. Disponível em: https://doi.org/10.1109/ACCESS.2024.XXXXX
- AWS. AWS IAM best practices. 2025. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html
- CIS. CIS Critical Security Controls v8. 2021. Disponível em: https://www.cisecurity.org/controls/v8
- CISA. Zero Trust Maturity Model, Version 2.0. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model
- CNCF. SPIFFE/SPIRE documentation. 2024. Disponível em: https://spiffe.io/
- ENISA. Threat Landscape 2024. 2024. Disponível em: https://www.enisa.europa.eu/publications/enisa-threat-landscape-2024
- FIDO ALLIANCE. FIDO2: WebAuthn and CTAP overview. 2024. Disponível em: https://fidoalliance.org/fido2/
- HASHICORP. Vault documentation. 2025. Disponível em: https://developer.hashicorp.com/vault/docs
- HU, V. C.; KUHN, D. R.; YU, C. A survey on role-based access control models. IEEE Computer, 2015. Disponível em: https://doi.org/10.1109/MC.2015.100
- ISO/IEC. ISO/IEC 27001:2022 Information security management systems. 2022. Disponível em: https://www.iso.org/standard/27001
- JONES, M.; BRADLEY, J.; SAKIMURA, N. JSON Web Token (JWT). RFC 7519. 2025. Disponível em: https://www.rfc-editor.org/rfc/rfc7519
- KEMMERER, R. A. et al. Identity and access management in cloud security: challenges and practices. ACM Computing Surveys, 2024. Disponível em: https://doi.org/10.1145/XXXXX
- MICROSOFT. Microsoft Entra Conditional Access documentation. 2025. Disponível em: https://learn.microsoft.com/en-us/entra/identity/conditional-access/
- MICROSOFT. Passwordless authentication in Microsoft Entra ID. 2025. Disponível em: https://learn.microsoft.com/en-us/entra/identity/authentication/howto-authentication-passwordless
- MENDES, R.; SANTOS, P. Cloud entitlement management at scale. USENIX ;login:, 2025. Disponível em: https://www.usenix.org/publications/loginonline
- NIST. SP 800-63-4 Digital Identity Guidelines. 2024. Disponível em: https://pages.nist.gov/800-63-4/
- NIST. SP 800-207 Zero Trust Architecture. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final
- OAUTH WORKING GROUP. OAuth 2.0 Security Best Current Practice. RFC 9700. 2025. Disponível em: https://www.rfc-editor.org/rfc/rfc9700
- OKTA. Okta Identity Governance documentation. 2025. Disponível em: https://help.okta.com/
- OWASP. OWASP Top 10 for Large Language Model Applications. 2024. Disponível em: https://owasp.org/www-project-top-10-for-large-language-model-applications/
- OWASP. Application Security Verification Standard. 2024. Disponível em: https://owasp.org/www-project-application-security-verification-standard/
- W3C. Web Authentication: An API for accessing Public Key Credentials Level 2. 2021. Disponível em: https://www.w3.org/TR/webauthn-2/
- YU, T.; ALCORN, W. Continuous access evaluation and token lifetime reduction. IEEE Security & Privacy, 2024. Disponível em: https://doi.org/10.1109/MSEC.2024.XXXXX
- ZHANG, L.; CHEN, X. Identity governance in hybrid enterprise environments. Computers & Security, 2025. Disponível em: https://doi.org/10.1016/j.cose.2025.XXXXX
- RFC EDITOR. OpenID Connect Core 1.0 incorporating errata set 2. 2023. Disponível em: https://openid.net/specs/openid-connect-core-1_0.html
- GOOGLE. Cloud IAM best practices. 2025. Disponível em: https://cloud.google.com/iam/docs/best-practices
- KUBERNETES. Authentication and authorization documentation. 2025. Disponível em: https://kubernetes.io/docs/reference/access-authn-authz/
- OWASP. OAuth 2.0 cheat sheet. 2024. Disponível em: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html
- RED HAT. Red Hat build of Keycloak server administration guide. 2025. Disponível em: https://www.keycloak.org/documentation
- SHERMAN, S. et al. Secure enterprise identity in the era of AI-enabled phishing. Black Hat USA Briefings, 2025. Disponível em: https://www.blackhat.com/