認可とIAM ― 最小権限を貫く実務 ― 生成AI時代のアーキテクチャ超入門

本記事について

当サイトを閲覧いただきありがとうございます。本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第3弾として、認可とIAMについて解説する記事です。

認証で鍵穴を通しても、認可でどこまで入れるかを絞らなければシステムは常時丸裸（Capital One事件の1億人流出が典型）。本記事ではRBAC／ABAC／ReBACの3モデル、最小権限の原則、IAM運用、サービスアカウント、そしてAI時代に人間より機械の権限を厳しくすべき理由を解説します。

このカテゴリの他の記事

概要 ― 多層防御とゼロトラストの全体像 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-overview/

認証設計 ― IDaaS+Passkey+短命トークンの基本 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-auth/

暗号化 ― 鍵管理が暗号の強度を決める ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-encryption/

ネットワークセキュリティ ― 境界からゼロトラストへ ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-network/

ゼロトラスト ― 何も信用せず常に検証する ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-zerotrust/

秘密情報管理 ― ゼロ秘密化が最高の防御 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-secrets/

脆弱性診断 ― CIに組み込み毎日検査する運用 ― 生成AI時代のアーキテクチャ超入門senkohome.com/arch-intro-security-vuln/

この記事の守備範囲

記事	扱う範囲
本記事（認可とIAM）	RBAC / ABAC / ReBAC / 最小権限 / IAM運用 / Service Account
50/01 認証設計	認証強度 / MFA / Passkey / IDaaS / SSO
20/07 認証・セッション	セッション技術 / JWT / OAuth実装
30/07 認証認可	ブラウザ側の認可UI / XSS / CSRF

本記事の問いは「誰に何を許すか」本人確認ではなく、権限の設計と運用の話です。

鍵を配る相手が増えるほど、家は危うくなる

認証で「本人」を確認できても、権限設計が雑だと全員管理者と同じ状態になります。認可は最小権限の原則に基づき、必要最小限の権限だけを付与するのが鉄則です。

「全員にadmin権限」は最も多いインシデントの温床。最小権限を貫きます。

なぜ必要か

① 内部不正・事故の被害を限定する

必要のない権限を持たせると、内部不正・誤操作で大きな被害が出ます。退職者が引き続きアクセスできる事件も頻発します。

② 規制・監査対応

SOX法（米国企業改革法）・個人情報保護法・HIPAA（米国医療情報保護法）──多くの規制で誰が何にアクセスできるかの管理と監査が要求されます。IAMが整備されていないと監査に落ちます。

③ クラウド時代は権限が爆発する

AWS だけで数百種類のAPIがあり、マイクロサービス・SaaSが増えるほど権限管理が複雑化します。手動管理は破綻するため、体系的なIAM設計が必須です。

認証と認可の違い

よく混同される2つの概念ですが、役割は明確に違います。認証で「誰か」を確認し、認可で「何ができるか」を決めます。両方が揃って初めて安全なアクセス制御になります。

	認証（AuthN）	認可（AuthZ）
目的	本人確認	権限判定
問い	「あなたは誰？」	「それをする権限ある？」
タイミング	ログイン時	各操作時
例	パスワード・MFA	ファイル読取・管理画面

認証は1回、認可は毎回行われます。認可のロジックを軽量かつ正確に設計できるかが、システムのスケーラビリティとセキュリティを左右します。

flowchart LR
    subgraph RBAC_BLOCK["RBAC (ロールベース)"]
        U1[ユーザー] --> R1[ロール]
        R1 --> P1[権限]
    end
    subgraph ABAC_BLOCK["ABAC (属性ベース)"]
        U2[ユーザー属性] --> POL[ポリシー]
        RES[リソース属性] --> POL
        ENV[環境属性<br/>時間/場所] --> POL
        POL --> P2[権限判定]
    end
    subgraph REBAC_BLOCK["ReBAC (関係ベース)"]
        U3[ユーザー] -.|owner of| DOC1[Doc]
        U3 -.|member of| TEAM[Team]
        TEAM -.|access to| DOC2[Doc]
    end
    classDef rbac fill:#dbeafe,stroke:#2563eb;
    classDef abac fill:#fef3c7,stroke:#d97706;
    classDef rebac fill:#fae8ff,stroke:#a21caf;
    class RBAC_BLOCK,U1,R1,P1 rbac;
    class ABAC_BLOCK,U2,RES,ENV,POL,P2 abac;
    class REBAC_BLOCK,U3,DOC1,DOC2,TEAM rebac;

RBAC（ロールベース認可）

RBAC は、役割（ロール）に権限をまとめ、ユーザーにロールを付与する方式です。「営業部」「経理」「管理者」といったロールに必要な権限を定義し、ユーザーにロールを割り当てるだけで権限管理ができます。管理がシンプルで、90%以上のシステムがRBACベースです。

メリット	デメリット
管理がシンプル	例外ケースが苦手
監査しやすい	ロール爆発（数百ロールに）
一括変更が容易	粒度が粗い

ロール数が100を超えると破綻の兆候で、ABACへの移行を検討すべきサインです。

ABAC（属性ベース認可）

ABAC は、ユーザー・リソース・環境の属性を使って動的に権限を判定する方式です。「営業部かつ東京支店の担当者は、自部署の顧客情報だけ見られる」のようなきめ細かい制御が可能で、RBACでは表現できない複雑なルールを記述できます。

メリット	デメリット
柔軟で粒度が細かい	設計が難しい
ロール爆発を回避	監査が複雑
時間・場所で制御可能	実装コストが高い

AWS IAM ポリシーは実質ABACで、Condition句で属性による制御ができます。OSSの実装としては Open Policy Agent（OPA）・Cedar（AWS製）が注目されています。

ReBAC（関係ベース認可）

ReBAC は、リソース間の関係を使って権限を判定する方式で、Google の Zanzibar が有名です。「このドキュメントの所有者のメンバーは編集できる」のようなグラフ構造の権限管理ができ、SaaS・ソーシャル系サービスで威力を発揮します。

適する場面	例
階層構造	組織階層の権限継承
所有関係	ドキュメント・フォルダ所有
メンバーシップ	グループ・チーム単位
共有リンク	外部公開・招待

OSSの実装：SpiceDB・OpenFGA（Auth0）・Permify──これらが現代の ReBAC の実装です。Google Docs のような柔軟な共有が必要なら ReBAC を検討する価値があります。

Google Docs的な共有機能があるならReBAC。通常の業務システムはRBACで十分です。

最小権限の原則

セキュリティの最も重要な原則の1つで、業務に必要な最小限の権限だけを付与する考え方です。「とりあえず管理者権限」は最悪のアンチパターンで、侵害時の被害を最小化するためにも、権限は必ず絞ります。

やってはいけない	正しい設計
全員admin	役割別ロール
無期限のAPI Key	短命トークン・ローテーション
全リソースアクセス	リソース単位で絞る
本番と開発の権限共通化	環境別にロール分離

定期的な権限棚卸しも重要で、退職者・異動者の権限は即座に削除、使っていない権限は定期的に縮小するのが運用の基本です。2019年7月の Capital One 情報流出事件は、過剰に設定された IAM ロールと WAF の設定ミスが突かれ、約1億600万件の顧客データが S3 から持ち出されました。最小権限を貫いていれば、WAF が破られても S3 までは届かなかった事例です。

IAMの主要概念

IAM は複数の概念の組み合わせで設計されます。クラウド（AWS・GCP・Azure）の IAM は若干用語が違いますが、構造はほぼ同じです。

概念	意味
Identity（アイデンティティ）	人・サービス・デバイスなどの主体
Principal	権限を付与される実体
Role	権限のまとまり
Policy	具体的な許可/拒否のルール
Resource	保護対象（データ・API等）
Action	操作（読取・書込・削除）
Condition	条件（時間・場所・MFA有無）

クラウドIAMの比較

クラウド3社のIAMは設計思想が少しずつ違い、それぞれに癖があります。複数クラウドを使う場合は、両方を正しく理解する必要があります。

特徴	AWS IAM	GCP IAM	Azure AD
基本モデル	Policy中心・細かい	Role中心・シンプル	RBAC中心・階層
粒度	極めて細かい	中程度	細かい
学習コスト	高い	低い	中
ベストプラクティス	最小権限・ロール分離	組み込みロール優先	グループ中心

AWS IAMは粒度細かいが難しいため、ポリシー設計を専門家に任せる企業も多いです。

サービスアカウントと機械間認証

人ではなくシステム同士の認証・認可もIAMの重要な領域です。マイクロサービス間通信・バッチジョブ・AIエージェントなど、非人間のアクセスが爆発的に増えています。

認証方式	用途
Service Account	クラウド内のサービス同士
Workload Identity	K8s（Kubernetes）Pod → クラウドAPI
mTLS（相互TLS）	マイクロサービス間
OAuth Client Credentials	外部システム連携
SPIFFE / SPIRE	汎用ID基盤（OSS標準）

永続的なAPI Keyは極力避け、短命のトークンを発行する設計が現代の標準です。

権限の委譲と代理アクセス

「AさんのPermissionでBさんが作業する」「サービスAがサービスBの権限で呼び出す」という権限の委譲も設計論点です。誤った実装は横取り攻撃（Confused Deputy、権限を持つ仲介役を騙して攻撃者の操作を代行させる手口）を招きます。

パターン	方式
Role Assumption（AWS）	STS（Security Token Service、一時認証トークン発行）で一時的に別ロールに変身
Impersonation（GCP）	サービスアカウントの代理実行
On-Behalf-Of（OAuth）	認可済ユーザーの代理操作
Delegation（委譲）	明示的な権限の付与

委譲は監査ログで「誰が誰の権限で何をしたか」を追跡可能にしておくのが必須です。

判断基準

① システム規模

IAMの複雑さはシステム規模で決まります。小規模でABACやReBACを採用すると過剰で、運用が追いつきません。

規模	推奨
小規模・数ロール	RBAC（シンプルに）
中規模・条件分岐あり	RBAC + 属性条件
大規模・権限が複雑	ABAC（OPA・Cedar）
ソーシャル・共有多い	ReBAC（SpiceDB・OpenFGA）

② 規制要件

監査対応が必要な業種では、権限の付与・変更・利用の全てを記録できる仕組みが必須です。

業種	必須IAM要件
金融	職務分掌・承認フロー・監査ログ
医療	アクセスログ・最小権限・患者別制御
政府系	多段階承認・物理隔離・クリアランス
一般企業	退職者処理・定期棚卸し

ケース別の選び方

一般的な業務SaaS（部署と役割が主軸）

RBAC + クラウドIAM組み込みロール。部署・職種でロールを切り、Okta/Entra IDで一元管理。複雑化したら条件（Condition）で補強。

Google Docs系の共有モデル（所有者・閲覧者）

ReBAC（SpiceDB / OpenFGA）。所有・共有・階層の関係をグラフで表現できるため、「ユーザーがフォルダを共有すると配下ファイルも自動共有」といった振る舞いを自然に実装できる。

金融・医療の厳格なアクセス制御

ABAC（OPA / Cedar）+ 強い監査。部署 × データ種別 × 時間帯 × MFA有無のような多次元条件を制御可能。承認フロー・職務分掌をIAMに組み込む。

マイクロサービス間・AIエージェント

Workload Identity + 短命トークン + mTLS。永続API Keyは禁止。エージェントごとに専用サービスアカウントを発行し、スコープを最小化。

権限設計の段階別ロードマップ

IAMは「いきなりABAC」では運用が止まるため、規模と複雑度で段階的に昇格させます。

フェーズ	人数・規模	推奨モデル	実装例	ロール数目安
① スタートアップ	〜10人	素のRBAC	admin / editor / viewer	3〜5個
② 成長期	〜30人	RBAC + 部署属性	RBAC + Department条件	10〜30個
③ 中規模SaaS	〜300人	ABAC（属性ベース）	OPA / Cedarで条件付き	30〜100個
④ 共有機能あり	規模不問	ReBAC（関係ベース）	OpenFGA / SpiceDB	グラフ関係
⑤ 大企業・規制業種	3000人〜	ABAC + 職務分掌	承認フロー + 監査ログ	数百個

「ロール数が100個を超えると破綻の兆候」で、ABACへの移行を検討すべきサインです。「とりあえずAdmin」は侵害時の被害を最大化する最悪のアンチパターン。1ロールに絞ることから始めて、必要が出たときに権限を広げるのが唯一安全な設計です。

権限はReadOnly + 明示的Actionで始める。後から広げるのは簡単、絞るのはほぼ不可能です。

IAM運用の鬼門・禁じ手

IAMで事故る典型パターンを整理します。どれも過剰権限 → 侵害時に被害最大化という構造を持ちます。

禁じ手	なぜダメか
「とりあえずAdmin」で開発・運用	後で絞る日は来ない。Capital One 2019年事件（過剰IAMロールで1億600万件流出）のパターン
永続API Keyをアプリ埋め込み	漏洩で即アクセス。OIDC Federation + 一時認証 + Service Accountへ
退職者のアクセス権限を数ヶ月放置	2019年米大手銀行の内部不正事例。退職当日のプロビジョニング自動化が必須
ロール棚卸しを実施しない	権限が累積してAdminだらけに。四半期1回の棚卸しを運用
Root / Adminアカウントの日常利用	最大権限での操作ミスで全消失。MFA必須 + IAMユーザーに分離
サービスアカウントを人間ユーザー扱い	MFA困難、権限管理不透明。Service Account専用ロールに分離
本番・開発・ステージングの権限共通化	開発ミスが本番に伝播。環境別にロール分離
ポリシーをGUIで手作業管理	変更履歴が残らない・再現不能。OPA / Cedarでコード化 + Git
AIエージェントに管理者権限付与	高速大量操作で被害甚大。エージェントごとに専用・最小権限
監査ログを本番アカウント内に保管	侵害時にログごと消される。別アカウント + WORM

Capital One 2019年事件はIAMロールの1行の甘さが数十億円の損害に化ける典型例（詳細は本記事の業界事例セクションと付録「重大インシデント事例集」）。

IAMは地味な運用こそ最強の防御。最小権限 + 定期棚卸し + ポリシーのコード化です。

AI時代の視点

AI駆動開発（バイブコーディング）とAI活用が前提になると、IAMはAIエージェントの権限境界として極めて重要になります。AIが自律的にシステムを操作する時代には、「AIがどこまでやっていいか」を権限で制御しないと、暴走時の被害が甚大です。

AI時代に有利	AI時代に不利
短命トークン・スコープ限定	永続API Key・全権限
OPA・Cedarでポリシーをコード化	設定画面で手動管理
エージェントごとに別ロール	全エージェント共通ロール
操作ログ・監査が完備	ログなし・履歴追跡不可

AIエージェントは人間より危険です。高速で大量の操作を行うため、誤った認可は分単位で大損害を生みます。エージェントの権限は人間より厳しくがAI時代の新常識です。

AI時代のIAMは人間より機械の権限を厳しく。暴走時の被害範囲を限定します。

筆者メモ — 「過剰権限」が企業を一撃で沈めた事例

IAM設計の怠りが一撃で企業を沈める、という話はセキュリティ業界の定番の語り草になっています。

最も有名なのが2019年のCapital One情報流出事件で、元AWSエンジニアによる「WAFの設定ミス経由のSSRF攻撃」を入口に、EC2インスタンスのIAMロールが過剰権限を持っていたことが致命傷となり、約1億600万件の顧客情報がS3から持ち出されました。最小権限を貫いていれば、WAFが破られてもS3までは届かなかったはずで、「IAMロールの一行の甘さ」が8,000万ドル規模の制裁金に化けた事例として語り継がれています。

もう一つ、2019年に米大手銀行で発覚した事案では、「退職した元エンジニアのAWSアカウントが数か月間削除されずに残っていた」ことが、内部不正による顧客情報持ち出しの踏み台に使われました。退職処理のチェックリストに AWS IAM の行が1行抜けていただけという地味なミスが、数千万ドル規模の損害に繋がった典型例です。

筆者も過去、検証用に付与した強い権限をうっかり本番用ユーザーに広げてしまい、監査で指摘されるまで気づかなかった経験があります。どちらも派手なゼロデイ攻撃ではなく「最小権限と棚卸しの怠り」が根本原因で、地味な運用こそが最強の防御だという教訓を突きつけます。

IAM事故は1行の甘さで起きる。棚卸しとポリシーのコード化が最強の防御です。

よくある勘違い

とりあえずadmin権限で動かして後で絞る → 後で絞る日は来ない、というのはIAM運用の定番の教訓です。AdministratorAccessで走り始めたサービスが2年経っても一度も絞られず、CloudTrailを眺めても「この権限は削っていいか」の判断がつかなくなり、誰も触れなくなった、という事例はいくらでも聞かれます
ロール数は少ない方が管理しやすい → 少なすぎると権限が粗くなります。ただし100超える場合はABAC移行を検討。バランスが重要
認可は後回しでOK → 後から入れるのが最も難しい機能。初期設計で必ず組み込む。リファクタが最悪の展開になります
IAMはインフラチームの仕事 → アプリケーション層の認可は開発チームの仕事です。インフラIAMとアプリ認可は別物

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。

認可モデル（RBAC / ABAC / ReBAC）
ロール設計（業務ロールの棚卸し）
ポリシー管理方法（コード化・GitOps（Git管理のファイルから自動反映する運用手法））
最小権限の運用（棚卸し頻度・承認フロー）
機械間認証（Service Account・mTLS）
監査ログ（誰がいつ何をしたか）
AIエージェントの権限境界（スコープ・期限）

最終的な判断の仕方

認可とIAMの核心は最小権限の原則を貫くことであり、「とりあえずadmin」は最悪のアンチパターンです。認証で本人確認できても、権限設計が雑なら全員管理者と同じ状態になります。小規模ならRBAC、複雑化したらABAC、共有関係が主役ならReBACという段階設計が合理的で、最初から過剰な仕組みを入れると運用が止まります。権限の棚卸しと退職者処理を組み込んだ運用プロセスが、技術選定と同じくらい重要になります。

もう一つの決定的な軸は人間より機械（AIエージェント）の権限を厳しくすることです。AIは高速で大量の操作を行うため、誤った認可は分単位で大損害を生みます。永続API Keyを禁止し、エージェントごとに別サービスアカウント + 短命トークン + スコープ限定で閉じ込め、OPA / Cedarでポリシーをコード化してGit管理するのが、AI時代のIAM設計の形になります。

選定の優先順位

最小権限を貫く — adminデフォルト禁止、必要最小限だけ付与し、定期的に棚卸し
規模に応じてモデルを選択 — 小はRBAC、中〜大はABAC、共有主役ならReBAC
ポリシーをコードで管理 — OPA / Cedar + Gitを使い、GUI手動管理は属人化の罠
エージェント権限は人間より厳しく — 短命トークン・スコープ限定・操作ログ完備

「人間より機械の権限を厳しく」最小権限をコードで管理し、暴走時の被害範囲を限定します。

まとめ

本記事は認可とIAMについて、RBAC・ABAC・ReBACの3モデル・最小権限・IAM運用・Service Account・AI時代に人間より機械の権限を厳しくする理由まで含めて解説しました。如何だったでしょうか。

最小権限を貫き、規模に応じてモデルを選択し、ポリシーをコードで管理し、エージェント権限を人間より厳しくする。これが2026年の認可とIAMの現実解です。

次回は暗号化（TLS・AES・KMS・鍵管理）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。