Patching keamanan

Dokumen ini menjelaskan cara Google mengelola kerentanan dan patch keamanan untuk Google Kubernetes Engine (GKE). Informasi ini mungkin berguna bagi spesialis Keamanan yang mendukung penyelesaian masalah atau kerentanan keamanan yang memerlukan bantuan strategis, seperti insiden dan masalah yang ditingkatkan dari dukungan.

Patching tanggung jawab bersama

Patching merupakan tanggung jawab bersama antara Google dan pelanggan. Platform yang berbeda memiliki tanggung jawab bersama yang berbeda. Lihat topik berikut di setiap platform untuk detail selengkapnya:

Cara kami menemukan kerentanan

Google telah melakukan investasi besar pada desain dan hardening keamanan proaktif, bahkan sistem software dengan desain terbaik sekalipun memiliki kerentanan. Untuk menemukan kerentanan tersebut dan melakukan patch sebelum dapat dieksploitasi, Google telah melakukan investasi yang signifikan di berbagai bidang.

Untuk tujuan patching, GKE adalah lapisan Sistem Operasi (OS) dengan container yang berjalan di atasnya. Sistem operasi, Container-Optimized OS atau Ubuntu, telah diperkuat dan berisi jumlah minimum software yang diperlukan untuk menjalankan container. Fitur GKE berjalan sebagai container di atas image dasar. GKE secara konsisten berupaya mengurangi jumlah dependensi yang dimiliki komponen sistem, yang membantu mengurangi potensi serangan dan meningkatkan efisiensi pengelolaan kerentanan. Misalnya, komponen sistem GKE dapat menggunakan image dasar minimal jika memungkinkan.

Google mengidentifikasi dan memperbaiki kerentanan dan patch yang tidak ada dengan cara berikut:

  • Container-Optimized OS: Google memindai image untuk mengidentifikasi potensi kerentanan dan patch yang tidak ada. Tim Container-Optimized OS meninjau dan menyelesaikan masalah.

  • Ubuntu: Canonical memberi Google build OS dengan semua patch keamanan yang tersedia dan diterapkan.

Google memindai container menggunakan Container Registry Artifact Analysis untuk menemukan kerentanan dan patch yang tidak ada di Kubernetes dan container yang dikelola Google. Jika perbaikan tersedia, pemindai secara otomatis memulai proses patch dan rilis.

Selain pemindaian otomatis, Google menemukan dan melakukan patch pada kerentanan yang tidak diketahui oleh pemindai dengan cara berikut.

Google melakukan audit, pengujian penetrasi, dan penemuan kerentanan sendiri di seluruh platform. Untuk mengetahui daftar platform, lihat bagian sebelumnya Tanggung jawab bersama patching.

Tim khusus di dalam Google dan vendor keamanan pihak ketiga tepercaya melakukan riset serangan mereka sendiri. Google juga bekerja sama dengan CNCF untuk menyediakan banyak keahlian konsultasi teknis dan organisasi untuk audit keamanan Kubernetes.

Google secara aktif berinteraksi dengan komunitas riset keamanan melalui beberapa vulnerability reward program. Vulnerability reward program khusus memberikan hadiah signifikan, termasuk $133.337 untuk kerentanan cloud terbaik yang ditemukan setiap tahunnya. Google Cloud Untuk GKE, ada program yang memberikan reward kepada peneliti keamanan jika mereka dapat merusak kontrol keamanan kami. Program ini mencakup semua dependensi software GKE.

Google berkolaborasi dengan partner software open source dan industri lain yang membagikan kerentanan, riset keamanan, dan patch sebelum rilis publik kerentanan tersebut. Tujuan dari kolaborasi ini adalah untuk melakukan patch infrastruktur Internet dalam jumlah besar sebelum kerentanan diumumkan kepada publik. Dalam beberapa kasus, Google berkontribusi terhadap kerentanan yang ditemukan dalam komunitas ini. Misalnya, Project Zero Google menemukan dan memublikasikan kerentanan Spectre and Meltdown. Tim Keamanan juga secara rutin menemukan dan memperbaiki kerentanan di Kernel-based Virtual Machine (KVM). Google Cloud

Kolaborasi keamanan Google terjadi di berbagai level. Terkadang masalah ini terjadi secara formal melalui program yang didaftarkan oleh organisasi untuk menerima notifikasi pra-rilis terkait kerentanan software untuk produk seperti Kubernetes dan Envoy. Kolaborasi juga terjadi secara informal karena interaksi kami dengan banyak project open source, seperti kernel Linux, runtime container, teknologi virtualisasi, dan lainnya.

Untuk Kubernetes, Google adalah anggota aktif dan pendiri Security Response Committee (SRC) dan menulis banyak Proses Rilis Keamanan. Google adalah anggota dari Daftar Distributor Kubernetes yang menerima notifikasi kerentanan sebelumnya dan telah terlibat dalam triase, patching, pengembangan mitigasi, dan komunikasi dalam hampir setiap kerentanan keamanan Kubernetes yang serius. Google juga menemukan beberapa kerentanan Kubernetes, seperti CVE-2019-11254, CVE-2019-11255, dan CVE-2021-25741.

Meskipun kerentanan yang tidak terlalu parah ditemukan dan di-patch di luar proses ini, sebagian besar kerentanan keamanan yang penting dilaporkan secara pribadi melalui salah satu saluran yang sebelumnya tercantum. Pelaporan awal memberi Google waktu sebelum kerentanan menjadi publik untuk meneliti pengaruhnya terhadap GKE, mengembangkan patch atau mitigasi, serta menyiapkan saran dan komunikasi untuk pelanggan. Jika memungkinkan, Google akan melakukan patch pada semua cluster sebelum rilis publik kerentanan.

Cara kerentanan diklasifikasikan

GKE melakukan investasi besar dalam memperkuat keamanan pada seluruh stack, termasuk OS, container, Kubernetes, dan lapisan jaringan, selain menetapkan setelan default yang baik, konfigurasi yang di-hardening dengan keamanan, dan komponen terkelola. Gabungan upaya ini membantu mengurangi dampak dan kemungkinan kerentanan.

Tim keamanan GKE mengklasifikasikan kerentanan berdasarkan sistem penskoran kerentanan Kubernetes. Klasifikasi mempertimbangkan banyak faktor, termasuk konfigurasi dan hardening keamanan GKE. Karena faktor-faktor ini dan investasi yang dilakukan GKE dalam keamanan, klasifikasi kerentanan GKE mungkin berbeda dengan sumber klasifikasi lainnya.

Tabel berikut menjelaskan kategori tingkat keparahan kerentanan:

Keparahan Deskripsi
Penting Kerentanan mudah dieksploitasi di semua cluster oleh penyerang jarak jauh yang tidak diautentikasi yang mengakibatkan penyusupan sistem sepenuhnya.
Tinggi Kerentanan mudah dieksploitasi oleh banyak cluster yang mengakibatkan hilangnya kerahasiaan, integritas, atau ketersediaan.
Sedang Kerentanan yang dapat dieksploitasi untuk beberapa cluster di mana hilangnya kerahasiaan, integritas, atau ketersediaan dibatasi oleh konfigurasi umum, kesulitan eksploitasi itu sendiri, akses yang diperlukan, atau interaksi pengguna.
Rendah Semua kerentanan lainnya. Eksploitasi tidak mungkin dilakukan atau konsekuensi dari eksploitasi terbatas.

Lihat buletin keamanan untuk mengetahui contoh kerentanan, perbaikan dan mitigasi, serta ratingnya.

Cara kerentanan di-patch untuk cluster GKE

Melakukan patch pada kerentanan melibatkan upgrade ke nomor versi GKE yang baru. Versi GKE mencakup komponen berversi untuk sistem operasi, komponen Kubernetes, dan container lain yang membentuk platform GKE. Perbaikan beberapa kerentanan hanya memerlukan upgrade bidang kontrol, yang dilakukan secara otomatis oleh Google di GKE, sementara yang lain memerlukan upgrade bidang kontrol dan node.

Agar cluster tetap di-patch dan diperkuat dari kerentanan pada semua tingkat keparahan, kami merekomendasikan penggunaan upgrade node otomatis di GKE (aktif secara default). Untuk cluster yang terdaftar di saluran rilis, rilis patch dipromosikan karena memenuhi persyaratan kualifikasi setiap saluran. Jika memerlukan rilis patch GKE sebelum mencapai saluran cluster, Anda dapat mengupgrade secara manual ke versi patch jika rilis patch menggunakan versi minor yang sama dengan yang tersedia di saluran rilis cluster Anda.

Di platform lain tempat cluster berjalan, Google merekomendasikan untuk mengupgrade setidaknya setiap bulan. Untuk mengetahui daftar platform, lihat bagian sebelumnya Tanggung jawab bersama patching.

Beberapa pemindai keamanan atau pemeriksaan versi manual mungkin salah mengasumsikan bahwa komponen seperti runc atau containerd tidak memiliki patch keamanan upstream tertentu. GKE secara rutin melakukan patch pada komponen dan hanya melakukan upgrade versi paket jika diperlukan, yang berarti komponen GKE secara fungsional mirip dengan komponen upstream-nya meskipun nomor versi komponen GKE tidak cocok dengan nomor versi upstream. Untuk mengetahui detail tentang CVE tertentu, lihat buletin keamanan GKE.

Melakukan patch pada linimasa

Tujuan Google adalah memitigasi kerentanan yang terdeteksi dalam jangka waktu yang sesuai dengan risiko yang dimiliki. GKE disertakan dalam Google Cloud's ATO sementara FedRAMP yang mengharuskan perbaikan kerentanan yang diketahui dalam jangka waktu tertentu sesuai dengan tingkat keparahannya sebagaimana ditentukan dalam kontrol RA-5(d) dari catatan Penilaian Risiko (RA) RA-5, "Pemindaian Kerentanan", dalam spreadsheet FedRAMP Security Controls Baseline.

Untuk setiap kerentanan yang diketahui, tujuan GKE adalah merilis versi patch yang memperbaiki kerentanan dalam jangka waktu yang sesuai. ATO sementara Google Cloud FedRAMP tidak mencakup Google Distributed Cloud, GKE di AWS, GKE di Azure, atau cluster terlampir GKE, tetapi kami menargetkan jangka waktu perbaikan yang sama untuk produk tersebut. Setelah GKE menyediakan versi patch untuk memperbaiki kerentanan yang diketahui, upgrade cluster Anda ke versi tersebut untuk memenuhi jangka waktu patching bagi organisasi Anda.

Bagaimana kerentanan dan patch dikomunikasikan

Sumber terbaik untuk informasi terkini tentang kerentanan dan keamanan patch adalah di feed buletin keamanan untuk produk berikut:

  • Google Kubernetes Engine (GKE)
  • Google Distributed Cloud (khusus software) di VMware
  • GKE di AWS
  • GKE di Azure
  • Google Distributed Cloud (khusus software) di bare metal

Buletin ini mengikuti skema penomoran kerentanan yang umum Google Cloud dan ditautkan dari halaman buletin utama Google Cloud dan Catatan Rilis GKE. Setiap halaman buletin keamanan memiliki feed RSS tdi mana pengguna dapat berlangganan info terbaru.

Kerentanan terkadang dirahasiakan di bawah embargo selama waktu terbatas. Embargo membantu mencegah publikasi awal kerentanan yang dapat menyebabkan upaya eksploitasi secara luas sebelum langkah-langkah dapat diambil untuk mengatasinya. Dalam situasi embargo, catatan rilis merujuk pada "update keamanan" hingga embargo dicabut. Setelah embargo dicabut, Google memperbarui catatan rilis untuk menyertakan kerentanan tertentu.

Tim keamanan GKE memublikasikan buletin keamanan untuk kerentanan tingkat keparahan Tinggi dan Penting. Saat tindakan pelanggan diperlukan untuk mengatasi kerentanan Tinggi dan Penting ini, Google akan menghubungi pelanggan melalui email. Selain itu, Google juga dapat menghubungi pelanggan untuk memberikan kontrak dukungan melalui saluran dukungan.

Apa cara tercepat untuk menginstal patch keamanan?

Semua cluster akan otomatis tetap di-patch dengan upgrade otomatis GKE. Bagian ini menjelaskan cara melakukan patch lebih cepat daripada upgrade otomatis untuk perbaikan keamanan tertentu, atau secara berkelanjutan. Dengan menggabungkan lingkungan pengujian, upgrade manual lintas saluran, setelan patch yang dipercepat, dan notifikasi berbasis peristiwa, Anda dapat mengurangi waktu tunggu patching.

GKE mengelola peluncuran versi di seluruh saluran rilis untuk memastikan versi baru memenuhi syarat dan diuji. Untuk mengurangi waktu tunggu patching, Anda harus memahami cara kerja peluncuran ini, lalu menyesuaikan perilaku default agar sesuai dengan kebutuhan spesifik Anda.

Menguji versi yang di-patch melibatkan menjalankannya di cluster dari waktu ke waktu untuk mengamati stabilitas. Proses ini membantu menangkap bug yang hanya muncul setelah penggunaan yang berkepanjangan di berbagai lingkungan. Untuk memastikan waktu pengujian yang memadai, rilis patch GKE diperkenalkan terlebih dahulu ke saluran Cepat, diikuti oleh Reguler dan Stabil. Rilis juga diuji di setiap saluran sebelum menjadi target upgrade default untuk saluran tersebut.

Memenuhi syarat patch lebih awal dengan cluster khusus di saluran Cepat

Untuk memenuhi syarat patch keamanan yang ingin Anda percepat, jalankan cluster khusus yang terdaftar di saluran Cepat dengan upgrade otomatis patch yang dipercepat diaktifkan. Gunakan cluster ini untuk memverifikasi kompatibilitas workload, dan menangkap masalah apa pun segera setelah perbaikan keamanan dirilis oleh Google. Cluster ini dapat digunakan sebagai kualifikasi satu kali untuk patch tertentu, tetapi menjalankannya secara terus-menerus memberikan manfaat keandalan tambahan untuk fleet Anda.

Mengurangi penundaan pengujian dengan upgrade otomatis patch yang dipercepat

Setelah cluster yang terdaftar di Cepat siap mendeteksi masalah, Anda dapat memilih untuk menggunakan patch lebih cepat di dalam cluster produksi Anda di Reguler dan Stabil. Aktifkan upgrade otomatis patch yang dipercepat untuk cluster produksi Anda guna memulai upgrade ke rilis patch terbaru di saluran terdaftar Anda segera setelah tersedia. Fitur ini memberi tahu GKE untuk melewati waktu pengujian dalam saluran untuk update patch, terutama patch keamanan.

Upgrade manual ke versi patch yang lebih baru di saluran Reguler dan Stabil

Jika workload produksi Anda berada di cluster yang terdaftar di saluran Reguler atau Stabil, Anda tidak perlu keluar dari saluran tersebut atau menunggu peluncuran patch otomatis dan bertahap untuk menjangkau Anda jika ada update keamanan tertentu yang perlu Anda prioritaskan.

Jika cluster yang terdaftar di Cepat berhasil memenuhi syarat patch, Anda dapat memulai upgrade secara manual di cluster produksi Anda di Reguler atau Stabil ke versi patch yang sama.

Mengotomatiskan pengelolaan patching dengan notifikasi Pub/Sub berbasis peristiwa

Anda tidak perlu memantau halaman web buletin keamanan untuk mendapatkan informasi patch. Untuk mendapatkan notifikasi programatik cepat tentang patch yang tersedia menggunakan Pub/Sub untuk memicu tindakan kualifikasi dan upgrade patch:

  • Peringatan berbasis peristiwa: Siapkan notifikasi cluster menggunakan Pub/Sub.
  • Pemfilteran keamanan: Konfigurasi notifikasi cluster Anda untuk memfilter secara khusus untuk SecurityBulletinEvent dan UpgradeEvent.
  • Tindakan programatik: GKE akan mengirim pesan programatik real-time ke topik Pub/Sub Anda saat buletin keamanan diposting atau patch yang memitigasi buletin tersedia untuk cluster Anda di zona atau region Anda. Notifikasi ini dapat diintegrasikan ke dalam sistem informasi keamanan dan manajemen peristiwa (SIEM), operasi chat, atau memicu pipeline pengujian otomatis.