取り込み量を最適化する

以下でサポートされています。

このガイドでは、Google Security Operations のデータ処理パイプラインを構成して、取り込み量を最適化する方法について説明します。この機能を使用すると、ソースに関係なく、データが完全に取り込まれる前に、データをフィルタ、変換、削除できます。この方法により、データ品質と脅威検出の効率が向上します。

このガイドは、Google SecOps へのログの取り込みを管理するセキュリティ エンジニア、Google SecOps アナリスト、クラウド管理者を対象としています。

フィルタリングされていない大量のログを取り込むと、予算とリソースに負担がかかる可能性があります。費用が増加し、検索と分析の機能が低下し、セキュリティ アナリストが大量の無関係なデータの中から重要なアラートを見逃す可能性が高くなります。費用対効果が高く効率的な Google SecOps デプロイメントを実現するには、効果的なフィルタリングが不可欠です。

始める前に

次のことを確認してください。

  • Identity and Access Management（IAM）ロール: 事前定義の Chronicle API Admin ロール（roles/chronicle.admin）または次のいずれかの権限を含むカスタムロール。
    • chronicle.logProcessingPipelines.*
    • chronicle.logTypes.get
    • chronicle.logTypes.list
    • chronicle.feeds.get
    • chronicle.feeds.list
    • chronicle.logs.list
  • Bindplane のバージョン: Bindplane Server コンソール バージョン 1.96.4 以降が必要です。
  • Bindplane Cloud では、認証に Workload Identity 連携（WIF）がサポートされています。セルフホスト型の Bindplane デプロイメントには、サービス アカウントの JSON 鍵認証情報が必要です。
  • プロセッサ ノードを構成するには、Bindplane 管理コンソールまたは Google SecOps Data Pipeline API のいずれかにアクセスします。
  • ボリューム削減のためにフィルタ、変換、削除プロセッサを構成するために必要な正確なフィールド、ログタイプ、条件を特定します。
  • 取り込み方法に関連付けられた特定のログタイプ、コレクタ ID（Bindplane ソースの場合）、フィード名（データフィードの場合）を照合して、パイプライン ストリームの入力を定義します。
  • ログを取り込む Google Cloud 場合は、必要な Logging エクスポート フィルタを定義して、データが SecOps パイプラインに到達する前にアップストリーム フィルタリングを実装し、費用を最大限に削減します。
  • ログデータを理解する:
    • ボリュームが多いログや価値の低いログを特定する: 現在の取り込み指標を分析して、ボリュームと費用に最も影響しているログタイプとソースを特定します。詳細については、取り込み指標の概要をご覧ください。
    • フィルタリング条件を決定する: 削除、変換、削除するログを確実に識別する特定のフィールド、値、パターン（正規表現）、条件を決定します。
    • 取り込み方法を把握する: 各ターゲット ログソースがどのように取り込まれるか（直接、Bindplane、フィード、API）を理解します。これは、パイプライン ストリームの構成方法に影響します。

主な用語

  • データ処理パイプライン: ログデータが保存およびインデックス登録される前に、ログデータをフィルタ、変換、削除するために使用される機能。
  • フィルタ/フィルタリング: ボリューム最適化の主要な機能。セキュリティ分析に不要なイベントを選択的に削除する条件を定義します。
  • 変換: ログ形式を変更してユーザビリティを向上させるために使用される機能。たとえば、完全修飾ドメイン名（FQDN）を削除したり、イベント内の詳細フィールドを削除したりします。
  • Redact: ログが保存される前にログから機密情報をマスクまたは完全に削除する機能。コンプライアンスとプライバシーに役立ちます。
  • Bindplane エージェント: オンプレミス システムまたは他のクラウド システムから収集されたログの取り込み方法。
  • フィード: Cloud Storage、Amazon S3、サードパーティ API などのソースから取り込まれたデータの取り込み方法。
  • Ingestion API: カスタムログデータを送信する方法。データ処理パイプラインを使用したサーバーサイド フィルタリングが可能です。
  • アップストリーム フィルタリング: Logging エクスポート フィルタを使用してソースで Google Cloud ログをフィルタリングし、費用を最適化する推奨ベスト プラクティス。
  • ストリーム: ログタイプと取り込みソース（フィードや API など）によって定義される特定のデータフロー。データ処理パイプラインへの入力として機能します。
  • プロセッサ ノード: データを順番に操作する 1 つ以上のプロセッサ（フィルタ、変換、削除アクション）を含むパイプライン内のコンポーネント。
  • 宛先: データ処理パイプラインのエンドポイント。通常は、処理されたデータが最終的な取り込みと分析のために送信される Google SecOps インスタンス。

最適化にデータ処理パイプラインを使用する

Google SecOps のデータ処理パイプラインを使用すると、データの取り込みプロセスを事前に解析して強力に制御できます。ログが保存およびインデックス登録される前に、ログに適用されるルールとアクションを定義できます。詳細については、データ処理パイプラインを設定して管理するをご覧ください。

主な機能

  • フィルタ: これは、ボリューム最適化の主な焦点です。元のログコンテンツ、属性、正規表現を使用して条件を定義し、セキュリティ分析に不要なイベントを選択的に削除できます。これは、ノイズと費用を削減するための鍵となります。
  • 変換: ログ形式を変更してユーザビリティを向上させるか、イベント内の不要なデータを削除します。たとえば、ホスト名から FQDN を削除する、JSON ペイロードを解析して再構築する、詳細だが無関係なフィールドを削除するなどがあります。
  • 削除: ログが保存される前に、個人を特定できる情報（PII）などの機密情報をログからマスクまたは完全に削除します。これにより、コンプライアンスとプライバシー要件を満たすことができます。

普遍的な適用性

データ処理パイプラインの主な利点は、任意の取り込み方法のデータに適用できることです。これにより、次のものに対して一貫したフィルタリング レイヤが提供されます。

  • Google Cloud 組み込みログ
  • Bindplane エージェントを使用して収集されたログ
  • フィード経由で取り込まれたデータ
  • Ingestion API を介して送信されたカスタムログ

詳細については、このガイドのメソッド固有のフィルタリング戦略をご覧ください。

データ処理パイプラインでフィルタリングを実装する

ステップ 1: パイプラインを設定する

データ処理パイプラインは、Bindplane 管理コンソールまたは公開 Google SecOps Data Pipeline API を使用して構成および管理できます。ストリーム（入力）を定義し、プロセッサ ノード（フィルタ、変換、削除）を構成して、パイプラインのデプロイを管理できます。

設定手順の詳細については、データ処理パイプラインを設定して管理するをご覧ください。

ステップ 2: フィルタリング用のプロセッサを構成する

パイプライン内で、ノードにプロセッサを追加できます。ボリュームを削減するには、主にフィルタ プロセッサを使用する必要があります。これらのプロセッサを構成して、条件または正規表現に基づいてログを削除できます。OTTL（OpenTelemetry Transformation Language）構文を使用して、カスタム パイプラインの条件とステートメントを構成します。

  • 条件: ログデータのフィールドまたは属性を評価します。
  • 正規表現: 元のログメッセージ内のパターンを照合します。
  • [OTTL の例]: ステートメントの例は set(attributes["labels.myLabel.value"], "myValue") です。

フィルタリングは重要ですが、変換プロセッサを使用して、保持するログから不要な大きなフィールドを削除し、削除プロセッサを使用して機密データを無効にすることもできます。

ステップ 3: メソッド固有のフィルタリング戦略

次のセクションでは、主な取り込みタイプごとに、データ処理パイプラインを使用したフィルタリングのアプローチについて説明します。

Google Cloud ログ

  • アップストリーム フィルタリング（推奨ベスト プラクティス）: 費用を最適化するには、Cloud Logging エクスポート フィルタを使用してソースで Google Cloud ログをフィルタリングすることをおすすめします。これにより、不要なログが Google SecOps に送信されるのを防ぐことができます。必要に応じて、データ処理パイプラインを追加のフィルタリングに使用できます。詳細については、データを取り込む Google Cloud ガイドの「エクスポート フィルタの設定をカスタマイズする」をご覧ください。

  • パイプライン アプリケーション: 適切な Google Cloud ログタイプと取り込み方法（直接 または クラウドネイティブ ）を選択して、データ処理パイプラインを構成します。コンテンツに基づいて不要なログを削除するフィルタ プロセッサを定義します。

Bindplane エージェント

Bindplane エージェントによってオンプレミス システムまたは他のクラウド システムから収集されたログは、データ処理パイプラインを使用してフィルタできます。Bindplane ソースに関連付けられたログタイプとコレクタ ID に一致するようにストリームを構成します。詳細については、Google SecOps で Bindplane を使用するをご覧ください。

データフィード

フィード（Cloud Storage、Amazon S3、サードパーティ API など）を使用して取り込まれたデータの場合、パイプライン ストリームを構成するときにフィード名とログタイプを選択して、データ処理パイプライン フィルタを適用できます。詳細については、フィードを操作するガイドをご覧ください。

Chronicle API の取り込み方法

Chronicle API の取り込み方法を使用してデータを送信する場合でも、データ処理パイプラインを活用できます。API 呼び出しで使用するログタイプに一致するようにパイプライン ストリームを構成します。これにより、カスタムログ ストリームのサーバーサイド フィルタリングが可能になります。詳細については、Chronicle API の取り込み方法ガイドをご覧ください。

ベスト プラクティス

  • 可能な限りアップストリームでフィルタする: Google Cloudで説明したように、ログは可能な限りソースに近い場所でフィルタしてください。これにより、データ転送と処理のオーバーヘッドが削減されるため、最も費用対効果の高い方法となります。
  • 具体的にする: 既知のボリュームが多く価値の低いログを除外するために、狭く明確に定義されたフィルタから始めます。有用なデータを誤って削除する可能性のある、過度に広範なフィルタは避けてください。
  • 反復して改善する: フィルタの効果を定期的に確認します。適切なイベントをキャッチしていますか？フィルタリングする必要がある新しいノイズはありますか？
  • フィルタを文書化する: 特に複雑な正規表現や条件ロジックの場合は、どのようなフィルタが設定されているか、その理由を記録しておきます。

検証とテスト

  • テスト: 最初に非本番環境またはデータの小さなサブセットでフィルタをテストする必要があります。
  • フィルタを検証する: Bindplane コンソールのパイプライン エディタ内のテスト機能を使用します。これにより、サンプルログを入力して、プロセッサの適用後の出力を確認し、フィルタが期待どおりに機能することを確認できます。
  • 取り込みをモニタリングする: パイプラインをデプロイしたら、Google SecOps の取り込みダッシュボードをモニタリングして、データ量と費用への影響を確認します。詳細については、取り込み指標の概要をご覧ください。
  • 構成を表示する: すべての構成は、Google SecOps UI の [SIEM 設定 > データ処理] で確認できます。
  • 外部管理: 構成を検索して [Bindplane で開く] をクリックすると、Bindplane コンソールに直接移動して詳細な管理を行うことができます。

制限事項

  • サービス上限: 過度に複雑な正規表現や、パイプラインあたりのプロセッサの数が多すぎると、パフォーマンスに影響したり、上限が適用されたりする可能性があります。サービス上限で Google SecOps の上限を確認する必要があります。
  • Google SecOps パッケージ: Google SecOps パッケージの機能と機能を確認してください。詳細については、Google SecOps パッケージをご覧ください。
  • 再利用性: 強力な機能ですが、1 つのログタイプまたはソースのパイプライン構成は、調整なしで別のログタイプまたはソースに直接再利用できない場合があります。
  • 最大プロセッサ数: パイプラインごとに最大 10 個のプロセッサを定義します。
  • 正規表現のパフォーマンス: 正規表現のマッチングが多すぎると、タイムアウトが原因でパイプラインの作成またはデプロイに失敗する可能性があるため、避けてください。データを JSON に解析して、特定のフィールドでフィルタすることをおすすめします。
  • ストリーム関連付けの制約: 同じログタイプの異なるフィードに対して異なるパイプラインを作成できますが、まったく同じストリーム定義（同じフィードや同じログタイプのキャッチオールなど）を複数のアクティブなパイプラインに関連付けることはできません。ログタイプを [すべての取り込み方法] に設定すると、キャッチオールとして機能し、そのログタイプの特定のフィードに対して他のパイプラインを構成できなくなります。

さらにサポートが必要な場合コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。