2006年10月
2006年10月05日何をいまさら、という声が聞こえてきそうですが、 社内からの情報漏洩が問題となっている今だからこそ、 あらためて社内情報を扱うサーバを、 社内LAN に置くことの重要性を訴えたいと思います。
もともと、グループウェアといえば社内のサーバに置くのが当たり前だったのですが、 いろいろな情報がグループウェアに蓄積されるにつれ、 社内からだけでなく、社外にいるときもグループウェアにアクセスしたい、 というニーズが高まってきました。
グループウェアを社外からも利用するには、 サーバをどこに置くかで分類すると、 次の 3 通りの方法があります。
- 社内LAN に置く
ファイアウォールに穴をあけて社内のサーバへアクセスできるようにするか、 あるいは VPN などの方法で社内からのアクセスを社内へ導く方法です。 正規のアクセス以外の、招かざる客を確実に排除できなければなりません。 - DMZ 上に置く
社外からもアクセスできる非武装地帯 (DMZ) にサーバを置く方法です。 ファイアウォールで守られない場所に置くのですから、 サーバは自分自身を守ることができなければなりません。 - 社外に置く
他社が提供するグループウェア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ワープをお試し頂くことが可能です。
2006年10月02日「技術をウリにする会社は、その立ち上げメンバに三種類の人種が含まれていることが必須なのだと思います」と以前書いたのですが、 「人種」が異なる人が出会う事って、 実はかなり稀な現象なのではないかという気がしています。
先日、某大学へ遊びに行く機会があったのですが、 日頃ベンチャーの中ではあまり感じることがなかった 「人種の近さ」のようなシンパシーを 感じてしまいました。 そういえば、私の大学時代の友人には、 大学に残って学究の道を進み、 教授や助教授にまで上り詰めた人が少なくありません。 大学に残らず大企業の研究所などに就職した人もいるのですが、 いつのまにか ;-) 大学に戻っていたりします。
彼らの大半は、私なんぞよりはるかに頭がよく、 その能力をベンチャー発展のために使ってもらえたら、 日本のベンチャーはもっと活気付くのにと、 つい思ってしまうのですが、 彼らの興味がベンチャーに向くことが稀なのだから仕方ありません。
つまり、大学志向の人とベンチャーを興そうという人とでは、 興味の対象が異なるのです。 日本の大学でインターネットの研究が盛んだったのは '80年代の終わりごろです。 インターネット黎明期と呼ばれる頃ですね。 日本を代表するような大企業の研究所では、 当時からインターネットに注目していましたが、 ビジネス的にはまだ海のものとも山のものとも分からず、 ましてこれから起業しようとする人たちが興味を持つような 代物ではありませんでした。
1992年ごろにインターネットの商用利用がはじまりましたが、 インターネットでベンチャーを興してみようと思う人たちが現れたのは、 1994年ころからです。翌年 1995年はインターネット元年と呼ばれていますね。 ところが大学では、 1992年ころまでにインターネットは すっかり日常生活の一部となってしまっていました。 いまさらインターネットで何をするんだ、と思ってしまっていた人も 多かったのではないでしょうか。 今となっては先見の明の無さを恥じるばかりですが、 私自身 1992年ごろには、インターネットにはもはや技術的に新しいことは 何も残ってはいないと思っていました。
ところが、みなさんもご存じの通り、ベンチャーにとってインターネットは '90年代終わりになってからが本番で、 2000年のネットバブル崩壊をものともせず、 数多くのベンチャーが果敢に挑戦を続けています。
学問的に盛り上がってしばらくして下火になる頃から、 それがビジネスの種になりベンチャーが盛り上がる、 こういう順番になるのは当たり前と言えば当たり前すぎるのですが、 こうした時間のずれが、 学問の世界の人たちと ベンチャーの世界の人たちが 出会う機会を減らしているのでしょう。
そんな中、2001年に始まったケータイJAVA は、 学問志向の人とベンチャー志向の人が同時に関心を寄せた、 数少ない例外の一つだったのではないでしょうか。 当時私はベンチャーに対しては何の興味もなかったのですが、 ケータイでユーザプログラムを動かすことができれば、 何か面白そうなことができそうだと思っていました。 一方この年は、iモードの成功が誰の目にも明確になった年で、 ケータイJAVA は iモードの可能性をさらに広げてくれるものとして、 多くのベンチャーが大変な関心を寄せました。
そうして、ベンチャー志向の人と、大学志向の人との出会いが数多く生まれました。 あれから 6年たった今、 こうした出会いを産み出す共通の関心事には何があるでしょうか？
