Muchas entornos de producción se benefician de desplegar de forma centralizada encabezados de seguridad y Content‑Security‑Policy (CSP). La palabra clave central „Security Headers und CSP zentral ausrollen“ describe exactamente esta tarea: establecer en un punto central encabezados HTTP relevantes para la seguridad (Reverse‑Proxy o CDN) y garantizar mediante pruebas automatizadas que aplicaciones como Zammad u otras soluciones de software cercanas al proceso no queden bloqueadas de forma no intencionada. En esta guía práctica conocerá variantes arquitectónicas, ejemplos concretos de configuración, automatización de pruebas, trampas habituales y una estrategia de despliegue segura.
¿Por qué desplegar encabezados de seguridad de forma centralizada?
Los encabezados de seguridad son cabeceras de respuesta HTTP que indican a los navegadores o proxies cómo tratar los recursos. Ejemplos son Content‑Security‑Policy (CSP) para RESTringir orígenes de scripts y estilos, Strict‑Transport‑Security (HSTS) para forzar HTTPS o X‑Content‑Type‑Options para evitar MIME‑sniffing. Si estas cabeceras se establecen de forma central en el Reverse‑Proxy (p. ej. Nginx, HAProxy, Traefik), se logra:
- Una base de seguridad homogénea para múltiples aplicaciones sin intervenir cada base de código.
- Respuesta más rápida ante amenazas mediante el cambio centralizado de políticas.
- Mejor capacidad de auditoría y consistencia.
Al mismo tiempo, las configuraciones centrales conllevan riesgos: aplicaciones con contenido dinámico (scripts inline, widgets de terceros) pueden quedar bloqueadas por una CSP RESTrictiva. Por ello, un enfoque escalonado (Report‑Only, endurecimiento progresivo) es esencial.
Variantes de arquitectura: Reverse‑Proxy vs. CDN‑Edge
Existen dos patrones prácticos para establecer encabezados de seguridad:
1) Reverse‑Proxy como aplicador central de políticas
El Reverse‑Proxy se sitúa delante de sus backends en su red o en la nube y manipula las respuestas. Ventajas: control total, capacidad de integración con mecanismos de autenticación internos (LDAP/AD, JWT‑Translation), logging uniforme y menor dependencia de terceros. Inconveniente: debe gestionar usted mismo la escalabilidad, la disponibilidad y el manejo de TLS.
2) Capa CDN/Edge (Cloudflare, Fastly, Akamai)
Los CDN aplican cabeceras ya en el edge—cerca del usuario. Ventajas: baja latencia, manejo de grandes volúmenes y distribución global sencilla. Inconvenientes: algunas funcionalidades del CDN (Edge Workers, caching, reescritura de cabeceras) pueden modificar cabeceras o afectar a las aplicaciones; además, el control está a veces limitado por las RESTricciones del proveedor.
Regla práctica: utilice Reverse‑Proxy para aplicaciones internas/altamente dinámicas (p. ej. instalaciones Zammad con plantillas JS inline) y CDN‑Edge para recursos estáticos o como capa de protección adicional. Si usa ambas capas en paralelo, pRESTe atención a las reglas de sobrescritura de cabeceras.
¿Qué encabezados debe priorizar?
Empiece con una selección básica que endurezca los navegadores de forma fundamental:
- Strict‑Transport‑Security (HSTS): exigir HTTPS, importante para proteger contra degradaciones (downgrade).
- Content‑Security‑Policy (CSP): control de orígenes de scripts, estilos e imágenes; previene XSS.
- X‑Content‑Type‑Options: nosniff para proteger contra MIME‑sniffing.
- Referrer‑Policy: controla qué información de referer se transmite.
- Permissions‑Policy (antes Feature‑Policy): RESTringe APIs como geolocation, camera, microphone.
- Cache‑Control / Surrogate‑Control: importante en la integración con CDN para establecer límites de caché correctos.
Otras cabeceras como X‑Frame‑Options son en parte reemplazadas por frame‑ancestors de CSP; utilice la variante CSP más moderna cuando sea posible.
Implementación técnica: ejemplo Nginx como Reverse‑Proxy
El siguiente ejemplo muestra cómo añadir encabezados en Nginx. Nginx actúa aquí como proxy inverso y terminación SSL. Asegúrese de que los backends no envíen encabezados contradictorios. Si los backends establecen sus propios encabezados, puede eliminarlos con „more_clear_headers“ (del módulo ngx_headers_more).
server {
listen 443 ssl;
server_name example.internal;
# TLS setup (verkürzt)
ssl_certificate /etc/ssl/certs/example.pem;
ssl_certificate_key /etc/ssl/private/example.key;
# Baseline Security Headers
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=()" always;
# HSTS: vorsichtig in der Anfangsphase (Report-Only zuerst)
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
# CSP: initial als Report-Only, später in enforce
add_header Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'nonce-%{CSP_NONCE}'; report-uri /csp-report-endpoint" always;
location / {
proxy_pass http://backend_pool;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Nota: El uso de nonces (valores aleatorios de vida breve) permite scripts inline sin permitir la insegura ‚unsafe-inline‘. Nginx puede generar nonces mediante creación de variables e insertarlos en plantillas HTML; muchos frameworks de aplicaciones admiten integración de nonces directamente.
Despliegue centralizado de encabezados de seguridad y CSP — Diseño de CSP: Nonce, Hash o lista blanca?
Elija la estrategia de CSP según el tipo de aplicación:
- Nonce: Bueno para páginas renderizadas en servidor con un stack de plantillas controlado. Cada respuesta recibe un nonce aleatorio que se asigna en la etiqueta