HSTSの概要

HSTS(HTTP Strict Transport Security)を利用する目的は、「HTTPSでの通信をクライアント（ブラウザ、ユーザ）に強制させること」と、「証明書の認証に関するエラーをユーザに無視・回避させないこと」です。
悪意ある人間が公衆Wi-Fiを持ち込んで、DNSやARPをいじられても、HTTP通信にフォールバックさせられないようにして、被害を防ぎます。

HSTSを使わない場合のセキュリティリスク：

HSTSの設定自体はシンプルで、適切な設定を行った「Strict-Transport-Security」を、サーバサイドから応答させるだけです。

レスポンスヘッダ例： Strict-Transport-Security: max-age=31536000; includeSubDomains

※サーバサイドと記載しているのは、バックエンドのサーバが応答することもありますし、
サーバの手前にあるリバースプロキシ（LBなど）が応答することもあるからです。

HSTSでややこしいポイントは、[ preload ] です。
本項の冒頭の動作は基本的にキャッシュとして、指定された期間中、HSTSの動作をします。
ただそれでは、HSTSヘッダを受け取っていない（HSTSの動作を理解していない）状態のブラウザを保護することができません。

そこで [ preload ] を利用します。
[ preload ] を利用するにはGoogleのHSTS事前読み込みサービスにドメインを登録する必要がありますが、
初回アクセスからHSTSによる保護が行えます。

preloadを利用しない場合には、HTTPでアクセスされたときに、HTTPSへリダイレクトさせる設定を
使用する必要があります。（先述の通り、この時にブラウザとしてはリクエストを送ってしまいます。）

preload未使用時の中間者攻撃リスク：

preload使用時にはリスク低減される：

読んでいると、 [ preload ] を設定するべきじゃないか、と見えますが、実際はそういうわけでもなく、
Googleも受けられるメリットもごくわずかと言っています。
最近のブラウザはHTTPアクセスを自動的にHTTPSにアップグレードしてリクエストを試みるため、
「HTTPを明記したURL」に「攻撃者が詐称したドメインにアクセスされうるネットワーク」でアクセスしないと実害はないので、preloadの設定を誤るリスクのほうが高いと考えることもできます。

 

利用時に気を付けること

まず、HSTSはロールバックが難しいと認識しておくとよいです。
切り戻しが難しいので、徐々に設定を固めていくようなイメージを持っておきましょう。

前提部分での気を付ける事項

・HTTPSのみでリクエストを受け入れられる状態か確認します

レガシーなシステムだとHTTPでのリクエストを受け入れている場合があります。
その場合にはHSTS以前の問題になりますので、先にHTTPでのアクセスをHTTPSにリダイレクトさせる設定を入れてHTTPSのみでのアクセスを行わせるか、環境によっては設定をあきらめなければいけません。

・どこでHSTS用ヘッダを挿入するのか考えます

リバースプロキシ（CDN、LB）で有効化する方法と、バックエンドのサーバで有効化する方法があります。
これは完全にアプリケーション次第です。
includeSubDomainsを有効化する場合には、全てのサブドメインからもHSTSを応答するのが望まれるため、バックエンドのサーバで応答したほうが管理しやすいかもしれないですし、
まとめてLBでトラフィックを受けているならば、LBで挿入する方法もあります。
個人的な感覚としては、インフラ系のHTTPヘッダ操作はリバースプロキシでやるのが自然だと思います。

環境によって差はあるかと思いますが、ディレクティブごとに考慮ポイントがあります。

max-age　（必須）

ブラウザがHTTPS強制を記憶する期間（秒）です。
最終的には1年にすることを目的にするとよいかと思います。
max-ageの有効期間中でも、HTTPS通信が成立していれば新しいHSTSヘッダによって設定変更は可能ですが、HTTPS通信自体ができなくなると修正不能になります。
そのため、設定ミスがあった場合に備えて、最初は分、数時間、数日にして、問題が起きなければ半年、1年と伸ばしていくようにしていったほうが良いかと思います。
本番環境と開発環境でドメインが異なることもあるので、開発環境の設定が問題なくとも、本番環境の設定時にミスがあることも考えられるため、どちらでも徐々に伸ばしていくという対応は必要になると思います。

後述していますが、preloadを利用する場合には、1年以上のmax-ageを設定する必要があります。

includeSubDomains （オプション）

設定すると、HSTSポリシーを全サブドメインに適用することになります。
基本的には有効化することを前提に考えるオプションとなります。
後述していますが、preloadの設定をする場合には、必ず設定しなければいけません。
全サブドメインであるため、[ example.com ] で適用したら、[ secure.example.com ]
[ api.secure.example.com ] [ another.example.com ] においても適用されます。

Webアプリケーションでは、1つのアプリケーション内で用途ごとにサブドメインを分けることがあります。
includeSubDomainsを設定すると、無制限の階層に対してHSTSがかかってしまうので、
テスト/開発環境用、本番用（API用、静的コンテンツ用等）、将来追加されるドメイン、それぞれも
管理していく必要があります。

誤字によっては、HSTSに掛けたい対象が、同一サブドメイン判定されないことも起こり得ますので、
気をつけましょう。（逆もまたしかりですが…）

preload (オプション)

HSTSの事前読み込み（プリロード）を行うためのオプションですが、
RFCとして記載があるわけではありません。
利用するには、Googleのサービス（https://hstspreload.org/）にドメインを登録する必要があり、
一部有志による取り組みとなります。

preloadを設定するタイミングは、max-ageを一年以上にして、includeSubDomainsを有効化にして問題がなくなった時点で、preloadを設定して、ドメインを登録するような流れになります。
（先にも書いていますが、HTTP→HTTPSへのリダイレクト設定も登録要件として必要になります。）

preloadは、クライアントサーバ間の通信による動作指定ではなく、もっと大きな仕組みによるブラウザへの直接的な命令になります。
よく考えずにpreloadを設定したことで、以下のようなトラブルがあるようです。

”一部のサブドメインがHTTPSをサポートしていないことに気づかず、プリロードリストに登録されてしまったというサイト運営者から、定期的にメールが届きます。
こうしたサイトでは、削除に時間がかかり、手間がかかる傾向があります。”

Chromeのソースコードにハードコードされるため、安定版への反映にも時間がかかるうえ、
他のブラウザでの削除対応も正しく行われる保証もないと記載されています。
長期的にHSTSをサポートできないならリクエストをしないほうが良いとGoogleからもアナウンスがあります。

まとめ

最近は脆弱性スキャナーでHSTSの有効状態をチェックされるため、耳にすることが増えました。
ただ、インフラとセキュリティのちょうど、狭間にある設定だったため、よくわかっていない方が多い印象を持っています。

特にpreloadの設定については、RFCとしても書かれていないものの、皆が設定したほうがいいと言っているから、よくわからず設定されているケースも目の当たりにしていますので、各位気を付けていただければと思います。

記載されている会社名、システム名、製品名は一般に各社の登録商標または商標です。

当社製品以外のサードパーティ製品の設定内容につきましては、弊社サポート対象外となります。