Patching keamanan
Dokumen ini menjelaskan cara Google mengelola kerentanan dan patch keamanan untuk Google Kubernetes Engine (GKE) dan GKE Enterprise. Kecuali dinyatakan lain, GKE Enterprise mencakup platform GKE dan GKE Enterprise.
Halaman ini ditujukan untuk spesialis Keamanan yang mendukung penyelesaian masalah keamanan atau kerentanan yang memerlukan bantuan strategis, seperti insiden dan masalah yang dieskalasikan dari dukungan. Untuk mempelajari lebih lanjut peran umum dan contoh tugas yang kami referensikan dalam konten Google Cloud, lihat Peran dan tugas pengguna GKE Enterprise umum.
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 Enterprise 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 Enterprise berjalan sebagai container di atas image dasar.
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 GKE Enterprise. 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 Google Cloud khusus memberikan hadiah signifikan, termasuk $133.337 untuk kerentanan cloud terbaik yang ditemukan setiap tahunnya. 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 Google Cloud juga secara rutin menemukan dan memperbaiki kerentanan di Kernel-based Virtual Machine (KVM).
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 Daftar Distributor Kubernetes yang menerima notifikasi kerentanan sebelumnya dan telah terlibat dalam triase, patching, pengembangan mitigasi, dan komunikasi dalam hampir semua kerentanan keamanan Kubernetes yang serius. Google juga menemukan beberapa kerentanan Kubernetes kami sendiri.
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 Enterprise, 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 Enterprise mengklasifikasikan kerentanan berdasarkan sistem penskoran kerentanan Kubernetes. Klasifikasi mempertimbangkan banyak faktor, termasuk konfigurasi dan hardening keamanan GKE dan GKE Enterprise. Karena faktor ini dan investasi yang dilakukan GKE dalam hal keamanan, klasifikasi kerentanan GKE dan GKE Enterprise mungkin berbeda dari 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
Melakukan patch pada kerentanan melibatkan upgrade ke nomor versi GKE atau GKE Enterprise yang baru. Versi GKE dan GKE Enterprise mencakup komponen berversi untuk sistem operasi, komponen Kubernetes, dan container lain yang membentuk platform GKE Enterprise. 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, sebaiknya gunakan 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 GKE Enterprise lainnya, Google merekomendasikan untuk mengupgrade komponen GKE Enterprise Anda minimal setiap bulan.
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 bahwa 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 ATO sementara FedRAMP Google Cloud, yang mengharuskan perbaikan kerentanan yang diketahui dalam jangka waktu tertentu sesuai dengan tingkat keparahannya sebagaimana ditentukan dalam kontrol RA-5(d) dari tabel "Ringkasan Aktivitas & Hasil Pemantauan Berkelanjutan" dalam Panduan Strategi Pemantauan Berkelanjutan FedRAMP. ATO sementara FedRAMP Google Cloud tidak mencakup Google Distributed Cloud dan GKE di AWS, tetapi kami menargetkan jangka waktu perbaikan yang sama untuk produk tersebut.
Bagaimana kerentanan dan patch dikomunikasikan
Sumber terbaik untuk informasi terkini tentang kerentanan dan patch keamanan adalah di feed buletin keamanan untuk produk berikut:
- GKE
- Google Distributed Cloud
- GKE on AWS
- GKE on Azure
- Google Distributed Cloud
Buletin ini mengikuti skema penomoran kerentanan Google Cloud yang umum dan ditautkan dari halaman buletin Google Cloud utama 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 Enterprise 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.