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 komputasi berskala global, multi-tenant, dan terdistribusi infrastruktur Anda untuk menyediakan produk dan layanan kepada miliaran orang di seluruh saat ini. Infrastruktur ini harus menyeimbangkan prioritas keamanan yang bersaing, 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-tugas seperti memproses data pengguna, mengelola peluncuran software, serta penyediaan dan siklus proses manajemen untuk setiap komputer fisik.
Dokumen ini menjelaskan kontrol keamanan yang membantu melindungi hal-hal berikut tiga lapisan utama infrastruktur kami:
- Layanan produksi, yang mencakup layanan yang paling penting bagi keamanan (juga dikenal sebagai layanan dasar)
- Mesin produksi
- Workload produksi
Kami menerapkan kontrol ini agar Google personel hanya dapat mengakses layanan, mesin, dan beban kerja untuk tujuan bisnis (misalnya, akses pemeliharaan), dan untuk melindungi risiko internal dan penyusupan akun personel. Kontrol ini memberikan informasi perlindungan defense in depth yang melengkapi infrastruktur yang ada keamanan kontrol yang membantu mencegah penyusupan akun.
Perbaikan berkelanjutan
Kontrol yang dijelaskan dalam makalah ini digunakan di seluruh lingkungan production. Banyak layanan, termasuk layanan dasar, menggunakan tingkat kontrol terbaru yang kami tawarkan. Namun, karena cakupan dan infrastruktur Google, layanan produksi individu sering kali memiliki persyaratan unik dan mungkin memerlukan waktu tambahan untuk menerapkan rekomendasi. Melalui budaya peningkatan berkelanjutan, Site Reliability Engineering (SRE) dan tim keamanan terus menyesuaikan kontrol keamanan untuk memenuhi 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 supply chain software.
Daftar berikut menjelaskan kontrol yang membantu melindungi setiap jalur akses.
Kontrol akses administratif: Layanan produksi memerlukan pemeliharaan (misalnya, peluncuran biner atau konfigurasi). Di Google, tujuannya adalah bahwa operasi tersebut dilakukan melalui otomatisasi, {i>proxy<i} yang aman, atau akses darurat yang diaudit, setelah Zero Touch Prod filosofi Google. Rangkaian kontrol yang menghapus akses manusia ke produksi aset disebut Tidak Ada Orang (NoPe). NoPe memberi Google fleksibilitas untuk men-deploy kontrol akses berdasarkan pada sensitivitas layanan produksi dan kesiapannya untuk mencapai yang lebih kuat melalui peningkatan berkelanjutan.
Misalnya, Google tidak mengizinkan akses sepihak ke lainnya — bahkan akses darurat memerlukan persetujuan dari karyawan. 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 menegakkan proses ini menggunakan Otorisasi Biner untuk Borg (BAB).
Diagram berikut menunjukkan kontrol yang membantu melindungi sistem produksi layanan.
Dengan menerapkan tingkat NoPe dan BAB tertinggi, kami membantu memastikan bahwa tidak terdapat akses sepihak, bahkan dalam keadaan darurat, ke layanan dasar, dan bahwa setiap akses istimewa yang mereka terima memiliki ruang lingkup yang terdefinisi dengan baik durasi. Akses istimewa adalah tingkat akses yang lebih tinggi yang diberikan kepada personel untuk mengelola layanan produksi yang penting dalam keadaan yang unik yang tidak ditangani oleh otomatisasi. Kami membuat pengecualian terhadap 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 NoPe dan BAB tingkat tertinggi, dan kami terus berupaya memudahkan pemilik layanan produksi untuk 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 workload di lingkungan production.
Keanggotaan permanen dalam peran produksi membawa risiko hal-hal yang tidak diinginkan konsekuensi untuk produksi, dan risiko bahwa hak istimewa ini dapat disalahgunakan. Namun, misi SRE menuntut agar tim diberdayakan untuk memelihara layanan yang menjadi tanggung jawab mereka, sehingga penghapusan akses secara menyeluruh mungkin bukan masalah strategi.
NoPe Suite menyediakan cara untuk mengonfigurasi akses yang menyeimbangkan antara tuntutan pemberdayaan tim dan penjagaan keamanan sistem produksi. Dengan NoPe, Staf Google mengalami kendala mengenai hak istimewa akun mereka ketika mereka mencoba mengakses layanan produksi. NoPe memungkinkan hal berikut batasan:
- 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. {i>Proxy<i} aman dirancang sehingga hanya serangkaian perintah yang terdefinisi dengan baik yang dapat telah dijalankan. Perintah apa pun yang dipertimbangkan oleh organisasi Keamanan dan SRE Google berisiko (misalnya, menonaktifkan layanan atau mengakses atau menghapus data) juga memerlukan MPA.
- Tidak ada keanggotaan peran produksi permanen: kontrol yang disebut akses on-demand (AoD) membutuhkan personel untuk meminta keanggotaan sementara, memungkinkan akun personel untuk selalu memiliki hak 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 di masa mendatang, melalui peningkatan berkelanjutan Google Cloud Platform. Akses ke layanan produksi harus dicadangkan hanya untuk keadaan darurat yang ada. Untuk layanan dasar, jumlah situasi ketika akses diberikan sangat rendah sehingga tim keamanan akan melakukan audit masing-masing diberikan akses untuk mengkonfirmasi 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 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 menjadi penghalang terhadap penyalahgunaan akses.
Proxy aman untuk NoPe
{i>Proxy<i} aman adalah alat yang mengekspos serangkaian perintah bawaan yang telah yang dapat dijalankan atas nama pemanggil. Proxy aman menerapkan kebijakan otorisasi berbasis aturan untuk memberikan batasan pada akses ke produksi layanan IT perusahaan mereka. Kebijakan ini dapat, misalnya, memerlukan persetujuan dari individu yang berwenang 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 operasional bisnis.
Dalam kasus penyalahgunaan akses, akun tetap dibatasi hanya untuk operasi yang yang diizinkan oleh proxy yang 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 jejak audit yang jelas.
Untuk informasi selengkapnya tentang proxy aman, lihat Presentasi SREcon di produsen zero-touch. Produk zero-touch adalah rangkaian prinsip dan alat yang bahwa setiap perubahan dalam produksi dilakukan oleh otomatisasi (tidak ada orang terlibat), divalidasi sebelumnya oleh software, atau dibuat dengan kemampuan mekanisme atensi.
Akses on-demand
Dengan akses on-demand (AoD), Google dapat mengurangi hak istimewa personel dengan mengganti keanggotaan permanen dengan keanggotaan yang memenuhi syarat.
Anggota peran yang memenuhi syarat tidak memiliki akses ke hak istimewanya. Sebaliknya, jika anggota peran yang memenuhi syarat memerlukan akses, mereka dapat meminta keanggotaan sementara, yang dikenal sebagai hibah AoD. Jika disetujui oleh individu lain yang berwenang, maka AoD memberi pemohon sebagai anggota peran selama jangka waktu terbatas, biasanya kurang dari sehari.
Model keanggotaan yang memenuhi syarat memungkinkan personel meminta subset akses saja
yang mereka butuhkan selama
durasi waktu yang mereka butuhkan. Secara konseptual, Anda
dapat memikirkan
AoD sebagai sudo produksi yang terikat waktu, mirip dengan perintah sudo -u di Unix,
yang memungkinkan Anda menjalankan beberapa
perintah dengan izin akses yang ditingkatkan yang
yang terkait dengan pengguna tertentu. Namun, tidak seperti Unix sudo, penerimaan AoD
hibah memerlukan justifikasi bisnis dan MPA, serta meninggalkan jejak audit. Hibah
AoD juga dibatasi waktu.
Mengamankan hak istimewa sensitif di balik langganan yang memenuhi syarat berarti bahwa meskipun Anda dalam kasus penyalahgunaan akses, akun hanya dapat mengakses hak istimewa tersebut ketika ada hibah aktif. Penggunaan proxy aman secara signifikan menghilangkan kebutuhan akan pemberian tersebut.
Pemantauan permintaan akses
Meskipun banyak area produksi Google menggunakan NoPe sebagai pengurangan akses sangat jarang terjadi, hibah AoD sangat langka untuk produksi kami yang paling sensitif peran dan hanya disediakan untuk petugas tanggap darurat. Selain itu, setiap peristiwa akan memicu audit manual setelah kejadian. Tujuan audit ini adalah untuk mengurangi frekuensi pemberian AoD di masa mendatang (misalnya, dengan menggunakan peristiwa ini untuk memotivasi peningkatan pada API Administratif).
Google terus memantau hibah AoD, dan tindakan yang diambil saat menerima hibah AoD tersebut hibah, di seluruh perusahaan. Kami menggunakan data pemantauan real-time untuk mendeteksi potensi penyusupan dan identifikasi area untuk pengurangan akses lebih lanjut. Jika terjadinya insiden, jejak audit mendukung respons yang cepat.
Otorisasi biner untuk Borg
Sama seperti NoPe yang membantu melindungi jalur akses hak istimewa, Otorisasi Biner 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 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 memodifikasi kode sumber, menjalankan biner, atau mengkonfigurasi pekerjaan tanpa tinjauan sejawat, dan bahwa setiap artefak biner atau perangkat lunak dibuat secara terverifikasi dari kode sumber yang telah diperiksa dan ditinjau oleh rekan 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. Khususnya, kami mengimplementasikan hal berikut:
Kontrol akses shell: Sebagian besar personel Google tidak memiliki shell akses (misalnya, melalui SSH) ke mesin produksi atau ke beban kerja berjalan di Borg Sistem pengelolaan cluster Google. Sebaliknya, individu harus menggunakan kuasa yang mewajibkan orang lain yang berwenang untuk meninjau dan menyetujui masing-masing sebelum perintah tersebut 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 lebih, karyawan. 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 pusat data teknisi hanya mengakses komputer fisik dalam konteks alamat email alasan bisnis, Google menggunakan kontrol fisik-ke-logika.
Kontrol firmware dan software sistem: Google menerapkan model alur keamanan {i>boot<i} yang didasarkan pada akar kepercayaan perangkat keras. Perkakas Bertukang akar kepercayaan membantu memastikan integritas dari setiap {i>boot firmware <i} dan perangkat lunak sistem milik setiap komputer.
Diagram berikut menunjukkan kontrol yang membantu melindungi mesin dalam data tengah.
Kontrol akses shell
SSH adalah alat administratif {i>open source<i} yang populer untuk memungkinkan akses ke server berbasis Linux. Tanpa kontrol pada akses SSH, akun dengan yang benar mendapatkan sebuah shell yang memungkinkan mereka mengeksekusi kode arbitrer dalam cara yang sulit untuk diaudit.
Dengan akses {i>shell<i} ke layanan produksi, akun dapat, misalnya, mengubah perilaku tugas yang sedang berjalan, memindahkan kredensial yang tidak sah, atau menggunakan agar mereka dapat terus bekerja di lingkungan itu.
Untuk mengurangi risiko ini, kami menggunakan serangkaian kontrol berikut yang menggantikan SSH akses ke mesin produksi dengan metode alternatif yang aman:
- API Terbatas: untuk tim dengan alur kerja yang ditentukan dengan baik yang sebelumnya memerlukan SSH, kami mengganti SSH dengan API yang ditentukan secara terbatas dan dapat diaudit.
- Proxy aman untuk SSH: untuk tim yang memerlukan akses yang lebih fleksibel, proxy aman mengizinkan perintah untuk diotorisasi dan diaudit secara individual.
- MPA: saat SRE memerlukan akses SSH darurat ke komputer, Google memerlukan justifikasi bisnis dan individu yang berwenang untuk memberikan persetujuan aksesnya. 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 untuk tidak lagi memerlukan akses langsung ke komputer Linux yang menjalankan biner mereka, tetapi akses {i>shell<i} dipertahankan selama beberapa alasan:
- Personel terkadang memerlukan akses langsung ke mesin untuk proses debug tujuan.
- Akses SSH adalah alat pengajaran yang berharga untuk memahami berbagai lapisan abstraksi.
- Dalam skenario pemulihan dari bencana yang tidak terduga, alat dengan tingkat yang lebih tinggi mungkin tidak tersedia.
Untuk menyeimbangkan antara alasan ini dan risiko keamanan yang mereka timbulkan, Google mengejar serangkaian tonggak pencapaian untuk secara bertahap menghilangkan risiko SSH dan kemudian penggunaan.
Tahap 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 terhadap setiap penggunaan SSH dan memungkinkan kebijakan otorisasi. Upaya SSH dicatat, tidak hanya oleh komputer target, tetapi juga dengan pendekatan Proxy BeyondCorp. Perintah yang dijalankan oleh shell dicatat dan dimasukkan ke dalam perilaku berbahaya pipeline deteksi. Namun, pada dasarnya deteksi pada dasarnya reaktif dan rentan terhadap penghindaran dan obfuscation.
Meniadakan 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, cara ini tetap dapat diakses di komputer uji (misalnya, komputer yang digunakan untuk memenuhi syarat perangkat keras atau perangkat lunak tingkat rendah baru tetapi tidak menjalankan layanan produksi) untuk tim pengembangan.
API Sempit
Beberapa tim Google yang sebelumnya mengandalkan SSH untuk menjalankan perintah yang didefinisikan secara tepat (misalnya, dalam playbook), atau untuk mendapatkan data yang dapat diprediksi, kini gunakan API yang didefinisikan secara sempit yang melayani kasus penggunaan dan menyediakan data terstruktur.
API sempit memiliki sejumlah kecil metode yang selaras dengan perjalanan pengguna umum dan mengabstraksi detail akses tingkat rendah. Akibatnya, mereka adalah sebagai solusi pilihan karena memberikan keamanan dan kemampuan audit terbaik. Menurut membangunnya di infrastruktur remote procedure call (RPC) Google, kami mendapatkan manfaat dari investasi 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 berjalan perintah yang hanya menerima permintaan eksekusi perintah arbitrer dari proxy tepercaya yang dijalankan oleh keamanan. Teknologi ini mirip dengan teknologi yang digunakan dalam proxy yang aman untuk NoPe.
Proxy yang aman untuk SSH bertanggung jawab atas otorisasi perintah yang terperinci dieksekusi dan untuk audit. Otorisasi didasarkan pada argumen dan lingkungan perintah, parameter pembatasan kapasitas, justifikasi bisnis, dan MPA. Ini otorisasi memungkinkan pembatasan yang tepat secara sewenang-wenang atas perintah apa dapat berjalan dengan mengikuti playbook tim dan praktik terbaik. Dalam kegagalan tak terduga kondisi yang tidak dicakup dalam playbook yang ada, personel masih dapat menjalankan perintah {i>debugging <i}yang diperlukan setelah individu lain yang diotorisasi memiliki 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 ketika akses shell sepihak diizinkan: untuk memastikan Google dapat memperbaiki situasi penguncian. Kunci SSH yang digunakan untuk tujuan ini dibuat dengan proses khusus yang dapat diaudit dan disimpan secara offline pada perangkat keras yang tahan perusakan. Saat kunci ini digunakan, transkrip sesi shell lengkap akan dicatat ke dalam log.
Kontrol akses fisik
Pusat data Google adalah lingkungan server, perangkat jaringan yang kompleks, dan sistem kontrol yang membutuhkan berbagai peran dan keterampilan untuk dikelola, dirawat, dan dioperasikan.
Google menerapkan enam lapisan kontrol fisik dan banyak kontrol logis pada mesin itu sendiri untuk membantu melindungi workload di pusat data. Kami juga menjaga jarak antarkomputer, yang kami sebut 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 logika bertahan melawan musuh yang mencoba mengeksploitasi akses fisik ke komputer dan mengeskalasikan ke serangan yang logis menyesuaikan beban kerja komputer.
Untuk informasi selengkapnya, lihat Cara Google melindungi ruang fisik-ke-logika 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 di 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 cincin keamanan beban kerja (WSR). WSR membantu memastikan bahwa workload kritis tidak dijadwalkan di mesin yang sama workload yang kurang aman, sekaligus menghindari dampak negatif pada resource tingkat penggunaan. WSR mengelompokkan beban kerja ke dalam empat sensitivitas kelas dasar — dasar, sensitif, diperkeras, dan tidak dihardening — dan mencoba menjadwalkannya di kumpulan mesin yang berbeda.
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 {i>kernel<i} atau CPU serangan side-channel. WSR membantu memastikan bahwa hanya workload dengan keamanan yang serupa persyaratannya dijadwalkan bersama di komputer yang sama. Untuk mengimplementasikan WSR, kita melakukan berikut ini:
- Klasifikasikan workload sesuai dengan persyaratan keamanannya. Setiap class dikenal sebagai cincin beban kerja.
- Mendistribusikan mesin fisik ke beberapa kumpulan mesin yang terisolasi satu sama lain. Dengan kata lain, kita menghilangkan gerakan lateral jalur antarkumpulan.
- 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 mengharuskan workload dasar berjalan di mesin khusus dan tidak pernah dijadwalkan bersama dengan beban kerja non-dasar. Batasan ini memberikan isolasi yang kuat dari workload yang kurang aman.
Metode untuk mengisolasi workload
Perangkat lunak sistem modern sangatlah kompleks, dan peneliti keamanan secara berkala
menemukan kerentanan eskalasi akses lokal, seperti kernel zero-day
atau serangan {i>side-channel<i} CPU baru. WSR, pertama
diperkenalkan
di USENIX ;login:, memungkinkan Google mengurangi risiko yang terkait dengan
kolokasi workload sambil mempertahankan penggunaan resource yang tinggi.
Secara default, Borg menggunakan batas proses tingkat OS untuk mengisolasi container. Ini proses menawarkan batas isolasi yang lebih lemah daripada mesin virtual 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. Beban kerja tepercaya adalah beban kerja di mana biner dan sebenarnya dibuat dari kode yang ditinjau oleh rekan sejawat dari asal usul. Workload tepercaya tidak memproses data tidak tepercaya yang arbitrer. Contoh pemrosesan data yang tidak tepercaya mencakup menghosting kode atau encoding video.
Google memperoleh kepercayaan dalam biner kami dengan menggunakan BAB. Namun, BAB tidak cukup untuk memastikan integritas workload yang diproses data yang tidak dapat dipercaya. Selain BAB, beban kerja tersebut juga harus dijalankan di dalam sandbox. Sandbox adalah lingkungan yang terbatas, seperti gVisor yang didukung, yang memungkinkan sebuah 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). Keterbatasan ini berarti bahwa 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).
Sandbox workload yang tidak tepercaya juga mengurangi risiko keamanan, tetapi biaya atas peningkatan penggunaan komputasi dan memori. Efisiensi dapat menurun sebesar persentase dua digit, bergantung pada beban kerja dan jenis sandbox. Misalnya, dampak performa pada beban kerja sandbox, lihat tolok ukur mendetail di tindakan Panduan Performa gVisor. WSR memungkinkan kita mengatasi batasan efisiensi yang dihasilkan dari isolasi sebagian besar workload standar dan berbasis cloud.
Dering beban kerja
Google mendefinisikan empat kelas workload berdasarkan keamanannya persyaratan: dasar, sensitif, telah melalui proses hardening, dan tidak dihardening. Hal berikut menjelaskannya secara lebih rinci.
| Dering beban kerja | Deskripsi |
|---|---|
| Dasar | Workload yang penting bagi keamanan Google, seperti layanan pengelolaan akses dan identitas. Beban kerja dasar memiliki persyaratan keamanan tertinggi, dan secara rutin bertukar efisiensi dengan peningkatan 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 workload yang tidak penting bagi keamanan, tetapi memiliki mengadopsi BAB atau menggunakan sandbox, sehingga menimbulkan sedikit risiko terhadap workload yang berdekatan. |
| Tidak dihardening | Semua workload lainnya, termasuk yang menjalankan workload yang tidak tepercaya pada kode sumber. |
Di Google, kami mengklasifikasikan workload penting yang mendukung produk tertentu sebagai sensitif, sedangkan workload dasar adalah workload yang dapat memengaruhi semua produk.
Tidak seperti workload yang mendasar dan sensitif, kami dapat mengklasifikasikan workload apa pun sebagai berdasarkan kontrol yang diadopsinya dan jenis input yang proses-proses tersebut. Untuk workload yang telah melalui proses hardening, kami sangat peduli dengan berdampak pada workload lain, jadi solusi hardening dapat mencakup sandboxing.
Kumpulan mesin
Untuk menghindari penjadwalan layanan sensitif bersama dengan workload yang kurang tepercaya (misalnya, yang memproses data tidak tepercaya tanpa {i>sandbox<i}), kita harus menjalankan pada kumpulan komputer yang terisolasi. Isolasi mesin memudahkan untuk memahami invarian keamanan, tetapi setiap kumpulan mesin tambahan memperkenalkan untung-rugi penggunaan dan pemeliharaan sumber daya.
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 bisa menjadi signifikan ketika ada beberapa kumpulan mesin besar dan terisolasi.
Karena jejak resource workload berfluktuasi di setiap kumpulan, isolasi menambahkan overhead pengelolaan untuk menyeimbangkan kembali dan menggunakannya secara berkala mesin telusur di antara kumpulan kolam renang. Penyeimbangan ulang tersebut membutuhkan pengurasan semua beban kerja dari memulai ulang mesin, dan melakukan sanitasi mesin yang paling berat proses yang membantu memastikan keaslian dan integritas firmware.
Pertimbangan ini berarti implementasi isolasi mesin oleh Google harus menyediakan cara untuk mengoptimalkan pemanfaatan sumber daya fisik sekaligus melindungi beban kerja dasar dan sensitif dari ancaman.
Di Kubernetes, pendekatan ini dikenal sebagai isolasi node. Node Kubernetes dapat dipetakan ke mesin fisik atau virtual. Dalam makalah ini, kita akan membahas berfokus pada mesin fisik. Selain itu, produk Google Cloud seperti Compute Engine menawarkan sewa tunggal untuk menyediakan isolasi mesin fisik.
Batasan penjadwalan workload
Google menyediakan mesin ke dalam tiga jenis kumpulan gabungan: bagian dasar mesin, mesin produksi, dan mesin pengembangan. Google mengoperasikan beberapa kumpulan terpisah yang menghosting workload dasar dan sensitif. Namun, dalam dokumen ini menyajikan masing-masing sebagai satu kumpulan agar lebih praktis.
Untuk menawarkan perlindungan yang paling efektif, kami men-deploy penjadwalan berikut batasan-batasan untuk WSR:
- Workload dasar hanya dapat berjalan pada mesin dasar.
- Workload sensitif hanya dapat berjalan di mesin produksi.
- Workload yang tidak di-hardening hanya dapat berjalan di mesin pengembangan.
- Workload yang telah melalui proses hardening dapat berjalan di mesin produksi atau pengembangan, dengan preferensi untuk mesin produksi.
Diagram berikut menunjukkan batasan penjadwalan.
Dalam diagram ini, batas isolasi memisahkan berbagai kelas workload baik di antara maupun di dalam kumpulan mesin. Beban kerja dasar adalah satu-satunya tenant mesin dasar yang berdedikasi. Otorisasi biner atau sandbox workload yang berjalan di mesin produksi membantu mencegah hak istimewa lokal serangan eskalasi. Pada mesin pengembangan, ada risiko sisa bahwa yang tidak dihardening dapat membahayakan beban kerja lain, tetapi komprominya terbatas pada mesin pengembangan karena workload yang telah melalui proses hardening tidak dapat membuat pekerjaan.
Workload yang telah melalui proses hardening 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 diperkuat mengisi kesenjangan yang disebabkan oleh mengisolasi pekerjaan yang sensitif dan tidak dihardening. Selain itu, semakin besar jejak resource yang telah melalui proses hardening, semakin banyak fluktuasi dalam penggunaan resource dua kelas lainnya dapat diakomodasi tanpa perlu mesin yang mahal bergerak di antara cincin.
Diagram berikut menunjukkan batasan penjadwalan yang diberlakukan pada berbagai kelas workload. Beban kerja yang diperkeras dapat ditempatkan di atau mesin pengembangan.
Dengan mengisolasi workload dasar pada beberapa kumpulan dasar, Google mengorbankan efisiensi sumber daya untuk keamanan yang lebih tinggi. Untungnya, fondasi workload cenderung memiliki jejak resource yang relatif kecil, dan kumpulan mesin khusus memiliki dampak yang sangat kecil terhadap penggunaan 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 beban kerja non-dasar tidak pernah diizinkan untuk berjalan di komputer dasar. Mesin dasar dilindungi terhadap pergerakan lateral, karena hanya beban kerja dasar yang dapat berjalan pada mesin Linux dan Windows.
Ringkasan kontrol
Google menggunakan sejumlah kontrol di seluruh infrastrukturnya untuk membantu melindungi layanan produksi, mesin produksi, dan workload. Kontrol tersebut meliputi hal berikut:
- Kontrol akses administratif dan BAB untuk layanan produksi
- Kontrol akses shell, kontrol akses fisik, serta firmware dan sistem kontrol software untuk mesin produksi
- WSR untuk berbagai kelas workload
Bersama-sama, kontrol tersebut menerapkan batasan yang membantu melindungi pengguna Google dan pelanggan—serta data mereka. Diagram berikut menggambarkan bagaimana yang berbeda untuk mendukung postur keamanan Google.
Langkah selanjutnya
- Untuk informasi selengkapnya tentang kontrol keamanan pada 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 diingat dan Kevin Plybon