Konten ini terakhir diperbarui pada Juni 2026, dan menampilkan kondisi pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.
Google menjalankan infrastruktur komputasi terdistribusi, multi-tenant, dan berskala global untuk menyediakan produk dan layanan kepada miliaran orang di seluruh dunia. Infrastruktur ini harus menyeimbangkan prioritas yang bersaing antara keamanan, keandalan, ketahanan, efisiensi, kecepatan pengembangan, kemampuan proses debug, dan lainnya.
Dokumen ini menjelaskan beberapa mekanisme yang kami gunakan untuk mempertahankan postur keamanan yang terdepan di industri untuk layanan yang berjalan di lingkungan produksi Google. Layanan ini mencakup spektrum sensitivitas keamanan yang lengkap, mulai dari eksperimen pengembangan yang tidak memiliki akses ke data sensitif hingga infrastruktur identitas penting. Layanan ini menyelesaikan tugas seperti memproses data pengguna, mengelola peluncuran software, serta menyediakan dan mengelola siklus proses untuk setiap mesin fisik.
Dokumen ini menjelaskan kontrol keamanan yang membantu melindungi tiga lapisan utama infrastruktur kami berikut:
- Layanan produksi, yang mencakup layanan paling penting dari segi keamanan (juga dikenal sebagai layanan dasar)
- Mesin produksi
- Workload produksi
Kami menerapkan kontrol ini agar staf Google hanya dapat mengakses layanan, mesin, dan workload untuk tujuan bisnis yang sah (misalnya, akses pemeliharaan), serta untuk melindungi dari risiko orang dalam dan pembobolan akun staf. Kontrol ini memberikan perlindungan pertahanan mendalam lebih lanjut yang melengkapi kontrol keamanan infrastruktur yang ada yang membantu mencegah pembobolan akun.
Peningkatan berkelanjutan
Kontrol yang dijelaskan dalam dokumen ini digunakan di seluruh lingkungan produksi Google. Banyak layanan, termasuk layanan dasar, menggunakan tingkat kontrol terbaru yang kami tawarkan. Namun, karena cakupan dan kompleksitas infrastruktur Google, setiap layanan produksi sering kali memiliki persyaratan unik dan mungkin memerlukan waktu tambahan untuk menerapkan rekomendasi terbaru. Melalui budaya peningkatan berkelanjutan, tim Site Reliability Engineering (SRE) dan keamanan Google terus mengadaptasi kontrol keamanan untuk memenuhi perubahan lanskap ancaman.
Melindungi layanan produksi
Google membantu melindungi integritas layanan produksi sehingga staf Google hanya dapat mengakses layanan untuk tujuan bisnis yang sah, seperti pemeliharaan. Ada dua cara utama untuk mendapatkan akses ke layanan yang berjalan di lingkungan produksi: melalui akses administratif dan melalui rantai pasokan software.
Daftar berikut menjelaskan kontrol yang membantu melindungi setiap jalur akses.
Kontrol akses administratif: Layanan produksi memerlukan pemeliharaan rutin (misalnya, peluncuran biner atau konfigurasi). Di Google, tujuan kami adalah agar operasi tersebut dilakukan melalui otomatisasi, proxy yang aman, atau akses darurat yang diaudit, dengan mengikuti filosofi Zero Touch Prod. Serangkaian kontrol yang menghapus akses pengguna ke aset produksi disebut No Persons (NoPe). NoPe memberi Google fleksibilitas untuk men-deploy kontrol akses yang didasarkan pada sensitivitas layanan produksi dan kesiapannya untuk mencapai postur yang lebih kuat melalui peningkatan berkelanjutan.
Misalnya, Google tidak mengizinkan akses sepihak ke layanan dasar —bahkan akses darurat memerlukan persetujuan dari personel Google lainnya. Akses bersifat sepihak jika seseorang dapat melakukan akses tanpa persetujuan dari individu resmi lainnya. Sebagai contoh lain, kami menonaktifkan dump inti untuk membantu mencegah hilangnya rahasia penting, seperti kunci akses root, meskipun hal ini membuat proses penelusuran bug menjadi lebih sulit.
Kontrol supply chain software: Sebagian besar workload produksi di Google, termasuk layanan dasar, menjalankan biner dan konfigurasi tugas yang dibuat secara terverifikasi dari kode yang ditinjau oleh rekan sejawat dan berada di sumber tepercaya. Kami menerapkan proses ini menggunakan Otorisasi Biner untuk Borg (BAB).
Diagram berikut menunjukkan kontrol yang membantu melindungi layanan produksi.
Saat kami menerapkan NoPe dan BAB tingkat tertinggi, kami membantu memastikan bahwa tidak ada personel yang memiliki akses sepihak, bahkan dalam keadaan darurat, ke layanan dasar, dan bahwa setiap akses istimewa yang mereka terima memiliki cakupan dan durasi yang jelas. Akses istimewa adalah tingkat akses yang lebih tinggi yang diberikan kepada personel untuk mengelola layanan produksi penting dalam keadaan unik yang tidak ditangani oleh otomatisasi. Kami membuat pengecualian untuk aturan ini guna memastikan Google memiliki cara untuk keluar dari situasi terkunci.
Sebagian besar layanan produksi, termasuk produk seperti Filestore atau Cloud SQL dan produk infrastruktur internal seperti Borg dan Spanner, dikonfigurasi untuk menggunakan tingkat NoPe dan BAB tertinggi, dan kami terus berupaya mempermudah pemilik layanan produksi untuk mengadopsi NoPe dan BAB dari waktu ke waktu. Pengecualian yang dikelola dengan justifikasi bisnis yang valid ada dalam daftar risiko.
Kontrol akses administratif
Di Borg, anggota peran produksi dapat membaca, menulis, atau menghapus data yang dimiliki peran produksi, dan mereka dapat menjalankan kode menggunakan otoritas peran. Peran produksi adalah identitas yang dapat menjalankan workload di lingkungan produksi Google.
Keanggotaan permanen dalam peran produksi menimbulkan risiko konsekuensi yang tidak diinginkan untuk produksi, dan risiko bahwa hak istimewa ini dapat disalahgunakan. Namun, misi SRE menuntut agar tim diberi wewenang untuk memelihara layanan yang menjadi tanggung jawab mereka, sehingga penghapusan akses sepenuhnya mungkin bukan strategi yang tepat.
Rangkaian NoPe menyediakan cara untuk mengonfigurasi akses yang menyeimbangkan tuntutan yang bersaing untuk memberdayakan tim dan menjaga keamanan sistem produksi. Dengan NoPe, personel Google mengalami batasan pada hak istimewa akun mereka saat mereka mencoba mengakses layanan produksi. NoPe memungkinkan batasan berikut:
- Permintaan akses memerlukan pemberi persetujuan dan justifikasi: kontrol yang disebut otorisasi banyak pihak (MPA) membantu memastikan bahwa personel Google tidak dapat memperoleh akses ke layanan produksi tanpa justifikasi bisnis dan persetujuan dari individu lain yang berwenang untuk memverifikasi permintaan akses.
- Tidak ada akses langsung ke peran layanan produksi: personel hanya dapat mengakses layanan produksi melalui proxy aman untuk NoPe. Proxy aman dirancang agar hanya serangkaian perintah yang terdefinisi dengan baik yang dapat dieksekusi. Perintah apa pun yang dianggap berisiko oleh organisasi SRE dan Keamanan Google (misalnya, menonaktifkan layanan atau mengakses atau menghapus data) juga memerlukan MPA.
- Tidak ada keanggotaan peran produksi permanen: kontrol yang disebut akses sesuai permintaan (AoD) mewajibkan personel untuk meminta keanggotaan sementara, bukan mengizinkan akun personel untuk selalu memiliki hak akses. Kontrol ini membantu memastikan bahwa hak istimewa hanya diberikan untuk sementara dan karena alasan tertentu.
- Pemantauan permintaan akses staf ke layanan produksi: Google mewajibkan audit berkala terhadap pola akses ke peran produksi yang menjalankan layanan produksi. Tujuan audit ini adalah untuk menghilangkan kebutuhan akan permintaan tersebut pada masa mendatang, melalui peningkatan berkelanjutan pada API administratif. Akses ke layanan produksi hanya boleh diberikan dalam situasi respons darurat. Untuk layanan dasar, jumlah situasi saat akses diberikan sangat sedikit sehingga tim keamanan melakukan audit setiap akses yang diberikan untuk mengonfirmasi validitasnya.
Bagian berikut membahas setiap kontrol secara mendetail.
Otorisasi banyak pihak untuk NoPe
MPA memerlukan personel Google resmi lainnya untuk menyetujui permintaan akses.
Untuk permintaan akses ke layanan yang cukup sensitif, MPA juga mewajibkan personel memberikan justifikasi bisnis yang merujuk pada masalah mendesak produksi yang sedang berlangsung dengan setiap permintaan.
Kedua kondisi ini merupakan penghalang terhadap penyalahgunaan akses.
Proxy aman untuk NoPe
Proxy aman adalah alat yang mengekspos serangkaian perintah yang telah ditentukan sebelumnya yang dapat dijalankan oleh proxy aman atas nama pemanggil. Proxy aman menerapkan kebijakan otorisasi berbasis aturan yang terperinci untuk memberikan batasan pada akses ke layanan produksi. Kebijakan ini dapat, misalnya, memerlukan persetujuan dari individu resmi lain untuk menjalankan perintah yang dapat memengaruhi keamanan atau keandalan secara negatif (misalnya, perintah yang menghapus file). Kebijakan juga dapat mengizinkan perintah aman tertentu (misalnya, perintah yang mencantumkan pemanfaatan resource) dieksekusi tanpa memerlukan persetujuan. Fleksibilitas ini sangat penting untuk meminimalkan toil operasional.
Jika terjadi penyalahgunaan akses, akun tetap dibatasi pada operasi yang diizinkan oleh proxy aman. Akun hanya dapat menjalankan perintah aman secara sepihak, sementara operasi istimewa memerlukan persetujuan dari individu resmi lainnya. Semua operasi meninggalkan log audit yang jelas.
Untuk mengetahui informasi selengkapnya tentang proxy aman, lihat presentasi SREcon tentang zero touch prod dan Studi Kasus: Proxy Aman. Prod tanpa interaksi adalah serangkaian prinsip dan alat yang memastikan bahwa setiap perubahan dalam produksi dilakukan oleh otomatisasi (tanpa keterlibatan manusia), divalidasi sebelumnya oleh software, atau dilakukan menggunakan mekanisme yang diaudit dan memiliki kemampuan darurat.
Akses sesuai permintaan
Akses sesuai permintaan (AoD) memungkinkan Google mengurangi hak istimewa personel dengan mengganti keanggotaan permanen dengan keanggotaan yang memenuhi syarat.
Anggota yang memenuhi syarat untuk suatu peran tidak memiliki akses ke hak istimewanya. Sebagai gantinya, jika anggota peran yang memenuhi syarat memerlukan akses, mereka dapat meminta keanggotaan sementara, yang dikenal sebagai pemberian AoD. Jika disetujui oleh individu resmi lainnya, pemberian AoD akan menjadikan pemohon anggota peran selama jangka waktu terbatas, biasanya kurang dari satu hari.
Model keanggotaan yang memenuhi syarat memungkinkan personel meminta hanya subset akses
yang mereka butuhkan selama durasi yang mereka perlukan. Secara konseptual, Anda dapat menganggap
AoD sebagai produksi sudo yang terikat waktu, mirip dengan perintah sudo -u di Unix,
yang memungkinkan Anda menjalankan beberapa perintah dengan izin yang ditingkatkan yang
terkait dengan pengguna tertentu. Namun, tidak seperti sudo Unix, menerima pemberian AoD
memerlukan justifikasi bisnis dan MPA, serta meninggalkan jejak audit. Hibah AoD
juga memiliki batas waktu.
Mengamankan hak istimewa sensitif di balik langganan yang memenuhi syarat berarti bahwa meskipun dalam kasus penyalahgunaan akses yang tidak mungkin terjadi, akun hanya dapat mengakses hak istimewa tersebut jika ada pemberian aktif. Penggunaan proxy aman sebagian besar menghilangkan kebutuhan akan pemberian tersebut.
Pemantauan permintaan akses
Meskipun banyak area produksi Google menggunakan NoPe sebagai praktik pengurangan akses, pemberian AoD sangat jarang terjadi untuk peran produksi kami yang paling sensitif dan hanya diperuntukkan bagi respons darurat. Selain itu, setiap peristiwa memicu audit manual setelah fakta. Tujuan audit ini adalah untuk mengurangi frekuensi pemberian AoD pada masa mendatang (misalnya, dengan menggunakan peristiwa ini untuk mendorong peningkatan kualitas API Administratif).
Google terus memantau pemberian izin AoD, dan tindakan yang dilakukan saat memegang izin tersebut, di seluruh perusahaan. Kami menggunakan data pemantauan real-time untuk mendeteksi potensi pelanggaran dan mengidentifikasi area yang perlu dikurangi aksesnya lebih lanjut. Jika terjadi insiden, jejak audit mendukung respons cepat.
Otorisasi biner untuk Borg
Sama seperti NoPe yang membantu melindungi jalur akses istimewa, Otorisasi Biner untuk Borg (BAB) membantu melindungi supply chain software Google. BAB membantu memastikan bahwa software produksi dan konfigurasi tugas ditinjau dan disetujui sebelum di-deploy, terutama saat software dan konfigurasi tersebut dapat mengakses data sensitif. Awalnya dirancang untuk infrastruktur produksi Google, konsep utama BAB kini disertakan dalam spesifikasi terbuka yang disebut Supply Chain Levels for Software Artifacts (SLSA).
BAB membantu memastikan bahwa personel tidak dapat mengubah kode sumber, menjalankan biner, atau mengonfigurasi tugas tanpa peninjauan sejawat, dan bahwa konfigurasi software atau artefak biner apa pun dibuat secara terverifikasi dari kode sumber yang di-check in dan ditinjau sejawat.
Untuk mengetahui informasi selengkapnya, lihat Otorisasi biner untuk Borg.
Melindungi mesin produksi
Selain memperkuat jalur akses istimewa dan menjaga integritas supply chain software, Google melindungi mesin yang menjalankan layanan produksi. Secara khusus, kami menerapkan hal berikut:
Kontrol akses shell: Sebagian besar personel Google tidak memiliki akses shell (misalnya, melalui SSH) ke mesin produksi atau ke workload yang berjalan di Borg, sistem pengelolaan cluster Google. Sebagai gantinya, individu harus menggunakan proxy yang aman yang mengharuskan orang lain yang berwenang untuk meninjau dan menyetujui setiap perintah sebelum perintah tersebut dieksekusi.
Hanya beberapa tim yang menangani infrastruktur tingkat rendah yang mempertahankan akses shell non-unilateral sehingga mereka dapat men-debug masalah yang paling kompleks saat proxy yang aman tidak praktis untuk digunakan. Akses bersifat non-unilateral jika memerlukan otorisasi dari satu atau beberapa personel resmi tambahan. Google membuat satu pengecualian jika akses shell sepihak diizinkan: untuk memastikan bahwa Google memiliki cara untuk keluar dari situasi terkunci.
Kontrol akses fisik: Mesin memerlukan pemeliharaan fisik rutin agar tetap berfungsi dengan baik. Untuk membantu memastikan bahwa teknisi pusat data hanya mengakses mesin fisik dalam konteks alasan bisnis yang valid, Google menggunakan kontrol fisik-ke-logis.
Kontrol firmware dan software sistem: Google menerapkan alur keamanan booting terukur yang didasarkan pada root of trust hardware. Root of trust hardware membantu memastikan integritas firmware booting dan software sistem setiap mesin.
Diagram berikut menunjukkan kontrol yang membantu melindungi mesin di pusat data.
Kontrol akses shell
SSH adalah alat administratif open source yang populer karena memungkinkan akses luas ke server berbasis Linux. Tanpa kontrol pada akses SSH, akun dengan kredensial yang tepat dapat memperoleh shell yang memungkinkan mereka mengeksekusi kode arbitrer dengan cara yang sulit diaudit.
Dengan akses shell ke layanan produksi, akun tersebut dapat, misalnya, mengubah perilaku tugas yang sedang berjalan, mengekstraksi kredensial, atau menggunakan kredensial untuk mendapatkan pijakan persisten di lingkungan.
Untuk memitigasi risiko ini, kami menggunakan serangkaian kontrol berikut yang menggantikan akses SSH ke mesin produksi dengan metode alternatif yang aman:
- API terbatas: untuk tim dengan alur kerja yang terdefinisi dengan baik yang sebelumnya memerlukan SSH, kami mengganti SSH dengan API yang terdefinisi secara sempit dan dapat diaudit.
- Proxy aman untuk SSH: untuk tim yang memerlukan akses yang lebih fleksibel, proxy aman memungkinkan perintah diizinkan dan diaudit satu per satu.
- MPA: saat SRE memerlukan akses SSH darurat ke mesin, Google mewajibkan justifikasi bisnis dan individu yang berwenang untuk menyetujui akses tersebut. Transkrip sesi shell lengkap dicatat.
- Skenario penguncian: satu-satunya pengecualian saat akses SSH sepihak diizinkan. Transkrip sesi shell lengkap dicatat.
Kontrol ini menyeimbangkan kebutuhan akan akses shell yang sah dengan risiko yang terkait dengan akses shell yang terlalu luas.
Latar belakang: SSH di Google
Sebelumnya, Google menggunakan SSH untuk mengelola komputernya. Pengembangan Borg memungkinkan sebagian besar personel Google tidak lagi memerlukan akses langsung ke mesin Linux yang menjalankan biner mereka, tetapi akses shell tetap ada karena beberapa alasan:
- Terkadang personel memerlukan akses langsung ke mesin untuk tujuan pen-debug-an.
- Akses SSH adalah alat pengajaran yang berharga untuk memahami berbagai lapisan abstraksi.
- Dalam skenario disaster recovery yang tidak terduga, alat tingkat yang lebih tinggi mungkin tidak tersedia.
Untuk menyeimbangkan antara alasan-alasan ini dan risiko keamanan yang ditimbulkannya, Google mengejar serangkaian pencapaian untuk secara bertahap menghilangkan risiko SSH dan kemudian penggunaannya.
Tonggak pencapaian pemantauan dan kontrol akses terpusat
Google berinvestasi dalam sistem otorisasi dan pemantauan SSH pusat yang dikenal sebagai otorisasi pemantauan berbasis identitas host (HIBA). HIBA memberikan visibilitas ke penggunaan SSH dan memungkinkan penerapan kebijakan otorisasi yang ketat. Upaya SSH dicatat, tidak hanya oleh mesin target, tetapi juga oleh proxy BeyondCorp terpusat. Perintah yang dieksekusi oleh shell dicatat dan dimasukkan ke dalam pipeline deteksi perilaku berbahaya. Namun, deteksi pada dasarnya bersifat reaktif dan rentan terhadap penghindaran dan pengaburan.
Menghilangkan tonggak pencapaian akses sepihak
Untuk sebagian besar personel, Google telah menghapus akses shell (misalnya, melalui SSH) ke mesin produksi atau ke workload yang berjalan di Borg. Namun, file tersebut tetap dapat diakses di mesin pengujian (misalnya, mesin yang digunakan untuk menguji hardware baru atau software tingkat rendah baru, tetapi tidak menjalankan layanan produksi) oleh tim pengembangan.
API Sempit
Beberapa tim Google yang sebelumnya mengandalkan SSH untuk menjalankan sejumlah kecil perintah yang ditentukan secara tepat (misalnya, dalam playbook), atau untuk mendapatkan data yang strukturnya dapat diprediksi, kini menggunakan API yang ditentukan secara sempit yang melayani kasus penggunaan tertentu dan menyediakan data terstruktur.
API sempit memiliki sejumlah kecil metode yang selaras dengan perjalanan pengguna umum dan mengabstraksi detail akses tingkat rendah. Oleh karena itu, solusi ini adalah solusi pilihan Google karena memberikan keamanan dan kemampuan audit terbaik. Dengan membangunnya di infrastruktur remote procedure call (RPC) Google, kami mendapatkan manfaat dari investasi selama puluhan tahun dalam keamanan dan audit.
Proxy aman untuk SSH
Beberapa tim Google tidak dapat menentukan perintah yang mungkin mereka perlukan sebelumnya. Dalam hal ini, Google menggunakan daemon yang menjalankan perintah yang hanya menerima permintaan eksekusi perintah arbitrer dari proxy tepercaya yang dijalankan oleh tim keamanan. Teknologi ini mirip dengan teknologi yang digunakan dalam proxy aman untuk NoPe.
Proxy aman untuk SSH bertanggung jawab atas otorisasi terperinci dari eksekusi perintah dan untuk audit. Otorisasi didasarkan pada argumen dan lingkungan perintah, parameter pembatasan kecepatan, justifikasi bisnis, dan MPA. Proses otorisasi ini memungkinkan pembatasan yang sangat akurat pada perintah yang dapat dijalankan sesuai dengan playbook dan praktik terbaik tim. Dalam kondisi kegagalan yang tidak terduga yang tidak tercakup dalam playbook yang ada, personel masih dapat menjalankan perintah penelusuran masalah yang diperlukan setelah individu resmi lainnya menyetujuinya.
MPA untuk SSH
Beberapa tim yang masih bekerja di infrastruktur tingkat rendah mempertahankan bentuk akses shell non-unilateral untuk men-debug masalah yang paling kompleks.
SSH dalam skenario penguncian
Google membuat pengecualian jika akses shell sepihak diizinkan: untuk memastikan bahwa Google dapat memperbaiki situasi terkunci. Kunci SSH yang digunakan untuk tujuan ini dibuat dengan proses yang dapat diaudit dan disimpan secara offline di hardware yang tahan terhadap gangguan. Saat kunci ini digunakan, transkrip sesi shell lengkap akan dicatat.
Kontrol akses fisik
Pusat data Google adalah lingkungan kompleks yang terdiri dari server, perangkat jaringan, dan sistem kontrol yang memerlukan berbagai peran dan keterampilan untuk mengelola, memelihara, dan mengoperasikannya.
Google menerapkan enam lapisan kontrol fisik dan banyak kontrol logis pada komputer itu sendiri untuk membantu melindungi beban kerja di pusat data. Kami juga mempertahankan ruang di antara mesin, yang kami sebut sebagai ruang fisik-ke-logis.
Kontrol fisik ke logis memberikan lapisan pertahanan tambahan melalui kontrol yang disebut penguatan mesin, kontrol akses berbasis tugas, dan pertahanan diri sistem. Kontrol fisik-ke-logis melindungi dari musuh yang berupaya mengeksploitasi akses fisik ke mesin dan melakukan eskalasi ke serangan logis pada workload mesin.
Untuk mengetahui informasi selengkapnya, lihat Cara Google melindungi ruang fisik-ke-logis di pusat data.
Kontrol firmware dan software sistem
Postur keamanan mesin pusat data ditetapkan saat booting. Proses booting mesin mengonfigurasi hardware mesin dan melakukan inisialisasi sistem operasinya, sekaligus menjaga agar mesin tetap aman untuk berjalan di lingkungan produksi Google.
Pada setiap langkah dalam proses booting, Google menerapkan kontrol yang terdepan di industri untuk membantu menerapkan status booting yang diharapkan dan membantu menjaga keamanan data pelanggan. Kontrol ini membantu memastikan bahwa mesin kami melakukan booting ke software yang diinginkan, memungkinkan kami menghapus kerentanan yang dapat membahayakan postur keamanan awal mesin.
Untuk mengetahui informasi selengkapnya, lihat Cara Google menerapkan integritas booting pada mesin produksi.
Melindungi workload
Sesuai dengan filosofi zero-trust kami, Google juga telah memperkenalkan kontrol yang membantu melindungi dari ancaman pergerakan lateral antar-workload dengan persyaratan keamanan yang berbeda. Infrastruktur Google menggunakan hierarki beban kerja yang disebut cincin keamanan beban kerja (WSR). WSR membantu memastikan bahwa workload penting tidak dijadwalkan di mesin yang sama dengan workload yang kurang aman, sekaligus menghindari dampak negatif pada pemanfaatan resource. WSR mengelompokkan workload ke dalam empat kelas sensitivitas — dasar, sensitif, diperkuat, dan tidak diperkuat — serta mencoba menjadwalkannya di berbagai kumpulan mesin.
Diagram berikut menunjukkan cara WSR mengelompokkan dan menjadwalkan workload di seluruh mesin dasar, produksi, dan pengembangan.
WSR memberikan lapisan pertahanan tambahan terhadap eskalasi akses lokal menggunakan serangan kerentanan kernel atau serangan side-channel CPU. WSR membantu memastikan bahwa hanya workload dengan persyaratan keamanan yang serupa yang dijadwalkan bersama di mesin yang sama. Untuk menerapkan WSR, kita melakukan hal berikut:
- Mengklasifikasikan workload sesuai dengan persyaratan keamanannya. Setiap kelas dikenal sebagai ring workload.
- Mendistribusikan mesin fisik di beberapa kumpulan mesin yang terisolasi satu sama lain. Dengan kata lain, kita menghilangkan jalur pergerakan lateral antar-pool.
- Terapkan batasan penjadwalan untuk mencegah workload dengan persyaratan keamanan yang berbeda berjalan di mesin yang sama. Batasan penjadwalan ini mengurangi risiko penyusupan melalui eskalasi hak istimewa lokal.
Misalnya, WSR mengharuskan workload dasar berjalan di mesin khusus dan tidak pernah dijadwalkan bersama dengan workload non-dasar. Batasan ini memberikan isolasi yang kuat dari workload yang kurang aman.
Metode untuk mengisolasi workload
Software sistem modern sangat kompleks, dan peneliti keamanan secara berkala menemukan kerentanan eskalasi hak istimewa lokal, seperti eksploitasi zero-day kernel atau serangan saluran samping CPU baru. WSR, yang pertama kali
diperkenalkan
di USENIX ;login:, memungkinkan Google mengurangi risiko yang terkait dengan
kolokasi workload sekaligus mempertahankan pemanfaatan resource yang tinggi.
Secara default, Borg menggunakan batas proses tingkat OS untuk mengisolasi container. Proses ini menawarkan batas isolasi yang lebih lemah daripada virtual machine yang menggunakan virtualisasi berbasis hardware. Isolasi yang lebih lemah seperti itu biasanya merupakan kompromi yang baik antara efisiensi dan keamanan untuk lingkungan multi-tenant yang menjalankan workload tepercaya. Workload tepercaya adalah workload yang biner dan konfigurasinya dibangun secara terverifikasi dari kode yang telah ditinjau oleh rekan sejawat dengan asal yang terbukti. Workload tepercaya tidak memproses data tidak tepercaya arbitrer. Contoh pemrosesan data yang tidak tepercaya mencakup menghosting kode pihak ketiga atau mengenkode video.
Google mendapatkan kepercayaan pada biner kami dengan menggunakan BAB. Namun, BAB tidak cukup untuk memastikan integritas workload yang memproses data yang tidak tepercaya. Selain BAB, beban kerja tersebut juga harus berjalan di dalam sandbox. Sandbox adalah lingkungan yang dibatasi, seperti gVisor, yang memungkinkan biner berjalan dengan aman. BAB dan sandbox memiliki batasan.
BAB adalah kontrol yang kuat untuk produk yang sudah matang, tetapi dapat mengurangi kecepatan selama tahap awal pengembangan sistem baru dan saat menjalankan eksperimen tanpa data sensitif (misalnya, mengoptimalkan encoding data yang sudah publik). Batasan ini berarti beberapa workload harus selalu berjalan tanpa BAB. Beban kerja tersebut secara inheren memiliki risiko eskalasi hak istimewa lokal yang lebih tinggi (misalnya, dengan mengeksploitasi kerentanan kernel untuk mendapatkan akses root lokal di mesin).
Sandbox workload yang tidak tepercaya juga mengurangi risiko keamanan, tetapi dengan harga peningkatan penggunaan komputasi dan memori. Efisiensi dapat menurun hingga persentase dua digit, bergantung pada workload dan jenis sandbox. Untuk contoh dampak performa pada beban kerja yang di-sandbox, lihat benchmark mendetail dalam Panduan Performa gVisor. WSR memungkinkan kami mengatasi batasan efisiensi yang dihasilkan dari mengisolasi workload.
Ring workload
Google menentukan empat kelas workload sesuai dengan persyaratan keamanannya: dasar, sensitif, yang diperkuat, dan yang tidak diperkuat. Tabel berikut menjelaskan secara lebih mendetail.
| Cincin workload | Deskripsi |
|---|---|
| Dasar | Sejumlah kecil workload yang penting bagi keamanan Google, seperti layanan pengelolaan identitas dan akses. Workload dasar memiliki persyaratan keamanan tertinggi, dan secara rutin mengorbankan efisiensi untuk meningkatkan keamanan dan keandalan. |
| Sensitif | Workload yang dapat menyebabkan gangguan luas atau yang memiliki akses ke data sensitif khusus produk, seperti data pengguna atau pelanggan. |
| Telah melalui proses hardening | Mendukung workload yang tidak penting untuk keamanan, tetapi telah mengadopsi BAB atau di-sandbox, sehingga menimbulkan sedikit risiko bagi workload tetangga. |
| Tidak dikeraskan | Semua workload lainnya, termasuk yang menjalankan kode tidak tepercaya. |
Di Google, kami mengklasifikasikan workload penting yang mendukung produk tertentu sebagai sensitif, sementara workload dasar adalah workload yang dapat memengaruhi semua produk.
Tidak seperti beban kerja dasar dan sensitif, kita dapat mengklasifikasikan beban kerja apa pun sebagai beban kerja yang diperkuat hanya berdasarkan kontrol yang diterapkan dan jenis input yang diprosesnya. Dengan workload yang di-harden, kami terutama mengkhawatirkan dampaknya terhadap workload lain, sehingga solusi hardening dapat mencakup sandboxing.
Kumpulan mesin
Untuk menghindari penjadwalan bersama layanan sensitif dengan beban kerja yang kurang tepercaya (misalnya, yang memproses data yang tidak tepercaya tanpa sandbox), kita harus menjalankannya di kumpulan mesin yang terisolasi. Isolasi mesin mempermudah pemahaman invarian keamanan, tetapi setiap kumpulan mesin tambahan menimbulkan pertukaran dalam penggunaan dan pemeliharaan resource.
Isolasi mesin menghasilkan penggunaan resource fisik yang lebih rendah, karena memastikan kumpulan mesin digunakan sepenuhnya menjadi lebih sulit saat kita menambahkan lebih banyak kumpulan. Biaya efisiensi dapat menjadi signifikan jika ada beberapa kumpulan mesin besar yang terisolasi.
Karena jejak resource workload berfluktuasi di setiap pool, isolasi ketat menambah overhead pengelolaan untuk menyeimbangkan kembali dan mengubah fungsi mesin secara berkala antar-pool. Penyeimbangan ulang tersebut memerlukan pengurasan semua beban kerja dari mesin, melakukan booting ulang mesin, dan melakukan proses pembersihan mesin terberat yang membantu memastikan keaslian dan integritas firmware.
Pertimbangan ini berarti bahwa penerapan isolasi mesin oleh Google harus menyediakan cara untuk mengoptimalkan penggunaan resource fisik sekaligus mempertahankan beban kerja mendasar dan sensitif dari musuh.
Di Kubernetes, pendekatan ini dikenal sebagai isolasi node. Node Kubernetes dapat dipetakan ke mesin fisik atau virtual. Dalam makalah ini, kita akan berfokus pada komputer fisik. Selain itu, Google Cloud produk seperti Compute Engine menawarkan tenancy eksklusif untuk memberikan isolasi mesin fisik.
Batasan penjadwalan workload
Google menyediakan mesin ke dalam tiga jenis pool terisolasi: mesin dasar, mesin produksi, dan mesin pengembangan. Google mengoperasikan beberapa pool terisolasi yang menghosting workload dasar dan sensitif, tetapi dokumen ini menyajikan setiap pool sebagai satu pool untuk mempermudah.
Untuk menawarkan perlindungan yang paling efektif, kami men-deploy batasan penjadwalan berikut untuk WSR:
- Workload dasar hanya dapat berjalan di mesin dasar.
- Workload sensitif hanya dapat berjalan di mesin produksi.
- Workload yang tidak diperkeras hanya dapat berjalan di mesin pengembangan.
- Workload yang diperkuat dapat berjalan di mesin produksi atau pengembangan, dengan preferensi untuk mesin produksi.
Diagram berikut menunjukkan batasan penjadwalan.
Dalam diagram ini, batas isolasi memisahkan berbagai class workload baik di antara maupun dalam pool mesin. Workload dasar adalah satu-satunya penyewa mesin dasar khusus. Otorisasi biner atau sandboxing untuk beban kerja yang berjalan di mesin produksi membantu mencegah serangan eskalasi hak istimewa lokal. Di mesin pengembangan, ada risiko sisa bahwa workload yang tidak diperkeras dapat membahayakan workload lain, tetapi kompromi terbatas pada mesin pengembangan karena workload yang diperkeras tidak dapat membuat tugas baru.
Workload yang telah melalui proses hardening dijadwalkan di mesin produksi atau mesin pengembangan berdasarkan ketersediaan. Mengizinkan penjadwalan di beberapa pool mungkin tampak berlawanan dengan intuisi, tetapi hal ini penting untuk mengurangi penurunan penggunaan yang disebabkan oleh batasan penjadwalan. Workload yang diperkuat mengisi kesenjangan yang muncul akibat mengisolasi tugas sensitif dan tidak diperkuat. Selain itu, semakin besar jejak resource yang diperkuat, semakin banyak fluktuasi penggunaan resource dari dua kelas lainnya yang dapat diakomodasi tanpa perlu memindahkan mesin yang mahal antar-ring.
Diagram berikut menunjukkan batasan penjadwalan yang diterapkan pada berbagai class beban kerja. Workload yang diperkuat dapat berada di mesin produksi atau mesin pengembangan.
Dengan mengisolasi workload dasar di beberapa pool dasar, Google menukar efisiensi resource dengan keamanan yang lebih tinggi. Untungnya, workload dasar cenderung memiliki jejak resource yang relatif kecil, dan kumpulan kecil mesin khusus yang terisolasi memiliki dampak yang dapat diabaikan pada pemanfaatan secara keseluruhan.
WSR memberikan jaminan kuat bahwa workload non-dasar tidak pernah diizinkan untuk berjalan di mesin dasar. Mesin dasar dilindungi terhadap pergerakan lateral, karena hanya workload dasar yang dapat berjalan di mesin tersebut.
Ringkasan kontrol
Google menggunakan sejumlah kontrol di seluruh infrastrukturnya untuk membantu melindungi layanan produksi, mesin produksi, dan workload. Kontrol ini mencakup hal berikut:
- Kontrol akses administratif dan BAB untuk layanan produksi
- Kontrol akses shell, kontrol akses fisik, serta kontrol firmware dan software sistem untuk mesin produksi
- WSR untuk berbagai kelas beban kerja
Bersama-sama, kontrol ini menerapkan batasan yang membantu melindungi pengguna dan pelanggan Google—serta data mereka. Diagram berikut menggambarkan cara kerja kontrol bersama-sama untuk mendukung postur keamanan Google.
Langkah berikutnya
- Untuk informasi selengkapnya tentang kontrol keamanan di infrastruktur Google, baca Ringkasan desain keamanan infrastruktur Google.
- Untuk mempelajari budaya keamanan Google, baca Membangun sistem yang aman dan andal (buku O'Reilly).
- Untuk mempelajari lebih lanjut produk zero-touch, lihat presentasi SREcon.