Arsitektur dan aliran data Google SecOps

Didukung di:

Google secops

Lingkungan keamanan modern menghasilkan data telemetri dalam jumlah besar di seluruh infrastruktur berbasis cloud, microservice, dan endpoint terdistribusi. Arsitektur Security Information and Event Management (SIEM) lama sering kali kesulitan untuk menskalakan volume data ini, sehingga menghasilkan kueri yang lambat dan visibilitas yang terfragmentasi.

Platform Google Security Operations menyediakan lapisan analisis keamanan terpadu berperforma tinggi. Dibangun di infrastruktur yang sama dengan infrastruktur yang digunakan layanan global inti Google, platform ini menyerap dan membuat kueri data telemetri keamanan berskala petabyte dengan latensi sub-detik sekaligus menghilangkan perbedaan lama antara tingkat data hot dan cold.

Dokumen ini menjelaskan arsitektur dan aliran data Google SecOps, yang mencakup penyerapan, normalisasi UDM, deteksi ancaman YARA-L, dan respons otomatis.

Konvergensi kecerdasan, analisis, dan respons

Google SecOps menyatukan kemampuan operasi keamanan yang secara historis terpisah. Platform ini menggabungkan analisis SIEM dan Orkestrasi, Otomatisasi, dan Respons Keamanan (SOAR) ke dalam platform yang terhubung erat. Selain itu, platform ini menyematkan threat intelligence dari Google Threat Intelligence dan VirusTotal beserta kemampuan AI generatif yang didukung oleh Gemini langsung ke dalam alur kerja investigasi dan deteksi.

Ringkasan arsitektur platform

Google SecOps beroperasi sebagai bidang keamanan berbasis cloud khusus yang dibangun di atas infrastruktur inti Google Cloud . Platform ini mewarisi properti skalabilitas, ketahanan, dan performa layanan Google yang mendasarinya, termasuk Spanner dan Colossus.

Konteks sistem

Google SecOps berfungsi sebagai bidang operasional pusat untuk lingkungan keamanan Anda, yang mengelola data di tiga tahap utama:

• Input: Menyerap data telemetri dari lingkungan hybrid, termasuk pengumpul lokal (seperti agen BindPlane), API penyedia cloud, dan konektor Software-as-a-Service (SaaS) pihak ketiga langsung.
• Inti pemrosesan: Menormalisasi data telemetri mentah ke dalam skema UDM terstruktur, mengevaluasi peristiwa menggunakan mesin deteksi YARA-L, dan mengatur alur kerja menggunakan mesin pengelolaan kasus SOAR.
• Output: Memberikan threat intelligence keamanan yang dapat ditindaklanjuti dan insight triase AI kepada analis sekaligus mengirimkan perintah penampungan otomatis kembali ke lingkungan target melalui API dan agen jarak jauh.

Diagram berikut mengilustrasikan konteks sistem dan aliran data.

Keunggulan infrastruktur

Keunggulan arsitektur utama Google SecOps adalah model penyimpanan hot terpadunya. Arsitektur lama memindahkan data telemetri yang lebih lama ke penyimpanan yang jarang diakses, sehingga memperlambat kueri atau memerlukan rehidrasi manual. Sebaliknya, Google SecOps menyimpan semua data telemetri yang diserap dalam status hot aktif yang dapat ditelusuri indeksnya hingga 12 bulan. Desain ini memungkinkan Anda menjalankan kueri di seluruh data historis selama setahun penuh dengan performa yang sama seperti membuat kueri jam terakhir.

Pipeline pengumpulan dan normalisasi data

Google SecOps menggunakan pipeline penyerapan throughput tinggi yang mengubah log mentah tidak terstruktur menjadi Unified Data Model (UDM) terstruktur. Selama normalisasi, pipeline melengkapi setiap peristiwa dengan metadata kontekstual dari Entity Context Graph.

Arsitektur pengumpulan

Penyerapan data terjadi di tiga vektor utama:

• Pengumpul: Pengumpul berbasis agen (seperti agen BindPlane atau agen OpenTelemetry) yang di-deploy dalam jaringan lokal untuk menggabungkan data syslog dan paket. Pengumpul melakukan buffering, mengompresi, dan mengenkripsi data telemetri di lapisan transpor (TLS) sebelum meneruskannya ke Google SecOps.
• API penyerapan: Endpoint REST API langsung yang menyerap data telemetri terstruktur dan tidak terstruktur dari layanan cloud, aplikasi kustom, dan pipeline serverless.
• Integrasi pihak ketiga: Konektor berbasis pull bawaan yang mengambil log, pemberitahuan, dan data direktori langsung dari platform SaaS eksternal dan API cloud (seperti Microsoft 365 atau Microsoft Entra ID).

Alur pipeline pengumpulan dan persiapan data

Diagram berikut menjelaskan langkah-langkah transformasi tertentu dari data mentah ke format UDM.

Ringkasan skema Unified Data Model

Unified Data Model (UDM) menormalisasi log vendor yang berbeda ke dalam satu skema terstruktur. Representasi standar ini menyederhanakan analisis dan penelusuran dengan memastikan bahwa entity yang setara (seperti alamat IP, nama pengguna, atau hash file) menggunakan jalur kolom yang konsisten di semua sumber log.

Arsitektur skema UDM

UDM menggunakan skema hierarkis yang diketik dengan kuat untuk merepresentasikan peristiwa dan entity keamanan. UDM mengatur data ke dalam struktur logis inti berikut:

• Metadata: Konteks tentang peristiwa log itu sendiri, termasuk stempel waktu peristiwa, waktu penyerapan, nama produk vendor, dan jenis peristiwa.
• Principal: Entitas yang bertindak yang memulai aktivitas (seperti pengguna, host, alamat IP, atau proses asal).
• Target: Entity yang secara langsung terpengaruh oleh aktivitas (seperti file target, host tujuan, atau akun pengguna).
• Sumber, perantara, dan pengamat: Peserta jaringan sekunder (seperti proxy penerusan, firewall, atau hop perutean) yang terlibat dalam transaksi.
• Jaringan: Atribut protokol jaringan dan artefak transaksi (termasuk protokol aplikasi, kueri DNS, dan detail permintaan HTTP).
• Hasil keamanan: Hasil tindakan atau tingkat keparahan yang dilaporkan oleh perangkat keamanan (seperti ALLOWED, BLOCKED, atau QUARANTINED).
• Ekstensi: Kolom kustom dan key-value pair khusus vendor yang berada di luar skema inti standar. Untuk mengetahui detail tentang pemetaan definisi dan pengembangan parser, lihat Mengonfigurasi parser kustom dan Kolom UDM penting.

Diagram class UDM

Diagram berikut memberikan cetak biru struktural UDM.

Arsitektur penelusuran

Google SecOps menyediakan mekanisme penelusuran yang efektif dan disesuaikan dengan alur kerja investigasi yang berbeda. Anda dapat membuat kueri data telemetri yang dinormalisasi di seluruh penyimpanan hot, melakukan pencocokan pola terhadap log mentah yang tidak diuraikan, atau menelusuri data kasus terstruktur. Untuk panduan pengoptimalan, lihat Praktik terbaik penelusuran UDM.

Tabel berikut merangkum kemampuan penelusuran utama yang tersedia di seluruh platform:

Jenis penelusuran	Fungsi arsitektur
Penelusuran UDM	Mesin penelusuran terstruktur utama yang membuat kueri peristiwa UDM yang dinormalisasi dan diindeks di seluruh jendela hot 12 bulan. Mesin ini memungkinkan pemfilteran multi-kolom, agregasi, dan korelasi di seluruh sumber log yang berbeda.
Pemindaian log mentah	Memindai string teks asli yang tidak diuraikan dari log yang diserap. Kemampuan ini mendukung ekspresi reguler (`regex`) dan penelusuran substring untuk artefak dan parameter kustom yang tidak dipetakan ke sintaksis UDM tertentu.
Penelusuran bahasa alami	Menggunakan AI Gemini untuk menerjemahkan pertanyaan bahasa alami langsung ke dalam sintaksis penelusuran UDM formal, sehingga mempercepat pembuatan kueri dan alur kerja investigasi.
Penelusuran kasus	Mesin penelusuran khusus dalam lapisan respons yang membuat kueri kasus investigasi, pemberitahuan, playbook, dan metadata entity yang dianotasi dalam database SOAR.

Loop deteksi dan respons ancaman

Arsitektur Google SecOps membuat feedback loop berkelanjutan antara analisis deteksi dan respons otomatis. Aturan deteksi menghasilkan pemberitahuan fidelitas tinggi yang memicu alur kerja respons, sementara hasil investigasi memberikan masukan yang digunakan untuk menyempurnakan dan menyesuaikan logika deteksi di masa mendatang.

Arsitektur funnel deteksi

Mesin deteksi menggunakan pendekatan funnel multi-tahap untuk menyaring data telemetri keamanan mentah dalam jumlah besar menjadi pemberitahuan fidelitas tinggi:

1. Penyerapan dan normalisasi: Log mentah terus diserap dan diformat ke dalam struktur peristiwa UDM standar.
2. Pengayaan: Peristiwa diperkaya secara dinamis dengan pemetaan alias, data aset kontekstual, dan threat intelligence global dari sumber seperti Google Threat Intelligence.
3. Evaluasi deteksi: Mesin YARA-L 2.0 stateful mengevaluasi peristiwa yang diperkaya terhadap aturan perilaku dan ancaman di seluruh periode waktu yang diperpanjang. Untuk panduan pengoptimalan aturan, lihat Praktik terbaik YARA-L.
4. Penentuan prioritas dan pengelompokan: Deteksi yang cocok diagregasi ke dalam pemberitahuan, diberi skor risiko dinamis, dan dikelompokkan ke dalam kasus terpadu.

Dengan menggabungkan data aset kontekstual dengan threat intelligence, strategi funnel ini memfilter anomali yang tidak berbahaya (mengurangi positif palsu) dan menyoroti ancaman yang sebenarnya (mengurangi negatif palsu), sehingga membantu tim keamanan Anda berfokus pada insiden yang dapat ditindaklanjuti.

Loop perbaikan dan masukan otomatis

Pipeline deteksi dan respons menggabungkan evaluasi aturan stateful dengan triase dan penampungan otomatis:

1. Evaluasi berkelanjutan: Data telemetri UDM yang diperkaya di-streaming melalui mesin deteksi YARA-L 2.0 stateful.
2. Pembuatan kasus dan triase AI: Saat kondisi aturan terpenuhi, Google SecOps akan membuat pemberitahuan dan membuka kasus. Agen Triase dan Investigasi yang didukung AI menjalankan penelusuran dinamis dan pencarian threat intelligence untuk mengevaluasi temuan.
3. Eksekusi playbook otomatis: Jika triase AI mengonfirmasi positif sebenarnya, platform akan memicu playbook respons otomatis (seperti mengisolasi endpoint atau menangguhkan akun pengguna melalui agen jarak jauh). Jika diklasifikasikan sebagai positif palsu, kasus akan ditutup secara otomatis.
4. Penyesuaian berkelanjutan: Hasil perbaikan dan putusan triase analis di-loop kembali untuk menyempurnakan batas deteksi dan mengurangi positif palsu di masa mendatang.

Lapisan deteksi ancaman

Mesin YARA-L 2.0 mengevaluasi data telemetri UDM yang masuk menggunakan pipeline streaming multi-tahap untuk mendeteksi anomali perilaku dan pola serangan multi-peristiwa di seluruh periode waktu yang diperpanjang. Anda juga dapat membuat dan menyempurnakan aturan YARA-L menggunakan Gemini.

Siklus proses untuk setiap aturan YARA-L mengikuti lima tahap evaluasi yang berbeda:

1. Penyerapan (Ingest): Peristiwa UDM yang diperkaya memasuki pipeline evaluasi deteksi secara real time.
2. Pemfilteran (Filter): Peristiwa yang masuk dievaluasi terhadap kriteria peristiwa aturan (bagian events). Peristiwa yang tidak cocok akan dihapus, sedangkan peristiwa yang cocok akan diteruskan ke evaluasi stateful.
3. Penetapan jendela yang cocok (Window): Peristiwa yang cocok dikelompokkan berdasarkan kunci korelasi yang ditentukan di seluruh jendela waktu yang ditentukan (mulai dari detik hingga 12 bulan). Mesin melacak beberapa timer stateful serentak (TimerStart hingga TimerEnd) saat peristiwa terakumulasi.
4. Evaluasi kondisi (Condition): Saat jendela yang cocok ditutup atau dipicu, mesin akan mengevaluasi persyaratan batas dan ekspresi matematika yang ditentukan di bagian condition aturan (seperti jumlah peristiwa, batas yang berbeda, atau gabungan data lintas).
5. Pemicuan (Trigger): Jika kondisi dievaluasi menjadi True, mesin akan membuat deteksi, memicu pemberitahuan, dan membuka atau memperbarui kasus di lapisan respons. Jika False, status akan dihapus tanpa memicu pemberitahuan.

State machine eksekusi aturan

Diagram berikut mengilustrasikan siklus proses eksekusi aturan.

Arsitektur respons dan eksekusi jarak jauh

Google SecOps SOAR merepresentasikan pilar respons platform. Platform ini beroperasi sebagai mesin orkestrasi di atas lapisan analisis untuk menyerap pemberitahuan, melakukan triase kasus, dan menjalankan alur kerja respons otomatis.

Orkestrasi, otomatisasi, dan investigasi

Lapisan respons mencakup alat khusus yang dirancang untuk menyederhanakan alur kerja Pusat Operasi Keamanan (SOC) di seluruh investigasi, pengelolaan kasus, dan otomatisasi playbook:

• Pengelolaan kasus: Mengelompokkan pemberitahuan terkait ke dalam kasus terpadu, mengurutkan dan memfilter antrean insiden, menetapkan tugas, dan berkolaborasi dalam investigasi dengan pelacakan audit lengkap.
• Desainer playbook: Mem-build playbook respons otomatis menggunakan kanvas visual tanpa kode dengan tindakan integrasi bawaan.
• Lingkungan pengembangan terintegrasi (IDE): Menggunakan IDE berbasis kode bawaan untuk menulis skrip Python kustom, mengubah integrasi tindakan yang ada, dan men-debug alur kerja otomatisasi yang kompleks.
• Tampilan investigasi dan investigator grafik: Memvisualisasikan jalur serangan dan hubungan entity menggunakan tampilan investigasi berbasis grafik. Ringkasan entity khusus (seperti tampilan Aset, Alamat IP, Hash, Domain, dan Pengguna) menampilkan peristiwa linimasa yang relevan secara instan.
• Dasbor dan pelaporan: Melacak metrik operasional SOC, beban kerja analis, dan waktu rata-rata respons (MTTR) menggunakan dasbor bawaan atau widget pelaporan kustom.

Arsitektur komponen SOAR

Diagram berikut mengilustrasikan cara pemberitahuan yang masuk mengalir ke mesin pengelolaan kasus dan memicu alur kerja perbaikan otomatis di seluruh playbook visual dan integrasi IDE kustom.

Arsitektur agen jarak jauh

Untuk menjalankan tindakan perbaikan dalam jaringan pribadi (seperti pusat data lokal atau virtual private cloud), Google SecOps mengandalkan arsitektur agen jarak jauh yang aman dan hanya keluar.

Dalam model ini, platform Google SecOps tidak pernah memulai koneksi masuk ke lingkungan pribadi Anda:

1. Inisiasi tugas: Saat tindakan playbook memerlukan eksekusi lokal, Google SecOps akan memublikasikan instruksi di seluruh antrean penayang yang aman yang dihosting di Google Cloud.
2. Polling asinkron: Agen jarak jauh yang di-deploy di dalam lingkungan pribadi Anda terus melakukan polling antrean penayang melalui koneksi keluar yang dienkripsi TLS.
3. Eksekusi lokal: Saat instruksi tugas diambil, agen jarak jauh akan menjalankan tindakan yang diperlukan secara lokal terhadap alat keamanan internal atau endpoint jaringan (seperti menonaktifkan akun atau memblokir port firewall).
4. Pelaporan status: Setelah selesai, agen jarak jauh akan menampilkan status tindakan dan log eksekusi ke antrean penayang melalui TLS, tempat status dan log tersebut diambil dan ditampilkan dalam tampilan kasus SOAR.

Keamanan, kepatuhan, dan tanggung jawab bersama

Sebagai platform berbasis cloud, Google SecOps beroperasi berdasarkan model tanggung jawab bersama: Google bertanggung jawab atas keamanan platform, sedangkan Anda bertanggung jawab atas keamanan di platform.

Model tanggung jawab bersama

Google SecOps mewarisi desain keamanan inti, kemampuan komputasi, dan arsitektur penyimpanan Google Cloud infrastruktur. Dalam model ini:

• Google mengelola: Keamanan pusat data fisik, infrastruktur cloud yang mendasarinya, ketersediaan platform, dan enkripsi data dalam penyimpanan dan saat transit secara default.
• Anda mengelola: Tata kelola data, kontrol akses dan RBAC data yang dikonfigurasi melalui Identity and Access Management (IAM), aturan deteksi kustom, dan setelan kepatuhan tenant.

Semua persyaratan kepatuhan, aturan residensi data, dan kebijakan akses diwarisi dan diterapkan dari hierarki organisasi Anda hingga ke folder dan project ke tenant yang dikontrol kepatuhannya.

Kepatuhan dan kesiapan perusahaan

Untuk memenuhi persyaratan tata kelola organisasi dan peraturan yang ketat, Google SecOps menawarkan tenant yang dikontrol kepatuhannya. Tenant ini menerapkan standar keamanan yang ketat melalui Assured Workloads, yang mendukung framework kepatuhan terhadap peraturan dan paket perlindungan data teknis.

Framework kepatuhan terhadap peraturan yang didukung:

• FedRAMP: Tingkat dampak Sedang dan Tinggi (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Tingkat Dampak DoD: IL4 dan IL5 (IL4_AND_IL5)
• Layanan Kesehatan dan Keuangan: HIPAA dan PCI DSS (HIPAA, PCI_DSS)

Untuk men-deploy tenant yang dikontrol kepatuhannya, tautkan instance Google SecOps Anda ke a Google Cloud project yang berada dalam folder Assured Workloads yang dikonfigurasi untuk paket kontrol yang diperlukan.

Residensi data dan transparansi akses

Google SecOps menerapkan isolasi tenant logis yang ketat dan mendukung Transparansi Akses untuk memberi Anda kontrol yang dapat diverifikasi dan visibilitas audit atas akses data administratif.

Paket residensi dan keamanan data yang didukung:

• Kunci enkripsi yang dikelola pelanggan (CMEK): Mengontrol dan mengelola kunci yang digunakan untuk mengenkripsi data dalam penyimpanan (CMEK_V1).
• Residensi data lanjutan: Menerapkan batas residensi data regional dan kontrol akses administratif (DRZ_ADVANCED).
• Kontrol Layanan VPC: Membuat perimeter yang aman dan disesuaikan di sekitar resource keamanan cloud Anda menggunakan Kontrol Layanan VPC (VPC-SC).

Arsitektur keamanan platform mengandalkan model pewarisan empat lapis, tempat kontrol keamanan administratif Anda dibangun berdasarkan fondasi infrastruktur Google inti yang diperkuat:

Stack keamanan empat lapis:

1. Lapisan kontrol keamanan pelanggan: Kontrol administratif tingkat atas Anda, termasuk kontrol akses berbasis peran (RBAC) yang dikelola melalui Identity and Access Management (IAM), Kunci Enkripsi yang Dikelola Pelanggan (CMEK), dan kebijakan residensi data regional.
2. Lapisan keamanan platform: Isolasi tenant logis, enkripsi default untuk data dalam penyimpanan dan saat transit (TLS), serta logging audit Transparansi Akses.
3. Lapisan infrastruktur Google: Infrastruktur komputasi dan penyimpanan inti, termasuk pengelolaan cluster Borg, penyimpanan terdistribusi Colossus, dan database global Spanner.
4. Lapisan keamanan fisik: Keamanan dasar yang didukung oleh pusat data perusahaan Google, kontrol biometrik multi-faktor, dan chip keamanan Titan kustom (roots of trust).

Misalnya, saat Transparansi Akses diaktifkan, jika spesialis dukungan atau teknik Google mengakses data tenant Anda untuk menyelesaikan tiket dukungan, mereka harus mengirimkan justifikasi akses kriptografi yang valid. Permintaan akses ini dicatat dengan aman dan ditampilkan di log audit Anda secara hampir real time.

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