メールセキュリティ

メール暗号化めーるあんごうか

S/MIMEPGP公開鍵暗号TLS電子署名エンドツーエンド暗号化

メール暗号化について教えて

簡単に言うとこんな感じ！

メールを「鍵のかかった封筒」に入れて送るようなものだよ！ふつうのメールはハガキみたいなもので、途中で誰かに見られてもそのまま読めちゃう。暗号化すると、受け取った相手だけが開けられる封筒になるってこと！

メール暗号化とは

メール暗号化とは、電子メールの内容を第三者に読めない形式に変換して送受信する技術の総称です。通常のメールは平文（暗号化されていないテキスト）で送受信されるため、通信経路上や保存サーバー上で盗み見・改ざんされるリスクがあります。暗号化を施すことで、正規の受信者だけがメール内容を読める状態にします。

ビジネスの現場では、契約書・個人情報・財務情報など機密性の高いデータをメールで送受信する機会が多くあります。情報漏えいやなりすましを防ぐ観点から、メール暗号化はセキュリティ対策の基本のひとつとして位置づけられており、個人情報保護法やISMS（情報セキュリティマネジメントシステム）の観点からも対応が求められます。

メール暗号化には大きく「通信路の暗号化」と「コンテンツ（内容）の暗号化」の2種類があります。それぞれカバーする範囲が異なるため、セキュリティ要件に応じて組み合わせて使うことが重要です。

メール暗号化の種類と仕組み

種類	代表技術	暗号化の対象	守れる場面
通信路の暗号化	SMTP over TLS（STARTTLS）	送受信の通信経路	サーバー間の盗聴防止
コンテンツの暗号化	S/MIME、PGP/GPG	メール本文・添付ファイル	保存中・受信後の漏えい防止
エンドツーエンド暗号化	PGP/GPG、S/MIME	送信者〜受信者間すべて	途中のサーバーも含めた完全保護

通信路暗号化（TLS）と内容暗号化の違い

よく混同されるポイントなので整理しておきましょう。

【通信路暗号化（TLS）のイメージ】

送信者 ──[暗号トンネル]──► メールサーバーA ──[暗号トンネル]──► メールサーバーB ──► 受信者
                               ↑ここで復号                        ↑ここで復号
            ※サーバー上では平文で保存されている可能性あり

【コンテンツ暗号化（S/MIME / PGP）のイメージ】

送信者 ──[暗号化されたメール本文のまま]──────────────────────────────► 受信者
            ※途中のサーバーでも中身は読めない（エンドツーエンド）

公開鍵暗号の基本的な仕組み

S/MIMEやPGPは「公開鍵暗号」という方式を使います。カギのかかった南京錠と考えるとわかりやすいです。

受信者があらかじめ「公開鍵（誰でも使える南京錠）」を公開する
送信者はその南京錠でメールを施錠して送る
受信者だけが持つ「秘密鍵（南京錠を開けるカギ）」で開ける

主要技術の比較

メール暗号化の代表的な技術であるS/MIMEとPGPを比較してみましょう。

電子署名との違い

「暗号化」と「電子署名」はよく一緒に語られますが、目的が違います。

目的	技術	何を守るか
内容を秘匿する	暗号化	機密性（第三者に読まれない）
送信者を証明する	電子署名	真正性・完全性（なりすまし・改ざん防止）

S/MIMEとPGPはどちらも暗号化と電子署名の両方に対応しています。

歴史と背景

1991年 — Phil Zimmermann が PGP（Pretty Good Privacy） を開発・公開。個人がメールを暗号化できる最初の実用ツールとして広まった
1995年 — S/MIME（Secure/Multipurpose Internet Mail Extensions） の原型となる仕様がRSA Securityにより策定
1998年 — S/MIMEがIETFに標準化され、RFC 2311 として発行
1999年 — PGPの標準化版として OpenPGP が RFC 2440 として標準化
2002年 — SMTP over TLS を定義する RFC 3207（STARTTLS）が広く普及し始める
2012年頃〜 — GmailなどWebメールでもTLS通信が標準化。「鍵マーク」表示でユーザーが確認できるように
2019年 — MTA-STS（RFC 8461）が策定され、TLS通信の強制化が進む
現在 — 個人情報保護法改正・サイバー攻撃増加を背景に、企業での導入が加速

メール暗号化が必要な理由と実務での選択

どんなリスクを防げるか

■ メール暗号化で防げる主なリスク

[盗聴・傍受]        通信路上で第三者がメール内容を読む          → TLS で防止
[サーバー侵害]      メールサーバーへの不正アクセスで内容漏えい  → S/MIME/PGP で防止
[なりすまし]        送信者を偽った詐欺メール（BECなど）          → 電子署名で防止
[改ざん]            メール本文・添付が転送中に書き換えられる     → 電子署名で防止

実務での選び方

シナリオ	推奨手段
社内メールサーバー間の通信保護	SMTP over TLS（STARTTLS / MTA-STS）
取引先との公式な機密書類やり取り	S/MIME（CAから証明書を取得）
技術者間のセキュアな情報共有	PGP/GPG
GmailなどWebメール同士	TLS通信＋Google Workspace の S/MIME 機能

規格・RFC番号	内容
RFC 8551	S/MIME 4.0 メッセージ仕様（最新版）
RFC 9580	OpenPGP 最新仕様（PGP/GPGの標準）
RFC 3207	SMTP STARTTLS 拡張（通信路の暗号化）
RFC 8461	MTA-STS（TLS通信の強制ポリシー）
RFC 7672	SMTP DANE（DNSによるTLS証明書検証）