「マルウェア・標的型攻撃への対策に、本当に必要なインターネット分離」第2回

vforum-5-5

前回は、「マルウェアとは何か?を理解する」というテーマでご説明しました。

攻撃者はどのように仕掛けてきて、マルウェアは具体的にどのように動いているかを整理し、インターネット分離をするための目的をきちんと設定することの重要性をお伝えしました。第2回は「守りたい情報を設定し、インターネット分離に適した画面転送方式を検討する」を主題とし、何のためにインターネット分離をすべきなのかを今一度考えてみたいと思います。問題に対して、正しい解決策を講じるというシンプルなアプローチです。

  • 第1回:「マルウェアとは何か?を理解する 」
  • 第2回:「守りたい情報を設定し、インターネット分離に適した画面転送方式を検討する」
  • 第3回:「マルウェアの特性とインシデントレスポンス」
  • 第4回:「マルウェアへの対策に求められるインシデントレスポンスとは?」

そもそも、なぜインターネット分離をしなければならないのか?

vforum-5-5

なぜインターネット分離をするのかを考える上では、下記の2つの事項について考える必要があります。

  1. 何を守りたいか?
  2. 何から守りたいか?

何を守りたいか?

何を守りたいかと聞かれれば、多くの人が機密情報と答えると思います。しかしながら、機密情報って何でしょうか?組織が持っている情報のうち、何が機密情報なのでしょうか。実はこれはかなり重要で、守りたいデータごとに配置してある場所が異なるため、対策が異なるのです。機密情報とは具体的に何かを明らかにする必要があります。

何から守りたいか?

何から守りたいかと聞かれれば、多くの人が標的型攻撃マルウェアから守りたいと答えるでしょう。ただ、標的型攻撃やマルウェアといっても1つにまとめて整理することは難しいです。あの事件を2度と起こさないようにしたいであるとか、こういった攻撃から守れるようにしたいといったことをきちんと整理することで、必要なソリューションが見えてくるはずです。

機密情報とは何を指すか?

vforum-6

では、機密情報とはどういったものかを、皆さんでも整理してみましょう。

そもそも個人情報保護法においては、特定の個人を識別することができるものを個人情報と定義しています。そのため、一般的に機密情報とした場合には、マイナンバーであるとか、金融機関であれば預金情報などの顧客情報が挙げられるはずです。これらは情報漏えいした場合に、非常に大きな影響があるので、機密情報として定義して良いと思います。

それでは、業務メールの中身が情報漏えいした場合はどうでしょうか?たとえば、我々のようなITベンダーとのやりとりのメールは機密情報ではないでしょうか?メールの中には、私の名前・役職・組織・電話番号・メールアドレスが含まれていますが、これが情報漏えいしたことが発覚した場合、組織として情報漏えい事件として認識はされないでしょうか?

ほとんどの場合、業務メールも個人情報として認識されるはずです。整理してみておわかりいただけたかと思いますが、情報漏えいした際のことを想像してみると、比較的簡単に整理できると思います。

機密情報の配置とマルウェア到達範囲

vforum-7

よくブラウザ(Internet Explorer)のみを通常業務から分離すれば良いといういわゆる「ブラウザ分離」をインターネット分離と呼んでいるケースがあります。しかしながら、私は「ブラウザ分離」「インターネット分離」は区別してお話しています。

インターネットセグメントに置かれる仮想デスクトップ等からは、ブラウザのみを利用するということは、同じくインターネットに接続が必要なメールは、今まで通り事務用物理PCにて扱うことになります。この場合、ブラウザの脆弱性を突かれるような脅威に対しては効果がありますが、本来守りたい機密情報にアクセスできる物理PCはメールを通じてインターネットに接続している状態になります。

昨今起きている情報漏えい事件は、メールの添付ファイルを開かされてしまい、そこから情報漏えいしているため、これらの事件を防ぎたいと考えていたとしたら、全く何の対策にもなっていないことをご理解いただけるかと思います。

マルウェアは、HTTPの80番ポートとHTTPSの443番ポートを使ってC&Cサーバーにアクセスしているので、ブラウザ分離さえすれば問題ないということをおっしゃられることもありますが、攻撃者側も馬鹿じゃありません。このようにHTTPやHTTPSを止めていることをしれば、別の方法を考えてきます。たとえばメールクライアントを操作して、機密データをメールの添付ファイル等で転送するといったことも考え得るのです。

このように、攻撃者側と守る側では、攻撃する側が圧倒的に有利ですが、ブラウザ分離だけでは、今までお話したとおり、その状況をさらに悪化させていると言えます。

vforum-8

インターネット分離を多く実施された自治体様も、メールによってマルウェアに感染し、情報漏えいをしている事件への対策として、インターネットセグメント側で実施する業務を指定しています。ブラウザだけでなく、メールも通常業務とは分離し、本当に守りたい機密情報をマルウェアの脅威から遠ざけるようポリシー策定しています。

上記のような構成にすれば、たとえメールやブラウザから脅威が入って来たとしても、本当に守りたい機密情報までネットワーク通信が届かないような構成にすることができます。

ではこの構成にすれば何の問題もないのかといえば、答えはNOです。最も守りたい機密情報は守れますが、前項でお話したメール個人情報はインターネットセグメントにあります。これらを情報漏えいしてはいけないということであれば、この構成の上で、さらに対策をしなければならないということになります。

インターネット分離に求められる画面転送方式

今までお話したことを加味して、インターネット分離をする際に最も適した画面転送方式は一体何なのかを考えていきたいと思います。画面転送方式と言っても、市場には以下のような方式が用意されております。
※インターネット分離が、ブラウジングだけでは満たされないことを前提に、ここではLinux VDIは省いています。

vforum-9

大きく分けて、VDIとSBCの2種類があります。それぞれ以下の特徴があります。

  • VDIは、1ユーザーが1OSを専有
  • SBCは、1OSを複数ユーザーで共有

VDI

VDIにも以下の2種類があります。どちらもデスクトップの画面がユーザーに転送され、その中でユーザーが自由にアプリケーションを起動して操作します。

  • クライアントOS VDI:Windows7,8,10といったクライアントOSを利用するVDI
  • サーバーOS VDI:Windows Server 2012等のサーバーOSを利用するVDI
vforum-type1

クライアントOS VDIの場合は、仮想デスクトップとして利用するために、VDAライセンスが必要でその価格がネックになりがちですが、物理PCで動いていたアプリケーションはほとんど動作します。

vforum-type2

サーバーOS VDIは、VDAライセンスより安価なRDS-CALの購入で実現できますが、サーバーOSのインタフェースがユーザーに提供され、サーバーOSなので、動作するアプリケーションに制限があります。

SBC

SBCの場合は、どちらの方式でもサーバーOS VDIの場合と同様に、RDS-CALが必要となります。また、1OSを複数ユーザーで共有するため、マルチユーザーで動作するアプリケーションでなければいけないという制約も追加されます。

SBCでは、ユーザーから見える画面の違いで、以下の2種類があります。

  • SBCデスクトップ画面転送
  • SBCアプリケーション画面転送
vforum-type3

デスクトップ画面転送は、ユーザーが見える画面は、サーバーOS VDIと同一です。裏でそのOSが共有されているかどうかが違いです。この方式では、デスクトップの画面がユーザーに転送され、その中でユーザーが自由にアプリケーションを起動して操作します。

vforum-type4

アプリケーション画面転送は、物理PCのデスクトップ画面上に、必要アプリケーションのウィンドウだけが画面転送されるという技術になります。この方式のみ、ユーザーからの見え方が異なります。

インターネット分離には、どの画面転送方式が最適か

これらの特徴を踏まえた上で、メールやブラウザを扱うためには、どの画面転送方式が最適かを考える必要があります。

vforum-9

実際には80%以上の自治体で、デスクトップ画面転送が採用されました。ブラウジングだけであれば、アプリケーション画面転送で事足りるのですが、メール業務をおこなうにあたっては、ファイル操作のために、デスクトップ画面転送を選んだほうが良いという結論に至ったようです。さらにアプリケーション画面転送だと、物理PCに入っているブラウザと画面転送されてきているブラウザの区別がつかず、ユーザーからの問い合わせが増える可能性があるということも、選ばれなかった理由の1つでした。

マルウェアとは

次回のテーマは、何から情報を守りたいかについてです。一般的に、標的型攻撃やマルウェアからという回答が返ってきますが、これらの脅威を真の意味で理解しなければなりません。その上で、セキュリティ運用の中で求められる「インシデントレスポンス」がどうなるのかについて、お伝えしたいと思います。

ABOUTこの記事をかいた人

Junnosuke Nakajima

2010年にVMwareに入社し、お客様担当エンジニアとして活動中。肩書はLead Systems Engineer。「VMwareの基本」「改訂新版VMwareの基本」という2冊の著書がある。2016年からは、CTO Ambassadorとして、現場と開発のギャップを埋める役割も担っている。