Übersicht

Für Webanwendungen, die vertrauliche Inhalte preisgeben, sind Zugriffskontrollmechanismen erforderlich, die gewährleisten, dass nur autorisierte Benutzer auf diese Inhalte zugreifen können. Beispiele hierfür sind SPA-basierte interne Portale, die eine Benutzerauthentifizierung erfordern, und das Herunterladen vertraulicher Dateien. Die Zugriffskontrolle kann je nach Anwendungsfall auf der Beigesprungene oder auf CDN-Ebene implementiert werden.

Häufige Anwendungsfälle

Ursprungsbasierte Autorisierung

Wenn Sie CloudFront als Reverse-Proxy ohne aktiviertes Caching verwenden (d. h. Caching deaktiviert ist in der Verwalteten Caching-Richtlinie konfiguriert), können Sie einfach die nativen Autorisierungsfunktionen Ihres Ursprungs verwenden (z. B. API Gateway). Damit dies ordnungsgemäß funktioniert, konfigurieren Sie die Richtlinie für Ursprungsanfragen so, dass das Anfrageattribut mit den Autorisierungsinformationen, z. B. der Autorisierungs-Header, an Ihren Ursprung weitergeleitet wird.

Wenn Ihre Inhalte zwischengespeichert werden können, Sie es aber vorziehen, die Autorisierung weiterhin in Ihrer eigenen Infrastruktur zu verwalten, sollten Sie die Integration von CloudFront in Ihre Autorisierungsserver mit Lambda@Edge in Betracht ziehen. Mit dieser Architektur profitieren Sie vom CloudFront-Caching. Weitere Informationen über diese Implementierung finden Sie in diesem Blog.

Wenn Sie die Autorisierungslogik von Ihren Webanwendungskomponenten auf CloudFront auslagern möchten, sollten Sie die folgenden Abschnitte berücksichtigen.

CloudFront-basierte Autorisierung mit signierten Token

CloudFront bietet einen nativen Autorisierungsmechanismus, der signierte URLs oder signierte Cookies verwendet. Um diese Methode zu verwenden, folgen Sie den in der Dokumentation erläuterten Schritten:

  • Konfigurieren Sie einen asymmetrischen Verschlüsselungsschlüssel für die Signierung von Token unter Verwendung von Signaturschlüsselgruppen.
  • Fügen Sie in Ihrem Authentifizierungsworkflow die erforderlichen Tokenfelder in den Abfrageparametern oder Cookies der bereitgestellten Ressourcen-URL hinzu. Das Token enthält ein Ablaufdatum, die Signaturschlüssel-ID, die Richtlinie und eine Signatur. Mit der Richtlinie können Sie die Bedingungen definieren, die eine Anforderung erfüllen muss, um den Token-Validierungstest durch CloudFront zu bestehen. Sie können beispielsweise eine benutzerdefinierte Richtlinie verwenden, um ein Token zu generieren, das für alle URLs gültig ist, die mit einem bestimmten Pfad beginnen.
  • Aktivieren Sie die Signatur im Cache-Verhalten von CloudFront, die für private Inhalte verwendet wird. Ab diesem Zeitpunkt werden alle Anfragen von CloudFront zur Token-Validierung kontrolliert. Nicht autorisierte Anfragen erhalten einen 403-Fehler, der mithilfe der Funktion „Benutzerdefinierte Fehlerseite“ von CloudFront angepasst werden kann.

Verwenden Sie das aws-sdk, um ein gültiges Token mit Ihrem privaten Schlüssel zu generieren. Zur Veranschaulichung generiert der folgende Code in Nodejs eine von CloudFront signierte URL für ein bestimmtes Objekt edge-image.jpg, die zwei Stunden lang gültig ist.

const AWS = require('aws-sdk');

// It's recommended not to store signing keys in code. The below is just an illustrative example.
const cloudfrontAccessKeyId = 'K25ULYFPSTHQP9';
const cloudFrontPrivateKey = '-----BEGIN RSA PRIVATE KEY-----\nMIIEowIBAAKCAQ....2gvvIH\n-----END RSA PRIVATE KEY-----';

const signer = new AWS.CloudFront.Signer(cloudfrontAccessKeyId, cloudFrontPrivateKey);
const signedUrl = signer.getSignedUrl({
  url: 'https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg',
  expires: Math.floor((Date.now() + 2 * 60 * 60 * 1000) / 1000),
});
console.log(signedUrl);

Die Ausgabe des obigen Codeausschnitts sieht wie folgt aus:

https://d3jqlnxofenq2x.cloudfront.net/edge-image.jpg?Expires=1660317158&Key-Pair-Id=K25ULYFP9THQP9&Signature=agW2XF9S5AW0YCc6c7pkCwccJmxaIAWFO~uXn9KtOXtz4JTY7eRF07opJiseGXJxzlMeD4V6FUH8I-gOH~Gvafa16RFV9IryxCyzL9mIYt-XbDKMrY0ONzTWUk2x16AKDK27VoUwEPiI9dpPXMp7f4MsrpKA-u6huZCsulh0~aAYN~x25uNoDO-WgZpfkKFeKc910u4PVnEaKLlZlpuJ0hqWUjMVPes9DfA~msToJeyjrVzLi2R8O8LuuYHsAMAHXr7E9qB8tAoDWz24CurCirxc6sB45Zc-oK9JigX0L4~F~F1TE9i39ysmQF4UrOyu0bp7MKGSDBwLE1P2C3gWNw__

CloudFront-basierte Autorisierung mithilfe von CloudFront-Funktionen

Wenn das native signierte Token von CloudFront Ihre Anforderungen an die Autorisierung nicht erfüllt, können Sie eine benutzerdefinierte Autorisierungslogik mit Edge-Funktionen erstellen. Sie können zum Beispiel eine andere Verschlüsselung für das Signieren von Token verwenden, wie z. B. die symmetrische Verschlüsselung, oder Sie können nicht standardmäßige Attribute in die Signatur aufnehmen, wie z. B. den User-Agent-Header, oder Sie können eine bedingte Tokenisierungslogik basierend auf dem Benutzernetzwerk implementieren. Die folgenden benutzerdefinierten Implementierungen veranschaulichen einige der Möglichkeiten mit Edge-Funktionen:

  • CloudFront-Funktionen zur Validierung von JWT-basierten Token. Anmerkung: Die CloudFront-Funktionen lassen derzeit keine externen Netzwerkaufrufe zu, so dass die Signaturschlüssel im Funktionscode gespeichert werden müssen. Um das Risiko der Speicherung von Signaturschlüsseln im CloudFront-Funktionscode zu verringern, konfigurieren Sie den Schlüssel nicht manuell im Code, sondern verwenden Sie eine Automatisierung, die die Schlüssel rotiert und den Funktionscode generiert, bevor Sie ihn in CloudFront bereitstellen. Auf diese Weise besteht keine Gefahr, dass die Schlüssel in öffentliche Repositorys wie Github hochgeladen werden.
  • AWS-Lösung: Sichere Medienbereitstellung am Edge. Diese AWS-Lösung verwendet die CloudFront-Funktion, um einen benutzerdefinierten Autorisierungsmechanismus zu implementieren, der an Videostreaming angepasst ist.
  • Verwenden von OpenID Connect zur Authentifizierung einer auf S3 gehosteten Einzelseitenanwendung. Die Lösung verwendet AWS Secrets Manager zum Speichern von Signaturschlüsseln und kann mit einem externen Identitätsanbieter (IDP) wie Cognito oder Okta zusammenarbeiten. Diese Implementierung wurde vor dem Start der CloudFront-Funktionen veröffentlicht, weshalb sie vollständig auf Lambda@Edge basiert. Sie kann für die Verwendung von CloudFront-Funktionen für den Autorisierungsteil und Lambda@Edge für die Integration mit den IDPs optimiert werden.

Ressourcen

War diese Seite hilfreich?

 Feedback