検索のベスト プラクティス

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

このドキュメントでは、Google Security Operations の検索機能を使用する際の Google が推奨するベスト プラクティスについて説明します。検索を工夫しないと、大量の計算リソースが必要になることがあります。また、Google SecOps インスタンス内のデータのサイズや複雑さによってパフォーマンスも変わります。

クエリで特定のフィルタを使用して、速度とパフォーマンスを最大化する

検索パフォーマンスを向上させる最も効果的な方法は、特定の最適化された統合データモデル（UDM）フィールドを使用してクエリを作成することです。これらのフィールドは高速取得用に最適化されているため、検索が高速で実行され、使用するコンピューティング リソースが少なくなります。

以降のセクションでは、クエリでフィルタとして使用する高パフォーマンスの UDM フィールドを一覧表示します。

プリンシパル フィールド

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sid

マッピング元の項目

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

マッピング先の項目

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

その他のフィールド

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

エンティティ データとコンテキスト データをクエリする方法

metadata.log_type = "<LOG_TYPE>" を使用してエンティティまたはコンテキストのログタイプ（AZURE_AD_CONTEXT や WORKSPACE_USERS など）を検索すると、未加工ログが未加工ログ検索に表示されていても、検索結果は返されません。これは、UDM 検索が UDM イベント レコードのみをクエリするためです。

エンティティとコンテキスト データを検索するには、graph 構文を使用します。

  • エンティティまたはコンテキストのログタイプを検索するには、graph メタデータ フィールドをクエリします。次に例を示します。

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • エンティティ フィールドを検索するには、接頭辞 graph.entity.noun.field を使用します。次に例を示します。

    graph.entity.user.email_addresses = "foo_email"

詳細については、エンティティ コンテキスト データの検索を行うをご覧ください。

パフォーマンスを向上させる効果的な検索クエリを作成する

最適化されたクエリを作成することは、セキュリティ データ全体で速度を最大化し、リソース消費を最小限に抑えるための鍵となります。すべてのクエリ条件は、この基本構造に厳密に準拠する必要があります。

udm-field operator value

次に例を示します。principal.hostname = "win-server"

Google SecOps は検索中に大量のデータを取り込む可能性があるため、対象期間を短くしてクエリの範囲を絞り込むことで、検索のパフォーマンスを高めることができます。

検索クエリで正規表現を使用する

UDM 検索クエリを作成するときに標準の論理演算子と比較演算子を使用して、複雑な式を作成できます。

  • 論理演算子: AND、OR、NOT を使用して条件を結合します。2 つの条件の間の演算子を省略すると、AND とみなされます。
  • 演算子の優先順位: 括弧（）を使用して、デフォルトの優先順位をオーバーライドします。かっこ内で使用できる論理演算子（OR、AND、NOT）の最大数は 169 個です。
  • 比較演算子: UDM フィールドの型（文字列、整数、タイムスタンプ）に応じて、フィールド演算子には =、!=、>=、>、<、<= などがあります。

Google SecOps は RE2 正規表現エンジンを使用します。

大規模な値のセットを効率的に検索するには、参照リストを使用することもできます。

検索修飾子として nocase を使用する

文字列比較条件に nocase 修飾子を追加すると、大文字と小文字が区別されず、大文字と小文字が無視されます。

たとえば、次の検索では大文字と小文字が区別されず、大文字と小文字に関係なく tim.smith を含むすべての組み合わせが一致します。

target.user.userid = "TIM.SMITH" nocase

列挙型フィールドで正規表現を使用しない

列挙型フィールド（事前定義された値の範囲を持つフィールド）を検索する際に、metadata.event_type や network.ip_protocol などの正規表現を使用することはできません。

次の例は無効な検索です。 metadata.event_type = /NETWORK_*/

一方、次の例は有効な検索です。 (metadata.event_type = "NETWORK_CONNECTION" または metadata.event_type = "NETWORK_DHCP")

Events フィールドであらゆるすべての演算子を使用する

検索では、一部の UDM フィールド（principal.ip や target.file.md5 など）が繰り返しとしてラベル付けされています。これは、単一のイベント内で値またはメッセージ タイプのリストを保持できるためです。繰り返しフィールドは、デフォルトで常に any 演算子として扱われます（all を指定するオプションはありません）。

any 演算子を使用すると、繰り返しフィールドの値のいずれかが条件を満たした場合に、述語が true と評価されます。たとえば、principal.ip != "1.2.3.4" という検索をした場合、検索結果のイベントに principal.ip = "1.2.3.4" と principal.ip = "5.6.7.8" の両方が含まれていても、一致が生成されます。これにより、すべての演算子に一致するのではなく、いずれかの演算子に一致する結果も含まれるように検索が拡張されます。

繰り返しフィールドの各要素は個別に処理されます。検索対象のイベントに繰り返しフィールドが含まれている場合、そのイベントはフィールド内の各要素ごとに評価されます。これは予期せぬ挙動を引き起こすことがあります。特に != 演算子で検索する場合に注意が必要です。

any 演算子を使用すると、繰り返しフィールドの値のいずれかが条件を満たした場合に、述語が true と評価されます。

タイムスタンプに Unix エポック時刻を使用するか、日付変換に YARA-L 関数を使用する

タイムスタンプ フィールドは、Unix エポック時刻（1970 年 1 月 1 日木曜日の 00:00:00 UTC からの経過秒数の合計）を使用して照合されます。また、日付変換に YARA-L 関数を使用することもできます。

特定のタイムスタンプを検索する場合、次の形式（エポック時刻）が有効です。

metadata.ingested_timestamp.seconds = 1660784400

次のタイムスタンプは無効です。

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

特定のタイムスタンプを検索する場合、次の形式（日付変換に YARA-L 関数を使用）が有効です。

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

次の YARA-L の例では、timestamp 関数を使用して取り込み時間範囲を確認します。

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

古いタイムスタンプで新しく取り込まれたデータをクエリする方法

クエリするイベントの期間を指定しない限り、タイムスタンプが古い新しく取り込まれたイベントを検索することはできません。これは、期間の範囲が未加工ログイベントの取り込みタイムスタンプではなく、解析されたイベントのタイムスタンプに基づいているためです。

古いイベント タイムスタンプを含む取り込まれたログの UDM イベントを検索するには、[すべての期間] オプションを使用して metadata.ingested_timestamp を検索してクエリを実行します。

フィルタから除外されたフィールド

次のフィールドは、検索フィルタから意図的に除外されています。

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

これらのフィールドには重要なメタデータが含まれていますが、一意の値によって統計情報のカーディナリティと分散が高くなり、検索パフォーマンスに悪影響を及ぼします。

トラブルシューティング

「エラー: 検索でエラーが発生し、データを読み込めませんでした」などの一般的なエラー メッセージが表示された場合は、次の手順に沿って問題を解決してください。エラーが解消されない場合は、カスタマーサポートにお問い合わせください。

  • 別のネットワークから Google SecOps に接続します。たとえば、クラウド VM を使用してネットワークの問題を特定します。
  • 組織のファイアウォール、プロキシ構成、またはポリシーで Chronicle API 呼び出しが許可されていることを確認します。
  • 検索では大きなデータセットが返される可能性があるため、Search API 呼び出しにデータ上限が設定されていないことを確認します。
  • 検索クエリは非同期で実行されるため、データの返信に時間がかかることがあります。以前に実行した検索は検索履歴で確認でき、選択して後で結果を表示できます。

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