Architecture · Livraison statique protégée
WordPress statique sécurisé avec des cookies signés CloudFront
Utilisez Cognito pour prouver l’identité, un service de signature pour émettre un accès CloudFront limité dans le temps, et CloudFront pour imposer la protection des chemins statiques sans rétablir les sessions PHP de WordPress.
Visiteur → chemin CloudFront protégé ↓ aucun cookie valide Gatey → Amazon Cognito ↓ identité acceptée Service de signature → cookies signés ↓ CloudFront → objet S3 privé
Limites de confiance
L’identité, l’accès aux fichiers statiques et l’autorisation d’API sont des contrôles distincts
Un jeton Cognito prouve une identité. Un cookie signé CloudFront contrôle la récupération de certains objets statiques. Les API protégées ont toujours besoin de leur propre autorisation JWT, IAM ou côté service. La séparation de ces artefacts évite qu’un identifiant devienne une autorisation universelle.
Identité : navigateur → Cognito → jetons Accès statique : identité acceptée → signature → cookie CloudFront → chemin protégé Action d’API : navigateur → API autorisée → validation backend WordPress reste le CMS et n’applique pas l’accès visiteur lors de chaque requête.
Limite de livraison Les objets S3 privés doivent rester derrière CloudFront. Masquer les liens, bloquer avec JavaScript ou réussir une connexion ne protège pas à lui seul un objet statique.
Ce que provisionne la pile statique sécurisée
La couche de protection couvre le stockage, la livraison en périphérie, la signature, l’identité et les contrôles anti-abus. Le tableau indique le rôle de chaque composant et la limite de sécurité appliquée.
| Ressource / capacité | Objectif | Limite de sécurité | Note de conception |
|---|---|---|---|
| Origine S3 | Stocke les fichiers WordPress statiques exportés | Les objets ne doivent pas être publics lorsque CloudFront constitue la limite de livraison | Static Publisher peut publier les fichiers ; la pile de protection contrôle le chemin d’accès. |
| Distribution CloudFront | Sert les chemins publics et protégés en périphérie | Les comportements protégés exigent des cookies signés | La liste des chemins protégés est un paramètre d’architecture, pas un réglage de thème. |
| Groupe de clés / clé publique CloudFront | Permet à CloudFront de valider les signatures de politique des cookies | Seul CloudFront voit la clé publique ; la clé privée reste côté signature | La rotation des clés nécessite une procédure. |
| Service de signature | Émet des cookies signés après contrôle d’identité | Clé privée dans KMS/SSM ou stockage protégé équivalent | API Gateway + Lambda ou logique en périphérie sur le même domaine selon la portée requise. |
| Intégration Cognito/Gatey | Authentifie le visiteur avant l’émission des cookies | Les jetons d’identité restent distincts des cookies CloudFront | La page de connexion peut faire partie du site statique. |
| Options de routage, DNS et certificat | Associent le site public et le domaine facultatif de l’API/signature | TLS et les noms d’hôte définissent le comportement des cookies | La stratégie de domaine compte autant que le code Lambda. |
| WAF / contrôles de débit | Réduisent les abus sur les routes publiques et de signature | Filtrage en périphérie avant l’exécution | Particulièrement utile lorsque les chemins protégés et les points de signature sont publics. |
Cookies signés et JWT
Ces identifiants prouvent des éléments différents. La comparaison évite de traiter jetons d’identité, identifiants AWS temporaires, cookies d’accès CloudFront et sessions WordPress comme des autorisations interchangeables.
| Artefact | Émis par | Validé par | Usage recommandé |
|---|---|---|---|
| Jeton d’ID/d’accès Cognito | Amazon Cognito après authentification | Code frontend, mécanisme d’autorisation API Gateway, Lambda backend | Prouver l’identité de l’utilisateur et ses portées ou claims associés. |
| Identifiants IAM | Cognito Identity Pool / STS | Autorisation des services AWS | Appeler depuis le navigateur des API ou services autorisés par IAM avec des identifiants temporaires limités. |
| Cookie signé CloudFront | Service de signature de confiance détenant la clé privée | CloudFront en périphérie | Autoriser ou refuser la récupération d’objets statiques sous certains motifs de chemin. |
| Cookie de connexion WordPress | Environnement WordPress/PHP | WordPress | Sessions d’administration ou WordPress dynamiques classiques, pas autorisation statique en périphérie. |
Modèle de protection des chemins
Les classes de chemin doivent être explicites avant le déploiement. Le tableau distingue pages publiques, objets statiques protégés, pages de compte, API et points d’exécution à risque pour appliquer le bon contrôle.
| Classe de chemin | Exemple | Application | Erreur fréquente |
|---|---|---|---|
| Contenu public | /, /about/, /blog/, ressources | Cache CloudFront et contrôle d’accès à l’origine S3 | Placer par erreur du JSON privé, des chargements ou des fichiers générés sous des préfixes publics. |
| Contenu statique protégé | /members/*, /training/*, /client/* | Cookies signés CloudFront sur les comportements ou motifs correspondants | Masquer uniquement les liens alors que les objets restent directement récupérables. |
| Pages de connexion et de compte | /signin/, /profile/ | Flux navigateur Gatey + Cognito | Traiter la page de connexion comme un état WordPress côté serveur. |
| API protégées | /api/* ou domaine API Gateway configuré | Mécanisme Cognito, portées JWT ou IAM | Supposer qu’un cookie CloudFront autorise les mutations d’API. |
| Points d’IA ou de workflow | /frontend/prompt, /forms/submit | Authentification propre au point, WAF, reCAPTCHA et limites de débit | Réutiliser la logique d’accès aux pages pour des actions d’exécution plus risquées. |
Modes de défaillance importants
Le modèle est plus simple à exploiter lorsque les défaillances courantes sont explicites. Le tableau associe symptômes, causes probables et limite à inspecter en premier.
| Mode de défaillance | Symptôme | Cause probable | Piste de correction |
|---|---|---|---|
| Boucle vers la connexion | L’utilisateur se connecte mais revient à la page de connexion | Domaine/chemin de cookie incorrect, cookies CloudFront incomplets ou attributs refusés par le navigateur | Vérifier les en-têtes Set-Cookie, les réglages d’hôte/domaine et les attributs SameSite/Secure. |
| Fichier protégé public | L’URL privée s’ouvre en navigation privée sans connexion | Objet S3 public, comportement CloudFront non protégé ou URL d’origine directe exposée | Bloquer l’accès public S3, imposer l’accès d’origine CloudFront et vérifier les motifs de chemin. |
| 403 après une connexion valide | CloudFront renvoie AccessDenied | Cookie expiré, ID de paire de clés erroné, signature invalide ou chemin de politique non concordant | Contrôler la durée, le groupe de clés, la clé privée et le motif de ressource CloudFront. |
| Fonctionne sur un sous-domaine, échoue sur un autre | Cookies absents ou incorrects | Écart entre cookie de domaine et cookie lié à l’hôte, ou collision entre sites | Privilégier l’émission sur le même domaine ou isoler les environnements avec hôtes et clés distincts. |
| API accessible sans la page, ou inversement | L’utilisateur appelle l’API sans voir la page statique, ou l’inverse | Couches d’authentification séparées configurées différemment | Traiter et documenter l’accès statique et l’autorisation d’API comme deux politiques distinctes. |
Parcours d’implémentation
Concevez les chemins protégés avant de les publier
Le modèle de contenu protégé doit être explicite avant que l’artefact statique n’arrive en production.
- Définir les classes de chemins publics et protégés — Identifiez les URL et ressources qui restent publiques et les motifs de chemin qui exigent un accès authentifié par cookie signé.
- Configurer l’identité adossée à Cognito — Utilisez Gatey et le Cognito User Pool configuré pour la connexion, la MFA, le profil ou le SSO dans le navigateur, sans faire de WordPress l’autorité de session du frontend.
- Déployer le service de signature et la politique CloudFront — Conservez les clés de signature du côté de confiance, limitez les politiques de cookies aux chemins requis et choisissez une durée adaptée au contenu protégé.
- Tester l’accès comme un problème de livraison — Vérifiez séparément le refus anonyme, l’accès après connexion, l’expiration, l’accès direct à S3, le comportement du domaine des cookies et l’autorisation d’API.
Quand la protection par cookies signés convient
Bon choix
Contenu statique partagé avec accès authentifié
- Un site WordPress statique comporte des chemins membres, clients, documentation, formation ou portail pouvant être représentés par des objets statiques partagés.
- Vous souhaitez livrer pages publiques et protégées avec CloudFront sans réintroduire de sessions PHP.
- Cognito gère déjà l’identité des visiteurs ou doit constituer la limite d’identité de l’application.
Choisir un autre modèle
Utilisez un autre modèle d’autorisation lorsque
- La page elle-même doit être rendue différemment pour chaque utilisateur côté serveur.
- L’accès doit pouvoir être révoqué immédiatement à chaque requête et ne peut pas reposer sur une durée de cookie signé suffisamment courte.
- Le site reste entièrement dynamique et la protection ordinaire des rôles et sessions WordPress répond déjà au besoin.
Guides pratiques
Problèmes d’acheteurs couverts par cette architecture
Comment ajouter une connexion à WordPress statique sans sessions PHP ?
Utilisez Ajouter une connexion à WordPress statique sans réintroduire les sessions PHP comme point d’entrée centré sur le problème. Le guide explique la séparation de l’identité ; cette architecture détaille le contrôle de livraison CloudFront distinct.
Cognito doit-il remplacer WordPress comme couche d’identité de l’application ?
Consultez Utiliser Amazon Cognito plutôt que WordPress comme couche d’identité de l’application lorsque la connexion doit s’étendre aux API, aux frontends statiques ou à d’autres surfaces.
Les fournisseurs d’identité SAML ou OIDC existants peuvent-ils encore être utilisés ?
Consultez Connecter WordPress aux fournisseurs d’identité SAML et OIDC existants sans créer de flux de connexion séparés pour la fédération. Cognito peut rester le centre d’identité tandis que la couche statique protégée consomme l’état authentifié obtenu.
La connexion statique autorise-t-elle automatiquement les API ?
Non. L’accès statique signé et les actions d’API protégées sont deux limites distinctes. Le backend doit valider indépendamment JWT, IAM ou un autre mécanisme d’autorisation pris en charge.
Commencez par le problème d’accès
Ajoutez la connexion sans réintroduire la couche de session WordPress
Utilisez la solution de WordPress statique sécurisé pour le problème d’acheteur, puis cette architecture si certains fichiers ou chemins doivent aussi être protégés par CloudFront.