Anda sedang melihat dokumentasi Apigee dan Apigee Hybrid.
Lihat dokumentasi
Apigee Edge.
Dokumen ini menjelaskan cara Google mengelola kerentanan dan patch keamanan untuk Apigee hybrid. Kecuali jika dinyatakan lain, Apigee mencakup bidang pengelolaan dan bidang data.
Tanggung jawab patching bersama
Patching merupakan tanggung jawab bersama antara Google dan pelanggan. Apigee X dan Apigee hybrid memiliki tanggung jawab bersama yang berbeda mengingat bidang data untuk Apigee hybrid sepenuhnya dikelola oleh pelanggan. Untuk mengetahui informasi tentang tanggung jawab bersama Apigee Hybrid, lihat Model tanggung jawab bersama Apigee Hybrid.
Cara kerentanan ditemukan
Google menerapkan pendekatan proaktif terhadap keamanan sistem software, menggunakan prinsip desain Aman secara Default dan menerapkan berbagai praktik penguatan keamanan.
Misalnya, aplikasi yang di-container mendukung berbagai fitur Platform Pengelolaan API Apigee. Aplikasi dalam container di-deploy di Kubernetes. Image container dibangun di atas image dasar minimal (misalnya, image dasar distroless) untuk keamanan maksimum dan performa yang lebih baik.
Namun, sistem software dengan desain terbaik sekalipun dapat memiliki kerentanan. Untuk menemukan kerentanan tersebut dan melakukan patch sebelum dapat dieksploitasi, Google telah melakukan investasi yang signifikan di berbagai bidang.
Pemindai keamanan
Google secara proaktif mengidentifikasi dan memperbaiki kerentanan pada berbagai jenis image container:
- Container pihak pertama: Image container yang dibuat dan didistribusikan oleh Google sebagai bagian dari platform Apigee. Aplikasi ini adalah aplikasi eksklusif Google yang mendukung platform Pengelolaan API Apigee, termasuk fungsi inti seperti perutean traffic, pengelolaan kuota, dan pengelolaan kunci.
- Container pihak ketiga: Image container yang dibuat oleh komunitas open source tetapi didistribusikan oleh Google sebagai bagian dari platform Apigee. Sebagian besar komponen ini adalah komponen open source yang digunakan oleh platform untuk tugas operasional umum seperti logging, pemantauan, dan pengelolaan sertifikat.
Google memindai container menggunakan Container Analysis Container Registry untuk menemukan kerentanan dan patch yang tidak ada di container pihak pertama dan pihak ketiga. Jika perbaikan tersedia, Google akan memulai proses patch dan rilis. Pemindaian tersebut dijalankan secara rutin (saat gambar baru dipublikasikan) serta sesuai permintaan (sebelum rilis) untuk memaksimalkan peluang mendeteksi kerentanan baru dan perencanaan perbaikan atau mitigasi awal.
Riset keamanan
Selain pemindaian otomatis, Google menemukan dan melakukan patch pada kerentanan yang tidak diketahui oleh pemindai dengan cara berikut:
- Google melakukan audit keamanan dan kepatuhan sendiri, pengujian penetrasi aplikasi dan jaringan, pengujian segmentasi, dan penemuan kerentanan keamanan di semua komponen Apigee.
Tim khusus di dalam Google dan vendor keamanan pihak ketiga tepercaya melakukan riset serangan mereka sendiri. - 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 dan Meltdown. Tim Keamanan Google Cloud juga secara rutin menemukan dan memperbaiki kerentanan di Kernel-based Virtual Machine (KVM).
Program Reward Kerentanan
Google secara aktif berinteraksi dengan komunitas riset keamanan melalui beberapa program reward kerentanan. Program reward kerentanan Google Cloud khusus memberikan hadiah yang signifikan, termasuk $133.337 untuk kerentanan cloud terbaik yang ditemukan setiap tahunnya. Program ini mencakup semua dependensi software Apigee.
OSS
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.
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 Apigee, mengembangkan patch atau mitigasi, serta menyiapkan saran dan komunikasi untuk pelanggan. Jika memungkinkan, Google akan melakukan patch pada semua cluster (untuk Apigee X) sebelum rilis publik kerentanan. Untuk Apigee Hybrid, rilis patch tersedia secara rutin untuk mengatasi kerentanan keamanan dalam image container dan pelanggan dianjurkan untuk terus mengupdate ke versi patch terbaru.
Cara kerentanan diklasifikasikan
Apigee melakukan investasi besar dalam memperkuat keamanan pada seluruh stack, termasuk image dasar, library pihak ketiga, dan software aplikasi pihak pertama, 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 Apigee mengklasifikasikan kerentanan berdasarkan Common Vulnerability Scoring System (CVSS).
Tabel berikut menjelaskan kategori tingkat keparahan kerentanan:
| Keparahan | Deskripsi |
| Kritis | 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. |
Bagaimana kerentanan dan patch dikomunikasikan
Tujuan Google adalah memitigasi kerentanan yang terdeteksi dalam jangka waktu yang sesuai dengan risiko yang dimiliki. Apigee disertakan dalam ATO sementara FedRAMP Google Cloud yang mengharuskan perbaikan kerentanan yang diketahui dalam jangka waktu tertentu sesuai dengan tingkat keparahannya sebagaimana ditentukan dalam FedRAMP RA-5d. ATO sementara FedRAMP Google Cloud tidak mencakup komponen bidang data hybrid Apigee (dikelola pelanggan), tetapi kami menargetkan jangka waktu perbaikan yang sama untuk produk tersebut.
Kerentanan yang terdeteksi oleh pemindaian proaktif
Google mendeteksi kerentanan keamanan melalui pemindaian proaktif biner dan infrastruktur dasar yang menghosting platform Apigee. Apigee merilis update patch rutin untuk mengatasi kerentanan ini secara tepat waktu, bergantung pada tingkat keparahan CVE yang mendasarinya. Melakukan patch pada kerentanan melibatkan upgrade ke versi hybrid Apigee yang baru, baik upgrade versi minor maupun upgrade versi patch, bergantung pada sifat kerentanan. Kerentanan tersebut sebagian besar ditangani sebagai bagian dari rilis patch bulanan untuk Apigee Hybrid dan disertakan dalam update software rutin untuk fleet terkelola kami dalam kasus Apigee X. Patch keamanan dikomunikasikan melalui catatan rilis untuk Apigee X dan Apigee Hybrid.
Perbaikan beberapa kerentanan hanya memerlukan upgrade bidang kontrol, yang dilakukan secara otomatis oleh Google di Apigee, sementara yang lain memerlukan peluncuran biner baru ke bidang data. Untuk Apigee X, Google akan menangani peluncuran biner baru ke seluruh armada. Pelanggan yang menjalankan Apigee Hybrid harus menerapkan rilis patch ke cluster Apigee Hybrid mereka untuk meluncurkan biner yang diupdate.
Agar cluster tetap di-patch dan diperkuat dari kerentanan pada semua tingkat keparahan, sebaiknya terapkan rilis patch terbaru untuk versi minor tertentu dari Apigee hybrid. Untuk pengguna yang menjalankan Apigee hybrid di Anthos, Google merekomendasikan untuk mengupgrade komponen Anthos Anda minimal setiap bulan.
Kerentanan yang dilaporkan pelanggan
Dengan Apigee Hybrid, pelanggan diberi biner Apigee untuk dijalankan di pusat data mereka atau platform cloud pilihan mereka. Sebagai bagian dari standar keamanan pelanggan untuk meluncurkan software ke produksi di pusat data mereka sendiri, mereka dapat menjalankan serangkaian pengujian keamanan. Pengujian ini dapat mencakup uji penetrasi, pemindaian container, pemindaian kode statis, dll. Pengujian ini dapat melaporkan kemungkinan kerentanan dalam software Apigee. Sebelum mengaktifkan paket ini di pusat data mereka, pelanggan perlu menentukan apakah item yang dilaporkan ini dapat dieksploitasi dan oleh karena itu merupakan risiko keamanan.
Kerentanan dengan Bukti Konsep eksploitasi
Jika pelanggan mengidentifikasi kerentanan yang dapat dieksploitasi dan memiliki bukti konsep (POC) tentang cara mengeksploitasi kerentanan tersebut, mereka harus melaporkan masalah ini melalui Program Reward Kerentanan Google yang dapat ditemukan di goo.gle/vulnz. Tindakan ini akan melaporkan masalah tersebut kepada tim keamanan Google yang akan memvalidasi bukti konsep dan menentukan tingkat keparahan serta potensi dampaknya. Kemudian, masalah akan dieskalasikan ke Apigee. Pelanggan mungkin memenuhi syarat untuk mendapatkan reward melalui program VRP.
Kerentanan yang diidentifikasi oleh alat otomatis
Jika pelanggan telah membuat laporan tentang kemungkinan kerentanan dalam produk Apigee berdasarkan pemindaian statis atau alat atau teknik lain, tetapi tidak memiliki bukti konsep tentang cara mengeksploitasi masalah tersebut, item ini dapat dilaporkan ke dukungan melalui portal dukungan Google Cloud. Dengan melaporkan masalah tersebut ke dukungan, pelanggan akan mendapatkan nomor tiket untuk pelacakan dan dapat melihat pembaruan serta respons terhadap laporan tersebut. Kemudian, tim dukungan akan meneruskan masalah yang dilaporkan secara internal sebagaimana mestinya.
ID CVE
Pelanggan harus menyertakan sebanyak mungkin informasi tentang kerentanan, dan secara khusus menyertakan ID CVE, nama library/paket, nama image container, dll. untuk setiap item. CVE memungkinkan kita mengetahui bahwa kita sedang melihat kerentanan yang sama. Hanya memberikan deskripsi masalah atau nomor pelacakan eksklusif lainnya tidak memungkinkan korelasi masalah di seluruh alat deteksi atau proses pelaporan. Tanpa CVE, Google mungkin tidak dapat menanggapi item tertentu.
Respons
Untuk item yang dilaporkan ke dukungan yang memiliki skor tingkat keparahan kritis atau tinggi, pelanggan dapat mengharapkan respons melalui sistem tiket dukungan. Untuk item yang dilaporkan ke VRP, lihat aturan dan dokumentasi yang disediakan oleh program.