Konten ini terakhir diperbarui pada Juni 2024, 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 debug, dan lainnya.
Dokumen ini menjelaskan beberapa mekanisme yang kami gunakan untuk mempertahankan postur keamanan terdepan di industri untuk layanan yang berjalan di lingkungan produksi Google. Layanan ini menempati spektrum sensitivitas keamanan yang lengkap, mulai dari eksperimen pengembangan yang tidak memiliki akses ke data sensitif apa pun hingga infrastruktur identitas penting. Layanan ini menyelesaikan tugas seperti memproses data pengguna, mengelola peluncuran software, serta penyediaan dan pengelolaan 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 yang paling penting bagi keamanan (juga dikenal sebagai layanan dasar)
- Mesin produksi
- Workload produksi
Kami menerapkan kontrol ini sehingga staf Google hanya dapat mengakses layanan, mesin, dan beban kerja untuk tujuan bisnis yang sah (misalnya, akses pemeliharaan), dan untuk mempertahankan diri dari risiko orang dalam dan penyusupan akun staf. Kontrol ini memberikan perlindungan defense-in-depth lebih lanjut yang melengkapi kontrol keamanan infrastruktur yang ada yang membantu mencegah penyusupan akun.
Perbaikan berkelanjutan
Kontrol yang dijelaskan dalam laporan 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 keamanan dan Site Reliability Engineering (SRE) Google terus menyesuaikan kontrol keamanan untuk memenuhi lanskap ancaman yang terus berubah.
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 supply chain 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 aman, atau akses darurat yang diaudit, dengan mengikuti filosofi Zero Touch Prod. Rangkaian kontrol yang menghapus akses manusia ke aset produksi disebut Tidak Ada Orang (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 lain yang diberi otorisasi.
Kontrol supply chain software: Sebagian besar beban kerja produksi di Google, termasuk layanan dasar, menjalankan biner dan konfigurasi tugas yang dibuat secara verifikable dari kode yang ditinjau sejawat dan terletak di sumber tepercaya. Kami menerapkan proses ini menggunakan Otorisasi Biner untuk Borg (BAB).
Diagram berikut menunjukkan kontrol yang membantu melindungi layanan produksi.
Saat menerapkan tingkat NoPe dan BAB tertinggi, kami membantu memastikan bahwa tidak ada personel yang memiliki akses sepihak, bahkan dalam keadaan darurat, ke layanan dasar, dan bahwa setiap akses dengan hak istimewa yang mereka terima memiliki cakupan dan durasi yang ditentukan dengan baik. Akses dengan hak istimewa adalah tingkat akses yang lebih tinggi yang diberikan kepada tenaga kerja untuk mengelola layanan produksi penting selama keadaan unik yang tidak ditangani oleh otomatisasi. Kami membuat pengecualian untuk aturan ini untuk memastikan bahwa Google memiliki cara untuk keluar dari situasi terkunci.
Banyak layanan produksi lainnya, 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 untuk memudahkan pemilik layanan produksi mengadopsi NoPe dan BAB dari waktu ke waktu.
Kontrol akses administratif
Di Borg, anggota peran produksi dapat membaca, menulis, atau menghapus data yang dimiliki peran produksi, dan mereka dapat mengeksekusi kode menggunakan otoritas peran. Peran produksi adalah identitas yang dapat menjalankan beban kerja di lingkungan produksi Google.
Keanggotaan permanen dalam peran produksi berisiko menimbulkan konsekuensi yang tidak diinginkan untuk produksi, dan risiko bahwa hak istimewa ini dapat disalahgunakan. Namun, misi SRE menuntut agar tim diberi kemampuan untuk memelihara layanan yang menjadi tanggung jawab mereka, sehingga penghapusan akses sepenuhnya mungkin bukan strategi yang layak.
Suite NoPe menyediakan cara untuk mengonfigurasi akses yang menyeimbangkan permintaan yang bersaing untuk memberdayakan tim dan menjaga keamanan sistem produksi. Dengan NoPe, personel Google akan 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 multi-pihak (MPA) membantu memastikan bahwa personel Google tidak dapat memperoleh akses ke layanan produksi tanpa justifikasi bisnis dan persetujuan dari individu lain yang diberi otorisasi 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 ditentukan dengan baik yang dapat dijalankan. Setiap perintah 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 access on demand (AoD) memerlukan personel untuk meminta keanggotaan sementara, bukan memungkinkan akun personel selalu memiliki hak istimewa akses. Kontrol ini membantu memastikan peningkatan kemampuan hanya diberikan untuk sementara dan atas alasan tertentu.
- Pemantauan permintaan akses personel ke layanan produksi: Google memerlukan audit berkala terhadap pola akses ke peran produksi yang menjalankan layanan produksi. Tujuan audit ini adalah untuk menghilangkan kebutuhan akan permintaan tersebut di masa mendatang, melalui peningkatan berkelanjutan pada API administratif. Akses ke layanan produksi hanya boleh disediakan untuk situasi respons darurat. Untuk layanan dasar, jumlah situasi saat akses diberikan sangat rendah sehingga tim keamanan melakukan audit setiap akses yang diberikan untuk mengonfirmasi validitasnya.
Bagian berikut membahas setiap kontrol secara mendetail.
Otorisasi multi-pihak untuk NoPe
MPA mewajibkan personel Google resmi lainnya untuk menyetujui permintaan akses.
Untuk permintaan guna mengakses layanan yang cukup sensitif, MPA juga mewajibkan tenaga kerja untuk memberikan justifikasi bisnis yang mereferensikan keadaan darurat 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 kumpulan perintah standar yang dapat dijalankan proxy aman atas nama pemanggil. Proxy aman menerapkan kebijakan otorisasi terperinci berbasis aturan untuk memberikan batasan pada akses ke layanan produksi. Kebijakan ini dapat, misalnya, mewajibkan persetujuan dari individu lain yang diberi otorisasi untuk menjalankan perintah yang dapat berdampak buruk pada keamanan atau keandalan (misalnya, perintah yang menghapus file). Kebijakan juga dapat mengizinkan perintah aman tertentu (misalnya, perintah yang mencantumkan penggunaan resource) dijalankan tanpa memerlukan persetujuan. Fleksibilitas ini sangat penting untuk meminimalkan tugas operasional.
Jika terjadi penyalahgunaan akses, akun masih dibatasi pada operasi yang diizinkan oleh proxy aman. Akun hanya dapat menjalankan perintah yang aman secara sepihak, sedangkan operasi dengan hak istimewa memerlukan persetujuan dari individu yang berwenang lainnya. Semua operasi meninggalkan log audit yang jelas.
Untuk informasi selengkapnya tentang proxy aman, lihat presentasi SREcon tentang zero touch prod. Zero touch prod adalah serangkaian prinsip dan alat yang menerapkan bahwa setiap perubahan dalam produksi dilakukan oleh otomatisasi (tidak ada orang yang terlibat), divalidasi sebelumnya oleh software, atau dibuat menggunakan mekanisme yang mampu menangani keadaan darurat yang diaudit.
Akses on demand
Akses on demand (AoD) memungkinkan Google mengurangi hak istimewa personel dengan mengganti langganan permanen dengan langganan yang memenuhi syarat.
Anggota yang memenuhi syarat untuk peran tertentu 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 lain yang berwenang, pemberian AoD akan menjadikan pemohon sebagai anggota peran selama jangka waktu terbatas, biasanya kurang dari satu hari.
Model keanggotaan yang memenuhi syarat memungkinkan personel hanya meminta subset akses
yang mereka perlukan selama durasi yang mereka perlukan. Secara konseptual, Anda dapat menganggap
AoD sebagai sudo produksi terikat waktu, mirip dengan perintah sudo -u di Unix,
yang memungkinkan Anda menjalankan beberapa perintah dengan izin yang ditingkatkan yang
dikaitkan dengan pengguna tertentu. Namun, tidak seperti sudo Unix, menerima hibah
AoD memerlukan justifikasi bisnis dan MPA, serta meninggalkan audit trail. Hibah
AoD juga dibatasi 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 yang aktif. Penggunaan proxy aman secara signifikan menghilangkan kebutuhan akan pemberian tersebut.
Pemantauan permintaan akses
Meskipun banyak area produksi Google menggunakan NoPe sebagai praktik pengurangan akses, pemberian AoD sangat jarang untuk peran produksi kami yang paling sensitif dan hanya dicadangkan untuk respons darurat. Selain itu, setiap peristiwa akan memicu audit manual setelah kejadian. Tujuan audit ini adalah untuk mengurangi frekuensi pemberian AoD pada masa mendatang (misalnya, dengan menggunakan peristiwa ini untuk memotivasi peningkatan pada Administrative API).
Google terus memantau hibah AoD, dan tindakan yang dilakukan saat memegang hibah tersebut, di seluruh perusahaan. Kami menggunakan data pemantauan real-time untuk mendeteksi potensi kompromi dan mengidentifikasi area untuk pengurangan akses lebih lanjut. Jika terjadi insiden, pelacakan audit mendukung respons yang cepat.
Otorisasi biner untuk Borg
Sama seperti NoPe yang membantu melindungi jalur akses dengan hak 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 dibuat 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 artefak biner atau konfigurasi software apa pun di-build secara verifikable dari kode sumber yang di-check in dan ditinjau sejawat.
Untuk informasi selengkapnya, lihat Otorisasi biner untuk Borg.
Melindungi mesin produksi
Selain memperkuat jalur akses dengan hak istimewa dan mempertahankan integritas supply chain software, Google melindungi mesin tempat layanan produksi berjalan. 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 aman yang mewajibkan orang lain yang berwenang untuk meninjau dan menyetujui setiap perintah sebelum perintah dieksekusi.
Hanya beberapa tim yang bekerja pada infrastruktur tingkat rendah yang mempertahankan akses shell non-unilateral sehingga mereka dapat men-debug masalah paling kompleks saat proxy aman tidak praktis untuk digunakan. Akses bersifat non-unilateral jika memerlukan otorisasi dari satu, atau beberapa, personel yang diberi otorisasi tambahan. Google membuat satu pengecualian saat akses shell sepihak diizinkan: untuk memastikan bahwa Google memiliki cara untuk keluar dari situasi penguncian.
Kontrol akses fisik: Komputer memerlukan pemeliharaan fisik rutin agar tetap berjalan 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 boot 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 yang 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, mengeksfiltrasi kredensial, atau menggunakan kredensial untuk mendapatkan pijakan yang persisten di lingkungan.
Untuk mengurangi risiko ini, kami menggunakan kumpulan kontrol berikut yang menggantikan akses SSH ke mesin produksi dengan metode alternatif yang aman:
- API Sempit: untuk tim dengan alur kerja yang ditentukan dengan baik yang sebelumnya memerlukan SSH, kami mengganti SSH dengan API yang ditentukan secara sempit dan dapat diaudit.
- Proxy aman untuk SSH: untuk tim yang memerlukan akses yang lebih fleksibel, proxy aman memungkinkan perintah diotorisasi dan diaudit satu per satu.
- MPA: saat SRE memerlukan akses SSH darurat ke komputer, Google memerlukan justifikasi bisnis dan individu yang berwenang untuk menyetujui akses tersebut. Transkrip sesi shell lengkap dicatat ke dalam log.
- Skenario penguncian: satu-satunya pengecualian saat akses SSH sepihak diizinkan. Transkrip sesi shell lengkap dicatat ke dalam log.
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 berhenti memerlukan akses langsung ke mesin Linux yang menjalankan biner mereka, tetapi akses shell tetap ada karena beberapa alasan:
- Petugas terkadang memerlukan akses langsung ke mesin untuk tujuan proses debug.
- Akses SSH adalah alat pengajaran yang berharga untuk memahami berbagai lapisan abstraksi.
- Dalam skenario pemulihan dari bencana yang tidak terduga, alat tingkat lebih tinggi mungkin tidak tersedia.
Untuk menyeimbangkan antara alasan ini dan risiko keamanan yang ditimbulkannya, Google mengejar serangkaian pencapaian untuk secara bertahap menghilangkan risiko SSH, lalu penggunaannya.
Pencapaian pemantauan dan kontrol akses terpusat
Google berinvestasi dalam sistem otorisasi dan pemantauan SSH pusat yang dikenal sebagai host identity-based monitoring authorization (HIBA). HIBA memberikan visibilitas ke penggunaan SSH dan memungkinkan penegakan kebijakan otorisasi yang ketat. Upaya SSH dicatat ke dalam log, tidak hanya oleh mesin target, tetapi juga oleh proxy BeyondCorp terpusat. Perintah yang dieksekusi oleh shell dicatat ke dalam log dan dimasukkan ke dalam pipeline deteksi perilaku berbahaya. Namun, deteksi pada dasarnya bersifat reaktif dan rentan terhadap pengelakan dan obfuscation.
Menghapus tonggak pencapaian akses sepihak
Untuk sebagian besar personel, Google telah menghapus akses shell (misalnya, melalui SSH) ke mesin produksi atau ke beban kerja yang berjalan di Borg. Namun, aplikasi tersebut tetap dapat diakses di mesin pengujian (misalnya, mesin yang digunakan untuk memenuhi syarat hardware baru atau software tingkat rendah baru, tetapi tidak menjalankan layanan produksi) untuk tim pengembangan.
API Sempit
Beberapa tim Google yang sebelumnya mengandalkan SSH untuk menjalankan sejumlah terbatas perintah yang ditentukan secara akurat (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 auditabilitas terbaik. Dengan mem-build-nya 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 terlebih dahulu. 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.
Proksi aman untuk SSH bertanggung jawab atas otorisasi terperinci untuk eksekusi perintah dan untuk audit. Otorisasi didasarkan pada argumen dan lingkungan perintah, parameter pembatasan kapasitas, justifikasi bisnis, dan MPA. Proses otorisasi ini memungkinkan pembatasan yang akurat secara arbitrer pada perintah yang dapat dijalankan dengan mengikuti playbook tim dan praktik terbaik. Dalam kondisi kegagalan yang tidak terduga dan tidak tercakup dalam playbook yang ada, personel masih dapat menjalankan perintah proses debug yang diperlukan setelah individu lain yang berwenang menyetujuinya.
MPA untuk SSH
Beberapa tim yang tersisa yang bekerja pada 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 penguncian. Kunci SSH yang digunakan untuk tujuan ini dibuat dengan proses audit yang berbeda dan disimpan secara offline di hardware yang tahan modifikasi tidak sah. Saat kunci ini digunakan, transkrip sesi shell lengkap akan dicatat ke dalam log.
Kontrol akses fisik
Pusat data Google adalah lingkungan server, perangkat jaringan, dan sistem kontrol yang kompleks yang memerlukan berbagai peran dan keterampilan untuk mengelola, memelihara, dan mengoperasikan.
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 ruang fisik-ke-logis.
Kontrol fisik ke logis memberikan lapisan pertahanan tambahan melalui kontrol yang disebut hardening komputer, kontrol akses berbasis tugas, dan pertahanan diri sistem. Kontrol fisik-ke-logis melindungi dari penyerang yang berusaha mengeksploitasi akses fisik ke mesin dan melakukan eskalasi ke serangan logis pada workload mesin.
Untuk 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 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 antara workload dengan persyaratan keamanan yang berbeda. Infrastruktur Google menggunakan hierarki beban kerja yang disebut workload security ring (WSR). WSR membantu memastikan bahwa workload penting tidak dijadwalkan di mesin yang sama dengan workload yang kurang aman, sekaligus menghindari dampak negatif terhadap penggunaan resource. WSR mengelompokkan workload ke dalam empat class sensitivitas — dasar, sensitif, di-harden, dan tidak di-harden — dan mencoba menjadwalkannya di berbagai kumpulan mesin.
Diagram berikut menunjukkan cara WSR mengelompokkan dan menjadwalkan beban kerja di seluruh komputer dasar, produksi, dan pengembangan.
WSR memberikan lapisan pertahanan tambahan terhadap eskalasi akses lokal menggunakan serangan kerentanan kernel atau serangan saluran samping 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:
- Klasifikasikan workload sesuai dengan persyaratan keamanannya. Setiap class disebut cincin beban kerja.
- Mendistribusikan mesin fisik di beberapa kumpulan mesin yang terisolasi satu sama lain. Dengan kata lain, kita menghilangkan jalur gerakan lateral di antara kumpulan.
- Terapkan batasan penjadwalan untuk mencegah workload dengan persyaratan keamanan yang berbeda berjalan di mesin yang sama. Batasan penjadwalan ini mengurangi risiko penyusupan melalui eskalasi akses lokal.
Misalnya, WSR mewajibkan 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 bersifat kompleks, dan peneliti keamanan secara berkala
menemukan kerentanan eskalasi hak istimewa lokal, seperti eksploitasi zero-day
kernel atau serangan side-channel CPU baru. WSR, yang pertama kali
diperkenalkan
di USENIX ;login:, memungkinkan Google mengurangi risiko yang terkait dengan
kolokasi beban kerja sekaligus mempertahankan penggunaan resource yang tinggi.
Secara default, Borg menggunakan batas proses tingkat OS untuk mengisolasi penampung. Proses ini menawarkan batas isolasi yang lebih lemah daripada virtual machine yang menggunakan virtualisasi berbasis hardware. Isolasi yang lebih lemah tersebut 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 di-build secara verifikable dari kode dengan verifikasi provenans yang ditinjau sejawat. Workload tepercaya tidak memproses data arbitrer yang tidak tepercaya. Contoh pemrosesan data yang tidak tepercaya mencakup menghosting kode pihak ketiga atau mengenkode video.
Google memperoleh kepercayaan dalam biner kami dengan menggunakan BAB. Namun, BAB tidak cukup untuk memastikan integritas workload yang memproses data 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 beban kerja harus selalu berjalan tanpa BAB. Beban kerja tersebut secara inheren berisiko lebih tinggi terhadap eskalasi hak istimewa lokal (misalnya, dengan mengeksploitasi kerentanan kernel untuk mendapatkan root lokal di komputer).
Sandboxing workload yang tidak tepercaya juga mengurangi risiko keamanan, tetapi dengan biaya peningkatan penggunaan komputasi dan memori. Efisiensi dapat menurun sebesar persentase dua digit, bergantung pada beban kerja dan jenis sandbox. Untuk mengetahui contoh dampak performa pada beban kerja dengan sandbox, lihat benchmark mendetail di Panduan Performa gVisor. WSR memungkinkan kita mengatasi batasan efisiensi yang dihasilkan dari mengisolasi workload.
Cincin beban kerja
Google menentukan empat class workload sesuai dengan persyaratan keamanannya: dasar, sensitif, di-harden, dan tidak di-harden. Tabel berikut menjelaskannya secara lebih mendetail.
| Cincin beban kerja | Deskripsi |
|---|---|
| Dasar | Workload yang penting bagi keamanan Google, seperti layanan pengelolaan akses dan identitas. Workload dasar memiliki persyaratan keamanan tertinggi, dan secara rutin mengorbankan efisiensi untuk meningkatkan keamanan dan keandalan. |
| Sensitif | Beban kerja yang dapat menyebabkan pemadaman layanan secara luas atau yang memiliki akses ke data khusus produk yang sensitif, seperti data pengguna atau pelanggan. |
| Telah melalui proses hardening | Mendukung beban kerja yang tidak bersifat penting bagi keamanan, tetapi telah mengadopsi BAB atau di-sandbox, sehingga tidak menimbulkan banyak risiko bagi beban kerja di sekitarnya. |
| Tidak di-hardening | Semua workload lainnya, termasuk yang menjalankan kode tidak tepercaya. |
Di Google, kami mengklasifikasikan beban kerja penting yang mendukung produk tertentu sebagai sensitif, sedangkan beban kerja dasar adalah beban kerja yang dapat memengaruhi semua produk.
Tidak seperti beban kerja dasar dan sensitif, kita dapat mengklasifikasikan beban kerja apa pun sebagai di-harden berdasarkan kontrol yang diadopsi dan jenis input yang diprosesnya. Dengan workload yang di-hardening, kami terutama khawatir dengan 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 tidak tepercaya tanpa sandbox), kita harus menjalankannya di kumpulan mesin yang terisolasi. Isolasi mesin memudahkan untuk memahami invariant keamanan, tetapi setiap kumpulan mesin tambahan akan menimbulkan kompromi dalam penggunaan dan pemeliharaan resource.
Isolasi mesin menghasilkan penggunaan resource fisik yang lebih rendah, karena memastikan bahwa kumpulan mesin dimanfaatkan sepenuhnya menjadi lebih sulit saat kita menambahkan lebih banyak kumpulan. Biaya efisiensi mungkin menjadi signifikan jika ada beberapa kumpulan mesin besar yang terisolasi.
Karena jejak resource workload berfluktuasi di setiap kumpulan, isolasi ketat akan menambah overhead pengelolaan untuk menyeimbangkan dan menggunakan kembali komputer secara berkala di antara kumpulan. Penyeimbangan ulang tersebut memerlukan pengosongan semua beban kerja dari mesin, memulai ulang mesin, dan melakukan proses pembersihan mesin yang paling berat yang membantu memastikan autentisitas dan integritas firmware.
Pertimbangan ini berarti bahwa penerapan isolasi mesin Google harus memberikan cara untuk mengoptimalkan penggunaan resource fisik sekaligus menjaga workload dasar dan sensitif dari penyerang.
Di Kubernetes, pendekatan ini dikenal sebagai isolasi node. Node Kubernetes dapat dipetakan ke virtual machine atau mesin fisik. Dalam makalah ini, kita akan berfokus pada mesin fisik. Selain itu, produk Google Cloud seperti Compute Engine menawarkan sewa tunggal untuk memberikan isolasi mesin fisik.
Batasan penjadwalan beban kerja
Google menyediakan mesin ke dalam tiga jenis kumpulan terisolasi: mesin dasar, mesin produksi, dan mesin pengembangan. Google mengoperasikan beberapa kumpulan terisolasi yang menghosting workload dasar dan sensitif, tetapi dokumen ini menampilkan setiap kumpulan sebagai satu kumpulan untuk memudahkan.
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 di-harden hanya dapat berjalan di mesin pengembangan.
- Workload yang di-harden 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 kumpulan mesin. Workload dasar adalah satu-satunya tenant mesin dasar khusus. Otorisasi biner atau sandbox untuk beban kerja yang berjalan di mesin produksi membantu mencegah serangan eskalasi hak istimewa lokal. Pada mesin pengembangan, ada risiko residu bahwa workload yang tidak di-harden dapat membahayakan workload lain, tetapi kompromi tersebut terbatas pada mesin pengembangan karena workload yang di-harden tidak dapat membuat tugas baru.
Workload yang telah di-harden dijadwalkan di mesin produksi atau mesin pengembangan berdasarkan ketersediaan. Mengizinkan penjadwalan di beberapa kumpulan mungkin tampak bertentangan, tetapi hal ini penting untuk mengurangi penurunan penggunaan yang disebabkan oleh batasan penjadwalan. Workload yang di-harden mengisi kesenjangan yang diperkenalkan dengan mengisolasi tugas sensitif dan tidak di-harden. Selain itu, semakin besar jejak resource yang di-harden, semakin banyak fluktuasi penggunaan resource dari dua class lainnya yang dapat diakomodasi tanpa memerlukan pemindahan mesin yang mahal di antara ring.
Diagram berikut menunjukkan batasan penjadwalan yang diterapkan pada berbagai class beban kerja. Beban kerja yang di-harden dapat berada di mesin produksi atau mesin pengembangan.
Dengan mengisolasi beban kerja dasar di beberapa kumpulan dasar, Google mengorbankan efisiensi resource untuk keamanan yang lebih tinggi. Untungnya, workload dasar cenderung memiliki jejak resource yang relatif kecil, dan kumpulan mesin khusus yang terisolasi dan kecil memiliki dampak yang dapat diabaikan terhadap pemanfaatan secara keseluruhan. Namun, meskipun dengan otomatisasi yang luas, mengelola beberapa kumpulan mesin tidak tanpa biaya, sehingga kami terus mengembangkan desain mesin untuk meningkatkan isolasi.
WSR memberikan jaminan kuat bahwa workload non-dasar tidak pernah diizinkan untuk berjalan di mesin dasar. Mesin dasar dilindungi dari 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 tersebut 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 class workload
Bersama-sama, kontrol ini menerapkan batasan yang membantu melindungi pengguna dan pelanggan Google—serta data mereka. Diagram berikut menggambarkan cara kontrol bekerja sama untuk mendukung postur keamanan Google.
Langkah selanjutnya
- 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 produksi zero-touch, lihat presentasi SREcon.
Penulis: Michael Czapiński dan Kevin Plybon