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

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

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

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

HTTP 仕様には、以下を制御する多数のヘッダーがあります。

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

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

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

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

ヘッダー名 説明 使用例
Strict-Transport-Security(HSTS) このヘッダーを設定する前に、ドメインに有効な SSL(TLS)証明書があることを確認してください。

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

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

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

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

次のステップ

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