jump to navigation

ネットワークセキュリティ よくある設計ミス10選 11月 14, 2009

Posted by hyhy in 技術情報.
Tags:
trackback

しっかりした計画と設計がセキュリティ侵害の可能性を小さくする。この記事では、注意すべきセキュリティデザインの間違いをいくつか説明する。

ネットワークセキュリティの確保は、疑いなくIT部門の最も重要な機能の1つだ。ところが、ネットワークセキュリティの設計上、簡単に実践出来ることを見逃している組織をよく見かける。この記事では、ネットワークの安全性を脅かし、企業資産を危険にさらすよくある誤りについて紹介する。

1:設定したら忘れる
私が最初に説明したいのは、設計上の問題と言うよりは、計画の問題だ。この問題には、私が「設定したら忘れる」と呼んでいるメンタリティが関係している。これは、組織がネットワークのセキュリティを向上させることには力を入れておきながら、立ち止まってセキュリティプランを再評価することはしていない場合に起こる。セキュリティに対する脅威は常に変化しており、それに合わせてセキュリティアーキテクチャも変化する必要がある。これを実現するためには、セキュリティ上のニーズを定期的に再評価するのが一番だ。

2:ファイアウォールに必要以上のポートを開ける
われわれは、ファイアウォールに多くのポートを開けることは悪いことだと知っているが、どうしても必要な場合もある。Microsoft Office Communication Server 2007 R2を例に取ってみよう。外部からのアクセスを許そうとする場合には、1ダースほどのポートを開ける必要がある。これに加え、OCS 2007 R2では、さまざまなポートを動的に割り当てる。では、セキュリティ管理者はどうすべきなのだろうか。

 最善の問題解決方法は、リバースプロキシ(たとえばMicrosoftのForeFront Threat Management Gatewayなど)を利用することだ。リバースプロキシはインターネットとさまざまなポートを開ける必要のあるサーバとの間に置かれる。ポートを開けることは避けて通れないものの、リバースプロキシはリクエストを横取りしてフィルタリングし、その後それらのリクエストを意図されていたサーバに渡すという動作をする。これによって、サーバを外界から隠し、悪意を持ったリクエストがサーバに到達しないようにすることができる。

3:1台のサーバを兼用する
経済が壊滅状態にある現在、既存のサーバ資源を最大限に利用することに対する圧力が高まっている。このため、複数のアプリケーションや、アプリケーションの複数の役割を、1台のサーバにホストさせたいと思うこともあるだろう。この慣習は必ずしも悪いものではないが、コード行数が増えれば、脆弱性が存在する可能性も増すという法則がある。

 アプリケーションごとにサーバを1台用意するのは現実的でない場合もあるが、少なくともどのアプリケーション、どのアプリケーションの役割を1台にまとめるかについては、よく検討する必要がある。たとえば、Exchange 2007を使う組織には、少なくとも3つの役割のサーバ(ハブトランスポートサーバ、クライアントアクセスサーバ、メールボックスサーバ)が必要となる。これら3つの役割を1台のサーバでホストすることも可能だが、Outlook Web Accessを外部のユーザーに対して提供しようとしている場合には、役割の統合は避けるべきだ。クライアントアクセスサーバは、Outlook Web Accessの提供にIISを利用している。このため、クライアントアクセスサーバの役割と、ハブトランスポートサーバおよびメールボックスサーバの役割を同じサーバ上においてしまうと、メールボックスデータベースをインターネットに晒してしまうことになる。

4:ネットワークワークステーションを無視する
1年ほど前、ラジオ番組のインタビューで、ネットワークセキュリティの最大の脅威は何だと思うかと誰かが聞いてきた。私の答えは、ワークステーションが最大の脅威だというものであり、今でもその考えは変わっていない。ネットワークサーバについては安全性の確保に大変な手間をかけるのに、ワークステーションについてはほとんど無視している組織をよく見かける。適切にロックされていない限り、ユーザー(あるいは悪意のあるウェブサイト)は、ワークステーションに承認されていないソフトウェアを密かにインストールできる。

5:必要なところでSSLの暗号化を使っていない
誰もが、ユーザーがユーザー名とパスワード、あるいはクレジットカード番号などの秘密の情報を入力する場面では、必ずSSLの暗号化を必要とするということを知っている。しかし、自社のウェブポータルを安全にすることについては、多くの組織が誤った判断をしている。私がもっともよく見かけるセキュリティホールは、安全なページに安全でないコンテンツを掲載することだ。この場合、ユーザーは安全性を要するコンテンツにも、不要なコンテンツにも、表示をしたいかどうかを尋ねられることになる。これによって、ユーザーは安全性を必要としないコンテンツに対しても、表示する許可を与える癖をつけてしまう。

 それよりは目立たないが、より一般的な問題として、組織がウェブサイト内の重要なページに暗号化を施していないことが多いということが挙げられる。私の意見では、セキュリティ情報やセキュリティ上のアドバイス、連絡先情報を含むページはすべて、SSLで暗号化されるべきだ。これは、これらのページが特に秘密の情報を扱っているからというわけではない。ただ単に、暗号化のプロセスで使われている証明書によって、アクセスしているページが正規のものであり、フィッシング詐欺の一部として誰かが作成したページではないということをユーザーに対して保証できるからだ。

6:自己署名証明書を使っている
一部の組織がSSLによる暗号化の重要性を完全に無視しているため、Microsoftは同社の製品の一部に自己署名証明書を同梱し始めた。こうしておけば、その組織が自前の証明書を取得していない場合でも、SSLによる暗号化を使用したウェブインターフェースを使うことができる。

 自己署名証明書は、ないよりはましだとは言え、信頼されている証明機関から発行された有効なSSL証明書の代わりにはならない。自己署名証明書はもともと、管理者がある製品の安全性を適切に確保するまでの間、そのセキュリティを向上させるために用意されたものだ。確かに、自己署名証明書でSSLによる暗号化を提供することはできる。しかし、ユーザーはブラウザから、その証明書は信頼できないとして警告を受ける(そして、そうあるべきだ)。さらに、一部のSSLを使ったウェブサービス(たとえばActiveSync)は、信頼の問題から、自己署名証明書を用いて利用することはできなくなっている。

7:過剰なセキュリティログ
ネットワーク上で起こったイベントに関してログをとることは重要だが、やりすぎてログを過剰に取らないことも大切だ。ログが多すぎると、本当に見るべきセキュリティイベントを見つけることが難しくなってしまいかねない。すべてのログをとろうとするよりも、本当に意味のあるイベントだけに焦点をあわせた方がよい。

8:仮想サーバを無作為にグループ化する
仮想サーバはホストサーバ上に性能に基づいてグループ化されるのが一般的だ。たとえば、要求の高い仮想サーバは、いくつかの要求の低い仮想サーバと組み合わせられるかもしれない。性能の観点から言えばこれはいいアイデアだが、このアプローチはセキュリティの観点からは最高のアイデアとは言いがたい場合もある。

 私は、インターネットに接続される仮想サーバには。専用の仮想ホストを用意することを勧める。もし、インターネットユーザーにサービスを提供する3つの仮想サーバがあれば、それらのサーバを1つの仮想化ホスト上にグループ化するようにし、社内インフラ用のサーバ(ドメインコントローラなど)はそのホストには乗せないようにする。

 その理由は、VM escapeに対抗するということだ。VM escape攻撃とは、ハッカーが仮想マシンから抜け出してホストの制御を握ることを意味する。私の知る限りでは、実際にこのVM escapeを行う方法を見つけた者はいないはずだが、いずれその日が来ることは確実だ。そうなったとき、もしインターネットに接している仮想マシンのホストが、同様に強化されているウェブを提供するサーバとしか共有されていなければ、攻撃に対処出来る可能性はずっと高まる。

9:DMZにメンバサーバを配置する
可能であれば、DMZにメンバサーバを配置しないようにすべきだ。メンバサーバが侵害を受けると、Active Directoryに保存されている情報が漏洩してしまう。

10:アップデートのインストールをユーザーに頼る
最後に挙げるよくあるセキュリティ上の問題は、セキュリティパッチの適用をユーザーに任せるということだ。私は最近、いくつかのネットワークで、ネットワーク上のワークステーションにパッチを適用するのにWSUSを使用している例を見た。残念ながら、これらの例では、ユーザーにオプションをクリックさせ、最新のアップデートをインストールさせていた。問題は、ユーザーがアップデート作業にはコンピュータの再起動が必要になることを知っていることだ。一部のユーザーは、アップデートをいつまでも先延ばしにしてしまうかもしれない。エンドユーザーに依存するのではなく、パッチ管理ソリューションを利用して、セキュリティパッチを自動的に適用するようにし、この問題についてはユーザーに選択肢を与えないようにすべきだ。

原文

広告
%d人のブロガーが「いいね」をつけました。