6. その他

6.1. プロキシ環境下での利用について

プロキシ環境下でForwarderを利用する際は、下記の手順にてプロキシサーバの情報を設定してください。

  1. 管理者権限を持っているアカウントでマネージャーサーバにログオンする

  2. エクスプローラーを起動する

  3. Forwarderインストール時に指定したアプリケーションデータ用フォルダ配下にある[ALogForwarderData]フォルダをダブルクリックする

  4. [config]フォルダをダブルクリックし、[ace_config.xml]を右クリックし[プログラムから開く]>[メモ帳]をクリックする

  5. ファイルが開いたら、ファイル最下部まで移動し[ProxyHostName]と[ProxyPort]を下記のように編集し保存する

<ProxyHostName>プロキシのIPやホスト名</ProxyHostName>
<ProxyPort>プロキシのポート番号</ProxyPort>
../_images/ForwarderConfigbefore.png

             ↓

../_images/ForwarderConfigafter.png

以降は クレデンシャル設定 を手順1から実施してください。

注意

既にForwarderのWebコンソールへログイン済みの場合、 クレデンシャル設定 を行う前にWebコンソールの画面をリロードしてください。


6.2. アンインストール

Forwarderのアンインストール手順を説明します。
Forwarderをアンインストールする場合、事前に対象ホストを削除します。

6.2.1. Step1. 対象ホストの削除

対象ホストの削除は Forwarder と ALog Cloud のWebコンソールそれぞれで削除します。
手順の順番で削除してください。
  1. Forwarder Webコンソール 左メニューから[対象ホスト]画面へ遷移し、すべての対象ホストにチェックを入れ [削除] をクリックする

ソースタイプが「Windows-AccessLog」のものを選択して削除した場合は、削除確認ダイアログに「監査設定を無効化する」チェックボックスが表示されるので、必要に応じてチェックを入れて削除する
../_images/UninstallTargetServer.png

(ソースタイプが「Windows-AccessLog」のものを削除する場合の削除確認ダイアログ)

../_images/UninstallDialog.png
  1. ALog Cloud Webコンソール [管理]-[対象ホスト]画面で、「Forwarderホスト名」欄で当該ホストを絞り込み、対象ホストにチェックを入れ [削除] をクリックする

6.2.1.1. 対象ホスト削除後の監査設定について

対象ホスト削除後の監査設定についてログタイプごとに解説します。

ログタイプ

監査設定に対するその後の作業について

Windowsアクセスログ

・Forwarder経由で監査ポリシー設定を削除しイベントログの出力を停止する場合は、対象ホスト削除時に「監査設定を無効化する」にチェックを入れて削除する。チェックを入れた場合、ALogに関わるカテゴリのポリシー設定をすべて「監査設定なし」として上書きする。対象ホストのローカルセキュリティポリシーを変更するため、グループポリシーを適用している場合は手動でドメインコントローラーの設定を変更する必要がある
・フォルダーに対する監査設定は必要に応じて手動で解除する
・イベントログをアーカイブ保存しない場合、イベントビューアーのプロパティで設定変更する

Windowsアクセスログ以外

対象ホストとなる機器ごとに異なるため、それぞれの機器にあわせて解除する

6.2.2. Step2. Forwarderの削除

  1. Forwarderをインストールしているホストのスタートメニューから[コントロールパネル] ‐ [プログラム] ‐ [プログラムと機能]を開く

  2. 一覧から「ALog Cloud Forwarder」を選択して[アンインストール]をクリックする

  3. アンインストール後、Forwarderをインストールしているホストの以下のフォルダーに設定ファイルやデータ等が残るので、必要に応じて手動で削除する

  • プログラムインストール先フォルダー X:\ALogForwarder (既定のインストール先フォルダーにインストールした場合)

  • アプリケーションデータ用フォルダー X:\ALogForwarderData (既定のアプリケーションデータ用フォルダーにインストールした場合)


6.3. 制限事項

ForwarderおよびALogでは、以下の制限事項があります。


6.3.1. ログ変換に関する制限事項

ログ変換に関する制限事項を記載します。

6.3.1.1. 実際の操作と異なるファイルアクセスログが記録されることがある場合について (Windowsアクセスログ)

ALogは、対象ホストのイベントログを収集し、アクセスログに変換するシステムです。
収集したイベントログの内容によってアクセスログの内容が決まるため、対象ホストやクライアントPCのOS、ユーザーが利用するアプリケーションの制約などにより、ユーザーが行った操作通りのログが出力されないことがあります。
  • ファイルアクセスのログ変換ロジックは、以下のアプリケーションによるファイル操作が正しく反映されるよう作成されています。

    エクスプローラー / メモ帳 / ペイント / Microsoft Word, Excel, Power Point / Adobe Acrobat Reader

※その他のアプリケーションを利用した操作によるアクセスログは、実行されたシステムコールの内容を識別して、ユーザーの操作に近いログに置き換えますが、対象ホストやクライアントPCのOS、ユーザーが利用するアプリケーションの組み合わせによっては、ユーザーが行った操作どおりのログが出力されない場合があります。

6.3.1.2. COPY/MOVE操作のログ出力について (Windowsアクセスログ)

「COPY」や「MOVE」のユーザー操作は、イベントログ上は「COPY」や「MOVE」という形では記録されません。
ALogではアクセスログの可読性を上げるため、以下の通り特定の条件が合致した場合に「COPY」「MOVE」としています。
ユーザー操作ではコピー、移動をした場合でも、イベントログに、条件に合致するログが出力されていない場合は「COPY」、「MOVE」と出力されない場合があります。
 [COPY]
コピー元/コピー先双方のログがイベントログに書き込まれ、それぞれの関連性が読み取れる場合に、「COPY」として出力します。
 [MOVE]
移動したファイルは「RENAME」として記録されているため、移動元(名前変更前)と移動先(名前変更後)でファイル名が維持された「RENAME」の場合に「MOVE」として出力します。
  • コピーの操作について

アプリケーションの状況や処理により、実際にユーザーがCOPY操作を行っていなくても出力される場合があります。
この場合の「COPY」は、「READ」および「WRITE」が行われたことを示します。
  • 移動の操作について

ファイルを移動した際、移動先の情報がイベントログに記録されない場合があります。
このような場合はALogの変換において移動元で「MOVE」、移動先で「WRITE」とすることができません。
ALogの変換では以下のような出力になります。
  • 移動元…「RENAME」として出力され、[To]は非表示になる

  • 移動先…何も出力されない

6.3.1.3. 「ClientName」、「ClientIP」が表示される条件について (Windowsアクセスログ)

アクセスログの詳細項目である「ClientName」、「ClientIP」が表示されるか否かは、元となるイベントログの情報に基づき決定されます。
  • ログオンログ … 元となるログオンのイベントログに付与されている情報に応じて「ClientName」、「ClientIP」のいずれかが出力されます。

  • ファイルアクセスログ … ファイルアクセスのイベント前にログオン情報が記録されている場合のみ表示されます。

リモートホストからのWindowsファイルアクセスについて「ClientName」、および「ClientIP」が出力されるのは、以下の全ての条件を満たしたときのみです。
  • ファイルアクセスログ、管理者操作ログ、アプリケーション起動ログ、ログオンログ、のうち1つでも取得する設定が事前にされているとき (これらはセキュリティログを読み込むログ種別となります。)

  • 事前に上記アクセスログに変換されるイベントがイベントログに発生しているとき

6.3.1.4. ファイルアクセスログにおいて成功操作でFailureが出力されることがある場合について (Windowsアクセスログ)

ファイルアクセスログ(READ/WRITE/RENAME/DELETE)におけるFailureの出力は、当該ファイル/フォルダーに対するアクセス権の確認に失敗したことを示しています。
しかし、『Failureのアクセスログが出力された』ことは、必ずしも『ファイルへのアクセスに失敗した』ことを意味するものではありません。
ユーザーがファイル/フォルダーにアクセスした際、OSは権限チェックを行い、アクセスしようとしているユーザーに紐づいた複数のアクセス権を順番にチェックします。
Failureが出力されているケースでは、いくつか行われたアクセス権チェックにおいて、「失敗」(権限がない)の判定が出たことを意味しています。
しかし、このあと次の権限チェックを行う中で、ファイル/フォルダー操作に対して必要な権限を持っていることが判明した場合、ユーザー操作としては成功します。
この場合、ログの読み方としては、最終的にそのファイルへのアクセスに成功したログが出力されていれば、実際にはファイルアクセスは成功しています。

6.3.1.5. ファイルアクセスログにおいて期待したFailureが出力されないことがある場合について (Windowsアクセスログ)

実際のユーザー操作でファイルアクセスに失敗した場合、イベントログに「失敗」が記録されていないとアクセスログでFailureのログを出力することは出来ません。
ファイル破損等の権限以前の問題でファイルが開けないような場合も同様です。
また、何らかの障害でファイル操作に失敗した場合は、操作の途中で処理が中断されるため、失敗操作の種類を特定することができません。
実行されたシステムコールの内容をアクセスログに変換しますが、『書き込み処理でREAD-Failureになる』『削除処理でWRITE-Failureになる』など、実際の操作と異なるアクセスログが出力されることがあります。

6.3.1.6. フォルダーのアクセス失敗(READ-Failure)を出力しない場合について (Windowsアクセスログ)

フォルダー”folder1”とそのサブフォルダー”folder2”があり、ユーザーは”folder1”を開くことができるが、”folder2”はアクセス権がなく開けないとします。
このとき、このユーザーが”folder1”を開くと、”folder2”に対するREAD-Failureの履歴がイベントログに出力されます。
このイベントログをそのままアクセスログに変換すると、実際には”folder2”を開こうとした訳ではないのにREAD-Failureのログが記録されてしまうことから、ALogはフォルダーのアクセス失敗(READ-Failure)の履歴をアクセスログに出力しません。
なお、ファイルへのアクセスが失敗した場合(ユーザーがファイルを開こうとしたがアクセス権が無く開けなかった、等)はアクセスログに出力されます。

6.3.1.7. フォルダーを開くだけで配下のファイルのREADが出力されることがある場合について (Windowsアクセスログ)

対象ホストは、フォルダーを開いた時に「フォルダー内にあるすべてのファイルの情報」を読み取り、すべてのファイルのイベントログを出力します。
ALogは、この「フォルダーを開いた時のファイルのREAD」のイベントログと「実際にファイルを読み込んだ」時に発生するイベントログの違いを識別し、フォルダーを開いただけではファイルのREADを出力しないよう処理しています。
しかし、イベントログの問題により、稀にこの判別を行うことが出来ない場合があります(この問題は一度現象が起こると連続的に発生する場合があります)。
その場合は以下の条件によって目視で「フォルダーを開くだけで起きるファイルのREAD」を識別します。
  1. フォルダー内のすべてのファイルがREADと記録されている

  2. アクセスログの「ユーザー」と「時刻」がほとんど同じ内容になっている

表 6.1

時刻

ユーザー

対象

操作

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\業務受託案件リスト.doc

READ

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\社員名簿.xls

READ

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\受注登録シートマスター.xls

READ

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\090430運営委員会議事録.doc

READ

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\(社外秘)新卒採用シート.xls

READ

2015/05/18 14:04:51.890

Domain\Yamaguchi

D:\営業部\2008下期営業部業績.xls

READ

なお、ファイルの縮小版の表示や、フォルダー内のファイルのマイナー属性項目の表示などは、実際にファイルを操作しているとみなされ、READが記録されます。

6.3.1.8. 0byteのファイル/フォルダー操作について (Windowsアクセスログ)

ホスト内のファイルやフォルダーの操作では、中身のあるファイル/フォルダーの操作(nbyteの操作)と、中身のないファイル/フォルダーの操作(0byteの操作)で、変換の元となるイベントログに記録される内容が異なります。
ALogの変換は、nbyteの操作を優先したログ変換ロジックとなっており、0byteの操作はnbyteの操作と同じアクセスログにならない場合があります。
例1:0byteのファイルを開いた場合、操作したアプリケーションによってはアクセスログが出力されないことがあります。
例2:0byteのファイルをコピーした場合、元ファイルのCOPYもしくはREADが出ず、新ファイルのWRITEだけが出力されることがあります。
例3:0byteのWordファイルを移動した場合、MOVEおよびWRITEが2回出力されることがあります。
例4:0byteのフォルダーを別ドライブに移動した場合、元フォルダーのCOPYが出力されることがあります。

6.3.1.9. 拡張子の無いファイルはフォルダーとして扱われる可能性がある場合について (Windowsアクセスログ)

イベントログの解析によりファイルかフォルダーかの判断がつかないファイルアクセスに関しては、その判断を拡張子の有無で行っているため、拡張子のないファイルアクセスはフォルダーアクセスと見なされてREADが出力されないことがあります。

6.3.1.10. ユーザー名の末尾が「$」となるログの出力について (Windowsアクセスログ)

ローカルシステムアカウント(ドメイン名\コンピューター名$と表記されるアカウント)によるアクセスは、ユーザーの操作によるログとみなさないため、末尾が「$」となるユーザーによるアクセスログは出力されません。
ただし、管理者操作ログではこの仕様は適用されず、出力されます。

6.3.1.11. RENAME先のファイル名の確認方法 (Windowsアクセスログ)

「RENAME」操作が行われた際の変更後のファイル名は、「RENAME」のアクセスログ行の[To]に記録されます。
また、直後に「WRITE」のアクセスログが出力されます。
但し、「RENAME」先のファイル名がイベントログに出力されないケースを確認しており、この場合はアクセスログに出力できません。
  • 「RENAME」先のファイル名がイベントログに記録されるケース では「RENAME」行の後に「WRITE」が出力されます。

表 6.2 正しく出力される例

対象

操作

詳細

C:\XX\ファイル名A

RENAME

To:C:\XX\ファイル名B

C:\XX\ファイル名B

WRITE

  • 「RENAME」先のファイル名がイベントログに記録されない、関連が明確にならないケースでは、アクセスログが正しく出力できません。

表 6.3 「To」欄、後続のWRITEともに変更後のファイル名が不明なため出力されない例

対象

操作

詳細

C:\XX\ファイル名A

RENAME

(Toが出力されない)

(この行が出力されない)

表 6.4 変更後のパスが不明で正しく出力されない例

対象

操作

詳細

C:\XX\ファイル名A

RENAME

To:C:\YY\ファイル名B

C:\YY\ファイル名B

WRITE

6.3.1.12. ファイルアクセス時のアプリケーション名(詳細フィールド AppName)の表示について (Windowsアクセスログ)

リモートアクセスの場合イベントログにAppName相当の情報が出力されないため、AppNameは表示されません。
ファイルアクセスにおけるAppNameの表示は、ローカルアクセスの場合のみに限定されます。

6.3.1.13. 対象ホスト内のファイル操作に関するファイルアクセスログについて (Windowsアクセスログ)

対象ホスト内でのファイル操作では、共有経由でのファイル操作とは異なるイベントログが出力されるため、アクセスログの出力結果も異なる場合があります。
以下のようなケースを確認しています。
  • ケース

    操作:OfficeのアプリケーションにおいてPDF形式で保存する
    アクセスログの出力:「WRITE」を期待するが「DELETE」と出力される

6.3.1.14. プリントログのユーザーのドメイン名の表示について (Windowsアクセスログ)

イベントログによるプリントのイベントには、ユーザーのドメイン名情報が含まれていないため、プリントログのユーザーのドメイン名は表示されません。

6.3.1.15. アクセスログに「UnknownXXX(User/Workstation/PrintDocument)」と出力されることがある場合について (Windowsアクセスログ)

アクセスログの[User]に「(UnknownUser)」、[Object]に「(UnknownWorkstation)」、「(UnknownPrintDocument)」と出力される場合があります。
これらの出力は、収集したイベントログ内にユーザー名、ワークステーション名またはプリントドキュメント名が無かった事を意味しています。

6.3.2. マッピング設定を要するログタイプを対象とした制限事項

6.3.2.1. ログ収集に関する制限事項

マッピング設定を要するログタイプを選択した際に指定するログ収集に関して下記の制限事項があります。
制限事項は収集方式により異なりますので、制限事項に該当する方式をリストで記載します。
  • 対象ホストのイベントログを収集

  • 共有フォルダーから収集

  • ローカルフォルダーから収集

  • SCP収集

6.3.2.1.1. BOM(byte order mark)を含む収集対象のファイルの処理
  • 共有フォルダーから収集

  • ローカルフォルダーから収集

  • SCP収集


収集対象ファイルが先頭にBOM(byte order mark)を含むファイルであった場合、差分収集したファイルはBOM(byte order mark)のないファイルになります。 また、ファイルの分割が行われた場合、差分収集のような、単純なバイトカットではないため、以下のような処理結果になります。

  • 分割後のファイルの改行コードは、「CR/LF」になる。 utf-8またはutf-16などで分割した場合は、BOM(byte order mark)が必ず付加される。

6.3.2.1.2. 特定の条件下において対象ホストからのイベントログ収集処理が正常に動作しない
  • 対象ホストのイベントログを収集


対象ホストから収集の対象としているイベントログのパスが以下のような状況にある場合、ログ収集タスクで対象ホストのイベントログを収集する処理が正常に動作しません。

  • %SystemRoot% 以外の環境変数が含まれている。

  • %SystemRoot% 環境変数が含まれており、かつその値が C:\Windowsではない。

  • 収集対象となるログが格納されているフォルダーパスに対し、管理共有経由でアクセスできない。

6.3.2.1.3. 変更後の収集対象パスに過去のイベントログが存在する場合そのイベントログも収集されてしまう
  • 対象ホストのイベントログを収集


収集対象としているイベントログのパスを変更した際、変更後のパスのフォルダーに過去のイベントログが存在している場合、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となり、結果重複したログ収集となってしまいます。 なお、この重複したログ収集を避けるためには、変更後のパスのフォルダー内のイベントログを退避する必要があります。

6.3.2.2. 対象ホスト管理に関する制限事項

6.3.2.2.1. 収集対象となるログのフォーマットが変わった場合、ログ変換時にエラーとなる可能性がある
マッピング設定を要するログタイプを選択した場合において、収集対象となっているログのフォーマットが途中で変更された場合、ログ変換時にエラーが発生する可能性があります。
例として、以下のようなケースがあります。
  1. ファイル形式がCSVのログを収集するために、マッピングの設定で、「CSV/TSV/DSV」を選択し、カンマ区切りを指定した

  2. その後、出力されるログのファイル形式がSyslogに変更となったため、対象サーバのマッピングの設定を「CSV/TSV/DSV」から「Syslog」に変更した

上記の場合、次のログ変換タスクにおいて、一部のログ(直前までのログ収集でアップロードされたCSVのzipファイル)の翻訳処理でエラーが発生する可能性があります。
このようなエラーを抑制するために、最後に収集したログの変換が完了していることをALogで確認の上、マッピング設定にて収集するファイル形式を変更してください。

6.3.2.2.2. ログ変換時のマージ処理について
マッピング設定を要するログタイプを選択した場合において、[マッピング設定-出力]設定のオプション「重複する行を1行にマージする」にチェックをつけるとマージ処理が動作しますが、この処理はファイル内のレコードに対して行われるため、別ファイルに分かれる場合はマージ処理を行いません。
またファイル内のレコードにおいて、TimeStampフィールドの記録順にマージ処理を行います。TimeStampフィールドを変換処理時に並び替えすることは行いませんので、場合によっては期待するマージが行われない場合があります。
6.3.2.2.3. 過去のログを再変換する時のログフォーマット毎の既定値について
マッピング設定を要するログタイプを選択した場合において、「過去のログを再変換する」ことが可能です。
但し、イベントログ以外のログフォーマットを選択した場合、再変換実施時は「マッピング設定 - 入力」で任意で設定した値ではなく、ALog側で決められた既定値にてログの変換が行われます。
各ログフォーマットでの再変換時の既定値は下記の通りです。

ログフォーマット

設定項目

適用される値

プレーンテキスト

文字コード

UTF-8

自動フォーマット設定

ユーザー設定値

プレーンテキスト(旧方式)

文字コード

UTF-8

正規表現文字列

ユーザー設定値

CSV/TSV/DSV

文字コード

UTF-8

区切り文字

ユーザー設定値

入力ファイルにヘッダーを含む

OFF

空のフィールドを除外

OFF

コメント行の先頭文字

ユーザー設定値

JSON

文字コード

UTF-8

Syslog

文字コード

UTF-8

注意

ログフォーマットで「CSV/TSV/DSV」を選択した際、「区切り文字」および「コメント行の先頭文字」は任意の値へ変更することが可能ですが、再変換が失敗する原因となる可能性があります。

6.3.3. その他の制限事項

6.3.3.1. イベントログが破損している場合におけるタスクへの影響と変換について (Windowsアクセスログ/Windowsイベントログ)

Windowsのイベントログは、希にOSから出力されている時点で既に破損している事があります。 破損の程度は、ファイル全体が破損しているケースから、1行の特定レコードが破損しているケース、または特定レコードの中の特定のパラメータが破損している等、様々です。

ALogでは完全に破損している場合、収集タスクでエラーが発生し収集することが出来ません。 また、収集の際、収集対象となるイベントログファイルの先頭30行、および末尾30行の中に破損があれば、破損の行をスキップして収集します。 このときに、該当する先頭・末尾行以外に破損があってもエラーとはなりませんが、当該ログの変換時に、その破損レコードが変換対象となった場合には変換をスキップして処理を継続するため、アクセスログに変換できないレコードが発生します。 また、破損の状況によっては破損と認識せずに、その破損したデータをそのまま利用して変換等を行う場合があります。 その場合はアクセスログにその壊れたデータがそのまま表示されることがあります。

6.3.3.2. イベントログのOS設定について (Windowsアクセスログ)

1. 収集対象のイベントログのパスが以下の場合、イベントログ収集タスクで対象ホストのイベントログをリモート収集する処理や、対象ホスト設定編集ダイアログでイベントログのOS設定を変更する処理などが正常に動作しません。
a. %SystemRoot% 以外の環境変数が含まれている
b. %SystemRoot% 環境変数が含まれており、かつその値が C:\Windows でない
2. イベントログの出力先を変更した際、変更先のフォルダーに既に過去のイベントログが存在していると、過去のフォルダーにおける収集履歴はリセットされているため、すべてのイベントログが収集対象となります。重複したログの収集を避けるためには、変更先のフォルダーの中のイベントログを退避する必要があります。

6.3.3.3. ForwarderおよびALogで扱えるフォルダー、ファイルのパスの長さの制限について (Webコンソール)

ForwarderおよびALogにおいて収集/変換/レポート作成等で様々なファイル処理が発生しますが、.NET Frameworkの制限により、フォルダーパスが「248文字以上」および、ファイルパスが「260文字以上」に該当する場合、エラーとなり扱えません。

6.3.3.4. バックアップ機能やアンチウィルスソフトがデータファイルを排他で開き、エラーとなる場合について

Forwarderのアプリケーションデータ用フォルダーをバックアップ機能(robocopy等)のコピー対象や、アンチウィルスソフトのリアルタイムスキャンの対象にしている場合、バックアップ機能やアンチウィルスソフトがForwarderのデータファイルを排他で開き、各種処理がデータファイルを開けずエラーになることがあります。
アプリケーションデータ用フォルダーはバックアップ機能やアンチウィルスソフトの対象外にしてください。