第3部ネットワーク

第11章アプリケーション層 — HTTP・メール・SSH

ここまでの章で、データが宛先まで届く「土台」を学びました。この章では、その土台の上で私たちが実際に使うサービス——Web、メール、遠隔ログイン——の言葉、つまりアプリケーション層のプロトコルを見ていきます。仕組みを知ると、「なぜHTTPSでないと危ないのか」「なぜSSHは鍵を使うのか」が腑に落ちます。第3部の総仕上げです。

🎯 この章で学ぶこと

アプリケーション層のプロトコルとポート番号の関係
HTTP/HTTPSのリクエストとレスポンス、メソッドとステータスコード
curl -v で実際の通信を覗いて確かめる
メールの仕組み(SMTP/POP3/IMAP)となりすまし対策のさわり
SSHによる安全な遠隔ログインと公開鍵認証
平文プロトコルの危険と暗号化版への移行

11.1 アプリケーション層のプロトコルとは

アプリケーション層(第8章のOSIモデルの最上位)は、私たち人間が使うサービスに直接対応する層です。ここで使われるプロトコルは、「サービスの言葉」だと考えてください。Webを見るならHTTP、メールを送るならSMTP、サーバーに入るならSSH——それぞれ専用の言葉があります。そして第8章で学んだとおり、各サービスは決まったポート番号と結びついています。

プロトコル	用途	既定ポート	トランスポート
HTTP	Web(暗号化なし)	80	TCP
HTTPS	Web(TLSで暗号化)	443	TCP
SMTP	メール送信	25 / 587	TCP
IMAP / POP3	メール受信	143 / 110	TCP
SSH	安全な遠隔ログイン	22	TCP
DNS	名前解決(第10章)	53	UDP / TCP

これらはほとんどが、確実さを重視するTCP(第8章)の上で動きます。Webページやメールは1文字でも欠けると困るので、再送のあるTCPが向いているからです。

11.2 HTTP/HTTPS — Webの言葉

HTTP(HyperText Transfer Protocol)は、ブラウザ(クライアント)とWebサーバーがやり取りするためのプロトコルです。基本は非常にシンプルで、リクエスト(要求)とレスポンス(応答)の繰り返しです。ブラウザが「このページをください」と要求し、サーバーが「はい、これです」と返す。この1往復が基本単位です。

リクエストには、何をしたいかを表すメソッドが含まれます。代表的なものは次の2つです。

GET — 情報を取得する(ページを見る、画像を読み込む)
POST — 情報を送信する(フォーム送信、ログイン、投稿)

レスポンスには、結果を3桁の数字で表すステータスコードが付きます。この数字を読めると、トラブルの原因がぐっと分かりやすくなります。

コード	分類	意味
200	成功(2xx)	OK。正常に処理された
301 / 302	リダイレクト(3xx)	別のURLへ移動した(転送)
404	クライアント側エラー(4xx)	Not Found。ページが見つからない
403	クライアント側エラー(4xx)	Forbidden。アクセス権がない
500	サーバー側エラー(5xx)	サーバー内部でエラーが起きた

大まかに4xxは「要求した側(URLの打ち間違い・権限不足など)」、5xxは「サーバー側」の問題です。「404なら自分のURLを疑う、500ならサーバー管理者に連絡」といった判断ができます。

そして現在の主役は、HTTPをTLSで暗号化したHTTPSです。TLSは通信を暗号化し、盗み見(盗聴)や改ざんを防ぎ、さらに「接続先が本物のサーバーか」を証明書で確認します。だからブラウザは鍵マークを表示し、パスワードやカード番号を安全に送れるのです。HTTPSの仕組みは 🐍 入門コース第11章(Webセキュリティ入門)や 🛡️ セキュリティ中級・上級コース第6章でさらに深く扱います。

⚠️ HTTP(暗号化なし)の危険

ただのhttp://(ポート80)は通信が平文、つまり暗号化されていません。同じネットワーク上の第三者が通信を覗けば、入力したIDやパスワードが丸見えになります。特にカフェや空港の公衆Wi-Fiでは危険です。現在のWebサイトが軒並みHTTPSに移行したのはこのためで、ログインや個人情報を扱うページで http:// のままなら、その情報は保護されていないと考えてください。

11.3 実際にHTTPを覗く — curl -v

HTTPのやり取りは、curl というコマンドで実際に覗けます。-v(verbose、詳細)を付けると、送ったリクエストと受け取ったレスポンスのヘッダが見えます。mac / Linuxは標準搭載、Windowsも最近は標準で使えます。

$ curl -v https://example.com

* Connected to example.com (93.184.216.34) port 443    ← 443へTCP接続(第8章)
* TLS handshake, cipher TLS_AES_256_GCM_SHA384          ← TLSで暗号化(HTTPS)
> GET / HTTP/2                                          ← ここから送ったリクエスト
> Host: example.com
> User-Agent: curl/8.4.0
> Accept: */*
>
< HTTP/2 200                                            ← ここから受け取ったレスポンス
< content-type: text/html; charset=UTF-8
< content-length: 1256
<
<!doctype html>
<html> ... (本文のHTMLが続く) ...

読み方はシンプルです。行頭の記号が向きを表します。

> で始まる行 … こちら(クライアント)が送ったリクエスト
< で始まる行 … サーバーから返ってきたレスポンス
* で始まる行 … 接続やTLSに関する補足情報

1行目のリクエストは GET / HTTP/2、つまり「トップページ(/)をHTTP/2で取得したい」という意味です。返ってきた HTTP/2 200 がステータスコード200(成功)。続く content-type: text/html は「中身はHTMLですよ」という案内(ヘッダ)です。第10章の通しの流れ(名前解決 → 接続 → TLS → HTTP)が、この1回のコマンドにすべて詰まっています。ブラウザが裏で自動的にやっていることを、手で再現しているわけです。

✅ curlは切り分けの強い味方

ping が返らなくても(第9章のとおりICMPを止めているだけかもしれません)、curl -I https://example.com(-I はヘッダだけ取得)を打てば、Webサーバーが実際に応答するかを直接確かめられます。ステータスコードが200なら正常、404や500ならその内容から原因を絞れます。「Webが見えない」トラブルで、ブラウザのエラー画面より一段深く事実を確認できる道具です。

11.4 メールの仕組み — SMTP・POP3・IMAP

メールは、実は送るときと受け取るときで別のプロトコルを使います。ここを分けて理解するのがコツです。

プロトコル	役割	たとえ
SMTP	メールを送信・サーバー間で転送する	手紙を投函し、郵便局間で運ぶ
POP3	受信。サーバーからPCへダウンロードして取り込む	私書箱から手紙を持ち帰る
IMAP	受信。メールをサーバー上に置いたまま読む	私書箱に置いたまま出先で閲覧

送信はSMTPが担い、送り先のドメインの受信サーバーは第10章で学んだMXレコードで調べます。受信はPOP3かIMAPを選びます。POP3は端末にダウンロードして取り込む方式、IMAPはサーバーに置いたまま複数の端末(PC・スマホ)から同じ状態で読める方式です。今は複数端末で使うことが多いため、IMAPが主流です。

⚠️ なぜ迷惑メールやなりすましが起きるのか

SMTPは古くからあるプロトコルで、もともと送信者を名乗る部分(差出人)を自由に書けてしまうという弱点があります。封筒の差出人を勝手に「取引先の名前」と書けるようなもので、これがなりすましメール(スプーフィング)やフィッシングの温床になっています。この対策として、送信元を検証する仕組みが後から追加されました。

SPF — 「このドメインのメールは、このサーバーから送られるはず」を宣言(DNSのTXTレコード、第10章)
DKIM — メールに電子署名を付け、途中で改ざんされていないかを検証
DMARC — SPF/DKIMの結果をどう扱うか(拒否・隔離など)の方針を定める

ここでは「そういう対策が存在する」ことを押さえれば十分です。詳しくは 🧑‍💻 一人情シスコースなどの運用テーマで扱います。

11.5 SSH — サーバーへ安全に遠隔ログインする

サーバーの運用では、手元のPCから遠くのサーバーにログインして操作します。このとき使う定番がSSH(Secure Shell)です。通信全体が暗号化されるため、途中で覗かれても内容は読めません。使い方はシンプルで、ユーザー名とホスト(サーバー)を指定します。

$ ssh user@192.168.1.50          ← user として 192.168.1.50 にログイン
user@192.168.1.50's password:    ← (パスワード認証の場合)
...
user@server:~$                    ← ログイン成功。ここからは遠隔のサーバー上での操作

ログイン後は、第5章で学んだLinuxのコマンドがそのまま遠隔のサーバーに対して使えます。手元にいながら、遠くのサーバーを操作できるわけです。SSHはサーバー運用の主役の道具であり、第12章以降でも繰り返し登場します。

公開鍵認証 — パスワードより安全なログイン

SSHはパスワードでもログインできますが、実務では公開鍵認証が強く推奨されます。これはペアになった2つの鍵を使う仕組みです。

秘密鍵 — 手元にだけ置く、絶対に他人に渡さない鍵
公開鍵 — ログインしたいサーバーに登録しておく鍵(人に見られても構わない)

ログイン時、サーバーは公開鍵で「あなたが対応する秘密鍵を持っているか」を確認します。秘密鍵はネットワークに一切流れないため、盗聴されても認証情報が漏れません。仕組みのイメージは次のとおりです。

【手元のPC】                        【サーバー】
 秘密鍵(自分だけが持つ)   ←ペア→   公開鍵(登録済み)

 ① サーバー:「これに、あなたの秘密鍵で署名してみて」
 ② PC:秘密鍵で署名して返す(秘密鍵そのものは送らない)
 ③ サーバー:登録済みの公開鍵で署名を検証 → 一致すればログイン許可

公開鍵認証が安全なのは、次の理由からです。パスワードは「推測される・使い回される・盗聴される」危険が常にありますが、公開鍵認証ではそもそも認証の秘密(秘密鍵)がネットワークを流れません。また、総当たり攻撃で破ることが事実上不可能なほど鍵は複雑です。だからインターネットに公開するサーバーでは、パスワード認証を無効にし、公開鍵認証のみにするのが定石です。

💡 秘密鍵の扱いがすべて

公開鍵認証の安全性は、秘密鍵を漏らさないことに懸かっています。秘密鍵が盗まれれば、その人になりすましてログインされてしまいます。秘密鍵にはパスフレーズ(鍵を使うためのパスワード)を設定し、他人と共有せず、退職者の鍵はサーバー側から速やかに削除する——こうした鍵の管理が運用の重要な仕事になります。第9章のNIC由来のMACアドレスと同じく、「誰が本物か」を担保する要が鍵なのです。

11.6 ファイル転送とその他のプロトコル

最後に、実務でよく使う残りのプロトコルを押さえておきましょう。ここでも「暗号化されているか」が判断の軸になります。

プロトコル	用途	暗号化	備考
SFTP / SCP	ファイル転送	あり(SSH上で動く)	現在の標準。安全
FTP	ファイル転送	なし(平文)	ID・パスワードも丸見え。原則使わない
NTP	時刻同期	—	機器の時計を正確に合わせる

SFTPやSCPは、SSH(11.5)の安全な通信路の上でファイルをやり取りする方式で、現在の標準です。一方、古くからあるFTPはID・パスワードもファイルの中身も平文で流れるため、盗聴の危険があり、原則として避けるべきです。

NTP(Network Time Protocol)は、機器の時計を正確な時刻に合わせるプロトコルです。地味ですが運用では重要で、各サーバーの時計がずれていると、複数のサーバーのログ(第14章)を突き合わせて障害を追うときに時系列がバラバラになり、調査が非常に困難になります。「全機器の時刻を合わせておく」ことは、正しいログを残すための前提条件なのです。

🛡️ セキュリティ・運用の視点 — 平文プロトコルを捨て、鍵を守る

この章を貫くテーマは、「平文をやめて暗号化版へ移行する」ことです。HTTP→HTTPS、FTP→SFTP、Telnet→SSH——いずれも、旧来の平文プロトコルは通信内容やパスワードが第三者に丸見えになる危険があり、暗号化された後継に置き換えるのが鉄則です。特にTelnet(遠隔ログインの古い方式)は、ID・パスワードが平文で流れるため、SSHに完全に置き換えるべきものです。運用の現場では、「まだ平文プロトコルが残っていないか」を棚卸しし、暗号化版へ移すことが継続的な守りの仕事になります。もう一つの柱がSSH鍵の管理です。秘密鍵の保管(パスフレーズ設定・共有禁止)、入退社に伴う公開鍵の追加と削除、鍵の定期的な棚卸し——これらを怠ると、退職者の鍵が残り続けて不正アクセスの入口になりかねません。「暗号化されているか」と「鍵は誰の手にあるか」。この2つを問い続けることが、ネットワークを安全に運用する要です。この先の実務は、🧑‍💻 一人情シスコースや 🛡️ セキュリティ中級・上級コースへと続いていきます。

まとめ

アプリケーション層は人が使うサービスの言葉。各プロトコルは決まったポート番号を持つ
HTTPはリクエストとレスポンスの往復。メソッド(GET/POST)とステータスコード(200/404/500)が要点
HTTPSはTLSで暗号化。平文のHTTPはパスワードが丸見えになり危険
curl -v で実際のHTTPのやり取りを覗ける(>が送信、<が受信)
メールは送信SMTP、受信POP3/IMAP。SMTPの弱点からなりすましが生じ、SPF/DKIM/DMARCで対策する
SSHは暗号化された遠隔ログイン。公開鍵認証は秘密鍵を流さないためパスワードより安全
ファイル転送はSFTP/SCP(安全)を使い、平文のFTP/Telnetは避ける。NTPで時刻を合わせる

練習問題

問題 11-1

ブラウザである社内システムのURLを開いたところ、画面に「500 Internal Server Error」と表示されました。別のページでは「404 Not Found」が出ました。それぞれ何が起きていると考えられ、対応窓口はどちらでしょうか。

解答を見る

500(5xx)はサーバー側のエラーです。サーバー内部の処理で問題が起きており、利用者側でURLを直しても解決しません。サーバーの管理者(システム担当)に連絡すべきケースです。一方404(4xx)はクライアント側のエラーで、要求したページが存在しないことを意味します。URLの打ち間違い、リンク切れ、ページの移動・削除などが原因で、まず自分が開こうとしたURLを確認します。「4xxはこちら側、5xxは向こう側」と覚えると、切り分けと連絡先の判断が速くなります。

問題 11-2

インターネットに公開しているサーバーで、SSHのパスワード認証を無効にし、公開鍵認証だけにするよう勧められました。なぜ公開鍵認証のほうが安全なのか、パスワード認証と比べて説明してください。

解答を見る

パスワード認証には、(1) 推測や使い回しで破られる、(2) 総当たり攻撃(次々と試す)を受けやすい、(3) 設定次第では盗聴の危険がある、といった弱点があります。公開鍵認証では、認証の秘密である秘密鍵がネットワークを一切流れず、手元に置いたまま署名の検証だけで本人確認を行います。鍵は総当たりで破ることが事実上不可能なほど複雑なため、公開サーバーへの攻撃に対して格段に強くなります。ただし安全性は秘密鍵を漏らさないことに懸かっているため、秘密鍵の保管(パスフレーズ設定・共有禁止)が前提です。

問題 11-3

取引先とのファイル受け渡しに、まだFTPを使っている部署がありました。セキュリティの観点でどんな問題があり、何に置き換えるべきでしょうか。

解答を見る

FTPは通信が平文(暗号化なし)で、ログインID・パスワードも転送するファイルの中身も、途中の第三者に丸見えになる危険があります。同じネットワーク上で通信を覗かれれば、認証情報や機密ファイルが漏えいしかねません。対策は、SSHの安全な通信路の上で動くSFTPやSCPに置き換えることです。これらは通信が暗号化されるため、盗聴されても内容を読まれません。「平文プロトコル(FTP・Telnet・HTTP)は暗号化版(SFTP・SSH・HTTPS)へ移行する」という原則の、典型的な適用例です。