web-dev-qa-db-ja.com

リソースのリストの権限を処理する

同じデータベースとテーブルを使用してロールと権限を管理する、いくつかの大きなサービスがあります。各サービスは、データベースに権限を直接要求します。

次に、新しいサービスを作成する必要があります。アイデアは、すべての許可スタッフを処理する集中サービスを作成することです。その後、私のチームは、データベースへの直接アクセスから新しい認証サービスの使用に古いサービスを移行します。全体像はマイクロサービスのように見えます。

認証サービスがロールまたは権限のリストで応答すると想定されています（まだ不明です）。 GET /foo/resources_a/:resource_a_id:などのリクエストでは問題ないようです。このようなリクエストがあれば、コントローラーにチェックを追加するだけです。

しかし、タイプresource_aのリソースのリストのリクエストが来たときに、このようなサービスをどのように使用すべきですか？ GET /foo/resources_aなどのリクエストを意味します。データベースを直接使用せず、パフォーマンスを大幅に低下させることのない優れたアプローチはありますか？

うまくいけば、私の考えと質問は明確です。

microservicesauthorizationpermissionsabacrbac
5
alex

質問に対する私の理解を要約すると、すべての権限を処理する集中型サービスが理想的です。理想的には、このサービスでは、パフォーマンスを大幅に低下させることなくデータベースを直接使用する必要がなくなります。

まず、使用できる承認フレームワークのタイプについて説明します。

承認フレームワーク

RBAC

世の中で最も普及している認可フレームワークは、RBACまたはロールベースのアクセス制御と呼ばれるものです。 RBACは、国立標準技術研究所であるNISTによって正式に規定されました 。あなたの場合、RBACでの課題は、ユーザー（ロール、グループ）のパラメーターのみを考慮するため、アイデンティティ中心であるということです。役割を定義できます。パーミッションに割り当てられるマネージャ（例： viewDocumentData。

RBACには制限があるため、お勧めしません。ただし、RBACを使用する必要がある場合は、フレームワーク（つまり Spring Security for Java）を使用してセキュリティを抽象化し、ゲッターメソッドを使用してユーザーに関する情報を取得し、UIに表示できます。

ABAC

これに対処するために、NISTは ABAC（Attribute Based Access Control） という新しいモデルを考案しました。 ABACでは、より多くのメタデータ/パラメーターを使用できるようになりました。たとえば、次のことを検討できます。

  • ユーザーのID、役割、役職、場所、部門、生年月日...
  • リソースのタイプ、場所、所有者、値、部門...
  • コンテキスト情報、例えば時刻
  • ユーザーがリソースに対して試みているアクション

これらはすべて属性と呼ばれます。属性はABACの基礎であり、その名前が付けられています。これらの属性を組み合わせてポリシーを作成できます。ポリシーはABACの秘密のソースに少し似ています。ポリシーは、アクセスを許可および拒否できます。例えば：

  • 従業員とレコードが同じリージョンにある場合、従業員はレコードを表示できます
  • 午後5時から午前8時の間にレコードの読み取りへのアクセスを拒否します。

ポリシーを使用して、高度なシナリオを表現できます。

  • 義務の分離
  • 時間ベースの制約（上記を参照）
  • 関係ベースのアクセス制御（上記を参照）
  • 委任規則は、ボブがアリスのドキュメントにアクセスすることを委任します。

ポリシーの記述に使用できる主な構文は2つあります。

  • 承認のための略語（ALFA）
  • eXtensible Access Control Markup Language（XACML）

ABACには、ポリシーを評価および適用する方法を定義するためのアーキテクチャも付属しています。

ABAC diagram

アーキテクチャには、次のコンポーネントが含まれています。

  • ポリシー実施ポイント（PEP）：これは、保護するAPI /アプリケーションを保護するコンポーネントです。 PEPはフローをインターセプトして分析し、承認リクエストをPDPに送信します（以下を参照）。次に、実施する決定（許可/拒否）を受け取ります。

  • policy Decision Point（PDP）は承認リクエストを受信し（Aliceはレコード＃123を表示できますか？）、設定されている一連のポリシーに対してそれを評価します。最終的に、PEPに送信する決定に到達します。評価プロセス中に、PDPは追加のメタデータを必要とする場合があります。ユーザーの役職。そのために、ポリシー情報ポイント（PIP）を利用できます。

  • ポリシー情報ポイント（PIP）は、PDPと基礎となるデータソース（例： LDAP、データベース、a RESTサービス。ユーザー、リソース、その他に関するメタデータが含まれています。PIPを使用して、実行時にPDPが必要とする可能性のある情報（リスクスコア、レコードの場所など）を取得できます。 、またはその他。

XACMLは、データベースを含むあらゆる種類のリソースに実装できます。ただし、データベースの場合、これらのリクエストをインターセプトしてトランスレータとして機能するプロキシが必要になります。これにより、必要に応じて、フィルタリングとマスキングをきめ細かく実装できます。

実装

XACMLにはいくつかのオープンソースおよび商用の実装があり、すべての権限を一元的に処理し、データベースを直接使用することを省略できます。使いやすさは実装に依存します。

たとえば、リレーショナルデータベースの場合は Axiomatics Data Access Filter があり、[〜 ＃〜] hadoop [〜＃〜]SmartGuard があります。

ユーザーのすべての権限の表示はXACML標準の一部ではありませんが、その実装を拡張することで実現できます。 Axiomaticsはこれを Axiomatics Reverse Query（ARQ） で実現しています。

完全な開示-私は公理学のために働いています。

XACML実装のリスト全体については、このリストをWikipediaで確認できます 。

11
Michael C Good