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.

Sicherung von Workloads mit öffentlichen Endpunkten

AWS Bietet für Workloads, die öffentlich zugänglich sind, eine Reihe von Funktionen und Diensten, die zur Minderung bestimmter Risiken beitragen können. Dieser Abschnitt behandelt die Authentifizierung und Autorisierung von Anwendungsbenutzern und den Schutz von API-Endpunkten.

Authentifizierung und Autorisierung

Authentifizierung bezieht sich auf Identität und Autorisierung bezieht sich auf Aktionen. Verwenden Sie die Authentifizierung, um zu kontrollieren, wer eine Lambda-Funktion aufrufen kann und verwenden Sie dann die Autorisierung, um zu kontrollieren, was sie tun können. Für viele Anwendungen ist IAM ausreichend, um beide Kontrollmechanismen zu verwalten.

Für Anwendungen mit externen Benutzern, wie z. B. Web- oder Mobilanwendungen, ist es üblich, JSON-Web-Tokens (JWTs) zur Verwaltung der Authentifizierung und Autorisierung zu verwenden. Im Gegensatz zur herkömmlichen, serverbasierten Passwortverwaltung werden JWTs bei jeder Anfrage vom Client übergeben. Sie sind eine kryptografisch sichere Methode, um Identität und Ansprüche anhand der vom Client übermittelten Daten zu überprüfen. Bei Lambda-based Anwendungen können Sie jeden Aufruf an jedem API-Endpunkt sichern, ohne sich bei der Authentifizierung auf einen zentralen Server verlassen zu müssen.

Sie können JWTs mit Amazon Cognito implementieren, einem Benutzerverzeichnisdienst, der Registrierung, Authentifizierung, Kontowiederherstellung und andere gängige Kontoverwaltungsvorgänge abwickeln kann. Amplify Framework bietet Bibliotheken, die die Integration dieses Dienstes in Ihre Frontend-Anwendung vereinfachen. Sie können auch Partnerdienste von Drittanbietern wie Auth0 erwägen.

Angesichts der wichtigen Sicherheitsrolle eines Identitätsanbieter-Dienstes ist es wichtig, professionelle Tools zum Schutz Ihrer Anwendung zu verwenden. Es wird nicht empfohlen, eigene Dienste für die Authentifizierung oder Autorisierung zu entwickeln. Alle Sicherheitslücken in benutzerdefinierten Bibliotheken können erhebliche Auswirkungen auf die Sicherheit Ihres Workloads und seiner Daten haben.

API-Endpunkte schützen

Für Serverless-Anwendungen ist die Verwendung von Amazon API Gateway die bevorzugte Methode, eine Backend-Anwendung öffentlich bereitzustellen. Dies kann Ihnen helfen, eine API vor böswilligen Benutzern oder Datenverkehrsspitzen zu schützen.

API Gateway bietet zwei Endpunkttypen für Serverless-Entwickler: REST-APIs und HTTP-APIs. Beide unterstützen die Autorisierung mithilfe von AWS Lambda IAM oder Amazon Cognito. Bei der Verwendung von IAM oder Amazon Cognito werden eingehende Anfragen ausgewertet. Fehlt ein erforderliches Token oder enthält es eine ungültige Authentifizierung, wird die Anfrage abgelehnt. Diese Anfragen werden Ihnen nicht in Rechnung gestellt und sie werden auch nicht auf die Drosselungskontingente angerechnet.

Auf nicht authentifizierte API-Routen kann jeder im öffentlichen Internet zugreifen. Es wird daher empfohlen, die Verwendung nicht authentifizierter APIs einzuschränken. Wenn Sie nicht authentifizierte APIs verwenden müssen, ist es wichtig, diese vor häufigen Risiken wie Denial-of-Service (DoS) -Angriffen zu schützen. Die Anwendung von AWS WAF auf diese APIs kann dazu beitragen, Ihre Anwendung vor SQL-Injektion- und Cross-Site-Scripting (XSS)-Angriffen zu schützen. API Gateway implementiert auch Drosselung auf AWS Kontoebene und pro Client, wenn API-Schlüssel verwendet werden.

In vielen Fällen kann die Funktionalität einer nicht authentifizierten API mit einem alternativen Ansatz erreicht werden. Beispielsweise könnte eine Webanwendung Benutzern, die nicht angemeldet sind, eine Liste der Einzelhandelsgeschäfte von Kunden aus einer DynamoDB-Tabelle bereitstellen. Diese Anforderung kann von einer Frontend-Webanwendung oder von einer anderen Quelle stammen, die den URL-Endpunkt aufruft. In diesem Diagramm werden drei Lösungen verglichen: