Arquitectura · Entrega estática protegida
WordPress estático seguro con cookies firmadas de CloudFront
Utilice Cognito para demostrar la identidad, un firmante para emitir acceso temporal de CloudFront y CloudFront para proteger rutas estáticas sin restablecer sesiones PHP de WordPress.
Visitante → ruta protegida de CloudFront ↓ sin cookie válida Gatey → Amazon Cognito ↓ identidad aceptada Servicio firmante → cookies firmadas ↓ CloudFront → objeto S3 privado
Límites de confianza
La identidad, el acceso a archivos estáticos y la autorización de API son controles diferentes
Un token de Cognito demuestra una identidad. Una cookie firmada de CloudFront controla la recuperación de objetos estáticos seleccionados. Las API protegidas siguen necesitando su propia autorización JWT, IAM o del lado del servicio. Mantener separados estos artefactos evita convertir una credencial en un permiso universal.
Identidad: navegador → Cognito → tokens Acceso estático: identidad aceptada → firmante → cookie de CloudFront → ruta protegida Acción de API: navegador → API autorizada → validación del backend WordPress sigue siendo el CMS y no aplica el acceso de visitantes al recibir cada solicitud.
Límite de entrega Los objetos S3 privados deben permanecer detrás de CloudFront. Ocultar enlaces, bloquear con JavaScript o completar el inicio de sesión no protege por sí solo un objeto estático.
Qué aprovisiona el stack estático seguro
La capa de protección abarca almacenamiento, entrega en el edge, firma, identidad y controles de abuso. La tabla muestra qué posee cada componente y qué límite de seguridad aplica.
| Recurso / capacidad | Finalidad | Límite de seguridad | Nota de diseño |
|---|---|---|---|
| Origen S3 | Almacena archivos estáticos exportados de WordPress | Los objetos no deben ser públicos cuando CloudFront es el límite de entrega | Static Publisher puede publicar archivos; el stack de protección controla la ruta de acceso. |
| Distribución de CloudFront | Sirve rutas públicas y protegidas en el edge | Los comportamientos protegidos exigen cookies firmadas | La lista de rutas protegidas es un parámetro de arquitectura, no un ajuste del tema. |
| Grupo de claves / clave pública de CloudFront | Permite a CloudFront validar firmas de políticas de cookies | Solo CloudFront ve la clave pública; la privada permanece en el lado firmante | La rotación de claves necesita un procedimiento. |
| Servicio firmante | Emite cookies firmadas tras comprobar la identidad | Clave privada en KMS/SSM o almacenamiento protegido equivalente | Puede usar API Gateway + Lambda o lógica del edge en el mismo dominio según el ámbito de la cookie. |
| Integración Cognito/Gatey | Autentica al visitante antes de emitir cookies | Los tokens de identidad permanecen separados de las cookies de CloudFront | La página de inicio de sesión puede formar parte del sitio estático. |
| Opciones de ruta, DNS y certificado | Asignan el sitio público y un dominio opcional de API/firmante | TLS y los nombres de host definen el comportamiento de las cookies | La estrategia de dominios importa tanto como el código Lambda. |
| WAF / controles de tasa | Reducen abusos en rutas públicas y de firma | Filtrado en el edge antes de ejecutar el runtime | Especialmente útil cuando las rutas protegidas y los endpoints de firma son públicos. |
Cookies firmadas frente a JWT
Estas credenciales demuestran cosas distintas. La comparación evita tratar tokens de identidad, credenciales temporales de AWS, cookies de acceso de CloudFront y sesiones de WordPress como artefactos intercambiables.
| Artefacto | Emitido por | Validado por | Uso idóneo |
|---|---|---|---|
| Token de ID/acceso de Cognito | Amazon Cognito tras la autenticación | Código frontend, autorizador de API Gateway, Lambda del backend | Demostrar quién es el usuario y qué ámbitos o claims de identidad posee. |
| Credenciales IAM | Cognito Identity Pool / STS | Autorización de servicios AWS | Llamar desde el navegador a API o servicios autorizados por IAM con credenciales temporales limitadas. |
| Cookie firmada de CloudFront | Firmante de confianza propietario de la clave privada | CloudFront en el edge | Permitir o denegar la recuperación de objetos estáticos bajo patrones de ruta seleccionados. |
| Cookie de inicio de sesión de WordPress | Runtime de WordPress/PHP | WordPress | Sesiones administrativas o dinámicas tradicionales de WordPress, no autorización estática en el edge. |
Modelo de protección de rutas
Las clases de ruta deben ser explícitas antes del despliegue. La tabla distingue páginas públicas, objetos estáticos protegidos, páginas de cuenta, API y endpoints de mayor riesgo para aplicar el control correcto.
| Clase de ruta | Ejemplo | Aplicación | Error habitual |
|---|---|---|---|
| Contenido público | /, /about/, /blog/, recursos | Caché de CloudFront y control de acceso al origen S3 | Colocar por error JSON privado, cargas o archivos generados bajo prefijos públicos. |
| Contenido estático protegido | /members/*, /training/*, /client/* | Cookies firmadas de CloudFront en los comportamientos o patrones coincidentes | Ocultar solo los enlaces y dejar los objetos estáticos accesibles directamente. |
| Páginas de inicio de sesión y cuenta | /signin/, /profile/ | Flujo de navegador de Gatey + Cognito | Tratar la propia página de acceso como estado de WordPress del lado del servidor. |
| API protegidas | /api/* o dominio configurado de API Gateway | Autorizador de Cognito, ámbitos JWT o IAM | Suponer que una cookie de CloudFront autoriza mutaciones de API. |
| Endpoints de IA o workflow | /frontend/prompt, /forms/submit | Autenticación específica, WAF, reCAPTCHA y límites de tasa | Reutilizar la lógica de acceso a páginas para acciones de ejecución de mayor riesgo. |
Modos de fallo importantes
El modelo es más fácil de operar cuando los estados de fallo habituales son explícitos. La tabla relaciona síntomas visibles con causas probables y el límite que debe inspeccionarse primero.
| Modo de fallo | Síntoma | Causa probable | Dirección de corrección |
|---|---|---|---|
| La ruta protegida vuelve al inicio de sesión | El usuario inicia sesión pero regresa a la pantalla de acceso | Dominio o ruta de cookie incorrectos, faltan cookies de CloudFront o el navegador rechaza atributos | Revisar cabeceras Set-Cookie, ajustes de host/dominio y atributos SameSite/Secure. |
| El archivo protegido es público | La URL privada se abre en incógnito sin iniciar sesión | Objeto S3 público, comportamiento de CloudFront sin protección u origen directo expuesto | Bloquear acceso público de S3, imponer acceso de origen de CloudFront y verificar patrones. |
| 403 tras un inicio de sesión válido | CloudFront devuelve AccessDenied | Cookie caducada, ID de par de claves incorrecto, firma no válida o patrón de política distinto | Comprobar duración, grupo de claves, clave privada y patrón de recurso de CloudFront. |
| Funciona en un subdominio y falla en otro | Las cookies no se envían o se envían las equivocadas | Diferencia entre cookie de dominio y de host o colisión entre sitios | Tender a la emisión en el mismo dominio o aislar entornos con hosts y claves distintos. |
| La API funciona sin acceso a página o al contrario | El usuario llama a la API pero no ve la página, o viceversa | Capas de autenticación separadas configuradas de forma distinta | Tratar y documentar el acceso estático y la autorización de API como políticas separadas. |
Ruta de implementación
Diseñe las rutas protegidas antes de publicarlas
El modelo de contenido protegido debe quedar explícito antes de que el artefacto estático llegue a producción.
- Definir clases de rutas públicas y protegidas — Identifique qué URL y recursos seguirán siendo públicos y qué patrones de ruta exigirán acceso autenticado mediante cookies firmadas.
- Configurar identidad respaldada por Cognito — Use Gatey y el Cognito User Pool configurado para el inicio de sesión, MFA, perfiles o SSO en el navegador, sin convertir WordPress en autoridad de sesión del frontend.
- Desplegar el firmante y la política de CloudFront — Mantenga el material de firma en el lado de confianza, limite las políticas de cookies a las rutas necesarias y use tiempos de vida adecuados para el contenido protegido.
- Probar el acceso como un problema de entrega — Compruebe por separado la denegación anónima, el acceso tras iniciar sesión, la caducidad, el acceso directo a S3, el dominio de cookies y la autorización de API.
Cuándo encaja la protección con cookies firmadas
Buena opción
Contenido estático compartido con acceso autenticado
- Un sitio WordPress estático tiene rutas de miembros, clientes, documentación, formación o portal que pueden representarse como objetos estáticos compartidos.
- Desea entregar páginas públicas y protegidas mediante CloudFront sin volver a introducir sesiones PHP.
- Cognito ya controla la identidad de visitantes o será el límite de identidad de la aplicación.
Elegir otro patrón
Use otro modelo de autorización cuando
- La propia página deba renderizarse de forma distinta para cada usuario en el servidor.
- El acceso deba revocarse inmediatamente en cada solicitud y no pueda depender de una duración adecuadamente corta de la cookie firmada.
- El sitio siga siendo totalmente dinámico y la protección normal de roles y sesiones de WordPress ya satisfaga el requisito.
Guías de problemas
Problemas del comprador que admite esta arquitectura
¿Cómo añado inicio de sesión a WordPress estático sin sesiones PHP?
Use Añada inicio de sesión a WordPress estático sin recuperar las sesiones PHP como punto de entrada centrado en el problema. Explica la separación de identidad; esta arquitectura explica el control de entrega independiente de CloudFront.
¿Debe Cognito sustituir a WordPress como capa de identidad de la aplicación?
Consulte Use Amazon Cognito en lugar de WordPress como capa de identidad de la aplicación cuando el inicio de sesión deba extenderse a API, frontends estáticos u otras superficies.
¿Pueden seguir utilizándose proveedores de identidad SAML u OIDC existentes?
Consulte Conecte WordPress a proveedores de identidad SAML y OIDC existentes sin crear flujos de inicio de sesión separados para la federación. Cognito puede seguir siendo el centro de identidad y la capa estática protegida consumir el estado autenticado resultante.
¿El inicio de sesión estático autoriza automáticamente las API?
No. El acceso estático firmado y las acciones de API protegidas son límites distintos. El backend debe validar de forma independiente JWT, IAM u otro mecanismo de autorización compatible.
Empiece por el problema de acceso
Añada inicio de sesión sin recuperar la capa de sesiones de WordPress
Use la solución de WordPress estático seguro para el problema del comprador y esta arquitectura cuando determinados archivos o rutas también necesiten protección aplicada por CloudFront.