昨日までエントリで、「標的型攻撃」の巧妙な仕組みと、狙われる企業側の「弱点」について説明した。今日のエントリから、Citrix製品を使った効率的かつ効果的な対策について提案してみたい。既に過去のエントリで前置きが長くなったので結論を急ごう。私が提案する対策は次の2つだ。

1) XenAppを使った外部メール環境の隔離(入口対策)

2) XenAppを使ったインターネット閲覧環境の隔離と、端末上のWebブラウザからの直接的なインターネット参照のブロック(出口対策)

この2つは、それぞれ「入口」と「出口」を対策するものだ。いずれも狙われる企業側の「弱点」を補強する対策である。2つの対策の双方を実施すればそれだけ強い対策となるが、片方だけでも標的型攻撃への対策として相当な効果があると確信している。なぜなら標的型攻撃は、企業ネットワークの入口と出口をいずれも通過する必要があり、片方でも塞がれるとほぼ無力化してしまうからである。

「一つだけ取り入れるとしたらどちらか?」あるいは「2つとも取り入れるとして、どちらが先か?」と問われれば、2)の出口対策を実施していただくことを強くお勧めする。出口対策を先にお勧めする理由は複数あるが、最大の理由は入口対策に比べて導入が簡単で、利便性を損なう度合いが少ないことによる。他の理由も含めて、理由の詳細は後述する。

なお、このBlogの読者の中には「XenAppって何?」と言われるかたも多いと思う。別途機会を改めてXenAppを解説したいと思うが、当面はCitrixサイトの他、こちらこちらをご覧になっていただきたい。

以下、2)の出口対策について、さらに詳しく説明しよう。

対策の前にまず、一般的な企業でのWebアクセスについて復習する。どこの企業でも、基本的には下図のような仕組みになっているはずだ。(クリックで拡大)
一般的な企業LAN内からのWebアクセス

細かいことを言うと、Webプロキシサーバーが入っていたり、コンテンツフィルタリングをしていたりするかと思うが、残念ながらこれらは根本的な対策にはなっていない。私が訴えたいポイントは、ほとんどの企業が「ユーザ端末(パソコン)上のWebブラウザを使ってインターネット上のWebページを閲覧している(閲覧できる)」と言うことである。

「何を当たり前のことを言っているのか!」と言われそうだが、XenAppを使った出口対策とは、その「当たり前」を否定することから始まる。下の図を見ていただきたい。(クリックで拡大)
XenAppを使ったWebアクセスの隔離

注目していただきたい点は、「インターネットWebサイトを閲覧するWebブラウザは、ユーザ端末上では動いていない!」と言うことだ。ユーザ端末上では、Webブラウザが動作しているように見えるが、それは実際端末上で動作しているわけではなく、XenApp上で動作しているWebブラウザの「画面」が転送されてそれを遠隔操作しているに過ぎない。--最近流行の言葉で言えば「アプリケーション(Webブラウザ)が仮想化されている」とも言えるだろうか--

この仕組みの最大のポイントは、ユーザ端末から何らかの形でインターネットアクセスすることを、ネットワーク的に完全に禁止できることだ。一般的なWebプロキシサーバの導入も、「直接的なアクセスを禁止して間接的なアクセスのみ許可する」と言う観点では良く似ているが、XenAppを使った方法は、一般的なプロキシとは以下の点で完全に異なる。

一般的なWebプロキシを使った接続では、WebアクセスのTCPポート番号の変換は行われるが、HTTP通信の「中身」は、ほとんど手を加えられずに送られる。したがって、端末がウィルスに感染してそのウィルスがInternet Explorerのプロキシの設定を読み込めば(それは特別難しいことではない)、ウィルス自身もプロキシ経由の接続をしてしまえば、直接的にインターネットに接続しているのと何ら変わりない動作が可能である。

それとは違い、XenAppを使った「間接接続」では、ユーザ端末とXenApp間の通信はHTTP通信とは「中身」が全く異なる。ユーザ端末からXenAppへ送られるのは、キーボードの入力とマウスの動きの情報だけなのである。この仕組みによって、一連の事件で起きたような「ユーザ端末に感染したウィルスが、勝手に外部と通信する」事態を根本から防ぐことが出来るのだ。


これまで、ネットワーク的な仕組みを見てきたが、利用するユーザの視点に立つと、XenApp上のWebブラウザ利用は、下図のようなイメージになる。(クリックで拡大)
仮想IEの動作イメージ

Webブラウザが2つ立ち上がっているだけのように見えるが、よーく見ていただきたい。左上がIE6で、右下が(Windows XPでは本来動作しないはずの)IE9となっている。このIE9こそ、実際にはXenApp上で動作していて、画面転送・遠隔操作によってユーザ端末から利用できるようになっているものだ。一度起動してしまえば、ユーザは端末上のWebブラウザとほとんど同様に「仮想化されたWebブラウザ」を利用できる。

すぐ上で「ほとんど同様に」と書いたが、端末上のWebブラウザと仮想化されたWebブラウザでは異なることがある 何が異なるかと言うと、仮想化されたWebブラウザと、その他の端末上で動作するアプリケーションの間では「データ交換」が出来ないのだ。例えば、メモ帳で書いたテキストをコピーして、そのテキストをWebブラウザ内のフォームに「貼り付け」することは出来ないし、ユーザ端末上のファイルをWebブラウザを使ってインターネットサイトにアップロードすることは出来ない(注1)。

このWebブラウザとのデータ交換の無効化は、確かに不便なことかもしれない。しかしそれは、導入をためらうほど致命的なことだろうか?いや、それほど悪いことではないだろう。「外部インターネットを閲覧するためのWebブラウザ」に限定してデータ交換が出来なくなることは、ほとんどの企業で業務に支障がでるほどのこととは考えにくい。むしろ、「インターネットへファイルをアップロードできない」ことや「インターネットから端末にファイルをダウンロードできない」ことは、標的型攻撃への対策から離れたとしても企業のIT管理者にとって魅力的なことではないだろうか?

この「XenAppによるインターネットアクセスの分離」に関しては、実は一部の企業でこのような使い方が既に始まっている。それら企業がこのような対策を取り入れた一番の理由は、標的型攻撃への対策ではなかった。実は「インターネット経由で進入する脅威への入口対策」だったのだ。同じ対策が、標的型攻撃に対しては、出口対策にもなっていることは非常に興味深い。

さてここで少し、「1)入口対策」のことも触れてみよう。これを実施した場合に隔離の対象となるのはメールソフトである。入口対策のためには、これらメールソフトとその他のアプリケーションを隔離して、データ交換を禁止することになるわけだが、これは確かに利便性の面で悪い影響が大きいだろう。実はこのことが、「1)入口対策」よりも「2)出口対策」をお勧めする最大の理由なのだ。入口対策でメールソフトを隔離することは、セキュリティ面ではその効果が大きいものの、セキュリティ面以外に及ぼす影響があまりにも大きすぎる。
今日のエントリでは「2)出口対策」について詳しく説明したが、日を改めて「1)入口対策」についてもじっくり説明したい。


(注1)
実は、XenAppの機能としては、端末と仮想アプリ間のコピー/ペーストやファイル交換は可能である。しかし管理者側で定めるポリシー次第では禁止することも出来る。セキュリティ目的でXenAppの仮想アプリケーションを導入する場合、データ互換の機能は禁止することが妥当だろう。