Prácticas recomendadas para seguridad web

Prácticas recomendadas para seguridad web

Cloud CDN y Cloud Load Balancing pueden ayudarte a cumplir con las prácticas recomendadas para 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 la 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 que configures este encabezado.

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

Establecer este encabezado es, en efecto, irreversible. Después de almacenar en caché este encabezado, los clientes del navegador actualizado 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 entregas el encabezado Strict-Transport-Security, ten cuidado al agregar las directivas includeSubdomains o preload. Estas directivas requieren que cualquier subdominio use HTTPS, incluidos los sitios internos en el 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 renderizar una página en <frame>, <iframe>, <object> o <embed>. 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

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

Content-Security-Policy Para evaluar la Política de Seguridad del 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 con HTTPS: Content-Security-Policy: default-src https:

Ten cuidado cuando ingreses nuevos encabezados de seguridad en sitios web existentes, ya que pueden interrumpir secuencias de comandos de terceros, contenido incorporado (por ejemplo, en iframes) o cualquier otro aspecto 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.

También 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 pueden implementar con facilidad en tus balanceadores de cargas.
  • Se renuevan automáticamente.
  • 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 tránsito. Los certificados TLS proporcionan confidencialidad, ya que garantizan que un intruso 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 un video en streaming) y la confiabilidad en las redes congestionadas.

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

Puedes usar políticas de SSL para aumentar la versión mínima de TLS. Te recomendamos que aumentes la versión a TLS v1.2 si no necesitas admitir clientes más antiguos, como dispositivos incorporados o clientes que no son navegadores tan 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 la solicitud. Luego, puedes registrar esta información.

¿Qué sigue?