## この記事でわかること

- HTTPS を有効にしただけでは防げない「中間者攻撃」と、HSTS で何が変わるか
- HTTP/2・HTTP/3 がパフォーマンスとセキュリティの両面でなぜ標準になったか
- CT log（Certificate Transparency）が SSL 証明書の不正発行を抑止する仕組み

## Web セキュリティの全体像｜4 つのレイヤー

「サイトに鍵マークが付いているから安全」という時代はすでに過去のものです。Web サイトでも、現代の標準的な防御ラインは以下の 4 つのレイヤーで構成されます。

![Webセキュリティの4レイヤー](/blog/web-security-overview/web-security-layers.svg)

- **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 つの方法](/blog/ssl-expiration-check) も参照してください。

### 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がHTTPSダウングレード攻撃を防ぐ](/blog/web-security-overview/hsts-flow.svg)

### HSTS preload

HSTS の弱点は「初回アクセス前は適用されない」ことです。ブラウザがまだそのドメインを知らない時点で HTTP 接続を試みると、攻撃の余地が残ります。これを完全に塞ぐのが **HSTS preload** です。

[hstspreload.org](https://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](https://crt.sh/) という無料サービスで自社ドメインを検索するだけで行えます。複数の CA から発行された痕跡があれば、過去のサービス変遷を追えます。逆に「使った覚えのない CA」からの発行があれば要注意です。

ドメイン奪取・証明書の不正発行については [ドメイン管理の防御線（記事準備中）](/diagnose) も合わせて確認することを推奨します。

## まとめ｜現実的な順序

Web セキュリティを底上げする現実的な優先順位は以下です。

- **最優先**: HTTPS 化と SSL 証明書の自動更新の設定
- **コスト負担なし**: HSTS ヘッダーの有効化（max-age=31536000 から）
- **ホスティングに依存**: HTTP/2・HTTP/3 対応（多くは設定で済む）
- **継続監視**: CT log を定期的に確認する習慣

DNS レコード全般の整理は [DNS レコードの種類をわかりやすく](/blog/dns-record-types) で詳しく解説しています。

## まずは現状を把握しましょう

[無料のドメイン診断](/diagnose) では、HTTPS 接続・証明書期限・HSTS / HSTS preload 要件・HTTP/2-3 対応・CT log の多様性をまとめてチェックできます。CSP / X-Frame-Options / Referrer-Policy / [Permissions-Policy](/blog/permissions-policy-toha) のセキュリティヘッダに絞って単発で確認したい場合は、[Web セキュリティヘッダ 単発チェック](/security-headers/check) が 30 秒で結果を返します。設定状況を数秒で把握できるので、対策の優先順位を考える出発点としてご活用ください。

「自社の Web セキュリティ設定に不安がある」「HSTS preload を申請してよいか判断できない」といった場合は、[お問い合わせ](/contact) から専門家にご相談いただけます。設定変更の影響範囲を整理した上で、安全に進める手順をご案内します。