Entwerfen Sie Modelle für OPA

Verwendung eines zentralisierten PDP mit PEPs auf APIs

Das Modell eines zentralisierten Policy-Decision-Punkts (PDP) mit Policy-Enforcement-Punkten (PEPs) auf APIs folgt branchenweit bewährten Verfahren zur Schaffung eines effektiven und einfach zu wartenden Systems für die API-Zugriffskontrolle und -autorisierung. Dieser Ansatz unterstützt mehrere wichtige Prinzipien:

• Autorisierung und API-Zugriffskontrolle werden an mehreren Stellen in der Anwendung angewendet.

• Die Autorisierungslogik ist unabhängig von der Anwendung.

• Entscheidungen zur Zugriffskontrolle sind zentralisiert.

Dieses Modell verwendet ein zentralisiertes PDP, um Autorisierungsentscheidungen zu treffen. PEPs werden an allen APIs implementiert, um Autorisierungsanfragen an das PDP zu stellen. Das folgende Diagramm zeigt, wie Sie dieses Modell in einer hypothetischen SaaS-Anwendung mit mehreren Mandanten implementieren können.

Anwendungsablauf (im Diagramm mit blau nummerierten Callouts dargestellt):

1. Ein authentifizierter Benutzer mit einem JWT generiert eine HTTP-Anfrage an Amazon. CloudFront

2. CloudFront leitet die Anfrage an Amazon API Gateway weiter, das als CloudFront Ursprung konfiguriert ist.

3. Ein benutzerdefinierter API Gateway Gateway-Authorizer wird aufgerufen, um das JWT zu verifizieren.

4. Microservices antworten auf die Anfrage.

Ablauf der Autorisierung und API-Zugriffskontrolle (im Diagramm mit roten nummerierten Callouts dargestellt):

1. Das PEP ruft den Autorisierungsdienst auf und leitet die Anforderungsdaten, einschließlich aller JWTs, weiter.

2. Der Autorisierungsdienst (PDP) verwendet die Anforderungsdaten und fragt eine REST-API des OPA-Agenten ab, die als Sidecar ausgeführt wird. Die Anforderungsdaten dienen als Eingabe für die Abfrage.

3. OPA bewertet die Eingabe auf der Grundlage der in der Abfrage angegebenen relevanten Richtlinien. Daten werden importiert, um bei Bedarf eine Autorisierungsentscheidung zu treffen.

4. OPA gibt eine Entscheidung an den Autorisierungsdienst zurück.

5. Die Autorisierungsentscheidung wird an das PEP zurückgesendet und bewertet.

In dieser Architektur fordern PEPs Autorisierungsentscheidungen an den Service-Endpunkten für Amazon CloudFront und Amazon API Gateway sowie für jeden Microservice an. Die Autorisierungsentscheidung wird von einem Autorisierungsdienst (dem PDP) mit einem OPA-Sidecar getroffen. Sie können diesen Autorisierungsdienst als Container oder als herkömmliche Serverinstanz betreiben. Der OPA-Sidecar stellt seine RESTful-API lokal zur Verfügung, sodass nur der Autorisierungsdienst auf die API zugreifen kann. Der Autorisierungsdienst stellt eine separate API zur Verfügung, die PEPs zur Verfügung steht. Wenn der Autorisierungsdienst als Vermittler zwischen PEPs und OPA fungiert, kann jede erforderliche Transformationslogik zwischen PEPs und OPA eingefügt werden, z. B. wenn die Autorisierungsanfrage eines PEP nicht der von OPA erwarteten Abfrageeingabe entspricht.

Sie können diese Architektur auch mit benutzerdefinierten Policy-Engines verwenden. Alle Vorteile von OPA müssen jedoch durch die Logik ersetzt werden, die von der benutzerdefinierten Policy-Engine bereitgestellt wird.

Ein zentralisiertes PDP mit PEPs auf APIs bietet eine einfache Möglichkeit, ein robustes Autorisierungssystem für APIs zu erstellen. Es ist einfach zu implementieren und bietet außerdem eine easy-to-use wiederholbare Schnittstelle für Autorisierungsentscheidungen für APIs, Microservices, Backend for Frontend (BFF) -Schichten oder andere Anwendungskomponenten. Dieser Ansatz kann jedoch zu viel Latenz in Ihrer Anwendung führen, da Autorisierungsentscheidungen den Aufruf einer separaten API erfordern. Wenn die Netzwerklatenz ein Problem darstellt, könnten Sie ein verteiltes PDP in Betracht ziehen.

Verwenden eines verteilten PDP mit PEPs auf APIs

Das Modell des Distributed Policy Decision Point (PDP) mit Policy Enforcement Points (PEPs) auf APIs folgt den branchenweit bewährten Verfahren zur Schaffung eines effektiven Systems für die API-Zugriffskontrolle und -autorisierung. Wie beim Modell des zentralisierten PDP mit PEPs auf APIs unterstützt dieser Ansatz die folgenden Hauptprinzipien:

• Autorisierung und API-Zugriffskontrolle werden an mehreren Stellen in der Anwendung angewendet.

• Die Autorisierungslogik ist unabhängig von der Anwendung.

• Entscheidungen zur Zugriffskontrolle sind zentralisiert.

Sie fragen sich vielleicht, warum Entscheidungen zur Zugriffskontrolle zentralisiert werden, wenn das PDP verteilt wird. Obwohl das PDP möglicherweise an mehreren Stellen in einer Anwendung vorhanden ist, muss es dieselbe Autorisierungslogik verwenden, um Entscheidungen zur Zugriffskontrolle zu treffen. Alle PDPs bieten dieselben Zugriffskontrollentscheidungen bei denselben Eingaben. PEPs werden an allen APIs implementiert, um Autorisierungsanfragen an den PDP zu stellen. Die folgende Abbildung zeigt, wie dieses verteilte Modell in einer hypothetischen SaaS-Anwendung mit mehreren Mandanten implementiert werden kann.

Bei diesem Ansatz werden PDPs an mehreren Stellen in der Anwendung implementiert. Bei Anwendungskomponenten mit integrierten Rechenfunktionen, die OPA ausführen und eine PDP unterstützen, wie z. B. einen containerisierten Service mit Sidecar oder eine Amazon Elastic Compute Cloud (Amazon EC2) -Instance, können PDP-Entscheidungen direkt in die Anwendungskomponente integriert werden, ohne dass ein RESTful-API-Aufruf an einen zentralen PDP-Service getätigt werden muss. Dies hat den Vorteil, dass die Latenz reduziert wird, die beim zentralisierten PDP-Modell auftreten kann, da nicht jede Anwendungskomponente zusätzliche API-Aufrufe tätigen muss, um Autorisierungsentscheidungen zu erhalten. In diesem Modell ist jedoch immer noch ein zentralisiertes PDP für Anwendungskomponenten erforderlich, die nicht über integrierte Rechenfunktionen verfügen, die eine direkte Integration eines PDP ermöglichen, wie z. B. der Amazon CloudFront - oder Amazon API Gateway Gateway-Service.

Das folgende Diagramm zeigt, wie diese Kombination aus einem zentralisierten PDP und einem verteilten PDP in einer hypothetischen SaaS-Anwendung für mehrere Mandanten implementiert werden kann.

Anwendungsablauf (im Diagramm mit blau nummerierten Callouts dargestellt):

1. Ein authentifizierter Benutzer mit einem JWT generiert eine HTTP-Anfrage an Amazon. CloudFront

2. CloudFront leitet die Anfrage an Amazon API Gateway weiter, das als CloudFront Ursprung konfiguriert ist.

3. Ein benutzerdefinierter API Gateway Gateway-Authorizer wird aufgerufen, um das JWT zu verifizieren.

4. Microservices antworten auf die Anfrage.

Ablauf der Autorisierung und API-Zugriffskontrolle (im Diagramm mit roten nummerierten Callouts dargestellt):

1. Das PEP ruft den Autorisierungsdienst auf und leitet die Anforderungsdaten, einschließlich aller JWTs, weiter.

2. Der Autorisierungsdienst (PDP) verwendet die Anforderungsdaten und fragt eine REST-API des OPA-Agenten ab, die als Sidecar ausgeführt wird. Die Anforderungsdaten dienen als Eingabe für die Abfrage.

3. OPA bewertet die Eingabe auf der Grundlage der in der Abfrage angegebenen relevanten Richtlinien. Daten werden importiert, um bei Bedarf eine Autorisierungsentscheidung zu treffen.

4. OPA gibt eine Entscheidung an den Autorisierungsdienst zurück.

5. Die Autorisierungsentscheidung wird an das PEP zurückgesendet und bewertet.

In dieser Architektur fordern PEPs Autorisierungsentscheidungen an den Service-Endpunkten für ein API Gateway CloudFront und für jeden Microservice an. Die Autorisierungsentscheidung für Microservices wird von einem Autorisierungsdienst (dem PDP) getroffen, der als Sidecar mit der Anwendungskomponente fungiert. Dieses Modell ist für Microservices (oder Services) möglich, die auf Containern oder Amazon Elastic Compute Cloud (Amazon EC2) -Instances ausgeführt werden. Autorisierungsentscheidungen für Dienste wie API Gateway CloudFront würden immer noch die Kontaktaufnahme mit einem externen Autorisierungsdienst erfordern. Unabhängig davon stellt der Autorisierungsdienst eine API zur Verfügung, die PEPs zur Verfügung steht. Wenn der Autorisierungsdienst als Vermittler zwischen PEPs und OPA fungiert, kann jede Transformationslogik zwischen PEPs und OPA eingefügt werden, die erforderlich sein könnte, z. B. wenn die Autorisierungsanfrage eines PEP nicht der von OPA erwarteten Abfrageeingabe entspricht.

Sie können diese Architektur auch mit benutzerdefinierten Policy-Engines verwenden. Alle Vorteile von OPA müssen jedoch durch die Logik ersetzt werden, die von der benutzerdefinierten Policy-Engine bereitgestellt wird.

Ein verteiltes PDP mit PEPs auf APIs bietet die Möglichkeit, ein robustes Autorisierungssystem für APIs zu erstellen. Es ist einfach zu implementieren und bietet eine easy-to-use wiederholbare Schnittstelle für Autorisierungsentscheidungen für APIs, Microservices, Backend for Frontend (BFF) -Schichten oder andere Anwendungskomponenten. Dieser Ansatz hat auch den Vorteil, dass die Latenz reduziert wird, die beim zentralisierten PDP-Modell auftreten kann.

Verwenden eines verteilten PDP als Bibliothek

Sie können Autorisierungsentscheidungen auch von einem PDP anfordern, das als Bibliothek oder Paket zur Verwendung in einer Anwendung zur Verfügung gestellt wird. OPA kann als Go-Bibliothek eines Drittanbieters verwendet werden. Für andere Programmiersprachen bedeutet die Übernahme dieses Modells im Allgemeinen, dass Sie eine benutzerdefinierte Policy-Engine erstellen müssen.