PEP の実装

ポリシー適用ポイント (PEP) は、評価のためにポリシー決定ポイント (PDP) に送信される承認リクエストを受信する責任があります。PEP は、データとリソースを保護する必要があるアプリケーションや、認証ロジックが適用されるアプリケーション内の任意の場所に置くことができます。PEPsは PDPsと比較して比較的簡単です。PEP は、承認決定のリクエストと評価にのみ責任を負い、承認ロジックは必要ありません。PEPs、PDPsとは異なり、SaaS アプリケーションに一元化することはできません。これは、アプリケーションとそのアクセスポイント全体に承認とアクセスコントロールを実装する必要があるためです。PEPs は、APIs、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、またはアクセスコントロールが望ましいか必要なアプリケーション内の任意のポイントに適用できます。PEPs分散させると、承認が複数のポイントで頻繁に独立して検証されます。   

PEP を実装するための最初のステップは、アプリケーションでアクセスコントロールの適用を行う場所を決定することです。PEPs をアプリケーションに統合する場所を決定するときは、次の原則を考慮してください。 

アプリケーションが API を公開する場合は、その API に対する認可とアクセスコントロールが必要です。

これは、マイクロサービス指向またはサービス指向のアーキテクチャでは、APIsが異なるアプリケーション関数間の区切り文字として機能するためです。アプリケーション関数間の論理チェックポイントとしてアクセスコントロールを含めることは理にかなっています。SaaS アプリケーション内の各 API にアクセスするための前提条件として PEPs を含めることを強くお勧めします。また、アプリケーションの他のポイントで認証を統合することもできます。モノリシックアプリケーションでは、PEPsをアプリケーション自体のロジックに統合する必要がある場合があります。PEPs を含める場所は 1 つではありませんが、API の原則を出発点として使用することを検討してください。

承認決定のリクエスト

PEP は PDP に承認決定をリクエストする必要があります。リクエストにはいくつかの形式があります。承認決定をリクエストするための最も簡単でアクセス可能な方法は、PDP (OPA または Verified Permissions) によって公開される RESTful API に認証リクエストまたはクエリを送信することです。Verified Permissions を使用している場合は、 AWS SDK を使用して IsAuthorizedメソッドを呼び出し、承認決定を取得することもできます。このパターンの PEP の唯一の機能は、認証リクエストまたはクエリが必要とする情報を転送することです。これは、API が受信したリクエストを PDP への入力として転送するのと同じくらい簡単です。PEPs。例えば、API を使用する代わりに、ローカルで OPA PDP を Go プログラミング言語で記述されたアプリケーションとライブラリとして統合できます。

承認決定の評価

PEPs には、承認決定の結果を評価するロジックを含める必要があります。PDPs が APIsとして公開されると、承認の決定は JSON 形式で API コールによって返される可能性があります。PEP はこの JSON コードを評価して、実行されているアクションが認可されているかどうかを判断する必要があります。例えば、PDP がブール型の許可または拒否承認の決定を提供するように設計されている場合、PEP はこの値をチェックするだけで、許可の場合は HTTP ステータスコード 200、拒否の場合は HTTP ステータスコード 403 を返すことがあります。API にアクセスするための前提条件として PEP を組み込むこのパターンは、SaaS アプリケーション全体にアクセス制御を実装するための、簡単に実装され、非常に効果的なパターンです。より複雑なシナリオでは、PEP が PDP によって返される任意の JSON コードを評価する責任を負う場合があります。PEP は、PDP が返す承認決定を解釈するために必要なロジックを含めるように記述する必要があります。PEP はアプリケーションのさまざまな場所に実装される可能性が高いため、選択したプログラミング言語で再利用可能なライブラリまたはアーティファクトとして PEP コードをパッケージ化することをお勧めします。これにより、PEP はアプリケーションのどの時点でも、最小限の手直しで簡単に統合できます。