Nextcloudを提供するHTTPSエンドポイントにHSTSヘッダーを追加する

max-ageNextcloud の「Strict-Transport-Security」警告は、公開 HTTPS レスポンスに、少なくとも180 秒 (180 日)の HSTS ヘッダーが見つからなかったことを意味します15552000。HTTPS を提供する Web サーバーまたはリバース プロキシでヘッダーを追加し、その公開 URL を正確にテストしてください。HSTS は Nextcloud の設定項目ではなくconfig.php、通常の HTTP レスポンスではブラウザで HSTS ポリシーを確立することはできません。

設定を変更する前に確認すべき事項

• NextcloudサイトがHTTPS経由で正しく読み込まれ、ホスト名に対して有効な証明書が表示されていることを確認してください。
• TLSを終端するサービス（Apache、NGINX、ロードバランサー、コンテナイングレス、または外部プロキシ）を特定します。
• そのサービスが既に設定しているかどうかを確認してくださいStrict-Transport-Security。公開TLSエンドポイントから意図的に1つのポリシーを送信してください。重複または競合するヘッダーがあると、検証が混乱します。
• を追加する前に、すべてのサブドメインがHTTPSに対応しているかどうかを確認してくださいincludeSubDomains。preloadこの警告をすぐに解消する方法として有効にしないでください。

HSTS は、ホスト名への今後の接続には HTTPS を使用する必要があることをブラウザーに伝えます。ブラウザーがポリシーを受け取った後に HTTP にダウングレードされるのを防ぐのに役立ちます。TLS を置き換えたり、無効な証明書を修正したり、最初の HTTP アクセスをリダイレクトしたりするものではありません。別途 HTTP から HTTPS へのリダイレクトも設定してください。Nextcloud 35 の管理マニュアルでは、最小値 15552000 秒が示されており、Web サーバーでヘッダーを設定することを推奨しています。プロキシ展開における実際の強制ポイントは、訪問者に応答を返すコンポーネントです。

基本方針を設定する

Nextcloudホスト名の保守的な初期設定ポリシーは次のとおりです。

Strict-Transport-Security: max-age=15552000

これは、すべてのサブドメインにポリシーを自動的に適用することなく、Nextcloud ドキュメントの最低限の有効期間を満たします。関連するすべてのサブドメインが継続的に HTTPS をサポートしていることを確認したら、 を追加することを検討できます; includeSubDomains。このディレクティブを学習したブラウザは、これらのサブドメインでも HTTPS を要求します。HTTP に依存している内部ダッシュボード、メールホスト、またはレガシーサービスは、移行されるかポリシーの有効期限が切れるまで、そのブラウザではアクセスできなくなる可能性があります。

Apache

Apache TLS仮想ホストの場合、mod_headersポート80のリダイレクトホストだけでなく、HTTPS仮想ホスト内にもディレクティブを有効にして配置してください。

<VirtualHost *:443>
    ServerName cloud.example.com
    # Keep the existing TLS and Nextcloud configuration here.
    <IfModule mod_headers.c>
        Header always set Strict-Transport-Security "max-age=15552000"
    </IfModule>
</VirtualHost>

サンプルホスト名を置き換え、既存の証明書、プロキシ、またはPHP構成はそのまま使用してください。NextcloudのApache強化例では、Header always setHTTPS仮想ホストを使用しています。ディストリビューションでサポートされているconfig-testコマンドを使用してApache構成を検証し、テストに合格した場合のみApacheを再起動してください。

NGINX

serverNGINXでは、公開されているNextcloudホスト名でHTTPS接続をリッスンするブロック内に、以下のヘッダーを追加します。

server {
    listen 443 ssl;
    server_name cloud.example.com;
    # Keep your existing TLS and Nextcloud locations here.
    add_header Strict-Transport-Security "max-age=15552000" always;
}

この設定をサーバーの既存の設定の完全な代替として貼り付けないでください。NGINX ヘッダーの継承は、ネストされたロケーションが独自のadd_headerディレクティブを定義しているかどうかに依存する場合があります。有効な設定を確認し、静的アセットや DAV エンドポイントを含む代表的なレスポンスをテストしてください。公式の Nextcloud NGINX サンプルには、HTTPS 設定に HSTS 設定が含まれており、管理者に対してプリロードを有効にするよう注意喚起しています。

リバースプロキシまたはイングレス

ロードバランサー、イングレス、またはホスト型プロキシが、Nextcloud にトラフィックを転送する前に HTTPS を終端する場合、アーキテクチャで意図的に信頼できるアップストリームに HSTS を追加しない限り、そのパブリック TLS レイヤーで HSTS を設定してください。バックエンドのみで追加されたヘッダーは、プロキシによって削除または置き換えられる可能性があります。逆に、両方のレイヤーで設定すると、重複した値が生成される可能性があります。プロキシのレスポンス ヘッダー構成を確認し、テスト対象の HTTPS ルートであることを確認してください。Nextcloud の trusted-proxy および HTTPS URL 設定は、既存のデプロイメントと一貫性を持たせてください。ただし、これらの設定をヘッダーの送信の代替として扱わないでください。

公開された回答を検証する

1. 変更したウェブサーバーまたはプロキシの設定については、プラットフォームの構文チェッカーを使用してください。
2. 検証済みの構成を再読み込みまたはデプロイします。
3. 公開HTTPSアドレスをリクエストし、レスポンスヘッダーを調べます。少なくとも である行curl -sSI https://cloud.example.com/を1つ探します。Strict-Transport-Securitymax-age15552000
4. ブラウザの開発者ツールで、同じパブリックホスト名からの応答を調べてください。これにより、ヘッダーを改ざんするプロキシや、想定される仮想ホストを迂回するルートが明らかになる場合があります。
5. Nextcloudの「管理」→「概要」ページを再読み込みし、セキュリティチェックが更新されるまで待ちます。

HSTS ヘッダーが表示されない場合はcurl、DNS が編集したエンドポイントを指していること、リクエストが HTTPS を使用していること、プロキシがヘッダーを削除していないことを確認してください。ヘッダーがホームページには表示されるが他のレスポンスには表示されない場合は、NGINX のロケーション レベルのディレクティブまたはプロキシのレスポンス ヘッダー ルールを確認してください。パブリック レスポンスが正しいにもかかわらず Nextcloud が警告を表示する場合は、管理者チェックで外部から見えるホスト名とスキームが同じであることを確認し、サーバーとチェックの間にあるキャッシュまたはプロキシ レイヤーを調べてください。

ドメイン全体の見直しを行った後にのみ、プリロードを使用してください。

プリロードは、影響の大きい別の選択肢です。プリロードディレクティブ自体はドメインを登録しません。ブラウザのプリロードリストには、それぞれ独自の提出要件があります。現在のブラウザのガイダンスでは、登録に長い手順max-ageとフォームが必要ですincludeSubDomains。Nextcloud は、出荷済みのプリロードリストから削除しても、インストールされているブラウザに反映されるまでに数か月かかる場合があると警告しています。まずは基本ポリシーから始め、影響を受けるすべてのホスト名を一覧し、ドメイン全体で HTTPS が機能することを確認し、適用する前に公式のプリロード要件を確認してください。ほとんどの Nextcloud 管理者は、プリロードを有効にしなくても、この特定の警告を解決できます。

参考資料：Nextcloud 35 のセキュリティ警告、Nextcloud のセキュリティ強化に関するガイダンス、Nextcloud NGINX の設定、およびMDN の HSTS ヘッダーのリファレンス。