取り込み量を最適化する

このガイドでは、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 Management Console または Google SecOps Data Pipeline API へのアクセス権。
  • ボリューム削減のために Filter、Transform、Redact プロセッサを構成するために必要な正確なフィールド、ログタイプ、条件を特定します。
  • 取り込み方法に関連付けられている特定のログタイプ、コレクタ ID（Bindplane ソースの場合）、またはフィード名（データフィードの場合）を照合して、パイプライン ストリームの入力を定義します。
  • Google Cloud ログを取り込む場合は、必要な Logging エクスポート フィルタを定義して、データが SecOps パイプラインに到達する前に、コストを最大限に削減するためのアップストリーム フィルタリングを実装します。
  • ログデータを理解する:
    • 大量のログまたは価値の低いログを特定する: 現在の取り込み指標を分析して、ボリュームと費用に最も大きく影響しているログタイプとソースを特定します。詳細については、取り込み指標の概要をご覧ください。
    • フィルタリング条件を決定する: 削除、変換、または編集するログを確実に識別する特定のフィールド、値、パターン（正規表現）、または条件を決定します。
    • 取り込み方法を把握する: 各ターゲット ログソースがどのように取り込まれるか（直接、Bindplane、フィード、API）を把握します。これは、パイプライン ストリームの構成方法に影響します。

主な用語

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

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

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

主な機能

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

普遍的な適用性

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

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

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

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

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

データ処理パイプラインは、Bindplane Management Console または一般公開されている Google SecOps Data Pipeline API を使用して構成および管理できます。これらを使用すると、ストリーム（入力）を定義し、プロセッサノード（フィルタ、変換、編集）を構成して、パイプラインのデプロイを管理できます。

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

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

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

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

フィルタリングは重要ですが、変換プロセッサを使用して、保持するログから不要な大きなフィールドを削除し、秘匿化プロセッサを使用してセンシティブ データを null にすることも検討してください。

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

以降のセクションでは、主な取り込みタイプごとに、データ処理パイプラインでフィルタリングを行う方法について説明します。

Google Cloud ログ

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

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

Bindplane エージェント

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

データフィード

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

Chronicle API の取り込み方法

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

ベスト プラクティス

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

検証とテスト

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

制限事項

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

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