読者です 読者をやめる 読者になる 読者になる

フルスタックエンジニアを目指して

いろいろやってみるブログ

Microsoft Office 365系サービスとプロキシサーバ

インフラ

Microsoft Office 365を利用するケースが増えているようですが、プロキシサーバとの相性があるようなので書いておきます。

 

プロキシサーバ経由で、Microsoft Office 365(以下O365)系のサービスを利用する場合、いくつか注意点があるようです。

 

利用セッション数増によるプロキシ負荷増大

O365系のサービスを利用する場合は、1セッション/1ユーザというわけにはいかず、数10セッション/1ユーザということもあり得るそうです。Outlookだけでも20~30セッションを消費するらしいですので、従来のWEBアクセスだけをスコープに入れていると、O365系サービスを導入した際にプロキシが耐えきれないなんてことが起きるかもしれません。

 

そもそもプロキシ経由での利用が推奨されていない

一次資料は見つけられなかったのですが、NTT Communicationsのサイトに以下の記載がありました。

Office 365は、FirewallやProxyを経由しない構成が推奨構成となっております。

参考:Office 365を使う上でネットワーク構成上の条件はありますか? | Enterprise Cloud Office 365 ハイブリッドオプション | NTT Com お客さまサポート

 

現在の企業ネットワークでは、プロキシはまだしも、Firewallを使わないケースはレアケースかと思いますので、この制約はなかなかの鬱陶しさがあります。推奨していない理由の一つには、プロキシ認証が間に挟まるとうまく動作しないことが知られています。

参考:運用を見据えた失敗しないOffice365導入

 

実際、以前紹介したプロキシサーバへのBasic認証やDigest認証の導入をした上で、O365系のサービスに接続しようとした場合、O365系の認証のポップアップが10個くらい連続して上がってきました。このような状態ではユーザが耐えられませんので、何かしらの方法(プロキシの例外設定やPACファイルによる制御)が必要となります。

 

FQDNが頻繁に変わるため制御が困難

上記でPAC制御などで逃げるしかないと書きましたが、一筋縄ではいきません。O365系のサービスで使われるFQDN、IPは以下のサイトに明記されています。

参考:Office 365 URL および IP アドレス範囲 - Office 365

 

これらのFQDN、IDは突如変更されることが知られています。これを知る方法としてはRSS配信を見逃さないようにしかありません。少なくとも50程度のFQDNが存在しており、これらすべてを管理、運用していくことは正直言って難しいです。というかやりたくありませんよね。プロキシに認証をかましている限りやらざるを得ないのですが。

 

最近は、このような事例に対するソリューションもいくつか出てきているようですので、検討してみてもいいかもしれません。

参考:Office365によるプロキシ負荷の増大をNetScalerで解決 - アセンテック

参考:ASCII.jp:FNETS、「Office 365」利用時のプロキシ負荷低減ソリューション

 

以上、プロキシ目線での留意点でしたが、クラウドサービスと付き合っていくには、インフラとして注意すべきことがたくさんあるようなので、皆様お気を付けください。