ウェブセキュリティのベストプラクティス

Cloud CDN と Cloud Load Balancing は、Compute Engine インスタンス、Cloud Storage バケット、Google Cloud の外部にある送信元のどこからコンテンツを提供する場合でも、ウェブセキュリティのベストプラクティスを満たすのに役立ちます。

セキュリティヘッダーを設定する

HTTP 仕様には、次のことを制御する複数のヘッダーがあります。

クライアントの動作
コンテンツの埋め込み方法
複数のドメインにわたるコンテンツの配信方法
そのドメインへの接続時に TLS（HTTPS）を常時使用するかどうか

通常これらのコントロールは、HTTP レスポンスヘッダーとして表され、各バックエンド（CDN 用語では送信元）を外部 HTTP(S) ロードバランサと Cloud CDN Deployment のカスタムレスポンスヘッダーとして設定できます。

Cloud Storage を使用してバケットからウェブコンテンツを配信する場合は、ストレージバケットの前面に Cloud CDN を使用して、ウェブセキュリティヘッダーを設定し、人気のコンテンツをキャッシュに保存できます。

次の表に、最も有用なウェブセキュリティヘッダーを示します。

ヘッダー名説明使用例

ヘッダー名	説明	使用例
`Strict-Transport-Security`（HSTS）	このヘッダーを設定する前に、ドメインに有効な SSL（TLS）証明書があることを確認してください。 HTTPS（SSL / TLS）経由でドメインに直接接続する必要があることをクライアントに知らせることで、速度が低下し、中間者攻撃のリスクを招く HTTP から HTTPS へのリダイレクトを回避します。このヘッダーを設定すると元に戻すことはできません。このヘッダーがキャッシュに保存されると、最新のブラウザクライアントは HTTPS 以外の接続を試行せず、SSL が停止しても、ユーザーはこのヘッダーを受け取ったドメインにはアクセスできません。この動作によって、攻撃者が安全なプロトコルを保護されていない HTTP にダウングレードすること（ダウングレード攻撃）が防止されます。 `Strict-Transport-Security` ヘッダーを付ける場合、`includeSubdomains` ディレクティブや `preload` ディレクティブを追加するときに注意が必要です。これらのディレクティブでは、同じドメインの内部サイトを含め、すべてのサブドメインで HTTPS を使用する必要があります。たとえば、`support.example.com` が `example.com` から提供される場合などです。	クライアントに、以降の接続すべてを HTTPS 経由にすることを求め、このディレクティブを最長 2 年間キャッシュに保存する。 `Strict-Transport-Security: max-age=3104000`
`X-Frame-Options`	ブラウザが <frame>、<iframe>、<embed>、または <object> でページをレンダリングできるかどうかを示します。コンテンツを他のサイトに埋め込まないようにして、クリックジャッキング攻撃の防止をサポートします。	サイトの iframe をすべて拒否する: `X-Frame-Options: DENY` ご利用のサイトのみに iframe（埋め込み）を許可する: `X-Frame-Options: SAMEORIGIN`
`Content-Security-Policy`	サイトのコンテンツセキュリティポリシーを評価するために、Google の CSP 評価ツールを使用できます。	インラインスクリプトを許可せず、HTTPS 経由でのみスクリプトを読み込む: `Content-Security-Policy: default-src https:`

Strict-Transport-Security（HSTS）

このヘッダーを設定する前に、ドメインに有効な SSL（TLS）証明書があることを確認してください。

HTTPS（SSL / TLS）経由でドメインに直接接続する必要があることをクライアントに知らせることで、速度が低下し、中間者攻撃のリスクを招く HTTP から HTTPS へのリダイレクトを回避します。

このヘッダーを設定すると元に戻すことはできません。このヘッダーがキャッシュに保存されると、最新のブラウザクライアントは HTTPS 以外の接続を試行せず、SSL が停止しても、ユーザーはこのヘッダーを受け取ったドメインにはアクセスできません。この動作によって、攻撃者が安全なプロトコルを保護されていない HTTP にダウングレードすること（ダウングレード攻撃）が防止されます。

Strict-Transport-Security ヘッダーを付ける場合、includeSubdomains ディレクティブや preload ディレクティブを追加するときに注意が必要です。これらのディレクティブでは、同じドメインの内部サイトを含め、すべてのサブドメインで HTTPS を使用する必要があります。たとえば、support.example.com が example.com から提供される場合などです。

クライアントに、以降の接続すべてを HTTPS 経由にすることを求め、このディレクティブを最長 2 年間キャッシュに保存する。

Strict-Transport-Security: max-age=3104000

X-Frame-Options

ブラウザが <frame>、<iframe>、<embed>、または <object> でページをレンダリングできるかどうかを示します。コンテンツを他のサイトに埋め込まないようにして、クリックジャッキング攻撃の防止をサポートします。

サイトの iframe をすべて拒否する: X-Frame-Options: DENY

ご利用のサイトのみに iframe（埋め込み）を許可する: X-Frame-Options: SAMEORIGIN

Content-Security-Policy サイトのコンテンツセキュリティポリシーを評価するために、Google の CSP 評価ツールを使用できます。インラインスクリプトを許可せず、HTTPS 経由でのみスクリプトを読み込む: Content-Security-Policy: default-src https:

既存のサイトに新しいセキュリティヘッダーを導入する際は、サードパーティのスクリプト、埋め込みコンテンツ（iframe など）、またはサイトの他の側面を壊すことがあるため、注意する必要があります。本番環境のトラフィックを変更する前に、バックエンドバケットかバックエンドサービスの 2 つ目のインスタンスを作成してテストすることをおすすめします。

ウェブセキュリティヘッダーとベストプラクティスの詳細については、web.dev と Mozilla の infosec サイトをご覧ください。

TLS と証明書の管理

マネージド証明書には次の特徴があります。

無料で提供されている
ロードバランサに簡単にデプロイ可能
自動更新
Google のすべてのエッジロケーションにグローバルに分散

TLS は、データが転送中に変更されていないかを検証することで信頼性を確保します。TLS 証明書は、ユーザーとサーバー間でやり取りされる内容を傍受者が判別できないようにすることで、機密性を確保します。これはユーザーのプライバシーとセキュリティを確保するために重要です。

SSL 証明書によって、HTTP/2 や Google の QUIC プロトコル（どちらも SSL（TLS）が必要）など、最新のトランスポートプロトコルを利用できます。これらのプロトコルは、ウェブコンテンツのパフォーマンス、メディア配信（ストリーミング動画など）、輻輳が発生しているネットワークの信頼性などを直接改善します。

Google Cloud では、Cloud Load Balancing サービスと Cloud CDN サービス全体で、最新の TLS プロトコル（TLS 1.3 など）がサポートされています。

TLS の最小バージョンは、SSL ポリシーを使用して引き上げることができます。組み込みデバイスや、ブラウザ以外の古いクライアント（10 年以上前）など、古いクライアントをサポートする必要がない場合は、TLS v1.2 にバージョンを引き上げることをおすすめします。グローバルにみると、TLS v1.0 と TLS v1.1 の利用は、Google Cloud 全体の接続の 0.5% 未満です。古いバージョンの TLS でクライアントを識別する必要や、クライアントを古いバージョンの TLS に関連付ける必要がある場合は、リクエストヘッダーで変数 {tls_version} を使用できます。その後この情報をログに記録できます。

次のステップ

Cloud CDN がキャッシュからレスポンスを配信しているかどうかを確認するには、ログの表示をご覧ください。
キャッシュに保存可能なコンテンツと保存できないコンテンツについては、キャッシュの概要をご覧ください。
Cloud CDN の接続拠点を確認するには、キャッシュのロケーションをご覧ください。

ウェブ セキュリティのベスト プラクティス