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 platform pengelolaan dan platform 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 platform data untuk Apigee hybrid sepenuhnya dikelola oleh pelanggan. Untuk 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 hardening keamanan.
Misalnya, aplikasi dalam container mendukung berbagai fitur Platform Pengelolaan Apigee API. Aplikasi dalam container di-deploy di Kubernetes. Image container dibuat di atas image dasar minimal (misalnya, image dasar distroless) untuk keamanan maksimum dan performa yang lebih baik.
Namun, 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.
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. Ini adalah aplikasi eksklusif Google yang mendukung platform Pengelolaan API Apigee, termasuk fungsi inti seperti pemilihan rute traffic, pengelolaan kuota, dan pengelolaan kunci.
- Penampung pihak ketiga: Image penampung yang dibuat oleh komunitas open source, tetapi didistribusikan oleh Google sebagai bagian dari platform Apigee. Komponen ini sebagian besar merupakan komponen open source yang digunakan oleh platform untuk tugas operasional umum seperti logging, pemantauan, dan pengelolaan sertifikat.
Google memindai container menggunakan Container Registry Container Analysis 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 image baru dipublikasikan) serta on demand (sebelum rilis) untuk memaksimalkan peluang mendeteksi kerentanan baru dan perencanaan mitigasi atau perbaikan 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, 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 Virtual Machine berbasis Kernel (KVM).
Program Reward Pencarian Kerentanan
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. 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 selalu menggunakan 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 platform data campuran 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 terhadap biner dan infrastruktur dasar yang menghosting platform Apigee. Apigee merilis update patch reguler untuk mengatasi kerentanan ini secara tepat waktu, bergantung pada tingkat keparahan CVE yang mendasarinya. Melakukan patch pada kerentanan melibatkan upgrade ke versi campuran Apigee 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 reguler ke kumpulan terkelola kami dalam kasus Apigee X. Patch keamanan disampaikan 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 biner baru untuk diluncurkan ke bidang data. Untuk Apigee X, Google akan menangani peluncuran biner baru ke seluruh armada. Pelanggan yang menjalankan Apigee 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 Apigee hybrid tertentu. 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 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 penampung, pemindaian kode statis, dll. Pengujian ini mungkin melaporkan kemungkinan kerentanan dalam software Apigee. Sebelum mengaktifkan paket ini di pusat data mereka, pelanggan harus menentukan apakah item yang dilaporkan ini dapat dieksploitasi sehingga berisiko terhadap keamanan.
Kerentanan dengan Bukti Konsep eksploit
Jika pelanggan mengidentifikasi kerentanan yang dapat dieksploitasi dan memiliki bukti konsep (POC) tentang cara mengeksploitasi kerentanan tersebut, mereka harus melaporkan masalah ini melalui Google Vulnerabilities Reward Program 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 keparahannya serta potensi dampaknya. Kemudian, masalah tersebut akan dieskalasi 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, item ini dapat dilaporkan ke dukungan melalui portal dukungan Google Cloud. Dengan melaporkan masalah kepada tim dukungan, pelanggan akan memiliki nomor tiket untuk pelacakan dan dapat melihat pembaruan serta respons terhadap laporan. Tim dukungan kemudian akan mengeskalasikan masalah yang dilaporkan secara internal sebagaimana mestinya.
ID CVE
Pelanggan harus menyertakan informasi sebanyak mungkin 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 merespons item tertentu.
Respons
Untuk item yang dilaporkan ke dukungan yang memiliki skor 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.