情報セキュリティマネジメント 2016年 秋期 午前（科目A） 問17
問題文
次の電子メールの環境を用いて、秘密情報を含むファイルを電子メールに添付して社外の宛先の利用者に送信したい。その際のファイルの添付方法、及びその添付方法を使う理由として、適切なものはどれか。
〔電子メールの環境〕
・電子メールは、Webブラウザから利用できる電子メールシステム（Webメール）を用いて送信する。
・WebブラウザとWebメールのサーバとの通信はHTTP over TLS（HTTPS）で行う。
・社外の宛先ドメインのメールサーバはSMTPとPOP3を使用している。
・IP層以下は暗号化していない。
選択肢
ア：WebブラウザからWebメールのサーバまでの通信が暗号化されているので、ファイルは平文のままでメールに添付する。
イ：WebブラウザからWebメールのサーバまでの通信は暗号化されるが、その後の通信が暗号化されないこともあるので、ファイルを暗号化してメールに添付する。（正解）
ウ：Webブラウザから宛先の利用者がメールを受信するPCまで、全部の通信は暗号化されるので、ファイルは平文のままでメールに添付する。
エ：Webメールのサーバから宛先ドメインのメールサーバまでの通信は暗号化されないが、サーバ間の通信はBase64形式でエンコードすれば盗聴できないので、ファイルはBase64形式でエンコードしてメールに添付する。
🔒 解説は解答すると表示されます
添付ファイルの暗号化【情報セキュリティマネジメント解説】
正解の理由
社内のWebブラウザとWebメールのサーバ間はHTTPS（HTTP over TLS：ブラウザとサーバ間の通信を暗号化する仕組み）で保護されますが、メールは送信後に複数のメールサーバを経由することがあります。SMTP（Simple Mail Transfer Protocol：メールを転送する仕組み）やPOP3（Post Office Protocol version 3：受信に使う仕組み）が暗号化されずに使われる場合、サーバ間や受信側までの経路上で内容が平文で流れる可能性があります。したがって、送信するファイルそのものを暗号化しておけば、経路上で盗聴されてもファイルの中身は守られます。選択肢の中でこれを示しているのが イ です。
（補足：Base64はデータを文字列化する符号化であって暗号化ではありません。IP層が暗号化されていないと、途中の経路で傍受される恐れがあります。）
解法ステップ
- 「どこが暗号化されるか」を順に確認する。Webブラウザ→WebメールはHTTPSで暗号化されると明記されている。
- しかし、その後の「サーバ間」や受信側までの経路が暗号化されるとは限らない点に注目する。SMTP/POP3が暗号化されない設定の可能性がある。
- 守りたいものは「ファイルの中身（機密情報）」なので、経路の一部が暗号化されない場合でも、ファイル自体を暗号化すれば終点まで機密性が担保される。
- よって「ファイルを暗号化して添付する」選択が最も確実であり、これが正解の根拠となる。
選択肢別の誤答解説
- ア: Webブラウザ→Webメール間が暗号化されているから平文で良い、という考えです。途中のサーバ間や受信側への経路が暗号化されない場合、内容が露出します。よって不十分です。
- イ: 正解。送信経路の一部が暗号化されない可能性があるため、ファイル自体を暗号化して機密性を保つ方法が適切です。
- ウ: 「全ての通信が暗号化される」と仮定するのは誤りです。問題文でIP層以下は暗号化していないと明記され、宛先ドメイン側のサーバが暗号化を使う保証もありません。
- エ: Base64はデータを転送可能な文字列に変換するだけの符号化（エンコード）です。符号化は可逆で誰でも元に戻せるため、盗聴に対する防御になりません。したがってエは誤りです。
よくある誤解
- 「HTTPSなら全部安全」と思い込む誤解。HTTPSはブラウザとサーバ間のみを守りますが、メールの経路全体は別問題です。
- 「Base64は安全」あるいは「添付をZIPにするだけでOK」と考える誤解。Base64は暗号化でなく、パスワード無しZIPも保護になりません。
- 「パスワードつきZIPなら十分」と過信すること。パスワードの共有方法（メールで同時に送る等）が甘いと意味がなくなるため、鍵のやり取り方法を別チャネルで行う必要があります。
補足コラム
実務で使える暗号化の選択肢とポイント
- S/MIME（Secure/Multipurpose Internet Mail Extensions）：メールにデジタル署名や暗号を付ける仕組み。証明書（公開鍵）管理が必要。企業で導入すると利便性が高い。
- PGP/GPG（Pretty Good Privacy / GNU Privacy Guard）：公開鍵暗号方式。相手と公開鍵のやり取りが必要だが、端末側でファイルを暗号化できる。
- パスワード付きZIP（AES暗号化）やPDFのパスワード保護：手軽だが、パスワードの安全な共有（電話や別のメッセージ手段）が必須。
- セキュアなファイル共有リンク（社内の安全なクラウドにアップし、受信者に限定的なアクセス権を与える）：大容量や共同作業に向く。リンクの有効期限やダウンロード制限を設定するのが望ましい。
運用面では「誰が暗号化するか」「鍵（パスワード）をどう管理するか」「復号できる人の範囲」のルールを社内で決めておくことが重要です。
職場での実運用イメージ
- 緊急を要する機微情報は、まず管理職や情報管理担当に連絡して伝達方法を決めます。
- 鍵やパスワードはメールでは送らず、電話や社内チャットの別スレッド、もしくは対面で共有します。
- 定期的に利用する相手なら、S/MIMEやPGPの公開鍵交換を事前に行っておくと便利です。
FAQ
Q1: パスワード付きZIPをメールに添付して、パスワードを別メールで送れば安全ですか？
A1: パスワードを同じチャネル（メール）で送ると意味が薄れます。別チャネル（電話や別のメッセージ手段）で共有すること、かつ強いパスワードを使うことが重要です。
A1: パスワードを同じチャネル（メール）で送ると意味が薄れます。別チャネル（電話や別のメッセージ手段）で共有すること、かつ強いパスワードを使うことが重要です。
Q2: S/MIMEとPGPはどちらが良いですか？
A2: 両方とも公開鍵暗号を使います。組織で証明書を一元管理したい場合はS/MIMEが導入しやすいです。個人間で柔軟に使うならPGP/GPGが向きます。運用コストや既存システムとの相性で選びます。
A2: 両方とも公開鍵暗号を使います。組織で証明書を一元管理したい場合はS/MIMEが導入しやすいです。個人間で柔軟に使うならPGP/GPGが向きます。運用コストや既存システムとの相性で選びます。
Q3: メールの道中はSTARTTLSで暗号化されるのでは？
A3: STARTTLSはサーバ間暗号化手段ですが、相手サーバが対応していなければ暗号化されません。必ずしも終端まで保証されない点に注意してください。
A3: STARTTLSはサーバ間暗号化手段ですが、相手サーバが対応していなければ暗号化されません。必ずしも終端まで保証されない点に注意してください。
Q4: 添付ではなく「HTTPSで保護されたクラウドにアップしてリンクを送る」方法はどうですか？
A4: 有効な方法です。リンクに認証や有効期限を設定し、アクセス権を限定することで安全性が高まります。ただしリンク自体が第三者に渡るリスクや、クラウド側のアクセス管理が適切かを確認する必要があります。
A4: 有効な方法です。リンクに認証や有効期限を設定し、アクセス権を限定することで安全性が高まります。ただしリンク自体が第三者に渡るリスクや、クラウド側のアクセス管理が適切かを確認する必要があります。
関連キーワード: 電子メール暗号化、添付ファイルの機密性、S/MIME、PGP/GPG、Base64、STARTTLS、HTTPS、SMTP、POP3、パスワード付きZIP
\ せっかくなら /
情報セキュリティマネジメントを
クイズ形式で学習しませんか？
クイズ画面へ遷移する→
すぐに利用可能！