Best Practices für Websicherheit
Cloud CDN und Cloud Load Balancing können Ihnen dabei helfen, Best Practices für die Websicherheit anzuwenden, unabhängig davon, ob Sie Inhalte aus Compute Engine-Instanzen, einem Cloud Storage-Bucket oder einem externen Ursprung außerhalb von Google Cloudbereitstellen.
Sicherheitsheader festlegen
Die HTTP-Spezifikation hat eine Reihe von Headern, die Folgendes steuern:
- Clientverhalten
- Wie Inhalte eingebettet werden
- Wie Inhalte domainübergreifend bereitgestellt werden
- Ob immer TLS (HTTPS) verwendet werden soll, wenn eine Verbindung zu dieser Domain hergestellt wird
Diese Einstellungen werden durch HTTP-Antwortheader repräsentiert, die Sie für jedes Backend (Ursprung nach CDN-Terminologie) als benutzerdefinierte Antwortheader für Ihren externen Application Load Balancer und Ihre Cloud CDN-Bereitstellung festlegen können.
Wenn Sie Cloud Storage verwenden und Webinhalte aus Ihrem Bucket bereitstellen, können Sie Cloud CDN vor Ihrem Storage-Bucket verwenden, um Websicherheitsheader festzulegen und oft angeforderte Inhalte im Cache zu speichern.
Die nützlichsten Websicherheitsheader sind in der folgenden Tabelle definiert.
| Headername | Beschreibung | Nutzungsbeispiel |
|---|---|---|
Strict-Transport-Security (HSTS) |
Stellt sicher, dass Ihre Domains gültige SSL-Zertifikate (TLS-Zertifikate) haben, bevor Sie diesen Header festlegen Teilt Clients mit, dass sie sich direkt über HTTPS mit Ihrer Domain verbinden müssen (SSL/TLS), sodass keine Weiterleitung von HTTP zu HTTPS erforderlich ist. Dies ist langsamer und birgt das Risiko eines Person-in-the-Middle-Angriffs. Das Festlegen dieses Headers kann quasi nicht rückgängig gemacht werden. Nach dem Caching dieses Headers versuchen moderne Browserclients nicht, Nicht-HTTPS-Verbindungen auszuführen, und Nutzer können nicht auf Domains zugreifen, für die sie diesen Header erhalten haben, selbst wenn SSL ausgefallen ist. Dieses Verhalten verhindert, dass ein Angreifer ein Downgrade des sicheren Protokolls auf das ungeschützte HTTP-Protokoll (als Downgrade-Angriff bezeichnet) ausführt.
Seien Sie beim Bereitstellen des |
Clients müssen für alle zukünftigen Verbindungen eine direkte Verbindung über HTTPS herstellen, wobei diese Anweisung bis zu zwei Jahre im Cache gespeichert wird:
|
X-Frame-Options |
Geben Sie an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern kann. So können Sie Clickjacking-Angriffe verhindern, da Ihre Inhalte nicht in andere Websites eingebettet werden können. |
Jegliches iFraming Ihrer Website ablehnen: X-Frame-Options: DENY
Nur Ihrer Website selbst erlauben, ein iFraming (Einbettung) für sich vorzunehmen: |
Content-Security-Policy
|
Mit dem CSP Evaluator-Tool von Google können Sie die Content Security Policy Ihrer Website auswerten. | Keine Inline-Scripts zulassen und Scripts nur über HTTPS laden: Content-Security-Policy: default-src https:
|
Seien Sie vorsichtig, wenn Sie neue Sicherheitsheader auf vorhandenen Websites einführen, da diese möglicherweise Scripts von Drittanbietern, eingebettete Inhalte (z. B. in iFrames) oder andere Aspekte Ihrer Websites beeinträchtigen. Bevor Sie Änderungen am Produktions-Traffic vornehmen, empfehlen wir, eine zweite Instanz Ihres Backend-Buckets oder Backend-Dienstes zu erstellen und Tests durchzuführen.
Weitere Informationen zu Websicherheitsheadern und Best Practices finden Sie auf web.dev sowie auf der infosec-Website von Mozilla.
TLS und Zertifikatsverwaltung
Verwaltete Zertifikate haben folgende Eigenschaften:
- Sie werden kostenlos zur Verfügung gestellt.
- Sie können problemlos auf Ihren Load Balancern bereitgestellt werden.
- Sie werden automatisch verlängert.
- Sie werden weltweit an alle Edge-Standorte von Google verteilt.
TLS bietet Authentizität, indem kontrolliert wird, dass die Daten bei der Übertragung nicht geändert wurden. TLS-Zertifikate sorgen für Vertraulichkeit, da Unbefugte nicht feststellen können, was zwischen Nutzern und Servern ausgetauscht wird. Dies ist wichtig für den Datenschutz und die Sicherheit der Nutzer.
Mit SSL-Zertifikaten können Sie von modernen Transportprotokollen wie HTTP/2 und dem QUIC-Protokoll von Google profitieren. Beide erfordern SSL (TLS). Diese Protokolle verbessern direkt die Leistung von Webinhalten, Medienbereitstellungen (z. B. gestreamten Videos) und die Zuverlässigkeit bei stark ausgelasteten Netzwerken.
Google Cloud unterstützt moderne TLS-Protokolle (z. B. TLS 1.3) für Cloud Load Balancing- und Cloud CDN-Dienste.
Sie können SSL-Richtlinien verwenden, um die Mindestversion von TLS zu erhöhen. Wir empfehlen, die Version auf TLS v1.2 zu erhöhen, wenn Sie keine älteren Clients wie eingebettete Geräte oder ältere (mehr als zehn Jahre alte) Nichtbrowserclients unterstützen müssen. Global werden TLS v1.0 und TLS v1.1 für weniger als 0,5 % der Verbindungen in Google Cloudgenutzt.
Wenn Sie bestimmte Clients mit veralteten TLS-Versionen identifizieren oder verknüpfen müssen, können Sie die Variable {tls_version} in einem Anfrageheader verwenden. Diese Informationen können Sie dann protokollieren.
Nächste Schritte
- Informationen zum Prüfen, ob Cloud CDN Antworten aus dem Cache bereitstellt, finden Sie unter Logs ansehen.
- Mehr darüber, welche Inhalte im Cache gespeichert werden können und welche nicht, erfahren Sie unter Caching-Details.
- Informationen zu den Points of Presence von Cloud CDN finden Sie unter Cache-Speicherorte.