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

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

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

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

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

以降のセクションでは、クエリでフィルタとして使用する高パフォーマンスの UDM フィールドについて説明します。

メタデータの項目

  • metadata.event_timestamp.seconds
  • metadata.event_type
  • metadata.log_type
  • metadata.product_event_type
  • metadata.product_name
  • metadata.vendor_name

プリンシパル フィールド

  • principal.application
  • principal.asset_id
  • 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.pid
  • principal.user.email_addresses
  • principal.user.userid

マッピング元の項目

  • src.asset_id
  • src.hostname
  • src.ip
  • src.mac
  • src.user.userid

マッピング先の項目

  • target.application
  • target.asset_id
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.mac
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.employee_id
  • target.user.userid
  • target.user.windows_sid

ネットワーク フィールド

  • network.dhcp.chaddr
  • network.dhcp.ciaddr
  • network.dhcp.client_hostname
  • network.dhcp.yiaddr
  • network.dns.answers.class
  • network.dns.answers.name
  • network.dns.answers.type
  • network.dns.questions.class
  • network.dns.questions.name
  • network.dns.questions.type
  • network.email.from
  • network.email.to
  • network.http.method

セキュリティ結果フィールド

  • security_result.action
  • security_result.category
  • security_result.rule_name

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

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 など）が繰り返しとしてラベル付けされています。これは、1 つのイベント内に値またはメッセージ タイプのリストを保持できるためです。繰り返しフィールドは、デフォルトで常に 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 のプロフェッショナルから回答を得ることができます。