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 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 juga merupakan pelanggan Google Workspace. Untuk mengetahui informasi tentang tanggung jawab bersama hybrid Apigee, lihat Model tanggung jawab bersama Apigee Hybrid
Bagaimana kerentanan ditemukan
Google menggunakan pendekatan proaktif terhadap keamanan sistem software dengan menggunakan desain Aman secara Default prinsip dan menerapkan berbagai praktik pengerasan keamanan.
Misalnya, aplikasi dalam container mendukung berbagai Platform Pengelolaan API Apigee baru. Aplikasi dalam container di-deploy di Kubernetes. Image container yang dibuat berdasarkan image dasar minimal (misalnya, image dasar tanpa gangguan) untuk keamanan maksimum dan peningkatan performa.
Namun, bahkan sistem perangkat lunak yang dirancang dengan baik pun memiliki kerentanan. Untuk menemukan kerentanan dan mem-patch sebelum dapat dieksploitasi, Google telah investasi di berbagai bidang.
Pemindai keamanan
Google secara proaktif mengidentifikasi dan memperbaiki kerentanan di 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 Apigee API Platform pengelolaan termasuk fungsi inti seperti pemilihan rute traffic, pengelolaan kuota, dan dan pengelolaan kunci.
- Penampung pihak ketiga: Image container yang dibuat oleh komunitas open source tetapi didistribusikan oleh Google sebagai bagian dari platform Apigee. Sebagian besar {i>open source<i} komponen yang digunakan platform untuk tugas operasional umum seperti logging, pemantauan, dan pengelolaan sertifikat.
Google memindai container menggunakan Container Analysis Container Analysis untuk menemukan kerentanan dan {i>patch<i} yang hilang di penampung pihak pertama dan ketiga. Jika tersedia perbaikan, Google akan memulai proses patching dan rilis. Pemindaian tersebut dijalankan pada secara teratur (saat gambar baru dipublikasikan) serta sesuai permintaan (sebelum rilis) untuk memaksimalkan kemungkinan deteksi kerentanan baru dan perbaikan dini atau perencanaan mitigasi.
Riset keamanan
Selain pemindaian otomatis, Google menemukan dan membuat patch kerentanan yang tidak diketahui pemindai dengan cara berikut:
- Google melakukan audit keamanan dan kepatuhan, serta penerapan dan jaringannya sendiri
uji penetrasi, pengujian segmentasi, dan penemuan kerentanan keamanan di seluruh Apigee
komponen komputer.
Tim khusus di dalam Google dan vendor keamanan pihak ketiga tepercaya melakukan melakukan riset serangan sendiri. - Google berkolaborasi dengan partner software open source dan industri lainnya yang membagikan
kerentanan, riset keamanan, dan patch sebelum kerentanan tersebut dirilis ke publik.
Tujuan kolaborasi ini adalah untuk memperbaiki infrastruktur Internet yang besar sebelum kerentanan diumumkan ke publik. Dalam beberapa kasus, Google menyumbangkan kerentanan yang ditemukan di komunitas ini. Misalnya, Project Zero Google menemukan dan memublikasikan Spectre dan Meltdown kerentanan. Tim Keamanan Google Cloud juga secara rutin menemukan dan memperbaiki kernabilitas di Virtual Machine Berbasis Kernel (KVM).
Program Reward Kerentanan
Google secara aktif terlibat dengan komunitas riset keamanan melalui beberapa program reward kerentanan. Program reward kerentanan Google Cloud khusus memberikan hadiah signifikan, termasuk $133.337 untuk kerentanan cloud terbaik yang ditemukan setiap tahun. Program ini mencakup semua dependensi software Apigee.
OSS
Kolaborasi keamanan Google terjadi di berbagai level. Terkadang itu terjadi secara formal melalui program tempat organisasi mendaftar untuk menerima notifikasi pra-rilis tentang software kerentanan terhadap produk seperti Kubernetes dan Envoy. Kolaborasi juga terjadi secara informal karena keterlibatan kami dengan banyak proyek {i>open source<i} seperti {i>kernel<i} Linux, {i>runtime container<i}, teknologi virtualisasi, dan lainnya.
Sementara kerentanan yang lebih ringan ditemukan dan diperbaiki di luar proses ini, sebagian besar kerentanan keamanan kritis dilaporkan secara pribadi melalui salah satu saluran yang sebelumnya terdaftar. Pelaporan awal memberi Google waktu sebelum kerentanan menjadi publik untuk meneliti cara Dampaknya terhadap Apigee, mengembangkan patch atau mitigasi, serta menyiapkan saran dan komunikasi untuk pelanggan. Jika memungkinkan, Google mem-patch semua cluster (untuk Apigee X) sebelum rilis publik kerentanannya. Untuk Apigee Hybrid, rilis patch tersedia secara rutin untuk mengatasi kerentanan keamanan dalam image container. Jadi, pelanggan dianjurkan untuk tetap mengikuti versi patch terbaru.
Cara kerentanan diklasifikasikan
Apigee banyak berinvestasi dalam pengerasan keamanan di seluruh stack, termasuk image dasar, perpustakaan pihak ketiga dan perangkat lunak aplikasi pihak pertama, selain mengatur default, konfigurasi yang di-hardening oleh keamanan, dan komponen terkelola. Jika digabungkan, upaya ini membantu untuk mengurangi dampak dan kemungkinan terjadinya kerentanan.
Tim keamanan Apigee mengklasifikasikan kerentanan berdasarkan Common Vulnerability Scoring System (CVSS).
Tabel berikut menjelaskan kategori tingkat keparahan kerentanan:
| Keparahan | Deskripsi |
| Kritis | Kerentanan yang mudah dieksploitasi di semua cluster oleh remote yang tidak diautentikasi penyerang yang dapat menyebabkan penyusupan ke seluruh sistem. |
| Tinggi | Kerentanan yang mudah dieksploitasi untuk banyak cluster yang menyebabkan hilangnya kerahasiaan, integritas, atau ketersediaan. |
| Sedang | Kerentanan yang dapat dieksploitasi untuk beberapa klaster dengan hilangnya kerahasiaan, integritas data, atau ketersediaan dibatasi oleh konfigurasi umum, tingkat kesulitan eksploitasi, itu sendiri, akses yang diperlukan, atau interaksi pengguna. |
| Rendah | Semua kerentanan lainnya. Eksploitasi tidak mungkin terjadi atau konsekuensi eksploitasi terbatas. |
Bagaimana kerentanan dan patch dikomunikasikan
Tujuan Google adalah memitigasi kerentanan yang terdeteksi dalam jangka waktu yang sesuai untuk risiko yang diwakilinya. Apigee disertakan dalam ATO sementara FedRAMP Google Cloud yang mengharuskan agar kerentanan yang diketahui diperbaiki dalam jangka waktu tertentu sesuai dengan tingkat keparahannya sebagai ditentukan dalam FedRAMP RA-5d. ATO sementara FedRAMP Google Cloud tidak menyertakan komponen bidang data hybrid Apigee (dikelola pelanggan), tetapi kami menginginkan jangka waktu perbaikan yang sama pada produk tersebut.
Kerentanan yang terdeteksi dengan pemindaian proaktif
Google mendeteksi kerentanan keamanan melalui pemindaian proaktif pada biner dan infrastruktur dasar yang menghosting platform Apigee. Apigee merilis update patch reguler untuk menangani kerentanan ini secara tepat waktu, tergantung pada tingkat keparahan CVE. Patching kerentanan melibatkan upgrade ke versi hybrid Apigee baru-‐baik di bawah atau {i>upgrade <i}versi {i>patch<i}, tergantung pada sifat kerentanan. Seperti sebagian besar ditangani sebagai bagian dari rilis patch bulanan untuk Apigee Hybrid dan disertakan dalam update software rutin ke fleet terkelola kami dalam kasus Apigee X. Patch keamanan dikomunikasikan melalui catatan rilis untuk Apigee X dan Apigee Hybrid.
Memperbaiki beberapa kerentanan hanya memerlukan peningkatan versi bidang kontrol, yang dilakukan secara Google di Apigee, sementara yang lain memerlukan biner baru untuk diluncurkan ke bidang data. Dalam kasus Apigee X, Google menangani peluncuran biner baru ke seluruh fleet. Pelanggan yang menjalankan Apigee Apigee Hybrid harus menerapkan rilis patch ke cluster hybrid Apigee untuk meluncurkan versi terbaru biner.
Untuk menjaga cluster tetap di-patch dan diperkuat terhadap kerentanan dengan segala tingkat keparahan, kami merekomendasikan menerapkan rilis patch terbaru untuk versi minor Apigee Hybrid tertentu. Untuk mereka yang berlari Apigee Hybrid di Anthos, Google merekomendasikan untuk mengupgrade komponen Anthos minimal setiap bulan.
Kerentanan yang dilaporkan pelanggan
Dengan Apigee Hybrid, pelanggan diberi biner Apigee untuk dijalankan di data mereka atau platform cloud pilihan mereka. Sebagai bagian dari standar keamanan pelanggan untuk meluncurkan perangkat lunak ke dalam produksi di pusat data mereka sendiri, mereka dapat menjalankan serangkaian tes keamanan. Tes ini dapat mencakup tes penetrasi, pemindaian container, pemindaian kode statis, dll. Pengujian ini mungkin 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 karenanya merupakan risiko keamanan.
Kerentanan dengan eksploit Proof of Concept
Jika pelanggan mengidentifikasi kerentanan yang dapat dieksploitasi dan memiliki bukti konsep (POC) tentang cara mengeksploitasi kerentanan, mereka harus melaporkan masalah ini melalui Google {i>Vulnerabilities Reward<i} Program ditemukan di goo.gle/vulnz. Laporan ini melaporkan masalah tersebut ke Tim keamanan Google yang akan memvalidasi bukti konsep dan menentukan tingkat keparahan dan dampak potensial. Masalah ini kemudian akan dieskalasi ke Apigee. Pelanggan mungkin memenuhi syarat untuk 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 lainnya, tetapi tidak memiliki bukti konsep tentang bagaimana mengeksploitasi masalah, item ini dapat dilaporkan untuk didukung melalui Portal dukungan Google Cloud. Dengan melaporkan masalah ke dukungan, pelanggan memiliki nomor tiket untuk pelacakan dan dapat melihat info terbaru serta respons pada laporan. Tim dukungan kemudian akan mengeskalasikan masalah yang dilaporkan secara internal jika perlu.
ID CVE
Pelanggan harus menyertakan sebanyak mungkin informasi tentang kerentanan, dan secara khusus sertakan ID CVE, library/nama paket, nama image container, dll. untuk setiap item. CVE memungkinkan kita mengetahui bahwa kita melihat kerentanan yang sama. Hanya menyediakan tentang masalah atau nomor pelacakan eksklusif lainnya tidak memungkinkan korelasi antara di seluruh alat deteksi atau proses pelaporan. Tanpa CVE, Google mungkin tidak dapat merespons item spesifik.
Respons
Untuk item yang dilaporkan ke dukungan dengan skor tingkat keparahan kritis atau tinggi, pelanggan dapat menunggu respons melalui penjualan tiket dukungan sistem file. Untuk item yang dilaporkan ke VRP, lihat aturan dan yang disediakan oleh program.