アプリケーション認可の置き場所を整理する

Jun 21, 2026

概要

アプリケーション開発における認可について整理した文章です
PDP / PEP / PIP、RBAC / ABAC、入力検証 / 認可 / ドメインルールの境界を整理し、認可ロジックをどこに置くかの判断材料をまとめます

結論

単一アプリケーションで完結し、認可ルールの変更主体も開発チームに限られるなら、PDP をアプリケーション内部に置く構成が扱いやすい
複数チームや複数システムで同じ認可ルールを共有したいなら、外部の認可サービスとして分離する選択肢が有力になる
1 つの業務ルールに見えても、入力検証、認可、ドメインルールを分けて考えると実装責務が整理しやすくなる

背景

認可を学習するきっかけになったのは、OWASP Top 10:2025 で Broken Access Control が主要なリスクとして挙げられていたことです。認可は、認証と同様にアプリケーションのセキュリティを守る重要な要素ですが、認証ほど注目されていないと感じています。

この記事では、認可モデルやアーキテクチャの選択肢を整理し、アプリケーション認可の置き場所を考えるための土台をまとめます。

PDP / PEP / PIP

この記事で用語定義と仕様引用は折りたたんでおきます。

PDP / PEP / PIP の定義と仕様引用を見る

用語

PDP

Policy Decision Point の略。
ポリシーに基づいてアクセス要求を評価し、認可（許可、拒否、判断不能、不適合）を判定するシステム。

The system entity that evaluates applicable policy and renders an authorization decision.

訳：適用されるポリシーを評価し、認可決定を行うシステムエンティティ。

引用：eXtensible Access Control Markup Language (XACML) Version 3.0

This component is responsible for applying policies or rules and returning a decision on whether a particular access is permitted

訳：このコンポーネントは、ポリシーやルールを適用し、特定のアクセスが許可されるかどうかの判定結果を返す役割を担っています

引用：Implementing a PDP - AWS Documentation

PEP

Policy Enforcement Point の略。
PDP に対してリクエストを送り、PDP から返された結果に基づいてリクエストを処理（リソースへのアクセスを許可または拒否）するシステム

The system entity that performs access control, by making decision requests and enforcing authorization decisions.

訳：アクセス制御を実行し、決定要求を行い、承認決定を適用するシステムエンティティ。

引用：eXtensible Access Control Markup Language (XACML) Version 3.0

A policy enforcement point (PEP) is responsible for receiving authorization requests that are sent to the policy decision point (PDP) for evaluation.

訳：ポリシー適用ポイント（PEP）は、評価のためにポリシー決定ポイント（PDP）に送信される承認要求を受け取る役割を担っています。

引用：Implementing a PEP - AWS Documentation

PIP

Policy Information Point の略。
評価に必要な属性情報（ユーザーの役割やリソースの状態など）をPDPに提供するシステム。

　The system entity that acts as a source of attribute values

訳：属性値の供給元として機能するシステムエンティティ

引用：eXtensible Access Control Markup Language (XACML) Version 3.0

PEP / PDP / PIP は実行時にどう連携するか

XACML では、アプリケーションが受け取ったアクセス要求をその場で直接判定するのではなく、役割ごとに分けたコンポーネントが連携して認可を進めます。

PEP はアクセス要求の受付と判定結果の反映を担当し、PDP はポリシーに基づいて許可するか拒否するかを決めます。判定に必要な属性が足りない場合は、PDP が PIP から追加情報を受け取り、その内容も含めて最終的な判断を返します。

以下の図は XACML の認可フローをシーケンス図で表したもので、用語も XACML のものを使っていますが、実際のアプリケーションでは HTTP API やライブラリ越しのやり取りになることが多いと思います。あくまで役割分担のイメージとして捉えてください。

参考

認可モデル

この記事では、代表的な認可モデルである RBAC、ABAC の特徴を整理します。

定義・引用・比較は、後半の判断材料として参照できるよう折りたたんでおきます。

RBAC / ABAC の定義、仕様引用、比較を見る

RBAC

ユーザーにロールを割り当て、そのロールを通じて権限を与える仕組みです

The basic concept of RBAC is that users are assigned to roles, permissions are assigned to roles and users acquire permissions by being members of roles

訳：RBAC（ロールベースアクセス制御）の基本概念は、ユーザーにロール（役割）を割り当て、そのロールに権限を割り当て、ユーザーはロールのメンバーになることで権限を取得する

引用：The NIST Model for Role-Based Access Control: Toward A Unified Standard

ABAC

「ユーザーの属性（例：部署、役職、勤務年数など）やリソースの属性（例：機密性、所有者など）、環境条件（例：現在の時刻、曜日、アクセス元の物理的場所など）に基づいてアクセスを制御する」モデルです。

ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes.

主体（ユーザーやシステムなど）、オブジェクト（データやリソースなど）、要求された操作、そして場合によっては環境条件に関連付けられた「属性」を、特定の属性の組み合わせに対して許容される操作を記述したポリシー、ルール、または関係性と照らし合わせて評価することによって決定される、論理的なアクセス制御手法

引用： Guide to Attribute Based Access Control (ABAC) Definition and Considerations

NIST.SP.800-162 で定義されている認可情報は次の4つの要素から構成されます。

要素	説明
主体の属性 (Assigned attributes of the subject)	アクセス要求を行う主体（人間のユーザーや非人間実体）に割り当てられた特徴や情報（例：役職、所属組織、セキュリティクリアランスなど）
対象の属性 (Assigned attributes of the object)	アクセス管理の対象となるシステムリソース（ファイル、デバイス、データなど）に割り当てられた特徴や情報（例：ファイルの所有者、データの機密区分など）
環境条件 (Environment conditions)	アクセス要求が発生した際の動的な状況やコンテキスト。主体や対象からは独立した、検出可能な環境特性（例：現在の時刻、曜日、アクセス元の物理的場所、現在の脅威レベルなど）
ポリシー (A set of policies)	上記の「主体の属性」「対象の属性」「環境条件」の条件をどのように組み合わせて評価し、要求された操作を許可または拒否するかを記述した一連のルール（規則）や関係性

※ 認可判断にはさらに Requested Operation が含まれます。

Attribute Based Access Control (ABAC): An access control method where subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.

訳：属性ベースアクセス制御（ABAC）：主体からのオブジェクトに対する操作実行要求を、主体に割り当てられた属性、オブジェクトに割り当てられた属性、環境条件、およびそれらの属性や条件に基づいて許容される操作を記述した一連のポリシー（規則）を評価することによって、許可または拒否するアクセス制御手法

引用：Guide to Attribute Based Access Control (ABAC) Definition and Considerations - NIST

XACML では、ABACの属性を次のように定義しています。

要素	説明
サブジェクト (Subject)	認可決定が下される対象となるエンティティ（主体）。仕様書内では、役職（role）、グループ（group）、認証時のIPアドレス（authn-locality:ip-address）などの属性が定義されている。
リソース (Resource)	アクセスを制限（認可）する対象となるデータ、サービス、またはシステム要素。仕様書内では、リソースID（resource-id）やネームスペース（target-namespace）などの属性が定義されている。
アクション (Action)	対象リソースに対して実行される操作。仕様書内では、アクションID（action-id）などの属性が定義されている。
環境 (Environment)	サブジェクト、リソース、アクションには属さない、認可決定に関連する一連の属性。仕様書内では、現在の日時（current-dateTime）などの属性が定義されている。

Characteristic of a subject, resource, action or environment that may be referenced in a predicate or target

訳：主体、リソース、アクション、または環境の特性であり、述語やターゲットで参照される可能性がある

引用：eXtensible Access Control Markup Language (XACML) Version 3.0

ABAC を実装するには、まず対象と保護要件を十分に理解する必要があります。

Implementing ABAC requires, first and foremost, a thorough understanding of the objects and their protection requirements.

訳：ABAC を実装するには、何よりもまず、オブジェクトとその保護要件を徹底的に理解する必要があります。

Without that understanding, the cost to develop and implement the technology required for enterprise ABAC increases dramatically.

訳：その理解がなければ、エンタープライズ ABAC に必要な技術を開発・実装するためのコストが劇的に増加します。

It is recommended that enterprise ABAC implementations be initially applied to objects that are well defined, controlled, and documented.

訳：エンタープライズ ABAC の実装は、まず明確に定義され、制御され、文書化されているオブジェクトに対して適用することをおすすめします。

参考

RBAC:

ABAC:

アプリケーション開発ではどのモデルを選ぶべきか

要件変化が多いアプリケーションでは、RBAC よりも ABAC を選択したほうが扱いやすい場面が多いと考えています。
理由は、ABAC の方がきめ細かい権限設定が可能で、最小権限の原則を実現しやすく、ビジネス要件の変化に柔軟に対応しやすいからです。

一方で、個人利用のアプリケーションや、組織内の小規模なプロジェクト、toC 向けのアプリなど、単純なアクセス制御要件を持つケースでは RBAC が適していることもあります。

ちなみに Authorization Cheat Sheet では、RBAC よりも ABAC や ReBAC が推奨されています。

it is easier to grant users additional permissions rather than to take away some they previously enjoyed. Careful planning and implementation of Least Privileges early in the SDLC can help reduce the risk of needing to revoke permissions that are later deemed overly broad.

訳：ユーザーには、以前付与されていた権限を取り消すよりも、追加の権限を付与する方が容易です。ソフトウェア開発ライフサイクル（SDLC）の初期段階で最小権限の原則を慎重に計画・実装することで、後になって権限が広すぎると判断される事態を防ぐことができます。

Although RBAC has a long history and remains popular among software developers today, ABAC and ReBAC should typically be preferred for application development.

訳：RBACには長い歴史があり、現在もソフトウェア開発者の間で広く利用されていますが、アプリケーション開発においては、通常、ABACやReBACを優先すべきです。

引用：https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html

ルールを入力検証 / 認可 / ドメインルールに分けてみる

ABAC を学び始めると、入力検証、認可、ドメインルールの境界が急に曖昧になります。
どれも「不適切な入力を拒否する」という見た目は似ていますが、目的が違うため整理します。

入力検証は、リクエストの形式や値が処理可能かを守る
認可は、その操作を誰に許可するかを守る
ドメインルールは、そのビジネス領域として成立する条件や制約を守る

実際の業務ルールは、1 つの文の中に「利用者の権限」「対象の属性」「業務上の制約」が同時に含まれやすく、実装時に分類しづらくなりやすいと思っています。

validation-auth-domain

参考：

Input Validation Cheat Sheet - OWASP Cheat Sheet

分類の観点

まずは、ルールを 1 文のまま扱わず、次の 3 つの問いに分解して考えるのがよさそうです。

リクエストの形として妥当か
この利用者にその操作を許可してよいか
業務上、その操作は成立するか

この 3 つに分けると、判断基準を次のように置けます。

観点	主に見るもの	例
入力検証	型、必須項目、値の範囲、構文	金額が数値か、コメントが 500 文字以内か
認可	利用者のロール、所属、対象との関係	申請者本人だけが下書きを編集できる
ドメインルール	業務上の状態、状態遷移、不変条件	承認済みの申請は取り下げできない

迷いやすいのは、1 つの条件が複数の観点から意味を持つときです。
たとえば「承認済みは取り下げできない」は、まずドメインルールとして扱うのが自然です。これは、誰が操作するかに関係なく守りたい業務制約だからです。

一方で、認可の段階でも同じ条件を参照して早めに拒否する設計はありえます。
ただし、その場合でも実装はドメインルール側に置き、認可側の重複は「不要な操作を早めに落とすための補助」または「多層防御」と考えても良いと思います。

具体例

実務では、要件は次のように自然言語で書かれ、1 文の中に認可条件とドメインルールが混ざることがあります。

申請者本人だけが、自分の下書き申請を更新できる
部門長は、自部署の未承認申請だけ承認できる

このような文をそのまま実装するのではなく、まずは判定条件に分解してから分類すると整理しやすくなります。

たとえば 申請者本人だけが、自分の下書き申請を更新できる という文には、次の条件が含まれます。

条件	分類	理由
利用者がその申請の申請者本人である	認可条件	操作者と対象リソースの関係に基づいて、更新操作を許可できるかを見ている
対象申請が下書き状態である	ドメインルール	業務上、更新操作が成立する状態かどうかを見ている

同じように、部門長は、自部署の未承認申請だけ承認できる という文も分解できます。

条件	分類	理由
利用者が部門長である	認可条件	操作者の属性に基づいて、承認操作を許可できるかを見ている
対象申請が利用者の部署に属している	認可条件	操作者と対象リソースの関係に基づいて、承認操作を許可できるかを見ている
対象申請が未承認状態である	ドメインルール	業務上、承認操作が成立する状態かどうかを見ている

境界が重なる条件はどう扱うか

ここで注意したいのは、1 つの条件が常に 1 つの分類だけに属するとは限らないことです。

たとえば 申請タイトルは文字列であり、1 文字以上 100 文字以下である という条件は、リクエストの妥当性を確認する入力検証として扱うこともできます。一方で、業務上 申請タイトルはその長さでなければ申請として成立しない のであれば、ドメインルールとして扱うこともできます。

同様に、対象申請が未承認状態である という条件も、本質的には状態遷移を制約するドメインルールですが、認可モデルとして ABAC を採用しているならば、認可の段階で参照して早めに拒否する設計はありえます。ただし、その場合でも業務的な正しさを最終的に保証する責任はドメインルール側に置くべきです。

境界が曖昧に見える場合は、UX の観点から早期拒否、セキュリティの観点から多層防御として位置づけ、複数に書く方針で問題ないと考えています。

PDP をどこに置くか

ここでは、PDP の配置と認可ルールの実装方法を分けて整理します。

PEP は基本的にアプリケーションサーバー内に実装しますが、PDP はどこに置くかの選択肢があります。

アプリケーションサーバー内に実装する
外部サービスや自前で作った認可サービスに置く

pdp

アーキテクチャと運用体制によって PDP をどこに置くべきかは変わります。

ここでは、アプリケーション内部に閉じるか、外部の認可サービスとして分離するかを考えるために、次の 4 つの観点で整理します。

1. 認可ルールの所有者

まず見るべきなのは、認可ルールを誰が責任を持って管理するかです。

1 つの開発チームがアプリケーションと認可ルールの両方を管理しており、変更やレビューもそのチーム内で完結するなら、PDP をアプリケーション内部に置く構成で十分なことが多いです。ルール変更とアプリケーション変更を同じリポジトリ、同じデプロイフローで扱えるためです。

一方で、プラットフォームチームやセキュリティチームが共通の認可基盤を持ち、複数のプロダクトチームがそれを利用する構成では、PDP を外部サービスとして分離する方が向いています。たとえば API、管理画面、BFF、バッチジョブをそれぞれ別チームが担当していて、同じ tenant / organization / resource 単位の権限を横断的にそろえたいケースです。

この場合、認可ルールを各アプリケーションに分散させるより、共通の認可サービスとして切り出した方が、責務分担やレビュー経路を整理しやすくなります。

2. 認可判定の利用範囲

次に見るべきなのは、同じ認可判定をどこから使うかです。

認可判定の呼び出し元が 1 つのアプリケーションに閉じているなら、PDP をアプリケーション内部に置いても大きな問題にはなりにくいです。モノリスや単一の BFF で、画面と API が同じアプリケーション境界の中にあるような構成です。

一方で、同じ認可判定を複数の API、管理画面、BFF、バッチジョブ、ワーカーから使いたいなら、PDP を外部に置く価値が出てきます。各コンポーネントに同じロジックを複製すると、ルールの差分や実装漏れが起きやすくなるためです。

ここでの判断軸は、チーム数ではなく「同じ認可判断を何箇所で再利用するか」です。利用箇所が増えるほど、外部化によって一貫性を保ちやすくなります。

3. 認可ルールの性質

3 つ目は、認可ルールがアプリケーション固有の業務ロジックなのか、複数システムにまたがる共通ポリシーなのかです。

たとえば「承認済みの申請は取り下げできない」のようなルールは、そのアプリケーションの業務状態に強く依存します。このようなルールは、ドメインロジックに近いため、アプリケーション内部で扱う方が自然です。

一方で、「同じ組織に所属しているユーザーだけが閲覧できる」「管理者ロールだけが設定を変更できる」「契約プランによって使える操作が変わる」のようなルールは、複数の機能やサービスで共有されやすいです。このような共通ポリシーは、外部 PDP に寄せる候補になります。

つまり、業務状態に密着した判断は内部に残し、組織・ロール・プラン・テナントなどをまたぐ共通判断は外部化を検討します。

4. 実行時制約

最後に、性能、可用性、データ取得の制約を見ます。

PDP を外部サービスにすると、認可判定のたびにネットワーク越しの呼び出しが発生します。追加のレイテンシや障害点を許容しにくい処理では、アプリケーション内部に PDP を置く方が扱いやすいです。

逆に、外部 PDP の可用性を確保でき、キャッシュやバルク判定などでレイテンシを抑えられるなら、外部化は現実的になります。

また、認可判断に必要なデータをどこから取得するかも重要です。判定に必要な属性がアプリケーションの DB に強く依存しているなら内部実装が簡単です。外部 PDP にする場合は、PIP を通じて属性を渡す、事前に同期する、判定に必要な情報だけをリクエストに含める、といった設計が必要になります。

まとめると、PDP の配置は次のように考えます。

観点	内部 PDP が向く場合	外部 PDP が向く場合
認可ルールの所有者	アプリチーム内で完結する	プラットフォーム・セキュリティチームが共通管理する
認可判定の利用範囲	1 つのアプリケーションで使う	複数の API、BFF、バッチなどから使う
認可ルールの性質	業務状態に強く依存する	組織、ロール、プラン、テナントなどの共通ポリシーである
実行時制約	低レイテンシ、DB 近接、障害点の少なさを優先する	一貫性、集中管理、横断的な監査を優先する

PEP はどこに置くか

pep

PDPはどこに置くかで考えたように、PDP はアプリケーション内部に置くことも、外部サービスとして分離することもできます。
しかし、PEP はリクエストから認可の判断を強制する役割があるため、アプリケーションサーバ内に実装することになるはずです。
そのため、今度はアプリケーションサーバー内のどこに PEP を置くかを考える必要があります。

Oso Academy では、認可を「誰が、何を、何に対して実行できるか」を判断し、その判断結果を実際の処理に反映するものとして説明しています。このうち PEP は、PDP に認可判断を問い合わせ、その結果に従って処理を進める、止める、レスポンスを変える場所です。

このブログでは、RBAC ではなく ABAC を前提に考えます。 ABAC では、ロールだけでなく、ユーザー属性、リソース属性、テナント、部署、時刻、変更対象フィールドなどの文脈を使って判断します。そのため、HTTP request だけを見て判断できる場所では情報が足りず、対象リソースやユースケースの文脈が揃う場所で認可の強制をする必要があります。

DDD のレイヤードアーキテクチャに当てはめると、PEP は主にプレゼンテーションレイヤーとアプリケーションレイヤーに置くのがよいと考えています。ただし、両者の役割は同じではありません。

レイヤー	PEP としての位置づけ	主な判定
プレゼンテーション	補助 PEP	未認証、ルートレベル（HTTP メソッドとパス単位）、Access Token の scope、リソース詳細を読まずに拒否できる操作
アプリケーション	主 PEP	ユースケース、リソースレベル、フィールドレベル、業務文脈まで含めた ABAC
ドメイン	原則 PEP ではない	業務不変条件
インフラ	クエリレベルの補助	一覧取得、検索、DB filter

プレゼンテーションレイヤーでは、粗い判定に留めます。たとえば、未認証ユーザーの拒否、管理画面へのルートレベルのアクセス制御、Access Token の scope 確認などです。ここで対象リソースの状態や業務文脈まで取得しようとすると、コントローラーやアプリケーションサービスで必要になる処理と重複しやすくなります。そのためプレゼンテーションレイヤーの PEP は、早期拒否や多層防御のための補助的なものとして扱います。

アプリケーションレイヤーは、主 PEP を置く場所です。アプリケーションサービスはユースケースを実行する場所であり、actor、action、resource、context が揃います。たとえば「レポートを更新できるか」のような粗い問いではなく、「この経費レポートを承認できるか」や「契約金額を変更できるか」のように、実行しようとしているユースケースに近い粒度で PDP に問い合わせます。

authorize(actor, action, resource, context)

認可条件をアプリケーションコードに直接書くと、PEP と PDP が混ざります。アプリケーションレイヤーの責務は、認可ルールそのものを持つことではなく、適切なタイミングで認可判断を要求し、その結果を処理に反映することです。

ドメインレイヤーには原則として PEP を置きません。ドメインレイヤーは「業務として成立するか」を表現する場所であり、「この actor が実行してよいか」を外部の認可基盤に問い合わせる場所ではありません。ただし、「申請者本人は自分の申請を承認できない」のように、業務概念として actor が登場する不変条件はドメインルールとして表現してよいと思います。その場合でも、PDP への問い合わせや 403 / 404 のレスポンス判断はドメインレイヤーに入れません。

インフラレイヤーは、一覧取得や検索のようなクエリで補助的に使います。単体リソースの操作はアプリケーションレイヤーで yes / no を判定できますが、「このユーザーが閲覧できる申請一覧を返す」のような処理では、1件ずつ認可判定すると効率が悪くなります。この場合は、アプリケーションレイヤーから渡された認可条件を repository や query service が SQL / ORM の filter に変換します。認可判断をインフラレイヤーに分散させるのではなく、クエリ条件として扱うのがよいと思います。

UI については、PEP ではなく認可結果を使った表示制御として考えます。ボタンを非表示にする、編集欄を disabled にする、といった制御は UX には有効ですが、ブラウザや API クライアントから迂回できるため、信頼できる enforcement にはなりません。最終的な拒否は必ずバックエンドのプレゼンテーションレイヤーまたはアプリケーションレイヤーで行います。

まとめると、PEP は1箇所に閉じ込めるものではありませんが、最終的な PEP はアプリケーションレイヤーに置きます。プレゼンテーションレイヤーは早期拒否と多層防御、インフラレイヤーはクエリ、UI は表示制御として位置づけると、DDD の責務分離と ABAC の文脈取得を両立しやすくなります。

PEP の参考

認可ライブラリ / 認可サービスを使うか自前で実装するか

auth-library

ここでの比較は、認可ルールをどこまでアプリケーションコードから切り離すか、という整理です。PDP の配置とは別の軸として考えます。

認可ライブラリ / 認可サービス: OPA、Casbin、Keycloak Authorization Services などを使い、認可ルールをアプリケーションコードの外側にも表現できるようにする
自前で実装する: アプリケーション内部に直接実装する

この判断では、単に 複雑そうだからライブラリを使う、モノリスだから自前でよい と決めるだけでは足りないと感じています。
実際には、認可がどこまで業務データとして扱われるのか、誰が変更するのか、一覧取得まで含めて何を保証したいのかを見る必要があると考えています。

自分の中では、次の 5 つの観点があると考えています。

1. 権限が業務データとして扱われるか

BtoB アプリケーションでは、権限設定そのものがプロダクト機能になることがあります。
たとえばドキュメント管理システムなら、利用者がページごとに閲覧権限や編集権限を設定したいかもしれません。

この場合、認可ルールは開発者がコードで固定するものではなく、業務データとして保存、変更、監査できる必要があります。
Casbin の adapter のように、policy を database に保存できる仕組みはこの要求と相性が良いと考えています。

逆に、権限が admin、manager、member のように固定され、変更もリリース時のコード修正で足りるなら、自前実装でも十分だと思います。

2. 候補のライブラリや外部サービスが、必要な認可要件を満たせるか

認可をライブラリや外部サービスに切り出すときは、判定ロジックを外に出せるか だけでなく、アプリケーションで必要な認可要件をその方式で本当に満たせるかを見る必要があります。

たとえば、canRead(document) のような個別判定だけで足りるなら、ライブラリの API 呼び出しやミドルウェアで十分に組み込めることも多いです。
一方で、このユーザーが閲覧できる文書だけを一覧表示したい のように、認可条件を検索条件へ落とし込む必要があるなら、単純な個別判定だけでは足りません。

その場合は、認可モデルを SQL の WHERE 条件、RLS、キャッシュ、インデックス設計とどう整合させるかまで含めて考える必要があります。

つまり、この観点で見たいのは ライブラリを使うかどうか そのものではなく、候補のライブラリや外部サービスが、自分たちの認可要件を無理なく実現できるかどうかです。

3. ロールベースで足りるか、リレーションシップまで必要か

admin、editor、viewer のようなロールベースで足りるなら、Casbin のような仕組みでも整理しやすいですが、自前で実装しても十分なことが多いと思います。一方で、次のような要求・要件が入ると、リレーションシップを中心に考えたほうが自然になります。

親フォルダに閲覧権限があると子ページも見られる
owner が editor を委譲できる
組織外の相手に個別共有できる
プロジェクト、フォルダ、文書の関係で権限が伝播する

こうした要求が強いなら、自前の if 文や単純なロール判定よりも、policy engine や ReBAC 系の仕組みを考えた方がよく、OpenFGA のようなモデルも選択肢に入ると思います。

4. 権限変更の主体が開発チーム以外にも広がるか

認可ルールを変更するのが開発チームだけなら、コードとして管理する方法でも運用できます。
しかし、アプリケーションによっては、顧客管理者、情シス、CS、監査担当が権限設定に関わることがありえます。

この場合は、コードレビューだけでは運用できません。
変更履歴、承認フロー、管理 UI、操作ログのような仕組みが必要になるため、認可ルールをコードから分離する必要性があります。

5. 「なぜ許可 / 拒否されたか」の説明可能性がどれだけ必要か

アプリケーションによっては、単に許可 / 拒否できれば終わりではなく、理由まで説明したい場面もありえます。たとえば、なぜこのユーザーはこの文書を見られないのか、どの権限設定が根拠なのか を画面や監査ログで示したい場面です。

自前実装でも不可能ではありませんが、判定根拠をデータやポリシーとして残せる形のほうが扱いやすいと思います。
deny 理由、継承元、付与元まで追いたいなら、最初から説明可能性を意識したモデルに寄せたほうが後で困りにくいです。

自前実装でも最低限揃えたいこと

少なくとも次の要素を考慮して、認可ロジックの設計をするのがよいと思います。

判定関数の置き場所。application / policy のように入口を揃える
actor、resource、action の入力形。判定に渡す値を毎回バラバラにしない
deny by default の方針。条件に一致しないときは拒否を基本にする
テストの置き方。ロール、所属、状態の組み合わせを表で検証する
監査や調査のための記録。少なくとも「誰が、何に、なぜ失敗したか」を追えるようにする

さいごに

このブログでは、認可ライブラリを使うか、自前で実装するか、また PDP をアプリケーション内部に置くか外部サービスとして分離するかを整理しました。そのほかにも、サーバレスかコンテナか、コンテナの場合サイドカーを使うか、など複数の観点を整理して、最適な構成を選ぶ必要があると考えています。

これらの設計判断をドキュメントにまとめておくと、チーム内での認可ルールの実装方針や、将来的な認可基盤の拡張方針を共有しやすくなると思います。