Best Practices für Websicherheit

Best Practices für Websicherheit

Cloud CDN und HTTP(S)-Load-Balancing können Ihnen dabei helfen, Best Practices für die Websicherheit einzuhalten, unabhängig davon, ob Sie Inhalte aus Compute Engine-Instanzen, einem Cloud Storage-Bucket oder einem externen Ursprung außerhalb von Google Cloud bereitstellen.

Sicherheitsheader festlegen

Die HTTP-Spezifikation hat eine Reihe von Headern, die Folgendes steuern:

  • Clientverhalten
  • Wie Inhalte eingebettet werden
  • Domainbereitstellung
  • Ob immer TLS (HTTPS) verwendet werden soll, wenn eine Verbindung zu dieser Domain hergestellt wird

Diese Steuerelemente werden normalerweise als HTTP-Antwortheader dargestellt, die Sie für jedes Back-End (Ursprung, was CDN angeht) als benutzerdefinierte Antwortheader für Ihre HTTP(S)-Load-Balancing und Cloud CDN festlegen können.

Wenn Sie Cloud Storage verwenden und Webinhalte aus Ihrem Bucket bereitstellen, können Sie Cloud CDN vor Ihrem Speicher-Bucket verwenden, um Websicherheitsheader festzulegen und beliebte 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 effektiv 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, auch wenn SSL ausgefallen ist. Dieses Verhalten verhindert, dass ein Angreifer ein Downgrade des sicheren Protokolls auf das ungeschützte HTTP-Protokoll ausführt. Dies wird als Downgrade-Angriff bezeichnet.

Seien Sie beim Bereitstellen des Headers Strict-Transport-Security vorsichtig, wenn Sie die Anweisungen includeSubdomains oder preload hinzufügen. Diese Anweisungen erfordern, dass HTTPS in einer Subdomain verwendet wird, einschließlich interner Websites in derselben Domain. Beispiel: support.example.com, wenn es von example.com bereitgestellt wird.

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:

Strict-Transport-Security: max-age=3104000

X-Frame-Options Geben Sie an, ob ein Browser eine Seite in einem <frame>, <iframe>, <embed> oder <object> rendern kann. So können Sie Click-Jading-Angriffe verhindern, da Ihre Inhalte nicht in andere Websites eingebettet werden können. Lehnen Sie alle iFrames auf Ihrer Website ab: X-Frame-Options: DENY

Erlauben Sie nur das Einbetten (iFrame) Ihrer Website selbst: X-Frame-Options: SAMEORIGIN

Content-Security-Policy Mit dem CSP-Evaluator-Tool von Google können Sie die Content Security Policy Ihrer Website auswerten. Lassen Sie keine Inline-Skripts zu und laden Sie nur Skripts über HTTPS: Content-Security-Policy: default-src https:

Seien Sie vorsichtig, wenn Sie neue Sicherheitsheader auf vorhandenen Websites einführen, da diese möglicherweise Skripts von Drittanbietern, eingebettete Inhalte (z. B. in Frames) oder andere Aspekte Ihrer Websites beeinträchtigen. Bevor Sie Änderungen am Produktionstraffic vornehmen, empfehlen wir, eine zweite Instanz Ihres Back-End-Buckets oder -Dienstes und Tests zu erstellen.

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
  • Automatisch erneuern
  • Werden weltweit an alle Edge-Standorte von Google verteilt

TLS bietet Authentizität, indem es überprüft, ob die Daten bei der Übertragung geändert wurden. TLS-Zertifikate bieten Vertraulichkeit, da sie nicht überwachen 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. Streamingvideos) und die Zuverlässigkeit bei überlasteten 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 (nicht mehr als zehn Jahre alte) Nicht-Browser-Clients unterstützen müssen. Global stellen TLS v1.0 und TLS v1.1 weniger als 0,5 % der Verbindungen in Google Cloud dar. Wenn Sie bestimmte Clients mit veralteten TLS-Versionen identifizieren oder verknüpfen möchten, 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.