Sicherung von Workloads mit öffentlichen Endpunkten - AWS Lambda

Sicherung von Workloads mit öffentlichen Endpunkten

Für Workloads, die öffentlich zugänglich sind, bietet AWS eine Reihe von Features und Diensten, mit denen bestimmte Risiken gemindert werden 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-basierten Anwendungen können Sie so jeden Aufruf an jeden 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ätsanbieterdienstes ist es wichtig, professionelle Tools zum Schutz Ihrer Anwendung zu verwenden. Es wird nicht empfohlen, eigene Dienste für die Authentifizierung oder Autorisierung zu schreiben. Schwachstellen 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 mit 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-Angriffen (DoS) 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 auf Client-Ebene, 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 kann eine Webanwendung Benutzern, die nicht angemeldet sind, eine Liste von Einzelhandelsgeschäften von Kunden aus einer DynamoDB-Tabelle bereitstellen. Diese Anfrage kann von einer Frontend-Webanwendung oder von einer anderen Quelle stammen, die den URL-Endpunkt aufruft. In diesem Diagramm werden drei Lösungen verglichen:

Sicherheitsoperationen, Abbildung 5
  1. Diese nicht authentifizierte API kann von jedem Benutzer im Internet aufgerufen werden. Bei einem Denial-of-Service-Angriff ist es möglich, die API-Drosselungsgrenzen, die Lambda-Gleichzeitigkeit oder die von DynamoDB bereitgestellte Lesekapazität für eine zugrunde liegende Tabelle auszuschöpfen.

  2. Eine CloudFront-Verteilung vor dem API-Endpunkt mit einer geeigneten Time-to-Live (TTL)-Konfiguration würde den größten Teil des Datenverkehrs bei einem DoS-Angriff absorbieren, ohne die zugrunde liegende Lösung für das Abrufen der Daten zu ändern.

  3. Alternativ könnte die CloudFront-Distribution für statische Daten, die sich selten ändern, die Daten aus einem Amazon-S3-Bucket bereitstellen.