Architektur · Geschützte statische Auslieferung
Sicheres statisches WordPress mit CloudFront Signed Cookies
Nutzen Sie Cognito zum Nachweis der Identität, einen Signer zur Ausgabe zeitlich begrenzter CloudFront-Zugriffe und CloudFront zur Durchsetzung geschützter statischer Pfade – ohne WordPress-PHP-Sitzungen wieder einzuführen.
Besucher → geschützter CloudFront-Pfad ↓ kein gültiges Cookie Gatey → Amazon Cognito ↓ akzeptierte Identität Signer-Dienst → Signed Cookies ↓ CloudFront → privates S3-Objekt
Vertrauensgrenzen
Identität, Zugriff auf statische Dateien und API-Autorisierung sind unterschiedliche Kontrollen
Ein Cognito-Token weist eine Identität nach. Ein CloudFront Signed Cookie steuert den Abruf ausgewählter statischer Objekte. Geschützte APIs benötigen weiterhin eine eigene JWT-, IAM- oder serverseitige Autorisierung. Die Trennung dieser Artefakte verhindert, dass ein einzelner Berechtigungsnachweis zur universellen Erlaubnis wird.
Identität: Browser → Cognito → Tokens Statischer Zugriff: akzeptierte Identität → Signer → CloudFront-Cookie → geschützter Pfad API-Aktion: Browser → autorisierte API → Backend-Validierung WordPress bleibt das CMS und setzt Besucherzugriff nicht zur Anfragezeit durch.
Auslieferungsgrenze Private S3-Objekte sollten hinter CloudFront bleiben. Verborgene Links, JavaScript-Sperren oder eine erfolgreiche Anmeldung schützen ein statisches Objekt für sich allein nicht.
Was der Secure-Static-Stack bereitstellt
Die Schutzschicht umfasst Speicher, Edge-Auslieferung, Signatur, Identität und Missbrauchsschutz. Die Tabelle zeigt die Verantwortung jeder Komponente und die durchgesetzte Sicherheitsgrenze.
| Ressource / Fähigkeit | Zweck | Sicherheitsgrenze | Designhinweis |
|---|---|---|---|
| S3-Ursprung | Speichert exportierte statische WordPress-Dateien | Objekte dürfen nicht öffentlich sein, wenn CloudFront die Auslieferungsgrenze bildet | Static Publisher kann Dateien veröffentlichen; der Schutz-Stack steuert den Zugriffspfad. |
| CloudFront-Distribution | Liefert öffentliche und geschützte Pfade am Edge aus | Geschützte Verhaltensweisen erfordern Signed Cookies | Die Liste geschützter Pfade ist Architekturparameter, keine Theme-Einstellung. |
| CloudFront-Schlüsselgruppe / öffentlicher Schlüssel | Ermöglicht CloudFront die Prüfung von Richtliniensignaturen der Signed Cookies | Nur CloudFront kennt den öffentlichen Schlüssel; der private Schlüssel bleibt beim Signer | Für Schlüsselrotation ist ein Runbook erforderlich. |
| Signer-Dienst | Gibt nach Identitätsprüfung Signed Cookies aus | Privater Schlüssel in KMS/SSM oder vergleichbar geschütztem Speicher | Je nach Cookie-Bereich als API Gateway + Lambda oder gleiche Domain/Edge-Logik umsetzbar. |
| Cognito-/Gatey-Integration | Authentifiziert Besucher vor der Cookie-Ausgabe | Identitätstokens bleiben von CloudFront-Cookies getrennt | Die Anmeldeseite kann Teil der statischen Website sein. |
| Routing-, DNS- und Zertifikatsoptionen | Ordnen öffentliche Website und optionale API-/Signer-Domain zu | TLS und Hostnamen bestimmen Cookie-Verhalten | Die Domainstrategie ist ebenso wichtig wie der Lambda-Code. |
| WAF- / Ratenkontrollen | Verringern Missbrauch öffentlicher und Signer-Routen | Edge-Filterung vor der Laufzeitausführung | Besonders nützlich bei öffentlich erreichbaren geschützten Pfaden und Signer-Endpunkten. |
Signed Cookies im Vergleich zu JWTs
Diese Berechtigungsnachweise belegen unterschiedliche Dinge. Der Vergleich verhindert, dass Identitätstokens, temporäre AWS-Zugangsdaten, CloudFront-Zugriffscookies und WordPress-Sitzungen als austauschbar behandelt werden.
| Artefakt | Ausgestellt von | Validiert durch | Am besten geeignet für |
|---|---|---|---|
| Cognito-ID-/Zugriffstoken | Amazon Cognito nach der Authentifizierung | Frontend-Code, API-Gateway-Autorisierer, Backend-Lambda | Nachweis der Nutzeridentität und ihrer identitätsbezogenen Bereiche oder Claims. |
| IAM-Zugangsdaten | Cognito Identity Pool / STS | AWS-Serviceautorisierung | Aufruf IAM-autorisierter APIs oder Dienste aus dem Browser mit temporären, begrenzten Zugangsdaten. |
| CloudFront Signed Cookie | Vertrauenswürdiger Signer mit privatem Schlüssel | CloudFront am Edge | Erlauben oder Verweigern des Abrufs statischer Objekte unter ausgewählten Pfadmustern. |
| WordPress-Anmeldecookie | WordPress-/PHP-Laufzeit | WordPress | Admin- oder klassische dynamische WordPress-Sitzungen, nicht statische Edge-Autorisierung. |
Modell für den Pfadschutz
Pfadklassen sollten vor der Bereitstellung feststehen. Die Tabelle trennt öffentliche Seiten, geschützte statische Objekte, Kontoseiten, APIs und risikoreichere Laufzeitendpunkte, damit jede Oberfläche richtig geschützt wird.
| Pfadklasse | Beispiel | Durchsetzung | Häufiger Fehler |
|---|---|---|---|
| Öffentliche Inhalte | /, /about/, /blog/, Assets | CloudFront-Cache und S3 Origin Access Control | Private JSON-Dateien, Uploads oder generierte Dateien versehentlich unter öffentlichen Präfixen ablegen. |
| Geschützte statische Inhalte | /members/*, /training/*, /client/* | CloudFront Signed Cookies für passende Verhaltensweisen/Pfadmuster | Nur Links verbergen, während statische Objekte direkt abrufbar bleiben. |
| Anmelde- und Kontoseiten | /signin/, /profile/ | Gatey- und Cognito-Browserablauf | Die Anmeldeseite selbst als serverseitigen WordPress-Zustand behandeln. |
| Geschützte APIs | /api/* oder konfigurierte API-Gateway-Domain | Cognito-Autorisierer, JWT-Bereiche oder IAM | Annehmen, ein CloudFront-Cookie autorisiere API-Mutationen. |
| KI- oder Workflow-Endpunkte | /frontend/prompt, /forms/submit | Endpunktspezifische Authentifizierung, WAF, reCAPTCHA und Ratenlimits | Seitenzugriffslogik für risikoreichere Laufzeitaktionen wiederverwenden. |
Wichtige Fehlermodi
Das Schutzmodell lässt sich leichter betreiben, wenn häufige Fehlerzustände klar sind. Die Tabelle ordnet sichtbaren Symptomen wahrscheinliche Ursachen und die zuerst zu prüfende Grenze zu.
| Fehlermodus | Symptom | Wahrscheinliche Ursache | Lösungsrichtung |
|---|---|---|---|
| Geschützte Route führt in Anmeldeschleife | Nutzer meldet sich an und landet wieder bei der Anmeldung | Cookie-Domain-/Pfadfehler, Signer setzt nicht alle CloudFront-Cookies oder Browser lehnt Attribute ab | Set-Cookie-Header, Host-/Domain-Einstellungen sowie SameSite- und Secure-Attribute prüfen. |
| Geschützte Datei ist öffentlich | Private URL öffnet inkognito ohne Anmeldung | S3-Objekt öffentlich, CloudFront-Verhalten ungeschützt oder direkte Ursprungs-URL offengelegt | Öffentlichen S3-Zugriff sperren, CloudFront-Ursprungszugriff erzwingen und Pfadmuster prüfen. |
| 403 trotz gültiger Anmeldung | CloudFront liefert AccessDenied | Abgelaufenes Cookie, falsche Schlüsselpaar-ID, ungültige Signatur oder abweichender Richtlinienpfad | Cookie-Laufzeit, Schlüsselgruppe, privaten Signer-Schlüssel und CloudFront-Ressourcenmuster prüfen. |
| Funktioniert auf einer Subdomain, auf einer anderen nicht | Cookies werden nicht oder falsch gesendet | Domain-Cookie und hostgebundenes Cookie passen nicht oder kollidieren | Ausgabe auf derselben Domain bevorzugen oder Umgebungen mit getrennten Hosts und Schlüsseln isolieren. |
| API funktioniert ohne Seitenzugriff oder umgekehrt | API-Aufruf möglich, statische Seite nicht – oder umgekehrt | Getrennte Authentifizierungsschichten sind unterschiedlich konfiguriert | Statischen Zugriff und API-Autorisierung als getrennte Richtlinien behandeln und dokumentieren. |
Implementierungspfad
Entwerfen Sie geschützte Pfade, bevor Sie sie veröffentlichen
Das Modell für geschützte Inhalte sollte feststehen, bevor das statische Artefakt die Produktion erreicht.
- Öffentliche und geschützte Pfadklassen definieren — Bestimmen Sie, welche URLs und Assets öffentlich bleiben und welche Pfadmuster authentifizierten Zugriff per Signed Cookie erfordern.
- Cognito-gestützte Identität konfigurieren — Nutzen Sie Gatey und den konfigurierten Cognito User Pool für Browser-Anmeldung, MFA, Profil- oder SSO-Anforderungen, ohne WordPress zur Sitzungsautorität des Frontends zu machen.
- Signer und CloudFront-Richtlinie bereitstellen — Bewahren Sie Signaturschlüssel auf der vertrauenswürdigen Signer-Seite auf, begrenzen Sie Cookie-Richtlinien auf die erforderlichen Pfade und wählen Sie zur Schutzdauer passende Cookie-Laufzeiten.
- Zugriff als Auslieferungsproblem testen — Prüfen Sie anonyme Ablehnung, Zugriff nach Anmeldung, Ablauf, direkten S3-Zugriff, Cookie-Domain-Verhalten und API-Autorisierung jeweils getrennt.
Wann Schutz mit Signed Cookies passt
Gut geeignet
Gemeinsame statische Inhalte mit authentifiziertem Zugriff
- Eine statische WordPress-Website hat Mitglieder-, Kunden-, Dokumentations-, Schulungs- oder Portalpfade, die als gemeinsame statische Objekte dargestellt werden können.
- Öffentliche und geschützte Seiten sollen über CloudFront ausgeliefert werden, ohne PHP-Sitzungen wieder einzuführen.
- Cognito verwaltet bereits die Besucheridentität oder soll die Identitätsgrenze der Anwendung bilden.
Anderes Muster wählen
Verwenden Sie ein anderes Autorisierungsmodell, wenn
- Die Seite serverseitig für jeden Nutzer unterschiedlich gerendert werden muss.
- Der Zugriff bei jeder Anfrage sofort widerrufbar sein muss und keine angemessen kurze Signed-Cookie-Laufzeit verwendet werden kann.
- Die Website vollständig dynamisch bleibt und der normale WordPress-Rollen- und Sitzungsschutz bereits ausreicht.
Problemlösungen
Käuferprobleme, die diese Architektur unterstützt
Wie füge ich einer statischen WordPress-Website eine Anmeldung ohne PHP-Sitzungen hinzu?
Nutzen Sie Anmeldung zu statischem WordPress hinzufügen, ohne PHP-Sitzungen zurückzubringen als problemorientierten Einstieg. Der Leitfaden erklärt die Identitätstrennung; diese Architektur erläutert die separate CloudFront-Auslieferungskontrolle.
Soll Cognito WordPress als Identitätsschicht der Anwendung ersetzen?
Lesen Sie Amazon Cognito statt WordPress als Identitätsschicht der Anwendung verwenden, wenn die Anmeldung über WordPress hinaus auf APIs, statische Frontends oder andere Anwendungsoberflächen ausgedehnt werden muss.
Können bestehende SAML- oder OIDC-Identitätsanbieter weiterverwendet werden?
Lesen Sie WordPress mit bestehenden SAML- und OIDC-Identitätsanbietern verbinden, ohne getrennte Anmeldeabläufe zu bauen für den Föderationsfall. Cognito kann Identitätsdrehscheibe bleiben, während die geschützte statische Schicht den resultierenden Anmeldestatus nutzt.
Autorisiert die statische Anmeldung automatisch APIs?
Nein. Signierter statischer Zugriff und geschützte API-Aktionen sind getrennte Grenzen. Das Backend muss JWT, IAM oder einen anderen unterstützten Autorisierungsmechanismus unabhängig validieren.
Beginnen Sie beim Zugriffsproblem
Fügen Sie eine Anmeldung hinzu, ohne die WordPress-Sitzungsschicht zurückzubringen
Nutzen Sie die Secure-Static-Lösung für das Käuferproblem und diese Architektur, wenn ausgewählte Dateien oder Pfade zusätzlich durch CloudFront geschützt werden müssen.