Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Implementierung eines PEP
Eine Policy Enforcement Point (PEP) ist für die Entgegennahme von Autorisierungsanfragen zuständig, die zur Bewertung an den Policy Decision Point (PDP) gesendet werden. Ein PEP kann sich überall in einer Anwendung befinden, wo Daten und Ressourcen geschützt werden müssen oder wo Autorisierungslogik angewendet wird. PEPs sind im Vergleich zu relativ einfach. PDPs Ein PEP ist nur dafür verantwortlich, eine Autorisierungsentscheidung anzufordern und auszuwerten, und benötigt keine Autorisierungslogik. PEPskann im PDPs Gegensatz dazu nicht in einer SaaS-Anwendung zentralisiert werden. Dies liegt daran, dass Autorisierung und Zugriffskontrolle in der gesamten Anwendung und ihren Zugriffspunkten implementiert werden müssen. PEPs kann auf Microservices APIs, Backend for Frontend (BFF) -Schichten oder auf jeden beliebigen Punkt in der Anwendung angewendet werden, an dem Zugriffskontrolle gewünscht oder erforderlich ist. Wenn die Autorisierung in einer Anwendung PEPs allgegenwärtig ist, wird sichergestellt, dass die Autorisierung häufig und unabhängig an mehreren Stellen überprüft wird.
Um ein PEP zu implementieren, muss zunächst festgelegt werden, wo die Durchsetzung der Zugriffskontrolle in einer Anwendung erfolgen soll. Berücksichtigen Sie diesen Grundsatz, wenn Sie entscheiden, welche Bereiche in Ihre Anwendung integriert werden PEPs sollten:
Wenn eine Anwendung eine API verfügbar macht, sollte es für diese API eine Autorisierung und Zugriffskontrolle geben.
Dies liegt daran, dass sie in einer microservices-orientierten oder serviceorientierten Architektur als Trennzeichen zwischen verschiedenen APIs Anwendungsfunktionen dienen. Es ist sinnvoll, die Zugriffskontrolle als logische Kontrollpunkte zwischen den Anwendungsfunktionen einzubeziehen. Wir empfehlen dringend, dass Sie jede API PEPs als Voraussetzung für den Zugriff auf jede API in eine SaaS-Anwendung aufnehmen. Es ist auch möglich, die Autorisierung an anderen Stellen in einer Anwendung zu integrieren. Bei monolithischen Anwendungen kann eine PEPs Integration in die Logik der Anwendung selbst erforderlich sein. Es gibt keinen einzigen Ort, der aufgenommen werden PEPs sollte, aber ziehen Sie in Betracht, das API-Prinzip als Ausgangspunkt zu verwenden.
Beantragung einer Autorisierungsentscheidung
Ein PEP muss beim PDP eine Autorisierungsentscheidung beantragen. Die Anfrage kann verschiedene Formen annehmen. Die einfachste und zugänglichste Methode, um eine Autorisierungsentscheidung anzufordern, besteht darin, eine Autorisierungsanfrage oder -abfrage an eine RESTful API zu senden, die vom PDP (OPA oder Verified Permissions) verfügbar gemacht wird. Wenn Sie Verified Permissions verwenden, können Sie die IsAuthorizedMethode auch mithilfe des AWS SDK aufrufen, um eine Autorisierungsentscheidung abzurufen. Die einzige Funktion eines PEP in diesem Muster besteht darin, die Informationen weiterzuleiten, die für die Autorisierungsanfrage oder -abfrage benötigt werden. Dies kann so einfach sein wie das Weiterleiten einer von einer API empfangenen Anfrage als Eingabe an das PDP. Es gibt andere Methoden zum Erstellen PEPs. Sie können beispielsweise eine OPA-PDP lokal in eine in der Programmiersprache Go geschriebene Anwendung als Bibliothek integrieren, anstatt eine API zu verwenden.
Bewertung einer Autorisierungsentscheidung
PEPs muss Logik zur Auswertung der Ergebnisse einer Autorisierungsentscheidung beinhalten. Wenn sie als verfügbar gemacht PDPs werden APIs, ist die Autorisierungsentscheidung wahrscheinlich im JSON-Format und wird durch einen API-Aufruf zurückgegeben. Das PEP muss diesen JSON-Code auswerten, um festzustellen, ob die ergriffene Aktion autorisiert ist. Wenn ein PDP beispielsweise so konzipiert ist, dass es eine boolesche Entscheidung über das Zulassen oder Verweigern der Autorisierung bereitstellt, könnte das PEP einfach diesen Wert überprüfen und dann den HTTP-Statuscode 200 für Zulassen und den HTTP-Statuscode 403 für Verweigern zurückgeben. Dieses Muster der Integration eines PEP als Voraussetzung für den Zugriff auf eine API ist ein einfach zu implementierendes und hocheffektives Muster für die Implementierung der Zugriffskontrolle in einer SaaS-Anwendung. In komplizierteren Szenarien könnte das PEP für die Auswertung von beliebigem JSON-Code verantwortlich sein, der vom PDP zurückgegeben wird. Das PEP muss so geschrieben werden, dass es die Logik enthält, die zur Interpretation der vom PDP zurückgegebenen Autorisierungsentscheidung erforderlich ist. Da ein PEP wahrscheinlich an vielen verschiedenen Stellen in Ihrer Anwendung implementiert wird, empfehlen wir Ihnen, Ihren PEP-Code als wiederverwendbare Bibliothek oder Artefakt in der Programmiersprache Ihrer Wahl zu verpacken. Auf diese Weise kann Ihr PEP problemlos und mit minimalem Nachaufwand an jeder Stelle in Ihrer Anwendung integriert werden.