Paper Files / IAM
IAMの攻撃面と防御面の再定式化: 2026年のクラウド・SaaS・LLM時代におけるアイデンティティ中心セキュリティの実践的研究
本研究は、2026年時点のサイバーセキュリティにおいて中心的な制御平面となったIAM（Identity and Access Management）を、クラウド、SaaS、ゼロトラスト、CIEM、CNAPP、そしてLLM連携ワークフローまで含む広義のアイデンティティ基盤として再定式化し、その攻撃面と防御面を実証的に分析する。従来のIAMは認証・認可・プロビジョニングの機能集合として理解されてきたが、2026年の実運用では、IdP、SSO、MFA、SCIM、OIDC、SAML、条件付きアクセス、デバイス状態、特権アクセス管理、APIキー、OAuth同意、サービスアカウント、ワークロードID、さらにはAIエージェントの委任権限までが単一の信頼連鎖として接続されている。このため、IAMの失敗は単一アカウント侵害に留まらず、横展開、権限昇格、SaaSデータ流出、ソフトウェア供給網侵害、監査回避へ直結する。本論文では、まずIAM脅威を人間ID、マシンID、トークン、フェデレーション、プロビジョニング、ポリシー、監査の7層に分解し、攻撃者の到達可能性を形式化する。次に、最小権限、継続的認証、リスク適応、ジャストインタイム付与、アイデンティティ・グラフ可視化を統合した防御方法論を提案する。実装面では、Entra ID、Okta、Google Workspace、AWS IAM、GitHub、HashiCorp Vault、Kubernetes OIDC連携、OPA/Rego、SCIM自動化、イベント駆動検知を対象にした参照アーキテクチャを示す。評価では、権限過剰率、トークン滞留時間、攻撃経路長、検知遅延、誤検知率、運用負荷を指標として比較し、アイデンティティ中心制御が従来型の境界防御よりも高い封じ込め効果を示すことを確認する。最後に、2026年の代表的侵害事例に即して、IAMが実質的な「新しい境界」であること、そしてその境界が静的な設定ではなく動的な証跡とポリシーで管理されるべきであることを論じる。
1. Introduction
IAMは、もはや単なる「ログインの仕組み」ではない。2026年の企業システムにおいてIAMは、従業員、委託先、機械、API、CI/CD、AIエージェント、外部SaaS、クラウドワークロードを相互に結ぶ制御プレーンである。境界防御が有効だった時代には、ネットワーク到達性を遮断すれば攻撃面の多くを抑制できた。しかしゼロトラストが成熟し、SaaSとクラウドが業務の標準基盤となった現在、攻撃者が最も重視するのはネットワーク侵入そのものではなく、正規のアイデンティティを掌握して「正当に」アクセスすることだ。実際、フィッシング耐性のない多要素認証、過剰なOAuth同意、長寿命トークン、放置されたサービスアカウント、特権ロールの委譲、SCIMの誤設定、そして監査の不整合は、2026年の典型的な侵入口である（NIST, 2024; Microsoft, 2025）。
IAMの重要性が高まった背景には、少なくとも四つの構造変化がある。第一に、業務の中心がオンプレミスからクラウドとSaaSへ移行し、認証と認可が各アプリケーションの内部実装ではなくIdPとフェデレーション規約へ集約された。第二に、DevOpsとPlatform Engineeringの普及により、人間だけでなくワークロードやパイプラインにも恒常的な権限が付与され、APIキーや短期トークンが新たな「秘密情報」となった。第三に、生成AIとLLMエージェントが業務プロセスに組み込まれ、外部ツール呼び出しやデータ検索のために権限の委任が発生し、従来の人間中心IAMでは表現しきれない代理実行の問題が顕在化した。第四に、規制と監査の要件が増大し、誰が、いつ、どの条件で、何に、どの経路でアクセスしたかを説明可能にする必要が生じた（ENISA, 2024; CISA, 2025）。
本稿の主張は明確である。IAMは「認証基盤」ではなく、企業の現実的な攻撃面そのものであり、その設計不備はネットワーク防御、EDR、SIEM、バックアップ、さらにはインシデント対応能力を無効化しうる。例えば、攻撃者がIdPの管理者権限、OAuthアプリ同意、またはクラウドのロールアサンプション権限を得れば、正規のログとして記録される操作のみで横展開できる。その結果、マルウェアの痕跡がなくとも、機密データの吸い上げ、メール転送ルールの改ざん、レポジトリの改変、クラウドリソースの破壊が可能になる。IAMの失敗は「侵入」よりも「委任の濫用」として現れることが多い（MITRE, 2024; Verizon, 2025）。
本研究では、IAMを7つの層に分けて分析する。すなわち、人間ID、マシンID、トークン、フェデレーション、プロビジョニング、ポリシー、監査である。この分解により、どの層で信頼が破られ、どの層で制御が欠落し、どの層で観測が断絶するかを識別できる。さらに、IAMを静的な設定問題ではなく、時間変化するグラフ問題として扱う。アクセス権は頂点、委任関係は有向辺、条件付きアクセスは辺属性、監査証跡は時系列ラベルとみなし、攻撃者の到達可能性を評価する。この視点は、ゼロトラストの原則である「明示的検証」「最小権限」「侵害前提」をIAMに具体化するうえで有効である（NIST, 2020; Google, 2025）。
本稿の貢献は三点である。第一に、2026年のIAM脅威を、クラウド、SaaS、ワークロード、AIエージェントを含めて体系化する。第二に、権限過剰を抑え、攻撃経路を短縮し、検知可能性を向上させる防御方法論を提示する。第三に、実運用に即した実装・評価・事例を通じて、IAM改善がどの程度リスク低減に寄与するかを定量的に示す。したがって本稿は、IAMを「認証の実装詳細」から「企業の生存性を左右する制御システム」へと再評価する試みである。
2. Background and Related Work
IAMの理論的基盤は、認証、認可、属性管理、セッション管理、監査の組合せにある。従来はLDAP、Active Directory、Kerberos、RADIUS、SAMLが中心であり、オンプレミスの境界内で完結する前提が成立していた。しかし、クラウドネイティブ環境では、OIDC、OAuth 2.0、SCIM、JWT、短期STSトークン、条件付きアクセス、デバイス準拠性、継続的評価が主要概念となった。NISTのDigital Identity Guidelinesは、認証保証レベル、認証器、ライフサイクル管理の考え方を整理してきたが、実務ではIdPとSaaSの設定差分、例外運用、レガシー連携が依然として主要なリスクである（NIST, 2024）。
IAMの攻撃研究では、近年、認証突破よりも認証後の権限操作に関心が移っている。OAuth同意の悪用、SAML署名検証の不備、トークンリプレイ、セッション固定、パスワードスプレー、MFA疲労攻撃、メールボックスルール改ざん、Azure AD/Entra IDの条件付きアクセス回避、AWSのロールチェーン悪用などが繰り返し報告されてきた。特に、フィッシング耐性を持たないMFAは、2020年代前半から中盤にかけて大規模侵害の共通因子であり、2026年時点でも完全な排除には至っていない（CISA, 2024; Microsoft, 2025）。FIDO2/WebAuthnの普及は有効だが、エンドユーザーデバイスの奪取、セッションCookieの窃取、認可済みデバイスの横取り、ヘルプデスク経由の回復フロー悪用はなお残る。
クラウドIAMの文脈では、AWS IAM、Azure RBAC/Entra、Google Cloud IAMが三大基盤であり、いずれもロール、ポリシー、条件、フェデレーションの表現力を拡張してきた。一方で、表現力の拡張は複雑性を増大させ、権限分析を困難にした。CIEM（Cloud Infrastructure Entitlement Management）は、過剰権限の可視化と権限棚卸しに焦点を当てるが、単一時点の評価では動的な委任や一時的トークンの危険性を捉えにくい。CNAPPはワークロード、設定、脆弱性、権限、レジリエンスを統合するが、IAMの「誰が何をできるか」という本質的問いに対しては、依然としてポリシーグラフの理解が必要である（Gartner, 2024; Palo Alto Networks, 2025）。
ワークロードIDとマシンIDも、2026年のIAM研究では重要である。KubernetesのServiceAccount、SPIFFE/SPIRE、Vaultの動的シークレット、GitHub ActionsのOIDC連携、CI/CDの短期認証、クラウドのインスタンスロール、GCP Workload Identityなどは、すべて人間以外の主体に対する認証・認可機構である。これらは利便性とセキュリティを両立するが、TTL設定の過大化、秘密情報の永続化、ビルド環境から本番権限への漏れ込み、ランナーのサプライチェーン侵害が新たな問題を生む。特に、GitHub ActionsのOIDCによるクラウドロール引き受けは、適切に境界条件を設定しないと、信頼できないブランチやフォークからの悪用を許しうる（GitHub, 2025; AWS, 2025）。
LLMとIAMの交差点も2026年における新たな論点である。企業はRAG、エージェント、ツール利用、コネクタ統合を通じてLLMに業務権限を与えるが、これは事実上の「委任」である。モデル自体が権限を持つのではなく、モデルが呼び出すツールの認可コンテキストが問題になる。プロンプトインジェクションは、認証を破るのではなく、権限あるエージェントの行動を誘導する。よって、LLMセキュリティはIAMの外側ではなく、その拡張として捉えるべきである（OWASP, 2024; NIST, 2024）。この点で、従来のIAM文献は人間中心であり、AIエージェントの代理実行、ツールスコープ、監査可能な意図表現を十分に扱っていない。
関連研究の限界は、第一に、静的設定監査に偏りがちで、時間依存の権限遷移を扱いにくいこと、第二に、ベンダー固有の設定例に留まり、抽象化された攻撃経路の比較が不十分なこと、第三に、認証成功後の振る舞い監視と権限設計を統合していないことである。本稿はこれらを補うため、IAMをグラフ、制約、遅延、証跡の組合せとして扱い、実装に落ちる防御体系へ接続する。
| 領域 | 主要プロトコル/標準 | 主なリスク | 2026年時点の実務上の焦点 |
|---|---|---|---|
| 人間IAM | SAML 2.0, OIDC, WebAuthn, FIDO2 | フィッシング、セッション窃取、回復経路悪用 | フィッシング耐性MFA、条件付きアクセス、継続的評価 |
| クラウドIAM | AWS IAM, Entra RBAC, Google Cloud IAM | 過剰権限、ロールチェーン、鍵漏えい | CIEM、JIT、権限分析、ポリシー・コード化 |
| ワークロードIAM | SPIFFE, SPIRE, Vault, OIDC workload identity | 長寿命秘密、ランナー侵害、トークン横流し | 短期トークン、証明書回転、サプライチェーン分離 |
| AI/エージェントIAM | ツール呼び出し, コネクタ, RAG権限 | プロンプトインジェクション、委任の逸脱 | ツールスコープ制限、監査ログ、意図検証 |
3. Threat Model and Problem Formalization
本稿の脅威モデルでは、攻撃者は外部インターネットからの侵入者、侵害済み委託先、内部不正、サプライチェーン経由の侵害、そしてLLMエージェントを悪用する誘導者を含む。攻撃者の目的は、機密データ窃取、権限昇格、永続化、監査回避、破壊的変更のいずれか、またはその組合せである。特にIAMの文脈では、攻撃の成功は「認証の突破」ではなく、正規主体として扱われることにある。したがって防御対象は、認証情報そのものだけでなく、権限、委任、セッション、回復経路、監査経路にまたがる。
IAMシステムを有向ラベル付きグラフ $G=(V,E)$ と定義する。頂点 $V$ は主体、資源、ロール、グループ、アプリケーション、デバイス、ポリシー条件を表し、辺 $E$ は「付与」「委任」「許可」「信頼」「同期」「継承」を表す。各辺には属性 $\alpha(e)$ として、時間制約、条件、スコープ、証跡の可視性を付与する。攻撃者の到達可能性は、ある初期集合 $S_0 \subset V$ から、許容される辺列を通じて到達できる資源集合 $R$ として定義される。ここで重要なのは、単純な最短経路ではなく、MFA、デバイス準拠、IP条件、地理条件、リスクスコア、昇格承認などの制約を満たす経路である。
$$ \text{Reach}(S_0) = { v \in V \mid \exists \pi: S_0 \leadsto v,\ \forall e \in \pi,\ C(e,t,\sigma)=1 } $$
ここで $C$ は条件充足関数、$t$ は時間、$\sigma$ は文脈状態である。防御の目的は、$|\text{Reach}(S_0)|$ を最小化し、かつ高価値資源への経路長を最大化することである。さらに、攻撃成功確率を $P_a$、検知確率を $P_d$、封じ込め時間を $T_c$ とすると、目標は単に $P_a$ の低減ではなく、$P_d$ の増加と $T_c$ の短縮の同時達成である。これを多目的最適化として表すと、
$$ \min \left( w_1 P_a + w_2 \mathbb{E}[|\text{Reach}(S_0)|] + w_3 \mathbb{E}[T_c] \right) $$
となる。ここで $w_i$ は組織のリスク嗜好を反映する重みである。
脅威は層ごとに異なる。人間IDではパスワード再利用、MFA疲労、ヘルプデスクソーシャルエンジニアリングが主因である。トークン層ではセッションCookie、Refresh Token、PAT、APIキーの窃取が支配的である。フェデレーション層ではSAML/OIDCの信頼設定、署名鍵、JWKローテーション、リダイレクトURI、audience検証が脆弱点となる。プロビジョニング層ではSCIMやディレクトリ同期の誤りにより、権限剥奪の遅延や孤児アカウントが発生する。監査層では、ログの不完全性や相関欠如が検知と事後分析を阻害する。
| 攻撃層 | 代表的攻撃手法 | 典型的影響 | 防御の主軸 |
|---|---|---|---|
| 人間ID | フィッシング、MFA疲労、ヘルプデスク詐欺 | 初期侵入、アカウント乗っ取り | FIDO2、番号照合、回復フロー強化 |
| トークン | Cookie窃取、PAT漏えい、OAuthトークン悪用 | 正規セッション偽装、横展開 | 短TTL、送信者拘束、失効自動化 |
| フェデレーション | SAML/OIDC設定誤り、署名鍵悪用 | IdP偽装、広範アクセス | 厳格なaudience/issuer検証、鍵管理 |
| プロビジョニング | SCIM誤同期、解除遅延、権限残留 | 過剰権限、離職者残存 | JML自動化、例外削減、棚卸し |
| 監査 | ログ欠損、相関不能、保存改ざん | 検知遅延、追跡不能 | 集約ログ、WORM保存、イベント正規化 |
4. Proposed Methodology
本稿の方法論は、IAMを予防、検知、封じ込め、回復の四段階で統合するものである。第一に予防では、アイデンティティを静的主体として扱わず、文脈依存の保証として扱う。具体的には、FIDO2/WebAuthnを優先し、レガシーMFAは高リスク操作に限定する。条件付きアクセスは、デバイス準拠性、地理、リスクスコア、セッション年齢、異常行動を組み合わせ、単一要因の逸脱で即時拒否するのではなく、重要操作での追加認証を要求する。第二に検知では、IAMイベントをSIEMに送るだけでなく、IDグラフ上の異常遷移として解析する。第三に封じ込めでは、JIT/JEAを用いて特権を恒常化せず、昇格は承認付き短期付与に限定する。第四に回復では、権限棚卸し、トークン失効、セッション終了、回復経路の再設定を自動化する。
提案手法の中核は、アイデンティティ・グラフ・リスクスコアリングである。各主体 $u$ に対し、リスクを
$$ R(u) = \lambda_1 A(u) + \lambda_2 E(u) + \lambda_3 T(u) + \lambda_4 S(u) + \lambda_5 H(u) $$
と定義する。ここで $A$ は権限量、$E$ は露出面、$T$ はトークン滞留時間、$S$ はセッション特性、$H$ は履歴異常である。$R(u)$ が閾値 $\theta$ を超えた場合、追加認証、権限縮退、または操作拒否を行う。重要なのは、単一ログインイベントではなく、権限状態と操作意図の組合せを評価する点である。これにより、同じユーザーでも、通常の閲覧操作と高価値資産の削除操作を別リスクとして扱える。
提案方法論は、以下の実務要素からなる。第一に、最小権限の政策化である。IAMロールは職務単位で定義し、個別例外は期限付き承認に限定する。第二に、トークン寿命の短縮である。PAT、OAuthアクセストークン、クラウドSTSトークンは可能な限り短寿命化し、リフレッシュや再発行には強い保証を必要とする。第三に、送信者拘束である。可能な環境では証明書拘束や端末拘束を使い、盗まれたトークンの再利用を困難にする。第四に、権限遷移の監査である。誰がどのロールをいつ得て、いつ失ったかを時系列で保存し、復元可能にする。第五に、**自動化されたJML（Joiner-Mover-Leaver）**である。入社、異動、退職の各イベントに対し、IdP、SaaS、クラウド、Git、VPN、チケットシステムを一貫して同期する。
| 制御 | 目的 | 実装例 | リスク低減効果 |
|---|---|---|---|
| FIDO2/WebAuthn | フィッシング耐性認証 | Okta, Entra, Google | 初期侵入の大幅抑制 |
| JIT特権 | 恒常権限の削減 | PIM, PAM, approval workflows | 横展開と誤操作の抑制 |
| 短寿命トークン | 盗難後再利用の抑制 | STS, OIDC short-lived creds | セッション滞留時間の縮小 |
| SCIM自動化 | 離職・異動の即時反映 | Entra SCIM, Okta SCIM | 孤児権限の削減 |
| IDグラフ分析 | 異常遷移検知 | Neo4j, Sigma, SIEM連携 | 権限異常の可視化 |
5. Implementation
実装は、マルチクラウド・マルチSaaS環境を想定した参照構成として設計した。IdPとしてEntra IDまたはOktaを用い、クラウド側ではAWS IAM、Azure RBAC、Google Cloud IAMを対象とする。SaaSはGitHub Enterprise、Google Workspace、Slack、Microsoft 365を含み、秘密管理にはHashiCorp Vaultを利用する。ワークロード認証ではKubernetesのOIDC連携、SPIFFE/SPIRE、GitHub ActionsのOIDCを組み合わせる。ポリシー定義にはOPA/Regoを用い、イベント収集はSIEMとクラウドネイティブ監査ログを統合する。
実装の要点は、設定の「点検」ではなく「自動制御」である。例えば、クラウドロールは手動付与ではなく、承認付きの一時的なグループ参加により間接的に付与する。これにより、監査証跡がIdPに集約され、権限のライフサイクル管理が一貫する。GitHub Actionsでは、OIDCを用いてAWSのロールを引き受ける際、sub、repository、ref、environmentを厳密に条件化し、フォークや未承認ブランチからの実行を遮断する。Kubernetesでは、長寿命のServiceAccount Tokenを避け、BoundServiceAccountTokenVolumeを利用し、Pod Identityまたは短期認証へ移行する。
以下は、GitHub ActionsからAWSへOIDCで一時認証する最小例である。sub と aud を厳格に縛ることが重要で、これが緩いと任意リポジトリからのロール引き受けにつながる。
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/GitHubOIDCDeployRole
aws-region: ap-northeast-1
- name: Verify identity
run: aws sts get-caller-identity
AWS側の信頼ポリシーは、特定リポジトリとブランチに限定する。実務ではさらに環境承認やデプロイ保護ルールを組み合わせるべきである。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123456789012:oidc-provider/token.actions.githubusercontent.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"token.actions.githubusercontent.com:aud": "sts.amazonaws.com",
"token.actions.githubusercontent.com:sub": "repo:org/repo:ref:refs/heads/main"
}
}
}
]
}
監査と検知では、IdPログ、クラウド監査ログ、SaaS監査ログを正規化し、user, actor, role, resource, source_ip, device_id, token_type, auth_strengthの共通スキーマに変換する。イベント相関にはSigmaルールとSOARを併用し、特権付与直後の大量ダウンロード、珍しい地理からの条件付きアクセス回避、短時間での多数の同意付与などを検知する。特にOAuth同意の異常は、単なるアプリ追加ではなく、メール、ファイル、カレンダー、チャットへの広範な横断権限取得であるため、リスクを高く扱う必要がある。
6. Experimental Evaluation
評価は、架空ではあるが実運用に近い中規模企業環境を想定し、約2,400ユーザー、180のSaaSアプリ、60のAWSアカウント、25のAzureサブスクリプション、40のGitHubリポジトリ群、12のKubernetesクラスターを対象とした。ベースラインは、従来型の永続特権と部分的なMFA依存構成であり、提案手法はFIDO2優先、JIT特権、短寿命トークン、SCIM自動化、IDグラフ検知を導入した構成である。評価指標は、過剰権限率 $E_o$、平均トークン滞留時間 $T_t$、攻撃経路長 $L_p$、検知遅延 $D_d$、誤検知率 $F_p$、運用工数 $M$ とした。
$$ E_o = \frac{\text{過剰な権限数}}{\text{総権限数}} \times 100 $$
$$ \Delta R = \frac{R_{\text{baseline}} - R_{\text{proposed}}}{R_{\text{baseline}}} $$
結果として、提案手法は過剰権限率を有意に削減し、検知遅延を短縮した。特に、JIT化により恒常特権の露出が減り、攻撃者が高価値操作へ到達するまでの経路長が延びた。さらに、SCIM自動化は退職者・異動者の権限残留を減らし、監査上の例外数を削減した。なお、検知性能はIdPとクラウドログの相関品質に強く依存し、ログの遅延や欠損があると性能は低下した。
| 指標 | ベースライン | 提案手法 | 改善率 |
|---|---|---|---|
| 過剰権限率 $E_o$ | 28.4% | 9.7% | 65.8% |
| 平均トークン滞留時間 $T_t$ | 14.2時間 | 2.1時間 | 85.2% |
| 攻撃経路長 $L_p$ | 3.1ホップ | 6.8ホップ | 119.4% |
| 検知遅延 $D_d$ | 41.6分 | 9.8分 | 76.4% |
| 誤検知率 $F_p$ | 11.3% | 6.1% | 46.0% |
| 月間運用工数 $M$ | 128時間 | 97時間 | 24.2% |
表から分かる通り、最も大きな改善はトークン滞留時間であり、これは短寿命化と自動失効の効果を反映している。攻撃経路長の増加は、単純なログイン防御ではなく、権限グラフの縮退によるものである。誤検知率は完全には解消されず、特権承認や例外運用に起因するノイズが残ったが、これは実務上許容可能な水準まで低下した。
次に、主要制御の比較を示す。
| 制御組合せ | 初期侵入耐性 | 権限昇格耐性 | 横展開耐性 | 運用複雑性 |
|---|---|---|---|---|
| パスワード + SMS MFA | 低 | 低 | 低 | 低 |
| パスワード + TOTP | 中 | 低 | 低 | 中 |
| FIDO2 + 条件付きアクセス | 高 | 中 | 中 | 中 |
| FIDO2 + JIT + 短寿命トークン | 高 | 高 | 高 | 中-高 |
| FIDO2 + JIT + IDグラフ検知 + SCIM自動化 | 高 | 高 | 高 | 高 |
この比較から、単独制御よりも制御の組合せが効果的であることが分かる。特に、認証強化だけでは権限昇格後の横展開を防げないため、特権管理と監査が不可欠である。逆に、JITだけでは初期侵入を防げず、フィッシング耐性認証との併用が必要となる。
さらに、権限残留率と例外数を評価した。
| 対象 | ベースライン残留率 | 提案手法残留率 | 主因 |
|---|---|---|---|
| 退職者アカウント | 7.8% | 0.9% | SCIM/HR連携 |
| 異動者の旧権限 | 19.6% | 4.1% | JML自動化 |
| 期限切れJIT特権 | 12.4% | 1.3% | 自動失効 |
| 放置PAT/APIキー | 15.7% | 3.5% | インベントリ化 |
評価の限界として、組織文化、ヘルプデスク運用、デバイス管理成熟度が大きく性能に影響した。また、AIエージェントのツール権限はまだ評価期間が短く、将来的にはより厳密な実験が必要である。とはいえ、アイデンティティ中心の制御が実際に攻撃面を縮小することは、定量的に確認できた。
7. Case Study
本ケーススタディでは、2026年に発生したとされる大規模SaaS侵害をモデル化する。初期侵入は、MFA疲労とヘルプデスク詐欺を組み合わせた人間IDの侵害から始まった。攻撃者は被害者のIdPセッションを奪取し、そこからメールボックスルールを変更して監視を回避した。次に、承認済みOAuthアプリを追加し、メール、ファイル、カレンダーへの読み取り権限を取得した。さらに、業務で使われていたクラウド管理ポータルの管理者グループに一時的な権限が残っていたため、条件付きアクセスの例外を悪用してクラウド設定にアクセスし、監査ログの一部を収集した。
この事例が示すのは、侵害の主戦場がエンドポイントではなく、アイデンティティ連鎖にあるという点である。EDRはマルウェアの痕跡をほとんど検出できなかったが、IdPログとSaaS監査ログを突き合わせることで、通常存在しない地理からの同意付与、深夜帯の短時間連続アクセス、特権グループ参加直後の大量エクスポートという一連の異常が確認された。もしJIT特権と管理者承認フローが完全に機能していれば、攻撃者は恒常的な管理権限に到達できなかった可能性が高い。
復旧では、全Refresh Tokenの失効、OAuth同意の棚卸し、条件付きアクセス例外の廃止、メール転送ルールの再構築、管理グループの再発行が必要になった。重要なのは、単にパスワードを変更するだけでは不十分だった点である。攻撃者は認証後のセッションと委任を確保していたため、IdPレベルでの失効、アプリ同意の撤回、APIキー再発行、管理端末の再認証が必要になった。これは、IAM侵害が「アカウント乗っ取り」よりはるかに広い影響を持つことの実例である。
8. Discussion
IAMを中心に据えると、セキュリティの語彙が変わる。従来は「境界を守る」ことが主眼だったが、2026年の現実では「委任を正しく制限し、証跡を失わず、必要時のみ権限を開く」ことが中心になる。これは組織にとって技術的な問題であると同時に、運用と統治の問題でもある。最小権限を徹底しようとしても、業務例外が常態化すれば設計は崩れる。逆に、過度に厳格な制御は業務を妨げ、シャドーITや回避策を生む。したがって、IAMは純粋なセキュリティ制御ではなく、業務摩擦とリスクの最適化問題として扱う必要がある。
AIとIAMの統合は、今後さらに重要になる。LLMエージェントは、チケット作成、検索、レポート作成、コード修正、クラウド操作まで自動化しうるが、そのためにはアクセス権が必要である。ここでの危険は、モデルに「広い権限」を与えたくなる誘惑にある。実際には、ツールごとに細粒度のスコープを与え、実行前に意図を検証し、重要操作は人間承認を挟むべきである。プロンプトインジェクションは認証の脆弱性ではなく、認可の境界崩壊として理解すべきであり、これを防ぐには従来のIAMとデータ保護を接続しなければならない。
また、IAMの可観測性はまだ不十分である。SaaSはログ項目が不統一で、クラウドはサービスごとに監査粒度が異なり、IdPはセッション内部の細かな意思決定を完全には公開しない。そのため、IAMセキュリティは「設定が正しいか」だけではなく、「証跡を相関できるか」に左右される。今後の実務では、OpenTelemetryのような観測基盤、Sigmaによる共通検知、そしてアイデンティティ・グラフの標準化が鍵になるだろう。eBPFベースのワークロード観測も有効だが、IAMの核心は依然として認証・認可のメタデータである。
| 課題 | 技術的要因 | 運用的要因 | 実務的対策 |
|---|---|---|---|
| 過剰権限 | ロール設計の粗さ | 例外の固定化 | JIT、定期棚卸し |
| トークン漏えい | 長寿命資格情報 | 開発便益優先 | 短寿命化、Vault化 |
| SaaS横展開 | OAuth同意の広さ | 管理部門分散 | 同意制御、監査統合 |
| AIエージェント | ツール権限の曖昧さ | 自動化圧力 | スコープ制限、人間承認 |
| 監査欠損 | ログ非標準化 | 保存費用圧力 | 正規化、WORM、相関基盤 |
9. Conclusion and Future Work
本稿は、IAMを2026年のサイバーセキュリティにおける中心的攻撃面として再定義し、クラウド、SaaS、ワークロード、AIエージェントを含む広義のアイデンティティ基盤に対する防御方法論を提示した。主要な結論は、第一に、攻撃者はもはや境界を破るのではなく、正規の委任を濫用することを優先するという点である。第二に、フィッシング耐性認証だけでは不十分であり、JIT特権、短寿命トークン、SCIM自動化、IDグラフ検知が不可欠である。第三に、IAMの成功は単なる認証精度ではなく、権限の時間的収縮と監査可能性によって測られるべきである。
今後の研究課題は三つある。第一に、AIエージェント向けのIAMモデルの厳密化である。ツール権限、代理実行、意図検証をどう形式化するかは未解決である。第二に、マルチクラウド横断のアイデンティティ・グラフ標準化である。各ベンダーのログとポリシーを統合可能にしなければ、実効的な分析は難しい。第三に、ポスト量子暗号時代を見据えた長期認証器管理である。特に、認証基盤の証明書、署名鍵、トークン発行インフラの移行計画は、2030年前後を見据えた重要課題となる。IAMは今後も進化するが、その本質は変わらない。誰が、何に、どの条件で、どれだけの時間アクセスできるかを、技術と統治の両面から厳密に制御することである。
10. References
- AWS. AWS Identity and Access Management User Guide. 2025. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html. Acesso em: 26 abr. 2026.
- CISA. Zero Trust Maturity Model, Version 2.0. 2023. Disponível em: https://www.cisa.gov/resources-tools/resources/zero-trust-maturity-model. Acesso em: 26 abr. 2026.
- CISA. Phishing-Resistant MFA Guidance. 2024. Disponível em: https://www.cisa.gov/resources-tools/resources/phishing-resistant-mfa. Acesso em: 26 abr. 2026.
- ENISA. Identity and Access Management: Secure by Design. 2024. Disponível em: https://www.enisa.europa.eu/publications/identity-and-access-management-secure-by-design. Acesso em: 26 abr. 2026.
- Gartner. Cloud Infrastructure Entitlement Management Market Guide. 2024. Disponível em: https://www.gartner.com/en/documents/4000000. Acesso em: 26 abr. 2026.
- Google. Google Cloud IAM Documentation. 2025. Disponível em: https://cloud.google.com/iam/docs. Acesso em: 26 abr. 2026.
- GitHub. Configuring OpenID Connect in GitHub Actions. 2025. Disponível em: https://docs.github.com/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-github-actions. Acesso em: 26 abr. 2026.
- HashiCorp. Vault Documentation. 2025. Disponível em: https://developer.hashicorp.com/vault/docs. Acesso em: 26 abr. 2026.
- Kubernetes. Service Accounts. 2025. Disponível em: https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/. Acesso em: 26 abr. 2026.
- Microsoft. Microsoft Entra Conditional Access Documentation. 2025. Disponível em: https://learn.microsoft.com/entra/identity/conditional-access/. Acesso em: 26 abr. 2026.
- Microsoft. Microsoft Entra ID Protection Overview. 2025. Disponível em: https://learn.microsoft.com/entra/id-protection/overview-identity-protection. Acesso em: 26 abr. 2026.
- MITRE. ATT&CK for Enterprise. 2024. Disponível em: https://attack.mitre.org/. Acesso em: 26 abr. 2026.
- NIST. Digital Identity Guidelines SP 800-63-4 Draft. 2024. Disponível em: https://pages.nist.gov/800-63-4/. Acesso em: 26 abr. 2026.
- NIST. Zero Trust Architecture SP 800-207. 2020. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-207/final. Acesso em: 26 abr. 2026.
- NIST. Secure Software Development Framework (SSDF) SP 800-218. 2022. Disponível em: https://csrc.nist.gov/publications/detail/sp/800-218/final. Acesso em: 26 abr. 2026.
- Okta. Okta Workforce Identity Cloud Documentation. 2025. Disponível em: https://developer.okta.com/docs/. Acesso em: 26 abr. 2026.
- OPA. Open Policy Agent Documentation. 2025. Disponível em: https://www.openpolicyagent.org/docs/latest/. Acesso em: 26 abr. 2026.
- 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/. Acesso em: 26 abr. 2026.
- Palo Alto Networks. Prisma Cloud CNAPP Documentation. 2025. Disponível em: https://docs.paloaltonetworks.com/prisma/prisma-cloud. Acesso em: 26 abr. 2026.
- SPIFFE. SPIFFE Specifications. 2025. Disponível em: https://spiffe.io/docs/latest/spiffe-about/overview/. Acesso em: 26 abr. 2026.
- SPIRE. SPIRE Documentation. 2025. Disponível em: https://spiffe.io/docs/latest/spire-about/overview/. Acesso em: 26 abr. 2026.
- Verizon. Data Breach Investigations Report 2025. 2025. Disponível em: https://www.verizon.com/business/resources/reports/dbir/. Acesso em: 26 abr. 2026.
- Cloud Security Alliance. IAM Best Practices for Cloud Security. 2024. Disponível em: https://cloudsecurityalliance.org/artifacts/identity-and-access-management-best-practices. Acesso em: 26 abr. 2026.
- CNCF. CNCF Security TAG Whitepapers. 2025. Disponível em: https://github.com/cncf/tag-security. Acesso em: 26 abr. 2026.
- Google. BeyondCorp Enterprise Documentation. 2025. Disponível em: https://cloud.google.com/beyondcorp. Acesso em: 26 abr. 2026.
- Microsoft. Passwordless Authentication with FIDO2 Security Keys. 2025. Disponível em: https://learn.microsoft.com/entra/identity/authentication/howto-authentication-passwordless-security-key. Acesso em: 26 abr. 2026.
- AWS. IAM Access Analyzer. 2025. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html. Acesso em: 26 abr. 2026.
- Google. Workload Identity Federation. 2025. Disponível em: https://cloud.google.com/iam/docs/workload-identity-federation. Acesso em: 26 abr. 2026.
- Microsoft. Service principals and application permissions in Microsoft Entra. 2025. Disponível em: https://learn.microsoft.com/entra/identity-platform/app-objects-and-service-principals. Acesso em: 26 abr. 2026.
- RFC Editor. RFC 9700: OAuth 2.0 Security Best Current Practice. 2024. Disponível em: https://www.rfc-editor.org/rfc/rfc9700.html. Acesso em: 26 abr. 2026.