UNIX、Linuxコマンド操作監査ツール「WEEDS UNIX-Trace」
「本番機の操作記録を監査したい」
「いろいろなベンダーが重要な本番機をどのように操作しているのか、監視したい」
「システム担当者が不正をしていないことを証明したい」
「操作ログはScript-Fileで取得しているが、とても監査できない」
UNIX、Linux系サーバーを管理されているお客様では、このようなお悩みが絶えません。
J-SOXにおけるIT統制でも、企業の重要なサーバー操作を統制することが求められています。このような課題に的確に対処したのがWEEDS UNIX-Traceです。
UNIX、Linux系サーバーの監査の課題
UNIX、Linux系サーバーの監査では、以下のような課題があり、容易には運用できていない現状があります。
・OSに付属したScript-Fileでログ取得しても、Aliasや環境変数でコマンドに別名を定義され
ると、実際の操作がわからない。
・Script-Fileで取得したログは、人間の目では監査が難しい。
（コマンドを追うことすらできない）
・例えコマンドの一覧を取得しても、UNIXコマンドに長けていないと監査できない。
（何が不正か判断できない）
・OSに既存で存在するログ「wtmp」は、「ログオフ日時が不明」、「コマンドが出力されない」
など、監査に堪えられない。
・OSに既存で存在するログ「history」は、「コマンド実行時刻が不明」、
「いつログインしたものか不明」、「最後にログインしたコマンドしか取得できない」など、
監査に堪えられない。
つまり、上記の課題を解決することがポイントであり、適した監査を実施するには必須と言えます。
WEEDS UNIX-Traceとは
WEEDS UNX-Traceは、サーバー操作の全て（コマンド、パラメータ、標準出力結果）をログ取得し、ログリポジトリデータベースへ暗号化して蓄積します。
WEEDS UNIX-Traceによって解析処理されたログは、即座にログ蓄積サーバー（ログリポジトリーサーバー）へ転送され、ログデータベースへロードされます。ログリポジトリーサーバー上では、WEEDS Log-Repository Managerによってログは管理され、監査レポートの生成やログメンテナンス（定期退避、バックアップ、リストア）を行えます。
監査対象サーバーにて一旦出力されたWEEDS UNIX-Trace用のログは、WEEDS UNIX-Traceが解析処理を実行後（標準では）削除し、監査対象サーバーへ負担をかけないよう対処しています。
全コマンド/パラメータ/実行結果を漏れなく取得
WEEDS UNX-Traceでは、監査に堪えうるログ取得のため、コマンド、パラメータ、Aliasコマンド、環境変数、コマンド実行結果を取得しています。
ここまでの機能を実装することができて、初めて実際に操作したコマンドとパラメータがわかることになります。
多くの企業がUNIX、Liunx系サーバーの操作記録をScript-Fileで取得しておられますが、Script-Fileでは上記のことを人間の目で追っていかなければなりません。
人手が介在することで、システムでの対応が実現されず、監査漏れリスク（オペレーショナルリスク）がなくなりません。
Script-FileファイルとWEEDS UNIX-Traceの比較
UNIX、Linux系OSに標準で搭載されているScript-FileとWEEDS UNIX-Traceを比較してみると一目瞭然です。
「何を見たか」が監査では重要
“情報漏えい”という観点では、「画面に何を表示したか」をいつでも過去のログを追跡できることが重要です。
UNIXサーバーからデータベースへアクセスし、個人情報や機密情報を閲覧することは容易であり、画面に表示したものをメモを取って外部へ持ち出すことも可能だからです。
WEEDS UNIX-Traceではコマンド実行結果を取得し、操作者が“何を表示して、何を見たのか”が監査可能になります。
WEEDS UNIX-Trace Guardianオプション
リアルタイムで不正コマンド、パラメータをガード
WEEDS UNX-Traceには、Guardianオプションというコマンドをブロックする抑止機能が備わっているため、
・特定のファイルに対して、何も（開く、削除、実行）させたくない。
・特定のユーザーは、使用してはいけないコマンド及びパラメータの組合せがある。
・コマンドを使用してもよいが、リアルタイムでアラートさせたい。
といった要望にお応えすることが可能です。
WEEDS UNIX-Traceは、シェルをフックしてコマンド及びパラメータを取得しているため、フックしたログを実行させるか判断ができます。 予め登録しておいた監査コマンド及びパラメータと比較し、コマンド実行を抑止したり、（syslogへ）アラートすることが可能です。
OSへユーザーIDを作らなくてもかんたん管理
監査のために、用途にわけてユーザーIDを作成しなくてはならず、管理にお困りの企業も多いと思います。
・実は特定ユーザーIDを使いまわしている。
・監査のためにユーザーIDを増やすと、ID管理が大変。
そういう企業のために、WEEDS UNIX-Traceでは、独自のユーザーIDを生成し、OSユーザーIDとは別に管理することができます。
ログサーバー側にコマンドの抑止設定
WEEDS UNIX-Traceは、シェルをフックしてコマンド及びパラメータを取得しているため、フックしたログを実行させるか判断することでコマンド実行抑止を行っています。 予め登録しておいた監査コマンド及びパラメータと比較し、コマンド実行を抑止したり、（syslogへ）アラートすることが可能です。
UNIX系サーバーのシステム監査のポイント
WEEDS UNIX-Traceで、操作記録をすべて取得し、いつでも過去に遡って操作記録を確認することができますが、日々の監査ではどのような対処が必要なのでしょうか。
通常、下図の通り、サーバーで作業を行う際には作業申請をし、許可を得てから作業されていると思います。
このような運用が想定されるとき、①～⑤の監査を実施することが望ましいとWEEDSは考えます。
①許可された端末からの操作か
サーバーを操作する際は、決められた端末での操作を義務付けている企業が多くあります。
そして、その指定端末だけを監視して監査されている企業も稀に見受けますが、OSのユーザーIDとパスワードを把握していれば、指定端末以外でも操作できます。（サーバーのコンソールなど）
指定端末以外で操作した場合、“何も痕跡が残らない”という環境は要注意です。（監査にならない）
また、例え社内ルールで、サーバーへのアクセス制限をしていても、ネットワークがはられている環境であれば、いくらでもハッキングしてアクセスされる可能性があります。
従って、どのような経路でサーバーへアクセスしても、監査証跡として操作ログを取得することはもちろん、どの端末からアクセスがしているかを監査することは、上記の通り重要になります。
指定された端末以外からアクセスしていれば、その環境で何ができてしまうのか、想定できず、抑制もかけることができません。
社内ルールやアクセス制限だけでなく、
１．どのIPからアクセスがあったのかを記録し、
２．そのIPはアクセスが許可されているか
を監査することが重要です。
作業申請はしっかりチェックされると思われますが、指定の端末で操作を実施したのか、監査することが重要になります。
②ログイン/ ログオフの管理
サーバーにいつログインし、いつログオフしたのかを監査することは重要です。
稀にログオフが取得できず、ログインだけを把握する製品がありますが、いつ作業を終了したのか把握できないということは、不正操作を実施する可能性が残っており、監査にならないに等しくなってしまいます。
通常、メンテナンス等でサーバーを操作する際には、「いつ・誰が・どこから・いつまで・何をするか」を明記した作業申請が必要となります。
作業申請なくサーバーをすることは、違反というだけでなく、不自然な操作として疑わなければならないことです。そのような作業申請外の操作を監視するために、いつ・誰がサーバーにアクセスしたのかの証跡である、ログイン、ログオフの管理が重要となります。
③作業申請とのシステムチェック
作業申請をしっかりチェックし、記録に残されているのであれば、その内容と実際の操作ログを突合させ、自動的にチェックすることで、監査コストを抑えられ、システマチックに監査ができるため、監査漏れや属人的にならずに、作業申請と実作業でのコマンド操作が同様であったか監査が実施できます。
④ログからの情報漏洩対策
前段でも述べましたが、UNIXコマンドに個人情報や機密情報が含まれる場合があります。
例えば、UNIX系サーバーからデータベースへアクセスし、個人情報が含まれる情報を参照すれば、コマンドの出力結果として個人情報が掲載され、サーバーのパスワードファイルや各種設定情報を閲覧することも容易です。
これらのログを単純に保持していると、“ログから情報漏えい”してしまうという、本末転倒な結果となりかねません。ログは暗号化などを施して保持する必要があります。
つまり、ログがセキュリティーホールとなってしまうため、不用意なログを出力することは大変危険です。
この防止策としては、
１．Scriptを禁止にする
２．ターミナルエミュレータのログ生成を禁止する
３．IPパケットがスニファーされているかを検知する
４．サーバーへの操作PCを限定する
といったことが考えられます。
⑤操作時間の監視
必要以上にサーバーを操作させることは、不正操作を誘発しかねません。
情報漏えいは、データのコピーや、印刷によるものだけではなく、画面に表示された情報を紙に書き写すことによっても起こります。
この場合、情報が流出した証跡が残りません。
特に作業には必要のない情報の閲覧や、ログインしたまま席を外してしまったり、サービス停止時間の増加を促さないように、監査して的確な時間で作業を行うよう監査しながな指導していくことが重要です。
製品仕様
| 導入効果 | 内部統制（IT全般統制対応）、監督官庁監査対応、個人情報保護法対応、 システム内部監査対応、Pマーク、ISMS対応 |
|
| エージェント モジュール | 対応OS | AIX4.3.3以降・RedHat Linux3以降・Sun Solaris 7以降 HP-UX 11i以降 ・Miracle Linux・Cent OS ※他のUNIX系OSはポーティング次第で即時対応可能 |
| サーバー負荷 | ログインシェルの出力をモニタリングしている為、サーバー負荷は微量 | |
| ログ | ログ取得項目 | ログイン日時、ログオフ日時、ログインユーザーID、入力コマンド・ パラメータ・出力結果（スタンダードI/O全て）、Aliasコマンド、 環境変数定義コマンド、実行シェル内部コマンド、FTP接続操作コマンド、 Telnet接続操作コマンド |
| 暗号化 | 独自暗号化した状態でアクセスログを生成 | |
| 転送 | エージェント実行時に転送（通常１～３回／日） | |
| ログ量 | 1kb／コマンド（操作量、標準出力量によって変動します） | |
| ライセンス体系 | サーバー（OS）単位 | |
| 価格 | オープン（ボリュームディスカウント有り） | |
.jpg)
.jpg)