Prácticas recomendadas de seguridad web

Prácticas recomendadas de seguridad web

Cloud CDN y Cloud Load Balancing pueden ayudarte a cumplir las prácticas recomendadas de seguridad web, ya sea que entregues contenido desde instancias de Compute Engine, un bucket de Cloud Storage o un origen externo ubicado fuera de Google Cloud.

Configura encabezados de seguridad

La especificación HTTP tiene una serie de encabezados que controlan lo siguiente:

  • Comportamiento del cliente
  • Cómo se incorpora el contenido
  • Cómo se entrega el contenido en los dominios
  • Si siempre se debe usar TLS (HTTPS) cuando se establece una conexión a ese dominio

Por lo general, estos controles se representan como encabezados de respuesta HTTP, que puedes configurar para cada backend (origen, en términos de CDN) como encabezados de respuesta personalizados para tu balanceador de cargas de aplicaciones externo y tu implementación de Cloud CDN.

Si usas Cloud Storage y entregas contenido web desde tu bucket, puedes usar Cloud CDN frente al bucket de almacenamiento para configurar encabezados de seguridad web y almacenar en caché el contenido popular.

Los encabezados de seguridad web más útiles se definen en la siguiente tabla.

Nombre del encabezado Descripción Ejemplo de uso
Strict-Transport-Security (HSTS) Garantiza que tus dominios tengan certificados SSL (TLS) válidos antes de configurar este encabezado.

Informa a los clientes que deben conectarse a tu dominio directamente a través de HTTPS (SSL/TLS), lo que evita la necesidad de redireccionar de HTTP a HTTPS, lo que es más lento y genera el riesgo de una persona en el medio del ataque.

Establecer este encabezado es efectivamente irreversible. Después de almacenar en caché este encabezado, los clientes modernos del navegador no intentan establecer conexiones no HTTPS y los usuarios no pueden acceder a ningún dominio por el que recibieron este encabezado, incluso si SSL está inactivo. Este comportamiento evita que un atacante pase a una versión inferior del protocolo seguro al HTTP sin protección (conocido como ataque de degradación).

Cuando publiques el encabezado Strict-Transport-Security, ten cuidado cuando agregues las directivas includeSubdomains o preload. Estas directivas requieren que cualquier subdominio use HTTPS, incluidos los sitios internos del mismo dominio. Por ejemplo, support.example.com cuando se entrega desde example.com.

Requiere que los clientes se conecten directamente a través de HTTPS para todas las conexiones futuras y que almacenen esta directiva en caché por hasta dos años:

Strict-Transport-Security: max-age=3104000

X-Frame-Options Indica si un navegador puede procesar una página en <frame>, <iframe>, <embed> u <object>. Esto ayuda a prevenir los ataques de clickjacking, ya que no permite que tu contenido se incorpore en otros sitios. Rechaza todo el iframing de tu sitio: X-Frame-Options: DENY

Permitir que solo tu sitio incluya iframe (incorporar): X-Frame-Options: SAMEORIGIN

Content-Security-Policy Para evaluar la política de seguridad de contenido de tu sitio, puedes usar la herramienta CSP Evaluator de Google. No permitas secuencias de comandos en línea y solo carga secuencias de comandos mediante HTTPS: Content-Security-Policy: default-src https:

Ten cuidado cuando introduzcas encabezados de seguridad nuevos en sitios web existentes, ya que pueden dañar secuencias de comandos de terceros, contenido incorporado (por ejemplo, en iframes) y otros aspectos de tus sitios. Antes de realizar cambios en el tráfico de producción, te recomendamos que crees una segunda instancia de tu bucket o servicio de backend y que realices pruebas.

Puedes obtener más información sobre los encabezados de seguridad web y las prácticas recomendadas en web.dev y en el sitio de seguridad de la información de Mozilla.

Administración de certificados y TLS

Los certificados administrados tienen las siguientes características:

  • Se proporcionan sin costo.
  • Se puede implementar fácilmente en tus balanceadores de cargas
  • Renovación automática
  • Se distribuyen de forma global a todas las ubicaciones perimetrales de Google.

TLS proporciona autenticidad validando que los datos no se hayan modificado durante el envío. Los certificados TLS proporcionan confidencialidad, ya que se aseguran de que un usuario que escucha en secreto no pueda determinar qué se intercambia entre los usuarios y los servidores. Esto es importante para la privacidad y seguridad de los usuarios.

Con los certificados SSL, puedes beneficiarte de los protocolos de transporte modernos, como HTTP/2 y el protocolo QUIC de Google, ambas en las que se requiere SSL (TLS). Estos protocolos mejoran directamente el rendimiento del contenido web, la entrega de medios (como la transmisión de video) y la confiabilidad en las redes congestionadas.

Google Cloud admite protocolos TLS modernos (como TLS 1.3) en Cloud Load Balancing y servicios de Cloud CDN.

Puedes usar políticas de SSL para aumentar la versión mínima de TLS. Te recomendamos que actualices la versión a TLS v1.2 si no necesitas admitir clientes más antiguos, como dispositivos incorporados o clientes que no sean de navegadores más antiguos (más de 10 años). A nivel global, TLS v1.0 y TLS v1.1 representan menos del 0.5% de las conexiones en Google Cloud. Si necesitas identificar o asociar clientes específicos con versiones desactualizadas de TLS, puedes usar la variable {tls_version} en un encabezado de solicitud. Luego, puedes registrar esta información.

¿Qué sigue?