カテゴリー: 気まぐれ日記

暑いですね。
ここ、札幌も連日夏日が続いていて夏ばて気味です。

さて、先日はFAX誤送信問題について述べてみましたが、ネット上を検索すると、2社ほど対策をシステム化しているのがみつかりましたので紹介します。

●まず、「Cooh」と言う会社のIP-ファックスで、以下の機能が紹介されていました。
（http://www.cooh.co.jp/solution/index.html）

1：送信先情報登録時の誤登録防止

登録時に先方担当者確認を伴う登録方法を採用し、確実に正しい番号が登録されます。
簡単な操作で送信先を登録→受信確認シート＋メール（FAXとメールを組み合わせた送信先確認）→登録時の誤りを排除します。

2：FAX送信時の番号打ち間違いを防止

全ての送信は登録されたデータより、PC上で送信先を選択して行われるため、番号の打ち間違いによる誤送信が発生しません。また、送信時に確認画面をポップアップ表示することで、さらに送信先の再確認を促します。

3：受信者の番号変更に対応・登録番号の鮮度保持

相手先のFAX機に登録されている「発信者番号」「発信元表示名称」等を自動取得して送信時にチェックすることで、古いFAX番号に送信してしまうことを防ぎます。　また、定期的に送信先受信端末のハードウェア情報を照会。登録者情報の鮮度を保つことで、受信者の転居などに起因する誤送信を防止し、なおかつ送信エラーも減少します。

●次にNECでも取り組まれていて、以下の機能が紹介されていました。
（http://www.nec.co.jp/pcom/fax/ip6050cs/security.html）

相手機確認送信

相手先番号をディスプレイで再確認。誤送信を抑制。
スタートを押した後すぐに送信せず、ディスプレイで相手先番号を確認してから送信。フルダイヤルはもちろん、ワンタッチで送信する場合にも有効です。
・ スタートを押してもすぐに送信せず、番号確認画面を表示することで誤送信を防止
・ ワンタッチや同報送信時も有効。間違った宛先への送信を抑制

相手機の登録番号情報と指定した番号を照合して誤接続による誤送信を抑制。
送信時にワンタッチダイヤルに登録されている宛先番号やフルダイヤルで指定した番号と相手機に登録されている番号情報を照合してから送信を開始します。こちらの指定番号と相手機で持つ番号情報が合致しない場合は送信を行いません。
・ 送信時に相手先から受信するCSI信号で相手先を確認してから送信することでFAXの誤接続による誤送信を抑制

親展通信

パスワード指定で送りたい相手だけに確実に送信。
送信側でパスワードを指定すると、受信側ではすぐにプリントされません。パスワードを知る人だけがプリントして内容を確認できます。
・ Fコードに対応。他メーカーのFコード対応機種との間でも親展通信が可能

●NECの親展機能は、相手FAXでも同様の機能があることが前提となりますが、誤送信に対するリスクとセキュリティに対するコストをどう考えるかがポイントになりそうです。
ちなみに、NTTFAXで検索しても、親展の機能をもつものはありましたが、CSI信号による相手先確認機能を記載しているFAXはみつかりませんでした。
セキュリティに対する取り組み姿勢の違いでしょうか、、、、

ひところ、ファイル共有による情報漏洩が問題となっていたが、最近の我が社では、FAX誤送信による情報漏洩が事欠かない。
で、事故が起きるたびに行われてきた対策が、

①直接ダイヤルせずに宛先登録機能を使え
②ダイヤル部に蓋をして使用しないように
③別人によるチェックをする
等々、なんとも頼りない指導が行われてきた。

人為的に起きるミス・事故に対しての対策が人の行動に頼った対策では、同じような事故が再発しても不思議ではない。

どうせ人の行動に頼った対策を考えるなら、自動送信機能を使わずに、FAXが誕生したころのように、相手を呼び出して相互に確認しながら手動送信を行うのが最も危険が少ないと思うのだが．．．

事故が発生した時、何故事故になったのか？他に危険要素はなかったのかを分析して対策を指導してきたのか疑問に思う。

単純に考えても

１．宛先登録登録機能に潜む危険

①宛先ダイヤルを誤って登録
②古い宛先ダイヤルを登録
③登録されている宛先の陳腐化

２．送信時に潜む危険

①登録ボタンを誤って使用
②直接ダイヤル時に誤ダイヤル

3.送信後に潜む危険

①送信先で他の受信にに紛れて紛失
②送信先で他の人に盗用されてしまう
③送信先で誤って破棄されてしまう

等々の危険要因が思いつく。
これらを解消するFAXが世の中に無いとは思えない。

我が社には、仮にも誇り高いソリューション部門というものがあるのだから、会社上げて本気に対策を打たないと。
大きな問題に発展してからでは遅すぎると思うのだが、、、、

しばらく記事の更新をサボってました。
病気のぶり返しか、無気力で何もしたくなかった訳で、、、、

先週、会社のセキュリティ総点検ということで、数人の人がこられ、聞き取り調査を行って行った。
自ら、何かツール類を使って調査する訳でもなく、ルールが守られているか等、点検簿を主にチェックを行っていた。（この程度のものか、、、）

ちなみに、わが社では、会社から貸与されているPCには、端末管理ソフトがインストールされていて、Windowｓのアップデートやウィルスチェックパターンファイルのアップデートの管理、端末にインストールされているアプリケーションの管理等を行っている（らしい）。

これは多分、レジストリの情報を引き出していると思われる。（ならば、レジストリの該当項目を削除してしまえば、管理不能となるかも、、、、）

私の端末には、『Cain』という危ないツールをインストールしているが、端末管理ソフトの情報を見てみると、そのアプリケーションをも管理センタへ情報が送られているようだ。
しかし、今日まで何も指摘されていないので、管理センタでは確実にセキュリティ管理されているのかが疑問だ。

ちなみに、『Cain』では他端末のパケットモニタの機能もある。他端末がSW配下であろうと、モニタできてしまう。
POPパスワードなんて、簡単に取得できてしまう。
で、このアプリケーションを度々動かしているが、そういった行動に対して、何も監視できていないようだ。

またぞろ、２～３日前から、妙な好奇心がもぞもぞしだし、Windowsネットワークの不思議に挑戦してみようかという気になりだした。

とりあえずは、手始めに、わが社のネットワークにぶらさがっているWindows端末の情報をWindowsXPの機能とPerlを使って収集する手段を実験してみよう。

私の勤める職場の業務システムに使っている古いSUNのワークステーション（SPARCstation5、Ultra-1、Ultra-10等々）のGDM5010PTとかGDM20E20とかのモニタを、汎用液晶ディスプレイに交換し、地球温暖化防止「国民運動」に少しでも貢献しようと試みる計画の続編。

液晶ディスプレイとVGA変換コネクタが7月6日に揃ったので、本日交換してみた。

業務システムでは、ＯｐｅｎＷＩＮ（懐かしい．．．．）を使っているようで、うまく表示されるか心配し、社内の有スキル者から沢山の情報を頂くなど、準備万端で臨んだが、特にシステム側へ何も設定変更せずに表示できた。

馬鹿デカイ、ＳＵＮの純正ディスプレイに埋もれていた環境がすっかり一変し、机周りがスッキリとし、回りの社員からも感嘆の声があがった。

とりあえす、1台だけなら私の独断で行えたが、全てとなると関連部門の調整やら何やらですぐには動けないのがこの会社の特徴（末期的ですね）。

これからどうするか、思案のしどころ．．．．．

本日、旭川市へ日帰り出張した。
久しぶりの出張であり、旭川も久しぶりであった。

目的地は、旭川市十条通10丁目。
札幌から旭川まではＬ特急で1時間30分で着いてしまうんですね。
旭川駅から目的地までは、買物公園（今もそう呼ぶのかな？）通りをひたすら真直ぐ進む。
この通りは、9条辺りまで続いており、札幌の大通り公園とはまた違ったおもむきがある。

何か催し物でもあるのか、テントを設営する人々があちらこちらに居た。

会議までの時間があまりなかったので、急ぎ足で通り過ぎたが、こんどはゆっくり来てみたいと思った。

ところで、Ｌ特急「ライラック」は初めて乗車してみたが、結構、落ち着きのある車両で、座席も一人掛けのものもあり、ゆったりと乗ることができた。