Custom Security Data Analytics ログを収集する
このドキュメントでは、複数の取り込み方法を使用してカスタム セキュリティ分析データを Google Security Operations に取り込む方法について説明します。このガイドは、事前構築済みパーサーまたはログタイプがないカスタム セキュリティ データソースを対象としています。
カスタム セキュリティ データ分析には、独自のセキュリティ テレメトリー、カスタム アプリケーション ログ、内部セキュリティ ツール、または Google SecOps とネイティブに統合されていないソースからのセキュリティ関連データが含まれます。このデータは非構造化ログとして取り込み、必要に応じてカスタム パーサーを使用して正規化できます。
始める前に
次の前提条件を満たしていることを確認してください。
- Google SecOps インスタンス
- JSON、CSV、SYSLOG、その他の構造化形式でログをエクスポートできるカスタム セキュリティ データソース
- 次のいずれかへのアクセス権があること。
- Google Cloud コンソール(API キーの作成と GCS 用)
- AWS コンソール(S3 または Firehose の場合)
- Azure Portal(Azure Blob Storage の場合)
- Webhook リクエストを送信できる HTTP クライアントまたはアプリケーション
- Google SecOps でフィードを作成、管理する権限
取り込み方法を選択する
Google SecOps は、カスタム セキュリティ データの複数の取り込み方法をサポートしています。データソースの機能に最も適した方法を選択します。
| 取り込み方法 | ユースケース | レイテンシ | 設定の難易度 |
|---|---|---|---|
| Webhook | アプリケーションからのリアルタイム プッシュ | 秒 | 低 |
| Amazon S3 V2 | S3 バケットへのバッチ エクスポート | 数分から数時間 | 中 |
| Google Cloud Storage V2 | GCS バケットへのバッチ エクスポート | 数分から数時間 | 中 |
| Azure Blob Storage V2 | Azure ストレージへのバッチ エクスポート | 数分から数時間 | 中 |
| Amazon Data Firehose | AWS からのリアルタイム ストリーミング | 秒 | 高 |
オプション 1: Webhook 取り込み(リアルタイム プッシュ)
カスタム セキュリティ アプリケーションが外部エンドポイントに HTTP POST リクエストを送信できる場合は、このメソッドを使用します。
Google SecOps で Webhook フィードを作成する
フィードを作成する
- [SIEM 設定] > [フィード] に移動します。
- [Add New Feed] をクリックします。
- 次のページで [単一フィードを設定] をクリックします。
- [フィード名] フィールドに、フィードの名前を入力します(例:
custom-security-analytics-webhook)。 - [Source type] として [Webhook] を選択します。
- [ログタイプ] として [カスタム セキュリティ データ分析] を選択します。
- [次へ] をクリックします。
- 次の入力パラメータの値を指定します。
- 分割区切り文字: 省略可: 複数行のイベントを分割する区切り文字を入力します。一般的な値:
\n- 改行区切り文字(NDJSON で最も一般的)- 各リクエストに単一のイベントが含まれている場合は、空のままにします
- アセットの名前空間: アセットの名前空間
- Ingestion labels: このフィードのイベントに適用されるラベル
- 分割区切り文字: 省略可: 複数行のイベントを分割する区切り文字を入力します。一般的な値:
- [次へ] をクリックします。
- [Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
秘密鍵を生成して保存する
フィードを作成したら、認証用のシークレット キーを生成する必要があります。
- フィードの詳細ページで、[シークレット キーを生成] をクリックします。
- ダイアログに秘密鍵が表示されます。
秘密鍵をコピーして安全に保存します。
フィード エンドポイントの URL を取得する
- フィードの [詳細] タブに移動します。
- [エンドポイント情報] セクションで、[フィード エンドポイント URL] をコピーします。
URL の形式は次のとおりです。
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreateまたは
https://<REGION>-malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate次の手順で使用するため、この URL を保存します。
[完了] をクリックします。
Google Cloud API キーを作成する
Google SecOps では、認証に API キーが必要です。Google Cloud コンソールで制限付き API キーを作成します。
API キーを作成する
- Google Cloud コンソールの [認証情報] ページに移動します。
- プロジェクト(Chronicle インスタンスに関連付けられているプロジェクト)を選択します。
- [認証情報を作成> API キー] をクリックします。
- API キーが作成され、ダイアログに表示されます。
- [API キーを編集] をクリックして、キーを制限します。
API キーを制限する
- [API キー] 設定ページで、次の操作を行います。
- 名前: わかりやすい名前を入力します(例:
Chronicle Webhook API Key)。
- 名前: わかりやすい名前を入力します(例:
- [API の制限] で次の操作を行います。
- [キーを制限] を選択します。
- [API を選択] プルダウンで、[Google SecOps API](または [Chronicle API])を検索して選択します。
- [保存] をクリックします。
- ページ上部の [API キー] フィールドから API キーの値をコピーします。
API キーを安全に保存します。
データを送信するようにカスタム アプリケーションを構成する
Chronicle Webhook エンドポイントに HTTP POST リクエストを送信するように、カスタム セキュリティ アプリケーションまたはスクリプトを構成します。
Webhook URL を作成します。
Chronicle エンドポイント URL と API キーを組み合わせます。
<ENDPOINT_URL>?key=<API_KEY>例:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...
HTTP リクエストの形式:
メソッド: POST
URL:
<ENDPOINT_URL>?key=<API_KEY>ヘッダー:
Content-Type: application/json x-chronicle-auth: <SECRET_KEY>本文(単一イベント):
{ "timestamp": "2025-01-15T10:30:00Z", "event_type": "authentication", "user": "john.doe@example.com", "action": "login", "result": "success", "source_ip": "203.0.113.45", "custom_field_1": "value1", "custom_field_2": "value2" }本文(改行区切り文字で複数のイベント):
{"timestamp": "2025-01-15T10:30:00Z", "event_type": "authentication", "action": "login"} {"timestamp": "2025-01-15T10:30:05Z", "event_type": "file_access", "action": "read"} {"timestamp": "2025-01-15T10:30:10Z", "event_type": "authentication", "action": "logout"}
例:
例: Python スクリプト:
import requests import json from datetime import datetime # Configuration ENDPOINT_URL = "https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate" API_KEY = "your-api-key-here" SECRET_KEY = "your-secret-key-here" # Construct full URL url = f"{ENDPOINT_URL}?key={API_KEY}" # Headers headers = { "Content-Type": "application/json", "x-chronicle-auth": SECRET_KEY } # Sample event event = { "timestamp": datetime.utcnow().isoformat() + "Z", "event_type": "custom_security_event", "severity": "high", "source": "custom_security_tool", "message": "Suspicious activity detected", "user": "admin@example.com", "ip_address": "192.168.1.100" } # Send request response = requests.post(url, headers=headers, data=json.dumps(event)) if response.status_code == 200: print("Event sent successfully") else: print(f"Error: {response.status_code} - {response.text}")例: cURL コマンド:
curl -X POST \ "https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=YOUR_API_KEY" \ -H "Content-Type: application/json" \ -H "x-chronicle-auth: YOUR_SECRET_KEY" \ -d '{ "timestamp": "2025-01-15T10:30:00Z", "event_type": "security_alert", "severity": "critical", "source": "custom_tool", "message": "Threat detected" }'
認証方法のリファレンス
Google SecOps webhook フィードは、複数の認証方法をサポートしています。アプリケーションがサポートしている方法を選択します。
方法 1: カスタム ヘッダー(推奨)
アプリケーションがカスタム HTTP ヘッダーをサポートしている場合は、この方法を使用するとセキュリティが強化されます。
リクエストの形式:
POST <ENDPOINT_URL> HTTP/1.1 Content-Type: application/json x-goog-chronicle-auth: <API_KEY> x-chronicle-auth: <SECRET_KEY> { "event": "data", "timestamp": "2025-01-15T10:30:00Z" }メリット:
- API キーとシークレットは URL に表示されません。
- ヘッダーがウェブサーバーのアクセスログに記録されないため、より安全です。
- アプリケーションがサポートしている場合は、この方法をおすすめします。
方法 2: クエリ パラメータ
アプリケーションがカスタム ヘッダーをサポートしていない場合は、認証情報を URL に追加します。
URL 形式:
<ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>例:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...&secret=abcd1234...リクエストの形式:
POST <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY> HTTP/1.1 Content-Type: application/json { "event": "data", "timestamp": "2025-01-15T10:30:00Z" }デメリット:
- 認証情報が URL に表示される。
- 認証情報はウェブサーバーのアクセスログに記録される可能性があります。
- ヘッダーよりも安全性が低い。
方法 3: ハイブリッド(URL + ヘッダー)
一部の構成では、URL に API キーを使用し、ヘッダーにシークレット キーを使用します。
リクエストの形式:
POST <ENDPOINT_URL>?key=<API_KEY> HTTP/1.1 Content-Type: application/json x-chronicle-auth: <SECRET_KEY> { "event": "data", "timestamp": "2025-01-15T10:30:00Z" }
Webhook の上限とベスト プラクティス
リクエストに関する上限
| 上限 | 値 |
|---|---|
| 最大リクエスト サイズ | 4 MB |
| 最大 QPS(秒間クエリ数) | 15,000 |
| リクエストのタイムアウト | 30 秒 |
| 再試行の動作 | 指数バックオフによる自動 |
ベスト プラクティス
- イベントのバッチ処理: 改行区切り JSON(NDJSON)形式を使用して 1 つのリクエストで複数のイベントを送信し、オーバーヘッドを削減します。
- タイムスタンプを含める: 正確なイベント順序付けのために、ISO 8601 形式のタイムスタンプ フィールドを常に含めます。
- 構造化データを使用する: JSON 形式でデータを送信すると、解析やフィールドの抽出が容易になります。
- 再試行ロジックを実装する: 指数バックオフで一時的な障害を処理します。
- レスポンス コードをモニタリングする: 200 以外のレスポンスをロギングしてアラートを送信します。
オプション 2: Amazon S3 V2 取り込み(バッチ エクスポート)
カスタム セキュリティ アプリケーションがログを Amazon S3 バケットにエクスポートできる場合は、この方法を使用します。
Amazon S3 バケットを作成する
- Amazon S3 コンソールを開きます。
- [バケットを作成] をクリックします。
- 次の構成の詳細を入力します。
- バケット名: バケットのわかりやすい名前を入力します(例:
custom-security-analytics-logs)。 - リージョン: 使用する AWS リージョン(
us-east-1など)を選択します。
- バケット名: バケットのわかりやすい名前を入力します(例:
- [作成] をクリックします。
S3 アクセス権を持つ IAM ユーザーを作成する
- IAM コンソールを開きます。
- [ユーザー] > [ユーザーを追加] をクリックします。
- ユーザー名を入力します(例:
chronicle-s3-reader)。 - [プログラムによるアクセス] を選択します。
- [Next: Permissions] をクリックします。
- [既存のポリシーを直接アタッチする] を選択します。
- [AmazonS3FullAccess] を検索して選択します。
- [Next: Tags] をクリックします。
- [次へ: 確認] をクリックします。
- [Create user] をクリックします。
- [.csv ファイルをダウンロード] をクリックして、アクセスキー ID とシークレット アクセスキーを保存します。
- [閉じる] をクリックします。
S3 にエクスポートするようにアプリケーションを構成する
ログファイルを S3 バケットに書き込むようにカスタム セキュリティ アプリケーションを構成します。アプリケーションは次のことを行う必要があります。
- 構造化形式(JSON、CSV、プレーン テキスト)でログを書き込みます。
- 一貫したファイル命名規則を使用します。
- 省略可: ファイルを日付で整理します(例:
logs/2025/01/15/events.json)。 ファイルを完全に書き込みます(部分的な書き込みは避けてください)。
ファイル構造の例:
s3://custom-security-analytics-logs/ ├── security-events/ │ ├── 2025/01/15/ │ │ ├── events-10-00.json │ │ ├── events-11-00.json │ │ └── events-12-00.jsonログファイル形式の例(NDJSON):
{"timestamp": "2025-01-15T10:00:00Z", "event_type": "login", "user": "alice@example.com", "result": "success"} {"timestamp": "2025-01-15T10:05:00Z", "event_type": "file_access", "user": "bob@example.com", "file": "/data/sensitive.txt"} {"timestamp": "2025-01-15T10:10:00Z", "event_type": "logout", "user": "alice@example.com"}
S3 用の Google SecOps フィードを構成する
- [SIEM 設定] > [フィード] に移動します。
- [Add New Feed] をクリックします。
- 次のページで [単一フィードを設定] をクリックします。
- [フィード名] フィールドに、フィードの名前を入力します(例:
custom-security-analytics-s3)。 - [ソースタイプ] として [Amazon S3 V2] を選択します。
- [ログタイプ] として [カスタム セキュリティ データ分析] を選択します。
- [次へ] をクリックします。
次の入力パラメータの値を指定します。
S3 URI: バケット URI(形式:
s3://custom-security-analytics-logs/security-events/)Source deletion option: 必要に応じて削除オプションを選択します。
- なし: 転送後にファイルを削除しません(テストにおすすめ)。
- 転送されたファイルを削除する: 転送が完了した後にファイルを削除します。
- 転送されたファイルと空のディレクトリを削除する: 転送が完了した後にファイルと空のディレクトリを削除します。
ファイルの最大経過日数: 指定した日数以内に変更されたファイルを含めます(デフォルトは 180 日)。
アクセスキー ID: IAM ユーザーのアクセスキーを入力します。
シークレット アクセスキー: IAM ユーザーのシークレット キーを入力します。
アセットの名前空間: アセットの名前空間。
Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
オプション 3: Google Cloud Storage V2 の取り込み(一括エクスポート)
カスタム セキュリティ アプリケーションがログを Google Cloud Storage バケットにエクスポートできる場合は、この方法を使用します。
GCS バケットを作成する
- Google Cloud Console に移動します。
- プロジェクトを選択するか、新しいプロジェクトを作成します。
- ナビゲーション メニューで、[Cloud Storage > バケット] に移動します。
- [バケットを作成] をクリックします。
次の構成情報を提供してください。
設定 値 バケットに名前を付ける グローバルに一意の名前を入力します(例: custom-security-analytics-logs)。ロケーション タイプ ニーズに基づいて選択します(リージョン、デュアルリージョン、マルチリージョン)。 ロケーション ロケーションを選択します(例: us-central1)。ストレージ クラス Standard(アクセス頻度の高いログにおすすめ) アクセス制御 均一(推奨) 保護ツール 省略可: オブジェクトのバージョニングまたは保持ポリシーを有効にする [作成] をクリックします。
GCS にエクスポートするようにアプリケーションを構成する
次のいずれかの方法を使用して、ログファイルを GCS バケットに書き込むようにカスタム セキュリティ アプリケーションを構成します。
- Google Cloud SDK:
gsutilまたはクライアント ライブラリを使用する - サービス アカウント: Storage オブジェクト作成者のロールを持つサービス アカウントを作成します。
署名付き URL: 一時的な書き込みアクセス用の署名付き URL を生成する
gsutil を使用した例:
gsutil cp /path/to/logs/events.json gs://custom-security-analytics-logs/security-events/Python クライアント ライブラリの使用例:
from google.cloud import storage import json # Initialize client client = storage.Client() bucket = client.bucket('custom-security-analytics-logs') # Upload log file blob = bucket.blob('security-events/2025/01/15/events.json') # Write NDJSON data events = [ {"timestamp": "2025-01-15T10:00:00Z", "event_type": "login"}, {"timestamp": "2025-01-15T10:05:00Z", "event_type": "logout"} ] ndjson_data = '\n'.join([json.dumps(event) for event in events]) + '\n' blob.upload_from_string(ndjson_data, content_type='application/x-ndjson')
Google SecOps サービス アカウントを取得する
- [SIEM 設定] > [フィード] に移動します。
- [Add New Feed] をクリックします。
- [単一フィードを設定] をクリックします。
- [フィード名] フィールドに、フィードの名前を入力します(例:
custom-security-analytics-gcs)。 - [ソースタイプ] として [Google Cloud Storage V2] を選択します。
- [ログタイプ] として [カスタム セキュリティ データ分析] を選択します。
- [サービス アカウントを取得する] をクリックします。
一意のサービス アカウント メールアドレスが表示されます(例:)。
chronicle-12345678@chronicle-gcp-prod.iam.gserviceaccount.comこのメールアドレスをコピーして、次のステップで使用します。
IAM 権限を付与
- [Cloud Storage] > [バケット] に移動します。
- バケット名をクリックします。
- [権限] タブに移動します。
- [アクセス権を付与] をクリックします。
- 次の構成の詳細を入力します。
- プリンシパルを追加: Google SecOps サービス アカウントのメールアドレスを貼り付けます。
- ロールを割り当てる: [Storage オブジェクト閲覧者] を選択します。
[保存] をクリックします。
GCS 用に Google SecOps フィードを構成する
- フィード作成ページから続行します(または、[SIEM 設定] > [フィード] > [新しいフィードを追加] に移動します)。
- [次へ] をクリックします。
次の入力パラメータの値を指定します。
ストレージ バケットの URL: 接頭辞パスを含む GCS バケット URI を入力します。
gs://custom-security-analytics-logs/security-events/Source deletion option: 必要に応じて削除オプションを選択します。
- なし: 転送後にファイルを削除しません(テストにおすすめ)。
- 転送されたファイルを削除する: 転送が完了した後にファイルを削除します。
- 転送されたファイルと空のディレクトリを削除する: 転送が完了した後にファイルと空のディレクトリを削除します。
ファイルの最大経過日数: 指定した日数以内に変更されたファイルを含めます(デフォルトは 180 日)。
アセットの名前空間: アセットの名前空間。
Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
オプション 4: Azure Blob Storage V2 の取り込み(バッチ エクスポート)
カスタム セキュリティ アプリケーションがログを Azure Blob Storage にエクスポートできる場合は、この方法を使用します。
Azure Storage アカウントを作成する
- Azure ポータルで、[ストレージ アカウント] を検索します。
- [+ 作成] をクリックします。
次の構成情報を提供してください。
設定 値 サブスクリプション Azure サブスクリプションを選択する リソース グループ 既存のものを選択するか、新しいものを作成する ストレージ アカウント名 一意の名前を入力します(例: customsecuritylogs)。リージョン リージョンを選択します(例: East US)。パフォーマンス 標準(推奨) 冗長性 GRS(Geo 冗長ストレージ)または LRS(ローカル冗長ストレージ) [Review + create] をクリックします。
アカウントの概要を確認して、[作成] をクリックします。
デプロイが完了するまで待ちます。
ストレージ アカウントの認証情報を取得する
- 作成した ストレージ アカウントに移動します。
- 左側のナビゲーションで、[セキュリティとネットワーキング] の [アクセスキー] を選択します。
- [キーを表示] をクリックします。
- 後で使用できるように、次の値をコピーして保存します。
- ストレージ アカウント名:
customsecuritylogs - キー 1 またはキー 2: 共有アクセスキー
- ストレージ アカウント名:
BLOB コンテナを作成する
- 同じストレージ アカウントで、左側のナビゲーションから [コンテナ] を選択します。
- [+ コンテナ] をクリックします。
- 次の構成の詳細を入力します。
- 名前: コンテナ名を入力します(例:
security-events)。 - 一般公開アクセスレベル: [非公開(匿名アクセスなし)] を選択します。
- 名前: コンテナ名を入力します(例:
- [作成] をクリックします。
Azure Blob にエクスポートするようにアプリケーションを構成する
次のいずれかの方法を使用して、ログファイルを Azure Blob コンテナに書き込むようにカスタム セキュリティ アプリケーションを構成します。
- Azure CLI:
az storage blob uploadを使用する - Azure SDK: プログラミング言語のクライアント ライブラリを使用する
- AzCopy: AzCopy コマンドライン ツールを使用する
例:
Azure CLI を使用した例:
az storage blob upload \ --account-name customsecuritylogs \ --container-name security-events \ --name logs/2025/01/15/events.json \ --file /path/to/events.json \ --account-key <YOUR_ACCESS_KEY>Python SDK を使用した例:
from azure.storage.blob import BlobServiceClient import json # Initialize client connection_string = "DefaultEndpointsProtocol=https;AccountName=customsecuritylogs;AccountKey=<YOUR_KEY>;EndpointSuffix=core.windows.net" blob_service_client = BlobServiceClient.from_connection_string(connection_string) # Get container client container_client = blob_service_client.get_container_client("security-events") # Upload log file blob_client = container_client.get_blob_client("logs/2025/01/15/events.json") # Write NDJSON data events = [ {"timestamp": "2025-01-15T10:00:00Z", "event_type": "login"}, {"timestamp": "2025-01-15T10:05:00Z", "event_type": "logout"} ] ndjson_data = '\n'.join([json.dumps(event) for event in events]) + '\n' blob_client.upload_blob(ndjson_data, overwrite=True)
Azure Blob 用の Google SecOps フィードを構成する
- [SIEM 設定] > [フィード] に移動します。
- [Add New Feed] をクリックします。
- 次のページで [単一フィードを設定] をクリックします。
- [フィード名] フィールドに、フィードの名前を入力します(例:
custom-security-analytics-azure)。 - [ソースタイプ] で [Microsoft Azure Blob Storage V2] を選択します。
- [ログタイプ] として [カスタム セキュリティ データ分析] を選択します。
- [次へ] をクリックします。
次の入力パラメータの値を指定します。
Azure URI: コンテナパスを含む Blob Service エンドポイント URL を入力します。
https://customsecuritylogs.blob.core.windows.net/security-events/Source deletion option: 必要に応じて削除オプションを選択します。
- なし: 転送後にファイルを削除しません。
- 転送されたファイルを削除する: 転送が完了した後にファイルを削除します。
- 転送されたファイルと空のディレクトリを削除する: 転送が完了した後にファイルと空のディレクトリを削除します。
ファイルの最大経過日数: 指定した日数以内に変更されたファイルを含めます(デフォルトは 180 日)。
共有キー: ストレージ アカウントの共有キー値(アクセスキー)を入力します。
アセットの名前空間: アセットの名前空間。
Ingestion labels: このフィードのイベントに適用されるラベル。
[次へ] をクリックします。
[Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。
オプション 5: Amazon Data Firehose の取り込み(リアルタイム ストリーミング)
カスタム セキュリティ アプリケーションが Amazon CloudWatch Logs にログを書き込み、Google SecOps へのリアルタイム ストリーミングが必要な場合は、この方法を使用します。
Google SecOps Firehose フィードを作成する
- [SIEM 設定] > [フィード] に移動します。
- [Add New Feed] をクリックします。
- [フィード名] フィールドに、フィードの名前を入力します(例:
custom-security-analytics-firehose)。 - [ソースタイプ] として [Amazon Data Firehose] を選択します。
- [ログタイプ] として [カスタム セキュリティ データ分析] を選択します。
- [次へ] をクリックします。
- 次の入力パラメータの値を指定します。
- Split delimiter: 省略可: 改行区切りのログを分割するには、
\nを入力します。 - アセットの名前空間: アセットの名前空間。
- Ingestion labels: このフィードのイベントに適用されるラベル。
- Split delimiter: 省略可: 改行区切りのログを分割するには、
- [次へ] をクリックします。
- フィードの設定を確認し、[送信] をクリックします。
- [秘密鍵を生成する] をクリックして、このフィードを認証するためのシークレット キーを生成します。
- このシークレットは再び表示できないため、秘密鍵をコピーして保存します。
- [詳細] タブに移動します。
- [エンドポイント情報] フィールドから、フィードのエンドポイント URL をコピーします。
- [完了] をクリックします。
Google Cloud API キーを作成する
- https://console.cloud.google.com/apis/credentials で Google Cloud コンソールの [認証情報] ページに移動します。
- [認証情報を作成] をクリックして [API キー] を選択します。
- [API キーを編集] をクリックして、キーを制限します。
- [API の制限] で [キーを制限] を選択します。
- [Google SecOps API] を検索して選択します。
- [保存] をクリックします。
- API キーをコピーして保存します。
エンドポイント URL を作成する
次の形式で、フィード エンドポイント URL に API キーを追加します。
<FEED_ENDPOINT_URL>?key=<API_KEY>例:
https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate?key=AIzaSyD...次の手順で使用するため、この完全な URL を保存します。
Firehose の IAM ポリシーを作成する
- AWS コンソールで、[IAM] > [ポリシー] > [ポリシーを作成] > [JSON] タブに移動します。
次のポリシー JSON を貼り付けます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "firehose:PutRecord", "firehose:PutRecordBatch" ], "Resource": "arn:aws:firehose:<REGION>:<ACCOUNT_ID>:deliverystream/CustomSecurityToChronicle" } ] }次のように置き換えます。
<REGION>: AWS リージョン(例:us-east-1)。<ACCOUNT_ID>: AWS アカウント ID(12 桁の番号)。
ポリシーに
CloudWatchLogsToFirehosePolicyという名前を付けます。[ポリシーを作成] をクリックします。
CloudWatch Logs の IAM ロールを作成する
- [IAM]> [ロール]> [ロールを作成] に移動します。
[カスタム信頼ポリシー] を選択して、次の内容を貼り付けます。
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "logs.<REGION>.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }<REGION>は、実際の AWS リージョンに置き換えます。[次へ] をクリックします。
前の手順で作成したポリシー
CloudWatchLogsToFirehosePolicyを検索して選択します。[次へ] をクリックします。
ロールに
CloudWatchLogsToFirehoseRoleという名前を付けます。[ロールを作成] をクリックします。
Kinesis Data Firehose 配信ストリームを作成する
- AWS コンソールで、[Kinesis] > [Data Firehose] > [Create delivery stream] に移動します。
次の構成情報を提供してください。
移行元と移行先:
- ソース: [Direct PUT or other sources] を選択します。
- 宛先: [HTTP エンドポイント] を選択します。
配信ストリーム名:
- 配信ストリーム名: 「
CustomSecurityToChronicle」と入力します。
- 配信ストリーム名: 「
HTTP エンドポイントの宛先:
- HTTP エンドポイント URL: 先ほど作成した完全なエンドポイント URL(フィード エンドポイント + API キー)を入力します。
- コンテンツ エンコード: [GZIP] を選択します(帯域幅の節約に推奨)。
カスタム HTTP ヘッダー:
- [カスタム HTTP ヘッダーを追加] をクリックします。
- ヘッダー名: 「
X-Goog-Chronicle-Auth」と入力します。 - ヘッダー値: 前の手順で保存した秘密鍵を入力します。
バックアップの設定:
- Amazon S3 のソースレコード バックアップ: [失敗したデータのみ] を選択します(推奨)。
- S3 バケット: 既存のバケットを選択するか、失敗したレコード用に新しいバケットを作成します。
バッファのヒント:
- バッファサイズ:
1MiB(HTTP エンドポイントの最小値)を入力します。 - バッファ間隔:
60秒を入力します
- バッファサイズ:
再試行期間:
- 再試行期間:
300秒(5 分)と入力します。
- 再試行期間:
[配信ストリームを作成] をクリックします。
配信ストリームのステータスが [アクティブ] に変わるまで待ちます(1 ~ 2 分)。
CloudWatch ロググループを Firehose に登録する
- AWS コンソールで、[CloudWatch] > [ログ] > [ロググループ] に移動します。
- カスタム セキュリティ分析ログを含むターゲット ロググループを選択します。
- [サブスクリプション フィルタ] タブをクリックします。
- [作成> Amazon Kinesis Data Firehose サブスクリプション フィルタを作成] をクリックします。
- 次の構成の詳細を入力します。
- 宛先: 配信ストリーム
CustomSecurityToChronicleを選択します。 - 権限を付与: ロール
CloudWatchLogsToFirehoseRoleを選択します。 - サブスクリプション フィルタ名: 「
CustomSecurityToChronicle」と入力します。 - ログ形式: [その他] を選択します(Google SecOps が解析を処理します)。
- サブスクリプション フィルタ パターン: すべてのイベントを送信する場合は空白のままにします。特定のイベントのみを送信する場合は、フィルタ パターンを入力します。
- 宛先: 配信ストリーム
- [ストリーミングを開始] をクリックします。
- ログは Firehose を介して Google SecOps にリアルタイムでストリーミングされるようになります。
カスタム パーサーを作成する(省略可)
カスタム セキュリティデータを非構造化ログとして取り込んだ後、カスタム パーサーを作成して、検索性と検出性を高めるためにデータを UDM 形式に正規化できます。
カスタム パーサーを作成するタイミング
カスタム パーサーは、次のような場合に作成します。
- カスタム ログ形式から特定のフィールドを抽出する必要がある
- カスタムデータで UDM 検索を有効にする
- 検出ルールでカスタム フィールドを標準 UDM フィールドにマッピングする必要があります
- 特定のフィールドをインデックス登録して検索パフォーマンスを改善する
カスタム ログタイプを作成する
- [SIEM 設定] > [使用可能なログタイプ] に移動します。
- [ログタイプをリクエスト] をクリックします。
- [カスタムログタイプを作成するか、事前構築済みのログタイプをリクエストする] セクションで、[カスタムログタイプを作成する] を選択します。
- 次の情報を提供します。
- ログタイプの名前: わかりやすい名前を入力します(例:
CUSTOM_SECURITY_ANALYTICS)。 - 説明: ログタイプの説明を入力します。
- ログのサンプル: 5 ~ 10 個のログエントリのサンプルを未加工の形式で貼り付けます。
- ログタイプの名前: わかりやすい名前を入力します(例:
- [送信] をクリックします。
- カスタム ログタイプは、約 10 分後に使用できるようになります。
カスタム パーサーを作成する
- [SIEM 設定] > [パーサー] に移動します。
- [パーサーを作成する] をクリックします。
- [カスタム パーサー] を選択します。
- 次の情報を提供します。
- パーサー名: わかりやすい名前を入力します。
- ログタイプ: カスタム ログタイプ(
CUSTOM_SECURITY_ANALYTICSなど)を選択します。 - パーサーコード: Google SecOps のパーサー構成言語を使用してパーサー構成を入力します。
- サンプルログを使用してパーサーをテストします。
- [送信] をクリックして、パーサーを有効にします。
パーサーの構成例
カスタム JSON ログ形式の場合:
{ "timestamp": "2025-01-15T10:30:00Z", "event_type": "authentication", "user": "john.doe@example.com", "action": "login", "result": "success", "source_ip": "203.0.113.45" }パーサー構成の例:
filter { json { fields { timestamp: timestamp event_type: event_type user: user action: action result: result source_ip: source_ip } } } event { $e.metadata.event_timestamp.seconds = parseTimestamp(timestamp, "yyyy-MM-dd'T'HH:mm:ss'Z'") $e.metadata.event_type = "USER_LOGIN" $e.principal.user.email_addresses = user $e.target.ip = source_ip $e.security_result.action = if(result == "success", "ALLOW", "BLOCK") }カスタム パーサーの作成の詳細については、事前構築済みパーサーとカスタム パーサーを管理するをご覧ください。
データ取り込みを確認する
フィードを構成したら、データが正常に取り込まれていることを確認します。
フィードのステータスを確認する
- [SIEM 設定] > [フィード] に移動します。
- リストでフィードを探します。
- [ステータス] 列を確認します。
- 有効: フィードが実行中で、データを取り込んでいます
- エラー: フィードでエラーが発生しました(詳細を表示するにはクリックしてください)
- 一時停止: フィードが一時停止しています
取り込まれたログを検索する
- [検索> 未加工ログスキャン] に移動します。
カスタムログを見つけるための検索クエリを入力します。
metadata.log_type = "CUSTOM_SECURITY_DATA_ANALYTICS"必要に応じて期間を調整します。
[検索] をクリックします。
ログが結果に表示されていることを確認します。
フィードの指標をモニタリングする
- [SIEM 設定] > [フィード] に移動します。
- フィード名をクリックします。
- [指標] タブに移動します。
- 次の指標を確認します。
- 取り込まれたイベント: 取り込まれたイベントの合計数
- 取り込まれたバイト数: 取り込まれた合計データ容量
- 取り込み率: 1 秒あたりのイベント数
- エラー: 取り込みエラーの数
トラブルシューティング
Webhook の取り込みに関する問題
問題: HTTP 401 Unauthorized
- 原因: API キーまたはシークレット キーが無効です
- 解決策: API キーとシークレット キーが正しく、有効期限が切れていないことを確認します。
問題: HTTP 403 Forbidden
- 原因: API キーに Chronicle API の権限がない
- 解決策: API キーを編集し、[API の制限] で [Chronicle API] が選択されていることを確認します。
問題: HTTP 400 不正なリクエスト
- 原因: リクエストの形式またはペイロードが無効
- 解決策: Content-Type ヘッダーが
application/jsonに設定され、ペイロードが有効な JSON であることを確認する
S3/GCS/Azure Blob の取り込みに関する問題
問題: データが取り込まれない
- 原因: バケット URI が正しくないか、権限がない
- 解決策: バケット URI に末尾のスラッシュが含まれており、サービス アカウントに Storage オブジェクト閲覧者のロールが付与されていることを確認します。
問題: 取り込み後にファイルが削除されない
- 原因: サービス アカウントに削除権限がない
- 解決策: Storage オブジェクト閲覧者ではなく Storage オブジェクト管理者ロールを付与する
問題: 古いファイルが取り込まれない
- 原因: [Maximum File Age] 設定で古いファイルが除外されている
- 解決策: フィード構成で [Maximum File Age] の値を増やす
Firehose の取り込みに関する問題
問題: 配信ストリームにエラーが表示される
- 原因: エンドポイント URL または認証が無効
- 解決策: エンドポイント URL に API キー パラメータが含まれており、X-Goog-Chronicle-Auth ヘッダーに正しいシークレット キーが含まれていることを確認します。
問題: データの更新頻度が高い
- 原因: Firehose がスロットリングされているか、配信エラーが発生している
- 解決策:
ThrottledRecordsとDeliveryToHTTP.Successのレートについて CloudWatch 指標を確認する
問題: CloudWatch からログがストリーミングされない
- 原因: サブスクリプション フィルタが構成されていないか、IAM ロールに必要な権限がない
- 解決策: サブスクリプション フィルタが有効であり、IAM ロールに
firehose:PutRecord権限があることを確認します
UDM マッピング テーブル
カスタム セキュリティ データ分析ログは、非構造化データとして取り込まれます。UDM フィールド マッピングを有効にするには、上記の「カスタム パーサーを作成する」で説明した手順に沿って、カスタム パーサーを作成します。
カスタム パーサーを作成すると、パーサー構成に基づいて UDM フィールドが入力されます。セキュリティ分析データの一般的な UDM フィールドは次のとおりです。
| UDM フィールド | 説明 |
|---|---|
metadata.event_timestamp |
イベント タイムスタンプ |
metadata.event_type |
イベントタイプ(USER_LOGIN、FILE_ACCESS など) |
principal.user.email_addresses |
ユーザーのメールアドレス |
principal.ip |
送信元 IP アドレス |
target.resource.name |
ターゲット リソース名 |
security_result.action |
セキュリティ アクション(許可、ブロックなど) |
security_result.severity |
イベントの重大度 |
UDM フィールドの完全なリストについては、UDM フィールド リファレンスをご覧ください。
さらにサポートが必要な場合 コミュニティ メンバーや Google SecOps のプロフェッショナルから回答を得ることができます。