仙石浩明の日記

2006年10月5日

グループウェア・サーバを社内に置こう! hatena_b

何をいまさら、という声が聞こえてきそうですが、 社内からの情報漏洩が問題となっている今だからこそ、 あらためて社内情報を扱うサーバを、 社内LAN に置くことの重要性を訴えたいと思います。

もともと、グループウェアといえば社内のサーバに置くのが当たり前だったのですが、 いろいろな情報がグループウェアに蓄積されるにつれ、 社内からだけでなく、社外にいるときもグループウェアにアクセスしたい、 というニーズが高まってきました。

グループウェアを社外からも利用するには、 サーバをどこに置くかで分類すると、 次の 3 通りの方法があります。

  1. 社内LAN に置く
    ファイアウォールに穴をあけて社内のサーバへアクセスできるようにするか、 あるいは VPN などの方法で社内からのアクセスを社内へ導く方法です。 正規のアクセス以外の、招かざる客を確実に排除できなければなりません。
  2. DMZ 上に置く
    社外からもアクセスできる非武装地帯 (DMZ) にサーバを置く方法です。 ファイアウォールで守られない場所に置くのですから、 サーバは自分自身を守ることができなければなりません。
  3. 社外に置く
    他社が提供するグループウェアASP サービスを利用する方法です。 情報管理を他人任せにできるので一番手間がかかりませんが、 万一情報漏洩が起きたときに誰が責任をどうやって取るのか、 契約等ではっきり決めておかないとトラブルの種となるでしょう。

いずれも一長一短があるので、いちがいにどれがいいとは言えませんが、 それぞれどのようなリスクがあるかきちんと把握した上で利用することが重要ですね。

手軽さだけで言えば、もちろん 方法3 が一番簡単なのですが、 手軽なだけにリスク管理が出来ていない人が利用すると、 情報のダダ漏れが起きます。

【警告】Googleカレンダーで情報流出? から引用:

無防備な人が多いには驚きます。 Googleカレンダーで、 まるでソーシャルブックマークみたいに公開設定をしている人が何人もいます。 実に詳細な仕事のスケジュールが公の場にさらされており

ということも実際に起きているようです。

じゃ、公開設定しなければ安心か、というとそうとも言えません。 別に ASP サービスを提供している会社を信用しないわけではないのですが、 サーバに情報をため込めば、サーバの運用管理を行なう過程で、 どうしたってその情報が漏れるリスクはあります。 万一漏れたときに ASP サービス提供会社がどう責任をとってくれるのか、 確認しておきたいところです。

他人任せにするのは、どうも気持ち悪い、という場合は 方法1 あるいは 方法2 を選択することになります。 方法2 は、ASP サービス提供会社が行なっているのと同等のことを 自社で行なうイメージですね。 自社で運用するので、情報漏洩が起きたときの責任の所在ははっきりしていて いいのですが、 どうやって外部からの攻撃を防ぐかが問題となります。

インターネット上でサーバを安全に運用することが困難だからこそ、 各種 ASP サービスが提供されているわけで、 きちんとしたサーバ運用管理体制を整えずに運用したりすると、 あらゆる攻撃を受けて侵入されてしまうかも知れません。 また、サーバそのものは運用できていても、 グループウェアの側に脆弱性があって、漏洩事故が起きてしまうケースもあります。 そもそも、きちんとサーバを運用できるだけの体制を整えられるのなら、 ASP サービスの提供側になったほうがよさそうです。

と、いうわけで結論は、方法1 の「グループウェア・サーバを社内に置こう!」です。 この方法のいいところは、社内で使っているグループウェア・サーバを、 変更なしにそのまま使えるという点で、 気をつけなければならないのは、正規のアクセス以外の不正侵入を どうやって確実に排除するか、という点です。

社内で使っているグループウェア・サーバをそのまま使うわけですから、 何らかの脆弱性があることを前提としなければなりません。 脆弱性がないなら DMZ に出しておけるわけで、 社内に置く最大のメリットは、多少の脆弱性は許容できるという点にあります。 だから、 正規ユーザ以外からのアクセスは決して、 社内サーバに到達できないようにしなければなりません。

では、どうやって不正アクセスを排除すればいいのでしょうか? ファイアウォールに穴を開ける方法にせよ、 VPN を使う方法にせよ、 何らかの「入口」を設置して、 そこで正規アクセスと不正アクセスを選別することになりますが、 この「入口」を適切に運用管理することは結構大変です。 不正アクセスを試みる人は、なんとかこの「入口」をだまして 通ろうとするわけで、 「入口」をきちんと運用管理する体制を整えなければなりません。

あれ? 結局これでは 方法2 と同じですね?

そこで、「VPNワープ」です (我田引水... ^^;)。 VPNワープは、この「入口」を提供する ASP サービスなんです。 グループウェア・サーバ自体は社内に置いて情報漏洩のリスクを抑えつつ (方法1 の長所)、 「入口」の運用管理だけ他社 (つまり KLab) 任せにして手軽さも確保する (方法3 の長所)、 方法1 と 方法3 のいいとこどりの「入口ASP」、それが VPNワープです。

今月末まで無料スタートキャンペーン中ですので、 ぜひこの「入口ASP」をお試し下さい。 BIGLOBE会員のかたは、「エージェント」と「SSL証明書」を ダウンロードするだけで利用できますし、 BIGLOBE会員でないかたも、 初期費用・月額費用が無料の 「コンテンツ」コースに入会すれば、 すぐ VPNワープをお試し頂くことが可能です。

Filed under: システム構築・運用 — hiroaki_sengoku @ 13:56

1 Comment »

  1. 技術的に信頼できる会社があっても、生のデータを
    渡すのはいろいろマズイ。
    だから入り口の管理だけを請け負ってもらう。
    凄く良いアイデアですね。

    Comment by methane — 2006年10月7日 @ 12:20

RSS feed for comments on this post.

Leave a comment