本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「セキュリティアーキテクチャ」カテゴリ第3弾として、認可とIAMについて解説する記事です。
認証で鍵穴を通しても、認可でどこまで入れるかを絞らなければシステムは常時丸裸です。本記事の問いは「誰に何を許すか」です。RBAC／ABAC／ReBACの3モデル、最小権限の原則、IAM運用、そしてAI時代に人間より機械の権限を厳しくすべき理由を解説します。
本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。
この記事の結論
- 最小権限を貫く（「とりあえずAdmin」は最悪のアンチパターン）
- 規模に応じてRBAC→ABAC / ReBACとモデルを選ぶ
- ポリシーはコード（OPA / Cedar）+Gitで管理する
- AIエージェントの権限は人間より厳しくする
この記事を読む前に
本記事は認証・認可・暗号化といったセキュリティ用語が多めに登場します。IT用語にあまり馴染みがない方は、基礎編の「セキュリティと認証の基本」を先に読んでおくと格段に分かりやすくなると思います。また、読んでいて分からない用語が出てきたときは用語集で調べながら読み進められます。
そもそも認可とIAMとは何か
認可とIAMとは、ざっくり言えば「本人確認が済んだ相手に”何をしてよいか”を細かく制御する仕組み」です。
ホテルのカードキーを想像してください。チェックイン（認証）は全員通りますが、カードキーで開けられる部屋は人によって違います。一般客は自分の部屋だけ、清掃スタッフは全フロア、支配人は全室＋金庫室。この「誰に何を許すか」を設計・運用するのが認可であり、大量のユーザーと権限を一元管理する仕組みがIAMです。
なぜ認可とIAMが重要なのか
認証で本人を確認できても、権限設計が雑だと全員管理者と同じ状態になります。必要のない権限は内部不正・誤操作の被害を拡大させ、退職者が引き続きアクセスできる事件も頻発しています。SOX法・個人情報保護法・HIPAAなど多くの規制で「誰が何にアクセスできるか」の管理と監査が要求され、IAMが整備されていないと監査に落ちます。そしてクラウド時代はAWSだけで数百種類のAPIがあり、手動の権限管理は破綻します。
| 認証（AuthN） | 認可（AuthZ） | |
|---|---|---|
| 問い | 「あなたは誰？」 | 「それをする権限ある？」 |
| タイミング | ログイン時（1回） | 各操作時（毎回） |
| 例 | パスワード・MFA | ファイル読取・管理画面 |
認可の3モデル ― RBAC / ABAC / ReBAC
RBAC ― 90%のシステムはこれで十分
役割（ロール）に権限をまとめ、ユーザーにロールを付与する方式です。「営業部」「経理」「管理者」といったロールで管理がシンプル、監査もしやすく、90%以上のシステムがRBACベースです。弱点は例外ケースが苦手なことと、ロール数が100を超えると破綻の兆候が出ることで、それがABACへの移行を検討すべきサインです。
ABAC ― きめ細かい条件制御
ユーザー・リソース・環境の属性で動的に権限を判定する方式です。「営業部かつ東京支店の担当者は、自部署の顧客情報だけ見られる」のような多次元の制御ができ、ロール爆発を回避できます。AWS IAMポリシーのCondition句は実質ABACで、OSSではOPA（Open Policy Agent）・Cedar（AWS製）が定番です。代償は設計と監査の難しさです。
ReBAC ― Google Docs型の共有モデル
リソース間の関係で権限を判定する方式で、GoogleのZanzibarが有名です。「このドキュメントの所有者のメンバーは編集できる」「フォルダを共有すると配下ファイルも自動共有」のようなグラフ構造の権限管理ができ、SaaS・ソーシャル系で威力を発揮します。実装はSpiceDB・OpenFGAが定番です。共有機能が主役ならReBAC、通常の業務システムはRBACで十分です。
最小権限の原則とIAM運用
セキュリティの最重要原則の1つが、業務に必要な最小限の権限だけを付与することです。「とりあえず管理者権限」は最悪のアンチパターンで、権限はReadOnly+明示的Actionで始めて、必要が出たときに広げるのが唯一安全な設計です。後から広げるのは簡単ですが、絞るのはほぼ不可能です。
2019年のCapital One情報流出事件は、WAFの設定ミス（SSRF）を入口に、EC2インスタンスのIAMロールが過剰権限を持っていたことが致命傷となり、約1億600万件の顧客情報がS3から持ち出されました。最小権限を貫いていれば、WAFが破られてもS3までは届かなかった事例です。
運用面では、退職者・異動者の権限の即日削除、四半期1回の権限棚卸し、Root / Adminアカウントの日常利用禁止（MFA必須+IAMユーザー分離）、本番・開発の環境別ロール分離が基本です。
機械間認証とAIエージェント
人ではなくシステム同士の認証・認可もIAMの重要な領域です。クラウド内のサービス同士はService Account、Kubernetes PodからクラウドAPIへはWorkload Identity、マイクロサービス間はmTLS、外部連携はOAuth Client Credentialsが定番で、いずれも永続的なAPI Keyは極力避け、短命トークンを発行する設計が現代の標準です。
権限の委譲（AWSのRole Assumption・OAuthのOn-Behalf-Of等）を使う場合は、監査ログで「誰が誰の権限で何をしたか」を追跡可能にしておくのが必須です。誤った実装はConfused Deputy（権限を持つ仲介役を騙す攻撃）を招きます。
どう選べばいいのか ― 段階別ロードマップ
IAMは「いきなりABAC」では運用が止まるため、規模と複雑度で段階的に昇格させます。
| フェーズ | 規模 | 推奨モデル | 実装例 |
|---|---|---|---|
| ① スタートアップ | 〜10人 | 素のRBAC（admin / editor / viewer） | ロール3〜5個 |
| ② 成長期 | 〜30人 | RBAC+部署属性 | ロール10〜30個 |
| ③ 中規模SaaS | 〜300人 | ABAC | OPA / Cedarで条件付き |
| ④ 共有機能あり | 規模不問 | ReBAC | OpenFGA / SpiceDB |
| ⑤ 大企業・規制業種 | 3000人〜 | ABAC+職務分掌 | 承認フロー+監査ログ |
金融は職務分掌・承認フロー、医療はアクセスログ・患者別制御、政府系は多段階承認など、規制業種では監査要件がモデル選定に上乗せされます。
3つのシナリオで考える
個人開発・スタートアップの場合
admin / editor / viewerの3〜5ロールくらいの、素のRBACで十分だと思います。ClerkやSupabase Authの標準ロール機能に乗ってしまい、認可チェックはミドルウェア1箇所に集約しておきましょう。この段階でABACやReBACを組むのは、完全な過剰設計と言えます。
中小SaaSの場合
RBACに部署属性を加えた形から始めて、「このドキュメントをこのユーザーに共有」のようなテナントを越える共有機能が出てきた時点で、ReBAC（OpenFGAやSpiceDB）を検討するのが良いでしょう。B2B契約ではロールのカスタマイズ要求が必ず来ますので、ロール定義をコードではなく設定データとして持つ設計にしておくと後々助かります。
大企業・規制業種の場合
ABAC（OPAやCedar）に職務分掌・承認フロー・監査ログまで含めたフル装備となります。金融なら職務分掌、医療なら患者別のアクセス制御、政府系なら多段階承認と、規制要件がモデル選定に上乗せされていくイメージです。人事異動と権限変更をIdP連動で自動化しておかないと、棚卸しのたびに膨大な手作業が発生してしまいます。
AI判断軸 ― エージェントの権限は人間より厳しく
AIエージェントのIAM設計が新しい必須項目になった
AIエージェントが本番環境でコード生成・デプロイ・データアクセスを行う構成が増えています。AIは人間より高速に大量の操作を実行するため、権限設計は人間より厳しくする必要があります。具体的には、エージェントごとに別のIAMロール（共通ロールの使い回し禁止）、操作スコープの明示的制限、トークン有効期限1時間以内、全操作の監査ログ記録と異常検知の自動化です。
AIが書くIAMポリシーは過剰権限になりがち
AIにIAMポリシーのJSONを書かせることは可能ですが、AIは「動かすこと」を優先して "Resource": "*" や "Action": "s3:*" のような過剰権限を書きがちです。IAM Access Analyzer等のCIチェックを必ず組み込み、過剰権限を自動検知する仕組みが前提です。ポリシーをOPA / Cedarでコード化+Git管理していれば、このチェックをPRレビューに組み込めます。
やってはいけないこと
過剰権限 → 侵害時に被害最大化という構造の典型を、特に危険な6つに絞ります。
| 禁じ手 | なぜダメか → どうするか |
|---|---|
| 「とりあえずAdmin」で開発・運用 | 後で絞る日は来ない。Capital One事件のパターン → ReadOnlyから始める |
| 永続API Keyをアプリ埋め込み | 漏洩で即アクセスされる → OIDC Federation+一時認証にする |
| 退職者のアクセス権限を放置 | 内部不正の踏み台になる → 退職当日の自動削除を仕組み化する |
| ロール棚卸しを実施しない | 権限が累積してAdminだらけになる → 四半期1回の棚卸しを運用する |
| ポリシーをGUIで手作業管理 | 変更履歴が残らず再現不能 → OPA / Cedarでコード化+Gitにする |
| AIエージェントに管理者権限を付与 | 高速大量操作で被害甚大 → エージェントごとに専用・最小権限にする |
筆者メモ ― 「過剰権限」が企業を一撃で沈めた事例
最も有名なのが2019年のCapital One事件で、「IAMロールの一行の甘さ」が8,000万ドル規模の制裁金に化けました（詳細は付録「重大インシデント事例集」）。もう一つ、2019年に米大手銀行で発覚した事案では、退職した元エンジニアのAWSアカウントが数か月間削除されずに残っていたことが内部不正の踏み台に使われました。退職処理のチェックリストにIAMの行が1行抜けていただけ、という地味なミスが数千万ドル規模の損害に繋がった典型例です。
どちらも派手なゼロデイ攻撃ではなく「最小権限と棚卸しの怠り」が根本原因です。IAMは地味な運用こそ最強の防御で、最小権限+定期棚卸し+ポリシーのコード化に尽きます。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- 認可モデル（RBAC / ABAC / ReBAC）
- ロール設計（業務ロールの棚卸し）
- ポリシー管理方法（OPA / Cedarでコード化+Git）
- 最小権限の運用（棚卸し頻度・承認フロー）
- 機械間認証（Service Account・mTLS・短命トークン）
- AIエージェントの権限境界（スコープ・期限・監査ログ）
この記事に関連する記事
まとめ
本記事は認可とIAMについて、RBAC・ABAC・ReBACの3モデル・最小権限・IAM運用・AI時代に機械の権限を厳しくする理由まで含めて解説しました。如何だったでしょうか。
最小権限を貫き、規模に応じてモデルを選択し、ポリシーをコードで管理し、エージェント権限を人間より厳しくする。これが2026年の認可とIAMの現実解です。
次回は暗号化（TLS・AES・KMS・鍵管理）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は AWS IAM も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（54/95）