エンタープライズシステム市場の主要な場所の1つは、Microsoft Exchangeソリューションです。MicrosoftExchangeソリューションは、長ズボンから長く成長し、通信を提供するタスクの範囲を超えました。
これは、製品の複雑さと、ソリューションの実装および運用中に管理者が解決するタスクの量に影響を与える可能性があります。 これらのタスクのいくつかを検討してみます。
リバースプロキシ
2012年9月12日、マイクロソフトは、Forefront TMGの販売終了日と、この製品のサービスおよび技術サポートの終了スケジュールを発表しました。 それにもかかわらず、CASサーバーへの直接アクセスの事前承認と禁止は、依然として良い考えです。 リバースプロキシをまだ導入していない場合は、リバースプロキシを導入すると、パブリックインターネットからWebサービスへの安全なアクセスを整理できます。 MS Exchange 2013の世界では、これらはOWA、ActiveSync、Exchange Webサービス、およびOutlook Anywhereです。 事前承認により、権限のないユーザーからのデータが保護されたシステムに到達しないことを確認できます。 さらに、「適切な」リバースプロキシは2要素認証をサポートします。 したがって、ネットワークにまだリバースプロキシがない場合は、考えてみる必要があります。 特に、リバースプロキシは、SharePointやLyncなどの他の企業Webアプリケーションに同じレベルのセキュリティを追加できるという事実を考慮してください。
OWAへの安全なアクセス
「クライアントソフトウェアは安全なSSL接続を介してサーバーに接続します」というフレーズをよく耳にします。 しかし、これによりユーザー資格情報の漏洩を防ぐことができますか？送信されたデータを検査し、パブリックネットワークから確立されたSSL接続が本当に信頼できることを確認できますか？ 実践が示すように、答えは尋ねられたすべての質問に対する答えではありません-SSL自体はあなたを保護できません。
モバイルデバイスの数とスマートフォンやタブレットなどの機能の増加は、個人的なだけでなく、会社の従業員による企業のタスクを解決するための後者の使用の成長に貢献しています。 同時に、デバイスは依然として個人的なものであり、これらのデバイスのステータスをITサービスで管理する能力は、それ以上ではないとしても非常に困難です-完全に存在しません。 この場合、デバイス自体と企業アプリケーションとの相互作用を検査しないと、明らかに安全ではなくなります。
さらに、OWAを使用すると、ネットワークへのアクセスがなくてもユーザーがアプリケーションを操作できるようになることを忘れないでください。つまり、モバイルデバイスにメール通信の内容を保存します。 これはセキュリティリスクの1つです。
トラフィック分布
MS Exchange 2013の開発者が使用する新しいアーキテクチャソリューション（名前空間の統合、CASでの状態制御の放棄など）により、分析を必要とせずに、ネットワークレベルで利用可能な情報を使用するCASサーバー間でのユーザーの分布を決定できましたアプリケーション自体のデータ。 ただし、このソリューションは、ユーザーにサービスを提供するCASとメールボックスサーバーの両方の最適な選択を保証するものではなく、これらのサーバーはCASサーバーからアクセスされます。 さらに、MS Exchangeには、ソリューションの個々のコンポーネント（OA、OWA、EAS、EWS、AutoDiscoveryなど）の相互作用が実行される多くのサービスWebサービスがあります。 これらのサービスを使用して、各サービスのステータスを個別に監視できます。 クラスターの成長に伴い、MS Exchangeソリューションが同じデータセンター内と分散インストールの両方に展開されることに基づいて、上記のすべては、ソリューションのコンポーネント間でユーザートラフィックが最適に分配されない可能性が高くなります。 たとえば、メールボックスがデータセンターAに保存されているユーザーは、データセンターBにあるCASサーバーによってサービスのために送信されます。さらに、DNSサービスによる負荷分散技術は、名前空間から残された名前空間からの運用除外の問題を解決しませんソリューションコンポーネントの構築。
F5ネットワークソリューションとMS Exchangeとの統合
上記の問題のリストは、MS Exchangeに基づくソリューションの実装または新しいバージョンへの更新の計画中と運用中の両方で生じた、パートナーとその顧客のコンサルティングリクエストに基づいています。
これらの質問に対する回答では、パートナーと顧客が、MS Exchange展開のスケーラビリティ、セキュリティ、および高可用性を可能にする統合ソリューションとしてF5 Networks製品に注意を払うことをお勧めします。
F5製品ラインは、プラットフォーム（BIG-IP / VIPRION）とソフトウェア（TMOS）で構成されています。 このプラットフォームには、単一のモジュール式ソフトウェアで管理される仮想実装とハードウェア実装の両方が含まれています。 ソフトウェアにはすべての可能なモジュールが含まれており、その使用は確立されたライセンスによって規制されています。
製品ラインで使用可能な汎用モジュールの中で、この場合は次のことに注意する必要があります。
•Local Traffic Manager（LTM）-柔軟な分散アルゴリズムと方法を提供する、非常に手頃で効率的なロードバランサー。
•HTTPS接続の終了により、CASサーバーのコンピューティングリソースの負荷が軽減され、MS Exchange 2010、2013、および次のリリースに基づいたソリューションでのTLS / SSL証明書の管理が簡素化されます。
•Access Policy Manager（APM）により、ユーザー認証、ワンタイム認証（SSO）の2つの要素、HTTPプロトコルに基づいてExchangeサービスへのアクセスが実行されるデバイスの制御など、2つの要素を事前に整理できます。
•LTMモジュールのTCP Expressおよびデータ圧縮機能により、アプリケーションへのアクセスに使用されるデータ伝送ネットワークの特性を考慮し、最適な方法でネットワークスタックを構成し、ネットワーク経由で伝送されるデータ量を削減できます。
•GTMおよびAAMは、地理的に分散したMS Exchangeクラスターが展開されている場合に使用できます。 GTMモジュールは、アプリケーションへのフォールトトレラントな地理的位置の影響を受けたユーザーアクセスを提供するように設計されています。AAMモジュールは、MS Exchangeソリューションの地理的に分散したコンポーネント間の内部オフィストラフィックを最適化します。
F5とMS Exchangeの共同実装には多くのシナリオがあります。 最も一般的なスキームのいくつかに注意を向けたいと思います。
BIG-IP LTM-CASサービスのトラフィックのバランスと最適化
このソリューションでは、F5機器を使用して、クライアントとアプリケーションアクセスサービス間のトラフィックを制御および最適化します。 オプションで、APMとAFMを使用してセキュリティを強化できます。 このシナリオを図に示します。 1。
このシナリオでは：
1.すべてのクライアントトラフィックはBIG-IPを通過します
2.このデバイスでライセンス交付を受けてアクティブ化されるオプションのモジュールにより、次の機能を実装できます。
a。 BIG-IP Access Policy Manager-Outlook Web App、Outlook Anywhere、ActiveSync、およびAutoDiscoverのサービスにアクセスする際のユーザーの事前承認。 事前承認は、Active Directoryユーザーデータベースを使用するか、2要素認証メカニズムを使用する従来の方法でのみ実行できます。 さらに、企業標準への準拠のためにアクセス元のユーザーデバイスを監査することもできます。
b。 BIG-IP Advanced Firewall Managerは、接続監視機能を備えた高性能プロキシファイアウォールです。
3. BIG-IP Local Traffic Manager-RPC、POP3、IMAP4などのサービスのトラフィックを含む、クライアントトラフィックの分散と最適化。 HTTPプロトコルに基づいていないトラフィックアプリケーション。
図1
機能負荷を複数のデバイスに分散するシナリオ
ソリューションの負荷が増大すると、いくつかの方法で開発が可能になります。 それらの1つは、複数のデバイス間での機能負荷の分散です。 このシナリオは、機能の順次開発にも適用できます。 概略的に、このシナリオは図に示されています。 2および3。
LTMモジュールを備えたBIG-IPデバイスは、アクティブ化されたAPMモジュールを備えたBIG-IPデバイスによる予備処理の後、クライアントサービスにHTTPアクセストラフィックを配信します
シナリオのこの部分では、クライアントトラフィックは次のアルゴリズムに従って処理されます。
1. HTTPプロトコルに基づくアプリケーションのトラフィックは、BIG-IP APMで前処理されます（処理の詳細については、スクリプトの次の部分を参照してください）。
2. LTMモジュールを備えたBIG-IPデバイスは、APMモジュールを備えたBIG-IPデバイスから受信したHTTPトラフィックを分散および最適化します。 HTTPプロトコル（RPC、POP3、IMAP4など）に基づいていないトラフィックアプリケーションは、このデバイスに直接送信されます。
3.企業のローカルエリアネットワークにあるクライアントのトラフィックも、LTMモジュールを備えたBIG-IPデバイスに直接送られ、そこで分散および最適化されます。
4. BIG-IP Local Traffic Manager-RPC、POP3、IMAP4などのサービスのトラフィックを含む、クライアントトラフィックの分散と最適化。 HTTPプロトコルに基づいていないトラフィックアプリケーション。
図2
アクティブ化されたAPMモジュールを備えたBIG-IPデバイスは、サービスへの安全なリモートアクセスを提供します
一般的なシナリオのこの部分では、次の機能を実装します。
1.アクティブ化されたAPMモジュールを備えたBIG-IPデバイスは、Outlook Web App、Outlook Anywhere、ActiveSync、およびAutoDiscoverサービスへのアクセス時にユーザーを事前承認します。 事前承認は、Active Directoryユーザーデータベースを使用するか、2要素認証メカニズムを使用する従来の方法でのみ実行できます。
さらに、企業標準への準拠のためにアクセス元のユーザーデバイスを監査することもできます。
2.許可されたクライアントの正当なトラフィックは、さらなる配布と最適化のために、LTMモジュールを備えたBIG-IPデバイスに送信されます。
図3
エピローグ
エンドユーザーには最新のソリューションはシンプルに見えますが、ソリューションの管理者にとっては複雑なタスクとなり、1つまたは複数のハードウェアメーカーとソフトウェア開発者の製品を使用して多くのシナリオを使用できます。 このようなソリューションの導入は、一見しただけでは単純で理解しやすいように見えますが、実際には、後続の操作と使用を複雑にする可能性のある暗黙的で明白でないサブタスクに直面しています。
記載されている統合ソリューションに興味があり、実装の技術的な詳細を知りたい場合、またはF5製品ラインをより詳しく知りたい場合は、喜んでお手伝いします。 質問をf5@comptek.ruに送信してください