Cisco Identity Intelligence のログを収集する

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

Google SecOps SIEM

注: この機能には、Google Security Operations サービス固有の規約の 一般提供前サービス規約が適用されます。pre-GA の機能についてはサポートが制限されます。また、pre-GA の機能の変更は pre-GA の他のバージョンと互換性がない可能性があります。詳細については、Google SecOps 技術サポート サービス ガイドラインと Google SecOps サービス固有の規約をご覧ください。
この機能が環境に表示されない場合は、プレビュー機能を管理するをご覧になるか、システム管理者にお問い合わせください。

このドキュメントでは、Webhook を使用して Google Security Operations にログを push するように Cisco Identity Intelligence を構成する方法について説明します。

Cisco Identity Intelligence（旧 Oort Security）は、ID プロバイダ全体でユーザーの行動、認証パターン、デバイスの使用状況、アクセス権限を継続的にモニタリングする ID 脅威の検出と対応のプラットフォームです。ユーザー アクティビティ、セキュリティ チェックの失敗、信頼スコア、リスクの高い動作を分析して、ID ベースの脅威、構成ミス、コンプライアンス違反を検出します。

始める前に

次の前提条件を満たしていることを確認します。

• Google SecOps インスタンス
• Cisco Identity Intelligence テナントへの特権アクセス
• Cisco Identity Intelligence で統合を管理するための管理者権限
• Google Cloud コンソールへのアクセス（API キーの作成用）

Google SecOps で Webhook フィードを作成する

フィードを作成する

1. [SIEM 設定] > [フィード] に移動します。
2. [Add New Feed] をクリックします。
3. 次のページで、[単一のフィードを設定] をクリックします。
4. [フィード名] フィールドに、フィードの名前を入力します（例: Cisco Identity Intelligence Events）。
5. [Source type] として [Webhook] を選択します。
6. [Log type] として [Cisco Identity Intelligence] を選択します。
7. [次へ] をクリックします。
8. 次の入力パラメータの値を指定します。
   • Split delimiter（省略可）: 複数行のイベントを分割するには、\n を入力します。
   • Asset namespace: アセットの名前空間。
   • Ingestion labels: このフィードのイベントに適用されるラベル。
9. [次へ] をクリックします。
10. [Finalize] 画面で新しいフィードの設定を確認し、[送信] をクリックします。

秘密鍵を生成して保存する

フィードを作成したら、認証用の秘密鍵を生成する必要があります。

1. フィードの詳細ページで、[秘密鍵を生成] をクリックします。
2. ダイアログに秘密鍵が表示されます。
3. 秘密鍵をコピーして安全に保存します。

重要: 秘密鍵は一度しか表示されず、後で取得することはできません。秘密鍵を紛失した場合は、新しい秘密鍵を生成する必要があります。

フィード エンドポイントの URL を取得する

1. フィードの [詳細] タブに移動します。
2. [エンドポイント情報] セクションで、[フィード エンドポイント URL] をコピーします。

3. URL の形式は次のとおりです。

   https://{region}-chronicle.googleapis.com/v1/{parent}/logs:import
   

   ここで、{region} は Google SecOps インスタンスのリージョン（us、europe、asia-southeast1 など）で、{parent} は projects/<PROJECT_ID>/locations/<LOCATION>/instances/<INSTANCE_ID>/logTypes/<LOG_TYPE> 形式のリソースパスです。

4. 次の手順で使用するために、この URL を保存します。

5. [完了] をクリックします。

Google Cloud API キーを作成する

Chronicle では、認証に API キーが必要です。Google Cloud コンソールで制限付き API キーを作成します。

API キーを作成する

1. Google Cloud コンソールの [認証情報] ページに移動します。
2. プロジェクト（Chronicle インスタンスに関連付けられているプロジェクト）を選択します。
3. [認証情報を作成] > [API キー] をクリックします。
4. API キーが作成され、ダイアログに表示されます。
5. [API キーを編集] をクリックしてキーを制限します。

API キーを制限する

1. [API キー] の設定ページで、次の操作を行います。
   • 名前: わかりやすい名前を入力します（例: Chronicle Webhook API Key）。
2. [API の制限] で次の操作を行います。
   1. [キーを制限] を選択します。
   2. [API を選択] プルダウンで、[Google SecOps API]（または [Chronicle API]）を検索して選択します。
3. [保存] をクリックします。
4. ページ上部の [API キー] フィールドから API キーの値をコピーします。
5. API キーを安全に保存します。

注: API キーを制限すると、Chronicle API でのみ使用できるようになり、キーが侵害された場合のセキュリティ リスクが軽減されます。

Cisco Identity Intelligence の Webhook を構成する

Webhook URL を作成する

• Chronicle エンドポイント URL と API キーを組み合わせます。

  <ENDPOINT_URL>?key=<API_KEY>&secret=<SECRET_KEY>
  

  • 例:

    https://{region}-chronicle.googleapis.com/v1/{parent}/logs:import?key=AIzaSyD...&secret=abcd1234...
    

次のように置き換えます。

• <ENDPOINT_URL>: 前にコピーした Chronicle フィード エンドポイント URL
• <API_KEY>: 前に作成した Google Cloud API キー
• <SECRET_KEY>: 先ほど生成した Chronicle Webhook のシークレット キー

Cisco Identity Intelligence で Webhook 通知ターゲットを作成する

1. Cisco Identity Intelligence にログインします。
2. [インテグレーション] に移動します。
3. [Add Integration] をクリックします。
4. [Webhook] セクションまで下にスクロールします。
5. [Add Webhook Target] をクリックします。
6. 次の構成情報を指定します。
   • 名前: わかりやすい名前を入力します（例: Chronicle SIEM Integration）。
   • Webhook URL: 上記の API キーと秘密鍵を含む完全なエンドポイント URL を貼り付けます。
   • Authorization Type: [API キー] を選択します。
   • API Key Name: キー名（x-goog-chronicle-auth など）を入力します。
   • API Key Value: Google Cloud API キーを入力します。
7. [Invocation HTTP Parameters] セクションを開きます。
8. Header タイプの次のパラメータを追加します。
   • Key: Content-Type、Value: application/json
   • Key: Accept、Value: application/json
9. [このターゲットを使用する目的] セクションで、[失敗したチェック] を選択して、ID チェックで失敗した結果が検出されたときに通知を受け取ります。

10. [保存] をクリックします。

    注: Webhook の宛先には、有効な公的に信頼できる証明書が必要です。プライベート PKI の証明書はサポートされていません。

Webhook 接続をテストする

1. [統合] ページで、作成した Webhook 通知ターゲットを見つけます。
2. 行の右側にあるその他メニューをクリックします。
3. [接続をテスト] を選択します。
4. テスト メッセージが正常に配信されたことを確認します。

ID チェックの Webhook を有効にする

Webhook 通知ターゲットを作成したら、モニタリングする特定の ID チェックに対して有効にする必要があります。

1. Cisco Identity Intelligence で目的の [Check] 詳細ページに移動します。
2. ページの右上にあるプルダウンを開きます。
3. 作成した Webhook 通知ターゲットのチェックボックスをオンにします。

4. Google SecOps に送信するチェックごとに、この手順を繰り返します。

   注: 少なくとも 1 つの ID チェックで有効になるまで、Webhook を介して何も送信されません。有効にすると、Cisco Identity Intelligence は 1 日に 1 回、有効なチェックに失敗した新規ユーザーのリストを含むペイロードを Webhook に送信します。

詳細については、Cisco Identity Intelligence の Webhook のドキュメントをご覧ください。

認証方法のリファレンス

Chronicle ウェブフック フィードは、複数の認証方法をサポートしています。ベンダーがサポートしている方法を選択してください。

方法 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://{region}-chronicle.googleapis.com/v1/{parent}/logs:import?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"
  }
  

認証ヘッダー名

Chronicle は、認証に次のヘッダー名を使用します。

API キーの場合:

• x-goog-chronicle-auth（推奨）
• X-Goog-Chronicle-Auth（大文字と小文字を区別しない）

秘密鍵の場合:

• x-chronicle-auth（推奨）
• X-Chronicle-Auth（大文字と小文字を区別しない）

注: Cisco Identity Intelligence は、呼び出し HTTP パラメータを介してカスタム HTTP ヘッダーをサポートしています。クエリ パラメータ メソッド（方法 2）を使用して Webhook URL に認証情報を追加するか、[呼び出し HTTP パラメータ] セクションでカスタム ヘッダー（方法 1）を構成できます。クエリ パラメータ メソッドは、この統合の最も簡単な方法です。

Webhook の上限とベスト プラクティス

リクエストに関する上限

上限	値
最大リクエスト サイズ	4 MB
最大 QPS（秒間クエリ数）	15,000
リクエストのタイムアウト	30 秒
再試行の動作	指数バックオフによる自動

UDM マッピング テーブル

ログフィールド	UDM マッピング	ロジック
アカウント	account_label.value	値が直接コピーされる
アカウント	account_label.key	「account」に設定
account_label	security_result.detection_fields	detection_fields に統合されました
additional_detaildescription.key	additional_detaildescription.key	「詳細な説明」に設定
detaildescription	additional_detaildescription.value.list_value.values	detaildescription から統合
additional_detaildescription	event.idm.read_only_udm.additional.fields	additional.fields に統合
additional_recommendedaction.key	additional_recommendedaction.key	「推奨される対応」に設定
recommendedAction	additional_recommendedaction.value.list_value.values	recommendedAction から統合
additional_recommendedaction	event.idm.read_only_udm.additional.fields	additional.fields に統合
data1	usersFailing_label	値が直接コピーされる
data.login	login_label	値を直接コピーする
detail-type	security_result.summary	値が直接コピーされる
detail.id	security_result.rule_id	値を直接コピーする
detail.title	security_result.rule_name	値が直接コピーされる
detail.severity	security_result.severity	[CRITICAL、ERROR、HIGH、INFORMATIONAL、LOW、MEDIUM] のいずれかの場合は detail.severity の値。中程度の場合は MEDIUM
detaildescription	value_array.string_value	値が直接コピーされる
detailsdata.key	add_label.value、add_label.key	failedSigninDetails または ips でない場合、detailsdata.value の値、キーは「loginDetails %{index} details %{detailindex} %{detailsdata.key}」
detailsdata.value	add_label.value、add_label.key
detailsdata.key	security_result.detection_fields	条件が満たされた場合に add_label を統合
detailsdata.value	security_result.detection_fields
field_.value	security_result.detection_fields	json_array のさまざまなネストされたフィールド（msg、ipInfo、asn、coordinates、first_event、second_event、locations）を、「%{index} %{detailindex} %{index1} %{key}」などのキーでマージしました。ipAddress、ip などは除外されています。
field_.key	security_result.detection_fields
id	metadata.product_log_id	値が直接コピーされる
login_label	principal.user.email_addresses	メールの正規表現に一致する場合に統合
msg.ipAddress	principal.ip	空でない場合はマージされます
msg.first_event.ip_address	principal.ip	空でない場合はマージされます
msg.second_event.ip_address	principal.ip	空でない場合はマージ
msg_travels_first_event_ip_address	principal.ip	空でない場合はマージ
msg_travels_second_event_ip_address	principal.ip
recommendedAction	value_array.string_value	値が直接コピーされる
security_result	event.idm.read_only_udm.security_result	security_result に統合されました
ソース	source_label.value	値を直接コピーする
ソース	source_label.key	「source」に設定
source_label	event.idm.read_only_udm.src.labels	src.labels に統合
時間	@timestamp	ISO8601、RFC 3339、yyyy-MM-ddTHH:mm:ss.SSSSSSZ の日付フィルタを使用して解析されます。
usersFailing_label	principal.user.email_addresses	メールの正規表現に一致する場合に統合
version	metadata.product_version	値を直接コピーする
has_principal	event.idm.read_only_udm.metadata.event_type	has_principal が true の場合は「STATUS_UPDATE」に設定し、has_user が true の場合は「USER_UNCATEGORIZED」に設定し、それ以外の場合は「GENERIC_EVENT」に設定します。
has_user	event.idm.read_only_udm.metadata.event_type
metadata.product_name	metadata.product_name	「OORT」に設定
metadata.vendor_name	metadata.vendor_name	「OORT」に設定
detail.published	event.idm.read_only_udm.metadata.collected_timestamp	変更履歴からマッピング
detail.login	event.idm.read_only_udm.principal.user.userid	変更履歴からマッピング
detail.userTrustLevel	event.idm.read_only_udm.principal.user.attribute.labels	変更履歴からマッピング
detail.login	event.idm.read_only_udm.principal.user.user_display_name	変更履歴からマッピング
detail.checkTopics	event.idm.read_only_udm.security_result.category_details	変更履歴からマッピング
region	event.idm.read_only_udm.additional.fields	変更履歴からマッピング
detail.checkId	event.idm.read_only_udm.security_result.detection_fields	変更履歴からマッピング
detail.checkScope	event.idm.read_only_udm.security_result.detection_fields	変更履歴からマッピング
detail.frameworks	event.idm.read_only_udm.security_result.detection_fields	変更履歴からマッピング
detail.explainabilityEventIds	event.idm.read_only_udm.security_result.detection_fields	変更履歴からマッピング
data.value	event.idm.read_only_udm.security_result.detection_fields	変更履歴からマッピング

変更ログ

このパーサーの変更ログを表示する

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