White Paper

QuiX 端末認証によるセキュリティ対策

Ver 1.６

pg. 1

Table of contents
1.

情報セキュリティ対策の現状 .................................................................................................. 3

2.

企業情報システムにおけるセキュリティ課題 ......................................................................... 53.

課題解決に向けた従来手法のおさらい .................................................................................... 74.

QuiX 端末認証の概要 .............................................................................................................. 94.1

特徴......................................................................................................................................... 94.2

技術面のポイント.................................................................................................................... 94.3

既存の他の方式との比較 ....................................................................................................... 104.4

認証方式の違いによるラインナップ ..................................................................................... 114.4.1

Basic 版 ................................................................................................................................ 124.4.2

RADIUS 連携オプション ...................................................................................................... 144.4.3

SAML 連携オプション .......................................................................................................... 164.4.4

クライアントの種類 .............................................................................................................. 175.

各種パッケージの内容........................................................................................................... 185.1

動作環境................................................................................................................................ 196.

適用事例................................................................................................................................ 206.1

ケーススタディ１：全国 500 か所の教室から利用する業務システム.................................... 206.2

ケーススタディ２：社外勤務者のリモートアクセス ............................................................. 21

6.3

ケーススタディ３：スマートフォンセキュリティ ................................................................ 22

7.

Quix 端末の応用＆カスタマイズ事例 .................................................................................... 23

7.1

ソリューション事例１：IceWall(注)との連携 ......................................................................... 23

7.2

ソリューション事例２：端末認証とアプリケーションユーザカウントの紐づけ ................... 24

7.3

応用事例：アプリケーションとの連携例 .............................................................................. 25

8.

結論....................................................................................................................................... 26

9.

評価、試用について .............................................................................................................. 2610.

本件に関するお問い合わせ先 ................................................................................................ 26

pg. 2

1. 情報セキュリティ対策の現状
近年、情報漏えいのニュースがしばしば世間を騒がせています。お隣の韓国では 2011 年 3 月、1台のノートパソコンに仕組まれた悪意あるプログラムにより、農協のサーバ全体の半数に相当する 275台のデータが削除され、サービスが完全停止するというトラブルがありました。このケースでは、パスワードが簡単なものだったたり、最長 6 年以上も変更されていなかったことから、セキュリティ対策の甘さが厳しく非難されました。
さらに直近の海外では、ソニー、ＦＢＩ（米国連邦捜査局）、ＲＳＡセキュリティ社までもがハッキングされました。日本国内でも同様の事件の発生が予想されています。
こうしたことから昨今では、様々なセキュリティ製品が開発されていますが、今でも対策の主流は、ＩＤとパスワードです。
ＩＤ・パスワードによるセキュリティシステムは本来、必要十分な強度を有しているはずです。ところが実際の運用シーンでは、しばしば以下のような課題に直面します。
・一度設定したパスワードをずっと使い続けて変更しない
・簡単すぎるパスワードが容易に解析されてしまう・パスワードを他人に教えてしまったり、肩越しに盗み見られてしまう
これらはセキュリティシステムの機構・機能的な限界というよりも、使う人の問題です。つまり運用上の課題が原因となって、結果的にセキュリティを保てなくなってしまうケースが後を絶たないのです。
この運用上の課題を克服するために、これまでも様々な方法が提案されてきました。セキュリティの強度と実績という面では、ワンタイムパスワードの導入が決め手として有望視されています。アクセスの都度、1 回限りの使い捨てパスワードを発行する仕組みです。但し、コスト的にも手間の面でもユーザに負担を強いるため、汎用的な方法とは言い難く、金融機関ですら一部にしか導入されていないのが現状です。
加えて 2011 年 6 月、世界的に有名なセキュリティ会社が、外部から不正侵入されるという事態が発生しました。しかもこのケースでは、ワンタイムパスワードの技術そのものが盗難にあい、さらに、その不正侵入の成果（？）を用いて米国の航空・軍事会社がハッキングされるという事態にまで発展しました。最終的にそのセキュリティ会社は、端末 4,000 万台の交換を発表するという事態に至りました。
こうした状況を考えると、ワンタイムパスワードですら安全とは言えなくなりつつあるのです。
別の問題もあります。パスワードベースのシステムは、その特性から、アクセス元の端末を特定することができません。会社のデータに自宅のＰＣからアクセスした結果、子供がインストールしたファイル共有ソフトを通して業務データが流出するといった例も枚挙にいとまがありません。こうした事故はパスワードだけでは防ぐことができません。
危ないのは自宅のＰＣだけではありません。ここ１年足らずの間に、iPhone/Android/iPad といっ

pg. 3

たスマートフォンやタブレット端末が急速に普及しています。
これら携帯端末の高機能化に歩調を合わせる形で、社外からのアクセスも増加しています。パスワー
ドさえあれば、出張先や電車の中、喫茶店など、どこからでも社内情報へアクセスできてしまう訳です。
電車の中で入力中のパスワードを盗み見られるかもしれません。今後、情報セキュリティに絡む問題の発生件数が増えていくことは、ある意味で必然といえます。

このホワイトペーパーでは、これらの課題の包括的な解決策として、ＩＤ・パスワードによる防御に加えて、より積極的に「アクセス元の端末を特定する」という考え方を提唱するとともに、そのコンセプトに基づく端末セキュリティ対策をご紹介します。

pg. 4

2. 企業情報システムにおけるセキュリティ課題
情報セキュリティ問題は国を越えて、全世界的な問題になりつつあります。現在インテルが産学共同でセキュリティの技術開発を加速させていることもひとつの象徴でしょう。
将来的には、デバイスや OS といったレベルで十分なセキュリティが確保される可能性はあります
が、残念ながら現状では、直ちにその成果を期待できる状況にはありません。とはいえ、私たちの社会生活全体を覆う IT 化の波を押し止めることはできません。情報システムは今日の企業活動に不可欠なインフラとなっています。特にネットブック、スマートフォン、タブレットPC 等が登場したことで、従来の閉じた社内ネットワークにおける利用から、クラウドサービスの利用へというシフトが起こっています。情報システムはインターネット経由で使えることが当然かつ必然とみなされる時代となってきました。
こうした変化が起こる一方で、既存のシステムでは、従来からの一般的な手法である ID とパスワードによる認証が大半を占めているのが現状です。ID とパスワードだけでは不十分であることは、システム管理担当者の大半が漠然と認識しているでしょう。しかし、問題改善に要するコストが高額な事や、利用者の利便性低下などのマイナス面を考慮し、結局は現状維持で様子見というケースが多いようです。

企業におけるセキュリティ対策の現状※出典：社団法人 日本コンピュータシステム販売店協会「中堅・中小企業の IT サービスメニューに関する調査研究」平成 21 年 3 月

企業情報システムは今後、どのように運用されるべきでしょうか？ 自社ネットワークの鎖国状態を続けるのも、一つの手ではあります。また、全面刷新も一つの手ではあります。とはいえ、必ずしもそういった対応が可能だとはいえません。
既存システムのセキュリティ問題を解決して、インターネットに対応可能な形にするためには、大きく分けて下記のような対策作業が必要となってきます。

pg. 5

・パスワードの運営管理体制の見直し
・パスワードの複雑化、多要素認証の導入など。
・システム全体のセキュリティ的な不具合がないかどうかの見直し
SQL インジェクション等のハッキング手段に対抗するようにシステムを修正する。
場合によっては、客観的な第三者機関によるセキュリティテストなどの実施により、外部から擬似的にハッキングを試みる貫通（ペネトレーション）テストなども必要。
こうした対策を実施した場合、数百万円の費用に加え、かなりの手間を要するケースがほとんどです。
また費用対効果の点で、経営層を納得させる提案に落とし込むことは、なかなか難しいようです。
こうした問題を解決する方法として、このあと QuiX 端末認証を紹介していきます。

pg. 6

3. 課題解決に向けた従来手法のおさらい
世の中にはセキュリティ課題を解決するための商品が多数あります。QuiX 端末認証の説明に入る前に、従来どういった手法がとられてきたかをおさらいしてみましょう。
・MAC アドレス認証
端末に固有の MAC アドレスを利用して、ユーザの端末を一意に特定する方法です。端末を特定するという点では手軽ですが、次のような問題があります。
・利用開始にあたり、事前に MAC アドレスを調べて収集する必要がある。
・利用中にネットワーク環境が変更された場合のメンテナンスにコストがかかる。
・一部の機器では、MAC アドレスを任意に設定できるので、なりすましのリスクがある。
・PKI（Public Key Infrastructure, 公開鍵基盤）証明書
端末に認証局から電子証明書を配布し、それを保持しているかどうかで端末を特定する手法です。セキュリティ強度が非常に強い反面、欠点も多く併せ持っています。
・一般的に導入コストが高い。
・認証局の利用や証明書の更新のために、継続的に費用が発生する。
・利用開始時には、証明書の配布や設定などの手間がかかる。
・証明書をきちんと管理せずに盗まれると、なりすましに悪用される可能性がある。
・生体認証
利用者自身が持つ情報、例えば指紋や静脈のパターンを利用して端末を特定する方式です。最近は銀行などでも導入されており、本人に紐づいた認証強化という点ではきわめて優れた手法といえます。欠点は次のとおりです。
・高額である。
・読み取り装置が必要。スマートフォンなどには導入不可。
・読み取り装置の配布やインストールが必要。
・ワンタイムパスワード
ここ数年のトレンドとしては、もっともポピュラーな手法です。セキュリティ強度も一般的には優れていると信じられています。この方式には下記の欠点があります。
・ユーザに鍵を配布するコストが必要
・専用の認証サーバが必要
・ユーザは鍵管理のほかに、利用するたびに覚えにくいパスワードを入力しなければならない。

pg. 7

これらの従来からある手法は、確かに問題を解決してくれますが、コストや運用の手間からくる制約のため、広く普及しているとは言い難いまま現在にいたっています。
最近ではセキュリティの事故の増加に伴い、仕方なく、あるいは希望者のみに限定的に導入されるケースが増えてはきましたが、導入の敷居はまだまだ高いといえるでしょう。こうした現状を踏まえ、次章では QuiX 端末認証を用いた問題解決の手法を紹介します。

pg. 8

4. QuiX 端末認証の概要
今回のホワイトペーパーの主題である QuiX 端末認証を用いたソリューションについて、以下に説明します。

4.1

特徴

・従来のパスワード認証に追加する形で、二要素認証を実現することができます。
・ソフトウェアで端末認証を行うため、ワンタイムパスワードトークンなどの外部デバイス等を配布する必要がありません。
・認証に使用する鍵（トークン）はサーバで自動生成し、端末に配布します。
PKI 認証などで必要になる「鍵の配布」や「証明書の更新」が不要です。
・認証サーバがゲートウェイ（リバースプロキシ）として動作するため、認証を通らない端末からのアクセスを制限します。
これにより、不特定多数の悪意ある存在が、SQL インジェクション等の方法で直接アプリケーションサーバを攻撃することを防止できます。既存のシステムやアプリケーションに手をいれることなく、インターネット環境から安全に利用できるようにします。
・低価格、かつ簡単に導入可能。
・維持管理が容易
一時的な利用停止や利用再開、端末変更時の再設定などは、すべて管理者用 Web 画面から行うことができるので、運用コストが最低限で済みます。

4.2

技術面のポイント・暗号化方式には、公開鍵ではなく秘密分散法を用い、端末固有情報を生成しています。
暗号アルゴリズムは非公開なので、セキュリティ強度の面にも優れています。
・生成した端末情報は２分割されたのち、クライアントとサーバで保持します。双方の組み合わせが合致した場合にのみ、端末情報が正しく復元されるようにすることで端末を特定します。
・鍵は毎回異なったものが生成されるため、盗まれても悪用されることはありません。
・ユーザの手を煩わせるのは、利用開始時の初回認証のみです。
2 回目以降は自動で認証手続きが行われるため、ユーザは意識する必要がありません。
・クライアント側の端末の入れ替えや、紛失等に伴う更新の際等には、管理者用 Web 画面から、対象となる端末をリセットするだけで済むため、極めて簡単に運用可能です。

pg. 9

4.3

既存の他の方式との比較

先に述べた他の認証方式と Quix 端末認証を比較すると、下記のようになります。
各認証方式の比較
MAC アドレ

PKI

生体ワンタイム

QuiX

スによる認証

証明書

認証

パスワード

端末認証

WAN 対応

×○

○

○

○

PC 環境に非依存

×○

×

○

○

○

○

××

○

○

○

×

○

△

本人性の認証である

××

○

×

×

PC を特定する

○×××

○

導入コスト

標準的

高い

高い

高い

安価

運用負荷高い

高い

標準的

標準的低い

クライアントに専用ハードウェアを必須としない
クライアントに専用ソフトを必須としない

pg. 104.4

認証方式の違いによるラインナップQuiX 端末認証は、Web アクセスに対応した Basic 版と、マルチプロトコルに対応するためのRADIUS 連携オプション、および外部 Web システムの認証と連携する SAML 連携オプションが用意されています。
また、対応クライアント別にいくつかの種類があり、システム要件やセキュリティ要件といったニーズに合わせて最適なものを選べるようになっています。

pg. 11

4.4.1

Basic 版

端末認証のソフトウェアを実行するサーバを、負荷に応じて必要台数（1 台～）用意し、その上で QuiX端末認証ソフトウェアを動作させます。
QuiX 端末認証ソフトウェアが、ゲートウェイ（正確にいうとリバースプロキシ）として働き、認証作業及び、実際にユーザがアクセスするアプリケーションサーバとのやりとりを行います。

この方法は、認証機能がソフトウェアのみで実現されていますので取扱いが簡単です。但し、対応プロトコルは HTTP/HTTPs のみとなります。Basic 版の特徴としては、以下のような点が挙げられます。
 既存のアプリケーションに手を入れることなく、二要素認証を実現できる
 サイト単位・ディレクトリ単位で端末認証を行うことが可能→守るべき情報や機能を限定した形での認証強化が可能
 アクセスログを取得でき、利用状況の把握が可能
 Web アクセラレータオプションにより、アプリケーションレスポンスの改善が可能

pg. 12

Basic 版の端末認証シーケンスは下記の通りです。

HTTP/HTTPs

HTTP/HTTPs

pg. 13

4.4.2RADIUS 連携オプション

HTTP/HTTPs 以外のプロトコルを必要とするお客様のために用意されたオプションです。
導入時には、QuiX 端末認証が動作するサーバの他に、認証機能を持ったネットワークスイッチを用意する必要があります。
QuiX 端末認証サーバがスイッチのアクセスポートを制御するので、HTTP/HTTPｓだけでなく、導入企業が必要とするすべてのプロトコルを扱うことが可能です。

（＊ 対応するスイッチ製品については、事前にご確認ください）
RADIUS 連携オプションの特徴としては、Basic 版の特徴に加えて以下を挙げることができます。
 Web アクセスだけでなく、メールやファイルサーバへのアクセスなど、すべてのプロトコルで端末認証を行うことができる スイッチの設定により、端末認証で保護するネットワークと、保護しないネットワークを分けて管理することができるpg. 14

RADIUS 連携オプションの端末認証シーケンスは下記の通りです。

HTTP/HTTPs

HTTP/HTTPs

pg. 15

4.4.3

SAML 連携オプション

SAML に対応したクラウドサービスをご利用のお客様のために用意されたオプションです。
通常クラウドサービスを利用する場合 ID とパスワードによる認証を行うのが一般的ですが、企業でクラウドサービスを利用する場合に、「業務で使用する機密情報を格納するには、ID とパスワードによる認証だけでは不安」という声が多く聞かれます。
QuiX 端末認証 SAML 連携オプションは、こういったお客様の不安を解消するために用意されたオプションです。

※SAML：Security Assertion Markup Language（セキュリティ アサーション マークアップ ランゲージ）
OASIS で策定されたインターネット上で ID やパスワードなどを交換するための XML 仕様。

SAML 連携オプションの特徴としては、以下を挙げることができます。
 クラウドサービスを企業利用する際に、端末認証を行うことで不正端末からのアクセスを防止することができるため、業務で利用する機密情報をクラウド上に保存しても安心。
 SAML 対応しているクラウドサービスであれば、複数のクラウドサービスで端末認証を行うことができる。

pg. 16

SAML 連携オプションの端末認証シーケンスは下記の通りです。

HTTP/HTTPs

4.4.4

クライアントの種類

サーバ側は上記の３種類ですが、クライアント側も３種類の実装があります。
・ActiveX 版
・JavaScript 版
・専用アプリ版
これらを用いることで、幅広いシステムに対応可能となっています。
※専用アプリの対応は個別にご相談に応じております。

pg. 17

5. 各種パッケージの内容
QuiX 端末認証は、稼働プラットフォームや利用目的により、異なる内容のパッケージを選ぶことができます。

pg. 18

5.1

動作環境

QuiX 端末認証の稼働環境は下記のとおりです。
★ クライアント側の動作環境★ サーバ側の動作環境
Windows Server 2003R2 SP2Windows

Windows Server 2008SP2
Windows Server 2008R2
RedhatEL5/６

LinuxCentOS5/６
他の OS についてもカスタマイズ事例ありますので、ご相談ください。

pg. 196. 適用事例
6.1
ケーススタディ１：全国 500 か所の教室から利用する業務システム
業種：教育関連企業 A 社

対象システム：全国 500 か所の教室から利用する業務 Web システム

導入の背景
A 社の業務 Web システムはデータセンターに設置され、全国 500 か所の教室からアクセスしています。このシステムは、生徒の成績等のほか、保護者の住所や決済情報といった機密性の高い個人情報を格納しています。
このため、ID とパスワードによる認証だけでは不安がありました。特に、自宅やネットカフェなど教室以外からの不正アクセスや情報漏えいの危険性が懸念されていました。
QuiX 端末認証によるソリューション
この案件では当初、次の案が検討されました。
・教室とデータセンターを VPN で結ぶ案
・クライアント証明書による端末認証および利用制限
これらの案はコストやメンテナンス性の面で要求仕様を満たすことができず、最終的に QuiX 端末認証の導入が決まりました。導入決定の理由としては、下記が挙げられています。
①導入が容易であること
ブラウザで業務システムにアクセスするときに一度端末を認証するだけで、それ以降利用者は、認証機構を意識せずに利用可能②初期費用およびランニングコストが安価だった
他の方式と比較して、初期費用およびランニングコストが半分以下で済むこと。
③教室の移転・追加に伴うメンテナンスコストも安価なこと認証された端末は、移転先でもそのまま利用可能であり、メンテナンスの必要がない。
また端末の追加・削除も管理者画面で全て行うことができ、メンテナンスが容易。
④セキュリティ面は他社製品と比較して遜色がないと評価されたため。

pg. 20

6.2

ケーススタディ２：社外勤務者のリモートアクセス

業種：IT 企業 B 社

対象システム：社外勤務者がデータカードを使用して社内ネットワークにアクセスするシステム

導入の背景
B 社では、IT 業界によく見られる客先常駐や現地常駐で勤務している社員に向けて、業務報告や経費精算等などの日常業務の利便性を向上する目的で、データ通信カードを配布し、社内ネットワークへアクセスできるようにすることを検討していました。
しかし、データ通信カードの貸し借りにより、常駐先企業の PC や個人の PC から社内ネットワークにアクセスできてしまうという点が問題でした。情報漏えいやウィルス感染などのリスクが懸念されたため、対策案を検討していました。
QuiX 端末認証によるソリューション
このケースで当初から懸案だった「なりすまし」を避けるには、端末認証は最適な手法でした。そのため B 社における QuiX 端末認証の導入決定はスムーズでした。
導入決定のポイントは、なりすまし防止に有効であることに加え、下記の点を高く評価しました。
① アクセスする PC の認証に特化しており、PC のパフォーマンスに影響を与えないこと② 初期導入費用が安価で、運用管理も容易であること
B 社はこれらの点を評価して、QuiX 端末認証を採用しました。

pg. 21

6.3

ケーススタディ３：スマートフォンセキュリティ

業種：通信機器販売企業 C 社

対象システム：全国の営業マンが利用する営業支援 Web システム

導入の背景
C 社では「社内で利用している営業支援 Web システムを外出先から利用したい」という営業マンの要望を受け、インターネット経由でのアクセスを検討しました。
リモートアクセスに使うデバイスとして当初ノート PC を検討したが、可搬性や利便性の点から、最終的にはスマートフォンの導入を決定しました。
C 社の営業支援システムは、顧客や商談に関する機密情報を扱うため、ID とパスワードによる認証に加えて、認証の強化を検討することになりました。
QuiX 端末認証によるソリューション
QuiX 端末認証の導入検討においては、下記のような点を評価しました。
・VPN のように接続の手間がなく、つながらないなどの問題がない
・スマートフォン端末を特定することができる
・営業支援システムの改造が不要
・Web アクセラレータオプションにより、コンテンツを圧縮して送ることで、電波状況の悪い場所でも快適なアクセスが可能
これらの面を他社のソリューションと比較検討した結果、QuiX 端末認証を採用しました。

pg. 22

7. Quix 端末の応用＆カスタマイズ事例
QuiX 端末認証は、認証機能の追加だけでなく、システム連携をうまく考慮することで、幅広い応用が可能です。以下に参考として、そうした応用例やカスタマイズ例をいくつか挙げておきます。

7.1

ソリューション事例１：IceWall(注)との連携

業種：通信事業者 D 社
対象システム：通信事業者の提供するネットワーク接続サービス
導入時の課題通信事業者の D 社は、顧客企業のネットワークに外部から安全にアクセスするためのリモート接続サービスを提供しています。このサービスには、HP 社のシングルサインオン製品 IceWall を使用していました。
シングルサインオンはシンプルで便利ですが、ＩＤとＰＷに基づくシステムであるため、ID とパスワードを知っているユーザは、会社支給ではない端末からも利用できてしまいます。このため「認証を強化してほしい」との声が社内から寄せられ、認証強化のための施策を検討していました。
QuiX 端末認証によるソリューション
利用端末を特定する方法として、当初はクライアント証明書を検討しました。しかし、導入コストや運用コストが、ネットワ-ク接続サービス自体の費用と同じぐらいかかるため、費用対効果の面から採用を断念。最終的に QuiX 端末認証を採用することにしました。
採用決定のポイントは以下の２点でした。
・既に導入済みの IceWall との連携が可能
・クライアント証明書と比較して導入・運用コストが低い

注）IceWall は、日本 HP が国内で開発し、製品として提供している Web シングルサインオンソリューションです。

pg. 23

7.2

ソリューション事例２：端末認証とアプリケーションユーザカウントの紐づけ業種：物流業者 E 社
対象システム：業務支援システム
導入時の課題E 社では全国の営業所から業務支援システムにアクセスしていますが、顧客情報等の機密情報が含まれるため、「ID/パスワード認証だけでは情報漏えいの危険があるのでは」という漠然とした不安を抱えており、対策を検討していました。
QuiX 端末認証によるソリューション
通常の端末認証の場合は、「認証を通った端末のみが許可」されます。例えば、ＡさんがＢさんの端末からログインするといった運用も可能です。しかし今回の件では「それだけでは不十分」ということになりました。
そこで、業務用アプリケーション側でログイン時に行うユーザ認証と、端末認証とを連携するようカスタマイズを実施しました。
その結果、「Ａさんは、ＡさんのＩＤとパスワードで、Ａさん用の端末からのみログイン可能」ということになりました。仮にＩＤ／ＰＷが漏えいしても、本人の端末から操作しない限りアクセスできないため、セキュリティ強度をより高めることができました。

pg. 24

7.3

応用事例：アプリケーションとの連携例

端末認証の応用事例として、ちょっと変わったケースを一つ紹介します。
下の図は、出勤したユーザしかシステム利用できないよう、タイムカードとの連携を実現した例です。
こうしたシステム連携にも、簡単に対応できます。

pg. 258. 結論
昨今ではクラウド化が一つのキーワードとなっていますが、セキュリティ対策なしにクラウド化を進めることは、いつ爆発するかわからない爆弾を抱えて企業運営を行うようなものです。
情報セキュリティ対策は、問題が起こる前に必然性を認識することが難しく、また導入コストも高額であるため、費用対効果を測りにくく、つい放置されがちなのが現状です。
しかし最近では、サーバを攻撃するツールも自動化されて、アンダーグラウンドマーケットで数十ドルからという安価で販売されています。
今後、セキュリティへの配慮が不十分なシステムは、外部から容易に侵略され、業務停止や個人情報流出といった被害が多発すると考えられます。
今回紹介したようなシステムであれば、比較的安価にセキュリティ強度を高めることができます。本
ホワイトペーパーの内容が、読者のニーズとマッチするかどうかはケースバイケースだと思います。ただ、いずれにしても、自社のセキュリティ要件をきちんと定義したうえで、セキュリティ強度、費用対効果、運用の手間などを総合的に判断して、適切なセキュリティ対策を導入することが極めて重要であるといえるでしょう。

9. 評価、試用についてQuiX 端末認証に触ってみたい方は、試用することができます。弊社ホームページ(URL: http://www.base.jp)の「お問い合わせ」から試用をお申し込みください。
また、VMWare 社の仮想マシン上に構築した評価・テスト環境も用意してあります。
評価をご希望の方は、下記までご連絡ください。

10. 本件に関するお問い合わせ先
ベーステクノロジー株式会社
URL : http://www.base.jp
TEL : 03-5275-7581
E-Mail : quix@base.jp
担当：寺西pg. 26