Was ist CDN-Sicherheit?

CDN-Sicherheit umfasst Schutzmechanismen für Inhalte, die über Edge-Knoten ausgeliefert werden, und deren Origin-Server. Zu den gängigen Maßnahmen zählen TLS, signierte Anfragen, Zugriffsregeln, Ratenbegrenzungen und die Abwehr von Denial-of-Service-Angriffen.

Ein CDN sitzt zwischen Zuschauern und dem Origin-Server und muss daher zwei Seiten absichern. Auf der Zuschauerseite terminiert es TLS, kann missbräuchlichen Traffic abfangen oder dessen Rate begrenzen und kann für jede Anfrage einen Berechtigungsnachweis verlangen, meist mit einer signierten URL oder einem signierten Cookie. Der jeweilige Nachweis enthält eine Ablaufzeit und wird am Netzwerkrand geprüft. Amazon CloudFront prüft zuerst die Signatur und die Richtlinie und greift erst danach auf seinen Edge-Cache zu oder leitet die Anfrage weiter; Google Cloud CDN lehnt eine Anfrage mit ungültiger Signatur ab, ohne sie an das Backend zu senden. Eine vorhandene Signatur zu prüfen bedeutet nicht, eine zu verlangen: CloudFront verlangt signierte Anfragen nur für Dateien, die einem Cache-Verhalten mit zugeordnetem Signierer entsprechen, und Cloud CDN blockiert Anfragen ganz ohne Signatur nicht. Dort muss deshalb der Origin-Server solche Anfragen ablehnen. Da das CDN die Signatur selbst prüft, muss das Signieren den Cache nicht fragmentieren: Laut Cloud CDN teilen sich alle gültigen signierten Anfragen für dieselbe Basis-URL einen Cache-Eintrag, während signierte und unsignierte Anfragen nie denselben Eintrag nutzen. Unabhängig davon darf ein gemeinsam genutzter Cache bei einer Anfrage mit dem Header Authorization die Antwort nicht wiederverwenden, sofern diese die Wiederverwendung nicht mit public, s-maxage oder must-revalidate ausdrücklich erlaubt (RFC 9111). Gegenüber dem Origin-Server ist das CDN lediglich ein weiterer HTTP-Client: Der Origin-Server akzeptiert direkte Anfragen, sofern der Zugriff nicht auf das CDN beschränkt ist, und die Verbindung zwischen beiden ist nur verschlüsselt, wenn dies konfiguriert ist. Das Signieren steuert, wer eine Antwort vom Netzwerkrand abrufen darf. Es verschlüsselt die Medien nicht.

Identifiziert eine signierte URL den Zuschauer? Nein. Sie ist eine Form von Zugangsdaten nach dem Bearer-Prinzip: Laut der Dokumentation von Google zu Cloud CDN können alle, die die URL kennen, sie nutzen, bis sie abläuft oder der Signierschlüssel gewechselt wird. Deshalb empfiehlt die Dokumentation kurze Gültigkeitszeiträume und die Weitergabe signierter URLs ausschließlich über HTTPS. Amazon CloudFront kann eine benutzerdefinierte Richtlinie zusätzlich auf eine IP-Adresse oder einen IP-Adressbereich beschränken. Eine kurze Gültigkeitsdauer hat ihren Preis, denn der Ablauf wird bei jeder Anfrage geprüft: Laut der Dokumentation von CloudFront wird ein bereits laufender Download abgeschlossen, ein nach dem Ablaufzeitpunkt fortgesetzter Download schlägt jedoch fehl, ebenso jede spätere Range-Anfrage. Ist die Gültigkeitsdauer kürzer als die Wiedergabesitzung, wird die nächste Anfrage nach Ablauf daher abgelehnt, sofern die Anwendung bis dahin keine neuen Zugangsdaten mit einer späteren Ablaufzeit ausgegeben hat.
Signierte URLs oder signierte Cookies für HLS und DASH? Eine Playlist oder ein Manifest verweist auf viele Segment-URLs, und jede Anfrage muss autorisiert werden. Eine Signatur der Playlist-URL autorisiert daher nicht automatisch die Segmentanfragen. CloudFront und Cloud CDN empfehlen beide signierte Cookies, wenn der Zugriff mehrere Dateien umfasst, und nennen HLS-Video als Beispiel. Bei Cloud CDN autorisiert das Cookie bis zu seinem Ablauf jede URL unter einem Präfix. Manifeste müssen deshalb nicht für jeden Zuschauer umgeschrieben werden, und der Zugriff lässt sich mit kurzen Gültigkeitszeiträumen im Hintergrund erneuern. Jede Segment-URL für jeden Zuschauer zu signieren ist möglich, laut Google aber aufwendig. Signierte URLs bleiben die Wahl für einzelne Dateien und für Clients, die keine Cookies unterstützen. Bei beiden CDNs hat eine signierte URL Vorrang, wenn eine Anfrage beides enthält.
Warum liefert eine korrekt erzeugte signierte URL 403 zurück? Eine dokumentierte Ursache ist, dass die Anfrage nicht mehr mit dem signierten Inhalt übereinstimmt. CloudFront gibt 403 zurück, wenn nach dem Signieren eine Abfragezeichenfolge an die URL angehängt wird. Cloud CDN verlangt seine Signierparameter in einer festen Reihenfolge und ohne Änderungen an der Groß- und Kleinschreibung. Wird die gesamte URL signiert, müssen alle Abfrageparameter, die ein Player, Proxy oder Origin-Server benötigt, bereits vor der Berechnung der Signatur in der URL stehen. Bei Zugangsdaten mit Präfix-Geltungsbereich ist das anders: Die URL-Präfix-Signaturen und signierten Cookies von Cloud CDN decken Abfrageparameter nicht ab. Zusätzliche Parameter werden daher akzeptiert, sind aber nicht vor Änderungen geschützt. Bei CloudFront ist die in der benutzerdefinierten Richtlinie eines signierten Cookies benannte Ressource die URL einschließlich ihrer Abfragezeichenfolge. Ein Platzhalter in dieser Ressource kann auch auf eine hinzugefügte Abfragezeichenfolge passen. Schlüsselrotation ist eine weitere dokumentierte Ursache: Cloud CDN akzeptiert eine URL nicht mehr, sobald ihr Signierschlüssel gelöscht wird. Das Verfahren von CloudFront fügt den neuen öffentlichen Schlüssel hinzu, stellt die Signierung darauf um und entfernt den alten Schlüssel erst, nachdem alle damit signierten URLs oder Cookies abgelaufen sind.
Reicht die Signaturprüfung am Netzwerkrand aus, wenn der Origin-Server öffentlich erreichbar ist? Nein. Laut der Dokumentation von CloudFront ist eine Zugriffsbeschränkung für den Origin-Server nicht erforderlich, damit signierte URLs funktionieren, wird aber empfohlen, weil sich CloudFront sonst mit der eigenen URL des Origin-Servers umgehen lässt. Cloud CDN sagt dasselbe über Speicher-Buckets. Bei einem Bucket bedeutet das, den öffentlichen Lesezugriff zu entfernen und ihn ausschließlich dem CDN zu gewähren: bei CloudFront über eine Zugriffssteuerung für den Origin-Server, bei Cloud Storage für das Dienstkonto von Cloud CDN. Die Zugriffssperre für einen Bucket leert den Cache nicht: Cloud CDN beantwortet eine unsignierte Anfrage aus einem bereits vorhandenen Cache-Eintrag. Ein Eintrag bleibt normalerweise bestehen, bis er abläuft oder aus dem Cache verdrängt wird. Invalidieren Sie daher alle Inhalte, die zwischengespeichert wurden, während der Bucket öffentlich zugänglich war, sobald der Origin-Server unsignierte Anfragen ablehnt. Für andere Origin-Server unterscheiden sich die Verfahren in ihrer Schutzwirkung: Cloudflare stuft einen Anfrage-Header mit geheimem Wert oder eine Freigabeliste von CDN-IP-Bereichen als mäßig sicher ein, eine beidseitige TLS-Authentifizierung (Authenticated Origin Pulls) oder einen Tunnel dagegen als sehr sicher. HTTPS für Zuschauer sichert auch die Verbindung zum Origin-Server nicht automatisch ab. Im Modus „Flexible“ von Cloudflare, der für Zuschauer-HTTPS auf dem Standardport 443 gilt, verbindet sich Cloudflare über unverschlüsseltes HTTP mit dem Origin-Server. CloudFront hat eine separate Protokolleinstellung pro Origin-Server. Ein Header mit einem gemeinsamen geheimen Wert ist daher nur geschützt, wenn auch diese Verbindung verschlüsselt ist.

Konfigurieren Sie diese Schutzmaßnahmen, wenn Medien nur autorisierte Zuschauer erreichen dürfen oder missbräuchlicher Traffic gestoppt werden muss, bevor er den Origin-Server erreicht. Die Fehlerfälle wirken in entgegengesetzte Richtungen: Eine abgelaufene oder nicht mehr zur Anfrage passende Signatur sperrt berechtigte Zuschauer aus. Ein Origin-Server, der weiterhin direkte Anfragen beantwortet, oder ein CDN-Pfad, der Anfragen ohne Signatur bedient, ermöglicht dagegen allen, die Prüfungen zu umgehen. Fordern Sie vor der Veröffentlichung geschützte Dateien ohne Signatur sowohl über das CDN als auch über den eigenen Hostnamen des Origin-Servers an. Beziehen Sie auch Dateien ein, die das CDN zwischengespeichert hat, als sie noch öffentlich zugänglich waren. Jede solche Anfrage muss abgelehnt werden.

Das Smart CDN von Transloadit unterstützt signierte URLs. Ihr Backend berechnet mit dem Auth Secret eine HMAC-SHA256-Signatur über den Workspace-Namen, den Template-Namen, den Dateipfad und die sortierten Abfrageparameter und hängt sie als sig neben einer Ablaufzeit in exp an. Da die Transformationsparameter Teil der signierten Zeichenfolge sind, stimmt eine signierte URL nach einer Änderung ihrer Parameter nicht mehr mit ihrer Signatur überein. Das blockiert geänderte Anfragen nur, wenn unsignierte Anfragen abgelehnt werden. Die verlinkten Seiten beschreiben nicht, wie eine unsignierte Anfrage an dasselbe Template behandelt wird. Testen Sie dies daher in Ihrem eigenen Workspace, bevor Sie sich auf das Signieren verlassen. Die Ablaufzeit begrenzt auch, wie lange ein neu erzeugtes Ergebnis im Cache bleiben darf. Eine kürzere Gültigkeitsdauer für exp schränkt den Zugriff daher stärker ein, verringert aber die Wiederverwendung des Caches.

exp wird in Millisekunden seit der Unix-Epoche angegeben. Die Dokumentation bezeichnet den Parameter als optional, empfiehlt aber dringend, ihn zu setzen. Signaturen müssen auf dem Server erzeugt werden, da sie das Auth Secret verwenden, und der Auth Key muss für die Nutzung von Smart CDN freigeschaltet sein. Transloadit beschreibt Smart CDN als Transformations- und Auslieferungsschicht, die die Autorisierungsrichtlinie Ihrer Anwendung nicht ersetzt: Ihr Code entscheidet weiterhin, welcher Zuschauer eine signierte URL erhält.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was ist CDN-Sicherheit?

So funktioniert CDN-Sicherheit

Wichtige Fakten

Wann CDN-Sicherheit wichtig ist

So unterstützt Transloadit die CDN-Sicherheit

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline