Menggunakan UI feed

Didukung di:

Google secops SIEM

Dokumen ini menjelaskan cara membuat, memecahkan masalah, dan mengelola feed dalam UI Pengelolaan Feed, termasuk petunjuk untuk mengubah, mengaktifkan, dan menghapusnya.

Sebelum memulai

Setiap feed data memerlukan prasyarat tertentu sebelum penyiapan di Google Security Operations. Untuk menemukan persyaratan feed Anda, lihat Konfigurasi menurut jenis sumber dan telusuri sumber data spesifik Anda.

Format kompresi dan ukuran file yang didukung

Format kompresi yang didukung untuk penyerapan feed mencakup .gz, .tar.gz, .tar, dan solr.gz. Tabel berikut menguraikan berbagai ukuran file yang didukung transformasi feed Google SecOps:

Operasi	Jenis input	Ukuran yang direkomendasikan	Durasi yang diharapkan	Ukuran maks
Pemodelan Data	CSV	< 5 GB	< 7 mnt	10 GB
Pemodelan Data	CSV	< 5 GB	~30 mnt	10 GB
Pemodelan Data	CSV	Ditentukan Nanti	Ditentukan Nanti	2 GB
Pemodelan Data	XML / JSON	< 1 GB	< 10 mnt	2 GB
Pemodelan Data	XLS / XLSX	< 50 MB	~1 mnt	50 MB
Menggabungkan File	Semua	< 1 GB	Bervariasi berdasarkan jumlah file	100 GB
Mendekompresi File	Non-ZIP	< 5 GB	Bervariasi berdasarkan jumlah file	10 GB (tidak dikompresi)
Mendekompresi File	Kode Pos	-	Bervariasi berdasarkan jumlah file	4 GB (tidak dikompresi)

Batas dan pembatas baris log

Saat menyerap log berbasis teks (JSON, CSV, atau Syslog), pastikan data Anda mematuhi batas penyerapan khusus berikut:

• Ukuran Baris Maksimum: Satu baris log tidak boleh melebihi 4 MB. Jika satu baris melebihi batas ini, feed akan gagal dengan error MaxLogLineSize4MBExceeded.
• Pembatas yang Didukung: Newline (\n) dan Carriage Return + Newline (\r\n) didukung.

Catatan: Untuk jenis log dengan kepadatan data tinggi, pastikan sumber log Anda tidak mengelompokkan beberapa peristiwa ke dalam satu baris yang melebihi batas 4 MB. Jika Anda menemukan error ukuran, Anda mungkin perlu menyesuaikan konfigurasi logging sumber untuk memastikan setiap entri dibatasi dengan benar.

Dampak perubahan Project Cloud tertaut pada feed data

Jika Anda memperbarui project Google Cloud yang terkait dengan instance Google SecOps, semua feed yang menyerap data menggunakan konektor berikut akan berhenti, dan harus dibuat ulang secara manual:

• AMAZON_S3_V2
• AMAZON_SQS_V2
• GOOGLE_CLOUD_STORAGE_V2
• AZURE_BLOBSTORE_V2
• GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN

Untuk semua feed lainnya yang tidak menggunakan konektor ini, penyerapan akan berlanjut tanpa gangguan. Pelanggan tidak perlu melakukan tindakan apa pun.

Yang dapat terjadi selama migrasi

Untuk feed yang terpengaruh, Anda akan melihat perubahan berikut:

• Status feed: Feed yang dibuat sebelum migrasi akan segera berhenti menarik data aktif dan akan menjadi hanya baca.
• Data yang ada: Semua data yang sudah ditransfer ke Google SecOps sebelum migrasi akan diserap secara otomatis; tidak ada data yang akan hilang.
• Pesan error: Jika Anda mencoba mengedit atau menghapus feed lama, Anda akan menerima pesan yang menyatakan: This feed is read-only because this SecOps has now moved to a new Google Cloud Project (BYOP). To continue ingesting data from this source, please create a new feed.

Tindakan yang diperlukan untuk pelanggan

Untuk memastikan penyerapan data berkelanjutan, Anda harus membuat ulang feed secara manual di lingkungan baru. Ikuti langkah-langkah berikut untuk meminimalkan gangguan:

1. Buat ulang feed: Anda harus membuat feed baru untuk menggantikan feed yang ada sebelum migrasi.
2. Konfigurasi Usia File Maksimum: Saat menyiapkan feed baru, tetapkan Usia File Maksimum sekitar 2 jam sebelum pembaruan BYOP dimulai. Jeda waktu ini memastikan transisi yang lancar.

3. Mengelola data duplikat: Bergantung pada Usia File Maksimum yang Anda pilih, Anda mungkin mengalami beberapa transfer data duplikat. Untuk mengetahui detail teknis tentang cara Google SecOps memfilter log yang berlebihan ini, lihat Mencegah penghapusan duplikat.

   Catatan: Hal ini tidak berlaku untuk feed yang mengaktifkan opsi Hapus setelah Transfer.

4. Mencatat dan menghapus feed yang ada (sebelum migrasi): Sebelum memulai migrasi BYOP, catat setelan konfigurasi untuk semua feed yang ada yang menggunakan konektor yang terpengaruh (misalnya, Amazon S3 V2), lalu hapus feed tersebut. Jika Anda tidak menghapus feed yang dibuat sebelum migrasi, feed tersebut akan menjadi tidak dapat dikelola dan tetap berada di antarmuka web Google SecOps sebagai setelan yang tidak terkait.

Cara menyiapkan feed

Ada dua cara bagi pelanggan Google SecOps untuk menyiapkan feed di platform. Gunakan metode yang paling sesuai untuk lingkungan Anda:

• Setelan SIEM > Feed (standar)
• Hub Konten > Paket Konten (premium)

Catatan: Jika Anda menggunakan platform mandiri SIEM, Anda tidak akan memiliki akses ke Hub Konten. Hubungi perwakilan Google SecOps Anda untuk melakukan upgrade.

Mengonfigurasi feed

Bagian ini menjelaskan cara secara umum mengonfigurasi feed, dimulai dengan alur prosedural standar. Feed data yang tercantum di halaman Feed mencakup semua feed yang telah dikonfigurasi Google untuk akun Anda, termasuk feed yang Anda konfigurasi.

Menambahkan feed

Perhatian: Mulai 15 April 2026, framework konektor v1 untuk Cloud Storage, Amazon S3, Amazon SQS, dan Azure Blob Storage tidak digunakan lagi. Sebaiknya gunakan framework konektor v2, yang menggunakanGoogle Cloud Storage Transfer Service (STS) untuk penyerapan data hampir real-time. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade feed data penyimpanan cloud ke framework konektor v2 dan Penghentian penggunaan fitur.

Untuk menambahkan feed ke akun Google SecOps Anda, selesaikan langkah-langkah berikut:

1. Di menu Google SecOps, pilih SIEM Settings > Feeds.

2. Klik Tambahkan Feed Baru.

3. Di halaman berikutnya, klik Konfigurasi satu feed. Catatan: Langkah ini tidak relevan bagi pelanggan yang menggunakan platform mandiri Google SecOps SIEM.

4. Tambahkan nama feed.

5. Dalam daftar Source type, pilih jenis sumber untuk mengimpor data ke Google SecOps. Anda dapat memilih dari jenis sumber feed berikut:

   • Amazon Data Firehose
   • Amazon S3 (Tidak digunakan lagi)
   • Amazon S3 (V2)
   • Amazon SQS (Tidak digunakan lagi)
   • Amazon SQS (V2)
   • Azure Blob Storage (Tidak digunakan lagi)
   • Azure Blob Storage (V2)
   • API Kustom
   • Google Cloud Pub/Sub
   • Cloud Storage (Tidak digunakan lagi)
   • Cloud Storage (V2)
   • Cloud Storage Event Driven
   • API pihak ketiga
   • Webhook

   Penting:

   • Saat menggunakan feed Amazon S3 (Tidak digunakan lagi), Amazon SQS (Tidak digunakan lagi), Azure Blob Storage (Tidak digunakan lagi), dan Google Cloud Cloud Storage (Tidak digunakan lagi), pastikan Anda memiliki jalur direktori yang valid.
   • Saat menggunakan Amazon SQS (Tidak digunakan lagi) atau Amazon SQS (V2), berikan izin Google SecOps secara eksplisit untuk menghapus pesan dari antrean Amazon SQS.
   • Saat menggunakan feed Amazon SQS (Tidak digunakan lagi), pastikan hanya ada satu feed yang menggunakan pesan dari antrean. Pesan yang dibaca oleh aplikasi atau feed lain tidak dimasukkan ke dalam feed saat ini.
   • Menggunakan Amazon SQS (Tidak digunakan lagi) sebagai jenis sumber feed hanya didukung untuk log di bucket Amazon S3.

6. Di daftar Log type, pilih jenis log yang sesuai dengan log yang ingin Anda masukkan. Log yang tersedia bervariasi, bergantung pada jenis sumber yang Anda pilih sebelumnya.

   Catatan: Untuk jenis log AWS CLOUDTRAIL, pastikan log dalam format JSON dan nama filenya adalah file JSON (tidak dikompresi) atau file JSON GZipped (dikompresi).

   Jika Anda memilih Cloud Storage sebagai jenis sumber, gunakan opsi Dapatkan akun layanan untuk mendapatkan akun layanan unik. Lihat contoh penyiapan feed Google Cloud Storage.

7. Klik Berikutnya.

8. Tentukan parameter yang diperlukan dari tab Input Parameters. Opsi yang ditampilkan di sini bervariasi, bergantung pada jenis sumber dan log yang dipilih di tab Tetapkan Properti. Tahan kursor di atas ikon pertanyaan untuk setiap kolom guna mendapatkan informasi tambahan tentang apa yang perlu Anda berikan.

9. Opsional: Anda dapat menentukan namespace di tab Setel Properti. Untuk mengetahui informasi selengkapnya tentang namespace, lihat Menggunakan namespace aset.

10. Klik Berikutnya.

11. Tinjau konfigurasi feed baru Anda di tab Selesaikan.

12. Klik Kirim. Google SecOps menyelesaikan pemeriksaan validasi feed baru. Jika feed lulus pemeriksaan, nama akan dibuat untuk feed, feed akan dikirimkan ke Google SecOps, dan Google SecOps akan mulai mencoba mengambil data.

    

Mengonfigurasi beberapa feed untuk keluarga produk (khusus pelanggan Google SecOps)

Anda dapat mengonfigurasi beberapa feed per keluarga produk, berdasarkan jenis log.

• Jenis log dasar pengukuran: Ditandai sebagai direkomendasikan. Jenis log ini direkomendasikan untuk fungsionalitas platform inti.
• Jenis log tambahan: Ditandai sebagai opsional. Jenis log ini memberikan konteks tambahan.

Untuk menyederhanakan penyiapan, platform ini memberikan petunjuk penyiapan khusus dan parameter standar untuk setiap konfigurasi. Misalnya, untuk CrowdStrike Falcon, Anda dapat membuat beberapa feed unik dalam jenis log direkomendasikan dan opsional untuk memastikan cakupan data yang komprehensif.

Mengonfigurasi feed untuk CrowdStrike EDR

Ikuti langkah-langkah berikut untuk mengonfigurasi feed log untuk CrowdStrike EDR.

1. Dari Setelan > Feed, klik Tambahkan Feed Baru
   1. Klik produk CrowdStrike Falcon:.
   2. Pilih jenis log CrowdStrike EDR.
2. Atau, dari Content Hub > Content Packs, klik produk CrowdStrike Falcon:
   1. Klik Mulai.
   2. Pilih jenis log CrowdStrike EDR.

3. Tentukan nilai untuk kolom berikut:

   Kolom	Deskripsi
   Source Type	Amazon SQS
   Region	Region AWS S3 yang terkait dengan URI.
   Queue Name	Nama antrean SQS yang akan dibaca.
   Account Number	Nomor akun SQS.
   Source Deletion Option	Menunjukkan apakah akan menghapus file dan direktori setelah transfer.
   Queue Access Key ID	Kunci akses alfanumerik 20 karakter untuk akun, seperti AKIAOSFOODNN7EXAMPLE.
   Queue Secret Access Key	Kunci akses rahasia alfanumerik 40 karakter untuk akun, seperti wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY.

4. Opsional: Konfigurasikan parameter berikut:

   • Nama Feed: nama unik yang telah diisi otomatis untuk feed.
   • Namespace aset: namespace yang terkait dengan feed.
   • Label penyerapan: label yang diterapkan ke peristiwa dari feed ini.

5. Klik Buat Feed.

Anda dapat mengulangi proses ini untuk membuat feed tambahan untuk jenis log yang sama. Anda juga dapat mengonfigurasi feed untuk jenis log lain yang tersedia langsung dari halaman ini. Setelah selesai, buka halaman Pengelolaan Feed untuk melihat ringkasan mendetail dari semua jenis log yang dikonfigurasi.

Daftar IP yang diizinkan

Aktifkan daftar yang diizinkan dan tambahkan rentang IP Google untuk semua jenis log yang menyerap data dari API pihak ketiga.

Catatan: Daftar yang diizinkan IP hanya didukung untuk jenis feed tertentu: S3_V2, SQS_V2, Azure_Blobstore_V2, S3, SQS, Azure_Blobstore, dan Azure Event Hub. Feed push HTTPS tidak memerlukan pemberian izin IP karena berbasis push. Google SecOps tidak dapat menjamin bahwa semua feed akan berasal secara eksklusif dari alamat IP sesuai dengan region yang ditentukan.

Menghapus file sumber

Opsi penghapusan sumber memungkinkan Anda menghapus objek sumber feed (file dan folder) dari penyimpanan, setelah transfer berhasil. Opsi ini hanya tersedia untuk jenis sumber feed yang dipilih, termasuk Cloud Storage. Jenis sumber feed ini mencakup kolom SOURCE DELETION OPTION dalam alur kerja Tambahkan baru dan Edit feed.

Catatan: Saat mengonfigurasi kolom SOURCE DELETION OPTION, jika Anda memilih opsi untuk menghapus objek sumber, Anda harus mengaktifkan izin penghapusan yang diperlukan untuk jenis feed tersebut. Untuk mengetahui informasi tentang izin, lihat Konfigurasi menurut jenis sumber.

Opsi penghapusan sumber

• Untuk jenis sumber feed yang didukung, termasuk Cloud Storage, kolom SOURCE DELETION OPTION menawarkan opsi berikut:

  • Jangan pernah menghapus file
  • Menghapus file yang ditransfer dan direktori kosong
  • Menghapus file yang ditransfer

• Microsoft Azure Blob Storage (AZURE_BLOBSTORE) tidak mendukung penghapusan file sumber. Untuk kolom OPSI PENGHAPUSAN SUMBER, pilih opsi Jangan pernah hapus file saja.

• Untuk sumber feed berikut ("feedSourceType"): GOOGLE_CLOUD_STORAGE_V2, GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN, AMAZON_S3_V2, AMAZON_SQS_V2, dan AZURE_BLOBSTORE_V2, kolom OPSI PENGHAPUSAN SUMBER menawarkan dua opsi:

  • JANGAN PERNAH: Tidak pernah menghapus file apa pun setelah transfer.
  • ON_SUCCESS: Menghapus semua file dan direktori kosong setelah transfer.

Penyiapan dan izin khusus sumber

Jenis sumber yang berbeda memerlukan konfigurasi autentikasi dan jaringan tertentu untuk berkomunikasi dengan Google SecOps. Bagian ini menjelaskan cara mengonfigurasi izin dan menyiapkan akun layanan. Penyiapan yang diuraikan berfokus pada penyerapan Cloud Storage (berbasis pull), penyerapan multi-cloud (pull lintas cloud), dan penyerapan berbasis push (API atau real-time).

Catatan: Jika Anda menggunakan Kontrol Layanan VPC, lihat Mengonfigurasi Kontrol Layanan VPC untuk Google SecOps untuk mengetahui informasi selengkapnya.

Contoh penyiapan feed Google Cloud Storage

Catatan: Jika Anda menggunakan kebijakan organisasi Berbagi yang Dibatasi Domain di Google Cloud, pastikan Anda menambahkan ID pelanggan Google SecOps C02h8e9nw ke daftar yang diizinkan.

1. Dari menu Google SecOps, pilih Settings, lalu klik Feeds.
2. Klik Tambahkan Feed Baru.
3. Di halaman berikutnya, klik Konfigurasi satu feed. Langkah ini tidak berlaku jika Anda menggunakan platform mandiri Google SecOps SIEM.
4. Pilih Cloud Storage v2 untuk Source Type.
5. Pilih Jenis log. Misalnya, untuk membuat feed bagi log audit Google Kubernetes Engine, pilih Log audit Google Kubernetes Engine sebagai Jenis Log.
6. Klik Dapatkan akun layanan. Google SecOps menyediakan akun layanan unik yang digunakan Google SecOps untuk menyerap data. Atau, Anda bisa mendapatkan akun layanan ini secara terprogram menggunakan API. Lihat Mengambil akun layanan.
7. Opsional: Konfigurasi akun layanan. Untuk mengetahui informasi selengkapnya, lihat Memberikan akses ke akun layanan Google SecOps.
8. Klik Berikutnya.

9. Berdasarkan konfigurasi Cloud Storage yang Anda buat, tentukan nilai untuk kolom berikut:

   • URI bucket penyimpanan

     Catatan: Gunakan karakter pengganti untuk mencocokkan seluruh nama direktori. Misalnya, gs://cs-myprod/*/more-data valid (dengan * menggantikan seluruh nama tingkat direktori tunggal).
     Catatan: Untuk jenis feed yang Didorong Peristiwa Cloud Storage, siapkan langganan Pub/Sub untuk Cloud Storage, seperti yang dijelaskan dalam Mengonfigurasi Pub/Sub.

   • Opsi penghapusan sumber

   Untuk mempelajari lebih lanjut cara menyiapkan bucket Cloud Storage, lihat Membuat Bucket.

   Catatan: Feed bucket Cloud Storage tidak berfungsi dengan nama folder kosong.

10. Klik Berikutnya, lalu klik Kirim.

Memberikan akses ke akun layanan Google SecOps

1. Di konsol Google Cloud , buka halaman Buckets Cloud Storage.
   

   Buka Buckets

2. Berikan akses ke akun layanan untuk objek Cloud Storage yang relevan.

   • Untuk memberikan izin baca ke file tertentu, selesaikan langkah-langkah berikut:

     1. Pilih file, lalu klik Edit akses.
     2. Klik Add principal.
     3. Di kolom New principals, masukkan nama akun layanan Google SecOps.
     4. Tetapkan peran yang berisi izin baca ke akun layanan Google SecOps. Misalnya, Storage Object Viewer (roles/storage.objectViewer). Hal ini hanya dapat dilakukan jika Anda belum mengaktifkan akses level bucket yang seragam.
     5. Klik Simpan.

   • Untuk memberikan izin baca ke beberapa file, berikan akses di tingkat bucket sebagai berikut:

     • Untuk "feedSourceType": "GOOGLE_CLOUD_STORAGE":

       1. Tambahkan akun layanan Google SecOps sebagai akun utama ke bucket penyimpanan Anda dan berikan peran IAM Storage Object Viewer (roles/storage.objectViewer).
       2. Jika Anda mengonfigurasi feed untuk menghapus file sumber, Anda harus menambahkan akun layanan Google SecOps sebagai akun utama di bucket dan memberikan peran IAM Storage Object Admin (roles/storage.objectAdmin) kepadanya.

     • Untuk "feedSourceType": "GOOGLE_CLOUD_STORAGE_V2", berikan peran berikut:

       1. Berikan peran ini:

          • Storage Object Viewer (roles/storage.objectViewer) jika transfer dilakukan ke bucket Cloud Storage lain.

       2. Berikan salah satu peran berikut, bergantung pada opsi yang Anda pilih untuk Opsi Penghapusan Sumber. Jika Anda memilih Saat Berhasil, berikan peran Storage Legacy Bucket Writer. Jika Anda memilih Jangan pernah, berikan peran Storage Legacy Bucket Reader:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) jika izin penghapusan objek diperlukan.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) jika izin penghapusan objek tidak diperlukan.

     • Untuk "feedSourceType": "GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN":

       1. Berikan salah satu peran berikut:

          • Storage Object Viewer (roles/storage.objectViewer) jika transfer dilakukan ke bucket Cloud Storage lain.
          • Storage Object Creator (roles/storage.objectCreator) jika transfer dilakukan ke sistem file.

       2. Berikan salah satu peran berikut:

          • Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) jika izin penghapusan objek diperlukan.
          • Storage Legacy Bucket Reader (roles/storage.legacyBucketReader) jika izin penghapusan objek tidak diperlukan.

Mengaktifkan akses STS untuk Amazon S3 dan Azure Storage

STS digunakan oleh feed Google Cloud Storage berikut untuk mentransfer data dari blobstores Amazon S3 dan Azure Storage ke Google SecOps:

• Amazon S3 (V2)
• Amazon SQS (V2)
• Azure Blob Storage (V2)

STS mengirim permintaan transfer data ke layanan penyimpanan Amazon S3 dan Azure dari serangkaian rentang alamat IP STS yang ditentukan. Rentang alamat IP STS ini dipublikasikan dalam file JSON berikut: Rentang IP

Untuk menggunakan jenis sumber feed STS ini, Anda mungkin perlu menyesuaikan pembatasan akses IP agar STS dapat mengakses layanan penyimpanan Amazon S3 dan Azure Anda:

1. Tarik rentang IP terbaru dari file JSON.

   Sebaiknya baca data dari file JSON ini setidaknya setiap minggu agar konfigurasi keamanan Anda tetap terbaru. Saat rentang baru ditambahkan ke file, sistem akan menunggu setidaknya 7 hari sebelum menggunakan rentang tersebut untuk permintaan dari STS.

   Untuk contoh skrip Python yang mengambil rentang IP dari file JSON, lihat Alamat IP untuk domain default.

2. Bandingkan rentang IP saat ini creationTime dengan rentang IP creationTime yang dibaca dari file JSON sebelumnya. Jika berbeda, perbarui batasan akses IP di blobstores Amazon S3 dan Azure Storage.

   • Untuk Amazon S3

     Untuk memperbarui batasan akses IP di blobstore Amazon S3 Anda:

     Jika project AWS Anda menggunakan pembatasan IP untuk akses ke penyimpanan, Anda harus menambahkan rentang IP yang digunakan oleh pekerja STS ke daftar IP yang diizinkan.

     Catatan: Jika Anda menggunakan agen, bukan transfer tanpa agen, tambahkan alamat IP mesin agen ke daftar IP yang diizinkan.

     Untuk menambahkan rentang ini sebagai IP yang diizinkan, gunakan kolom Condition dalam bucket policy, seperti yang dijelaskan dalam dokumentasi AWS S3: Mengelola akses berdasarkan alamat IP tertentu.

   • Untuk Azure Storage

     Untuk memperbarui batasan akses IP di blobstore Azure Storage Anda:

     Jika membatasi akses ke resource Azure menggunakan firewall Azure Storage, Anda harus menambahkan rentang IP yang digunakan oleh pekerja STS ke daftar IP yang diizinkan.

     Untuk menambahkan rentang ini sebagai IP yang diizinkan, ikuti petunjuk berikut: Mengonfigurasi firewall dan jaringan virtual Azure Storage.

Menyiapkan feed push Pub/Sub

Untuk menyiapkan feed push Pub/Sub, lakukan hal berikut:

1. Buat feed push Pub/Sub.
2. Tentukan URL endpoint di langganan Pub/Sub.

Catatan: Feed push Pub/Sub harus ada di project Google Cloud Anda yang terikat ke Google SecOps agar langganan dapat diautentikasi. API ini menggunakan token JWT dari akun layanan Anda untuk autentikasi. Untuk mengetahui detail selengkapnya, lihat Autentikasi untuk langganan push.

Membuat feed push Pub/Sub

1. Di menu Google SecOps, pilih Setelan, lalu klik Feed.
2. Klik Tambahkan baru.
3. Di kolom Nama feed, masukkan nama untuk feed.
4. Dalam daftar Source type, pilih Google Cloud Pub/Sub Push.
5. Pilih Jenis log. Misalnya, untuk membuat feed untuk Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Jenis log.
6. Klik Berikutnya.
7. Opsional: Tentukan nilai untuk parameter input berikut:
   • Pembatas pemisahan: pembatas yang digunakan untuk memisahkan baris log. Anda hanya dapat menggunakan \n.
   • Namespace aset: namespace aset.
   • Label penyerapan: label yang akan diterapkan ke peristiwa dari feed ini.
8. Klik Berikutnya.
9. Tinjau konfigurasi feed baru Anda di layar Selesaikan, lalu klik Kirim.
10. Dari tab Detail, salin URL endpoint feed dari kolom Informasi Endpoint. Anda memerlukan URL endpoint ini untuk membuat langganan push di Pub/Sub.
11. Opsional: Klik tombol Feed Diaktifkan untuk menonaktifkan feed. Feed diaktifkan secara default.
12. Klik Done.

Tentukan URL endpoint

Setelah membuat feed push Pub/Sub, tentukan URL endpoint sebagai berikut:

1. Di Pub/Sub, buat langganan push. Untuk mengetahui informasi selengkapnya tentang cara membuat langganan push, lihat Membuat langganan push.
2. Tentukan URL endpoint, yang tersedia di feed push Pub/Sub Google Cloud .
3. Pilih Aktifkan autentikasi, lalu pilih akun layanan.
4. Nonaktifkan opsi Pembukaan payload push dan Tulis metadata pesan pembukaan payload push.

Catatan: Jika Anda perlu mengirimkan log dari project Google Cloud lain yang tidak terikat ke Google SecOps, seperti dari akun layanan yang dikelola pengguna, Anda harus menyiapkan sink log. Untuk mengetahui informasi selengkapnya tentang sink log, lihat Merutekan log ke tujuan yang didukung.

Menyiapkan feed Amazon Data Firehose

Untuk menyiapkan feed Amazon Data Firehose, lakukan hal berikut:

1. Buat feed Amazon Data Firehose, lalu salin URL endpoint dan kunci rahasia.
2. Buat kunci API untuk mengautentikasi ke Google SecOps. Anda juga dapat menggunakan kembali kunci API yang ada untuk mengautentikasi ke Google SecOps.
3. Tentukan URL endpoint di Amazon Data Firehose.

Membuat feed Amazon Data Firehose

1. Di menu Google SecOps, pilih Setelan, lalu klik Feed.
2. Klik Tambahkan baru.
3. Di kolom Nama feed, masukkan nama untuk feed.
4. Di daftar Source type, pilih Amazon Data Firehose.
5. Pilih Jenis log. Misalnya, untuk membuat feed untuk Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Jenis log.
6. Klik Berikutnya.
7. Opsional: Tentukan nilai untuk parameter input berikut:
   • Pembatas pemisahan: pembatas yang digunakan untuk memisahkan baris log. Anda hanya dapat menggunakan \n.
   • Namespace aset: namespace aset.
   • Label penyerapan: label yang akan diterapkan ke peristiwa dari feed ini.
8. Klik Berikutnya.
9. Tinjau konfigurasi feed baru Anda di layar Selesaikan, lalu klik Kirim.
10. Klik Buat Kunci Rahasia untuk membuat kunci rahasia guna mengautentikasi feed ini.
11. Salin dan simpan kunci rahasia karena Anda tidak dapat melihat rahasia ini lagi. Anda dapat membuat kunci rahasia baru lagi, tetapi pembuatan ulang kunci rahasia akan membuat kunci rahasia sebelumnya tidak berlaku.
12. Di tab Detail, salin URL endpoint feed dari kolom Informasi Endpoint. Anda memerlukan URL endpoint ini saat menentukan setelan tujuan untuk aliran pengiriman di Amazon Data Firehose.
13. Opsional: Klik tombol Feed Diaktifkan untuk menonaktifkan feed. Feed diaktifkan secara default.
14. Klik Done.

Membuat kunci API untuk feed Amazon Data Firehose

Untuk membuat kunci API untuk feed Amazon Data Firehose, lakukan hal berikut:

1. Buka halaman Credentials di konsol Google Cloud .
2. Klik Create credentials, lalu pilih API key.
3. Membatasi akses kunci API ke Chronicle API.

Tentukan URL endpoint

Di Amazon Data Firehose, tentukan endpoint HTTPS dan kunci akses, sebagai berikut:

1. Tambahkan kunci API ke URL endpoint feed dan tentukan URL ini sebagai URL endpoint HTTP dalam format berikut:

     ENDPOINT_URL?key=API_KEY
   

   Ganti kode berikut:

   • ENDPOINT_URL: URL endpoint feed.
   • API_KEY: kunci API untuk mengautentikasi ke Google SecOps.

2. Untuk kunci akses, tentukan kunci rahasia yang Anda peroleh saat membuat feed Amazon Data Firehose.

Menyiapkan feed webhook HTTPS

Sebelum memulai:

• Pastikan projectGoogle Cloud untuk Google SecOps dikonfigurasi dan Chronicle API diaktifkan untuk project tersebut.

• Tautkan instance Google SecOps ke Google Cloud layanan.

  Catatan: Batch data yang dikirim melalui feed Webhook mungkin mengalami penundaan penyerapan jika batas ukuran permintaan atau QPS ditetapkan terlalu rendah. Endpoint push HTTPS mendukung ukuran permintaan maksimum sebesar 4 MB per permintaan dan throughput maksimum 15 K QPS per instance Google SecOps.

Untuk menyiapkan feed webhook HTTPS, lakukan hal berikut:

1. Buat feed webhook HTTPS, lalu salin URL endpoint dan kunci rahasia.
2. Buat kunci API yang ditentukan dengan URL endpoint. Anda juga dapat menggunakan kembali kunci API yang ada untuk melakukan autentikasi ke Google SecOps.
3. Tentukan URL endpoint di aplikasi Anda.

Mengirim beberapa peristiwa dalam satu permintaan webhook

Contoh kode berikut menunjukkan cara memformat isi permintaan tunggal dengan beberapa objek JSON yang dipisahkan oleh baris baru setelah item curl --location:

--header 'Content-Type: application/json' \
--header 'X-goog-api-key: API_KEY' \
--header 'X-Webhook-Access-Key: SECRET' \
--data '{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}
{"principal": {"asset_id": "asset 123"}, "metadata": {"event_type": "GENERIC_EVENT", "product_name": "Product Acme"}}'

Membuat feed webhook HTTPS

1. Di menu Google SecOps, pilih Setelan, lalu klik Feed.
2. Klik Tambahkan baru.
3. Di kolom Nama feed, masukkan nama untuk feed.
4. Dalam daftar Jenis sumber, pilih Webhook.
5. Pilih Jenis log. Misalnya, untuk membuat feed untuk Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Jenis log.
6. Klik Berikutnya.
7. Opsional: Tentukan nilai untuk parameter input berikut:
   • Pembatas pemisahan: pembatas yang digunakan untuk memisahkan baris log. Anda hanya dapat menggunakan \n.
   • Namespace aset: namespace aset.
   • Label penyerapan: label yang akan diterapkan ke peristiwa dari feed ini.
8. Klik Berikutnya.
9. Tinjau konfigurasi feed baru Anda di layar Selesaikan, lalu klik Kirim.
10. Klik Buat Kunci Rahasia untuk membuat kunci rahasia guna mengautentikasi feed ini.
11. Salin dan simpan kunci rahasia karena Anda tidak dapat melihat rahasia ini lagi. Anda dapat membuat kunci rahasia baru lagi, tetapi pembuatan ulang kunci rahasia akan membuat kunci rahasia sebelumnya tidak berlaku.
12. Dari tab Detail, salin URL endpoint feed dari kolom Informasi Endpoint. Anda perlu menentukan URL endpoint ini di aplikasi klien Anda.
13. Opsional: Klik tombol Feed Diaktifkan untuk menonaktifkan feed. Feed diaktifkan secara default.
14. Klik Done.

Membuat kunci API untuk feed webhook

1. Buka halaman Google Cloud konsol Credentials.
2. Klik Create credentials, lalu pilih API key.
3. Membatasi akses kunci API ke Chronicle API.

Tentukan URL endpoint

1. Di aplikasi klien, tentukan endpoint HTTPS, yang tersedia di feed webhook.

2. Aktifkan autentikasi dengan menentukan kunci API dan kunci rahasia sebagai bagian dari header kustom dalam format berikut:

   X-goog-api-key = API_KEY

   X-Webhook-Access-Key = SECRET

   Sebaiknya tentukan kunci API sebagai header, bukan menentukannya di URL. Jika klien webhook Anda tidak mendukung header kustom, Anda dapat menentukan kunci API dan kunci rahasia menggunakan parameter kueri dalam format berikut:

     ENDPOINT_URL?key=API_KEY&secret=SECRET
   

   Ganti kode berikut:

   • ENDPOINT_URL: URL endpoint feed.
   • API_KEY: kunci API untuk mengautentikasi ke Google SecOps.
   • SECRET: kunci rahasia yang Anda buat untuk mengautentikasi feed.

Menyiapkan feed API Kustom

Catatan: Fitur ini tercakup dalam Persyaratan Penawaran Pra-GA dari Persyaratan Khusus Layanan Google Security Operations. Fitur pra-GA mungkin memiliki dukungan terbatas, dan perubahan pada fitur pra-GA mungkin tidak kompatibel dengan versi pra-GA lainnya. Untuk mengetahui informasi selengkapnya, lihat panduan Layanan Dukungan Teknis Google SecOps dan Persyaratan Khusus Layanan Google SecOps.
Jika fitur ini tidak terlihat di lingkungan Anda, lihat Mengelola fitur pratinjau atau hubungi administrator sistem Anda.

Catatan: Fitur ini tidak tersedia untuk semua pelanggan di semua wilayah.

Feed API Kustom Google Security Operations (juga dikenal sebagai Konektor Tanpa Kode) memungkinkan Anda menyerap telemetri dari REST API pihak ketiga menggunakan model berbasis konfigurasi yang fleksibel. Anda dapat mengonfigurasi penarikan data dengan menentukan endpoint, autentikasi, strategi penomoran halaman, dan pengelolaan status langsung di konsol.

Manfaat utama

• Mempercepat integrasi: Aktifkan sumber telemetri baru dalam hitungan menit melalui wizard terpandu tanpa menunggu pembaruan backend.
• Checkpointing dengan status: Memastikan tidak ada duplikasi data dan tidak ada log yang hilang di seluruh siklus polling.
• Penyebaran induk-turunan: Mendukung alur kerja penemuan dua tingkat, seperti mencantumkan resource dan mengambil telemetri terkaitnya.
• Ketahanan dan pembatasan kecepatan otomatis: Mencegah pembatasan vendor dan kehabisan kuota. Untuk penyerapan yang andal dan tanpa gangguan, feed API Kustom secara otomatis menangani respons HTTP 429 dengan backoff eksponensial, mengatur kecepatan permintaan dengan pembatasan kapasitas yang dapat dikonfigurasi dan penundaan tugas yang teratur, serta menerapkan pengamanan. Untuk mengetahui informasi selengkapnya, lihat Pembatasan kapasitas dan panduan throttling.

Prasyarat

Verifikasi prasyarat berikut sebelum membuat feed API Kustom:

• Izin: Untuk membuat atau mengubah feed, Anda harus memiliki peran Admin Chronicle API (roles/chronicle.admin) atau Editor Chronicle API (roles/chronicle.editor).
• Persyaratan API pihak ketiga:
  • URL dasar API yang valid (harus menggunakan https://).
  • Kredensial API (Kunci API, kredensial Autentikasi Dasar, atau Client ID/Secret OAuth 2.0).
  • Dokumentasi API Vendor yang menjelaskan jalur endpoint, parameter permintaan, struktur respons JSON, dan batas kecepatan.
• Akses Secret Manager: Kredensial dienkripsi dan dikelola dengan aman dalam Secret Manager. Identitas layanan yang menjalankan konektor akan otomatis berinteraksi dengan Secret Manager (roles/secretmanager.secretAccessor dan roles/secretmanager.admin).

Mengonfigurasi feed API Kustom

Untuk mengonfigurasi feed API Kustom, lakukan hal berikut:

1. Buka Setelan SIEM > Feed.
2. Klik Tambahkan feed baru.
3. Klik Konfigurasi satu feed.
4. Di kolom Nama feed, masukkan nama deskriptif yang unik (misalnya, 1Password-Audit-Events).
5. Dalam daftar Source type, pilih Custom API.
6. Di daftar Log type, pilih Target Jenis Log Google SecOps.
7. Klik Berikutnya.

8. Di bagian Setelan umum, konfigurasi hal berikut:

   • URL Dasar: Masukkan host utama (misalnya, https://events.1password.com). Host harus diawali dengan https://. Jangan tambahkan sub-jalur atau garis miring di akhir.

   • Frekuensi polling: Tentukan seberapa sering platform memeriksa API untuk telemetri baru, dalam menit. Rentang yang didukung: 5 hingga 2880 menit (default: 15 menit). Untuk feed Standard API (Sequential), 10–15 menit adalah waktu standar; untuk feed List & Detail (Parent-Child), 30–60 menit direkomendasikan untuk memungkinkan eksekusi tugas fan-out penuh tanpa tumpang-tindih.

9. Di bagian Authentication, pilih salah satu metode autentikasi yang didukung, lalu konfigurasi kolom yang diperlukan:

   • Autentikasi Dasar: Masukkan Nama Pengguna (identitas akun API) dan Secret (yaitu, sandi atau token rahasia).
   • Kredensial Klien OAuth 2.0: Lakukan autentikasi menggunakan alur Pemberian Kredensial Klien OAuth 2.0. SecOps Google secara otomatis meminta, menyimpan dalam cache, dan memperbarui token akses pembawa sebelum setiap siklus penyerapan. Masukkan endpoint token OAuth (misalnya, https://auth.vendor.com/oauth/token), ID klien OAuth, dan rahasia klien OAuth.
   • Header Permintaan Kunci API: Lakukan autentikasi menggunakan kunci API kustom yang dimasukkan ke dalam header permintaan (pola REST perusahaan yang paling umum). Masukkan Nama header (misalnya, Authorization atau X-API-Key) dan Nilai header (misalnya, Bearer <SECRET_TOKEN> atau <SECRET_KEY>).
   • Parameter Kueri Kunci API: Lakukan autentikasi menggunakan kunci API kustom yang dimasukkan ke dalam parameter kueri URL. Masukkan Nama parameter kueri (misalnya, api_key) dan Nilai parameter kueri (misalnya, <SECRET_KEY>).
   Catatan: Semua kredensial yang Anda masukkan di sini akan otomatis disamarkan selama entri dan dienkripsi dengan aman di Secret Manager, dengan dukungan opsional untuk kunci enkripsi yang dikelola pelanggan (CMEK).

10. Pilih model konektor yang digunakan API kustom Anda:

    • Standard API (Berurutan): Alur polling linear di mana setiap polling dibangun langsung berdasarkan status polling sebelumnya. Dalam model ini, polling berikutnya menggunakan kursor, token, atau stempel waktu yang diekstrak dari polling sebelumnya untuk mengambil hanya data baru. Pilih kartu ini jika vendor menyediakan endpoint yang langsung menampilkan rekaman peristiwa telemetri (misalnya, 1Password, Okta, SentinelOne, GitHub, atau Slack).
    • Daftar & Detail (Induk-Turunan): Alur penemuan dua tingkat. Feed melakukan panggilan awal (induk) untuk mengambil daftar resource atau objek (misalnya, daftar ID pengguna atau zona). Kemudian, feed secara otomatis memunculkan panggilan lanjutan (turunan) yang bergantung untuk mengambil telemetri mendetail untuk setiap resource yang diidentifikasi. Pilih kartu ini jika vendor API memerlukan pola penemuan dua tingkat: pertama, memanggil endpoint untuk mengambil daftar entitas dinamis (misalnya, zona, akun, project, perangkat), lalu menjalankan permintaan detail lanjutan per entitas untuk mengambil telemetri (misalnya, Cloudflare, AWS CloudWatch, atau Tenable).
    Catatan: Kedua model menggunakan pembuatan titik pemeriksaan, yang merupakan proses pengelolaan status yang mengekstrak dan menyimpan stempel waktu atau ID tertinggi dari polling untuk melanjutkan penyerapan pada siklus berikutnya tanpa kehilangan log atau membuat data duplikat.

11. Jika Anda memilih Standard API (Sequential), lakukan hal berikut:

    1. Di bagian endpoint API, konfigurasi parameter berikut untuk menentukan rute teknis dan kecepatan laju permintaan:
       • Jalur endpoint: Rute API spesifik yang ditambahkan ke URL Dasar (misalnya, /api/v1/auditevents). Ini menentukan resource telemetri yang tepat untuk dikueri.
       • Metode HTTP: Pilih GET untuk mengambil data menggunakan parameter kueri URL, atau POST untuk mengirimkan payload penelusuran atau isi filter.
    2. Isi permintaan: Untuk permintaan POST, berikan payload data JSON. Anda dapat menyematkan variabel titik pemeriksaan dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatasan kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kuota habis selama penomoran halaman multi-halaman.
    4. Opsional: Di bagian Custom headers, konfigurasi Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh target API (misalnya, Content-Type: application/json, Accept: application/json).
    5. Opsional: Di bagian Parameter kueri, konfigurasi Kunci dan Nilai, lalu klik Tambahkan untuk menentukan filter atau opsi tambahan yang ditambahkan ke string kueri URL (misalnya, count=1000, status=active) atau mengikat variabel template dinamis (misalnya, start={{.last_run_time}}).
    6. Di bagian Strategi penomoran halaman: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
       • Tidak Ada: Ambil data dalam satu permintaan tanpa penomoran halaman.
       • Penomoran Halaman Token: Gunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Jalur JSON token halaman berikutnya (misalnya, meta.next_cursor) dan Nama parameter kueri penomoran halaman token (misalnya, cursor).
       • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan jalur JSON link Halaman berikutnya (misalnya, links.next atau @odata.nextLink).
       • Penomoran Halaman Offset: Lewati sejumlah kumpulan data untuk mendapatkan kumpulan berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
       • Penomoran Halaman: Buka nomor halaman berurutan berikutnya. Masukkan Nama parameter kueri nomor halaman (misalnya, page).

    7. Di bagian Checkpointing, konfigurasikan setelan yang memungkinkan konektor mengingat posisi terakhirnya di antara siklus polling berulang:

       • Strategi: Pilih salah satu strategi berikut dan konfigurasi kolom yang diperlukan:
         • Tidak Ada: Ambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
         • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Jalur JSON nilai titik pemeriksaan (misalnya, timestamp atau event_time) dan Variabel titik pemeriksaan (misalnya, last_run_time, yang dirujuk dalam polling berikutnya sebagai {{.last_run_time}}).
         • Kumpulan Data Terbaru: Lacak ID kumpulan data tertinggi untuk mengambil hanya kumpulan data baru. Masukkan Jalur JSON nilai titik pemeriksaan (misalnya, id atau event_id) dan Variabel titik pemeriksaan (misalnya, last_id, dirujuk sebagai {{.last_id}}).
         • Token Iterator: Gunakan token kelanjutan persisten yang disediakan oleh API. Masukkan Jalur JSON nilai titik pemeriksaan dan Variabel titik pemeriksaan (misalnya, iterator_token, dirujuk sebagai {{.iterator_token}}).

    8. Di bagian Pemetaan Respons, berikan aturan yang memberi tahu platform cara menemukan dan mengekstrak log:

       • Jalur JSON data target: Masukkan jalur yang tepat di payload respons API tempat daftar entri log target berada. Untuk array yang dibungkus objek (misalnya, {"items": [...]}), masukkan items. Untuk API yang menampilkan array JSON root secara langsung (misalnya, [{...}, {...}]), biarkan kolom ini benar-benar kosong ([]).

12. Jika Anda memilih Daftar & Detail (Induk-Turunan), lakukan tindakan berikut:

    1. Permintaan Induk (Penemuan): Konfigurasi endpoint yang menampilkan daftar item:
       1. Di bagian endpoint API, konfigurasi parameter berikut untuk menentukan rute teknis dan kecepatan laju permintaan:
          • Jalur endpoint: Rute API tertentu yang ditambahkan ke URL Dasar (misalnya, /api/v1/auditevents). Ini menentukan resource telemetri yang tepat untuk dikueri.
          • Metode HTTP: Pilih GET untuk mengambil data menggunakan parameter kueri URL, atau POST untuk mengirimkan payload penelusuran atau isi filter.
          • Isi permintaan: Untuk permintaan POST, berikan payload data JSON. Anda dapat menyematkan variabel titik pemeriksaan dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatasan kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kuota habis selama penomoran halaman multi-halaman.
       3. Opsional: Di bagian Custom headers, konfigurasi Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh target API (misalnya, Content-Type: application/json, Accept: application/json).
       4. Opsional: Di bagian Parameter kueri, konfigurasi Kunci dan Nilai, lalu klik Tambahkan untuk menentukan filter atau opsi tambahan yang ditambahkan ke string kueri URL (misalnya, count=1000, status=active) atau mengikat variabel template dinamis (misalnya, start={{.last_run_time}}).
       5. Di bagian Strategi penomoran halaman: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
          • Tidak Ada: Ambil data dalam satu permintaan tanpa penomoran halaman.
          • Penomoran Halaman Token: Gunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Jalur JSON token halaman berikutnya (misalnya, meta.next_cursor) dan Nama parameter kueri penomoran halaman token (misalnya, cursor).
          • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan jalur JSON link Halaman berikutnya (misalnya, links.next atau @odata.nextLink).
          • Penomoran Halaman Offset: Lewati sejumlah kumpulan data untuk mendapatkan kumpulan berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
          • Penomoran Halaman: Buka nomor halaman berurutan berikutnya. Masukkan Nama parameter kueri nomor halaman (misalnya, page).
       6. Di bagian Checkpointing, konfigurasikan setelan yang memungkinkan konektor mengingat tempat terakhir kali konektor berhenti di antara siklus polling berulang:
          • Strategi: Pilih salah satu strategi berikut dan konfigurasi kolom yang diperlukan:
            • Tidak Ada: Ambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
            • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Jalur JSON nilai titik pemeriksaan (misalnya, timestamp atau event_time) dan Variabel titik pemeriksaan (misalnya, last_run_time, yang dirujuk dalam polling berikutnya sebagai {{.last_run_time}}).
            • Kumpulan Data Terbaru: Lacak ID kumpulan data tertinggi untuk mengambil hanya kumpulan data baru. Masukkan Jalur JSON nilai titik pemeriksaan (misalnya, id atau event_id) dan Variabel titik pemeriksaan (misalnya, last_id, dirujuk sebagai {{.last_id}}).
            • Token Iterator: Gunakan token kelanjutan persisten yang disediakan oleh API. Masukkan Jalur JSON nilai titik pemeriksaan dan Variabel titik pemeriksaan (misalnya, iterator_token, dirujuk sebagai {{.iterator_token}}).
    2. Ekstraksi data (jembatan): Konfigurasi hal berikut:
       • Jalur JSON ID item: Kolom tertentu dalam respons induk yang secara unik mengidentifikasi setiap entity (misalnya, id atau zone_id). Konektor mengekstrak ID ini dari setiap item dalam array induk.
       • Nama variabel template: Tentukan nama variabel kustom untuk menyimpan ID yang diekstrak (misalnya, zone_id). UI menampilkan badge dinamis: Gunakan {{.zone_id}} di permintaan turunan Anda di bawah.
    3. Permintaan Turunan (Detail): Konfigurasi endpoint yang menampilkan log mendetail untuk setiap item:
       1. Di bagian endpoint API, konfigurasi parameter berikut untuk menentukan rute teknis dan kecepatan laju permintaan:
          • Jalur endpoint: Rute API tertentu yang ditambahkan ke URL Dasar (misalnya, /client/v4/zones/{{.zone_id}}/logs/received). Ini menentukan resource telemetri yang tepat untuk dikueri.
          • Metode HTTP: Pilih GET untuk mengambil data menggunakan parameter kueri URL, atau POST untuk mengirimkan payload penelusuran atau isi filter.
          • Isi permintaan: Untuk permintaan POST, berikan payload data JSON. Anda dapat menyematkan variabel titik pemeriksaan dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatasan kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kuota habis selama penomoran halaman multi-halaman.
       3. Opsional: Di bagian Custom headers, konfigurasi Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh target API (misalnya, Content-Type: application/json, Accept: application/json).
       4. Opsional: Di bagian Parameter kueri, konfigurasi Kunci dan Nilai, lalu klik Tambahkan untuk menentukan filter atau opsi tambahan yang ditambahkan ke string kueri URL (misalnya, count=1000, status=active) atau mengikat variabel template dinamis (misalnya, start={{.last_run_time}}).
       5. Di bagian Strategi penomoran halaman: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
          • Tidak Ada: Ambil data dalam satu permintaan tanpa penomoran halaman.
          • Penomoran Halaman Token: Gunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Jalur JSON token halaman berikutnya (misalnya, meta.next_cursor) dan Nama parameter kueri penomoran halaman token (misalnya, cursor).
          • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan jalur JSON link Halaman berikutnya (misalnya, links.next atau @odata.nextLink).
          • Penomoran Halaman Offset: Lewati sejumlah kumpulan data untuk mendapatkan kumpulan berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
          • Penomoran Halaman: Buka nomor halaman berurutan berikutnya. Masukkan Nama parameter kueri nomor halaman (misalnya, page).
       6. Di bagian Checkpointing, konfigurasikan setelan yang memungkinkan konektor mengingat tempat terakhir kali konektor berhenti di antara siklus polling berulang:
          • Strategi: Pilih salah satu strategi berikut dan konfigurasi kolom yang diperlukan:
            • Tidak Ada: Ambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
            • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Jalur JSON nilai titik pemeriksaan (misalnya, timestamp atau event_time) dan Variabel titik pemeriksaan (misalnya, last_run_time, yang dirujuk dalam polling berikutnya sebagai {{.last_run_time}}).

13. Konfigurasi setelan Penjadwalan & Label berikut:

    • Frekuensi Polling: Pilih interval standar (misalnya, 5m, 1h).
    • Namespace: Tag organisasi opsional.
    • Label Penyerapan: Pasangan nilai kunci untuk RBAC Data.

14. Klik Kirim. Google SecOps melakukan pemeriksaan validasi endpoint dan kredensial otomatis. Jika validasi berhasil, feed akan mulai melakukan polling.

Contoh konfigurasi 1: Peristiwa audit 1Password (Model Standard API (Sequential))

Konfigurasi JSON deklaratif berikut menunjukkan model Standard API (Sequential), dengan pembuatan titik pemeriksaan berbasis kursor untuk 1Password:

{
  "base_url": "https://events.1password.com",
  "polling_frequency": 15,
  "header_auth": {
    "header_key_values": [
      {
        "key": "Authorization",
        "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
      }
    ]
  },
  "primary_request": {
    "request_settings": {
      "endpoint_path": "/api/v1/auditevents",
      "http_method": "POST",
      
      "request_body": "{\"limit\": 1000, \"start_time\": \"{{.last_run_time}}\"}",
      
      "custom_headers": [
        {
          "key": "Content-Type",
          "value": "application/json"
        }
      ],
      "max_requests_per_minute": 5
    },
    "pagination_strategy": {
      "token": {
        "next_page_token_json_path": "additional_items_url",
        "query_param": "cursor"
      }
    },
    "checkpointing": {
      "latest_timestamp_strategy": {
        "checkpoint_value_path": "timestamp",
        "checkpoint_variable": "last_run_time"
      }
    },
    "response_mapping": {
      "target_data_path": ["items"]
    }
  }
}

Contoh konkret konfigurasi 2: Telemetri zona Cloudflare (Model Daftar & Detail (Induk-Turunan))

Konfigurasi JSON deklaratif berikut menunjukkan model fan-out List & Detail (Parent-Child) untuk Cloudflare:

{
 "base_url": "https://api.cloudflare.com",
 "polling_frequency": 30,
 "header_auth": {
   "header_key_values": [
     {
       "key": "Authorization",
       "value": "Bearer <SECRET_STORED_IN_SECRET_MANAGER>"
     }
   ]
 },

 "primary_request": {
   "request_settings": {
     "endpoint_path": "/client/v4/zones",
     "http_method": "GET"
   },
   "response_mapping": {
     "target_data_path": ["result"]
   },
   "pagination_strategy": {
     "none": {}
   },
   "checkpointing": {
     "none_strategy": {}
   },
   "dependent_requests_config": {
     "item_id_json_path": "id",
     "item_id_variable": "zone_id",
     "dependent_requests": [
       {
         "request_settings": {
           "endpoint_path": "/client/v4/zones/{{.zone_id}}/logs/received",
           "http_method": "GET",
           "query_parameters": [
             {
               "key": "start",
               "value": "{{.last_run_time}}"
             },
             {
               "key": "count",
               "value": "1000"
             }
           ],
           "max_requests_per_minute": 5
         },

         "pagination_strategy": {
           "none": {}
         },
         "checkpointing": {
           "latest_timestamp_strategy": {
             "checkpoint_value_path": "EdgeStartTimestamp",
             "checkpoint_variable": "last_run_time"
           }
         },
         "response_mapping": {
           "target_data_path": []
         }
       }
     ]
   }
 }
}

Praktik terbaik API kustom

• Panduan frekuensi polling:
  • Mulai dengan interval polling sedang: Tetapkan interval polling awal ke 15 menit atau 30 menit untuk endpoint bervolume tinggi guna mengamati perilaku kuota API vendor sebelum menurunkannya menjadi 5 menit.
  • Mengoptimalkan untuk fan-out volume tinggi: Untuk feed Induk-Turunan (Daftar & Detail) yang menemukan puluhan atau ratusan resource, Google sangat menyarankan agar Anda menyetel Frekuensi polling ke 30 hingga 60 menit untuk memungkinkan semua tugas turunan yang diatur kecepatannya selesai dengan baik sebelum siklus penemuan berikutnya dimulai.
• Validasi jalur penyerapan: Gunakan dokumentasi vendor atau alat pengujian API untuk mengonfirmasi nama kolom JSON yang tepat untuk stempel waktu sebelum mengonfigurasi pembuatan titik pemeriksaan status.
• Menguraikan API multi-turunan: Jika API pihak ketiga memerlukan pengambilan pemberitahuan dan log audit untuk satu daftar pengguna, buat dua feed turunan tunggal terpisah (satu untuk pemberitahuan dan satu untuk log audit) untuk mempertahankan isolasi yang optimal.

Aturan pembatasan kapasitas dan pembatasan

Untuk mencegah konfigurasi feed pelanggan membebani kuota vendor pihak ketiga atau memonopoli resource sistem, jenis feed API Kustom menerapkan pengamanan otomatis berikut:

• Pengaturan kecepatan permintaan yang dapat dikonfigurasi (pembatasan kapasitas): Permintaan HTTP keluar secara otomatis diatur kecepatannya untuk mencegah terlampauinya batas kapasitas vendor. Kecepatan penyesuaian default adalah 5 permintaan per menit (1 permintaan setiap 12 detik). Anda dapat menyesuaikan ini per endpoint menggunakan kolom Permintaan maksimum per menit di setelan endpoint agar sesuai dengan kuota API yang dipublikasikan vendor Anda.
• Batas permintaan turunan: Untuk feed Induk-Turunan (Daftar & Detail), permintaan penemuan dapat mengirim hingga 500 permintaan turunan per siklus polling.
• Kedalaman fan-out satu tingkat: Konektor secara ketat menerapkan kedalaman fan-out maksimum 1 tingkat (Penemuan induk → Detail turunan). Permintaan dependen bertingkat (panggilan cucu) tidak didukung.
• Batas ukuran payload respons: Ukuran respons HTTP maksimum yang diizinkan untuk setiap permintaan atau halaman adalah 50 MB. Jika API yang tidak berpaginasi menampilkan respons yang melebihi 50 MB, pengambilan akan gagal dengan error resource habis. Untuk mencegah hal ini, selalu konfigurasi parameter kueri penomoran halaman (seperti limit atau page_size) untuk mengambil kumpulan data dalam batch yang lebih kecil.
• Penghentian otomatis HTTP 429: Jika API vendor pihak ketiga merespons dengan HTTP 429 (Terlalu Banyak Permintaan), Google SecOps akan otomatis merekam status dan memulai periode penghentian eksponensial, menghentikan sementara eksekusi tugas hingga periode kuota vendor diisi ulang.

Batasan API kustom

Saat merencanakan jalur penyerapan, perhatikan bahwa jenis feed API Kustom memiliki batasan berikut:

• Dukungan JSON ketat: Hanya respons JSON API yang didukung. Format lain seperti XML, CSV, Parquet, dan Avro tidak didukung.
• Tidak ada penandatanganan permintaan dinamis: API yang memerlukan tanda tangan kriptografi dinamis per permintaan tidak didukung (misalnya, AWS SigV4, Akamai, atau Oracle OCI).
• Tidak ada autentikasi multi-langkah: API yang memerlukan panggilan login terprogram awal untuk menukar kredensial dengan token sesi sementara (seperti Saviynt) sebelum melakukan polling tidak didukung.
• Tidak ada penyerapan WebSockets atau Push: Feed API kustom mendukung polling pull HTTPS standar. Koneksi streaming persisten (WebSockets) dan webhook masuk tidak didukung.
• Tanpa mutual TLS (mTLS): Autentikasi harus mengandalkan kunci API, autentikasi dasar, atau kredensial klien OAuth 2.0 standar. Negosiasi sertifikat sisi klien tidak didukung.

Memecahkan masalah feed API Kustom

Untuk menyelidiki error pada feed API Kustom di Logs Explorer Cloud Logging, gunakan kueri berikut:

resource.type="gce_instance" OR resource.type="generic_task"
jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"

Ganti FEED_ID dengan ID feed Anda.

Untuk memfilter secara khusus permintaan HTTP yang gagal, gunakan kueri berikut:

jsonPayload.service="gopher"
jsonPayload.feed_id="FEED_ID"
jsonPayload.http_status_code >= 400

Ganti FEED_ID dengan ID feed Anda.

Mode kegagalan umum dan solusinya

Gejala / Error	Akar masalah	Solusi / Perbaikan
HTTP 401 Unauthorized / HTTP 403 Forbidden	Kunci API, sandi, atau kredensial OAuth sudah tidak berlaku atau tidak valid.	Edit feed, masukkan kembali kredensial yang valid, lalu klik Kirim.
HTTP 404 Not Found	Template URL Dasar atau Jalur Endpoint salah.	Periksa endpoint dalam dokumentasi API vendor. Pastikan URL Dasar berakhir dengan benar dan Jalur Endpoint dimulai dengan /.
HTTP 429 Too Many Requests	Melebihi batas kapasitas API vendor.	Tingkatkan frekuensi polling atau kurangi parameter limit dalam parameter kueri.
Error Ekstraksi JSON (items_path kosong)	Ketidakcocokan di jalur konfigurasi respons.	Verifikasi struktur payload respons API dan perbarui jalur JSON data target.
Penyerapan Data Duplikat	Stempel waktu konfigurasi status atau jalur ekstraktor ID tidak valid.	Periksa nama kolom rekaman log untuk stempel waktu dan perbarui jalur ekstraktor.

Mengelola feed

Setelah mengonfigurasi feed data, gunakan alat pengelolaan untuk memantau kualitas penyerapan, mengubah parameter yang ada, dan mengelola siklus proses feed. Bagian ini menguraikan cara menafsirkan status feed dan melakukan tugas pemeliharaan penting untuk memastikan visibilitas data yang berkelanjutan.

Halaman Feed menyediakan beberapa alat untuk membantu Anda menjelajahi dan mengatur daftar feed yang dikonfigurasi:

• Penelusuran: Gunakan kotak penelusuran untuk menemukan feed berdasarkan Nama Feed, ID Feed, atau Jenis sumber.

• Filter: Klik ikon filter untuk mempersempit daftar berdasarkan atribut feed tertentu.

• Download CSV: Klik Download sebagai CSV untuk mengekspor daftar feed saat ini ke file CSV.

• Penomoran halaman: Gunakan kontrol penomoran halaman untuk:

  • Ubah jumlah Baris per halaman.

  • Jelajahi beberapa halaman feed menggunakan tab dan panah halaman.

• Waktu terakhir diperbarui: Lihat stempel waktu untuk mengetahui kapan daftar feed terakhir diperbarui.

Melihat feed yang dikonfigurasi

Halaman Feed menampilkan semua feed yang telah Anda konfigurasi.

1. Buka Setelan SIEM > Feed. Halaman utama menampilkan semua feed yang telah Anda konfigurasi.
2. Arahkan kursor ke setiap baris untuk menampilkan menu more_vert Lainnya.
3. Di menu, Anda dapat melihat detail feed, mengedit, menonaktifkan, atau menghapus feed.

Memantau status feed

Anda dapat memantau status feed di halaman Feed awal, tempat feed dapat memiliki status berikut:

• Aktif: Feed dikonfigurasi dan siap untuk menyerap data ke akun Google SecOps Anda.
• InProgress: Google SecOps mencoba menarik data dari pihak ketiga yang dikonfigurasi.
• Selesai: Data berhasil diambil oleh feed ini.
• Diarsipkan: Feed dinonaktifkan.

• Gagal: Feed gagal mengambil data dengan berhasil. Hal ini kemungkinan disebabkan oleh masalah konfigurasi. Klik pertanyaan untuk menampilkan error konfigurasi. Setelah Anda memperbaiki error dan mengirim ulang feed, kembali ke halaman Feed untuk menentukan apakah feed sekarang berfungsi atau tidak.

  Catatan: Kolom Terakhir berhasil pada di halaman Feed menunjukkan terakhir kali data berhasil diambil oleh feed tersebut. Untuk feed baru, kolom ini kosong. Feed push, seperti Webhook dan Google Cloud pubsub tidak mengisi kolom ini. Feed push ini tidak memiliki jadwal, yang berarti data masuk saat data di-push. Untuk feed Amazon SQS (V2), kolom Terakhir berhasil pada menampilkan stempel waktu detak jantung penyerapan aktif. Pembaruan pada kolom ini dibatasi dan dapat tertunda hingga 15 menit.

Mengedit feed yang ada

Di halaman Feed, Anda dapat mengedit feed yang ada, sebagai berikut:

1. Arahkan kursor ke feed yang ada, lalu klik more_vert di kolom kanan.

2. Klik Edit Feed. Sekarang Anda dapat mengubah parameter input untuk feed dan mengirimkannya kembali ke Google SecOps, yang akan mencoba menggunakan feed yang telah diperbarui.

   Catatan: Feed yang ada menampilkan [Tidak Dikonfigurasi] sebagai nama feed di halaman Feed. Edit feed untuk menambahkan nama feed.

Mengaktifkan (melanjutkan) dan menonaktifkan (menjeda) feed

Jika Anda menonaktifkan feed, Google SecOps akan berhenti menyerap data baru dari sumber tersebut. Untuk menghentikan penyerapan data secara langsung, Anda harus menghapus feed. Transfer aktif atau yang dibatasi yang sudah ada akan dilanjutkan hingga selesai. Saat Anda mengaktifkan kembali feed, Google SecOps dapat mengambil data yang terlewat saat feed dinonaktifkan. Kemampuan ini disebut "kemampuan pengisian ulang".

Di kolom Status, feed yang diaktifkan diberi label Aktif, Sedang Berlangsung, Selesai, atau Gagal. Kolom yang dinonaktifkan diberi label Diarsipkan. Untuk mengetahui deskripsinya, lihat Memantau status feed.

Di halaman Feed, Anda dapat mengaktifkan (melanjutkan) atau menonaktifkan (menjeda) feed yang ada:

1. Arahkan kursor ke feed yang ada, lalu klik more_vert di kolom kanan.

2. Opsional: Klik tombol Feed Diaktifkan untuk mengaktifkan feed.

3. Opsional: Klik tombol Nonaktifkan Feed untuk menonaktifkan feed. Feed kini diberi label Diarsipkan.

Pemulihan data saat Anda mengaktifkan kembali feed (kemampuan pengisian ulang)

Kemampuan Google SecOps untuk mengisi ulang data bergantung pada apakah feed Anda berbasis pull (didukung) atau berbasis push (tidak didukung).

Feed berbasis penarikan

Dengan feed ini, Google SecOps menarik data dari sumber eksternal. Feed tarik meliputi:

• Bucket penyimpanan cloud, seperti Amazon S3, Google Cloud Storage, Azure Blob Storage
• Server SFTP

• API pihak ketiga, seperti Microsoft 365, Okta, Proofpoint

  Saat Anda mengaktifkan kembali feed berbasis penarikan, Google SecOps dapat mengambil data yang dihasilkan saat feed dinonaktifkan.

Feed berbasis push

Dengan feed ini, sistem eksternal "mendorong" data ke Google SecOps. Feed push mencakup:

• Webhook HTTPS
• Google Cloud Pub/Sub
• Amazon Kinesis Data Firehose
• Penyerapan API/agen langsung, seperti Bindplane

Google SecOps tidak dapat otomatis memulai pengisian ulang data dari feed berbasis push. Saat feed dinonaktifkan dan sistem Anda mengirimkan data, Google SecOps akan mengirimkan error HTTP 403 Forbidden atau error 4xx umum.

Jika sistem Anda tidak menyimpan dan mencoba lagi mengirim data ke Google SecOps, data akan hilang. Selain itu, jika sistem Anda disetel ke "hapus saat gagal" atau menghapus buffer-nya, data akan hilang secara permanen untuk jangka waktu tersebut. Untuk menghindari kehilangan data, Anda harus mengonfigurasi sistem untuk melakukan buffering dan mengirim ulang data setelah feed diaktifkan kembali. Kemudian, Google SecOps dapat menyerap data yang terlewat saat feed dilanjutkan.

Pertimbangan pengisian ulang

• Batasan sistem sumber: Jumlah data historis yang dapat diisi ulang oleh Google SecOps dari feed berbasis penarikan dibatasi oleh berapa lama sistem sumber menyimpan data dan apa yang diizinkan oleh API-nya. Misalnya, beberapa API hanya memberikan akses ke data tujuh hari terakhir.
• Buffer Google SecOps: Untuk pemulihan otomatis, buffer internal Google SecOps untuk feed berbasis penarikan menyimpan data hingga 90 hari, setelah itu data akan dihapus.
• Batasan tenant: Tenant yang tidak membayar, seperti bukti konsep, mungkin memiliki batasan pada pengisian ulang data lama.
• Kuota penyerapan: Untuk menghindari dampak pada penyerapan data real-time, data pengisian ulang diproses dengan prioritas yang lebih rendah daripada data aktif. Pengisian ulang data berbasis penarikan juga dibatasi lajunya, biasanya hingga sepertiga (33%) dari batas lonjakan tenant Anda per jenis log. Hal ini memastikan feed berbasis push yang penting, seperti agen EDR, tidak terpengaruh secara negatif.
• Pembatasan frekuensi dinamis: Jika pengisian ulang menghabiskan semua kuota penarikan yang tersedia, penyerapan akan dijeda selama sisa interval lima menit dan dilanjutkan secara otomatis saat interval dimulai ulang.
• Penyimpanan cloud: Anda dapat menggunakan setelan feed untuk mengontrol pengisian ulang, seperti filter untuk file baru atau yang diperbarui, atau filter rentang tanggal, seperti "Usia file maksimum".
• Tumpukan data yang besar: Jika tumpukan data yang besar dari feed berbasis penarikan menyebabkan masalah saat diaktifkan kembali, Anda dapat menghubungi Dukungan Google untuk menghapus tumpukan data tersebut. Artinya, feed hanya akan mulai menyerap data baru ke depannya, dan data yang terlewat tidak akan diisi ulang.
• Mengedit feed yang dinonaktifkan: Setiap perubahan konfigurasi yang dilakukan pada feed saat feed dinonaktifkan akan diterapkan segera setelah feed diaktifkan kembali.

Menghapus feed

Di halaman Feed, Anda juga dapat menghapus feed yang ada:

1. Arahkan kursor ke feed yang ada, lalu klik more_vert di kolom kanan.

2. Klik Hapus Feed. Jendela HAPUS FEED akan terbuka. Untuk menghapus feed secara permanen, klik Ya, hapus.

   Catatan: Saat Anda menghapus feed, tidak ada data baru yang akan di-ingest. Mungkin ada data yang sudah dalam antrean yang masih akan diproses.

Untuk feed API Kustom, jendela dialog akan muncul dengan kotak centang opsional: Hapus data backlog yang tertunda:

• Tidak dicentang (Default): Konfigurasi dan kredensial feed dihapus, tetapi data backlog yang diantrekan diizinkan untuk diproses hingga penyerapan.
• Dicentang: Konfigurasi feed, kredensial, dan semua data backlog yang tertunda akan dihapus secara permanen.

Mengontrol kecepatan penyerapan

Jika kecepatan penyerapan data untuk tenant mencapai nilai minimum tertentu, Google Security Operations akan membatasi kecepatan penyerapan untuk feed data baru guna mencegah sumber dengan kecepatan penyerapan yang tinggi memengaruhi kecepatan penyerapan sumber data lain. Dalam kasus ini, terjadi penundaan, tetapi tidak ada data yang hilang. Volume penyerapan dan histori penggunaan tenant menentukan nilai minimum.

Anda dapat meminta peningkatan batas kapasitas dengan menghubungi Cloud Customer Care.

Memecahkan masalah feed yang gagal

Di halaman Feed, Anda dapat melihat detail seperti jenis sumber, jenis log, ID feed, dan status feed yang ada, sebagai berikut:

1. Arahkan kursor ke feed yang ada, lalu klik more_vert di kolom kanan.

2. Klik Lihat Feed. Dialog akan muncul dan menampilkan detail feed. Untuk feed yang gagal, Anda dapat menemukan detail error di bagian Detail > Status.

Untuk feed yang gagal, detailnya mencakup penyebab error dan langkah-langkah untuk memperbaikinya.

Lihat tabel Error Sumber dan Penyerapan untuk mengetahui pesan error yang mungkin Anda temui saat bekerja dengan feed data.

Untuk analisis dan pemecahan masalah aktivitas feed yang mendetail, Anda dapat melihat log di Cloud Logging. Lihat Menganalisis aktivitas feed dengan Cloud Logging.

Perlu bantuan lain? Dapatkan jawaban dari anggota Komunitas dan profesional Google SecOps.