LESSON 30分

ストーリー

田
田中VPoE
認証で「あなたは誰か」を確認した。次は認可 —「あなたは何ができるか」を制御する仕組みだ
あなた
RBACは使っています。admin、editor、viewerのようなロールを定義して、APIごとに必要なロールをチェックしています
あ
田
田中VPoE
基本的なRBACは良いが、BtoB SaaSではそれだけでは不十分な場面がある。例えば「テナントAの管理者はテナントBのデータにアクセスできない」。これはロールだけでは制御できない。リソースレベルの認可が必要だ
あなた
テナント分離とロールの組み合わせですね
あ
田
田中VPoE
そうだ。さらに複雑な要件になると「ドキュメントの作成者とそのチームメンバーだけが編集できる」のような関係ベースの認可（ReBAC）も必要になる。Google DriveやGitHubの権限モデルがこれだ

認可モデルの比較

4つの主要モデル

モデル正式名称判定基準適用場面複雑度
RBACRole-Based Access Controlロール社内システム、シンプルなAPI低
ABACAttribute-Based Access Control属性の組み合わせ条件付きアクセス中
PBACPolicy-Based Access Controlポリシー（ルール）クラウドリソース（AWS IAM）中〜高
ReBACRelationship-Based Access Controlリソース間の関係ファイル共有、SNS、マルチテナント高

RBAC（ロールベースアクセス制御）

RBAC モデル:

ユーザー ──→ ロール ──→ パーミッション

例（PayConnect）:
  User: alice ──→ Role: admin ──→ Permissions: [create, read, update, delete]
  User: bob   ──→ Role: viewer ──→ Permissions: [read]
  User: carol ──→ Role: editor ──→ Permissions: [create, read, update]

判定:
  can(alice, "delete", "invoice") → true（admin は delete 可能）
  can(bob, "delete", "invoice")   → false（viewer は read のみ）
利点制限
シンプルで理解しやすいテナント分離ができない
実装が容易リソース単位の制御が困難
管理コストが低いロール爆発（細かい権限=大量のロール）

ABAC（属性ベースアクセス制御）

ABAC モデル:

判定 = f(ユーザー属性, リソース属性, 環境属性, アクション)

ポリシー例:
  IF  user.role == "editor"
  AND resource.tenant_id == user.tenant_id  ← テナント分離
  AND environment.time IN business_hours     ← 時間帯制約
  AND action IN ["read", "update"]
  THEN ALLOW

例:
  can(alice{tenant:A, role:editor}, "update", invoice{tenant:A})
  → true（同一テナント + editor ロール）

  can(alice{tenant:A, role:editor}, "update", invoice{tenant:B})
  → false（テナント不一致）

ReBAC（関係ベースアクセス制御）

ReBAC モデル:

判定 = ユーザーとリソースの「関係」に基づく

関係の定義:
  document:annual-report#owner@user:alice
  document:annual-report#editor@team:finance
  team:finance#member@user:bob
  team:finance#member@user:carol

判定ロジック:
  can(alice, "edit", "annual-report")
  → alice は owner → edit 可能 ✓

  can(bob, "edit", "annual-report")
  → bob は finance の member
  → finance は annual-report の editor
  → edit 可能 ✓

  can(dave, "edit", "annual-report")
  → dave は関係なし → edit 不可 ✗

認可エンジンの選定

ツールモデル特徴適用場面
OPA（Open Policy Agent）PBACRego言語、汎用、Kubernetes統合インフラ、API認可
Cedar（AWS）ABAC + RBACRust実装、高速、AWS Verified PermissionsAWS環境
OpenFGAReBACGoogle Zanzibar inspired、OSSファイル共有、複雑な権限
SpiceDB（Authzed）ReBACZanzibar準拠、高パフォーマンス大規模BtoB SaaS
CasbinRBAC/ABAC/ReBAC多言語対応、軽量小〜中規模アプリ

OPA（Open Policy Agent）による認可

# OPA ポリシー例（PayConnect）
package payconnect.authz

default allow = false

# 管理者は全操作が可能
allow {
    input.user.role == "admin"
    input.resource.tenant_id == input.user.tenant_id
}

# エディターは読み取りと更新が可能
allow {
    input.user.role == "editor"
    input.resource.tenant_id == input.user.tenant_id
    input.action in ["read", "update"]
}

# ビューアーは読み取りのみ可能
allow {
    input.user.role == "viewer"
    input.resource.tenant_id == input.user.tenant_id
    input.action == "read"
}

# テナント不一致は常に拒否（暗黙のデフォルト deny）

マルチテナント認可のパターン

マルチテナント認可の実装パターン:

パターン1: テナントIDフィルタリング（シンプル）
  SELECT * FROM invoices
  WHERE tenant_id = :current_user_tenant_id
  AND id = :requested_invoice_id

パターン2: Row Level Security（PostgreSQL）
  CREATE POLICY tenant_isolation ON invoices
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

パターン3: 認可エンジン（OPA/Cedar）
  // API ミドルウェアで認可チェック
  const allowed = await opa.evaluate({
    user: req.user,
    action: "read",
    resource: { type: "invoice", id: invoiceId, tenant_id: tenantId }
  });
  if (!allowed) return res.status(403).json({ error: "Forbidden" });

認可のベストプラクティス

プラクティス説明
デフォルト拒否明示的に許可されない限り、すべてのアクセスを拒否する
一元的な認可ロジック各APIに個別実装ではなく、認可エンジンに集約する
認可の監査ログ全ての認可判定（許可/拒否）をログに記録する
テスト可能な認可ポリシーに対する自動テストを書く
権限の定期レビュー四半期ごとにアクセス権限を棚卸しする

まとめ

ポイント内容
4つの認可モデルRBAC（ロール）、ABAC（属性）、PBAC（ポリシー）、ReBAC（関係）
テナント分離RBACだけでは不十分。ABACやRLSでテナント分離を実現
認可エンジンOPA、Cedar、OpenFGA等を活用し、認可ロジックを集約
ベストプラクティスデフォルト拒否、一元管理、監査ログ、テスト、定期レビュー

チェックリスト

  • RBAC、ABAC、ReBAC の違いを説明できる
  • マルチテナント認可のパターンを理解した
  • OPA/Cedar等の認可エンジンの特徴を把握した
  • 認可のベストプラクティスを理解した

次のステップへ

次は「フェデレーションとSSO」を学びます。複数のIdPやサービスを横断するID連携の設計方法を身につけましょう。

推定読了時間: 30分