はじめに

今回私達4人(長谷川、飯島、韓、大橋)は、
生ログに出力される様々なデータから、必要な情報を抽出・可視化することで、
様々な障害検知などに活用出来ることを確認します。

今期(12月末まで)の検証としては、
「Windowsイベントログからログイン成功／失敗のログを収集・(可視化するために) 集計」することで、
不正アクセスの疑いを検知出来るようにします。
具体的には、以下の流れでログ収集から可視化までを検証します。
　①ログ収集 ＞ 蓄積 ＞ 可視化 の各ツールはLinuxに導入する。
　　そのため、WindowsイベントログをLinuxへ転送する。(ログ出力：Winlogbeat)
　②ログ検索・集計の高速化のため、収集したログを加工(整形)してログ蓄積ツールに渡す。
　　(ログ収集：Logstash)
　③ログ蓄積ツールと可視化ツールを連携し、不正アクセスの疑いを可視化する。
　　(ログ蓄積：Elasticsearch、ログ可視化：Kibana)

ログ検索ツールElasticsearchについて

今回のログ検索ツールには、
Elastic社の元でOSSとして開発されている全文検索エンジンのElasticsearchを使用します。
Elasticsearchには以下のような特徴があります。
(公式サイトから引用:https://www.elastic.co/jp/products/elasticsearch/service)

①直感的でフレキシブル
　設定・デプロイが驚くほど簡単で、高機能で使いやすい設計。

②すぐれた機能を搭載
　Elasticのプロダクト/サービス限定のすぐれた機能を搭載
　(Machine LearningやCanvas、APM、インデックスライフサイクル管理など)。

③あらゆるユースケースに対応
　多様なデータを組み合わせてセキュリティや可監視性の強化、クリティカルなユースケースに対応可能。

このElasticsearchへのデータ格納について説明する前に、
Elasticsearchで使われる用語やデータ型について説明します。

Elasticsearchにおいて使用される用語

「Elasticsearchにおいて使用される用語」は一般的なRDBとは異なっているため、
各用語について、RDBで使用する用語との対比を交えて説明します。

• index：データを保存する領域。RDBの「Database」や「Table」にあたる。
  以前は「_type」でindex内をさらに領域に分けることができましたが、現在は廃止されています。
• field：列を示す。RDBの「column」にあたる。
• document：行を示す。RDBの「record」にあたる。

Elasticsearchのデータ型

Elasticsearchの「データ型」は多岐に渡るため、
今回使用するデータ型と関連するデータ型を中心に説明します。

• date：日時を格納する。
• integer：32ビットの符号付整数で、値の範囲は「-2147483648 ～ 2147483647」。
                 一般的には9桁以下の数値を格納するために用いられる。
• short：16ビットの符号付整数で、値の範囲は「-32768～32767」。
              一般的には4桁以下の数値を格納するために用いられる。integer型よりも容量節約ができる。
• keyword：文字型のデータを格納する。完全一致検索に利用可能。
                   (正規表現などを利用することで部分一致検索も可能)
• text：文字型のデータを格納する。あいまい検索に利用可能。(1文字異なる単語の検索など)
• ip：IPv4/IPv6を格納する。

Elasticsearchの検索・集計

Elasticsearchでは収集する各項目ごとに「検索可否」と「集計可否」を設定します。

• 検索可否：指定した項目での検索可否を定義します。
• 集計可否：指定した項目で「可視化」するための集計可否を定義します。
  

なお、検索可否と集計可否はデフォルトで有効になっています。
無効にする場合は明示的に「false」を設定する必要がありますが、
無効設定とすることでデータ容量を節約できます。

今回収集するデータのデータ構造について

ここまで説明した内容を踏まえて、今回収集するデータを
Elasticsearchにどのような「データ構造」で保存するかを決めていきます。

• 収集する対象（ログファイル名と項目名)
  → Windowsログ「セキュリティ」から以下の表の項目を取得します。
• 収集する項目のデータ型
  → 以下の表のデータ型の通りです。
• 収集する項目についての「検索/（可視化するための）集計」可否
  → 以下の表の通り、全項目とも「検索/集計」を実施します。
• index名：logon_event.log

上記を決めた上で、
続いてログ収集に必要になる環境構築に取り組んでいきます。
この取り組みでは12月末までに全3回のアウトプットを予定しています。
なお、次回アウトプットは12月中旬頃を予定しています。