Exchange における TLS と SSL のベスト プラクティス


(この記事は 2015 年 7 月 27 日に Exchange Team Blog に投稿された記事 Exchange TLS & SSL Best Practices の翻訳です。最新情報については、翻訳元の記事をご参照ください。)

 

Exchange 実行時の最優先課題はセキュリティです。これは、オンプレミス環境でも、クラウド環境でも、ハイブリッド環境でも同様です。マイクロソフトは、お客様が現在の環境を適切に保護できるように、必要な情報を提供しています。

TLS 1.0 のサポートを無効にしたほうがよいとの複数の指摘が外部から寄せられています。2016 年の夏までに TLS 1.0 を無効にするように促すものもあれば、社内用アプリケーションでは TLS 1.0 を使用すべきでないというものもあります (Exchange は SMTP 経由で外部と接続しているため、通常このような方法では使用されません)。どちらも TLS 1.1 および 1.2 の導入促進を意図した善意の指摘だと考えられますが、実際マイクロソフトでは、現時点で Exchange Server 上の TLS 1.0 無効化を推奨していません。

TLS 1.1 および 1.2 は TLS 1.0 よりも上位のバージョンであるものの、業界内でのさまざまな緩和策により、実際のリスクはやや大げさに見積もられている可能性があります。さらに、セキュリティはイエス・ノーの判断ではありません。つまり、TLS 1.0 を無効にしたからといって、セキュリティ面の欠点が解決されるわけではないのです。マイクロソフトでは、TLS 1.1 および 1.2 が Exchange をはじめとする多様なクライアントで問題なく機能するよう、引き続き取り組んでいきます。

今回は、多くのお客様がまだ実践していない最新のベスト プラクティスをご紹介したいと思います。より安全な環境を実現するためには、まず、組織における TLS の認識を高めることが重要です。現時点で Exchange の TLS 1.0 の無効化はお勧めしませんが、他に実践可能なステップがあります。一般には SSL 3.0 が無効な状態で、マシンが随時更新され、適切な暗号を使っていれば、TLS 1.0 の安全性が低下することはありません。現時点での推奨事項は次のとおりです。

  • サポートされているバージョンの OS、クライアント、ブラウザー、Exchange を展開する
  •  Internet Explorer で SSL 3.0 を無効にしてあらゆるテストを実行する
  • クライアントで SSL 3.0 のサポートを無効にする
  • サーバーで SSL 3.0 のサポートを無効にする
  • TLS 1.2 の暗号化と AES/3DS の優先度を上げる
  • RC4 暗号化はなるべく無効にする
  • チェーン内で MD5/MD2 証明書のハッシュを使用しない
  • 新しい証明書キーの作成時に RSA-2048 を使用する
  • 証明書の新規取得時または更新時には  SHA 256 ビット以上のものを入手する
  • 使用中の Exchange バージョンのサポート内容を確認する
  • ツールを使用してテストおよび検証を行う
  • 明示的な TLS と暗黙的な TLS を混同しない
  • 現時点では Exchange サーバー上の TLS 1.0 を無効にしない

それでは、各項目について詳しく見ていきましょう。

 

サポートされているバージョンの OS、クライアント、ブラウザー、Exchange を展開する

どのような環境でも、安全性を確保するためにはまず、すべてのサーバー、デバイス、クライアント、アプリケーションを最新の状態に更新します。Exchange の推奨事項に従っているにもかかわらず発生する不具合は、多くの場合、互換性のないデバイス (プリンター、ファイアウォール、ロード バランサー) やソフトウェア (メーラーなど) に対してベンダーが提供している更新を適用すると簡単に解決できます。

Exchange の場合は Windows の更新と Exchange の更新を定期的に確認し、適用してください。なぜなら、環境のセキュリティ強度は、その環境内の最も弱い部分によって決まるからです。また、古いソフトウェアでは最新の TLS や暗号化の強みを活かせません。ファイアウォール、古い Linux MTA、ロード バランサー、一般的なメーラー ソフトウェアがすべて更新され、多機能プリンターが最新のファームウェアに更新されていることを確認してください。

Internet Explorer で SSL 3.0 を無効にしてあらゆるテストを実行する

まずブラウザーで SSL 3.0 を無効にすることをお勧めします。SSL 3.0 が無効であれば、ユーザーがどのページを閲覧しようと安全性が確保されます。また、Web サイトやアプリケーションが正常に動作するかどうかのテストも簡単に実行できます。現在 SSL 3.0 を使用しているサイトはまだ存在しますが、随時廃止されていくでしょう。Internet Explorer で現在の環境をテストする方法については、KB3009008 をご覧ください。

クライアントで SSL 3.0 のサポートを無効にする

テストが完了したら、すべてのクライアントのセキュア チャネル (SCHANNEL) レイヤーでも SSL 3.0 を無効にする (英語) ことを検討してください。また、クライアントで TLS 1.1 および 1.2 が有効になっていることを確認してください。多くの場合、クライアントとサーバーの両方でサポートされている最新のバージョンが使用されます。安全性を強化するには、まずこれを行います。TLS 1.1 および 1.2 は、現在サポートされているすべてのバージョンの Windows に対応していますが、古いバージョンの Windows では既定で無効になっている場合があります。

SCHANNEL のレジストリを変更する方法は、SCHANNEL API を使用するアプリケーションでのみ有効です。サード パーティやオープン ソースのセキュリティ API (OpenSSL など) を使用するアプリケーションは、SCHANNEL のレジストリ キーを参照しません。なお、変更を有効にするには再起動が必要です。

サーバーで SSL 3.0 のサポートを無効にする

次に、Exchange を含むすべてのサーバー上で SSL 3.0 を無効にします。マイクロソフト セキュリティ アドバイザリの「推奨するアクション」をすべて実行します。サーバーはクライアントの場合とサーバーの場合があるため、すべてのステップを実行することをお勧めします。また、サーバーで TLS 1.1 および 1.2 が有効になっていることを確認してください。

メモ: レジストリの変更を有効にするには再起動が必要です。

最低限 TLS 1.0 はサポートされているため、この処理は問題なく実行することができます。Exchange と Windows は、どちらも 10 年以上前から TLS 1.0 をサポートしています。クライアントとサーバー上で SSL 3.0 を無効にした場合でも、TLS 1.0 自体は脆弱とは見なされません。実際、長年ほとんどの Exchange セッションで TLS 1.0 以上が使用されています。SSL 3.0 にダウングレードするだけで、現在のセッションを無効にすることができます。10 年以上使用しているクライアントやデバイスでない限り、SSL 3.0 を無効にしてもそれほど影響はありません。

通常、これらの推奨事項は組織レベルで既に実施されているはずです。それでもなお、SSL 3.0 の脆弱性 (通称 POODLE) があるため、最初のセッション ネゴシエーションの間、クライアントとサーバー間のトラフィックを遮断する必要があります。これは難しくはありませんが、重要な作業です。外出の多いユーザーやホットスポットを利用するモバイル デバイスにとっては深刻な問題になります。多くのお客様がメールのリモート アクセスを利用していることからも、Exchange 管理者の対応が求められます。モバイル デバイス ベンダーによっては、SSL 3.0 を無効にする方法を公開していない場合もあるため、サーバー側で SSL 3.0 を無効にすることによって、少なくとも Exchange リソースの安全性は確保してください。

さらに、TLS 1.1 および 1.2 のサポートを有効にすることも強くお勧めします。当面、TLS 1.0 は有効のままにしておきましょう。Windows、アプリケーション、クライアントでサポートされている限り、クライアントとアプリケーションでは最も安全なオプションを選択する必要があります。

メモ: ロード バランサーで SSL トラフィックを遮断する場合は、SSL 3.0 も無効にし、以下の追加ステップを実行することをお勧めします。ベンダーからガイダンスを入手します。さらに、単一の VIP または DNS レコードを共有するすべての Exchange サーバーをチェックします。

Office 365 では、これらの変更は完了しており、SSL 3.0 はいずれのプロトコルでも使用することができません。

TLS 1.2 の暗号化と AES/3DS の優先度を上げる

この処理は、Office 365 で、よりブルート フォース攻撃に強いとされる最新の暗号化を優先的に使用するステップに基づいています。暗号化は最も安全性が高い方法ですが、1 つを有効にすると他のものは無効になります。最大限の互換性を得るために、クライアントにいくつかの選択肢を提供します。通常、最も安全性の低いものを無効にし、残りはオプションとして残しておきます。暗号化のネゴシエーションは次のように行われます。

  1. クライアントがサポートする暗号化の優先順リストを渡す
  2. サーバーは最良の暗号化を選択し、応答する (サーバー側に最終的な決定権)

サーバー上でリストの順序を変更すると、安全性の低い暗号化を使用するリスクを最小限に抑えられますが、完全に無効にすることをお勧めします。暗号化を変更するには、こちらのレジストリ キーを使用します。詳細はこちらをご覧ください。

RC4 暗号化はなるべく無効にする

多くの暗号化を無効にすると、一部のクライアントが正常に動作しなくなる可能性があります。それでも、RC4 暗号化スイートはぜひ無効にすることをお勧めします。これは非常に脆弱な暗号化スイートです。RC4 を無効化すると、古いサーバーやクライアントとの互換性がなくなる可能性があるため、注意が必要です。しかし、現在サポートされている Windows のバージョンは、かなり以前から RC4 から 3DES と AES に移行しているため、影響は最小限で済むでしょう。Office 365 でのセキュリティの強化は現在進行中であり、間もなく完了する予定です

チェーン内で MD5/MD2 証明書のハッシュを使用しない

暗号化は使用する証明書チェーンに依存しています。チェーン内で安全でない署名アルゴリズムを使用しているホストに接続しようとすると、問題が発生することがあります。たとえば、Office 365 の SMTP トランスポートは、MD5 や MD2 のハッシュを使用しているホストには接続できません。これは最新の暗号化がサポートされていないことが原因です。チェーン内の証明書についても同様です。この問題が SMTP で発生するのは、Exchange がクライアントとして機能しており、古い SMTP システムやファイアウォールが現在も広く使用されていることが理由となっています。

新しい証明書キーの作成時に RSA-2048 を使用しない

証明書の更新または再発行時には注意が必要です。まず、要求を作成するときは必ず 2,048 ビット RSA を使用してください。これより低いレベルの暗号化は安全と見なされません。

証明書の新規取得時または更新時には SHA 256 ビット以上のものを入手する

次に、署名アルゴリズムが SHA1 の場合は、証明書の更新時に SHA2 に変更してください。なお、証明書の更新時期が迫っている場合は特に対応する必要はありませんが、数年先まで更新する予定がない場合は今すぐ新しい署名アルゴリズムに変更することをお勧めします。

Exchange の証明書はブラウザーまたは証明書マネージャー (Microsoft Management Console、MMC) で確認できます。

このサンプル証明書は、Windows Server 2012 R2 が実行されている環境で、Exchange Server 2013 によって生成されました。2,048 ビットの RSA キーと、RSA SHA256 (SHA-2) 署名アルゴリズムを使用しています。

Exchange のサポート内容を確認する

一部のアプリケーションで新しいプロトコルを利用するには、再コンパイルとテストが必要になります。Exchange および Windows ベースのクライアントのあらゆる部分をくまなくテストしてください。現在、Exchange Server には次の制限事項があります。

  • SMTP – Exchange サーバー インフラストラクチャの主な要素です。Exchange Server 2013 CU8 および Exchange Server 2010 SP3 RU9 では、TLS 1.1 および 1.2 のサポートが追加されています。最新の暗号化および最新の TLS のサポートを追加するには、更新を適用する必要があります。
         重要: SMTP は、メールなど組織外との通信に使用される主要プロトコルです。TLS 1.0 を無効にすると、TLS 1.1 または 1.2 をサポートしない外部組織との通信で Opportunistic TLS を使用できなくなります。この場合、メールは暗号化されない状態で送受信されるため、TLS 1.0 の有効時よりもセキュリティは低下します。なお、Exchange SMTP プロトコル ログでは、新しいログが有効になっているため、SMTP の変更の影響を監査できます。
    追加メモ: SMTP プロトコルでは、Exchange はクライアントとしてもサーバーとしても機能します。以前のサーバーでは、バージョン ネゴシエーションが正しく実装されていない場合がありました。その場合、(クライアントの) Exchange が TLS 1.0 より新しいバージョンを使用すると、リモート サーバーによって接続が切断され、システム内でメールを使用できなくなることがありました。この問題は現在ほとんど発生していませんが、発生した場合に は、メール クライアントが接続できなくなるよりも深刻な影響があります。
  • POP/IMAP – あまり頻繁に使用されません。使用する場合は、Exchange Server 2016 のプレビューでは TLS 1.1 および 1.2 のオンプレミスしかサポートされない点に注意してください。この問題は将来の CU で修正される予定です。適切な方法でリクエストをいただければ、この問題の優先順位はより高くなります。Office 365 では既にサポートされています。
  • HTTPS (OWA、Outlook、EWS、Remote PS など) – TLS 1.1 および 1.2 のサポート状況は、IIS でのサポート状況に依存します。Windows Server 2008 R2 以上では、TLS 1.1 および 1.2 の両方がサポートされますが、それ以外のバージョンの Windows では、初期設定で有効になっている場合と無効になっている場合があります。もう 1 つ重要な点は、最新バージョンの Exchange Server では、CAS とメールボックス間の HTTPS プロキシで TLS 1.0 が必要です。このため、CAS とメールボックス間で TLS 1.0 を無効にすると、プロキシに障害が発生します。この問題は Exchange Server 2016 のプレビューでは解決されています。この問題は将来の CU で修正される予定です。サポート宛てにリクエストをお寄せください。現時点では推奨されていませんが、専用のロールがある場合はクライアントと CAS 間で TLS 1.0 を無効にすることも可能です。クライアントでサポートされていれば、Office 365 では TLS 1.1 および 1.2 がサポートされます。
  •          クライアント – TLS 1.0 はほぼ 100% サポートされている汎用プロトコルです。TLS 1.1 および 1.2 の普及は進んでいますが、多くの Exchange クライアントはまだ TLS 1.0 にしか対応していないのが現状です。現在マイクロソフトでは、Windows 8.0 以上で実行中の Outlook に関するさまざまな問題を追跡しています。これらの問題は間もなく解決される予定ですが、広く普及している Windows 7 環境では、TLS 1.0 の無効化はお勧めしていません。現段階で、マイクロソフトは、TLS 1.0 なしで稼働するその他のクライアントの包括的なテストをまだ完了していないためです。

メモ: Windows のバージョンによっては、Windows リモート デスクトップでも問題が発生する可能性があります。リモート管理されているサーバーについては、まずこの点をご確認ください。

ツールを使ってテストおよび検証を行う

サーバーとクライアントのテスト用のさまざまなツールや Web サイトがありますので、活用することを強くお勧めします。等級/スコア付けシステムを提供するものや、合否判定を行うものなどがあります。マイクロソフトでは、「セキュリティはリスクとトレードオフである」という考えに基づいて、スコア付けシステムを提供するものをお勧めしています。POODLE の完全なテストが行えず、TLS 1.0 が有害と見なされる場合もあります。最新の情報を基に、結果を判断してください。

マイクロソフトでは、全体的な脆弱性テストを実施すると同時に、特定の項目 (暗号化の順序、個々の TLS/SSL のバージョンなど) についてもチェックできるツールをお勧めしています。SSLLabs (英語) という優れた外部 Web サイトもお勧めです。このサイトでは、複数のクライアントをシミュレートして、既知のクライアントとの互換性の問題を警告します。たとえば、以下の結果では、古いバージョンの Android クライアントで TLS 1.0 を無効にした場合に、問題が発生する可能性が高いことがわかります。

インターネットの残りの部分と比較する方法もわかります。これは HTTPS に最適です。ほとんどの証明書ベンダーは、それぞれカバー範囲の異なるテスト ツールを提供しています。

追加プロトコルをテストするツールもあります。以下に、ポート 993 の IMAP (「SSL バインディング」。下記参照) に対するテスト結果を示します。

ご覧のように、ポート 993 でも TLS 1.0 と AES256 が使用されています。

明示的な TLS と暗黙的な TLS を混同しない。

一般に、人はものごとを省略する傾向にあります。TLS 1.0 に STARTTLS (明示的な TLS) のプロトコル単位の実装オプション サポートが追加されたときも同様です。「明示的な TLS」の登場前は、サーバー アプリケーション レベルのプロトコルが、安全性の低いオプションに加えて SSL/TLS を実装する必要がある場合、マシン上の別々のポートを占有する必要がありました。これを「暗黙的な TLS」と呼びます。次の表をご覧ください。

プロトコル

IANA ポート (明示的な TLS)

プロトコル

IANA ポート (暗黙的な TLS)

E-SMTP

25

SMTPS

465**

POP3

110

POPS

995

IMAP4

143

IMAPS

993

HTTP

80*

HTTPS

443

* HTTP は明示的な TLS を実装しません。明示的な TLS はステートレスであり、オーバーヘッドが大きすぎるためです。
** Exchange では、SMTPS (暗黙的な TLS) はサポート対象外です。

TLS を最初に実装したプロトコルは ESMTP でした。その結果、SMTP は同一ポート上でクライアントとサーバーの両方をサポートできるようになると同時に、便宜的な TLS/SSL も簡単に実装できるようになりました。ポート 465 は、Exchange Server 2013 で 3 つのトランスポート ロールの 1 つとして既定で再利用されていますが、実際 Exchange では SMTPS (ポート 465) はサポートされていません。一方、POP および IMAP については、明示的なオプションと暗黙的なオプションの両方がサポートされています。

問題は、STARTTLS が TLS 1.0 までサポートされなかった点にあります。そのため、一部のユーザーは「明示的な TLS」と「TLS」を混同し、一部のメール アプリケーションでは、これらが区別されていません。ポート 995 および 993 を無効にしても SSL 3.0 は無効になりません (SSL ではなく、暗黙的な POPS と IMAPS が無効化されます)。また、TLS 1.x に必要なポート 110 および 143 (明示的な TLS) も有効にはなりません。紛らわしい用語ですが、これらはほぼ無関係の概念です。この問題は、Exchange にも影響があります。

しかし、SSL 3.0 は無効化されないため、ポートや暗黙/明示の設定を変更する必要はありません。Exchange Server を保護するには、SCHANNEL レジストリ設定を変更してください。

現時点では Exchange サーバー上の TLS 1.0 を無効にしない

2015 年 7 月現在、Exchange では TLS 1.0 がサポートされています。さらに、次の最小要件が満たされている場合は、TLS 1.1 および 1.2 もサポートされます。

プロトコル

TLS 1.1/1.2 の最小要件

SMTP

Exchange Server 2013 CU8 または Exchange Server 2010 SP3 RU9

POP/IMAP

プレビュー版 Exchange Server 2016

HTTP (サーバー)

Windows Server 2008 R2
MAPI クライアントでは Windows 8.1 以上を実行する必要あり

HTTP (プロキシ- MBX 間)

プレビュー版 Exchange Server 2016

現時点では、Exchange Server 2016 はまだ一般提供されておらず (ラボ使用のみ)、最も普及している Windows バージョンは Windows 7 なので、TLS 1.0 を完全に無効にするのは得策ではありません。TLS 1.0 を無効にすると、(TLS 1.1 および 1.2 がサポートされないため) POP/IMAP も無効になります。また、メールボックス サーバー ロールを割り当てられている Exchange サーバーでは、TLS 1.0 を無効化することはできません。TLS 1.0 を無効にすると、一般的なモバイル デバイスやクライアントで互換性の問題が発生します。また、一部のインターネット メールが使えなくなる可能性があります。

SSL 3.0 を無効にし、組織に最適な暗号化順序を決定することで、安全性が確保され、POODLE 攻撃の心配はありません。マイクロソフトは、TLS 1.1 および 1.2 の完全なサポートに向けて取り組んでいます。TLS 1.3 はまだドラフト段階です。詳細については、今後の発表をお待ちください。現段階では、上記に従っていただければ問題ありません。

Windows Server 2012 R2 で Exchange Server 2013 を使用した Exchange ラボ テストでは、SSL 3.0 の無効化と RC4 暗号化の削除のみで、最高の評価が得られました。これは、現在リリースされている Exchange で、一般的なクライアントに影響を及ぼさないことを条件に得られるスコアとほぼ同じです。

この設定は、最新のセキュリティ要件を満たすと同時に、この 10 年間にリリースされたほぼすべてのクライアントおよびデバイスと互換性があります。もちろん、セキュリティを確保するには、新たな脅威や脆弱性に常に注意する必要があることも忘れてはなりません。今後も、引き続きセキュリティ情報や更新情報にご注目ください。

Scott Landry
Exchange サポート部門シニア プログラム マネージャー

Skip to main content