ビジネスに必須の電子メールのほとんどは、通常、ネット上で傍受可能な平文で通信されています。
中間者による改竄の可能性もあります。また、そもそも「送信者が本当に本人かどうかわからない」なりすましメール問題もあります。
これらは暗号化技術によって防ぐことができますが、これまでその利用はなかなか進んできませんでした。
しかし、2014年4月現在500万社以上の企業が導入しているGoogleのクラウドベースのビジネス向けツール「Google Apps」において主要なアプリケーションである「Gmail」が接続方法を常時HTTPSにするようになったことで、傍受や改ざんを防ぐことのできる電子メールの暗号化は、TLS/SSL利用への大きな流れに乗ったといえるでしょう。
Microsoft ExchangeがTLS/SSL利用を推奨し、Unix系サーバーでもほとんどのメールサーバーでTLS/SSL利用設定が可能であるにも関わらず、自社でメールサーバーを運営している場合でもその利用があまり進まなかったのは、TLS/SSL利用の暗号化で安全性が確保されるのは送信者側のクライアントマシンと自社メールサーバー間だけで、そこから先は暗号化が保障されないためでした。
しかし、「Gmail」が接続方法を常時HTTPSにするようになったことで、これからは自社メールサーバーがTLS/SSLを利用するようになっていれば、Gmailサーバーとの直接のやり取りはすべて暗号化されます。
「Gmail」の常時HTTPS化、Yahoo! メール・Outlook.com・@nifty等の多くのメールサービスでTLS/SSLが利用可能になっていることなどから、自社メールサーバーでTLS/SSLを設定し、常時メール暗号化を利用することが、取引情報や個人情報の安全性を確保していくためのリアリティのある対策になってきました。
メールの暗号化技術は、「TLS/SSL 利用暗号化」と「PGP と S/MIME」に大別できます。
どちらも証明書を利用した暗号化ですが、利用する証明書が少し異なります。
電子メールホスト名の証明書を利用します。 詳細＞＞
メールアドレスごとの証明書を利用します。 詳細＞＞
それぞれの概要は以下をご覧ください。
ここで言う「TLS/SSL利用暗号化」とは、以下の総称を指します。
「TLS/SSL 利用暗号化」という呼び名が一般に定着しているわけではありません。
メールクライアントとメールサーバーとの通信で利用される仕組みで、メールサーバーに設定された証明書と秘密鍵を使います。その仕組みはWebでのSSLとほぼ同じです。
ブラウザとWebサーバーの間の通信を証明書と秘密鍵を使ったhttpsで行います。Webサーバーとメールサーバーが別マシーン上にある場合はその間の通信も暗号化されていなければなりません。
メールクライアントとメールサーバーとの通信で利用されるだけでなく、メールリレーでのメールサーバー間の通信にも利用されます。
SMTP over SSLには、STARTTLSという接続方法と465番ポートを使う方法とがあります。
最初から暗号化された接続が行われます。
通信相手サーバーが TLS/SSLに対応しているかの判定が行われ、TLS/SSLに対応している場合に、全データの暗号化通信が行われます。
SMTP over SSLでは、STARTTLSが非常に重要です。サーバー間のメールリレーでは標準的にはこの方法が利用されているからです。
メールリレーで双方のサーバーがSTARTTLSに対応していれば、通信は自動的に暗号化されます。どちらか一方でもSTARTTLSに対応していなければ、メールは平文で送信されます。（STARTTLSという仕組みはPOP・IMAP にもありますが、主要メールクライアントで利用できない場合があるなど、ポピュラーではありません。）
「TLS/SSL利用暗号化」のメリットは、サーバーの設定が済んでいれば、すべてのメールを自動的に暗号化することができることです。
今後「TLS/SSL利用暗号化」を利用した電子メールの普及は進むことになるでしょう。
一方、最大のデメリットはメール送信者が本当に本人かどうかを確認する方法が含まれておらず、なりすましを防止できないことです。
メール送信者が本当に本人かどうかを確認する方法として、「PGP」と「S/MIME」の利用があります。
送信者は事前に入手した受信者の公開鍵で暗号化した共通鍵と、その共通鍵で暗号化したメール本体を電子署名とともに送付します。
受信者は送信者の電子署名を確認し、自分の秘密鍵で復号化した共通鍵でメール本体を復号化します。
この方法であえて共通鍵を使うのは、公開鍵で暗号化し秘密鍵で復号化するのに比べて格段に処理速度が速いからです。データサイズが小さな共通鍵の暗号処理には公開鍵・秘密鍵セットを使い、データサイズが大きなメール本体暗号処理には共通鍵を使います。
この方式の場合、公開鍵の信頼性が問題です。信頼性確認の手段がPGPとS/MIMEで異なります。
既に信頼している公開鍵 (A) の所有者が別の公開鍵 (B) を信頼している場合、公開鍵 (B) は信頼されます。信頼のネットワークに属するものは信頼するという仕組みです。
サーバー証明書の場合と同様に認証局 (CA) によって信頼性を取得します。信頼済み認証局 (CA) が認証している公開鍵は信頼されます。
「PGP」と「S/MIME」の最大のメリットは、なりすましを防止できることです。
デメリットは事前に送信相手の公開鍵を取得しないとならないことです。常にメールをやり取りしている相手との通信であれば問題ありませんが、新規の通信相手の場合、相手が公開鍵を持っていないければ平文での送信を行うことになってしまいます。
また、ほとんどの Web メールソフトは「PGP と S/MIME」をサポートしていません。
そのため、「PGP」と「S/MIME」は契約書の交換など機密性が非常に高い通信のためだけに利用される傾向があります。
DigiCert では「SSL Plus」「WildCard Plus」「マルチドメイン証明書」「EV SSL Plus」「EV マルチドメイン証明書」の5タイプの「SSL/TLS サーバ証明書」を提供していますが、そのすべてがメールサーバーで利用可能です。
しかし、コストパフォーマンスの点から、Unix 系単独サーバーで利用の場合は「SSL Plus」をお勧めします。多数のUnix 系サーバーで利用の場合は「WildCard Plus」、Exchange での利用の場合は「マルチドメイン証明書」をお勧めします。
メールサーバーには現時点で EV チェック機能がないので、メールサーバー専用のサーバ証明書の場合「EV SSL Plus」「EV マルチドメイン証明書」の利用メリットはありません。Web サーバーと共用であれば「EV SSL Plus」「EV マルチドメイン証明書」もお勧めです。
Unix系で同一メールサーバー上で複数ドメインのメールをサポートしている場合、各ドメインの証明書を取得する必要はありません。
Unix系サーバーのホスト名の証明書、一枚で問題ありません。
256ビットの暗号化に対応した、wwwなしのドメイン名でも警告なしで使えるSSLサーバ証明書です。
詳しくは、以下のページをご参照ください。
SSL Plus（SSL サーバ証明書）＞＞
ひとつの証明書で同一ドメインの全ホスト名をカバー、複数マシンでも利用可能なワイルドカード形式のサーバ証明書です。
詳しくは、以下のページをご参照ください。
WildCard Plus（ワイルドカードサーバー証明書）＞＞
ドメインの所有者が同一であれば、異なったドメインのホストでも25ホストまでを1枚のサーバー証明書でカバーする証明書です。Microsoft Exchange Serverでの利用が有名ですが、Apacheでも利用可能です。
詳しくは、以下のページをご参照ください。
マルチドメイン証明書＞＞
メールサーバーで「TLS/SSL 利用暗号化」を可能にするためにはサーバー証明書のインストールが必須です。
各サーバーでの具体的手順は以下を参照ください。
ipop3d imapd (imap-uw) でのCSR作成方法
ipop3d imapd (imap-uw) でのサーバー証明書のインストール方法
Exchange 2010でのCSR作成方法
Exchange 2010 CSR作成ウイザード
Exchange 2010でのサーバー証明書のインストール方法
Exchange 2007でのCSR作成方法
Exchange 2007 CSR作成ウイザード
Exchange 2007でのサーバー証明書のインストール方法
・SSLサーバー証明書
・コードサイニング
その他証明書
・バウチャ(クーポン)
