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

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

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

セキュリティ ヘッダーの設定

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

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

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

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.comexample.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 の接続拠点を確認するには、キャッシュのロケーションをご覧ください。