Bonnes pratiques de sécurité Web

Bonnes pratiques de sécurité Web

Cloud CDN et Cloud Load Balancing peuvent vous aider à respecter les bonnes pratiques de sécurité Web, que vous utilisiez du contenu provenant d'instances Compute Engine, d'un bucket Cloud Storage ou d'une origine externe située en dehors de Google Cloud.

Définir les en-têtes de sécurité

La spécification HTTP contient un certain nombre d'en-têtes qui contrôlent les éléments suivants :

  • Comportement du client
  • Intégration du contenu
  • Diffusion du contenu sur plusieurs domaines
  • Utilisation ou pas du protocole TLS (HTTPS) à chaque connexion à ce domaine

Ces contrôles sont généralement représentés par des en-têtes de réponse HTTP, que vous pouvez définir pour chaque backend (origine, en termes CDN), en tant qu'en-têtes de réponse personnalisés pour votre déploiement d'équilibreur de charge d'application externe et de Cloud CDN.

Si vous utilisez Cloud Storage et diffusez du contenu Web à partir de votre bucket, vous pouvez utiliser Cloud CDN devant votre bucket de stockage pour définir les en-têtes de sécurité Web et mettre en cache le contenu populaire.

Les en-têtes de sécurité Web les plus utiles sont définis dans le tableau suivant.

Nom de l'en-tête Description Exemple d'utilisation
Strict-Transport-Security (HSTS) Avant de définir cet en-tête, assurez-vous que vos domaines disposent de certificats SSL (TLS) valides.

Indique aux clients qu'ils doivent se connecter directement à votre domaine via HTTPS (SSL/TLS), ce qui évite d'avoir à rediriger le trafic HTTP vers HTTPS, ce qui est plus lent et présente un risque d'attaque MITM.

La définition de cet en-tête est irréversible. Une fois cet en-tête mis en cache, les clients de navigateur modernes n'effectuent pas de connexions non-HTTPS, et les utilisateurs ne peuvent accéder à aucun domaine pour lequel ils ont reçu cet en-tête, même si SSL est indisponible. Ce comportement empêche un pirate informatique de rétrograder du protocole sécurisé au protocole HTTP non protégé (appelé attaque par rétrogradation).

Lorsque vous diffusez l'en-tête Strict-Transport-Security, soyez prudent lorsque vous ajoutez les instructions includeSubdomains ou preload. Ces instructions nécessitent que tout sous-domaine utilise HTTPS, y compris les sites internes du même domaine. Par exemple, support.example.com diffusé depuis example.com.

Exiger que les clients se connectent directement via HTTPS pour toutes les connexions futures, en mettant en cache cette directive pendant deux ans maximum :

Strict-Transport-Security: max-age=3104000

X-Frame-Options Indique si un navigateur peut afficher une page dans un <frame>, un <iFrame>, un <embed> ou un <object>. Vous évitez ainsi les attaques par détournement de clic en ne permettant pas à votre contenu d'être intégré dans d'autres sites. Refuser tous les iFrames de votre site: X-Frame-Options: DENY

Autoriser uniquement votre site à s'insérer lui-même dans un iframe (embed) : X-Frame-Options: SAMEORIGIN

Content-Security-Policy Pour évaluer la stratégie de sécurité du contenu de votre site, vous pouvez utiliser l'outil CSP Evaluator de Google. Ne pas autoriser les scripts intégrés et ne charger des scripts que via HTTPS : Content-Security-Policy: default-src https:

Soyez prudent lorsque vous ajoutez de nouveaux en-têtes de sécurité à des sites Web existants, car ils peuvent rompre les scripts tiers, le contenu intégré (par exemple, dans des cadres RESTful) ou d'autres aspects de vos sites. Avant d'apporter des modifications à votre trafic de production, nous vous recommandons de créer une deuxième instance de votre bucket backend ou service de backend et de procéder à des tests.

Pour en savoir plus sur les en-têtes de sécurité Web et les bonnes pratiques, consultez web.dev, ansi que le site Infosec de Mozilla.

TLS et gestion des certificats

Les certificats gérés présentent les caractéristiques suivantes :

  • Ils sont fournis gratuitement.
  • Ils peuvent facilement être déployés sur vos équilibreurs de charge.
  • Renouvellement automatique
  • Ils sont distribués dans le monde entier sur tous les emplacements périphériques de Google.

TLS assure l'authenticité en validant l'absence de modifications des données pendant leur transit. Les certificats TLS assurent la confidentialité en s'assurant qu'un espion ne peut pas déterminer les données échangées entre des utilisateurs et des serveurs. Leur action est importante pour des raisons de confidentialité et de sécurité.

Les certificats SSL vous permettent de bénéficier de protocoles de transport modernes, tels que HTTP/2 et le protocole QUIC de Google, qui nécessitent tous deux SSL (TLS). Ces protocoles améliorent directement les performances du contenu Web, la diffusion de contenus multimédias (tels que les vidéos en streaming) et la fiabilité sur les réseaux encombrés.

Google Cloud est compatible avec les protocoles TLS modernes (tels que TLS 1.3) sur les services Cloud Load Balancing et Cloud CDN.

Vous pouvez utiliser des règles SSL pour augmenter la version minimale de TLS. Nous vous recommandons d'augmenter la version de TLS vers v1.2 si vous n'avez pas besoin de gérer d'anciens clients, tels que des appareils intégrés ou des clients plus anciens (plus de 10 ans) sans navigateur. Globalement, TLS v1.0 et TLS v1.1 représentent moins de 0,5 % des connexions dans Google Cloud. Si vous devez identifier ou associer des clients spécifiques à des versions obsolètes de TLS, vous pouvez utiliser la variable {tls_version} dans un en-tête de requête. Vous pouvez ensuite consigner ces informations.

Étape suivante