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

本記事について

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

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

本記事のテーマについてさらに詳しく知りたい方は『AWSの基本・仕組み・重要用語が全部わかる教科書』も参考にしてみてください。

そもそも認可とIAMとは何か

認可とIAMとは、ざっくり言えば「本人確認が済んだ相手に”何をしてよいか”を細かく制御する仕組み」です。

ホテルのカードキーを想像してください。チェックイン（認証）は全員通りますが、カードキーで開けられる部屋は人によって違います。一般客は自分の部屋だけ、清掃スタッフは全フロア、支配人は全室＋金庫室。この「誰に何を許すか」を設計・運用するのが認可であり、大量のユーザーと権限を一元管理する仕組みがIAMです。

この記事の守備範囲

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

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

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

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

なぜ必要か

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

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

② 規制・監査対応

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

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

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

認証と認可の違い

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

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

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つで、業務に必要な最小限の権限だけを付与する考え方です。「とりあえず管理者権限」は最悪のアンチパターンで、侵害時の被害を最小化するためにも、権限は必ず絞ります。

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

IAMの主要概念

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

クラウドIAMの比較

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

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

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

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

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

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

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

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

判断基準

① システム規模

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

② 規制要件

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

ケース別の選び方

一般的な業務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」では運用が止まるため、規模と複雑度で段階的に昇格させます。

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

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

やってはいけないこと

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

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

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

AI判断軸

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

AIエージェントのIAM設計が新しい必須項目になった

2026年現在、AIエージェントが本番環境でコード生成・デプロイ・データアクセスを行う構成が増えています。この場合、AIエージェントにも人間と同じレベルのIAM設計が必要です。むしろ、AIは人間より高速に大量の操作を実行するため、権限設計は人間より厳しくする必要があります。

具体的な設計指針は次の通りです。

• エージェントごとに別のIAMロール（共通ロールの使い回し禁止）
• 操作スコープを明示的に制限（読み取り専用/特定リソース限定）
• トークンの有効期限を1時間以内に設定
• 全操作をCloudTrail/監査ログに記録し、異常検知を自動化

IAMポリシーのコード生成とレビュー

AIにIAMポリシーのJSONを書かせることは可能ですが、AIは「動かすこと」を優先して"Resource": "*"や"Action": "s3:*"のような過剰権限を書きがちです。IAMポリシーのCIチェック（IAM Access AnalyzerやParliment）を必ず組み込み、過剰権限を自動検知する仕組みが前提です。

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

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

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

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

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

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

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

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

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

この記事に関連する記事

https://senkohome.com/arch-intro-security-overview/ https://senkohome.com/arch-intro-security-secrets/ https://senkohome.com/arch-intro-security-zerotrust/

まとめ

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

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

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

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

本記事で扱った内容の詳細は AWS IAM も合わせて参考にしてください。

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