プライバシーマーク取得の現状

プライバシーマークは昨年度の7月以降、個人情報保護のガイドラインを訂正し、かなり
厳しいファイルサーバのログ監視の仕組みを要求する形になりました。
ガイドラインにおける[3章3節の22条]の、「安全管理措置」という項目には、以下の様に記述
されています。
●第22条
個人情報のリスクに応じて、漏洩、減失、または棄損の防止その他の個人情報の安全管理の
為に必要、かつ適切な措置を講じます。
- (1,)物理的安全管理措置
- 1, 入退館(室)管理の実施
- 2, 盗難等の防止
- 3, 機器・装置等の物理的な保護
- 2, 盗難等の防止
- (2,)技術的安全管理措置
- 1, 個人データへのアクセスにおける識別と認証
- 2, 個人データへのアクセス制御
- 3, 個人データへのアクセス権限の管理
- 4, 個人データへのアクセスの記録
- 5, 個人データを扱う情報システムについての不正ソフトウェア対策
- 6, 個人データの移送・送信時の対策
- 7, 個人データを取り扱う情報システムの動作確認時の対策
- 8, 個人データを取り扱う情報システムの監視
- 2, 個人データへのアクセス制御
プライバシーマークの取得、及び更新に関しては、上記のガイドラインを遵守した場合、
現実的にはファイルサーバのログ監視が出来ないと、取得・更新に問題が有る事が判って来ています。
今迄では、確かにファイルサーバのログ監視という部分はおざなりにされて来ていました。
しかし、これからは確実に問題になるのです。
ファイルサーバのログ監視はPC操作のログ監視とは違います。
PC操作のログは、各クライアントのPC内部の操作項目をチェックするだけであり、通常社内の「個人情報保護ガイドラインに」乗っ取った場合には、「個人情報」は各クライアント内には存在しないはずです。
ですから、既にPC操作のログを取る製品を持っていたとしても、プライバシーマークの取得や更新には引っかかる可能性も高い、という事を是非ご理解頂きたいのです。
通常の個人情報は、ファイルサーバという「共有フォルダ」領域を持つサーバに入っている事が多い筈なのです。
その際にファイルサーバのログを監視するには、ファイルサーバ内にログを取得するソフトウェアを入れるか、ファイルサーバのログを外部から監視して、クライアントPCとファイルサーバ間のログをきちんと取得可能なツールの存在が必要不可欠になって来るのです。
ですから、これからはプライバシーマークを取得したり更新したりする場合には、
「ファイルサーバーのログ監視」は必須項目になるという事を、是非ご記憶頂きたいのです。
今迄のファイルサーバのログ監視ツールは、上記の様に実際いくつか存在していましたが、
非常に大きな3つの問題点がありました。
導入費用が高い
設置や設定に非常に時間が掛かる
Windowsのサーバには対応しているが、MacサーバやNASサーバには未対応
これらはログ監視ツールを導入するにあたり、大変大きな壁となっていました。
費用の面ではギガビットのネットワークの場合、ソフトウェアだけで300万円程度はかかっていたのです。
「コンテンツウォッチャー」が発売される迄は、ログ監視ツールは大変高価であったのですね。
これでは大企業しか導入出来ないツールと言われても仕方が無いのです。
更に、設置にも大変時間と手間が掛かっていました。
ハイエンドなサーバを新規導入し、更にそこにソフトウェアを入れる手間、設置後の設定等、人手もお金もかかっていました。
これも簡単設置の「コンテンツウォッチャー」が解決致しました!
更に、市場がWindowsサーバしかログ監視出来ないツールばかりの為、とあるプライバシーマークコンサルト様はなんと、「Macをやめて全社Windowsにして下さい。」という指導までしてしまっていたのです。
経営資産であるMacを廃棄して、会社のデータ資源を全くの無駄にするというのは、一体どういう事なのでしょうか?非常に勿体無い事だと思うのです。
「コンテンツウォッチャー」は、この3つの大きな無駄を省き、簡便にプライバシーマークの
取得や更新を進めて頂く為に開発したログ監視ツールなのです。
>>なぜ!?どこが「コンテンツウォッチャー」なら問題無いの?
世界最高水準のパケット取得精度を誇る
パケットキャプチャー型ログ監視ツールコンテンツウォッチャー
そもそもファイルサーバのログを取る際にはどのような仕組みがあるのでしょうか。
大きく分けますと、以下の3つの手法が考えられます。
サーバの中にアプリケーションを入れログを定期的に排出する様なプログラムにする方法 |
サーバにスクリプトを埋め込み、そこに対し外部から命令を出し、外にログを排出させる仕組みを作る方法 |
ファイルサーバを外部からモニタリングし、そのサーバ情報を取得、それをログとして整形し直して表示する方法 |
つまり、「1」と「2」に関しては、常にサーバ中にプログラムやスクリプトが常駐しており、それがログ取得の役割を果たしているのです。これ自体は実は問題は無いのです。正確なログも取れるでしょう。中に入ってイベントログ等を拾って来るのだから当然とも言えます。
しかし、実は既にお気付きの方もいらっしゃる様に、サーバ内にプログラムを常駐させている事は大変な負荷をサーバにかけてしまっているという事実を皆様はご存知でしたでしょうか?
![]() |
![]() |
![]() |
サーバには常に複数のユーザーがアクセスして来るのです。
それは即ち、複数のユーザーが全く違う事をサーバに対し要求する、という事になるのです。
本来サーバはマルチタスク、並列処理が出来るのが大きな特徴なのですが、当然サーバアクセスが増えて来れば、処理速度も遅くなるのは当然です。
ウイルスソフトがパソコンに入って
「パソコンが遅くなったなぁ…」と感じた事、ありませんか?
そのサーバに対し他の命令処理を行わせようとした場合、特に内部のログを拾って来て、それを別のサーバに送るという様な大変負荷のかかる場合には、サーバによってはアクセス速度が半分以下になってしまうケースまであるのです。
そういう作業はサーバはあまり得意ではないのです。
我々はもともとDTPを扱っている企業様や印刷会社様の様な、大容量のデータを24時間3交代制でファイルサーバ上で処理し続ける様な企業様とお付き合いしております。
また、弊社代表は15年以上に渡りファイルサーバアプリケーション等を、導入・検証・研究し続けているネットワーク・スペシャリストでもあり、このエージェント型を利用したログ監視ツールは危険すぎるという事を実は嫌という程知っていたのです。
『エージェント型の製品でログを取ったらウイルスソフトを入れたのと一緒だよ。真面目にファイルサーバを利用する企業ならまず導入はしないでしょう。
だって、仮に10人が自分が本来やる仕事を1時間でできる筈なのに1時間半かかったとするよ?
それを仮に1日に換算したら1人当たり(8時間労働7時間勤務の場合)210分のロスだよ。
これが10人で2100分。稼動20日で4200分。
70時間で時給2000円だとしても、なんと月間14万円、年間168万円のロスになるんだよ。
中古のマークIIが買えちゃうよ。まともな経営者だったらそこまで直ぐに判断付くもの…』

弊社代表は以前語りました。それは確かに危険なのは事実なのです。
もう少し分かり易く、3つの危険な理由についてご説明致します。
エージェントが常駐している事が原因でサーバ障害や故障が起きた際、サポートが困難
サーバに負荷がかかり、サーバー稼動時間が遅くなる可能性がある
サーバに入れるものだと「制御系」というネットワークへの不審者への侵入を防ぐ事は
出来るが、社内業務に支障がでる場合が多い
「2」についてはご説明致しましたが、「1」は実はもっと厄介な事なのです。
弊社製品のファイルサーバアプリケーション「HELIOS」という製品は大変堅牢なハイエンド向け製品です。特に大規模印刷会社様等ではデファクトスタンダードになっています。
しかしこの製品でもシステム障害やサーバ自体の故障等により問題が起きる場合があります。
その時に一体どこが原因でサーバ障害が起きているのかを早急に感知しない事にはサーバの復旧は行われません。
通常ファイルサーバは止める事は出来ないのです。止まったら損害賠償になる程クリティカルな製品なのです。
そのサーバ内に他のエージェントを入れ、かつ常駐させていた場合、障害原因を取り除く手間が増えるばかりか、損害賠償の矛先がログ監視システム自体に及ぶ事も予想されるのです。
「3」についてもエージェント型の製品は既に存在しています。
「不正侵入をブロック!!」等の見出しで販売していますが、これは現在「内部統制の呪縛」という新たな問題点を生む社会現象になっているのです。
日本版SOX法の呪縛と情報漏えい抑止と禁止
特に、昨年度に日本版SOX法とも呼ばれる「金融商品取引法」が成立した事により、企業内部の「内部統制」をきちんと法整備する事が求められています。
しかしこれを殊更厳しい社内の統制に利用しようとする事で、内部統制は強化されたが社内の雰囲気が悪くなったというケースが起きる事が指摘されています。
- 社内のメールが全て監視され、1本のメールを送るのにも上司の許可無しで送れない
- ウェブなども全てログが取られてしまい、しかもその情報が社長にまで届いてしまうので大変窮屈な環境になった
- 社内のコンテンツで触れられないものがあるのは良いが、誰が、いつ、そのファイルを触れられない様にするか、その許認可だけでも大変な労力が掛かってしまう
ファイルサーバのログ監視製品以外のログ解析の分野では、やはり上記の問題点をクリアに出来る製品が売上の大半を占めています。
つまり情報の流れをストップする「情報漏えい禁止」ではなく、「情報漏えい抑止」という発想で問題が起こった場合に直ぐに管理者が対処出来るという製品が市場のニーズである、という事なのです。
情報の流れをいちいち止められていては、実際の業務・実務に携わっている皆さんの心労はいかばかりかと思うのです。
仕事のスピードは落ちる、ネットワークトラフィックは遅くなる等、様々な問題点が出てきてしまうのです。
ですから、その危険性を少しでも知ってさえいれば、サーバ内にエージェントを入れる事は危険であるという事がお分かり頂けると思うのです。
しかし、プライバシーマークやISMS、日本版SOX法等では、ファイルサーバのログはきちんと監視出来なければならない事になっています。
そこで「コンテンツウオッチャー」は文頭でご説明した「3」の、
外部からログを監視する「パケットキャプチャー式」のログ監視システムとして開発される事になったのです。
この方式こそ、現在のログ監視の問題点を解決し、会社全体の仕事効率を妨げない唯一の手法であると我々は考え、今回の製品を開発する事になったのです。
それでは一体、このパケットキャプチャーとはどの様な意味なのでしょうか?
パケットキャプチャー型ログ監視で問題解決!!
パケットとはIT用語事典によると以下のような意味を持ちます。
コンピュータ通信において、送信先のアドレス等の制御情報を付加されたデータの小さな纏まりの事。データをパケットに分割して送受信する通信方式をパケット通信と呼ぶ。
データを多数のパケットに分割して送受信する事により、ある2地点間の通信に途中の回線が占有される事が無くなり、通信回線を効率良く利用する事が出来る。
また、柔軟に経路選択が行なえる為、一部に障害が出ても他の回線で代替で出来るという利点もある。
つまり映画「マトリックス」の様に、昔のマシン語さながらの「ゼロイチゼロイチ」の世界でLAN上では情報はやり取りされているのです。
パケットとは、それを1つ取り出したとしても意味をなさない位に、細分化されてしまっています。しかしパケット方式で流れているからこそネットワークが高速化したのです。
このパケットを全て集めてひとつひとつを元の意味ある文章に編集し直す事で、パケットキャプチャー型のログ監視システムはログを取得しているのです。
以上を踏まえ、結局の所パケットキャプチャー型のログ監視ツールというのは、ファイルサーバに対し流れてくる全ての情報を集めて、ログ(誰がいつ、どのファイルをどう操作したか)化するという製品である事が言えるのです。
これはハブというLANの接続点に「ポートミラーリング」という機能がある場合に実現出来る事です。(ポートミラーリング機能とはHUBに流れる1つのネットワークの線(NIC)と全く同じ情報を、別の線(NIC)に流す事の出来る機能)
この事により、パケットキャプチャー型の製品には以下の利点があります。
ファイルサーバに負荷がかからない
ハブに差すだけでログが監視できるので手間がかからない
ネットワークの帯域に負荷がかからない
以上の3点により、パケットキャプチャー型の製品はログ監視に向いているという事はお分かりになったと思います。
現実的にサーバにエージェントが入る仕組みは以前から製品としてありましたが、あまり評判は良くありませんでした。
しかし、この仕組みであればサーバに負荷が掛からず、問題点もクリアになるに違いないと我々は考えました。
ただ実は、このパケットキャプチャーにも大きな問題点があったのです。
パケットをきちんと正確に取れているのか分からないので情報精度が下がるんじゃ…
そうです。ファイルサーバに流れるログと全く同じものを取っているといっても、そのログをきちんと正確に取得出来ているという確証が得られ無かったのです。
それでは実際にログが取れていない操作をしていた項目が、情報漏えいの要のログであったりしたらどうするのでしょうか?それこそ大問題になってしまいます。
あるパケットキャプチャー型の製品ではパケット取得率が80%前後では無いかと思われる記述すらあるのです。その程度の精度では到底市場に出す訳には行きません。
プライバシーマークやISMS、来年度には日本版SOX法まで控えているというのに、それではファイルサーバにエージェントを入れた方が余程マシでは無いかと我々は考えました。
苦難・困難・パケット取得率99.99%への道!!
最良の選択肢は"パケットキャプチャー型である"と分かってから、我々は研究に研究を重ねて参りました。
決め手は精度であるのだから、ここをクリアすれば必ず道は開ける筈と信じたのです。
「出来るだけ負荷がかからず、パケットキャプチャー精度が限りなく100%のものを作ろう」
というスローガンの下、多くの時間をかけて開発を進めて来たのです。
数限りない手法を研究し、我々は精度を高めて参りました。失敗も数多く致しました。
精度が上がらず2ヶ月も無駄に時間が過ぎてしまった事もありました。
しかし現在やっと(ここから先は特許取得に関わる企業秘密なので詳しくは申せませんが…)
1年以上の歳月をかけ、ほぼ100%のパケットキャプチャー精度に到達する事が出来ました。
この水準は世界最高精度を目指して開発されたが故に達成されたのだと、はっきり自負できる様な製品となりました。
皆様からの期待の声に励まされ、何とか開発が完了する事が出来たのです。
本当に有り難うございました。
更なる精度へ、更なる高機能へ、コンテンツウォッチャーは進んで行きます。
この事により、ファイルサーバのログ監視に関し、パケットキャプチャー型製品が、
『負荷がかからず、更に導入もし易く、精度も高い製品』
としてが認知されるに至ったのです。
この事は日経産業新聞等でも大きく取り上げて頂きました。
大企業様等で大規模検証等を行って頂き、キャプチャー精度の確認では、弊社検証通りの結果も頂いております。
印刷業界様やデザイン会社様、多くの大企業様にも導入が進んで来ております。
昨年度の8月発売以来、パケットキャプチャー型のログ監視製品を切望していた企業様から、更に数多くのご相談を頂いております。
特にWindows、Macの混在環境や、NASサーバを利用している企業様にとっては、弊社製品は現在最も導入しやすい製品として多くのご用命を頂く様になりました。
弊社製品「コンテンツウオッチャー」は、これからもパケットキャプチャー型ログ監視ツールのデファクトスタンダードになるべく、更なる開発に邁進して参ります。


































