Menggunakan UI feed

Didukung di:

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 menurut 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.
  • Pembatas yang Didukung: Newline (\n) dan Carriage Return + Newline (\r\n) didukung.

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 real-time dan akan menjadi hanya baca.
  • Data yang ada: Semua data yang sudah ditransfer ke Google SecOps sebelum migrasi akan otomatis diserap; 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. Buat 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 baru, tetapkan Usia File Maksimum sekitar 2 jam sebelum pembaruan 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 yang berlebihan ini, lihat Mencegah penghapusan duplikat.

  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)

Menyiapkan daftar IP yang diizinkan

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

Untuk memasukkan daftar yang diizinkan pada 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. STS memerlukan rentang IP yang dimasukkan ke daftar yang diizinkan: 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 wilayah. Untuk mengetahui informasi selengkapnya, lihat Mengonfigurasi keamanan jaringan (opsional) di Membuat feed Azure Event Hub.

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 dilakukan secara eksklusif oleh pekerja 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 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

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)
    • 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 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 akan dimasukkan ke feed saat ini.
    • Menggunakan Amazon SQS (Tidak digunakan lagi) sebagai jenis sumber feed hanya didukung untuk log di bucket Amazon S3.

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

    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 log dan sumber yang dipilih di tab Tetapkan Properti. 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 Finalisasi.

  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.

    Menyelesaikan permintaan feed

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 fungsi 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 di bagian 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, 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.

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 menyertakan kolom OPSI PENGHAPUSAN SUMBER dalam alur kerja Tambahkan baru dan Edit feed.

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

    • NEVER: 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).

Contoh penyiapan feed Google Cloud Storage

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

    • Opsi penghapusan sumber

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

  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) kepadanya.
        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 opsi yang Anda pilih untuk Opsi Penghapusan Sumber. Jika Anda memilih Saat Berhasil, 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 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 batasan 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 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 worker STS 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.

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 Log type.
  6. Klik Berikutnya.
  7. Opsional: Tentukan nilai untuk parameter input berikut:
    • Pemisah 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.

Menentukan 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 Pembukaan payload push menulis metadata pesan.

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 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. Dalam 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 kunci API.
  3. Batasi 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:

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 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 lagi.
  12. Dari tab Detail, salin URL endpoint feed dari kolom Informasi Endpoint. Anda harus 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 kunci API.
  3. Membatasi akses kunci API ke Chronicle API.

Tentukan 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 mengautentikasi ke Google SecOps.
    • SECRET: kunci rahasia yang Anda buat untuk mengautentikasi feed.

Menyiapkan feed API Kustom

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 penarikan 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.
  • Checkpointing dengan status: 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 terkaitnya.
  • 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 pengaman. 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 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). Host ini harus dimulai 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 (Berurutan), 10–15 menit adalah waktu standar; untuk feed Daftar & Detail (Induk-Turunan), 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. 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: Mengautentikasi 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>).

  10. Pilih model konektor yang digunakan API kustom Anda:

    • Standard API (Berurutan): Alur polling linear di mana setiap polling 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 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). Feed kemudian 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).

  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 untuk 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.
    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 pembatas kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kehabisan kuota 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 konfigurasi kolom yang diperlukan:
      • Tidak Ada: Mengambil data dalam satu permintaan tanpa penomoran halaman.
      • 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).
      • 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 konfigurasikan kolom yang diperlukan:
        • Tidak Ada: Mengambil semua data yang tersedia tanpa melacak progres di seluruh siklus.
        • Stempel Waktu Terbaru: Lacak 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 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 checkpoint dan Variabel checkpoint (misalnya, iterator_token, yang direferensikan sebagai {{.iterator_token}}).

    8. Di bagian Pemetaan Respons, 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 dibungkus 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, konfigurasi parameter berikut untuk menentukan rute teknis dan kecepatan laju untuk permintaan:
        • Endpoint path: 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 pos 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 pembatas kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kehabisan kuota 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 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 penomoran halaman.
        • 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).
        • 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: Mengambil 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, 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:
      • Item identifier JSON path: 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}} dalam permintaan turunan di bawah.
    3. Permintaan Turunan (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). Hal 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 pos 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 pembatas kapasitas sisi klien untuk mematuhi batas kapasitas API vendor (default: 5 RPM = 1 permintaan setiap 12 detik). Setelan ini mencegah kehabisan kuota 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, 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 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 penomoran halaman.
        • 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).
        • 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: Mengambil 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, dirujuk dalam polling berikutnya sebagai {{.last_run_time}}).

  13. Konfigurasi setelan Penjadwalan & Label 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 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 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 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 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.

Pedoman 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 kecepatan): Permintaan HTTP keluar secara otomatis diatur kecepatannya untuk mencegah terlampauinya batas kecepatan 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 mengirimkan hingga 500 permintaan turunan per siklus polling.
  • Kedalaman fan-out tingkat tunggal: 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 kehabisan resource. Untuk mencegahnya, selalu konfigurasikan parameter kueri penomoran halaman (seperti limit atau page_size) untuk mengambil 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 jendela 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 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 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 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.
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.

    • 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 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 menyerap data ke akun Google SecOps Anda.
  • 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 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.

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. Anda kini dapat mengubah parameter input untuk feed dan mengirimkannya kembali ke Google SecOps, yang akan mencoba menggunakan feed yang telah diupdate.

Mengaktifkan (melanjutkan) dan menonaktifkan (menjeda) feed

Saat Anda menonaktifkan feed, Google SecOps akan berhenti memproses 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) salah satu 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 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 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 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 "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 menyediakan 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 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 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.
  • 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".
  • Tunggakan besar: Jika tunggakan besar dari feed berbasis penarikan menyebabkan masalah saat diaktifkan kembali, Anda dapat menghubungi Dukungan Google untuk menghapus tunggakan 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.

Untuk feed API Kustom, 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 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, 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, 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 mendetail dan pemecahan masalah aktivitas feed, 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.