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.
Häufig gestellte Fragen
Dieser Abschnitt enthält Antworten auf häufig gestellte Fragen zur Implementierung von API-Zugriffskontrolle und -autorisierung in SaaS-Anwendungen mit mehreren Mandanten.
F: Was ist der Unterschied zwischen Autorisierung und Authentifizierung?
Antwort: Bei der Authentifizierung wird überprüft, wer ein Benutzer ist. Die Autorisierung gewährt Benutzern die Erlaubnis, auf eine bestimmte Ressource zuzugreifen.
F: Was ist der Unterschied zwischen Autorisierung und Mandantenisolierung in einer SaaS-Anwendung?
Antwort: Die Mandantenisolierung bezieht sich auf explizite Mechanismen, die in einem SaaS-System verwendet werden, um sicherzustellen, dass die Ressourcen jedes Mandanten isoliert sind, auch wenn sie auf einer gemeinsam genutzten Infrastruktur betrieben werden. Bei der Mehrmandantenautorisierung werden eingehende Aktionen autorisiert und verhindert, dass diese auf dem falschen Mandanten ausgeführt werden. Ein hypothetischer Benutzer könnte authentifiziert und autorisiert werden, könnte aber dennoch auf die Ressourcen eines anderen Mandanten zugreifen. Nichts in Bezug auf Authentifizierung und Autorisierung blockiert diesen Zugriff unbedingt, aber um dieses Ziel zu erreichen, ist eine Isolierung des Mandanten erforderlich. Weitere Informationen zu diesen beiden Konzepten finden Sie in der Diskussion zur Mandantenisolierung im Whitepaper AWS SaaS Architecture Fundamentals.
F: Warum muss ich die Mandantenisolierung für meine SaaS-Anwendung in Betracht ziehen?
Antwort: SaaS-Anwendungen haben mehrere Mandanten. Ein Mandant kann eine Kundenorganisation oder eine externe Entität sein, die diese SaaS-Anwendung verwendet. Je nachdem, wie die Anwendung konzipiert ist, bedeutet dies, dass Mandanten möglicherweise auf gemeinsam genutzte APIs Datenbanken oder andere Ressourcen zugreifen. Es ist wichtig, die Mandantenisolierung aufrechtzuerhalten, d. h. Konstrukte, die den Zugriff auf Ressourcen streng kontrollieren und jeden Versuch blockieren, auf Ressourcen eines anderen Mandanten zuzugreifen, um zu verhindern, dass Benutzer eines Mandanten auf die privaten Informationen eines anderen Mandanten zugreifen. SaaS-Anwendungen sind häufig so konzipiert, dass sie sicherstellen, dass die Mandantenisolierung während einer gesamten Anwendung aufrechterhalten wird und dass Mandanten nur auf ihre eigenen Ressourcen zugreifen können.
F: Warum benötige ich ein Zugriffskontrollmodell?
Antwort: Zugriffskontrollmodelle werden verwendet, um eine konsistente Methode zu erstellen, mit der bestimmt wird, wie der Zugriff auf Ressourcen in einer Anwendung gewährt wird. Dies kann geschehen, indem Benutzern Rollen zugewiesen werden, die eng an der Geschäftslogik ausgerichtet sind, oder es kann auf anderen kontextuellen Attributen wie der Tageszeit oder der Tatsache basieren, ob ein Benutzer eine vordefinierte Bedingung erfüllt. Zugriffskontrollmodelle bilden die grundlegende Logik, die Ihre Anwendung verwendet, wenn sie Autorisierungsentscheidungen zur Bestimmung der Benutzerberechtigungen trifft.
F: Ist eine API-Zugriffskontrolle für meine Anwendung erforderlich?
Antwort: Ja. APIs sollte immer überprüfen, ob der Anrufer über den entsprechenden Zugriff verfügt. Eine umfassende API-Zugriffskontrolle stellt außerdem sicher, dass der Zugriff nur auf Mandantenbasis gewährt wird, sodass eine angemessene Isolierung gewährleistet werden kann.
F: Warum werden Policy-Engines zur Autorisierung PDPs empfohlen?
Antwort: Ein Policy Decision Point (PDP) ermöglicht es, die Autorisierungslogik im Anwendungscode auf ein separates System auszulagern. Dies kann den Anwendungscode vereinfachen. Es bietet auch eine easy-to-use idempotente Schnittstelle für Autorisierungsentscheidungen für Microservices APIs, Backend for Frontend (BFF) -Schichten oder jede andere Anwendungskomponente.
F: Was ist ein PEP?
Antwort: Eine Policy-Enforcement-Stelle (PEP) ist für die Entgegennahme von Autorisierungsanfragen zuständig, die zur Prüfung an das 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 PDPs relativ einfach. Ein PEP ist nur dafür zuständig, eine Autorisierungsentscheidung anzufordern und auszuwerten, und es muss keine Autorisierungslogik eingebaut werden.
F: Wie sollte ich zwischen Amazon Verified Permissions und OPA wählen?
Antwort: Wenn Sie zwischen Verified Permissions und Open Policy Agent (OPA) wählen möchten, sollten Sie immer Ihren Anwendungsfall und Ihre individuellen Anforderungen berücksichtigen. Verified Permissions bietet eine vollständig verwaltete Möglichkeit, detaillierte Berechtigungen zu definieren, Berechtigungen anwendungsübergreifend zu prüfen und das Policy-Verwaltungssystem für Ihre Anwendungen zu zentralisieren und gleichzeitig Ihre Anforderungen an die Anwendungslatenz mit einer Verarbeitung im Millisekundenbereich zu erfüllen. OPA ist eine universell einsetzbare Open-Source-Policy-Engine, die Ihnen auch dabei helfen kann, Richtlinien in Ihrem gesamten Anwendungsstapel zu vereinheitlichen. Um OPA ausführen zu können, müssen Sie es in Ihrer AWS Umgebung hosten, normalerweise mit einem Container oder Funktionen. AWS Lambda
Verified Permissions verwendet die Open-Source-Richtliniensprache Cedar, wohingegen OPA Rego verwendet. Wenn Sie mit einer dieser Sprachen vertraut sind, könnten Sie sich daher für diese Lösung entscheiden. Wir empfehlen Ihnen jedoch, sich über beide Sprachen zu informieren und dann von dem Problem, das Sie zu lösen versuchen, zurückzugehen, um die beste Lösung für Ihren Anwendungsfall zu finden.
F: Gibt es Open-Source-Alternativen zu Verified Permissions und OPA?
Antwort: Es gibt einige Open-Source-Systeme, die Verified Permissions und dem Open Policy Agent (OPA) ähneln, wie z. B. die Common Expression
F: Muss ich einen Autorisierungsdienst schreiben, um OPA verwenden zu können, oder kann ich direkt mit OPA interagieren?
Antwort: Sie können direkt mit OPA interagieren. Ein Autorisierungsdienst im Kontext dieser Anleitung bezieht sich auf einen Dienst, der Autorisierungsentscheidungsanfragen in OPA-Abfragen übersetzt und umgekehrt. Wenn Ihre Anwendung OPA-Antworten direkt abfragen und annehmen kann, ist es nicht notwendig, diese zusätzliche Komplexität einzuführen.
F: Wie überwache ich meine OPA-Agenten im Hinblick auf Verfügbarkeit und Prüfung?
Antwort: OPA bietet Protokollierung und grundlegende Verfügbarkeitsüberwachung, obwohl die Standardkonfiguration für Unternehmensbereitstellungen wahrscheinlich nicht ausreichend sein wird. Weitere Informationen finden Sie im DevOps Abschnitt „Überwachung und Protokollierung“ weiter oben in diesem Handbuch.
F: Wie kann ich verifizierte Berechtigungen zu Verfügbarkeits- und Prüfungszwecken überwachen?
Antwort: Verified Permissions ist ein AWS verwalteter Dienst, dessen Verfügbarkeit über den überwacht werden kann. AWS Health Dashboard Darüber hinaus ist Verified Permissions in der Lage AWS CloudTrail, sich bei Amazon CloudWatch Logs, Amazon S3 und Amazon Data Firehose anzumelden.
F: Welche Betriebssysteme und AWS Dienste kann ich verwenden, um OPA auszuführen?
Antwort: Sie können OPA unter macOS, Windows und Linux ausführen
F: Welche Betriebssysteme und AWS Dienste kann ich verwenden, um Verified Permissions auszuführen?
Antwort: Verified Permissions ist ein AWS verwalteter Dienst und wird betrieben von AWS. Für die Verwendung von Verified Permissions ist keine zusätzliche Konfiguration, Installation oder Hosting erforderlich, mit Ausnahme der Möglichkeit, Autorisierungsanfragen an den Dienst zu stellen.
F: Kann ich OPA auf ausführen? AWS Lambda
Antwort: Sie können OPA auf Lambda als Go-Bibliothek ausführen. Informationen dazu, wie Sie dies für einen API Gateway Lambda-Authorizer tun können, finden Sie im AWS Blogbeitrag Creating a custom Lambda Authorizer using
F: Wie sollte ich mich zwischen einem verteilten PDP und einem zentralisierten PDP-Ansatz entscheiden?
Antwort: Das hängt von Ihrer Anwendung ab. Sie wird höchstwahrscheinlich anhand des Latenzunterschieds zwischen einem verteilten und einem zentralisierten PDP-Modell bestimmt. Wir empfehlen Ihnen, einen Machbarkeitsnachweis zu erstellen und die Leistung Ihrer Anwendung zu testen, um Ihre Lösung zu verifizieren.
F: Kann ich OPA auch für andere Anwendungsfälle verwenden? APIs
Antwort: Ja. Die OPA-Dokumentation enthält Beispiele für Kubernetes
F: Kann ich Verified Permissions auch für andere Anwendungsfälle verwenden? APIs
Antwort: Ja. Verified Permissions kann auf jede eingegangene Autorisierungsanfrage eine DENY Antwort ALLOW oder eine Antwort geben. Verified Permissions kann Autorisierungsantworten für jede Anwendung oder jeden Dienst bereitstellen, für den Autorisierungsentscheidungen erforderlich sind.
F: Kann ich Richtlinien in Verified Permissions mithilfe der IAM-Richtliniensprache erstellen?
Antwort: Nein. Sie müssen die Sprache der Cedar-Richtlinien verwenden, um Richtlinien zu verfassen. Cedar wurde entwickelt, um das Berechtigungsmanagement für Anwendungsressourcen von Kunden zu unterstützen, wohingegen die Richtliniensprache AWS Identity and Access Management (IAM) weiterentwickelt wurde, um die Zugriffskontrolle für AWS Ressourcen zu unterstützen.
