次世代SIEMの完全ガイド
次世代SIEMの完全ガイド
構造化ログ、半構造化ログ、非構造化ログは幅広い分野にわたり、それぞれに独自のメリットと課題があります。非構造化ログと半構造化ログは、人間が読み取るのは簡単ですが、マシンが抽出するのは困難な場合があります。一方、構造化ログは、ログ管理システムで解析するのは簡単ですが、ログ管理ツールがなければ使用するのは困難です。
構造化ログとは
構造化ログは、ログデータを簡単に検索、フィルタリング、処理しやすいようにフォーマットすることで、より高度な分析を可能にします。構造化ログの標準形式はJSONですが、代わりに他の形式も使用できます。ベストプラクティスは、構造化ロギングを実装できるロギングフレームワークを使用し、カスタムフィールドを受け入れるログ管理ソリューションと統合することです。
構造化ログ、非構造化ログ、半構造化ログの違い
非構造化ログは、文字列で構成される大量のテキストファイルです。これは、人間が読み取ることを前提とした順序で並べられた文字列です。ログ内のこれらの文字列には、変数が含まれています。変数は、他の場所で定義された属性を表します。変数がワイルドカードになっている場合もあります。ワイルドカードとは、ポーカーのジョーカーのようなもので、特定の値が決まっていないものを表します。
unstructured_data = ["Unstructured message","Hello Python World",str(datetime.now(timezone("EST")).isoformat())]
人間は変数を簡単に理解できますが、マシンの場合は必ずしもそうではありません。マシンはログファイル内で、変数とそれに類似した文字列を見分けられないことがあります。この違いを見分けられなければ、混乱が生じることになり、生産性の低下、ミスの増加、工数や処理サイクルの浪費につながる可能性があります。
構造化ログは、文字列ではなくオブジェクトで構成されます。オブジェクトには、変数、データ構造、メソッド、関数を含めることができます。たとえば、ログメッセージの一部であるオブジェクトには、アプリやプラットフォームに関する情報が含まれる場合があります。組織は、独自のニーズを満たす最も役立つログを得るために、オブジェクトに含める基準を定義できます、これが構造化ログの「構造」です。
以下に構造化ログの一例を示します。
structured_data = [
{
"tags": {
"host": "str(ip)",
"host_name": "str(host)",
"filename": "str(caller.filename)",
"line": "str(caller.lineno)",
"error_level": "INFO"
},
"events": [
{
"timestamp": str(datetime.now(timezone("EST")).isoformat()), #.strftime("%Y-%m-%d %H:%M:%S %Z"),
"attributes": {
"message": "Structured message",
}
}
]
}
]
構造化ログはマシンが読み取ることを意図したものであるため、構造化ログを読み取るマシンは、構造化ログに対してすばやく検索を実行し、よりクリーンな出力を生成して、プラットフォーム間での一貫性を確保することができます。人間も構造化ログを読み取れますが、主要な対象者ではありません。人間は、マシンがデータ処理を完了した出力の対象者です。
半構造化ログはマシンと人間の両方をサポートしており、文字列とオブジェクトで構成されます。通常、これらのログを適切に分析するには、解析してテーブルにまとめる必要があります。このような半構造化ログはまだ標準化されていないため、いくつかのプログラムやシステムでは、それらの識別や分類が困難です。たとえば、空白文字の値の引用符に関して、普遍的なルールは存在しません。クラウドストライクのFalcon LogScaleは、半構造化ログにも対応しており、お客様の環境内の半構造化ログに適応できます。
構造化ロギングを使用する理由
非構造化ログから特定のイベントを探すことは困難になりえます。単純なクエリでは、必要以上の膨大な情報が返ってきてしまい、目的の情報が見つからないことがあります。たとえば開発者が、特定のアプリケーションがディスククォータを一定量超過したときに作成されたログイベントを探しているとします。この場合に、すべてのアプリで作成されたすべてのディスククォータイベントの中から、該当するイベントを探すことになる可能性があります。エンタープライズ環境では、そのファイルは大きなものになります。
適切なイベントを見つけるために、開発者は検索を定義する複雑な正規表現を記述する必要があります。また、イベントが具体的であればあるほど、表現は複雑になります。このようなアプローチは、大規模なデータに対しては計算コストが高くなります。これは、一致表現をログレコードのすべての行の値と比較する必要があるためです。ワイルドカードを使用すると、計算コストはさらに高くなります。また、ログデータが変わると、一致表現は意図したとおりに機能しません。
一部の組織では、開発者が文字列の形式でコードを記述し、運用チームがそれらの文字列を解析して構造化データに変換するコードを記述していますが、このような作業には時間がかかり、計算コストが増加します。開発者または運用チームのメンバーがミスをした場合には、ロギングプロセスは中断され、ミスの原因を見つけ出す作業に時間が費やされることになります。
構造化ロギングでは、データの生成時に構造化することで、こうした問題を解消します。組織は、固定列、キーと値のペア、JSONなど、最適な形式を選択できます。今日のほとんどの企業は、アラートシステムを含む自動化システムとうまく統合できることから、JSON形式を選択しています。
構造化ロギングにはいくつかの欠点があるため、テキストログは依然として企業で必要とされています。構造化ログでは、作成時点でデータが定義されるため、その定義に合致する目的でしか当該データを使用できません。また、構造化データがオンプレミスや、厳格なデータスキーマを持つデータウェアハウスに保存されている場合、そのスキーマを変更すると構造化データの更新が必要になります。この作業は膨大でコストがかかるものになります。組織は、ログ戦略を決定する際に、誰がデータを使用するのか、どのような種類のデータが収集されるか、データはどこにどのように保存されるか、データを保存する前に準備する必要があるのか、それとも使用時に準備すればよいかを考慮する必要があります。
Falcon LogScaleは、構造化ログ、半構造化ログ、非構造化ログのすべてをサポート
構造化ログのメリットを最大限に引き出すには、開発、コンプライアンス、セキュリティのニーズに対応できる、柔軟性と拡張性が高いログ管理システムが必要です。
クラウドストライクのFalcon LogScaleは、すべての非構造化、半構造化、構造化メッセージを処理でき、あらゆるデータ形式に対応しています。また、主要なオープンソースデータシッパーと互換性があります。カスタムパーサーを使用することで、任意のテキスト形式を簡単にサポートできるため、Falcon LogScaleの統合を簡単かつ迅速に進めることができます。
ほとんどのユーザーは、構造化データをJSONオブジェクトとしてFalcon LogScaleに送信します。特別なフォーマットは必要なく、有効なJSONオブジェクトであれば問題ありません。タイムスタンプはログエントリーの一部として送信でき、Falcon LogScaleは独自のタイムスタンプに置き換えずに、ユーザーのタイムスタンプを使用します。非構造化データを送信する場合、タイムスタンプは取り込み時にコンマ区切りの長い文字列として生成され、取り込みタイムスタンプに影響を与えません。
次世代SIEMおよびログ管理のための世界をリードするAIネイティブプラットフォームをお試しください
SIEMとログ管理のための最高水準のAIネイティブプラットフォーム、CrowdStrike Falcon®プラットフォームでサイバーセキュリティを強化しましょう。ペタバイト規模でのセキュリティログを体験してみてください。クラウドネイティブ型または自己ホスト型での展開が可能です。ボトルネックの生じない、強力でインデックスフリーのアーキテクチャを利用してデータをロギングすれば、1日あたり1PB以上のデータを取り込んで脅威ハンティングに役立てることができます。リアルタイムの検索機能により攻撃者をしのぐスピードで対策を実施できます。複雑なクエリを実行しても、そのレイテンシーは1秒未満です。360度の可視性によりデータを統合してサイロ化を解消し、セキュリティ、IT、DevOpsチームがシームレスに脅威のハンティング、パフォーマンスのモニタリング、コンプライアンスの確保を行うことができます。30億件ものイベントにわたる作業でも1秒未満で実施できます。