はじめに
セキュリティの設計をしていて気づくことがあります。
「強くする決定」は、技術的にはほとんどの場合「正しい」とされます。Content Security Policy を厳しくする、SameSite cookie を Strict にする、HSTS の max-age を長くする — どれも教科書には「やったほうがいい」と書いてあります。
ところが運用に入ると、別の質問が立ち上がってきます。
「この強化、もし間違っていたら、いつ・どうやって戻せるんですか?」
セキュリティ強化の中には、やった瞬間に取り消すのが極めて難しくなる 種類のものがあります。本記事は、niyase がベータリリース時点で HSTS Preload list への申請を意図的に保留した 、その判断の記録です。
HSTS Preload list とは何か
ごく簡単に: ブラウザに「このドメインは今後一切 HTTP で繋がず、HTTPS のみで繋ぐ」という命令を、サーバから受け取らないでも最初から覚えておくための仕組みです。
仕組みとしては、Google / Mozilla / Apple / Microsoft が共同で管理する「HTTPS 必須ドメインリスト」がブラウザのバイナリに焼かれており、リストに入ったドメインへの HTTP アクセスはブラウザが自動で HTTPS に切り替えます。
→ 詳細は 12 万ドメインがブラウザに hardcoded されている話 で書きました。
セキュリティの観点では、HTTPS で繋ぐ Web サービスにとって最強の HTTPS 強制機構 です。ユーザーが公衆 Wi-Fi で http://niyase.com と打っても、攻撃者は中継できません。
「強化 = 善」という業界バイアス
セキュリティ業界では、SOC 2 や ISO 27001 の審査でも、「できるだけ強い設定にしているか」を見るチェックリストがあります。
- HSTS は configured されているか?
- max-age は十分長いか? (推奨: 1 年以上)
- includeSubDomains か?
- preload は?
すべて Yes だと、チェックリストはすべて満たされた状態になります。これらの審査はセキュリティの基準を底上げする大切な仕組みで、私たちも GA に向けて取得を準備しています。
ただ、ここで私たちが意識しているのは、「強化 = 善」という前提だけでは判断しきれない領域がある ということです。チェックリストは設定の強さを確認できますが、その設定が将来取り消したくなる可能性、つまり可逆性までは評価できないと私たちは考えています。
取り消せない権利の重さ
HSTS Preload list の取り消しは、技術的にはこういう手順です。
- niyase の HSTS ヘッダから
preloadディレクティブを削除 + max-age 短縮 - hstspreload.org の取り消しフォームから申請
- Chromium developers が手動レビュー (数週間)
- 承認されると、次の Chrome リリース で取り消しが反映
- Firefox / Safari / Edge も Chrome のリストを取り込むため、順次反映
問題は最後の 2 段です。Chrome のリリースサイクルは 4〜6 週、各ブラウザの取り込み・配信を含めると、全ユーザーの手元から消えるまで 3〜6 ヶ月 かかります。
その間、もし niyase に「特定のサブドメインで HTTPS が一時的に維持できない事態」が起きていたら、そのサブドメインにアクセスしようとした全ユーザーが「HTTPS でしか接続できないが HTTPS が落ちている」 = アクセス不能の状態になります。
ベータリリース直後の SaaS にとって、これは大きすぎるリスクです。
β 期間中に何が起きうるか
セキュリティを「最強」に固めると失敗する場面を、いくつか想定してみました。
サブドメインの追加
ベータ期間中に「investor.niyase.com を急遽追加したい」となったとき、preload で includeSubDomains を固定していると、その新サブドメインも 最初から HTTPS 必須。証明書の準備が間に合わないと、関係者の手元で「接続不能」が一斉に起きます。
開発サブドメインの公開的テスト
alpha.niyase.com のような実験的環境を、特定パートナーだけに HTTP でアクセス検証してもらいたいケース。preload で固定していれば不可能 (HTTPS 化が前提)。
急な路線変更
ベータの 1 年間で、niyase 自体の URL 構成が変わる可能性はゼロではありません。*.niyase.app のような別ドメインへの移行、サブドメイン構成の再編 — preload にがっちり固めていると、これらの判断が後手に回ります。
これらはすべて「たぶん起きない」ものですが、ベータ期間の本質は「たぶん起きないことが起きた時の対応速度」です。
β 期間中の判断 — max-age=86400
niyase の現在の HSTS 設定は、6 アプリすべてで以下に統一しています。
Strict-Transport-Security: max-age=86400; includeSubDomains
- max-age=86400 = 24 時間
- includeSubDomains = サブドメインまで含む (これは入れて良いと判断、サブドメインは β 期間中も HTTPS 確定運用)
- preload なし = リストには申請しない
「max-age=86400」を選んだ意味は、もし何か気づいたら 24 時間後には全ユーザー設定が自然消滅する ということです。間違いを正す機動性を、信頼の代わりに諦めない。
これは技術的には「最強」ではありません。ベータ期間中に偶然発生する SSL strip 攻撃 (中間者攻撃) の窓は、24 時間分残ります。
しかしこれを「弱い」と批判するのは、「強さ」と「責任」を取り違えています。私たちは、強さよりも「間違えた時に最短で戻せること」を、ベータ期間の責任として選びました。
GA 移行時の申請計画
ベータの間ずっと max-age=86400 でいくわけではありません。以下のロードマップを公開しています。
| Phase | max-age | preload | 適用条件 |
|---|---|---|---|
| ベータ初期 (現在) | 1 日 | なし | リリース時の初期設定 |
| ベータ安定期 | 30 日 | なし | サブドメインの HTTPS 化全件確認後 |
| ベータ後期 | 1 年 | なし | 30 日運用で問題なし |
| GA 直前 | 2 年 | あり (申請) | SOC 2 Type II 取得後 (認証取得を準備中) |
| GA 後 | 同上 | リスト反映 | hstspreload.org 申請成功 |
このロードマップで重要なのは、preload 申請を SOC 2 Type II 取得とセットにした ことです。
SOC 2 Type II は、6 ヶ月以上にわたって運用実態が記録されていることを第三者に評価してもらう認証です。HSTS preload に「取り消せない権利」を背負わせるためには、それと同程度の運用安定性を社内で確認しておく必要があります。
「認証取得と同時期に申請する」というのは、認証を便宜的に使う のではなく、認証取得プロセス自体を 運用成熟度のチェックポイント にする、という発想です。
「強くしないと選んだ理由」を説明する責任
セキュリティ系の意思決定で、私たちが大事にしている考え方があります。
「強くする判断を説明することと同じくらい、強くしないと選んだ理由を説明することを大事にする」
「全部 HTTPS、preload で固めました!」と書いてあれば、読者は安心できます。
逆に「max-age 1 日です、preload はまだです」と書くと、不安になる人がいるかもしれません。
その不安に向き合わずに「強く設定すれば批判されない」ことだけ選ぶと、いずれ間違えた時の修正が遅れる 組織になります。これは技術的には「正しい」けれど、経営判断としては短絡的です。
niyase は、自分たちの判断を 対外的に説明できるレベルで言語化する ことを、ブランドの一部として位置付けています。本記事はその実践です。
おわりに
セキュリティ強化の選択肢があった時、
「これは強くしたい、なぜか」 「これは強くしないと選ぶ、なぜか」
の 両方を説明できる組織 であり続けたいと思います。
HSTS Preload list 申請は、ベータが安定し、SOC 2 Type II 認証 (準備中) を取得して、私たち自身が「これで安定して運用できる」と確信を持った時に申請します。それまでは max-age=86400 の慎重運用です。
「取り消せない権利」を持つということは、それだけの責任を背負うということ。その重さを、設計の段階で十分に考えてから持ちたいと考えています。