集中ロギングは、ネットワーク、インフラストラクチャ、およびアプリケーションからログを1か所に収集して保存および分析するプロセスです。これにより、管理者はネットワーク全体のすべてのアクティビティを統合的に把握でき、問題の特定とトラブルシューティングが容易になります。

この記事では、集中ロギングのアーキテクチャの価値、その仕組み、および集中ロギングワークフローの作成方法について説明します。

ログが必要な理由

ログには、ITシステム内のシステムアクティビティ、イベント、または変更の監査証跡が記録されます。これらは、システム機能の問題、パフォーマンスの問題、またはセキュリティインシデントのトラブルシューティングに役立ちます。システムログは、システムに変更が加えられた日時と、変更を行ったユーザーを特定するために使用されます。さらに、規制要件のためにログが必要になることもよくあります。

従来のシングルサービスロギングシステム

従来のロギングシステムでは、そのシステムがインストールされている個々のマシンにのみ焦点を当てていました。1台のスタンドアロンサーバーがサービス全体を提供していた頃は、これで十分だと考えられていました。しかし、多層マイクロサービスとネットワーク相互接続の時代においては、1つのデータソースだけを見ていては全体像を把握できません。

例えば、データベースの実行が遅い場合、データベースの低速クエリのログを分析することだけが解決策ではないかもしれません。ほとんどのシステムは、フロントエンド、ミドルウェア、データベースの順に階層化されています。基盤となるサーバーとストレージサブシステムから生成されたログ、および名前解決のパフォーマンスとネットワークも調べる必要がある可能性があります。

分散コンポーネント全体でのログ収集の必要性

そのため、分散システムで実際に何が起こっているのかを理解するには、ネットワーク全体で記録されたすべてのイベントをリアルタイムで収集するしかありません。これには、次のログが含まれます。

• サーバーインフラストラクチャ
• ストレージ
• データベース
• APIゲートウェイ
• ロードバランサー
• ファイアウォール
• その他

問題のトラブルシューティングを行う場合、複数のログソースからのイベントを関連付ける必要があることが多いため、アプリケーションの動作に関与するすべてのコンポーネントからログをキャプチャする必要があります。

毎日手動でログインして、数百行（あるいは数千行）のログを読み取るためだけに複数（おそらくは数十）のインフラストラクチャコンポーネントにアクセスするのは、対処不可能なほど面倒な作業です。このアプローチは時間の浪費であり、いずれかの時点で重要なイベントを見逃してしまうことはほぼ確実です。しかしそれでも、これらのログを無視するわけにはいきません。

したがって、唯一の実用的な解決策は、すべてのシステムに自動的に接続してログをリアルタイムで収集し、魅力的でわかりやすいインターフェースに表示できるソリューションを1つの画面にまとめることです。集中ロギングの利点をいくつか見ていきましょう。

集中ロギングの利点

複数のログ形式の処理

多層システムでは、さまざまな形式のログが生成される可能性があります。例えば、Linuxシステムではrsyslogやjournaldが使用されますが、Windowsではイベントログが使用されます。一方、データベース、ファイアウォール、SANシステムなどの他のシステムでは、独自の形式が使用される場合があります。

効率的な中央ストレージ

しかし、システムにテラバイト単位のログが蓄積されるのは珍しいことではありません。これにより、ストレージデバイスがすぐにオーバーランし、システムの整合性が脅かされ、アプリケーションのパフォーマンスオーバーヘッドが大幅に増加する可能性があります。

最新のログ管理ソリューションでは、ストレージの効率と保持期間を定義する圧縮アルゴリズムを使用して、取り込まれたログをフィルタリングすることができます。取り込まれたすべてのログは中央の場所に保存されるため、サーバーはログのコピーをローテーションしてローカルストレージ容量を節約することができます。集中ロギングシステムでは、通常、ログが独自の圧縮形式で保存されますが、ログを保持する期間を設定することもできます。

すべてのログの検索クエリの高速化

集中ロギングシステムでは、何千行ものイベントを対象に特定の情報を検索したり、情報の抽出や要約を迅速かつ効率的に行ったりすることもできます。取り込みのレイテンシーが最小限に抑えられ、お客様はクエリを実行して数秒以内に検索結果を取得することができます。

イベント相関

同様に、最新の集中ロギングシステムでは、ログに記録されたイベントに情報を追加して強化できます。人工知能を使用して、一見バラバラに見える情報が相互に関連付けられます。イベント相関とは、2つ以上の関連するイベントを結び付けて問題を特定し、根本原因を追跡する機能です。このようなプラットフォームでは、ダッシュボードやチャートに傾向や異常が表示されます。重要な傾向、異常、イベント相関が特定されたときにアラートを出すよう設定することもできます。

集中ロギングシステムのレポートとダッシュボードは、予算編成、キャパシティプランニング、パフォーマンスベンチマークなどの二次的な目的にも使用できます。

セキュリティ分析

高度な集中ログ管理は、セキュリティ情報およびイベント管理 (SIEM) またはセキュリティのオーケストレーション、自動化と対応 (SOAR) を介した効果的なサイバーセキュリティ制御を行うためにも極めて重要です。また、SIEMおよびSOARソリューションに関連するコストを削減できるのも利点です。最新のログ管理と連携して運用でき、お客様はわずかなコストでより長い保持期間とストレージを実現できます。

集中ロギングの仕組み

分散ロギングプロセスと集中ロギングプロセスはどちらも、次の4つのステップで構成されます。

1. 収集
2. 処理
3. インデックス作成
4. 可視化

これらの各ステップを詳しく見ていきましょう。

収集

ログ分析の最初のステップは、すべてのログを収集し、必要なときにアクセスして分析できる安全な場所にまとめて保存することです。

このステップでは、ソースシステムとロギングアプリケーションとの統合が必要です。統合は、ソースサーバー上で実行されているエージェントによって実現できます。エージェントがサーバーログを読み取って、特定のポートの集中ロギングプラットフォームに送信します。

統合は、ネイティブな方法によっても実現できます。例えば、サーバーのSyslogデーモンがログデータを直接ロギングサーバーに送信するように設定されている場合があります。クラウドホスト型サービスの場合、統合では、クラウドサービスのロギング環境（AWS CloudWatchやAzure Monitorなど）への接続と、イベントの読み取りが行われる場合があります。

処理

この次のステップは処理です。収集されたすべての未加工ログデータが使いやすい形式に変換されます。変換では、ログに記録されたイベントの解析や、日付/時刻、ソースIP、ユーザー名、アプリケーション名、イベントメッセージなどの特定のフィールドの抽出が行われる場合があります。

処理では、ロギング情報を強化するためのステップが行われる場合もあります。例えば、IPアドレスを含むログは、その位置情報を検索し、その情報をイベントストリームに追加することで強化できます。同様に、異なるログのタイムスタンプを共通のタイムゾーンに変換することもできます。

別の処理ステップで、不要なレコードをフィルタで除外し、残りのレコードを圧縮することもできます。

インデックス作成

インデックス作成ステップは、ログに記録されたすべてのイベントの処理の完了後、ロギングプラットフォームがイベントにインデックスを付ける内部プロセスです。これは、フルテキストインデックスやデータベースインデックスの作成とよく似ています。このインデックスは、ログの検索速度を最適化するために使用できます。

ログに記録されたイベントにインデックスが付けられると、検索とフィルタリングができるようになります。

可視化

このステップでは、集中ロギングシステムで組み込みおよびカスタムのチャートとダッシュボードすべてが更新およびリフレッシュされ、システムの新たなイメージが生成されます。

ここで説明した4つのステップはそれぞれに性質が異なりますが、同時にリアルタイムで行われることもあります。つまり、1分前に取り込まれたイベントから作成されたトレンドグラフを見ている間に、システムによって取り込まれた新しいデータの収集、処理、インデックス作成が行われ、視覚化チャートが動的に更新されている可能性があります。

集中ロギングのベストプラクティス

これ自体がトピックではありますが、企業に集中ロギングシステムを採用する際に組み込むべきいくつかのベストプラクティスを以下に紹介します。

チームを巻き込む

まず、プラットフォームを使用するチームと人を巻き込みます。開発者、DevOpsチーム、SecOpsチームなどがその対象となります。

収集するデータの決定

モニタリングの目的に最も重要なログは何か、およびそのログからどのようなイベントをキャプチャするかを計画する必要があります。例えば、関心があるのはファイアウォールログの接続拒否イベントのみかもしれません。さらに、次の詳細を考慮します。

• ログの保持期間をどのくらいにするか？
• タイムスタンプの正規化にどの共通タイムゾーンを使用するか？
• どのような共通情報フィールドを利用できるようにするか？

出力ニーズの明確化

次に、ログの出力タイプを決定します。リアルタイムの異常か、過去の傾向か、それともセキュリティイベントアラートのみのログを使用するかを考慮します。

すべてのソースシステムに統合が存在するかの確認

世の中には数多くのログ管理ソリューションが存在します。オンプレミスホスティングに最適なものもあれば、SaaSベースのものもあります。それぞれに長所と短所があります。プラットフォームは考慮事項ですが、選択するソリューションには、モニタリング対象のすべてのソースシステムの（ネイティブまたはコミュニティプラグイン経由の）統合があることも必要です。

コンプライアンス要件に留意

SaaSソリューションの場合は、規制上の制限がないか確認してください。海外のデータセンターにログを保存することを禁止している規制もあります。同様に、ログの機密情報を編集または暗号化することが義務付けられている業界標準もあります。

次世代SIEMおよびログ管理のための世界をリードするAIネイティブプラットフォームをお試しください

SIEMとログ管理ための最高水準のAIネイティブプラットフォーム、CrowdStrike Falcon®プラットフォームでサイバーセキュリティを強化しましょう。ペタバイト規模でのセキュリティログを体験してみてください。クラウドネイティブ型または自己ホスト型での展開が可能です。ボトルネックの生じない、強力でインデックスフリーのアーキテクチャを利用してデータをロギングすれば、1日あたり1PB以上のデータを取り込んで脅威ハンティングに役立てることができます。リアルタイムの検索機能により攻撃者をしのぐスピードで対策を実施できます。複雑なクエリを実行しても、そのレイテンシーは1秒未満です。360度の可視性によりデータを統合してサイロ化を解消し、セキュリティ、IT、DevOpsチームがシームレスに脅威のハンティング、パフォーマンスのモニタリング、コンプライアンスの確保を行うことができます。30億件ものイベントにわたる作業でも1秒未満で実施できます。