Communications: Log onto Outlook Web Access with Smart Cards

[アーティクル]
08/25/2016

通信

スマートカードを使用した Outlook Web Access へのログオン

Victor Akinnagbe and Ted Dressel and Jason Opdycke

概要:

2 要素認証
Kerberos の制約付き委任
ISA Server と Exchange の構成

モバイル機器を使用する従業員は、IT 組織にとって独特なセキュリティ上の課題をもたらします。リモートユーザーは、データや電子メールなどのサービスに、セキュリティが確保された方法でアクセスする必要があります。しかし、残念ながら実態としては、

セキュリティチェーンにおいて最も攻撃を受けやすいリンクは、脆弱なパスワード、(キーロガーなどの) マルウェア、組織内部のリソースにアクセスしているリモートコンピュータ上のウイルスなどに関係しています。

こうしたモバイル環境のセキュリティを強化する 1 つの方法は、攻撃を受けやすいリンクの 1 つである、パスワードを削除することです (認証にパスワードを使用しないでアカウントにアクセスを許可するという考えは、不安かもしれませんが)。パスワードに関連する問題を解消するための主要な技法を 2 要素認証と呼びます (または多要素認証と呼ぶこともあります)。2 要素認証では、アクセスを許可する際にパスワードという 1 つの方法だけに依存するのではなく、ユーザー名とパスワードを組み合わせたり、スマートカードなどの物理デバイスを使用したり、指紋などのバイオメトリクス ID を使用するなど、追加の認証手法の使用が求められます。

リモートユーザーがいる場合は、通常、ファイアウォールの一部を開放し、企業ネットワークへのリモートアクセスを許可する必要があります。標準のファイアウォールでは、社内ネットワークと社外ネットワークの間のネットワークレベルを分離することで、基本的なリスクを緩和しています (図 1 参照)。セキュリティを強化する場合は、単純にポートを閉じ、社内ネットワーク上のデバイスとの通信が必要になったときに、適切な場所にポートを転送します。これらの技術を使用することで、実質的にネットワークレベルが保護されますが、攻撃はますます巧妙化してきているため、現状は複数層でのネットワークセキュリティが必要になってきます。

図 1 標準ファイアウォールとブロックまたは転送されるポート

図 1** 標準ファイアウォールとブロックまたは転送されるポート **(画像を拡大するには、ここをクリックします)

モバイル機器を使用する従業員が最も多く使用する一般的な企業サービスは電子メールとメッセージングです。そのため、セキュリティを確保するために Exchange インフラストラクチャを構成することが今までになく重要となってきます。電子メールへのアクセス方法として Outlook® Web Access (OWA) を使用することは、モバイルユーザーにセキュリティが確保されたサービスを提供するための 1 つの方法です。もう 1 つの重要な方法は、スマートカードを使用してよりセキュリティの高い 2 要素認証を OWA で提供することです。この記事では、スマートカードに対応したユーザー独自の OWA を展開する際に、知っておく必要がある構成とセットアップの問題について詳しく説明します。

ファイアウォールを上回る利点

Microsoft® Internet Security and Acceleration (ISA) Server 2006 をネットワークに導入することにより、セキュリティがより確保される方法で、ネットワークをリモートユーザーに開放する作業を簡素化できます。ISA Server 2006 には、スマートカード対応の仮想プライベートネットワーク (VPN)、Active Directory® に対するライトウェイトディレクトリアクセスプロトコル (LDAP) 認証、Kerberos の制約付き委任などのセキュリティが強化された機能が含まれています。ISA Server は、従来のファイアウォールの考え方とは多少異なります。ISA Server は、標準ファイアウォールハードウェアの代用として、また標準ファイアウォールハードウェアと連携してネットワーク層で機能するだけでなく、従来のファイアウォールではサポートされていなかったアプリケーションフィルタなどの追加セキュリティ機能を提供することによって、複数層のセキュリティを提供します。ホストしている特定の Web サイトに対して HTTP POST メソッドを使用しない場合、SMTP メッセージが Exchange サーバーに到着する前に、メッセージを RFC に準拠させる場合、または暗号化された SSL (Secure Sockets Layer) HTTP パケットがネットワークに着信する前にパケットを検査したい場合などにISA Server を使用して、これらの作業すべてを管理し、さらにクリーンで、フィルタ処理されたトラフィックのみを DMZ や社内ネットワークに転送することができます。

SSL セッションは標準のファイアウォールにとっては厄介です。パケットがファイアウォールを通過する際、それらのパケットは暗号化されたままです (これは SSL が正常に機能していることを意味します)。そのため、OWA などのアプリケーションが、SSL を使用してハードウェアまたはソフトウェアファイアウォール経由で公開される場合、標準のファイアウォールで、実際にステートフルパケットインスペクション以外に適用できる検査はありません。単純にポートを開いて転送するだけでは、相当な範囲が攻撃にさらされてしまうことになります。エッジでは実際の検査は行われていないので、未検査の認証されていないパケットが社内ネットワークにルーティングされることになります。

ISA Server 2006 は、HTTP クライアント向けの SSL エンドポイントとして機能し、認証済みのトラフィックのみが、公開された Exchange サーバーに到達することを保証します。ISA Server では SSL ブリッジという有用な機能をサポートしています。通常、パケットは、標準の SSL セッション経由で ISA Server と通信しているクライアントによって暗号化されます。ISA Server は SSL ブリッジを使用して、SSL 暗号化をローカルで解除し、すぐにその暗号化が解除されたパケットを検査します。次に、(必要に応じて) Active Directory に対してユーザーを認証し、SSL を使用してパケットを再暗号化してから、暗号化したパケットを適切な Exchange サーバーに転送します（図 2 参照)。SSL ブリッジではこの技法を使用して、アプリケーションを認識しないファイアウォールに送信される、暗号化された BLOB データにしか見えない SSL セッション内に潜む攻撃を緩和します。

図 2 ISA Server によるトラフィックのアプリケーション層ビュー

図 2** ISA Server によるトラフィックのアプリケーション層ビュー **(画像を拡大するには、ここをクリックします)

Kerberos の制約付き委任について話をする際には、サーバーに到着する事前認証済みのトラフィックが重要なポイントになります。標準ファイアウォールでは、ポートが単純に Exchange サーバーに転送され、悪意のある可能性があるユーザーに対し、フロントエンドサーバー自体が認証作業を実行します。ISA Server では、認証が必要な場合に、直接 Active Directory にアクセスして、そのユーザーに代わって資格情報を要求できます。ユーザーが正しく認証されると、ISA Server から Exchange フロントエンドサーバーにメッセージが転送されます。これにより、フロントエンドサーバーではランダムで未知のユーザー要求を認証する必要がなくなるため、バックエンサーバーへの要求を単にプロキシするためだけにフロントエンドサーバーを使用できるようになります。また、ISA Server 2006 では、Kerberos の制約付き委任を使用して、Windows SharePoint Services や Exchange ActiveSync などのテクノロジに証明書ベースでアクセスすることもできます。

Exchange Server 2003 では、OWA ログイン用に、フロントエンドサーバーとバックエンドサーバー間での Kerberos ベースの認証がサポートされていました (クライアントトラフィックの保護には IPsec を使用していることと思います)。Exchange Server では、クラスタ化されたメールボックスサーバーに対する Kerberos 認証もサポートされています。

スマートカード認証を有効にする

これまで、OWA 向けにスマートカードベースの認証を実装することは困難でした。しかし、ISA Server 2006 で使用可能になった Kerberos の制約付き委任機能を基にソリューションが開発されました。このソリューションでは、証明書を使用してユーザーから資格情報を送信することで、OWA に対して正しく認証を行うことができます。Kerberos の制約付き委任は、制約のない委任に使用していた Windows® 2000 でサポートされている Kerberos 委任を上回る優れた機能強化です。Kerberos の制約機能により、さらにセキュリティが確保され、偽装を利用した巧妙な攻撃による潜在的なリスクを軽減します。

スマートカード対応のシナリオでは、ユーザーは社外ネットワークからキー配布センター (KDC) にルーティング可能な方法でアクセスできないので、ISA Server 2006 が Active Directory にアクセスしてユーザーを認証します。ISA Server は、Active Directory 証明書ユーザーマッピングに従ってユーザーを認証した後、ユーザープリンシパル名 (UPN) に基づいてそれぞれの Kerberos チケットを取得します。この場合、ISA Server は、Kerberos の制約付き委任機能を、アプリケーションレベルのフィルタリングとリバースプロキシサービス経由で Exchange フロントエンドサーバーに提供します。リバースプロキシを経由しないで委任が試行された場合、脆弱性に対するリスクが増加し、ネットワークまたは Active Directory ドメインの完全性に影響することがあります。

Exchange Server 2003 と Exchange Server 2007 はどちらも、基本認証と統合認証を許可します。ただし、Exchange Server 2003 で OWA に対するスマートカードベースの認証が正常に機能するには、ソフトウェア更新プログラムを適用する必要があります (詳細については、「Outlook Web Access に対するスマートカード認証をサポートする Exchange Server 2003 の新機能について」を参照してください)。Windows Server® 2003 ネイティブ機能モードのドメインを用意し、関連するすべての Exchange Server 2003 サーバーに SP2 以降を適用する必要があります。また、OWA サイトのリバースプロキシとして機能する ISA Server 2006 サーバーが必要です。

ソフトウェア更新プログラムをインストールして、ISA サーバーと Exchange サーバーを構成すると、ユーザーはスマートカードを使用して OWA セッションを認証できるようになります。図 3 に、スマートカード認証に必要なイベントフローを示します。まず、ユーザーが Internet Explorer® で OWA サイトを開きます (1)。実際には、ユーザーが接続しているのは ISA Server で、OWA セッションを開始するために、ユーザー名とパスワードの代わりに証明書が求められます。適切な証明書はスマートカードに保存されているため、PIN が必要です。

図 3 スマートカードによる OWA の認証

図 3** スマートカードによる OWA の認証 **(画像を拡大するには、ここをクリックします)

証明書の検証 (2) は、ISA Server とその他のインストール済みソフトウェアの構成に応じて、証明書失効リスト (CRL) またはオンライン証明書状態プロトコル (OCSP) 要求を経由して処理されます。ISA Server は、ユーザーの資格情報を確認するようにドメインコントローラ (DC) に要求します。この要求に失敗すると、ISA Server はユーザーに対してエラーページを表示し、要求は Exchange フロントエンドサーバーには到達しません。

資格情報が確認されると Kerberos チケットが生成され、統合認証を使用して Exchange フロントエンドサーバーに要求が渡されます (3)。Exchange フロントエンドサーバーが要求を受け取ると、Kerberos チケットを検証して、ユーザーのバックエンドメールボックスサーバーを検索します (4)。

フロントエンドサーバーは、適切なバックエンドサーバーの Kerberos チケットを Kerberos の制約付き委任を使用して要求し、統合認証を使用してバックエンドサーバーにメールボックス要求をプロキシします (5)。要求がバックエンドサーバーで処理され (6)、メールボックスデータが Exchange フロントエンドサーバーに返されます (7)。OWA ページの HTML データが ISA Server に渡され (8)、その後、クライアントコンピュータに渡されます (9)。

Exchange 環境の構成

前述のサポート技術情報の資料には、Exchange Server 2003 のソフトウェア更新プログラムの説明、および ISA Server 2006 と Exchange Server 2003 を使用して Kerberos の制約付き委任を有効にするプロセスに役立つ情報が記載されています。

このソフトウェア更新プログラムによって有効になる主な機能は、Exchange フロントエンドサーバーからそれぞれのバックエンドサーバーまでの Kerberos の制約付き委任のプロセスの自動化です。ISA Server は Exchange 組織の一部ではないので、この更新プログラムを適用しても、ISA Server からフロントエンドサーバーまでの Kerberos の制約付き委任のプロセスは自動化されません。各 ISA Server インスタンスから各 Exchange フロントエンドサーバーまでの委任プロセスは、手動で有効にする必要があります。

このソフトウェア更新プログラムを適用すると、Exchange システムマネージャに新しいタブが追加され、Exchange フロントエンドサーバーを KCD-FE として指定できるようになります (図 4 参照)。また、それぞれの Exchange バックエンドサーバーの委任タブでそのサーバーを設定できるようになります。

図 4 Kerberos の制約付き委任を有効にする

図 4** Kerberos の制約付き委任を有効にする **

新しい UI では、図 5 に示すように、msDS-AllowedToDelegateTo (A2D2) 属性の設定に使用する資格情報を、管理グループのプロパティで指定することもできます。この属性が、Kerberos の制約付き委任を担当します。

図 5 委任を制御するアカウントの設定

図 5** 委任を制御するアカウントの設定 **

最小特権の原則に関しては、標準ユーザーアカウントを使用し、グループポリシーオブジェクト (GPO) 経由でユーザーとコンピュータに委任する権限を標準ユーザーアカウントに許可することができます。アカウントにこの権限を昇格したアクセス許可を与えると、各管理グループの Kerberos の制約付き委任プロセスを自動化するサービスアカウントとしてこのアカウントを使用できます。

悪意のあるユーザーに Kerberos の制約付き委任サービスアカウントを知られないようにするために、適切な措置を講じてください。そのアカウントがドメイン管理者でなくても、そのアカウントへのアクセスにより、Kerberos 委任を利用した巧妙な攻撃につながる可能性があります。このアカウントを使用すると新たに Kerberos の関連付けを確立できるため、十分に注意して使用してください。アカウントのセキュリティと完全性を確保するために、必要な予防措置を講じてください。たとえば、長くて複雑なパスワードを使用することや、監査を増やすこと、またはアカウントを無効にする技術などが必要です。

また、この Exchange ソフトウェア更新プログラムでは、統合認証に関連する非常に重要な変更が ESM インターフェイスに加えられます。以前、Exchange Server 2003 では、サーバーをフロントエンドサーバーとして指定した場合に、HTTP 仮想ディレクトリ (HTTP 仮想サーバーの下) の統合 Windows 認証を有効にするオプションを使用できませんでした (図 6 参照)。

図 6a 更新プログラムにより統合認証が有効になる

図 6a** 更新プログラムにより統合認証が有効になる **

図 6b 更新プログラムにより統合認証が有効になる

図 6b** 更新プログラムにより統合認証が有効になる **

プロキシサーバーによって NTLM セッションが中断されたり、Kerberos 認証を使用するユーザーは Active Directory に接続する必要があったり、インターネットユーザーは通常ドメインに所属していなかったりなどの技術上の問題により、統合認証が Exchange フロントエンドサーバーでサポートされていなかったため、このオプションを使用できませんでした。前述のサポート技術情報の資料で説明されている更新プログラムを適用すると、こうした制限が取り除かれます。更新プログラムをインストールすると、単に仮想ディレクトリに移動し、ユーザー資格情報を確認するためのメカニズムとして、統合 Windows 認証のチェックボックスをオンにすることができるようになります。このチェックボックスをオンにすると、msexchAuthenticationFlags という属性が、Active Directory の仮想ディレクトリオブジェクトに設定されます (Microsoft 管理コンソールの Adsiedit.msc スナップインを使用して確認できます)。

OWA を使用してメールを確認するユーザーは、使用している Exchange バックエンドサーバーの名前を把握できます。また、企業ネットワークにログオンしている間は統合認証を使用して Exchange バックエンドサーバーに接続できます。統合認証とのユーザーエクペリエンスの違いは、ネットワークにログオンしているため、Internet Explorer によって Web サイトに対して自動的に認証が行われているので、ユーザー名とパスワードの入力を求められない点です。このことは、企業ネットワーク上のユーザーにとっては好都合ですが、社外ユーザー (OWA ユーザーは通常社外ユーザーです) はネットワーク外部から Exchange フロントエンドサーバーにアクセスするとき、通常はドメインにログオンしません (このプロセスは、サポート技術情報の資料「[INFO] IIS におけるブラウザクライアントの認証方法」で詳しく説明されています)。

Exchange Server では、この更新プログラムにより、[委任] タブが、Active Directory のサービスプリンシパル名 (SPN) 属性ではなく A2D2 属性を使用するように設定されます。Adsiedit.msc を使用して Exchange コンピュータオブジェクトを確認すると、2 つの属性に気付きます。Kerberos の制約付き委任リストである A2D2 属性と、Kerberos ロケータおよびアカウント指定ポイントとして機能する SPN 属性です。両方の属性が連携して Kerberos の制約付き委任が行われるのは事実ですが、グラフィカルインターフェイスを使用してA2D2 属性のみを変更してください。

Windows では、組み込みの HOST SPN をエイリアスとして使用して、他のサービスを検索できます。つまり、setspn.exe を Kerberos の制約付き委任に使用しなくても、Exchange フロントエンドからバックエンドへの委任が機能します (SPN 属性リストで HTTP/Servername を明示的に指定すると、このソリューションは機能しますが、管理者の設定ミスによるエラーが発生しやすくなるため、このソリューションは Kerberos の制約付き委任を機能させるための要件にはなっていません)。Kerberos の制約付き委任では、Active Directory の A2D2 属性が検索されます。この属性が設定されていない場合 (または間違った SPN 値に設定されている場合)、Kerberos の制約付き委任はそれぞれのサーバー間で機能しません。ただし、Exchangeh クラスタ上では、フロントエンドサーバーの A2D2 属性がクラスタノードコンピュータアカウントを指してさえいれば正しく機能します。

前述のように、Exchange 2003 サーバーを含む Windows Server 2003 ドメインは、Windows Server 2003 ネイティブ機能モードになっている必要があります。Kerberos の制約付き委任は、ドメインの機能レベルが満たされない限り使用できません。ドメインが混合モードの状態で前述のソフトウェア更新プログラムをインストールすると、更新プログラムは正常に機能するように見えますが、実際には SPN の登録に失敗します。Kerberos の制約付き委任もドメインレベルの機能であり、フォレストレベルの機能ではありません。つまり、Exchange Server 2003 の場合、ISA Server、Exchange フロントエンドサーバー、および Exchange バックエンドサーバーは、同じドメインのメンバである必要があります (ただし、異なるドメインのユーザーでも Kerberos の制約付き委任に対する認証は可能です)。ISA Server インスタンスがドメインのメンバでない場合、または異なるドメインのメンバである場合は、このソリューションの一部としては機能しません。

OWA サイトの構成

IIS Admin は OWA に関する認証の変更には使用しないでください。IIS で実行される OWA が他の Web サイトのようにメタベースの変更に応答したとしても、Exchange の Directory Services to Metabase (DS2MB) プロセスに多少問題が生じます。DS2MB プロセスは、変更を Active Directory から IIS メタベースに一方向のプロセスでレプリケートします。これにより、IIS に対して直接加えられたすべての変更が上書きされます。このプロセスの影響により、管理者が直接 IIS メタベースに変更 (統合認証の設定など) を加えた場合に、そのソリューションが成功したように見えますが、次回の DS2MB レプリケーションサイクルが始まると問題が発生します。

ESM によって直接 Active Directory に対する編集が行われ、変更が IIS メタベースにレプリケートされるため、HTTP 仮想ディレクトリの統合 Windows 認証を有効にするオプションが ESM で使用できるようになりました。システムアテンダントサービスを停止すると DS2MB プロセスも停止し、IIS メタベースに変更を加えてもその変更が上書きされないようにすることができますが、この方法はお勧めしません。システムアテンダントの次回起動時に、システムアテンダントから Active Directory に変更がポーリングされるので、このソリューションは自動的に無効になります。

[委任] タブには、[Kerberos のみを使う] と [任意の認証プロトコルを使う] というオプションが表示されます。ここで説明しているソリューションでは、Kerberos の制約付き委任を使用しているので、単純に考えると [Kerberos のみを使う] を選択すればよいことになりますが、IT の状況はさまざまで、共通の論理は当てはまりません。そのため、[任意の認証プロトコルを使う] を選択します (図 7 参照)。これは、要求は Kerberos 要求としてではなく、Active Directory アカウントにマップされた対応する証明書を備えた HTTP 要求として着信するためです。

図 7 スマートカードの正しい認証設定

図 7** スマートカードの正しい認証設定 **

この場合、ISA Server は SSL 経由でユーザー PKI 証明書を要求します。着信要求は Kerberos チケットではないため、Kerberos の制約付き委任が正常に機能するには、遷移が行われる必要があります。そのため、[Kerberos のみを使う] を指定すると、ISA Server で通信のチェーンが途切れます。ただし、Exchange フロントエンドサーバーは ISA Server から Kerberos チケットのみを受信するため、Exchange のフロントエンドサーバーからバックエンドサーバーへの委任では [Kerberos のみを使う] オプションが機能します。

仮想ディレクトリ \Exchange と \Public のみが、プライベートユーザー情報とパブリックフォルダ情報を含む場所です。Exchange の SSL 構成は、Kerberos の制約付き委任または 2 要素認証にとって新たに必要になるものではなく、基本認証の資格情報を使用する標準の SSL 対応の OWA から持ち越されます。不適切な SSL を使用すると OWA だけではなく、ESM にも問題が発生する原因にもなるので、ドキュメントに記載された方法に従って OWA で SSL を有効にしてください。

構成のその他の詳細

このソリューションを実装する場合、最初に標準の方法で ISA Server と Exchange を展開する方がより簡単です。すべての設定が構成済みの完全な Kerberos の制約付き委任ソリューションを展開しないでください (ISA Server をまだ展開していない場合に特にこのことが当てはまります)。このような展開では、トラブルシューティングプロセスが複雑になり、プロセスの手順が失敗します。ISA Server と Exchange を標準の方法 (ユーザー名とパスワードを使用しますが、フォームベースの認証は使用しません) で展開する方がはるかに容易であり、インストールが正常に機能し、Kerberos の制約付き委任と証明書認証への遷移が確実になります。

通常、スマートカード対応の OWA にはフォームベースの認証を使用できません。フォームベースの認証は、ユーザーが、標準の Outlook フォーム経由で送信するユーザー名とパスワードを所持していることを示します。しかし、スマートカードベースの 2 要素認証では、ユーザーはスマートカードのみを所持し、パスワードは所持しません。そのため、フォームベースの認証には、認証用の証明書のみを授受する方法がありません。認証チェーンのどこか (たとえば、ISA Server の背後のフロントエンドサーバー上) でフォームベースの承認を使用すると、スマートカード対応の OWA 構成は機能しません。フォームベースの認証を有効にすると、Exchange 仮想ディレクトリが強制的に基本認証に設定されるため、IIS メタベースも同様に基本認証に設定されます。

ユーザー名およびパスワードと、スマートカードの両方を混在使用するユーザーが存在する場合は、ISA Web リスナでフォールバック認証を有効にできます。この場合、証明書ベースの資格情報を求められた後にユーザーが Esc キーを押すと、Exchange サーバー上の ISA Server の背後で統合認証を有効にしている場合でも、標準のユーザー名とパスワードの資格情報の入力が求められます。さらに、ISA Server は、フォームベースの認証機能とほぼ同じ方法で SSL セッションをタイムアウトできます。

まとめ

OWA の認証でスマートカードがサポートされることは、Exchange Server 2003 と Exchange Server 2007 の両方にとって歓迎すべき機能追加です。証明書を使用して OWA にログオンする機能により、ユーザーは長くて複雑なパスワードを覚えることに悩む必要がなくなり、管理者は、キーロガーや、侵害されたシステムからユーザー証明書を盗聴できるその他の形式のマルウェアに対して有効な手段を持つことになります。詳細については、「詳細情報」を参照してください。

スマートカードによる 2 要素認証用に ISA Server を適切に構成すると、公開された OWA アプリケーションに対してアプリケーションレベルのフィルタ処理を実行することにより、全体のセキュリティがさらに向上します。また、ISA Server 2006 には簡単な公開ウィザードを使用して Exchange Server 2003 と Exchange Server 2007 の両方を公開する組み込みサポートが用意されているため、組織が Exchange Server 2007 に移行する際にも健全な投資といえます。

詳細情報

Victor Akinnagbeは、ワシントン D.C. の Microsoft に勤務するプレミアフィールドエンジニアです。主な担当分野は、セキュリティ、インフラストラクチャ、およびメッセージングです。

Ted Dresselは、ワシントン D.C. の Microsoft に勤務するコンサルタントです。主な担当分野は、セキュリティおよびインフラストラクチャです。

Jason Opdyckeは、シャーロットの Microsoft に勤務するプレミアフィールドエンジニアです。主な担当分野は、セキュリティおよびインフラストラクチャです。

その他のリソース