APIs の PEPsを使用した一元化された PDP - AWS 規範ガイダンス

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

APIs の PEPsを使用した一元化された PDP

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

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

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

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

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

A sample multi-tenant SaaS application that uses a centralized PDP with PEPs on APIs

アプリケーションフロー:

Application flow - step 1

JWT トークンを持つ認証済みユーザーは、Amazon への HTTP リクエストを生成します CloudFront。

Application flow - step 2

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

Application flow - step 3

API Gateway Lambda オーソライザーが呼び出され、JWT トークンが検証されます。

Application flow - step 4

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

認証と API アクセスコントロールフロー:

Authorization flow - step 1

PEP は認証サービスを呼び出し、JWT トークンを含むリクエストデータを渡します。

Authorization flow - step 2

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

Authorization flow - step 3

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

Authorization flow - step 4

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

Authorization flow - step 5

PEP に返され、評価される認可の決定。

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

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

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