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 diffusiez 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), afin d'éviter 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 directives includeSubdomains ou preload. Ces directives 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 , un