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 disiapkan 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
Gabungkan 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 spesifik berikut:

• Ukuran Baris Maksimum: Satu baris log tidak boleh melebihi 4 MB. Jika satu baris melebihi batas ini, feed akan gagal dengan error MaxLogLineSize4MBExceeded.
• Pemisah 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 mengalami 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 lain 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 mengambil data real-time dan akan menjadi hanya baca.
• Data yang ada: Data apa pun yang telah 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 bagi pelanggan

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

1. Membuat ulang feed berita: Anda harus membuat feed berita baru untuk menggantikan feed berita yang ada sebelum migrasi.
2. Konfigurasi Usia File Maksimum: Saat menyiapkan feed berita baru, tetapkan Usia File Maksimum ke sekitar 2 jam sebelum update BYOP dimulai. Buffer 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 redundan 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 tidak akan dapat dikelola dan tetap berada di antarmuka web Google SecOps sebagai setelan tanpa induk.

Cara menyiapkan feed

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

• SIEM Settings > Feeds (standar)
• Hub Konten > Paket Konten (premium)

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

Menyiapkan daftar IP yang diizinkan

Saat Google SecOps mengambil data dari S3, SQS, Azure, dan API pihak ketiga, infrastruktur Google akan terhubung ke luar ke bucket pelanggan atau API pihak ketiga.

Untuk mengizinkan traffic masuk di bucket penyimpanan atau firewall, Anda harus mengonfigurasi daftar yang diizinkan sesuai dengan jenis feed, seperti yang dijelaskan dalam daftar berikut:

• Feed V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): Feed ini secara eksklusif menggunakan Google Cloud Storage Transfer Service (STS) untuk mengambil data dari penyimpanan pelanggan. Mereka memerlukan daftar yang diizinkan untuk rentang IP STS: ipranges.json.
• API pihak ketiga: Memerlukan goog.json.
• Feed lama (S3, Azure_Blobstore): Memerlukan rentang IP khusus. Untuk mengetahui informasi selengkapnya, hubungi dukungan Google SecOps.
• Azure Event Hub: Memerlukan rentang IP khusus region. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi keamanan jaringan (opsional) di Membuat feed Azure Event Hub.

Catatan: Google SecOps tidak dapat menjamin bahwa semua feed akan secara eksklusif berasal dari alamat IP sesuai dengan region yang ditentukan.

Karena rentang IP Layanan Google berubah secara dinamis, Google merekomendasikan agar Anda mengonfigurasi firewall untuk mengambil dan mengurai feed secara berkala sebagai berikut:

• Feed V2 (S3_V2, SQS_V2, Azure_Blobstore_V2): Transfer data dijalankan secara eksklusif oleh worker Storage Transfer Service. Anda hanya perlu mengambil dan mengurai ipranges.json secara berkala.
• Feed lama (S3, SQS, Azure_Blobstore, Azure Event Hub) dan API pihak ketiga: Koneksi ini berasal dari infrastruktur Google. Anda hanya perlu mengambil dan mengurai goog.json dan cloud.json secara berkala.

Mengonfigurasi feed

Bagian ini menjelaskan cara mengonfigurasi feed Anda secara umum, 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 menggunakan Google Cloud Storage Transfer Service (STS) untuk penyerapan hampir real-time. Untuk mengetahui informasi selengkapnya, lihat Mengupgrade feed data penyimpanan cloud ke framework konektor v2 dan Penghentian 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 Berita Baru.

3. Di halaman berikutnya, klik Konfigurasi satu feed. Catatan: Langkah ini tidak relevan untuk 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)
   • Berbasis Peristiwa Cloud Storage
   • 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 secara eksplisit kepada Google SecOps untuk menghapus pesan dari antrean Amazon SQS.
   • Saat menggunakan feed Amazon SQS (Tidak digunakan lagi), pastikan hanya satu feed yang menggunakan pesan dari antrean. Pesan yang dibaca oleh aplikasi atau feed lain tidak akan diserap ke dalam feed saat ini.
   • Penggunaan 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 serap. 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 Get service account untuk mendapatkan akun layanan yang 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 sumber dan jenis log yang dipilih di tab Set Properties. Tahan kursor ke ikon tanda tanya untuk setiap kolom guna mendapatkan informasi tambahan tentang hal yang perlu Anda berikan.

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

10. Klik Berikutnya.

11. Tinjau konfigurasi feed berita baru Anda di tab Finalize.

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

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

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

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

Untuk menyederhanakan penyiapan, platform ini menyediakan petunjuk penyiapan khusus dan parameter yang telah ditetapkan untuk setiap konfigurasi. Misalnya, untuk CrowdStrike Falcon, Anda dapat membuat beberapa feed unik di jenis log direkomendasikan dan opsional untuk memastikan ada cakupan data yang cukup 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, misalnya, 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 Feed Management untuk melihat ringkasan mendetail dari semua jenis log yang dikonfigurasi.

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 tertentu, termasuk Cloud Storage. Jenis sumber feed ini menyertakan kolom OPSI PENGHAPUSAN SUMBER 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 hapus 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 SOURCE DELETION OPTION, hanya pilih opsi Never delete files.

• 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:

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

Memfilter objek menurut awalan di feed STS

Catatan: Pemfilteran berbasis awalan menggunakan kolom Sertakan awalan (include_prefixes) tersedia dalam Pratinjau Terbatas dan mengharuskan tenant Anda berada dalam daftar yang diizinkan. Untuk mengaktifkan fitur ini (enable_feed_include_prefixes) bagi tenant Anda, hubungi tim akun Google Cloud , Technical Account Manager (TAM), atau Cloud Customer Care. Jika tenant Anda tidak ada dalam daftar yang diizinkan, menyimpan feed dengan awalan akan menampilkan error. Untuk mengetahui detailnya, lihat Error: Generic::failed_precondition: include_prefixes is not enabled for this customer.

Kolom Sertakan awalan (include_prefixes) memfilter objek penyimpanan yang ditransfer oleh Storage Transfer Service (STS) sebelum penyerapan berdasarkan awalan kunci objek. Nilai yang Anda tentukan di kolom ini diteruskan langsung ke ObjectConditions.include_prefixes STS.

Jenis sumber feed STS yang didukung

Pemfilteran berbasis awalan didukung untuk jenis sumber feed STS berikut (feedSourceType):

• Cloud Storage (V2) (GOOGLE_CLOUD_STORAGE_V2) dan Cloud Storage Event Driven (GOOGLE_CLOUD_STORAGE_EVENT_DRIVEN)
• Amazon S3 (V2) (AMAZON_S3_V2) dan Amazon SQS (V2) (AMAZON_SQS_V2)
• Azure Blob Storage (V2) (AZURE_BLOBSTORE_V2) dan Azure Blob Storage Event Driven (AZURE_BLOBSTORE_EVENT_DRIVEN)

Aturan sintaksis dan validasi awalan

Saat Anda mengonfigurasi Sertakan awalan (include_prefixes), ikuti aturan sintaksis dan validasi berikut:

• Tidak ada garis miring di awal: Awalan bersifat relatif terhadap root bucket atau container dan tidak boleh diawali dengan garis miring (/). Misalnya, masukkan logs/audit/, bukan /logs/audit/.
• Garis miring di akhir versus pencocokan sebagian: Garis miring di akhir mengontrol apakah awalan hanya cocok dengan objek dalam folder tertentu atau kunci objek apa pun yang dimulai dengan awalan:
  • Dengan garis miring di akhir: Awalan yang diakhiri dengan / (misalnya, logs/app/) membatasi kecocokan hanya pada objek di dalam folder tersebut. Sertakan garis miring di akhir untuk cakupan tingkat direktori.
  • Tanpa garis miring di akhir: Awalan tanpa / di akhir (misalnya, logs/app) cocok dengan objek apa pun yang dimulai dengan string tersebut, termasuk logs/app_old/ dan logs/application/.
• Kepekaan huruf besar/kecil: Awalan kunci objek sangat peka terhadap huruf besar/kecil.
• Tidak ada karakter pengganti atau ekspresi reguler: Pencocokan pola tidak didukung. Karakter seperti * dan ? diperlakukan sebagai karakter literal.
• Tidak ada nilai kosong: Entri awalan individual tidak boleh kosong atau hanya berisi spasi kosong. Untuk menyerap seluruh bucket atau container, biarkan kolom Include prefixes kosong.
• Namespace yang berbeda dan tidak tumpang-tindih: Awalan tidak boleh menjadi awalan dari awalan lain dalam daftar yang sama. Misalnya, ["logs/", "logs/audit/"] tidak valid, sedangkan awalan yang setara seperti ["logs/audit/", "logs/vpc/"] valid.
• Batas: Feed mendukung hingga 1.000 awalan. Setiap awalan dapat memiliki panjang maksimum 1.024 byte jika berenkode UTF-8 dan tidak boleh berisi karakter enter (\r) atau baris baru (\n).

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 (termasuk detail untuk mengonfigurasi aturan untuk feed V2 berbasis Cloud Storage).

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 Berita 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 log audit Google Kubernetes Engine, pilih Google Kubernetes Engine audit logs sebagai Log Type.
6. Klik Get service account. 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: Konfigurasikan 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 satu tingkat direktori).
     Catatan: Untuk jenis feed Berbasis Peristiwa Cloud Storage, siapkan langganan Pub/Sub untuk Cloud Storage, seperti yang dijelaskan di Mengonfigurasi Pub/Sub.

   • Opsi penghapusan sumber

   • Opsional: Sertakan awalan (opsional). Fitur ini saat ini dalam Pratinjau Terbatas. Untuk mengetahui aturan sintaksis dan detail daftar yang diizinkan, lihat Memfilter objek menurut awalan di feed STS.

   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 level 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 Anda dan memberinya peran IAM Storage Object Admin (roles/storage.objectAdmin).

     • 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 apa yang Anda pilih untuk Opsi Penghapusan Sumber. Jika Anda memilih On Success, berikan peran Storage Legacy Bucket Writer. Jika Anda memilih Never, 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 blobstore Amazon S3 dan Azure Storage ke Google SecOps:

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

STS mengirimkan 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 selalu 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 blobstore 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 worker 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 di 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 worker 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. Membuat feed push Pub/Sub.
2. Tentukan URL endpoint di langganan Pub/Sub.

Catatan: Feed push Pub/Sub harus berada di project Google Cloud Anda yang terikat ke Google SecOps agar langganan dapat melakukan autentikasi. Alat 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 Settings, lalu klik Feeds.
2. Klik Tambahkan baru.
3. Di kolom Feed name, masukkan nama untuk feed.
4. Dalam daftar Source type, pilih Google Cloud Pub/Sub Push.
5. Pilih Jenis log. Misalnya, untuk membuat feed bagi Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Log type.
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 berita baru Anda di layar Finalize, lalu klik Submit.
10. Dari tab Details, salin URL endpoint feed dari kolom Endpoint Information. 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.

Menentukan URL endpoint

Setelah Anda 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 Enable authentication, lalu pilih akun layanan.
4. Nonaktifkan opsi Push payload unwrapping dan Push payload unwrapping write message metadata.

Catatan: Jika Anda perlu mengirim 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 melakukan autentikasi ke Google SecOps. Anda juga dapat menggunakan kembali kunci API yang ada untuk melakukan autentikasi ke Google SecOps.
3. Tentukan URL endpoint di Amazon Data Firehose.

Membuat feed Amazon Data Firehose

1. Di menu Google SecOps, pilih Settings, lalu klik Feeds.
2. Klik Tambahkan baru.
3. Di kolom Feed name, masukkan nama untuk feed.
4. Dalam daftar Source type, pilih Amazon Data Firehose.
5. Pilih Jenis log. Misalnya, untuk membuat feed bagi Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Log type.
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 berita baru Anda di layar Finalize, lalu klik Submit.
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 lagi.
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. Batasi akses kunci API ke Chronicle API.

Menentukan 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 melakukan autentikasi 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 telah dikonfigurasi dan Chronicle API diaktifkan untuk project tersebut.

• Menautkan instance Google SecOps ke layanan Google Cloud .

  Catatan: Batch data yang dikirim melalui feed Webhook mungkin mengalami penundaan penyerapan jika ukuran permintaan atau batas QPS ditetapkan terlalu rendah. Endpoint push HTTPS mendukung ukuran permintaan maksimum 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 satu isi permintaan dengan beberapa objek JSON yang dipisahkan 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 Settings, lalu klik Feeds.
2. Klik Tambahkan baru.
3. Di kolom Feed name, masukkan nama untuk feed.
4. Dalam daftar Jenis sumber, pilih Webhook.
5. Pilih Jenis log. Misalnya, untuk membuat feed bagi Open Cybersecurity Schema Framework, pilih Open Cybersecurity Schema Framework (OCSF) sebagai Log type.
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 berita baru Anda di layar Finalize, lalu klik Submit.
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 lagi.

12. Dari tab Details, salin URL endpoint feed dari kolom Endpoint Information. Anda harus menentukan URL endpoint ini di aplikasi klien Anda.

    Perhatian: Saat mengonfigurasi aplikasi klien, Anda harus menempelkan URL endpoint lengkap yang disalin dari kolom Endpoint Information (berakhiran :importPushLogs). Jangan menempelkan URL konsol Google SecOps generik, yang akan menyebabkan error HTTP 404 Not Found.

    

    Gambar 1. Informasi endpoint feed webhook

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 Credentials di konsol Google Cloud .
2. Klik Create credentials, lalu pilih API key.
3. Batasi akses kunci API ke Chronicle API.

Menentukan URL endpoint

1. Di aplikasi klien Anda, 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 melakukan autentikasi 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 dalam Pratinjau Pribadi dan tidak tersedia untuk semua pelanggan di semua wilayah. Fitur pratinjau pribadi tidak dapat dikelola di halaman Public Preview Manager di platform Google SecOps.

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

Manfaat utama

• Percepat integrasi: Tambahkan sumber telemetri baru dalam hitungan menit melalui wizard terpandu tanpa menunggu update backend.
• Check-point stateful: Memastikan tidak ada duplikasi data dan tidak ada log yang hilang di seluruh siklus polling.
• Fan-out induk-turunan: Mendukung alur kerja penemuan dua tingkat, seperti mencantumkan resource dan mengambil telemetri terkait.
• Ketahanan dan pembatasan kapasitas otomatis: Mencegah throttling vendor dan kehabisan kuota. Untuk penyerapan yang andal dan tanpa gangguan, feed Custom API secara otomatis menangani respons HTTP 429 dengan backoff eksponensial, mengatur kecepatan permintaan dengan pembatasan kapasitas yang dapat dikonfigurasi dan penundaan tugas yang bertahap, serta menerapkan batasan keamanan. Untuk mengetahui informasi selengkapnya, lihat Pedoman pembatasan kapasitas dan throttling.

Prasyarat

Verifikasi prasyarat berikut sebelum membuat feed API Kustom:

• Izin: Untuk membuat atau mengubah feed, Anda harus memiliki peran Chronicle API Admin (roles/chronicle.admin) atau Chronicle API Editor (roles/chronicle.editor).
• Persyaratan API pihak ketiga:
  • URL dasar API yang valid (harus menggunakan https://).
  • Kredensial API (Kunci API, kredensial Basic Auth, atau Client ID/Rahasia Klien OAuth 2.0).
  • Dokumentasi API vendor yang menjelaskan jalur endpoint, parameter permintaan, struktur respons JSON, dan batas kapasitas.
• 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 SIEM Settings > Feeds.
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. Dalam daftar Log type, pilih Jenis Log Google SecOps target.
7. Klik Berikutnya.

8. Di bagian Setelan umum, konfigurasikan hal berikut:

   • URL dasar: Masukkan host utama (misalnya, https://events.1password.com). URL harus diawali dengan https://. Jangan tambahkan subjalur atau garis miring di akhir.

   • Frekuensi polling: Tentukan seberapa sering platform memeriksa API untuk telemetri baru, dalam menit. Rentang yang didukung: 5 hingga 2.880 menit (default: 15 menit). Untuk feed Standard API (Sequential), 10–15 menit adalah 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 konfigurasikan kolom yang diperlukan:

   • Basic Authentication: Masukkan Username (identitas akun API) dan Secret (yaitu, sandi atau token rahasia).
   • Kredensial Klien OAuth 2.0: Melakukan autentikasi menggunakan alur Pemberian Kredensial Klien OAuth 2.0. Google SecOps otomatis meminta, meng-cache, dan memperbarui token akses pemilik sebelum setiap siklus penyerapan. Masukkan OAuth token endpoint (misalnya, https://auth.vendor.com/oauth/token), OAuth client ID, dan OAuth client secret.
   • Header Permintaan Kunci API: Melakukan autentikasi menggunakan kunci API kustom yang dimasukkan ke dalam header permintaan (pola REST perusahaan yang paling umum). Masukkan Header name (misalnya, Authorization atau X-API-Key) dan Header value (misalnya, Bearer <SECRET_TOKEN> atau <SECRET_KEY>).
   • Parameter Kueri Kunci API: Melakukan 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 dimasukkan dan dienkripsi dengan aman di Secret Manager, dengan dukungan kunci enkripsi yang dikelola pelanggan (CMEK) opsional.

10. Pilih model konektor yang digunakan API kustom Anda:

    • Standard API (Berurutan): Alur polling linear yang setiap polling-nya dibuat langsung berdasarkan status polling sebelumnya. Dalam model ini, polling berikutnya menggunakan kursor, token, atau stempel waktu yang diekstrak dari polling sebelumnya untuk mengambil data baru saja. Pilih kartu ini jika vendor menyediakan endpoint yang langsung menampilkan data 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). Feed kemudian secara otomatis menghasilkan panggilan tindak lanjut dependen (turunan) untuk mengambil telemetri mendetail untuk setiap resource yang diidentifikasi. Pilih kartu ini jika API vendor memerlukan pola penemuan dua tingkat: pertama, memanggil endpoint untuk mengambil daftar entitas dinamis (misalnya, zona, akun, project, perangkat), lalu menjalankan permintaan detail tindak lanjut per entitas untuk mengambil telemetri (misalnya, Cloudflare, AWS CloudWatch, atau Tenable).
    Catatan: Kedua model menggunakan checkpointing, yang merupakan proses pengelolaan status yang mengekstrak dan menyimpan stempel waktu atau ID tertinggi dari polling untuk melanjutkan penyerapan dalam siklus berikutnya tanpa melewatkan log atau membuat data duplikat.

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

    1. Di bagian endpoint API, konfigurasikan parameter berikut untuk menentukan rute teknis dan kecepatan 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 checkpoint dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
    3. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatas 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, konfigurasikan Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh API target (misalnya, Content-Type: application/json, Accept: application/json).
    5. Opsional: Di bagian Parameter kueri, konfigurasikan 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 Pagination strategy: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
       • Tidak ada: Mengambil data dalam satu permintaan tanpa paging.
       • Penomoran Halaman Token: Menggunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Next page token JSON path (misalnya, meta.next_cursor) dan Token pagination query parameter name (misalnya, cursor).
       • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan Next page link JSON path (misalnya, links.next atau @odata.nextLink).
       • Paginasi Offset: Melewati sejumlah data tertentu untuk mendapatkan set berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
       • Paginasi Nomor Halaman: Membuka nomor halaman berikutnya secara berurutan. 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 konfigurasikan kolom yang diperlukan:
         • None: Mengambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
         • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Checkpoint value JSON path (misalnya, timestamp atau event_time) dan Checkpoint variable (misalnya, last_run_time, yang direferensikan dalam polling berikutnya sebagai {{.last_run_time}}).
         • Data Terbaru: Lacak ID data tertinggi untuk mengambil data baru saja. Masukkan Checkpoint value JSON path (misalnya, id atau event_id) dan Checkpoint variable (misalnya, last_id, yang direferensikan sebagai {{.last_id}}).
         • Token Iterator: Gunakan token kelanjutan persisten yang disediakan oleh API. Masukkan Checkpoint value JSON path dan Checkpoint variable (misalnya, iterator_token, yang direferensikan sebagai {{.iterator_token}}).

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

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

12. Jika Anda memilih List & Detail (Parent-Child), lakukan tindakan berikut:

    1. Permintaan Induk (Penemuan): Konfigurasi endpoint yang menampilkan daftar item:
       1. Di bagian endpoint API, konfigurasikan parameter berikut untuk menentukan rute teknis dan kecepatan permintaan:
          • Jalur endpoint: Rute API tertentu yang ditambahkan ke URL Dasar (misalnya, /api/v1/auditevents). Tindakan 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 checkpoint dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatas 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, konfigurasikan Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh API target (misalnya, Content-Type: application/json, Accept: application/json).
       4. Opsional: Di bagian Parameter kueri, konfigurasikan 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 Pagination strategy: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
          • Tidak ada: Mengambil data dalam satu permintaan tanpa paging.
          • Penomoran Halaman Token: Menggunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Next page token JSON path (misalnya, meta.next_cursor) dan Token pagination query parameter name (misalnya, cursor).
          • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan Next page link JSON path (misalnya, links.next atau @odata.nextLink).
          • Paginasi Offset: Melewati sejumlah data tertentu untuk mendapatkan set berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
          • Paginasi Nomor Halaman: Membuka nomor halaman berikutnya secara berurutan. Masukkan Nama parameter kueri nomor halaman (misalnya, page).
       6. Di bagian Checkpointing, konfigurasikan setelan yang memungkinkan konektor mengingat posisi terakhirnya di antara siklus polling berulang:
          • Strategi: Pilih salah satu strategi berikut dan konfigurasikan kolom yang diperlukan:
            • None: Mengambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
            • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Checkpoint value JSON path (misalnya, timestamp atau event_time) dan Checkpoint variable (misalnya, last_run_time, yang direferensikan dalam polling berikutnya sebagai {{.last_run_time}}).
            • Data Terbaru: Lacak ID data tertinggi untuk mengambil data baru saja. Masukkan Checkpoint value JSON path (misalnya, id atau event_id) dan Checkpoint variable (misalnya, last_id, yang direferensikan sebagai {{.last_id}}).
            • Token Iterator: Gunakan token kelanjutan persisten yang disediakan oleh API. Masukkan Checkpoint value JSON path dan Checkpoint variable (misalnya, iterator_token, yang direferensikan sebagai {{.iterator_token}}).
    2. Ekstraksi data (jembatan): Konfigurasikan 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.
       • Template variable name: Tentukan nama variabel kustom untuk menyimpan ID yang diekstrak (misalnya, zone_id). UI akan menampilkan badge dinamis: Use {{.zone_id}} in your child request below.
    3. Child Request (Detail): Konfigurasi endpoint yang menampilkan log mendetail untuk setiap item:
       1. Di bagian endpoint API, konfigurasikan parameter berikut untuk menentukan rute teknis dan kecepatan permintaan:
          • Jalur endpoint: Rute API tertentu yang ditambahkan ke URL Dasar (misalnya, /client/v4/zones/{{.zone_id}}/logs/received). Tindakan 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 checkpoint dinamis seperti {"limit": 100, "start_time": "{{.last_timestamp}}"}.
       2. Permintaan maks per menit: Masukkan jumlah maksimum permintaan yang akan dikirim per menit. Ini adalah pembatas 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, konfigurasikan Header name dan Value, lalu klik Add untuk menentukan header HTTP khusus yang diperlukan oleh API target (misalnya, Content-Type: application/json, Accept: application/json).
       4. Opsional: Di bagian Parameter kueri, konfigurasikan 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 Pagination strategy: Pilih mekanisme penomoran halaman yang diperlukan API pihak ketiga untuk menangani set hasil multi-halaman, lalu konfigurasikan kolom yang diperlukan:
          • Tidak ada: Mengambil data dalam satu permintaan tanpa paging.
          • Penomoran Halaman Token: Menggunakan token (kunci kustom) untuk mendapatkan halaman berikutnya. Masukkan Next page token JSON path (misalnya, meta.next_cursor) dan Token pagination query parameter name (misalnya, cursor).
          • Penomoran Halaman Link: Ikuti URL yang diberikan dalam respons untuk mendapatkan lebih banyak data. Masukkan Next page link JSON path (misalnya, links.next atau @odata.nextLink).
          • Paginasi Offset: Melewati sejumlah data tertentu untuk mendapatkan set berikutnya. Masukkan Nama parameter kueri offset (misalnya, offset).
          • Paginasi Nomor Halaman: Membuka nomor halaman berikutnya secara berurutan. Masukkan Nama parameter kueri nomor halaman (misalnya, page).
       6. Di bagian Checkpointing, konfigurasikan setelan yang memungkinkan konektor mengingat posisi terakhirnya di antara siklus polling berulang:
          • Strategi: Pilih salah satu strategi berikut dan konfigurasikan kolom yang diperlukan:
            • None: Mengambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
            • Stempel Waktu Terbaru: Melacak stempel waktu data terbaru. Masukkan Checkpoint value JSON path (misalnya, timestamp atau event_time) dan Checkpoint variable (misalnya, last_run_time, yang direferensikan dalam polling berikutnya sebagai {{.last_run_time}}).

13. Konfigurasikan setelan Scheduling & Labels berikut:

    • Polling Frequency: 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 kredensial dan endpoint otomatis. Jika validasi berhasil, feed akan mulai melakukan polling.

Contoh konfigurasi 1: Peristiwa audit 1Password (Model API Standar (Berurutan))

Konfigurasi JSON deklaratif berikut menunjukkan model Standard API (Sequential), dengan checkpoint 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 konfigurasi konkret 2: Telemetri zona Cloudflare (model Daftar & Detail (Induk-Turunan))

Konfigurasi JSON deklaratif berikut menunjukkan model fan-out Daftar & Detail (Induk-Turunan) 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 ke 5 menit.
  • Optimalkan untuk fan-out bervolume tinggi: Untuk feed Induk-Turunan (Daftar & Detail) yang menemukan puluhan atau ratusan resource, Google sangat menyarankan agar Anda menetapkan Frekuensi polling ke 30 hingga 60 menit agar semua tugas turunan yang diatur kecepatannya dapat diselesaikan 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 checkpointing status.
• Menguraikan API multi-turunan: Jika API pihak ketiga memerlukan pengambilan pemberitahuan dan log audit untuk satu daftar pengguna, buat dua feed turunan tunggal yang terpisah (satu untuk pemberitahuan dan satu untuk log audit) untuk mempertahankan isolasi yang optimal.

Pedoman pembatasan kapasitas dan throttling

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

• Pengaturan kecepatan permintaan yang dapat dikonfigurasi (pembatasan kapasitas): Permintaan HTTP keluar diatur kecepatannya secara otomatis untuk mencegah melebihi batas kapasitas vendor. Kecepatan default adalah 5 permintaan per menit (1 permintaan setiap 12 detik). Anda dapat menyesuaikan hal ini per endpoint menggunakan kolom Max requests per minute 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 menerapkan kedalaman fan-out maksimum 1 tingkat (Penemuan induk → Detail turunan). Permintaan dependen bertingkat (panggilan turunan) tidak didukung.
• Batas ukuran payload respons: Ukuran respons HTTP maksimum yang diizinkan untuk satu permintaan atau halaman adalah 50 MB. Jika API tanpa penomoran halaman menampilkan respons yang melebihi 50 MB, pengambilan akan gagal dengan error resource habis. Untuk mencegahnya, selalu konfigurasikan parameter kueri penomoran halaman (seperti limit atau page_size) untuk mengambil data dalam batch yang lebih kecil.
• Back-off HTTP 429 otomatis: Jika API vendor pihak ketiga merespons dengan HTTP 429 (Terlalu Banyak Permintaan), Google SecOps akan otomatis menangkap status dan memulai periode back-off eksponensial, menjeda eksekusi tugas hingga kuota vendor tersedia kembali.

Batasan API kustom

Saat merencanakan jalur penyerapan, perhatikan bahwa jenis feed Custom API 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 kriptografis 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 polling tidak didukung.
• Tidak ada penyerapan WebSockets atau Push: Feed API kustom mendukung polling pull HTTPS standar. Koneksi streaming persisten (WebSocket) dan webhook masuk tidak didukung.
• Tidak ada Mutual TLS (mTLS): Autentikasi harus mengandalkan kunci API, autentikasi dasar, atau kredensial klien OAuth 2.0 standar. Handshake sertifikat sisi klien tidak didukung.

Memecahkan masalah feed API Kustom

Untuk menyelidiki error feed Custom API 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 permintaan HTTP yang gagal secara khusus, 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 dan solusi umum

Gejala / Error	Akar masalah	Solusi / Cara Mengatasi
HTTP 401 Unauthorized / HTTP 403 Forbidden	Kunci API, sandi, atau kredensial OAuth 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 diakhiri 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.
JSON Extraction Error (items_path empty)	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 data log untuk stempel waktu dan perbarui jalur ekstraktor.

Mengelola feed

Setelah mengonfigurasi feed data, gunakan alat pengelolaan untuk memantau kondisi 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 membuka dan mengatur daftar feed yang dikonfigurasi:

• Telusuri: 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.

  • Buka beberapa halaman feed menggunakan tab dan panah halaman.

• Waktu terakhir dimuat ulang: 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 SIEM Settings > Feeds. Halaman utama menampilkan semua feed yang Anda konfigurasi.
2. Arahkan kursor ke setiap baris untuk menampilkan menu More more_vert .
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 menyerap data ke akun Google SecOps Anda.

  Catatan: Status Aktif menunjukkan bahwa konfigurasi feed diaktifkan, tetapi tidak mencerminkan autentikasi runtime atau kondisi pengumpulan. Jika log tidak diterima dari feed pihak ketiga yang aktif, periksa Health Hub untuk melihat error operasional seperti rahasia yang sudah tidak berlaku atau token yang tidak valid.

• InProgress: Google SecOps mencoba mengambil data dari pihak ketiga yang dikonfigurasi.

• Selesai: Data berhasil diambil oleh feed ini.

• Diarsipkan: Feed dinonaktifkan.

• Gagal: Feed gagal mengambil data. Hal ini mungkin 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 waktu terakhir 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 di-push. Untuk feed Amazon SQS (V2), kolom Terakhir berhasil pada menunjukkan stempel waktu heartbeat penyerapan aktif. Pembaruan pada kolom ini dibatasi dan dapat tertunda hingga 15 menit.

Mengedit feed yang ada

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

1. Arahkan kursor ke feed yang ada dan 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 diperbarui.

   Catatan: Feed yang ada menampilkan [Not Configured] sebagai nama feed di halaman Feeds. Edit feed untuk menambahkan nama feed.

Mengaktifkan (melanjutkan) dan menonaktifkan (menjeda) feed

Saat Anda menonaktifkan feed, Google SecOps akan berhenti menyerap data baru dari sumber tersebut. Untuk segera menghentikan penyerapan data, 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 sebagai Aktif, Sedang Berlangsung, Selesai, atau Gagal. Kolom yang dinonaktifkan diberi label sebagai 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 dan 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 sebagai 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 pull

Dengan feed ini, Google SecOps mengambil data dari sumber eksternal. Feed pull mencakup:

• 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 pull, 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 mengirim data, Google SecOps akan mengirimkan error HTTP 403 Forbidden atau error 4xx umum.

Jika sistem Anda tidak menyimpan dan mencoba mengirim ulang data ke Google SecOps, data tersebut akan hilang. Selain itu, jika sistem Anda disetel ke "drop on failure" atau menghapus buffering-nya, data akan hilang secara permanen untuk periode yang bersangkutan. Untuk menghindari kehilangan data, Anda harus mengonfigurasi sistem untuk melakukan buffering dan mengirim ulang data setelah feed diaktifkan kembali. Google SecOps kemudian 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 pull dibatasi oleh durasi sistem sumber menyimpan data dan hal 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 pull menyimpan data hingga 90 hari, setelah itu data akan dihapus.
• Batasan tenant: Tenant yang tidak membayar, seperti bukti konsep, mungkin memiliki batasan dalam pengisian ulang data lama.
• Kuota penyerapan: Agar tidak memengaruhi penyerapan data real-time, data pengisian ulang diproses dengan prioritas yang lebih rendah daripada data live. Pengisian ulang data berbasis pull juga dibatasi kapasitasnya, biasanya 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 kapasitas dinamis: Jika pengisian ulang menghabiskan semua kuota pull yang tersedia, penyerapan akan dijeda selama sisa interval lima menit dan dilanjutkan secara otomatis saat interval dimulai ulang.
• Cloud Storage: 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".
• Backlog besar: Jika backlog besar dari feed berbasis pull menyebabkan masalah saat diaktifkan kembali, Anda dapat menghubungi Dukungan Google untuk menghapus backlog. 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 dan klik more_vert di kolom kanan.

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

   Catatan: Jika Anda menghapus feed, tidak ada data baru yang akan diserap. Mungkin ada data yang sudah ada dalam antrean yang masih akan diproses.

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

• Tidak dicentang (Default): Konfigurasi dan kredensial feed akan 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

Saat tingkat penyerapan data untuk tenant mencapai batas tertentu, Google Security Operations membatasi tingkat penyerapan untuk feed data baru guna mencegah sumber dengan tingkat penyerapan tinggi memengaruhi tingkat penyerapan sumber data lain. Dalam kasus ini, ada 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 dan 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 mendetail dan pemecahan masalah aktivitas feed, Anda dapat melihat log di Cloud Logging. Lihat Menganalisis aktivitas feed dengan Cloud Logging.

• Error Generic::failed_precondition:

  Error: Generic::failed_precondition: include_prefixes is not enabled for this customer

  Error ini terjadi saat Anda menyimpan feed STS dengan nilai di kolom Include prefixes (include_prefixes), tetapi tenant Google SecOps Anda tidak ada dalam daftar yang diizinkan untuk pemfilteran berbasis awalan.

  Untuk mengatasi error ini, lakukan salah satu tindakan berikut:

  1. Hapus semua awalan dari kolom Sertakan awalan (include_prefixes) dan simpan feed lagi untuk menyerap seluruh bucket atau container.
  2. Hubungi tim akun Google Cloud , Technical Account Manager (TAM), atau Cloud Customer Care Anda untuk meminta akses ke fitur include_prefixes (enable_feed_include_prefixes) untuk tenant Anda. Untuk mengetahui informasi selengkapnya, lihat Memfilter objek menurut awalan di feed STS.

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