OPA の設計モデル - AWS 規範ガイダンス
API での PEPs での一元化された PDP の使用 APIsAPI での PEPsでの分散 PDP の使用 APIs分散 PDP をライブラリとして使用する

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

OPA の設計モデル

API での PEPs での一元化された PDP の使用 APIs

APIsモデルのポリシー適用ポイント (PEPs) を使用した一元化されたポリシー決定ポイント (PDP) は、業界のベストプラクティスに従って、API アクセスコントロールと認可のための効果的で簡単に維持できるシステムを作成します。このアプローチは、いくつかの主要な原則をサポートしています。

  • 認可と API アクセスコントロールは、アプリケーションの複数のポイントに適用されます。

  • 認可ロジックはアプリケーションから独立しています。

  • アクセスコントロールの決定は一元管理されます。

このモデルは、一元化された PDP を使用して認可の決定を行います。PEPsは、PDP への認可リクエストを行うためにすべての APIs に実装されます。次の図は、架空のマルチテナント SaaS アプリケーションでこのモデルを実装する方法を示しています。

一元化された PDP を使用した OPA 設計モデル

アプリケーションフロー (図では青色の番号付きコールアウトで示されています）。

  1. JWT を持つ認証されたユーザーは、Amazon CloudFront への HTTP リクエストを生成します。

  2. CloudFront は、CloudFront オリジンとして設定された Amazon API Gateway にリクエストを転送します。

  3. API Gateway カスタムオーソライザーが呼び出され、JWT が検証されます。

  4. マイクロサービスはリクエストに応答します。

認可と API アクセスコントロールフロー (図では赤の番号のコールアウトで示されています）。

  1. PEP は認可サービスを呼び出し、JWTs。

  2. 認可サービス (PDP) はリクエストデータを受け取り、サイドカーとして実行されている OPA エージェント REST API をクエリします。リクエストデータは、クエリへの入力として機能します。

  3. OPA は、クエリで指定された関連ポリシーに基づいて入力を評価します。必要に応じて承認を決定するためにデータがインポートされます。

  4. OPA は認可サービスに決定を返します。

  5. 認可決定は PEP に返され、評価されます。

このアーキテクチャでは、PEPs Amazon CloudFront と Amazon API Gateway のサービスエンドポイント、およびマイクロサービスごとに認可決定をリクエストします。認可の決定は、OPA サイドカーを使用する認可サービス (PDP) によって行われます。この認可サービスは、コンテナまたは従来のサーバーインスタンスとして運用できます。OPA サイドカーは RESTful API をローカルに公開するため、API は認可サービスにのみアクセスできます。認可サービスは、PEPs。認可サービスが PEPs と OPA の間の仲介として機能することで、PEPs からの認可リクエストが OPA によって予期されるクエリ入力に準拠していない場合など、PEP と OPA の間に必要な変換ロジックを挿入できます。

このアーキテクチャは、カスタムポリシーエンジンでも使用できます。ただし、OPA から得られる利点は、カスタムポリシーエンジンによって提供されるロジックに置き換える必要があります。

API 上の PEPs を使用した一元化された PDP は、APIs。 APIs 実装が簡単で、APIs、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、またはその他のアプリケーションコンポーネントの承認決定を行うためのeasy-to-use繰り返し可能なインターフェイスも提供します。ただし、認可の決定では別の API を呼び出す必要があるため、このアプローチではアプリケーションでレイテンシーが長すぎる可能性があります。ネットワークレイテンシーに問題がある場合は、分散 PDP を検討してください。

API での PEPsでの分散 PDP の使用 APIs

APIsモデルのポリシー適用ポイント (PEPs) を使用した分散ポリシー決定ポイント (PDP) は、業界のベストプラクティスに従って、API アクセスコントロールと認可のための効果的なシステムを作成します。API での PEPsを使用した一元化された PDP モデルと同様に、このアプローチは次の主要な原則をサポートしています。 APIs

  • 認可と API アクセスコントロールは、アプリケーションの複数のポイントに適用されます。

  • 認可ロジックはアプリケーションから独立しています。

  • アクセスコントロールの決定は一元管理されます。

PDP が配布されるときに、アクセスコントロールの決定が一元化される理由が疑問に思うかもしれません。PDP はアプリケーションの複数の場所に存在する可能性がありますが、アクセスコントロールの決定を行うには同じ認可ロジックを使用する必要があります。すべての PDPs、入力が同じであれば、同じアクセスコントロールの決定を行います。PEPsは、PDP への認可リクエストを行うためにすべての APIs に実装されます。次の図は、この分散モデルを架空のマルチテナント SaaS アプリケーションで実装する方法を示しています。

このアプローチPDPs はアプリケーションの複数の場所に実装されます。サイドカーや Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを備えたコンテナ化されたサービスなど、OPA を実行し PDP をサポートできるオンボードコンピューティング機能を持つアプリケーションコンポーネントの場合、一元化された PDP サービスに対して RESTful API コールを行うことなく、PDP の決定をアプリケーションコンポーネントに直接統合できます。これは、すべてのアプリケーションコンポーネントが認可決定を取得するために追加の API コールを行う必要がないため、一元化された PDP モデルで発生する可能性のあるレイテンシーを減らすという利点があります。ただし、このモデルでは、Amazon CloudFront や Amazon API Gateway サービスなど、PDP の直接統合を可能にするオンボードコンピューティング機能を持たないアプリケーションコンポーネントに対して、一元化された PDP が依然として必要です。

次の図は、一元化された PDP と分散された PDP のこの組み合わせを、架空のマルチテナント SaaS アプリケーションで実装する方法を示しています。

分散 PDP を使用した OPA 設計モデル

アプリケーションフロー (図では青色の番号付きコールアウトで示されています）。

  1. JWT を持つ認証されたユーザーは、Amazon CloudFront への HTTP リクエストを生成します。

  2. CloudFront は、CloudFront オリジンとして設定された Amazon API Gateway にリクエストを転送します。

  3. API Gateway カスタムオーソライザーが呼び出され、JWT が検証されます。

  4. マイクロサービスはリクエストに応答します。

認可と API アクセスコントロールフロー (図では赤の番号のコールアウトで示されています）。

  1. PEP は認可サービスを呼び出し、JWTs。

  2. 認可サービス (PDP) はリクエストデータを受け取り、サイドカーとして実行されている OPA エージェント REST API をクエリします。リクエストデータは、クエリへの入力として機能します。

  3. OPA は、クエリで指定された関連ポリシーに基づいて入力を評価します。必要に応じて承認を決定するためにデータがインポートされます。

  4. OPA は認可サービスに決定を返します。

  5. 認可決定は PEP に返され、評価されます。

このアーキテクチャでは、PEPs CloudFront と API Gateway のサービスエンドポイント、およびマイクロサービスごとに認可決定をリクエストします。マイクロサービスの認可決定は、アプリケーションコンポーネントでサイドカーとして動作する認可サービス (PDP) によって行われます。このモデルは、コンテナまたは Amazon Elastic Compute Cloud (Amazon EC2) インスタンスで実行されるマイクロサービス (または サービス) で使用できます。API Gateway や CloudFront などのサービスの承認決定は、外部認可サービスに連絡する必要があります。いずれにしても、認可サービスは PEPs。認可サービスが PEPs と OPA の間の仲介として機能することで、PEPs からの認可リクエストが OPA によって予期されるクエリ入力に準拠していない場合など、PEP と OPA の間に必要な変換ロジックを挿入できます。

このアーキテクチャは、カスタムポリシーエンジンでも使用できます。ただし、OPA から得られる利点は、カスタムポリシーエンジンによって提供されるロジックに置き換える必要があります。

API で PEPsを使用する分散 PDP は、APIs の堅牢な認可システムを作成するオプションを提供します。 APIs 実装が簡単で、APIs、マイクロサービス、バックエンド for Frontend (BFF) レイヤー、またはその他のアプリケーションコンポーネントの承認決定を行うためのeasy-to-use繰り返し可能なインターフェイスを提供します。このアプローチには、一元化された PDP モデルで発生する可能性のあるレイテンシーを減らすという利点もあります。

分散 PDP をライブラリとして使用する

アプリケーション内で使用するためにライブラリまたはパッケージとして利用できる PDP に認可の決定をリクエストすることもできます。OPA は Go サードパーティーライブラリとして使用できます。他のプログラミング言語では、通常、このモデルを採用すると、カスタムポリシーエンジンを作成する必要があります。