ロールエンジン

1）承認モデル

RBAC （Role-Based Access Control）：サブジェクトは役割を受け取り、役割は権限に関連付けられます。管理するだけで、典型的な業務に適しています。
ABAC（属性ベースのアクセス制御）-ソリューションは、件名、リソース、アクション、環境（時間、IP、地域、リスク）の属性に依存します。複雑なルールに柔軟かつ拡張可能。
RBAC+ABACハイブリッド：ロールは「基本的な」能力を与え、属性はそれを狭めます（条件）。
（オプション）ReBAC/Relationship-based：関係グラフ（所有者、チームメンバー、委任者）、ドキュメントや組織に役立ちます。

2）アーキテクチャ： PDP/PEPとフロー

PEP （Policy Enforcement Point）：ソリューションが適用される場所（APIゲートウェイ、バックエンドメソッド、SQLレイヤ、UI）。
PDP （Policy Decision Point）：ポリシーと属性によって「ALLOW/DENY」を計算するサービス/ライブラリ。
PIP （Policy Information Point）：属性ソース（IdP/プロファイル、リソースメタデータ、リスクレート、地理）。
PAP （Policy Administration Point）-管理インターフェイス/ポリシーリポジトリ（バージョン、ドラフト、パブリケーション）。

フロー：PEP→リクエストはコンテキストを形成します→PDPは（PIPを介して）欠落している属性を引き上げます→決定→PEPが適用される（有効/無効/カットオフフィールド）→監査を計算します。

3）データモデル

• 'tenant_id'、 'roles'、 'departments'、 'risk_level'、 'mfa_verified'、 'scopes'、 'claims'。
• 'resource'型と属性：'type'、 'owner_id'、 'tenant_id'、 'classification' （public/confidential）、 'region'、 'tags'。
• 'action'： 'read'、 'write'、 'delete'、 'export'、 'approve'、 'impersonate'。п.
• 'environment'： 'time'、 'ip'、 'device'、 'geo'、 'auth_strength'、 'business_context' （тариф）。

• 'roles （id、 tenant_id、 name、 inherits［］）'-階層とパターンをサポートします。
• 'permissions （id、 resource_type、 action、 constraint？）'。
• 'role_permissions （role_id、 permission_id）'。
• 'assignments （subject_id、 role_id、 scope）'-scope： global/by project/by object。

• 'policy （id、 effect=allow' deny、 target： {subject、 resource、 action}、 condition： expr、 priority、 version、 status）'。

4）意思決定の原則

Deny-overrides：明示的な禁止は権限を優先します。
Lost Privilege （PoLP）：必要最小限のアクセスを発行し、条件を拡張します。
職務の分離（SoD）：役割/行動の組み合わせの禁止（例えば、「作成された支払い」≠「逮捕された」）。
Context-aware：より高いリスク（MFA、疑わしいIP）で要件を強化します。
決定主義：同じコンテキスト→同じ応答；ポリシーのバージョンをログに記録します。

5）実装パターン

5.1 ハイブリッドRBAC→ABAC（コンディショニング）

yaml
Declarative Policy Example
- id: doc_read_own effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","owner"] }
condition: resource. owner_id == subject. id

- id: doc_read_team effect: allow target: { action: read, resource. type: document, subject. roles: ["editor","viewer"] }
condition: subject. team_id in resource. shared_team_ids

- id: doc_read_confidential_external effect: deny target: { action: read, resource. type: document }
condition: resource. classification == "confidential" and subject. tenant_id!= resource. tenant_id priority: 100 # deny high priority

5.2行/フィールドレベルのセキュリティ

データベースレベル：RLSポリシー（'tenant_id'、 'owner_id'）。
APIレベルで：'allow： read_sensitive_fields'がない場合、コレクションとマスクフィールドをフィルターします。

5.3ステップアップソリューション

allow if action == "export" and subject. mfa_verified == true else deny

5.4一時的な許容

TTLの付与：'割り当て。expires_at'、アクセス「windows」（リソース領域の作業時間中）。

6）パフォーマンスとキャッシュ

短いTTLでキー'（subject_hash、 resource_key、アクション、policy_version）'による意思決定キャッシュ。
サブジェクト属性のエッジキャッシュ（トークン内のクレーム）+lazy-fetchリソース属性。
Incremental Invalidation：イベントによる障害（ロールの変更、ポリシーの変更、リソースの「機密」への転送）。
バッチチェック：リストの場合-PDPラインをラインで引かないように「フィルタ」（policy-predict pushdown）で評価します。

7）マルチテナント

各テーブル-'tenant_id'；デフォルトポリシーは、リース内のアクセスを制限します。
リース管理者は、リースの役割/権利のみを管理します。
クロスリースアクセス-明示的な招待/共有と明示的な拒否オーバーライドを通じてのみ。

8）ポリシー管理とライフサイクル

バージョン管理：'ポリシー。PDPレスポンスのバージョン'は、監査に保存します。
環境：draft→canary（トラフィック/シャドウモードの一部）→prod。
テストマトリックス：キーの役割/属性（契約テスト）による真理テーブル。
変更管理：セキュリティ/コンプライアンスレビューでポリシーの要求をマージします。

9）監査および観察可能性

Журнал： 'decision_id'、 'subject'、 'action'、 'resource_ref'、 'result'、 'matched_policies'、 'policy_version'、 'attributes_digest'。
指標：QPS PDP、 p95レイテンシ、ヒットレートキャッシュ、シェア拒否、ステップアップレート、SoDインシデント。
トレース：PDPコールあたりのスパン；APIリクエストとの相関。
リプレイ：ポリシーの新しいバージョンで歴史的な決定を「再生」する機能（安全性チェック）。

10）認証とトークンとの統合

アイデンティティ-IdP （OIDC/SAML）から。トークンには、'sub'、 'tenant'、 'roles'、 'auth_time'、 'amr'、 'scopes'という最低限の属性があります。
ABACの場合、トークンを膨らませないように、サーバー側（PIP）から「重い」兆候を引き上げます。
署名されたリソーストークン（機能/招待状）-厳密に制限された委任のため。

11） PDP擬似コード（簡略化）

python def decide(subject, resource, action, env, policies):
matched = []
effect = "deny"
Explicit DENYs with priority for p in sorted (policies, key = lambda x: x.priority, reverse = True):
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
if p. effect == "deny":
return Decision("deny", matched, p. version)
Looking for ALLOW for p in policies:
if target_matches(p. target, subject, resource, action):
if eval_condition(p. condition, subject, resource, env):
matched. append(p. id)
effect = "allow"
break return Decision(effect, matched, max_version(matched, policies))

12）アンチパターン

「役割=ページ」（ドメインモデルのない何百もの小さな役割）。
バージョン/監査のないコードにのみポリシーを保存します。
deny-overrideとSoDの不足→詐欺リスクの増加。
ハードは、（属性/関係の代わりに）ルールに'user_id'をリストします。
UIフィルタのみのデータ層フィルタリング（RLS）はありません。
イベントやキャッシュ障害のない手動スクリプトによるロールの同期。

13）ケースとレシピ

13.1フィールドレベルのマスキング：

allow read invoice when subject. roles includes "support"
mask fields ["card_last4", "billing_email"] unless subject. role == "finance"

13.2 MFAのみでデータをエクスポート：

allow export if subject. mfa_verified and env. ip in cidr("203. 0. 113. 0/24")

13.3 SoD：

deny approve_payment if subject. performed_actions includes ("create_payment" within last 24h)

13.4委任（制限されたトークン）：

機能トークンには'resource_id'、 'actions=［」read」］、' expires_at'、'aud'が含まれます。PEPは署名と締め切りを確認します。

14）テスト

ポリシーのユニットテスト：主要な組み合わせによる真実テーブル。
プロパティベース：「穴」を見つけるためのランダム属性の生成。
ゴールデンテスト：重要なエンドポイントのソリューションのセットを修正します。
Canary/Shadow：古いバージョンと新しいバージョンのポリシーの並列評価と矛盾のログ。

15）「アーキテクチャとプロトコル」セクションの関連機能

認証と認証（OIDC/OAuth2）

同意の管理

トークン化とキー管理

観測可能性： ログ、メトリック、トレース

ジオルーティングとローカリゼーション

At Rest/In Transit暗号化

16）建築家チェックリスト

1.サブジェクトの役割とその階層は定義されていますか？
2.属性にroles+conditionsというハイブリッドモデルはありますか？
3.deny-overrides、 SoD、ステップアップでPDPを実装しましたか？
4.PEPはどこですか？（ゲートウェイ、バックエンド、データベース、UI）-それはどこでも均一ですか？
5.ソリューションキャッシュとイベント障害は設定されていますか？
6.ポリシーはバージョン管理され、テストされ、プロセスによってロールアウトされますか？
7.監査の意思決定、指標、トレースは有効ですか？
8.マルチリースとRLS/フィールドマスキングをサポートしていますか？
9.インシデントと政策回帰に関するランブックを入手しましたか？

お知らせいたします

RBACは制御性を提供し、ABACはコンテキストと精度を提供します。役割を属性条件と組み合わせることで、PDP/PEPの共有、キャッシュの実装、監査、ポリシーのテストを行うことで、製品および規制要件に対して予測可能、検証可能、拡張可能なプラットフォーム機能として承認を構築できます。