JP2010093716A - 複数組織共有システム - Google Patents

Abstract

【課題】 複数の会社における情報共有を簡便にかつ情報セキュリティ上安全な環境を提供する。
【解決手段】 独立したネットワーク内の特定機器と別の独立したネットワーク内の特定機器のデータ共用を、共有ネットワークを有するデータセンタ経由で行う構成の複数組織共用システムであって、前記データセンタが、
独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、別の独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、共有ネットワークに接続された共有サーバを備え、それぞれの独立したデータセンタ内ネットワークがそれぞれの所有者の特定機器に対応する対応機器を備え、それぞれの独立したネットワーク内の特定機器とデータセンタ内ネットワーク内の対応機器が通信を行い、それぞれの所有者の対応機器がデータセンタ内の共有サーバと通信することによりデータ共用を行う。
【選択図】 図１

Description

本発明は、仮想ネットワーク定義を利用し、論理的に異なる複数のネットワークを簡便にかつ安全（Ｓｅｃｕｒｅ）に接続する複数組織共有システムに関するものである。

例えば労働環境に目を向けてみる。我々が働く場所はオフィスだけでなく、サテライトオフィス、出張先でのホテル、移動中のカフェ、そして自宅と広がりを見せている。もちろん、それを支えているのはＩＴ技術である。オフィスの外からオフィスの中にＶＰＮ（Virtual Private Network）を構築し、ファイルサーバや業務サーバにアクセスできる仕掛けができて初めて、我々はオフィスの外で満足に仕事ができるようになる。
しかし、これまでの試みはオフィスの中に限定していたイントラネットの空間を、オフィスの外に限定的に拡大したに過ぎない。そのイントラネットの空間には、社員と限られたパートナー社員が入れるに過ぎない。プロジェクトが複数の会社で進行される中、もっと多くのプロジェクト従事者が入るプロジェクト専用のネットワークが望まれている。
プロジェクトが発足すれば、プロジェクト単位にネットワークが誕生し、プロジェクト従事者は随時入ったり出て行ったりでき、最後にプロジェクトの終了と共にそのネットワークは消滅する。そういう柔軟なプロジェクトネットワークが求められている。

また、企業形態に目を向けてみても、自社のコア（得意）事業分野に集中し、それ以外の部分はアウトソースするようなことが当たり前のように行われている。こうした場合においてもＳＣＭ（サプライ・チェーン・マネジメント）システムは複数の企業間をＶＰＮ接続することで実現している。しかし、多くの企業が参加するＳＣＭの場合ネットワーク構成は複雑になる一方である。このような複雑性を排除し、簡易でかつセキュリティ上安全なネットワークシステムが必要とされている。
上記技術に関連する先行技術としては特許文献１、特許文献２のようなものがある。

特許第４１００１４５号公報 特許公開２００４−１６５７６１号公報

先の労働環境を例において、２つの会社の社員３人がお互いのパソコンにアクセスし、共同でプロジェクトを遂行することを想定した場合、これを従来のネットワーク技術でどう構築するのか考察する。
プロジェクトに参画するメンバーは、Ａ社のＰグループのｐ君、Ｑグループのｑ君、Ｂ社のＲグループのｒ君とする。ＰグループとＱグループはＡ社のイントラではネットワーク接続されているが、図５に示すように、ネットワークセグメントは違っているものとする。
この３人がお互いのパソコンにアクセスするためにはどうすればいいだろうか。それにはまず、Ａ社とＢ社をＶＰＮで繋ぐ必要がある。ここでは価格を安くするために、インターネットＶＰＮ装置を使い、Ａ社とＢ社を直接繋ぐことにする。しかし、ここで問題が生じる。Ａ社とＢ社を単にインターネットＶＰＮで繋いでしまうと、この３人以外の人もすべて繋がってしまうことになる。そこで、Ａ社とＢ社にそれぞれ、ファイアーウォール（Ｆ／Ｗ）を設置する必要が出てくる

ここで、それぞれのルータに相手先のアドレスを登録することになるが、そこで２番目の問題が発生する。社内のネットワークアドレスをグローバルアドレスで割り当てているところはまずない。だとすると、Ａ社のネットワークアドレスとＢ社のネットワークアドレスが重なる可能性がある。例えば、どちらの会社もクラスＢのプライベートアドレス１９２．１６８．０．０／１６を使っている場合である。図５では、ｐ君が属するネットワークアドレスとｒ君が属するネットワークアドレスは、どちらも「192.168.10.0/24」で同じである。
１つの解決法は、重ならないように調整するという手はある。ある巨大グループでは、グループ全体でクラスＡのプライベートアドレス「10.0.0.0/8」を使っている。しかし、同じグループ企業であれば各社にどのアドレスを割り当てるかを調整することは可能かもしれないが、グループの異なる企業があるプロジェクトに参画するためだけに、一度、社内に割り当てたアドレスを変更するということはあり得ない。

これを解決するために、図６に示すように、各社を繋ぐ真ん中のハブにデータセンタを置いて、すべての接続はそのデータセンタを経由して繋げるやり方を思いつく。
データセンタ内にはプロジェクトに参画するエンジニアのパソコンを用意しておく。それは、通常のパソコンでも良いし、ブレードＰＣでもいいし、仮想化ソフトで提供されるＶＭ（Virtual Machine）でも構わない。図６では、Ａ社のｐ君のＶＭとＢ社のｒ君のＶＭを用意している。
Ａ社とＢ社は、それぞれのネットワークポリシーに従い、データセンタとＶＰＮで接続する。先ほどとは違い、Ａ社のＶＰＮやＦ／Ｗの設定で、Ｂ社のネットワークから影響を受けることはない。逆に、Ｂ社側も同じくＡ社側の設定で影響を受けることはない。
図６では、ｐ君、ｒ君がそれぞれ独立に、データセンタ内の自分のＶＭにアクセスすることができる。プロジェクトは、このデータセンタ内のＶＭ同士でデータのやり取りを行うことができる。そして、お互いのＦ／Ｗの設定で、データセンタのＶＭからそれぞれの会社のパソコンへの進入を防ぐことができる。

しかし、この場合もデータセンタで使われるネットワークアドレスを、各社のルータに登録して、ｐ君とｒ君のパソコンからデータセンタのＶＭにアクセスできるようにルーティングを行う必要がある。このため、社外のネットワークアドレス、図２ではデータセンタ内のＡ社とＢ社の共有ネットのアドレス「192.168.30.0/24」を、Ａ社、Ｂ社それぞれの社内のルータに登録するという状況になる。これは、Ｆ／Ｗの設定を間違えると、いつ何時、例えば、Ｂ社のｒ君がデータセンタから誤ってＡ社のネットワークにアクセスしてしまう可能性が生じる。また、ｐ君やｒ君がＷｉｎｄｏｗｓ（Ｍｉｃｒｏｓｏｆｔ社の商標）のリモートデスクトップ接続でＶＭに入っている場合、手元のパソコンとＶＭとでフォルダを共有することも出来るため、ｒ君のパソコンが仮にウィルスに感染した時、共有ネットのｒ君のＶＭとｐ君のＶＭが感染し、さらに、ｐ君のＶＭからｐ君の社内のパソコンが感染し、その結果、Ａ社の社内ネットがウィルスに感染してしまう危険がある。
このことから言えることは、Ａ社とＢ社は直接的にせよ、間接的にせよ、レイア３でＶＰＮを構築してはいけないということである。Ａ社とＢ社の社内ネットがレイア３でＩＰ（Internet Protocol）的に繋がっている以上、技術的にはＦ／Ｗでアクセス制御をかけられるとしても、運用上のミスからお互いの社内ネットが相手の脅威にさらされているという状況は変わらないのである。

本発明の目的は、上記のような複数の会社（組織あるいは団体）における情報共有を簡便にかつ情報セキュリティ上安全な環境を提供できる複数組織共有システムを実現することにある。

上記課題を解決するために、本発明の複数組織用システムは、独立したネットワーク内の特定機器と別の独立したネットワーク内の特定機器のデータ共用を、前記独立したネットワークの所有者と前記別の独立したネットワークの所有者が共有する共有ネットワークを有するデータセンタ経由で行う構成の複数組織共用システムであって、
前記データセンタが、
前記独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、
前記別の独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、
前記共有ネットワークに接続されたを共有サーバをさらに備え、
前記それぞれの所有者の独立したデータセンタ内ネットワークがそれぞれの所有者の前記特定機器に対応する対応機器を備え、
それぞれの所有者の所有する前独立したネットワーク内の前記特定機器と前記独立したデータセンタ内ネットワーク内の対応機器が通信を行い、
それぞれの所有者の所有する前記対応機器がデータセンタ内の前記共有ネットワークに接続された共有サーバと通信することによりデータ共用を行うことを特徴とする。
また、前記独立したネットワークと前記独立したデータセンタ内ネットワークがレイヤ２バーチャルプライベートネットワークで接続されていることを特徴とする。
また、前記独立したデータセンタ内ネットワークが仮想ネットワークで構成されていることを特徴とする。
また、前記対応機器は仮想機械であることを特徴とする。

本発明によれば、物理接続では非常に困難であった２組織間の接続が容易に、しかもセキュリティ上も安全に実現することができる。

以下、本発明を図示する実施の形態に基づいて詳細に説明する。
図１は、本発明の実施の形態を示すシステム構成図である。
この実施形態のシステムは、ＶＬＡＮ（Virtual Local Area Network）番号を付けたタグ付きフレームによって複数の組織で論理的に異なる複数のネットワークを構築した例を示すものである。
最近ではイーサネットフレーム（転送するデータパケット）にＶＬＡＮ（Virtual Local Area Network）番号を付けたタグ付きフレームを扱えるＬ２（Layer2）スイッチの品揃えが増えてきた。これは、同じ物理ネットワークを使っていても、ＶＬＡＮ番号を分けることにより、論理的に異なる複数のネットワークを構築できる。
例えば、Ｌ２スイッチの４つのポートに、それぞれＡ、Ｂ、Ｃ、Ｄの４つのパソコンを繋いだとする。ＡとＢのパソコンが繋がっているポートにはＶＬＡＮ１００を、ＣとＤのパソコンが繋がっているポートにはＶＬＡＮ２００を設定する。通常、Ｌ２スイッチでは繋がった４つのパソコンはお互いにパケットを転送し合うことができる。しかし、ＶＬＡＮ番号を分けることにより、ＶＬＡＮ１００のパソコンＡとＢ同士か、ＶＬＡＮ２００のパソコンＣとＤ同士しかパケットを転送しあうことができない。

図１の例では、このＶＬＡＮの技術を使って、データセンタ１の内部に３つの独立したネットワーク１１、１２，１３を構築している。それは、ＶＬＡＮ１００のＡ社の仮想ネット１１とＶＬＡＮ２００のＡ社とＢ社の共有ネット１２、さらにＶＬＡＮ３００のＢ社の仮想ネット１３である。これら３つのネットワーク１１〜１３は、ＶＬＡＮ番号が違うため、お互いにパケットを直接転送し合うことができないという意味で、独立したレイア２のネットワークになっている。

次に、Ａ社のネット２とデータセンタ１の繋ぎ方を見てみよう。データセンタ１内のＡ社の仮想ネット１１は、Ｌ２−ＶＰＮと表示されたＶＰＮ装置を使って、Ａ社のネット２のＦ／Ｗと同じセグメントにレイア２で繋がる。このため、Ａ社の仮想ネット１１は、Ａ社の社内ネット２の一部になる。この結果、Ａ社の仮想ネット１１のネットワークアドレスは、Ａ社の社内に割り当てられるネットワークアドレスでなければならず、図１の場合は「192.168.20.0/24」を割り当てている。
ここで注意すべきことは、データセンタ１内のＡ社の仮想ネット１１をレイア２でＡ社のネット２に繋げたので、Ａ社の社内ネットワークアドレスである「192.168.20.0/24」を割り当てたのであって、Ａ社の仮想ネット１１に「192.168.20.0/24」を先に割り当ててレイア３で接続したのではないということである。別な言い方をすると、Ｌ２−ＶＰＮ装置を使ってレイア２で接続したのであって、レイア３のＶＰＮ装置を使ったのでないということである。

レイア２とレイア３の接続の違いは、ブロードキャストのパケットの転送に違いが出る。図１のレイア２での接続の場合、Ａ社のネット２のＦ／Ｗのセグメントに流れ込むブロードキャストのパケットはすべて、Ｌ２−ＶＰＮ装置を経由してＡ社の仮想ネット１１に流れ込むことになる。このため、Ａ社の仮想ネット１１のｐ君のＶＭは、社内のｐ君のパソコンと同じく、社内のファイルサーバ、プリンタサーバ、ディレクトリ等のすべてのネットワークサービスにアクセスできる。ただし、Ｌ２−ＶＰＮ装置間は社内ＬＡＮより遅い回線であるので、Ａ社のネット２からデータセンタ１のＡ社の仮想ネット１１に不要なパケットを転送しないように、通常はＬ２−ＶＰＮでパケットのフィルタリング設定をする。
図１では、データセンタとＢ社もレイア２で接続している。データセンタ１内のＢ社の仮想ネット１３は、Ｂ社の社内ネット３のアドレスを割り当てる。この時、Ａ社の仮想ネット１１とＢ社の仮想ネット１３のネットワークアドレスは同じでも構わない。
データセンタ内では、Ａ社の仮想ネット１１はＶＬＡＮ１００に、Ｂ社の仮想ネット１３はＶＬＡＮ３００に割り当てているため、レイア２で独立したネットワークになっているからである。レイア２で分離されていれば、その上のレイア３で同じネットワークアドレスを使っても混信しない。

Ａ社のｐ君とＢ社のｒ君がファイルを共有するためには、データセンタ内１のＡ社とＢ社の共有ネット１２を使う。この共有ネット１２のネットワークアドレスは、Ａ社の仮想ネット１１でもＢ社の仮想ネット１３でもない独立したネットワークアドレスを割り当てる。ｐ君とｒ君はそのネットワークへのルーティングをＦ／Ｗに振り向けることで、共有ネット１２上の共有サーバ１４にアクセスすることができる。

ここで特筆すべきことは、Ａ社とＢ社が同じネットワークアドレスを使っていても、この仕掛けは機能するところである。Ａ社の仮想ネット１１とＢ社の仮想ネット１３はＶＬＡＮで分離されているからである。また、仮想ネット上のｐ君とｒ君は、共有サーバ１４にアクセスするために共有サーバ１４へのルーティングを静的にＦ／Ｗに振っている。このため、仮にＡ社またはＢ社の社内ネットで共有ネット１２と同じネットワークアドレスが使われていても、仮想ネット１１，１３上のｐ君とｒ君は影響を受けない。このように、レイア２での接続は、レイア３での接続と違って、お互いのネットワークアドレスに影響されないのが特徴である。

このこの構成の活用例としては次のようなものが考えられる。
Ａ社をシステム開発の発注元、Ｂ社を発注先とする。これまでは、お互いにドキュメントをやり取りする時には、まずドキュメントを暗号化し、それをメールに添付し、相手に送付するというやり方が行われている。しかし、この方法では、ドキュメントは読まれないにしても、メールの補完機能を誤って、間違ったアドレスに送付するリスクが付きまとう。さらに、共同開発ではやりとりされるドキュメントの数が非常に多く、ドキュメントの更新のたびに１つ１つメールで送付していては、どれが最新版なのか分からなくなる。
図１のようなネットワークを導入すると、共有サーバ１４で安全にドキュメントの共有ができることに加え、ドキュメントの版管理としても非常に役立つことが理解できる。

次に、自宅ＰＣをデータセンタ１のＶＭに繋げる例を図２に示す。
これまでの接続形態は、会社とデータセンタの間のＬＡＮ間接続であった。Ｆ／Ｗでの制限はあるにしても、社内の複数のパソコンからデータセンタの複数のＶＭにアクセスできた。

図２は、自宅ＰＣ４からデータセンタ１のｐ君のＶＭ１６にアクセスする経路を示している。例えば、自宅ＰＣ４でブラウザを立ち上げ、HTTPプロトコルでデータセンタ１のゲートウェイ１５にアクセスする。そして、ＰＩＮ番号とパスワードを入れて、ゲートウェイ１５の認証を済ませ、Ｆ／Ｗを経由してｐ君のＶＭにアクセスする。仮に、ｐ君のＶＭ１６がＷｉｎｄｏｗｓ（登録商標）ＸＰだとするとターミナルサービスが使える。ｐ君は自宅ＰＣ４でリモートデスクトップ接続というプログラムを起動し、ＲＤＰプロトコルによってＶＭ１６で動いているＷｉｎｄｏｗｓＸＰを操作することができる。さらに、ｐ君のＶＭ１６はＡ社の社内ネット２とはレイア２で接続しているので、そのＶＭ１６を踏み台にさらにＡ社の社内ネット２にある業務サーバにアクセスできる。これにより、ｐ君は会社にいるかのように、自宅で仕事をすることが可能となる。
しかし、自宅ＰＣ４から社内ネット２にあまりに簡単にアクセスできるのは問題である。このために、セキュリティを強化する必要がある。まず、自宅ＰＣ４からゲートウェイ１５へのアクセス制御をもう少し強化したい。例えば、自宅ＰＣ４でブラウザだけでゲートウェイ１５にアクセスするのではなく、ＰＩＮ番号を格納した特殊なＵＳＢキーと組み合わせて認証をかけるようにする。また。ワンタイムパスワードの機能をゲートウェイ１５に組み込む。
一方、Ｆ／Ｗでは、自宅ＰＣ４からＶＭ１６にアクセスするプロトコルを制限することができる。Ｗｉｎｄｏｗｓの画面のイメージだけを自宅ＰＣ４に転送するＲＤＰプロトコルは許可するが、ＦＴＰプロトコルは許可しないといった制限を設定することができる。
この構成の活用例としては次のようなものが考えられる。

最近のパソコンでは、ハードディスクからＷｉｎｄｏｗｓを起動する前に、もしＬｉｎｕｘ（登録商標）の入ったＵＳＢキーがあればまずＬｉｎｕｘから起動するように、ブートの順番を変更することができる。この機能を使うと、自宅ＰＣ４のハードディスクを使わず、シンクライアント化してゲートウェイ１５にアクセスできる。さらに、ＬｉｎｕｘにはrdesktopというＲＤＰプロトコルを実装したプログラムがあるので、仮想ネットのＷｉｎｄｏｗｓＸＰにアクセスすることもできる。この場合、自宅ＰＣ４のハードディスクは一切使っていないため、ＷｉｎｄｏｗｓＸＰから自宅ＰＣ４にファイルをダウンロードすることができない。なにより、特別なシンクライアントＰＣを導入することなく、自宅ＰＣ４を使ってＶＭ経由で会社の業務サーバにアクセスできる点が有益である。
こうしたことにより、これまで特殊な機器の導入で実現が困難だった在宅勤務の適用を拡げる起爆剤になる可能性がある。

次に、データセンタ１内に仮想オフィス１９を構築する例を図３に示す。
仮想オフィスに入居する人は、Ａ社のａ君、ｂ君、ｃ君、Ｂ社のｄ君、ｅ君、ｆ君、それに在宅勤務のｐ君とｑ君の８人とする。
Ａ社とＢ社は、図１で説明したように、データセンタ１へはレイア２でＶＰＮ接続する。データセンタ１のＡ社の仮想ネット１１にはａＶＭ、ｂＶＭ、ｃＶＭというａ君、ｂ君、ｃ君用のＶＭを用意する。Ｂ社の仮想ネット１３にも、それぞれ３人分のＶＭを用意する。
また、ｐ君とｑ君には、図２で説明したように、外部接続用のゲートウェイ１７を経由してアクセスできるｐ君のｐＶＭとｑ君のｑＶＭを用意する。

次に、全員がアクセスできる共有サーバ１８を用意する。この共有サーバ１８には３つのネットワークインターフェースがあり、それぞれＡ社の仮想ネット１１にアクセスするためのＦ／Ｗが属しているＶＬＡＮ、Ｂ社の仮想ネット１３にアクセスするためのＦ／Ｗが属しているＶＬＡＮ、ｐ君とｑ君のＶＭと同じＶＬＡＮに接続されている。
Ａ社とＢ社の仮想ネット１１，１３に繋がっているＦ／Ｗでは、ａＶＭ、ｂＶＭ、ｃＶＭ、ｄＶＭ、ｅＶＭ、ｆＶＭのそれぞれから共有サーバ１８にのみ一方向でアクセスできる設定がなされている。共有サーバ１８から各ＶＭにはアクセスできないようになっている。

一方、ｐＶＭ、ｑＶＭと共有サーバ１８とはお互いにアクセスできるようにしている。これは、ｐＶＭやｑＶＭから自宅ＰＣ４にアクセスできないようにＦ／Ｗを設定しているからである。
以上の設定により、８人全員の仮想オフィス１９をデータセンタ１内に構築することができる。図３では共有サーバ１８は１台となっているが、もちろんこのネットワークセグメントにはサーバを何台でも置くことができる。

ところで、Ａ社とＢ社の仮想ネット１１，１３はそれぞれのオフィスとレイア２で接続されているので、仮想ネットのＶＭからドキュメントを社内ネットに接続されたプリンタに印刷することができる。また、仮想ネットのＶＭ上でブラウザを起動し、社内ネット経由でインターネットに出て、外のＷｅｂページを表示することもできる。さらに、社内ネットのメールサーバにアクセスしてメールを読むことも送ることもできる。
このように、レイア２接続では、仮想ネットのＶＭからは、社内ネットのパソコンと同じく、社内のネットワークサービスをすべて利用できる。
しかし、ｐ君とｑ君は自宅ＰＣ４をシンクライアント化してＶＭにアクセスしているので、通常のネットワークサービスを利用することは出来ない。ｐＶＭやｑＶＭの仮想ネットからは、プリンタサーバやメールサーバ、さらにインターネットへはアクセス経路はない。もちろん、ｐＶＭやｑＶＭの仮想ネットに、プリンタサーバやメールサーバの属するＶＬＡＮを接続すれば利用できるようになる。そうした制御ができる、違った見方をすればデータセンタ１内でプロジェクト専用の閉じたネットワークが自由に構成できるというのが、レイア２接続の一番の魅力である。

ｐ君とｑ君が彼らの自宅ではなく、彼らの会社と考えると面白い活用事例が想定される。海外の発注先で１０名の現地エンジニアにプロジェクトに参加してもらっているとしよう。彼ら１０名に１０本のＵＳＢキーを渡して、彼らの海外のオフィスのＰＣにそのＵＳＢキーを挿してもらえれば、彼らは海外にいながらにして日本のデータセンタの各人のＶＭにアクセスすることができる。図３のＡ社は発注元、Ｂ社は国内発注先とすれば、国内ではそれぞれのオフィスにドキュメントをダウンロードして開発してもらう。海外からは、ドキュメントのダウンロードはできず、データセンタ内で開発をしてもらう。こういう国内分散開発と海外オフショア開発をデータセンタ内のプロジェクトオフィスで進めることができる。特に、海外へは画面イメージの転送だけで開発が進められるため、ドキュメントの輸出管理作業を軽減できる。ただし、海外のエンジニアが国内で生成された画面のイメージを見るだけでも輸出行為であるので、輸出管理業務そのものがなくなるわけではない。

これまでの構成で、Ａ社とＢ社、さらに在宅勤務の人をネット上の仮想オフィスに住居させることができた。しかも、海外からも仮想オフィスに住むことができた。
しかし、ここで１つの大きな問題が生じる。それは、Ａ社やＢ社の社内ネットをデータセンタ１に繋ぐと、Ａ社やＢ社のすべての社員は、データセンタ１のＶＭとネットワーク的に繋がってしまうということである。すなわち、社員のパソコンからデータセンタ１のＶＭにｐｉｎｇを送信すると、確実に応答が返ってくるということである。もちろん、自分のＶＭをデータセンタ１に持っていないので入ることはできない。しかし、ＶＭを持っている人からその人のＶＭのＩＤとパスワードを教えてもらうと入れてしまう。

ところで、これからの社内ネットはＶＬＡＮで構築されるようになるだろうと予測している。現在、自席のＰＣはツイストペアケーブルでフロアのＬ２スイッチにつながっている。そこで、Ｌ２スイッチがポートＶＬＡＮをサポートしていれば、ＰＣが繋がっているポートごとにＶＬＡＮ番号を割り振ることができる。つまり、社員をＶＬＡＮ番号でグルーピングできることになる。

例えば、図４に例示するように、ａ君とｂ君とｃ君はＡというプロジェクトに参画し、ＶＬＡＮ１００番のネットワークに入る。このＶＬＡＮ１００番のネットワークは、先ほどのレイア２でデータセンタのＡプロジェクト用の仮想ネットに接続される。もちろん、Ａプロジェクトに参画する他の会社も社内でＶＬＡＮを構築して、同じようにＡプロジェクト用の仮想ネットに入ってくる。在宅勤務者も外部接続用のゲートウェイを経由して、Ａプロジェクト用の仮想ネットに入ってくる。ここで初めて、Ａ社やＢ社という組織を超えて、プロジェクト独自のネットワークを構築することができる。

一方、ｄ君とｅ君とｆ君はＢというプロジェクトに参画し、ＶＬＡＮ２００番のネットワークに入る。このＶＬＡＮ２００番のネットワークも、先ほどのレイア２でデータセンタのＢプロジェクト用の仮想ネットに接続される。もちろん、Ｂプロジェクトに参画する他の会社の社員や在宅勤務者も、同じようにＢプロジェクト用の仮想ネットに入ってくる。
このように社内ネットにＶＬＡＮを導入すると、社員はプロジェクトのネットワークと、全社統一基盤で業務サーバにアクセスするための社内ネットという２つのネットワークを使うようになる。
Ａプロジェクトのネットワークに入っている社員は、会社のネットワークサービスは社内ネットでアクセスし、Ａプロジェクトの仕事をするときはＡプロジェクトのネットワークを利用することになる。その場合、Ｂプロジェクトのネットワークに入ることはできない。プロジェクトのネットワークは、プロジェクトごとに完全に分離されているからである。また、プロジェクトの従事者は図３のゲートウェイを経由し、自宅から自分のプロジェクトネットワークに入ることができる。
このように、レイア２でデータセンター内に仮想オフィスを構築するによって、会社に居ようが、自宅に居ようが、プロジェクトネットワークに入ることでどこでも仕事ができるようになる。

２社のネットワークをデータセンタ内で論理的に接続し、かつデータ共有を行う場合の実施形態を示すシステム構成図である。 自宅のコンピュータをデータセンタのＶＭに接続する実施形態を示すシステム構成図である。 データセンタ内に仮想オフィスを導入する実施形態を示すシステム構成図である。 社内ネットワークにＶＬＡＮを導入しグルーピングする実施形態を示すシステム構成図である。 ２社間のユーザが直接データをやり取りするためのネットワーク構成図の従来構成図である。 ２社のネットワークを一般的な方法でデータセンタに接続し、２社のユーザで情報共有を行う場合の従来のネットワーク構成図である。

符号の説明

１ データセンタ
２ Ａ社のネット
３ Ｂ社のネット
４ 自宅ＰＣ
１１ Ａ社の仮想ネット
１２ Ａ社とＢ社の共有ネット
１３ Ｂ社の仮想ネット
１４ 共有サーバ
１５ ゲートウェイ
１６ ＶＭ
１７ ゲートウェイ
１８ 共有サーバ
１９ 仮想オフィス

Claims (4)

1. 独立したネットワーク内の特定機器と別の独立したネットワーク内の特定機器のデータ共用を、前記独立したネットワークの所有者と前記別の独立したネットワークの所有者が共有する共有ネットワークを有するデータセンタ経由で行う構成の複数組織共用システムであって、
   前記データセンタが、
   前記独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、
   前記別の独立したネットワークの所有者用の独立したデータセンタ内ネットワークと、
   前記共有ネットワークに接続された共有サーバをさらに備え、
   前記それぞれの所有者の独立したデータセンタ内ネットワークがそれぞれの所有者の前記特定機器に対応する対応機器を備え、
   それぞれの所有者の所有する前独立したネットワーク内の前記特定機器と前記独立したデータセンタ内ネットワーク内の対応機器が通信を行い、
   それぞれの所有者の所有する前記対応機器がデータセンタ内の前記共有ネットワークに接続された共有サーバと通信することによりデータ共用を行うことを特徴とする複数組織共用システム。
2. 前記独立したネットワークと前記独立したデータセンタ内ネットワークがレイヤ２バーチャルプライベートネットワークで接続されていることを特徴とする請求項１に記載の複数組織共有システム。
3. 前記独立したデータセンタ内ネットワークが仮想ネットワークで構成されていることを特徴とする請求項１または２に記載の複数組織共有システム。
4. 前記対応機器は仮想機械であることを特徴とする請求項１〜３のいずれか一項に記載の複数組織共有システム。

Images