第10章　Webとセキュリティの入り口 — 鍵マークの正体(読み物)

この章について

この章は 読み物(参考資料) です。演習も提出もありません。テーマは、毎日使うWebの仕組みと、アドレス欄の 鍵マークの正体 です。第7章の総集編で「Webページが表示されるまで」を配達の観点で追いました。この章は、その 中身と安全 を扱います。

この章で登場する略語です(読み流して構いません)。

• URL(Uniform Resource Locator)… Webページの所在を表すアドレス
• HTTP / HTTPS(HyperText Transfer Protocol / — Secure)… Webのやり取りの約束事と、その暗号化版
• TLS(Transport Layer Security)… HTTPSの暗号化を担う仕組み
• Cookie(クッキー)… サーバーが端末に預ける小さなデータ

10-1 URLの構造 — 3つの部品

Webページのアドレス(URL)は、3つの部品で構成されます。

https://www.example.com/products/list.html

部品	上の例では	意味
スキーム	https://	通信の約束事の指定(ここでは暗号化ありのWeb)
ホスト名	www.example.com	どのサーバーか(DNSがIPアドレスに変換する — 第7章)
パス	/products/list.html	そのサーバーの中の、どのリソースか

ホスト名まではDNSと配達の仕組みが担当し(第7章まで)、ホスト名の先(パスの解決)はWebサーバーが担当します。後半がこの章の範囲です。

10-2 HTTP — 要求と応答の繰り返し

ブラウザーとWebサーバーのやり取りの約束事が HTTP です。構造は単純で、要求(リクエスト) と 応答(レスポンス) の繰り返しです。

レスポンスの先頭には、結果を表す3桁の ステータスコード が付きます。

コード	意味
200	OK(正常)
404	リソースが見つからない(リンク切れのときに表示される画面)
500番台	サーバー側のエラー

「404 Not Found」は、Webサーバーからの「そのパスにリソースが存在しない」という応答です。ネットワークの故障ではなく、正常な応答の一種です。

10-3 Cookie — 状態を保持する仕組み

HTTPは、1回のやり取りごとに状態を保持しません(ステートレス)。サーバーは、前回の要求元を記憶していません。

しかし実際には、一度ログインしたサイトはログイン状態が維持されます。これを実現するのが Cookie です。サーバーは最初の応答に「次回以降、この識別子を提示してください」という小さなデータを添えます。ブラウザーはそれを保存し、以降の要求に毎回添付します。サーバーは識別子を見て「同じ利用者だ」と判別します。

• 利点: ログイン状態・カートの内容・言語設定などが保持される
• 注意点: 識別子を盗まれると、なりすましが可能になる。だから次節の暗号化が重要になる

10-4 HTTPSの2つの保護 — 暗号化と認証

アドレス欄の鍵マーク(https)は、2つの保護のセット を意味します。

図10-1 HTTPS = 暗号化 + サーバー認証

保護① 暗号化 — 経路上では読めない

HTTPSの通信は、中身が TLS によって暗号化されます。途中の経路で受信されても、意味のある内容としては読めません。第9章の「暗号化なしのWi-Fi」でも、HTTPSのサイトなら中身が保護される、と言えた理由がこれです。

ここで疑問が生じます。「暗号化の鍵を、どうやって相手に渡すのか。渡す過程を盗聴されたら無意味では?」

この問題は 公開鍵暗号 で解決されます。サーバーは「誰でも暗号化できるが、対応する秘密鍵を持つ本人しか復号できない鍵(公開鍵)」を配ります。ブラウザーは、本番の暗号化に使う共通の鍵をこの公開鍵で暗号化して送り返します。暗号化された鍵は、秘密鍵を持つサーバーだけが復号できます。こうして、盗聴されても安全に共通鍵を共有してから、本番の暗号化通信が始まります。

保護② サーバー認証 — 相手が本物である確認

暗号化だけでは不十分です。通信相手そのものが偽物 であれば、暗号化して偽物に届けるだけになります。

そこでHTTPSのサーバーは サーバー証明書 を提示します。これは「このサーバーは正規の www.example.com である」ことを、信頼できる第三者機関(認証局)が保証する電子的な身分証です。偽サイトは正規の証明書を提示できないため、ブラウザーが警告を表示します。

フィッシング詐欺への重要な視点がここにあります。鍵マークは「通信が保護されている」ことの印であって、「相手が善良」であることの印ではありません。 偽サイトが自分名義の正規証明書を持っていることもあります。鍵マークの確認とあわせて、ホスト名(ドメイン)が正しいか を確認する習慣が有効です。

10-5 プロキシ — 代理アクセスの仕組み

会社のPCで「プロキシ設定」という項目を見たことがあるかもしれません。プロキシ(proxy)は、社内からWebへのアクセスを 代理で行う中継役 です。

社内のブラウザーは、Webサーバーへ直接ではなく、いったんプロキシに「このページを取得してほしい」と依頼します。会社がプロキシを置く目的は主に2つです。

• 保護 — 危険なサイトへのアクセスを、入り口でまとめて遮断できる
• 記録・管理 — 業務PCのWebアクセスを監査できる

「家庭では閲覧できるサイトが、会社では閲覧できない」現象の多くは、このプロキシによる制御です。故障ではなく、会社の設計どおりの動作です。

10-6 クラウド — サーバーの利用形態

第1章で「サーバーは特別な機械ではない」と学びました。現在では、そのサーバーを 自社で保有せず、利用形態として借りる のが主流です。これが クラウド です(自社で保有する形態は オンプレミス と呼びます)。

借り方には段階があります。

利用形態	借りる範囲	自分で用意するもの
IaaS	仮想的なサーバー(ハードウェア相当)	OS・ミドルウェア・アプリケーション
PaaS	実行環境まで	アプリケーションのみ
SaaS	完成したサービス	なし(利用するだけ。Webメール・会議サービスなど)

普段使うWebメールやオンライン会議は、SaaSというクラウドの利用形態です。ニュースや商談で登場するクラウド用語も、この分類で整理できます。

もう一歩深く

デジタル署名 — 「本人が作成した」ことの証明

公開鍵暗号の仕組みは、逆向きにも使えます。本人だけが持つ秘密鍵で「封」をすると、対応する公開鍵で「本人が封をした・途中で改ざんされていない」ことを誰でも検証できます。これが デジタル署名 で、サーバー証明書の信頼もこの仕組みで支えられています。

QUIC

第6章の「もう一歩深く」で登場したQUIC(HTTP/3)は、この章で見たHTTPのやり取りと暗号化を、UDPの上でより高速に行う新しい方式です。今日閲覧したWebページのいくつかは、すでにQUICで届いています。

よくある誤解

誤解	実際
鍵マークがあるサイト=信用してよいサイト	鍵マークは「通信の保護」の印です。偽サイトも鍵マークを持てるため、ホスト名の確認が必要です。
Cookieは危険なもの	ログインやカートを支える基本の仕組みです。「識別子を盗まれるとなりすまされる」性質を理解して使うのが正しい対応です。
404エラーはネットワークの故障	配達は成功しています。「そのリソースが存在しない」というWebサーバーからの正常な応答です。
会社で閲覧できないサイトがある=ネットワークの不調	プロキシによる制御である場合がほとんどです。
クラウドは遠隔地の特別な技術	実体は「他社のデータセンターにあるサーバーを、ネットワーク越しに借りる」ことです。この研修で学んだ仕組みの上に載っています。

まとめ

• URLは スキーム + ホスト名 + パス の3部品
• HTTPは要求と応答の繰り返し。404はリソースが見つからないという正常な応答
• Cookie はHTTPに状態を持たせる仕組み。ログイン状態が保持される理由
• HTTPS = 暗号化(TLS) + サーバー認証(証明書) の2つの保護。ただし「相手が善良」の保証ではない
• プロキシ は代理アクセスの中継役(保護+記録)
• クラウド はサーバーの利用形態(IaaS/PaaS/SaaS)

考えてみよう(答えは1つではありません)

1. 銀行を名乗るメールのリンク先に、鍵マークが付いていました。それでも入力をためらうべき理由を、この章の言葉で説明できますか。
2. 「会社のPCだけ、あるサイトが開けない」— 故障を疑う前に確認したいことは何でしょうか。
3. あなたが普段使うサービス(メール・地図・動画など)は、SaaS/PaaS/IaaSのどれに当たりそうですか。

考え方のヒントを表示する

1. 鍵マークは「通信の暗号化」と「そのホスト名の持ち主であること」までしか保証しません。ホスト名そのものが銀行の正しいドメインか を確認する必要があります(10-4)。
2. プロキシやフィルターによる制御の可能性です(10-5)。管理部門に「このサイトは業務で必要」と相談するのが正しい手順です。
3. 利用するだけならSaaS、実行環境を借りていればPaaS、仮想サーバーそのものを借りていればIaaSです(10-6)。

関連章

• 第6章 TCP/IP — HTTPのやり取りは、TCPの確実な配達(と最新のQUIC)の上に載っています
• 第7章 ネットワークサービスとインターネット — URLのホスト名をIPアドレスに変換するのはDNSでした。総集編の「その先」がこの章です
• 第9章 無線LAN(Wi-Fi)(読み物) — 「暗号化なしのWi-FiでもHTTPSなら中身は保護される」の理由がつながりました
• 将来の発展編 — 暗号の仕組みの詳細、証明書の検証、Webアプリケーションのセキュリティは、そちらで扱う予定です