認証用語は混乱している：それを修正しよう

認証用語は混乱している：修正しよう

Andrea Chiarelli 著

ポリシーベースのアクセス制御（PBAC）は認証モデルか？ という記事で、私はPBACがRBACやABACと同じカテゴリに属するように比較されることが多いが、実際には異なる問いに答えていると論じました。

RBACとABACは、決定が何に基づいているか、つまりロールや属性といった「どのようなデータ」を記述します。一方、PBACは、その決定が「どのように」行われるか、つまりアプリケーションに組み込まれたロジックではなく、中央集権的なポリシーエンジンを通じて行われることを記述します。一方はルールの形状に関わり、もう一方はルールがどこに存在し、誰がそれを評価するかにかかわります。

私の意見では、これらを競合する選択肢として扱うのは、レシピとキッチンを比較するようなものです。

この区別は、特定の混乱を解決しようとしましたが、より大きな混乱は未解決のままでした。PBACだけがこのように誤って分類される用語ではありません。

Mandatory Access Control（MAC）やDiscretionary Access Control（DAC）も、RBACやABACと比較されますが、それらはルールの形状ではなく、誰がルールを管理するかを記述しています。

Access Control List（ACL）やRelationship-Based Access Control（ReBAC）も、「認証モデル」という同じ文脈で登場しますが、どちらの論文を読むかによっては、一方が他方の特別なケースであるとも言えます。

認証を取り巻く用語は、アクセス制御の研究、IDベンダー、標準化団体などを通じて数十年にわたって蓄積されてきましたが、その多くは、単一の質問「これはどのモデルか？」という言葉を使いながら、異なる問いに答えています。

この記事では、モデル対アーキテクチャの区別を、完全な分類法に一般化します。「このシステムはどの認証モデルを使用していますか？」と尋ねる代わりに、あらゆる認証システムについて5つのより狭い質問をし、それぞれを独立して回答し、その後、RBAC、ABAC、MAC、PBACのような一般的なラベルが実際にどこに位置するかを見ていきます。用語が正しい軸上に配置されたときに競合しなくなるのであれば、それは軸が実際に機能している証拠です。

認証の核心的な問題

認証は一つの問いに答えます：この主体は、この対象に対してこのアクションを実行できますか？ ユーザーがファイルを読み取る、サービスがAPIを呼び出す、プロセスがデータベースに書き込む。あらゆる認証の決定は、その同じトリプル：主体、アクション、対象に還元されます。

最も単純なシステムでは、要求する側と決定する側の間に分離がないため、決定を下す必要はありません。自分の部屋の引き出しにしまってある自分の日記を想像してください。読みたいので、引き出しを開けて読みます。誰もあなたに許可を与える必要はありません。なぜなら、他に誰も関与していないからです。欲することと得することは同じ行為です。

アクセスされるものが通常複数の関係者の所有物であるため、実際のシステムがこの単純さを保つことはめったにありません。その日記を同居人がいる家に入れたり、会社のファイルキャビネットに移したりすると、状況はすぐに変わります。引き出しを開けたいと思うすべての人に許可を与えるべきではありません。そして、誰が許可を与えられ、誰が与えられないかを、ケースバイケースで決定する誰かが必要です。

リソースサーバーは、ソフトウェアに対してまさにその仕事を行います。マルチテナントSaaSアプリケーション、社内API、数十のサービスからアクセスされるクラウドストレージバケット：これらすべては、リクエストを見て、それを許可するかどうかを決定する何らかのものが必要です。その「何か」が、この記事の残りの部分で扱うものであり、RBACやPBACのような単一の単語では捉えきれないほど多くの可動部分があることがわかります。

認証リクエストの処理方法

リソースサーバーを通過する単一の認証リクエストを追跡すると、特定のテクノロジーに関係なく、一貫した一連のステージが現れます。リクエストが到着し、サーバーはユーザーとリソースに関するコンテキストを収集し、ポリシーがそのコンテキストをルールに対して評価します。評価は許可または拒否の決定を生成し、サーバーはその決定をリクエストを通過させるか拒否することによって強制します。

同じ5つのステージが、実質的にすべての認証システムに現れます：

1. 誰かがルールを定義します。 開発者がチェックをハードコーディングする。セキュリティチームがポリシーを作成する。リソースオーナーが自分のファイルに共有権限を設定する。
2. ルールは具体的な形をとります。 アプリケーションコード内の条件分岐。JSONドキュメント。XACMLポリシー。スプレッドシートの行をデータベーステーブルにエクスポートしたもの。
3. 何らかのデータが決定に必要になります。 ユーザーのロール。データベースに記載された部署。時刻。要求元のユーザーとリソースの所有者との関係。
4. 決定が計算されます。 ルールとデータが一緒に評価され、許可または拒否が生成されます。
5. 決定が強制されます。 実際に行動を起こすものが必要です。リクエストをブロックするか、リダイレクトします。

これらの5つのステージは、アクセス制御アーキテクチャでしばらく前から使われている語彙に対応します：

• Policy Administration Point (PAP)（ルールを定義する人）
• Policy Information Point (PIP)（決定にデータを提供するもの）
• Policy Decision Point (PDP)（決定が計算される場所）
• Policy Enforcement Point (PEP)（それが強制される場所）

BrossardのABACアーキテクチャの概要 は、このPAP/PIP/PDP/PEPの内訳をより詳細に説明しており、これらの用語に慣れていない場合は読む価値があります。

ここには、2022年の Mohamed、Auer、Hofer、Küng による認証およびアクセス制御研究の体系的な文献レビューから、より学術的なフレームワークを引用する価値があります。この論文は4つのレベルの梯子を描いています。認証戦略（裁量的、必須、またはハイブリッド）は、認証モデル（システムが推論する主体、対象、その他のコンポーネント）の上にあり、それは認証ポリシー（具体的なルールのインスタンス）の上にあります。並行して、アクセス制御モデル（許可/拒否を決定するロジック）は、アクセス制御メカニズム（実際の実行ソフトウェア）によって強制されます。これは、戦略、モデル、ポリシー、メカニズムが別々のレイヤーであり、それらを混同することが用語の崩壊の原因であるという同じことを厳密に述べています。

これらの5つのステージのいずれも、単独ではシステムが「RBACである」とか「PBACである」とは教えてくれません。各ステージは実際には独立した質問であり、それぞれ独自の回答セットを持っています。それが以下の分類の種となります。

一貫した分類

6つの軸が上記の5つのステージをカバーしています（認証ポリシーは認証モデルから分割されています。なぜなら、1つのモデルは複数の種類の具体的なポリシーアーティファクトによってインスタンス化できるためです）。各軸には少数の一般的な回答があり、すべての一般的な用語（ACL、RBAC、ABAC、ReBAC、MAC、DAC、PBAC）は、システム全体をラベル付けするのではなく、実際には1つの特定の軸への回答です。

6つの軸を明確に保つための有用な方法は、ソフトウェア以外のもの、つまり法律の仕組みから借用した比喩です。立法府はルールを起草し、ルールは法規として書き留められ、裁判所はそれらの法規を事件の事実と照らし合わせて検討し、警察は評決を実行します。「法制度」を「認証システム」に置き換えると、同じ6つの仕事が一つずつ現れます。

認証管理：誰がルールを設定するか？

ルールが評価される前に、誰かがそもそもそれを書く権限を持っていなければなりません。その権限は1箇所に集中させることも、多くの場所に分散させることもでき、システムのこの軸に対する回答は、ルールが実際に何を言っているかとは独立しています。認証管理は次のようになります：

• 中央集権的: セキュリティチームまたは管理者が、すべての人のためのルールを定義します。これはMAC（Mandatory Access Control）の背後にあるパターンです。アクセスはリソースオーナーではなく、中央当局によって決定されます。
• 分散的: リソースの所有者が、他の誰がそれにアクセスできるかを決定します。これはDAC（Discretionary Access Control）です。「このファイルをこれらの人々と共有する」という古典的なパターンです。
• ハイブリッド: 一部のルールは中央当局から、他のルールは個々のリソースオーナーから来て、それらが重ね合わされます。

Mohamedらの文献レビューも戦略をこのように扱っており、彼らの比較分析は示唆に富んでいます。彼らがこの軸に対してアクセス制御モデルを分類したとき、RBAC、ABAC、ReBACファミリーはすべて、DACやMACにきれいに収まるのではなく、ハイブリッドカテゴリに分類されました。これはそれ自体有用なデータポイントです。管理戦略が認証モデルとは本当に独立していることを確認します。ロールベースのシステムは中央管理されることも、オーナー管理されることも、あるいはその両方も可能であり、いずれにしてもRBACです。

法制度はまさにこの分割で成り立っています。議会、あるいは古い制度の下での王は、全人口のために法律を制定します。これは中央集権的な管理です。2人の隣人がフェンスの境界線について合意すること、あるいは家主が誰に鍵を与えるかを決定することは、分散的な管理であり、契約法や財産法が実際に機能する方法に近いものです。ほとんどの実際の法制度は、ほとんどの認証システムと同様に、両方を混合しています。

認証モデル：決定を駆動するデータ型は何か？

ルールを書く権限が確定したら、次の質問は、ルールが実際に何を推論するか、つまり決定が実行されるたびにチェックされる情報の具体的な種類です。これは、ほとんどの人が「認証モデル」と言うときに意味する軸であり、私の以前のPBACの記事が焦点を当てたものです。一般的な認証モデルをいくつか挙げます：

• IDベース（ACL）: 決定は、特定の主体が対象に添付されたリストに表示されるかどうかをチェックします。
• ロールベース（RBAC）: 決定は、主体が要求された権限を付与されたロールを持っているかどうかをチェックします。
• 属性ベース（ABAC）: 決定は、主体、アクション、対象、または環境の属性をルール（部署 = 「財務」、クリアランス ≥ 「秘密」、時刻は午前9時から午後5時の間）に対してチェックします。
• 関係ベース（ReBAC）: 決定は、主体と対象の関係をチェックします。多くの場合、グラフをたどります（このユーザーはこのドキュメントの所有者であるチームのメンバーか？）。

ここでの曖昧さについて正直であることは価値があります。どの学術的な情報源を読むかによっては、ACLとRBACはABACの特別なケースとして説明されることがあり、その場合の属性は、アイデンティティまたはロールメンバーシップです。これらの4つのカテゴリは、作業分類法にとって最も有用なカットであり、カテゴリが数学的なレベルで相互に排他的であるという主張ではありません。

法律は、ルールが実際には何についてであるかという点で、同じ種類の区別をします。憲法および行政法は通常、誰が役職によって行動できるかを定義します。「大統領のみがこの条約に署名できる」これはロールベースです。規制法は、属性に訴えることが多く、「収益が1000万ドルを超えるすべての事業は、この報告書を提出しなければならない」家族法および契約法は、配偶者、親、ビジネスパートナーといった関係に依存します。そして、特定の個人または会社を名指しした法律または命令は、ACLの法的等価物です。法律の異なる分野が同じ理由で異なる基準に訴えるのは、異なる認証システムがそうするのと同じ理由です。各基準は異なる種類の決定に適しています。

認証ポリシー：ルールはどのような形をとるか？

モデルが選択されると、それはまだ具体的なアーティファクトとしてどこかに書き留められる必要があります：

• アプリケーションコード内のハードコーディングされた条件分岐。
• 実行時にロードおよび解釈される構造化されたドキュメント（JSON、YAML）。
• XACML、Rego（Open Policy Agent）、またはCedarのような、認証専用に構築された宣言的なポリシー言語。
• データベーステーブルの行。

この軸は重要です。なぜなら、2つのシステムが同じ認証モデル（両方ともRBAC）を共有していても、ポリシーがどのように表現されるかという理由だけで、保守性、監査可能性、および誰がルールを変更できるかという点で完全に異なる場合があるからです。

法律の比喩では、これは単に法律そのものです。法規またはコードの実際のテキストであり、誰がそれを制定したか、またそれがどの法律分野に属するかとは無関係です。

認証情報：決定に関連するデータはどこから来るか？

ルールは、それが評価されるデータと同じくらいしか良くありません。そして、そのデータはすべて同じ方法で到着するわけではありません。ルールが依存するものを、システムが実際にそれをどのように入手するかから分離することは価値があります：

• 組み込み: データはアプリケーションの通常の要求フローで既に利用可能であり、追加のルックアップは不要です。
• トークンベース: データは、発行時にIDプロバイダーによって入力されたJWTまたは類似のクレデンシャル内のクレームとして到着します。
• ルックアップ: アプリケーションは、決定時にデータベース、ディレクトリ、または外部サービスにクエリを実行します。
• 環境: データは、主体または対象ではなく、要求のコンテキストを記述します。時刻、場所、デバイスの姿勢、ネットワーク。

これは、注意深い学術的な扱いでも実際の区別が曖昧になる場所です。Mohamedらのフレームワークは、環境属性を、主体や対象と共に、認証モデルのコンポーネントリストに折り込みます。「このデータは実行時に物理的にどこから来るのか」を独自のアーキテクチャ上の懸念として扱うのではなく。私は、それがPBAC記事が指摘する間違いの小さなバージョンだと思います。決定が「時刻」に依存することを知っていることはモデリングの問題ですが、要求がディレクトリサービスへのネットワークラウンドトリップを行う必要があることを知っていることはアーキテクチャの問題であり、レイテンシと障害モードに実際の影響を与えます。

法廷も同様の入力に依存します。事実と出来事。証言、文書、タイムスタンプ、過去の記録。異なる事実セットに適用される同じ法律は、異なる評決を生成します。これは、異なるトークンクレームまたは異なるデータベースルックアップに適用される同じポリシーが異なる認証決定を生成するのと同じようにです。そして、認証システムと同様に、それらの事実がどこから来るか（証言台の証人、召喚状で要求された文書、または専門家の報告書）は、法律が何を言っているかとは別の懸念事項です。

認証決定：決定はどのように、どこで計算されるか？

ルールとデータが両方利用可能になったら、実際に評価を実行するものがなければなりません。その「何か」はいくつかの異なる場所に存在でき、それがどこに存在するかは、ルール自体ではなくアーキテクチャに関する質問です：

• アプリケーションコードに組み込み: ビジネスロジックにインラインで、決定ロジックと同じコードパスがそれに対処します。
• 専用ライブラリまたはモジュール: 決定ロジックが分離されていますが、アプリケーションプロセス内で実行されます。
• 中央集権的なポリシーエンジン: コンテキストを受け取り、決定を返す別のサービス。多くの場合、多くのアプリケーションで共有されます。

PBACはここに存在します。「認証モデル」の軸ではありません。決定ポイントをポリシーエンジンに集中させることは、評価がどこで行われるかに関するアーキテクチャ上の選択であり、あらゆる認証モデルと互換性があります。PBACエンジンは、ロールベースのルール、属性ベースのルール、またはそれらの混合を評価できます。PBACがRBACやABACの同等物ではないのはまさにこのためです。それはRBACやABACが答える質問とは異なる質問に答えています。

これは法廷の比喩がぴったりくる場所です。裁判所、特に裁判官が決定エンジンです。法律と事実が入力され、評決が出力されます。そして、法制度が、根本的な法律を変えることなく、異なる種類の事件を異なる専門裁判所（交通裁判所、家庭裁判所、最高裁判所）にルーティングする習慣は、PBACが実際には何であるかの良い絵です。それは、法律自体を変更することではなく、どの裁判所が事件を聞くかの選択です。

認証強制：決定はどのように、どこで強制されるか？

決定が何かによって実行されない限り、その決定は意味がありません。そして、そのアクションは、決定が行われたのと同じ場所で行われる必要はありません。認証強制は次の場所に存在できます：

• アプリケーションコードに組み込み: 決定を行ったのと同じコードパスが、それに対処します。
• 専用ミドルウェア: フレームワークレベルのコンポーネントが、決定に基づいてリクエストをインターセプトします。
• 分散強制: ゲートウェイ、サイドカー、またはプロキシが、アプリケーション自体とは独立して、ネットワークエッジで決定を強制します。

認証決定の軸と同様に、これはモデルではなくアーキテクチャです。APIゲートウェイを通じてABAC決定を強制するシステムと、インラインミドルウェアを通じてABAC決定を強制するシステムは、両方とも疑いなくABACです。それらは単に、どこで強制が生きるかについて異なる選択をしただけであり、通常は運用規模や1つのポリシーを共有する必要があるサービスの数といった懸念によって駆動されます。

これは比喩における警察です。評決は、それが法廷内で行われるか、数マイル離れた街角で行われるかに関係なく実行されます。裁判所が決定し、警察が行動します。これは、認証システムにおける認証決定と強制との間の同じ分離です。

まとめ

実際の認証システムの完全な説明は、単一の単語ではなく、6つの軸すべてにわたるタプルです。「RBAC」は認証モデルの軸について何かを語り、他の5つの軸については何も語りません。認証システムは次のようになります：

• 中央集権的な管理（MAC）
• ロールベースのモデル（RBAC）
• JSONポリシー文書
• トークンベースの情報
• 共有ポリシーエンジン（PBACアーキテクチャ）
• ゲートウェイレベルの強制。

これは、現実世界で一般的で一貫したセットアップであり、その中のすべてのラベルは同時に正確です。なぜなら、それぞれが異なる質問に答えているからです。ほとんどの認証議論における混乱は、システムごとに1つのラベルを選び、それを網羅的なものとして扱うことから生じますが、実際には会話で最初に浮上した軸への回答にすぎません。

［画像］

このセクション全体を貫く法律の比喩は、ソフトウェアの用語が崩壊するのと同じ場所で崩壊するため、有用です。裁判所を「行政法」と呼んだり、「証人ベースの法律」の存在を主張したりする人はいません。なぜなら、裁判官は証人の陳述を考慮して評決を下すからです。しかし、その下にある6つの仕事（誰が立法するか、どのような種類の法律が適用されるか、法律が実際に何を言っているか、どのような事実に適用されるか、誰が裁くか、誰が執行するか）は、法廷でもポリシーエンジンでも同じように分離可能であり、それらを混同することは、どちらの場合でも同じ種類のカテゴリエラーを引き起こします。

結論

認証における用語の問題は、分野に語彙がないということではありません。むしろ、多すぎると言えます。MAC、DAC、RBAC、ABAC、ReBAC、ACL、PBACなど、それぞれが異なる論文、標準、またはベンダーによって、同じリクエストライフサイクルの異なるレイヤーで考案されました。問題は、これらすべてを、選択すべき「認証モデル」の単一のフラットリストとして扱う習慣であり、実際にはこれらの用語のほとんどが互いに競合していません。

質問を分離することは、実際のシステムのアプローチを選択する際に非常に実用的な方法で役立ちます。アクセスルールが自然に依存するものを（ロール、属性、関係）に基づいて認証モデルを選択します。次に、運用上の制約（ポリシーを共有する必要があるサービスの数、許容できるレイテンシ、監査またはルールを変更する必要がある人）に基づいてアーキテクチャ（決定がどこで行われ、強制されるか）を選択します。これらは、2つの別々のトレードオフセットを持つ2つの別々の決定であり、それらを単一の選択（「PBACを採用します」または「RBACを採用します」）にバンドルすることは、実際に決定する必要があることの半分を隠してしまう傾向があります。

これらのどれも、個々のラベルを間違ったものにするわけではありません。RBACは、モデルの現実的で有用な説明です。PBACは、アーキテクチャの現実的で有用な説明です。それらは単に同じものを記述しているのではなく、一貫した分類法があれば、それぞれが正確に何であるかを言うことができます。

参考文献

• ポリシーベースのアクセス制御（PBAC）は認証モデルか？
• 現代の認証モデルの分類法
• 認証の現状
• 認証およびアクセス制御のための体系的な文献レビュー：定義、戦略、およびモデル。International Journal of Web Information Systems、18(2/3)、156-180。 https://doi.org/10.1108/IJWIS-04-2022-0077。

［画像］

Andrea ChiarelliはAuth0（Okta）のプリンシパルデベロッパーアドボケイトです。彼はソフトウェア開発において豊富な経験を持ち、さまざまな技術的役割を担ってきました。近年、彼はアイデンティティに焦点を当て、コアコンセプトへの情熱を育み、それを開発者コミュニティに広めることを目指しています。

［画像］

［画像］

［画像］