WordPress estático · Autenticación
Autenticación para WordPress estático simplificada: despliegue con la plantilla de AWS SAR
Un frontend estático de WordPress elimina el entorno de ejecución de PHP de las solicitudes públicas, pero también suprime el inicio de sesión nativo de WordPress del sitio servido. Por ello, los portales, las descargas y las rutas para miembros protegidos necesitan un modelo de identidad y acceso en el perímetro diseñado para la entrega estática.
Actualización importante
Este método de despliegue ha sido sustituido
La plantilla de AWS Serverless Application Repository (SAR) descrita en este artículo ya no está disponible. WP Suite utiliza ahora Deployment Access, con plantillas de CloudFormation que cubren la infraestructura de backend necesaria para todos los plugins de WP Suite.
Próximamente: una nueva guía explicará el flujo de trabajo actualizado de Deployment Access y la solución ampliada.
El patrón
Autentique con Cognito y autorice la entrega con CloudFront.
Gatey inicia la sesión del usuario
El navegador se autentica en un Amazon Cognito User Pool mediante la experiencia de Gatey integrada en las páginas generadas por WordPress.
Un firmante emite cookies
Una API protegida verifica al usuario autenticado y devuelve cookies firmadas de CloudFront con una ruta y una duración limitadas.
CloudFront protege el contenido
Los comportamientos de CloudFront y un grupo de claves de confianza aplican el control de acceso antes de entregar desde S3 los objetos estáticos protegidos.
01 · Por qué
¿Por qué la publicación estática necesita otra arquitectura de inicio de sesión?
Cuando WordPress se exporta a archivos estáticos, ya no hay una sesión de PHP ni una solicitud a la base de datos de WordPress en la ruta pública. El sitio puede seguir mostrando JavaScript interactivo, pero el sistema nativo de autenticación de WordPress ya no está presente en el perímetro.
La alternativa debe proteger la propia ruta de entrega del contenido, no limitarse a ocultar enlaces en el navegador. Las cookies firmadas de CloudFront son adecuadas cuando un usuario autenticado necesita acceder a varios archivos o rutas protegidos dentro de la misma distribución.
- No confíe en reglas de visibilidad del lado del cliente como control de acceso.
- Proteja el origen para que los visitantes no puedan eludir CloudFront ni leer directamente los objetos de S3.
- Limite las políticas de cookies al dominio, la ruta y la duración necesarios.
Así se obtiene un sitio estático que sigue siendo almacenable en caché y se distribuye globalmente, mientras el contenido seleccionado permanece tras una política aplicable en el perímetro. Para conocer el planteamiento completo del problema, consulte cómo añadir inicio de sesión a WordPress estático sin recuperar las sesiones de PHP y cómo mantener funciones dinámicas después de la publicación estática.
WordPress estático y dinámico
| Característica | WP dinámico (PHP/MySQL) | WP estático (S3 + CloudFront) |
|---|---|---|
| Velocidad | Renderizado en el servidor, depende de PHP/BD | Almacenado en caché en el perímetro de la CDN, ultrarrápido |
| Seguridad | El núcleo y los plugins aumentan la superficie de ataque | Superficie mínima (archivos estáticos) |
| Escalabilidad | Limitada por los recursos del servidor | Prácticamente ilimitada mediante CloudFront |
| Autenticación | Inicio de sesión integrado de WordPress | SAR + Gatey (cookies firmadas) |
| Mantenimiento | Parches y copias de seguridad de la base de datos | Sincronización de archivos e invalidación de caché |
02 · Componentes
¿Qué proporciona la pila de Static Site Guardian?
El patrón de despliegue combina un origen de S3, un comportamiento de distribución de CloudFront, una clave pública y un grupo de claves de CloudFront, además de endpoints de API Gateway y Lambda que emiten y eliminan cookies firmadas después de la autenticación.
Los recursos auxiliares pueden almacenar de forma segura el material de firma, conectar un dominio personalizado y un certificado, aplicar protecciones de WAF y exponer salidas que Gatey o la configuración de WordPress puedan utilizar.
- Origen privado de S3 y entrega mediante CloudFront.
- Endpoints de emisión de cookies y cierre de sesión con autorización específica para cada ruta.
- Claves, registros, dominios y costes de servicios de AWS propiedad del cliente.
Los recursos exactos dependen de los parámetros de despliegue seleccionados, pero el control de acceso permanece fuera de los archivos HTML exportados. Para profundizar en el límite de entrega, consulte la arquitectura de cookies firmadas de CloudFront.
03 · Integración
¿Cómo conecta Gatey el inicio de sesión con las rutas estáticas protegidas?
Gatey gestiona el flujo de cuenta de Cognito en el navegador. Tras iniciar sesión correctamente, el frontend llama al endpoint emisor de cookies configurado con el contexto autenticado necesario. La respuesta establece cookies firmadas para el dominio de CloudFront; después, el visitante puede solicitar la ruta protegida con normalidad.
El cierre de sesión debe eliminar tanto la sesión de la aplicación como las cookies de CloudFront. Los destinos de redirección deben ser explícitos para que las solicitudes caducadas o no autorizadas devuelvan al visitante a una ruta de inicio de sesión útil, en lugar de mostrar un error de entrega genérico.
- Mantenga alineados la URL de devolución de Cognito, el dominio del sitio y el dominio de las cookies.
- Pruebe el inicio de sesión, el acceso directo a una URL protegida, la caducidad y el cierre de sesión.
- Evite ámbitos de cookies que cubran sitios o rutas no relacionados.
El usuario ve un recorrido de cuenta normal, mientras CloudFront sigue aplicando la decisión de entrega.
04 · Operaciones
¿Qué debe probarse después del despliegue?
Un despliegue correcto de CloudFormation es solo el principio. Publique los archivos estáticos en el prefijo de S3 previsto, invalide las rutas pertinentes de CloudFront y verifique que las rutas públicas sigan accesibles mientras las protegidas rechazan las solicitudes anónimas.
Después, pruebe varios usuarios, la caducidad de las cookies, los modos de privacidad del navegador, los dominios personalizados, el comportamiento CORS de la API de firma, la rotación de claves, los registros, las alarmas y los procedimientos de reversión. Confirme que los cambios en la página de WordPress no eliminen accidentalmente la configuración de integración necesaria para el frontend exportado.
- Pruebe los estados anónimo, autenticado, caducado y con la sesión cerrada.
- Supervise los fallos del firmante y las respuestas de autorización inesperadas.
- Documente cómo rotar las claves y la configuración sin tiempo de inactividad.
La entrega estática reduce la superficie de ataque pública de WordPress, pero no elimina las responsabilidades de identidad, claves, API y operaciones.
Regla de control de acceso
Una página estática puede ser interactiva, pero el navegador no debe ser el límite de seguridad.
Utilice la lógica del navegador para mejorar la experiencia del usuario. Utilice Cognito, API protegidas, políticas de CloudFront y un origen privado para decidir si el contenido protegido se entrega realmente.
Siguiente paso
Planifique las rutas protegidas antes de desplegar la pila.
Revise Static Publisher y Deployment Access para definir cómo se exporta el sitio, dónde se entrega y qué rutas requieren protección mediante cookies firmadas.