APIでのアクセス制御とRBAC

1）なぜAPIアクセス制御

認可は質問に対する答えです"このアクターは今、このリソースでこのアクションを実行できますか？».エラーは、BOLA/IDOR漏洩、権利のエスカレーション、規制要件の違反につながります。目的は、マルチレベルモデルを構築することです：境界→サービスマッシュ→ビジネスルール、明示的なポリシーとオブジェクトレベルでのチェック。

2）承認モデル： 何を選ぶべき時

RBAC （Role-Based Access Control）-役割→権限。シンプルで安定しているが「、役割爆発」が起こりやすい。
ABAC （Attribute-Based）-サブジェクト/オブジェクト/コンテキスト（国、KYCレベル、リソース所有者、リスク）の属性の決定。
ReBAC（関係ベース）-関係グラフ（所有者、チームメンバー、「プロジェクトマネージャー」）；複雑な階層を解決します。
スコープ（OAuth）-「アクセスエリア」に関するクライアントとリソースサーバの間の契約（例：「payments： write」）。
実践：基本行列のRBAC、コンテキストと制約のABAC、複雑な階層（フォルダ、組織、限界、podaccounts）のReBAC。

3）資源・行動の分類

階層：'org→project→wallet→transaction'。可能な「リミッター」で上から下への権利の継承。
アクション：CRUD+ドメイン固有（'approve'、 'refund'、 'settle'）。
リソースプロパティ：所有者、地域、ステータス、リスクタグ（AML/KYC）、制限。
マルチテナンシー：すべてのソリューションに'tenant_id'が含まれています。deny-by-defaultを指定します。

4）建築： 決定がなされるところ

PEP（ポリシー執行ポイント）-検証サイト：ゲートウェイ/APIゲートウェイ、サイドカーmash、サービス自体。
PDP （Policy Decision Point）-ポリシーエンジン：集中型（OPA-service、 Cedar-engine）または組み込みライブラリ。
PIP （Policy Information Point）-属性ソース：ユーザー/ロールディレクトリ、テナントプロファイル、CCP/リスク、リソース所有権マップ。
PAP （Policy Administration Point）-ポリシーのバージョン管理、公開、監査。

推奨事項：PEPでの一元化されたPDP+ローカルソリューションキャッシュ；複雑なオブジェクトは、ドメインインバリアントの存在下でサービスをチェックします。

5）トークン、スタンプ、アイデンティティ

OIDC/OAuth2： 'sub' （サブID）、 'aud'（ターゲットサービス）、'scope'/'roles'、 'tenant'、 'kyc_level'、 'risk_tier'。
JWT： RS/ES署名、短い'exp'、リフレッシュによる再リリース。PIIを入れないでください。失効/トラック監査には'jti'を使用します。
mTLS/HMAC：サービス・ツー・サービスおよびパートナー；スタンプはディレクトリから'client_id'で取得されます。
デバイス/コンテキスト：IP/ASN、地理、時間帯-ABACソリューションにログインします（例えば、作業時間外の書き込みを禁止します）。

6）オブジェクトレベル認証（BOLA-first）

各操作は「主体は所有者/この'resource_id'の権利を持っていますか？」に応答する必要があります。

所有権チェック：'リソース。owner_id==subject。ロールを持つ'org'のIDまたはメンバーシップ。
フィルタサンプル：常に'WHEREリソースをオーバーレイします。tenant_id=：テナントAND……'（行レベルのセキュリティ）。
参照操作（path/bodyのID）の場合、ビジネスロジックに正規化して検証します。

7） RBACの設計： 役割、アクセス権、セット

パーミッション-atomic rights： 'wallet。'、'walletを読んでください。'、'支払いを書く。払い戻し'。

ロール-名前付きパーミッションセット： 'admin'、 'support。'、'cashier'、'詐欺を読んでください。アナリストだよ'.

スコープ-顧客の外部契約（スコープ→アクセス許可マッピング）

• ベースロール+パーミッションパック、
• ABACの制限（国/地域/テナント）、
• 「ジャスト・イン・タイム・アクセス」

8） ABAC/コンテキスト制約

地理/管轄：禁止されている国（制裁/規制）からの書き込みを禁止します。

時間/リスク： 'risk_score<しきい値'

ACC/limits： 'kyc_level>=2'ピン>X；トランザクション間の「冷却」の制御。
「信頼できるデバイス」：危険なルートのパートナーにはmTLSが必要です。

9） ReBACと権利のグラフ

複雑なビジネス構造（グループ、チーム、ブランド、支店）に役立ちます。

関係：'member'、 'admin'、 'owner'、 'viewer'。
派生権：リソースの'viewer'は'org'に属するプロジェクトの'member'から継承されます。
グラフストレージ：関係行列を持つデータベース、専門的なサービス（Zanzibarアプローチの精神で）。キャッシュ'check （subject、 relation、 object）'応答。

10）ソリューションキャッシュとパフォーマンス

PEPレベルのPDPキャッシュ（例えば、ゲートウェイで）キー：'sub'テナント'リソース'アクション'policy_version'。
TTLショート（秒-分）+イベントによる障害：役割/関係/テナントの変更。
リストのバッチチェック（bulk authz）： PDP料金を削減します。
遅延の解決を測定して下さい；degradation中-読み取り専用のgraceful-degradation（決して書き込み/金銭的）。

11）ポリシーの例

11.1 JWTスタンプ→ラフPEP（擬似ゲートウェイ）

yaml
- match: { prefix: "/api/v1/wallets" }
authz:
require:
- claim: "aud"
equals: "wallet-service"
- claim: "scope"
includes_any: ["wallet. read", "wallet. write"]
context:
tenant_from: "claim:tenant"

11.2 OPA/レゴ （ABAC+BOLA）

rego package authz

default allow = false

allow {
input. action == "wallet. read"
input. subject. tenant == input. resource. tenant some role role:= input. subject. roles[_]
role == "support. read"
}

allow {
input. action == "payment. refund"
input. subject. tenant == input. resource. tenant input. subject. kyc_level >= 2 input. subject. risk_tier <= 2 input. subject. id == input. resource. owner_id # BOLA
}

11.3管轄権の制限（deny-listポリシー）

rego deny[msg] {
input. action == "withdraw. create"
input. context. country in {"IR","KP","SY"}
msg:= "Jurisdiction not allowed"
}

11.4 ReBACポリシー（擬似）

allow(subject, "wallet. write", wallet) --
related(subject, "member", wallet. project) ∧ related(subject, "admin", wallet. org)   ∧ wallet. tenant == subject. tenant.

12）ポリシーとバージョン管理

危険な変更のためのポリシーのバージョン管理（'policy_version'）とカナリア。
「Dry-run」 （dry-run/shadow decision）-影響なしでログ「allow/deny」。
ポリシーと移行ディレクトリ：Who Changed When and Why；インシデントへのマッピング。
否定的なシナリオ（禁止されたケース）のテスト-CIで必要。

13）可視性と監査

意思決定ログ：'trace_id'、 'subject'、 'tenant'、 'action'、 'resource_id'、 'result'、 'policy_version'、失敗理由。
メトリクス：'authz_decision_latency'、 'authz_denied_total {action}'、 BOLA試行の共有、キャッシュのヒットレート。
ダッシュボード：アクション/テナントによるトップの失敗、ポリシーリリース後のトレンド。

14）安全性と持続可能性

Deny-by-default： no explicit permission=deny。
フェイルクローズ：PDPが利用できない場合、クリティカルな書き込み→禁止（または厳密に検証されたロールの「最小セット」に劣化）。
重要な不変量（例えば、'tenant'/'owner'）に対するサービス内のローカルの「ガードチェック」。
JWTにおけるホールマークの最小化;セキュアチャネル経由でPIP経由で機密属性をロードします。

15） iGaming/Financeの詳細

役割： 'cashier'、 'kyc。エージェント'、'aml。警官、詐欺だ。アナリスト'、'vip。マネージャー'、'リスク。管理者よ'.

制限：支払い取引は'kyc_level'、責任ある支払いの制限、AMLステータス/制裁に依存します。
ロックレジスタ：'org/brand/device/payment_instrument'-書き込み時のABACフィルタ。
KYC/AML/ピンアクションの監査ログは変更されません。規制の期限に従って貯蔵。
パートナーAPI： mTLS+コントラクトの「スコープ」、周囲のgeo/ASNフィルタ。

16）テストおよび検証

Negative-matrix：明示的な「禁止された」ケースをリストし、テストで修正します。
Fuzz authorization： 'tenant_id'、 'owner_id'の置換、ページング/ソート時のフィルタのバイパス。
PDPロードテスト：p95/p99でキャッシュのレイテンシと動作を確認します。
ポリシーリリース：dry-run+canary+deny/allowが期待される自動テスト。
インシデント：正確なバージョンのポリシーを使用して、スタンドでリクエストをリプレイします。

17） Antipatterns

オブジェクトチェック（BOLA）のない'scope'のみに依存します。
一元化されたモデルを使用せずに、各ハンドラのビジネスロジックと権利チェックを混在させます。
UIと信頼クライアントソリューションのハードコードの役割。
データベースへのリクエストに'tenant'/'owner'フィルタがない（リーク読み取り）。
ロール/リレーションシップを変更する場合、キャッシュソリューションの障害はありません。
リコール/回転のない長寿命のJWT。

18） Prod Readinessチェックリスト

• リソース/アクティビティ、階層、マルチテナンシーが定義されています。
• 基本的なRBAC行列+ABACリミッター、必要に応じて-ReBAC。
• PDP/PEPは設計されています；ローカルソリューションキャッシュとその障害があります。
• ポリシーはバージョン管理されており、CIにおけるシナリオテストは否定的である。
• BOLAは、特定の'resource_id'への書き込み/読み込みごとにチェックします。
• 最小限の切手でJWT、短い'経験'；'jti'の監査/リコール。
• deny/latencyによるメトリクス/意思決定ログ、ダッシュボード、アラート。
• クリティカルな書き込みのためにフェイルクローズ。フォールバックモードはドキュメント化されています。
• 顧客ドキュメント：'scopes'、エラーコード（401/403/404/409）、例。

19） TL；DR（ドクター）

BOLA-first authorizationを構築する：中央のPDP+ソリューションキャッシュ、ベースとしてのRBAC、コンテキスト用のABAC、リレーションシップ用のReBAC。すべてのリクエストは'tenant'と特定の'resource_id'のコンテキストにあります。deny-by-default、短いJWT、データベース内のオブジェクトフィルタ。バージョンとテストポリシー、レイテンシ/拒否の測定、リプレイインシデント。iGamingの場合-個々の役割（KYC/AML/キャッシュレジスタ）、 ハードABACリミッター、および変更のない監査。