HSTS・HTTP/2・HTTP/3・CT logとは｜Webセキュリティの基礎
目次
この記事でわかること
- HTTPS を有効にしただけでは防げない「中間者攻撃」と、HSTS で何が変わるか
- HTTP/2・HTTP/3 がパフォーマンスとセキュリティの両面でなぜ標準になったか
- CT log（Certificate Transparency）が SSL 証明書の不正発行を抑止する仕組み
Web セキュリティの全体像｜4 つのレイヤー
「サイトに鍵マークが付いているから安全」という時代はすでに過去のものです。中小企業の Web サイトでも、現代の標準的な防御ラインは以下の 4 つのレイヤーで構成されます。
- HTTPS / SSL 証明書: 通信路の暗号化とサーバーの真正性確認（土台）
- HSTS: 「このドメインは常に HTTPS でアクセスしろ」とブラウザに記憶させる仕組み
- HTTP/2・HTTP/3: 通信の効率化と、現代的な暗号化方式（TLS 1.3）の前提
- CT log: 発行された SSL 証明書を全世界に公開し、不正発行を可視化する仕組み
それぞれ役割が違い、コスト負担なく追加できるものが大半です。順に見ていきます。
HTTPS と SSL 証明書｜大前提のチェック
HTTPS（Hypertext Transfer Protocol Secure）は、ブラウザとサーバー間の通信を TLS で暗号化する仕組みです。RFC 2818 で標準化され、現在では Google Chrome や Safari が「HTTP は安全でない」と警告を出すため、ビジネスサイトでは HTTPS が事実上の必須条件です。
ポイントは 2 つあります。
1. 証明書の有効期限管理
SSL 証明書には有効期限があり、Let's Encrypt なら 90 日、有償の証明書でも 1 年程度が現代の上限です。期限が切れるとブラウザが「この接続はプライベートではありません」という強い警告を出し、サイトへのアクセスが事実上停止します。
期限管理を手動運用に任せると忘れます。Let's Encrypt の certbot による自動更新や、AWS / Cloudflare のマネージド SSL のような自動化された仕組みを使うのが現代の標準です。証明書管理の詳細は SSL 証明書の有効期限を確認する 3 つの方法 も参照してください。
2. 証明書の信頼性
無料・有料に関わらず、現代の主要 CA から発行された証明書の暗号強度に大きな差はありません。ブランドや組織認証（OV / EV）が必要な場合のみ有料を選ぶ判断で十分です。
HSTS と HSTS preload｜中間者攻撃を防ぐ
HTTPS を有効にしても、最初のアクセスが HTTP（暗号化なし）で始まる場合、攻撃者が間に入って通信を傍受する余地が残ります。これを防ぐのが HSTS（HTTP Strict Transport Security、RFC 6797） です。
HSTS の動作
サーバーが Strict-Transport-Security: max-age=31536000 のようなレスポンスヘッダーを返すと、ブラウザは「今後 1 年間、このドメインへは HTTP でアクセスしようとしても自動的に HTTPS に切り替える」と記憶します。一度この状態になれば、次回以降は最初から HTTPS で通信されるため、HTTP 経由の盗聴・改ざんを根本から防げます。
HSTS preload
HSTS の弱点は「初回アクセス前は適用されない」ことです。ブラウザがまだそのドメインを知らない時点で HTTP 接続を試みると、攻撃の余地が残ります。これを完全に塞ぐのが HSTS preload です。
hstspreload.org というサイトで申請すると、Chrome・Firefox・Safari に「このドメインは初回から HTTPS のみ」というリストが組み込まれ、ブラウザの最新版で自動的に HSTS が有効になります。preload 申請には以下の条件があります。
- 有効な SSL 証明書が設定されていること
- すべてのサブドメインを HTTPS で公開していること（includeSubDomains 必須）
max-age=31536000（1 年）以上で HSTS ヘッダーを返していること- 申請後の取り下げに数ヶ月かかる（影響範囲が大きいため）
中小企業で HSTS preload まで申請する例は多くありませんが、ブランドサイトやログイン機能を持つサービスでは検討する価値があります。
HTTP/2 と HTTP/3｜現代の通信効率と暗号化
HTTP/2（RFC 7540）と HTTP/3（RFC 9114）は通信プロトコルの世代更新で、パフォーマンスとセキュリティの両面で従来の HTTP/1.1 より優れています。
HTTP/2 の利点
- 1 つの接続で複数リクエストを並列処理（HoL Blocking 改善）
- ヘッダー圧縮（HPACK）で通信量削減
- TLS 1.2 以上が事実上必須
HTTP/3 の利点
- TCP ではなく QUIC（UDP ベース）で通信
- 接続確立が高速化（特にモバイル回線で体感差大）
- TLS 1.3 が必須で、古い暗号化スイートが排除
ホスティング側の対応状況により、Cloudflare、AWS CloudFront、主要レンタルサーバーは HTTP/2 / HTTP/3 を標準対応しています。自社サイトが HTTP/1.1 のままだと、海外取引先などからのアクセスが遅く感じられる原因になります。
CT log｜証明書の透明性
CT log（Certificate Transparency、RFC 6962）は、発行された SSL 証明書を「世界中の誰でも閲覧できる公開ログ」に記録する仕組みです。Google、Cloudflare、DigiCert などが運営する複数の Log サーバーが、すべての発行済み証明書を時系列で公開しています。
何が嬉しいのか
- 自社ドメインで「身に覚えのない証明書」が発行されたら、CT log を監視して検知できる
- 証明書の不正発行（CA の内部不正、ドメイン乗っ取り等）が早期発見される
- ドメイン奪取の前兆として、不正な証明書発行が記録される事例がある
CT log の確認は crt.sh という無料サービスで自社ドメインを検索するだけで行えます。複数の CA から発行された痕跡があれば、過去のサービス変遷を追えます。逆に「使った覚えのない CA」からの発行があれば要注意です。
ドメイン奪取・証明書の不正発行については ドメイン管理の防御線（記事準備中） も合わせて確認することを推奨します。
まとめ｜中小企業の現実的な順序
Web セキュリティを底上げする現実的な優先順位は以下です。
- 最優先: HTTPS 化と SSL 証明書の自動更新の設定
- コスト負担なし: HSTS ヘッダーの有効化（max-age=31536000 から）
- ホスティングに依存: HTTP/2・HTTP/3 対応（多くは設定で済む）
- 継続監視: CT log を定期的に確認する習慣
DNS レコード全般の整理は DNS レコードの種類をわかりやすく で詳しく解説しています。
まずは現状を把握しましょう
無料のドメイン診断 では、HTTPS 接続・証明書期限・HSTS / HSTS preload 要件・HTTP/2-3 対応・CT log の多様性をまとめてチェックできます。設定状況を数秒で把握できるので、対策の優先順位を考える出発点としてご活用ください。
「自社の Web セキュリティ設定に不安がある」「HSTS preload を申請してよいか判断できない」といった場合は、お問い合わせ から専門家にご相談いただけます。設定変更の影響範囲を整理した上で、安全に進める手順をご案内します。