BeyondProd

Konten ini terakhir diperbarui pada Mei 2024, dan menampilkan kondisi saat ini pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.

Dokumen ini menjelaskan cara Google menerapkan keamanan dalam infrastruktur kami menggunakan arsitektur berbasis cloud yang disebut BeyondProd. BeyondProd mengacu pada layanan dan kontrol dalam infrastruktur kami yang bekerja sama untuk membantu melindungi workload. Workload adalah tugas unik yang diselesaikan aplikasi. BeyondProd membantu melindungi layanan mikro yang dijalankan di lingkungan kita, termasuk cara mengubah kode dan mengakses data pengguna.

Dokumen ini adalah bagian dari serangkaian makalah teknis yang menjelaskan teknologi tersebut, seperti Chrome Enterprise Premium, yang telah kami kembangkan untuk membantu melindungi platform Google dari ancaman canggih. Chrome Enterprise Premium menerapkan arsitektur zero-trust yang dirancang untuk memberikan akses aman ke platform Google dan layanan yang berjalan di dalamnya. Seperti Chrome Enterprise Premium, BeyondProd tidak mengandalkan perlindungan perimeter jaringan tradisional seperti firewall. Sebagai gantinya, BeyondProd membantu menciptakan kepercayaan antara microservice menggunakan karakteristik seperti asal kode, identitas layanan, dan hardware tepercaya. Kepercayaan ini meluas ke software yang berjalan di Google Cloud serta software yang di-deploy dan diakses oleh pelanggan Google Cloud.

Dokumen ini menjelaskan manfaat BeyondProd, layanan dan prosesnya, serta cara kami bermigrasi ke arsitektur ini. Untuk ringkasan keamanan infrastruktur kami, lihat ringkasan desain keamanan infrastruktur Google.

Pengantar

Arsitektur keamanan modern telah beralih dari model keamanan berbasis perimeter tradisional seperti firewall yang melindungi perimeter yang setiap pengguna atau layanan di dalam perimeter dianggap tepercaya.

Di era ini, pengguna memiliki mobilitas tinggi dan umumnya beroperasi di luar perimeter keamanan tradisional organisasi seperti dari rumah, kedai kopi, atau pesawat. Dengan Chrome Enterprise Premium, kami memberikan akses ke resource perusahaan menggunakan beberapa faktor, termasuk identitas pengguna, identitas perangkat yang digunakan untuk mengakses resource, kondisi perangkat, sinyal kepercayaan seperti perilaku pengguna, dan daftar kontrol akses.

BeyondProd menangani masalah yang sama untuk layanan produksi seperti yang dilakukan Chrome Enterprise Premium kepada pengguna. Dalam arsitektur berbasis cloud, kita tidak bisa hanya mengandalkan firewall untuk melindungi jaringan produksi. Microservice dipindahkan dan di-deploy di berbagai lingkungan, di seluruh host heterogen, dan beroperasi pada berbagai tingkat kepercayaan dan sensitivitas. Jika Chrome Enterprise Premium menyatakan bahwa kepercayaan pengguna harus bergantung pada karakteristik seperti status perangkat yang kontekstual, bukan kemampuan untuk terhubung ke jaringan perusahaan, BeyondProd menyatakan bahwa kepercayaan layanan harus bergantung pada karakteristik seperti asal kode, hardware tepercaya, dan identitas layanan, bukan lokasi di jaringan produksi, seperti alamat IP atau nama host.

Infrastruktur dalam container

Infrastruktur kami men-deploy workload sebagai microservice individual dalam container. Microservice memisahkan tugas-tugas individual yang perlu dilakukan aplikasi ke dalam layanan yang berbeda. Setiap layanan dapat dikembangkan dan dikelola secara independen dengan API, peluncuran, penskalaan, dan pengelolaan kuota mereka sendiri. Microservice bersifat independen, modular, dinamis, dan sementara. Model ini dapat didistribusikan ke banyak host, cluster, atau bahkan cloud. Dalam arsitektur microservice, workload dapat berupa satu atau beberapa microservice.

Infrastruktur dalam container berarti setiap microservice di-deploy sebagai kumpulan container yang dapat dipindahkan dan dijadwalkan. Untuk mengelola container ini secara internal, kami mengembangkan sistem orkestrasi container disebut Borg, yang menerapkan beberapa miliar container seminggu. Borg adalah sistem pengelolaan container terpadu Google yang menjadi inspirasi bagi Kubernetes.

Container membuat workload lebih mudah dan lebih efisien untuk dijadwalkan di seluruh mesin. Dengan pengemasan microservice dalam container, workload dapat dibagi menjadi unit yang lebih kecil dan lebih mudah dikelola untuk pemeliharaan dan penemuan. Arsitektur ini menskalakan workload sesuai kebutuhan: jika ada permintaan tinggi untuk workload tertentu, mungkin ada beberapa mesin yang menjalankan salinan container yang sama untuk menangani skala workload yang diperlukan.

Di Google, keamanan berperan penting dalam setiap evolusi dalam arsitektur kami. Tujuan kami dengan arsitektur dan proses pengembangan microservice ini adalah untuk mengatasi masalah keamanan sedini mungkin dalam siklus proses pengembangan dan deployment (jika penanganan masalah tidak memerlukan banyak biaya) dan untuk melakukannya dengan cara yang terstandarisasi dan konsisten. Hasil akhirnya adalah developer menghabiskan lebih sedikit waktu untuk keamanan sekaligus tetap mencapai hasil yang lebih aman.

Manfaat BeyondProd

BeyondProd memberikan banyak manfaat otomatisasi dan keamanan untuk infrastruktur Google. Manfaatnya meliputi:

  • Perlindungan edge jaringan: workload diisolasi dari serangan jaringan dan traffic tidak sah dari internet. Meskipun pendekatan perimeter bukanlah konsep baru, pendekatan ini tetap menjadi praktik terbaik keamanan untuk arsitektur cloud. Pendekatan perimeter membantu melindungi sebanyak mungkin infrastruktur dari traffic tidak sah dan potensi serangan dari internet, seperti serangan DoS berbasis volume.
  • Tidak ada rasa saling percaya yang melekat di antara layanan: Hanya pemanggil atau layanan yang diautentikasi, tepercaya, dan diizinkan secara khusus yang dapat mengakses layanan lain. Tindakan ini mencegah penyerang menggunakan kode yang tidak tepercaya untuk mengakses layanan. Jika layanan disusupi, manfaat ini membantu mencegah penyerang melakukan tindakan yang memungkinkan mereka memperluas jangkauan. Sikap saling tidak percaya ini, yang digabungkan dengan kontrol akses terperinci, membantu membatasi dampak gangguan dari penyusupan.
  • Mesin tepercaya yang menjalankan kode dengan asal yang diketahui: Identitas layanan dibatasi agar hanya menggunakan kode dan konfigurasi yang diizinkan, serta hanya berjalan di lingkungan yang sah dan terverifikasi.
  • Penegakan kebijakan yang konsisten di seluruh layanan: Penerapan kebijakan yang konsisten membantu memastikan bahwa keputusan akses dapat diandalkan di seluruh layanan. Misalnya, Anda dapat membuat penerapan kebijakan yang memverifikasi permintaan akses ke data pengguna. Untuk mengakses layanan, pengguna akhir yang sah harus memberikan permintaan yang divalidasi, dan administrator harus memberikan justifikasi bisnis.
  • Peluncuran perubahan yang sederhana, otomatis, dan terstandardisasi: Perubahan infrastruktur dapat dengan mudah ditinjau dampaknya terhadap keamanan, dan patch keamanan dapat diluncurkan tanpa berdampak pada produksi.
  • Isolasi antara workload yang menggunakan sistem operasi yang sama: Jika layanan disusupi, hal tersebut tidak dapat memengaruhi keamanan workload lain yang berjalan pada host yang sama. Isolasi ini membantu membatasi dampak gangguan dari penyusupan.
  • Hardware dan pengesahan hardware tepercaya: Root of trust hardware membantu memastikan bahwa hanya kode yang diketahui dan diotorisasi (dari firmware ke mode pengguna) yang berjalan di host sebelum workload apa pun dijadwalkan untuk dijalankan di atasnya.

Manfaat ini berarti bahwa container dan microservice yang berjalan di dalam arsitektur cloud kami dapat di-deploy, saling berkomunikasi, dan berjalan berdampingan tanpa melemahkan keamanan infrastruktur kami. Selain itu, setiap developer microservice tidak dibebani dengan detail keamanan dan implementasi infrastruktur yang mendasarinya.

Layanan keamanan BeyondProd

Kami merancang dan mengembangkan beberapa layanan keamanan BeyondProd untuk menciptakan manfaat yang dibahas dalam manfaat BeyondProd. Bagian berikut menjelaskan layanan keamanan ini.

Google Front End untuk perlindungan edge jaringan

Google Front End (GFE) memberikan perlindungan edge jaringan. GFE menghentikan koneksi dari pengguna akhir dan menyediakan titik pusat untuk menerapkan praktik terbaik TLS.

Meskipun penekanan kami tidak lagi pada keamanan berbasis perimeter, GFE masih menjadi bagian penting dari strategi kami untuk melindungi layanan internal dari serangan DoS. GFE adalah titik masuk pertama bagi pengguna yang terhubung ke infrastruktur Google. Setelah pengguna terhubung ke infrastruktur kami, GFE juga bertanggung jawab atas load balancing dan pengubahan rute traffic antar-region sesuai kebutuhan. GFE adalah proxy edge yang merutekan traffic ke microservice yang tepat.

VM Pelanggan di Google Cloud tidak terdaftar di GFE. Sebagai gantinya, mereka mendaftar ke Cloud Front End, yang merupakan konfigurasi khusus GFE yang menggunakan stack jaringan Compute Engine. Dengan Cloud Front End, VM pelanggan dapat mengakses layanan Google secara langsung menggunakan alamat IP publik atau pribadi mereka. (Alamat IP pribadi hanya tersedia jika Akses Google Pribadi diaktifkan.)

Application Layer Transport Security untuk kepercayaan antar-layanan

Application Layer Transport Security (ALTS) membantu memastikan bahwa layanan tidak saling percaya satu sama lain. ALTS digunakan untuk autentikasi remote procedure call (RPC), integritas, enkripsi traffic, dan identitas layanan. ALTS adalah sistem enkripsi transpor dan autentikasi timbal balik untuk layanan di infrastruktur Google. Secara umum, identitas terikat dengan layanan, bukan ke nama server atau host tertentu. Binding ini membantu kelancaran replikasi, load balancing, dan penjadwalan ulang microservice di seluruh host.

Setiap mesin memiliki kredensial ALTS yang disediakan menggunakan sistem integritas host, dan hanya dapat didekripsi jika sistem integritas host telah memverifikasi bahwa booting aman telah berhasil. Sebagian besar layanan Google berjalan sebagai microservice di atas Borg, dan setiap microservice ini memiliki identitas ALTS sendiri. Borg Prime, Pengontrol terpusat Borg, memberikan kredensial microservice ALTS ini ke workload berdasarkan identitas microservice. Kredensial ALTS level mesin membentuk saluran aman untuk penyediaan kredensial microservice, sehingga hanya mesin yang telah berhasil meneruskan booting yang diverifikasi integritas host yang dapat menghosting workload microservice. Untuk informasi selengkapnya tentang kredensial ALTS, lihat Sertifikat workload.

Otorisasi Biner untuk Borg untuk asal kode

Otorisasi Biner untuk Borg (BAB) memberikan verifikasi asal kode. BAB adalah pemeriksaan penerapan waktu deployment yang membantu memastikan bahwa kode memenuhi persyaratan keamanan internal sebelum kode di-deploy. Misalnya, pemeriksaan penegakan BAB termasuk memastikan bahwa perubahan ditinjau oleh engineer kedua sebelum kode dikirim ke repositori kode sumber kami, dan biner dibangun secara terverifikasi di infrastruktur khusus. Di infrastruktur kami, BAB membatasi deployment microservice yang tidak sah.

Integritas host untuk kepercayaan mesin

Integritas host memverifikasi integritas software sistem host melalui proses booting yang aman dan didukung oleh chip keamanan root of trust hardware (disebut Titan) jika didukung. Pemeriksaan integritas host mencakup verifikasi tanda tangan digital di BIOS, pengontrol pengelolaan baseboard (BMC), bootloader, dan kernel OS. Jika didukung, pemeriksaan integritas host dapat mencakup kode mode pengguna dan firmware periferal (seperti NIC). Selain verifikasi tanda tangan digital, integritas host membantu memastikan bahwa setiap host menjalankan versi yang diinginkan dari komponen software ini.

Pengelolaan akses layanan dan tiket konteks pengguna akhir untuk penegakan kebijakan

Pengelolaan akses layanan dan tiket konteks pengguna akhir membantu memberikan penegakan kebijakan yang konsisten di seluruh layanan.

Pengelolaan akses layanan membatasi cara data diakses di antara layanan. Saat RPC dikirim dari satu layanan ke layanan lainnya, pengelolaan akses layanan menentukan kebijakan otorisasi dan audit yang diperlukan layanan untuk mengakses data layanan penerima. Hal ini membatasi cara data diakses, memberikan tingkat akses minimum yang diperlukan, dan menentukan bagaimana akses tersebut dapat diaudit. Di infrastruktur Google, pengelolaan akses layanan membatasi akses satu microservice ke data microservice lainnya, dan memungkinkan analisis global atas kontrol akses.

Tiket konteks pengguna akhir dikeluarkan oleh layanan autentikasi pengguna akhir, dan menyediakan layanan dengan identitas pengguna yang terpisah dari identitas layanan mereka. Tiket ini adalah kredensial yang dilindungi integritas, diterbitkan secara terpusat, dan dapat diteruskan yang membuktikan identitas pengguna akhir yang membuat permintaan layanan. Tiket ini mengurangi kebutuhan akan kepercayaan antarlayanan, karena identitas pembanding yang menggunakan ALTS mungkin tidak cukup untuk memberikan akses, saat keputusan akses tersebut biasanya juga didasarkan pada identitas pengguna akhir.

Alat Borg untuk peluncuran otomatis perubahan dan skalabilitas

Alat Borg untuk blue-green deployment menyediakan peluncuran perubahan yang sederhana, otomatis, dan terstandardisasi. Blue-green deployment adalah cara untuk meluncurkan perubahan pada workload tanpa memengaruhi traffic masuk, sehingga pengguna akhir tidak mengalami periode nonaktif saat mengakses aplikasi.

Tugas Borg adalah satu instance microservice, yang menjalankan beberapa bagian dari aplikasi. Tugas diskalakan untuk menangani beban, dengan tugas baru yang di-deploy saat beban meningkat, dan tugas yang ada dihentikan saat beban berkurang.

Alat Borg bertanggung jawab untuk memigrasikan workload yang berjalan saat kami melakukan tugas pemeliharaan. Saat tugas Borg baru di-deploy, load balancer secara bertahap memindahkan traffic dari tugas yang ada ke tugas baru. Hal ini memungkinkan microservice diupdate tanpa periode nonaktif dan tanpa sepengetahuan pengguna.

Kami juga menggunakan alat ini untuk menerapkan upgrade layanan saat menambahkan fitur baru, dan untuk menerapkan update keamanan penting tanpa periode nonaktif. Untuk perubahan yang memengaruhi infrastruktur, kami menggunakan migrasi langsung VM pelanggan untuk membantu memastikan workload tidak terpengaruh.

Untuk informasi selengkapnya, lihat Otorisasi Biner untuk Borg.

Kernel gVisor untuk isolasi workload

Kernel gVisor memungkinkan isolasi antara workload yang menggunakan sistem operasi yang sama. gVisor menggunakan kernel ruang pengguna untuk mencegat dan menangani syscall, sehingga mengurangi interaksi dengan host dan potensi permukaan serangan. Kernel ini menyediakan sebagian besar fungsi yang diperlukan untuk menjalankan aplikasi, dan membatasi platform kernel host yang dapat diakses oleh aplikasi. gVisor adalah salah satu dari beberapa alat yang kami gunakan untuk mengisolasi workload internal dan workload pelanggan Google Cloud yang berjalan di host yang sama. Untuk mengetahui informasi selengkapnya tentang alat sandbox lainnya, lihat Sandbox Kode.

Melindungi data pengguna dengan BeyondProd

Bagian ini menjelaskan cara layanan BeyondProd bekerja sama untuk membantu melindungi data pengguna di infrastruktur kami. Bagian di bawah ini menjelaskan dua contoh:

  • Mengakses permintaan data pengguna mulai dari pembuatan hingga pengiriman di tujuannya.
  • Perubahan kode dari pengembangan ke produksi.

Tidak semua teknologi yang tercantum digunakan di semua bagian infrastruktur kami; hal itu tergantung pada layanan dan workload.

Mengakses data pengguna

Diagram di bawah menunjukkan proses yang digunakan infrastruktur kami untuk memverifikasi bahwa pengguna diizinkan untuk mengakses data pengguna.

Kontrol keamanan berbasis cloud Google yang mengakses data pengguna.

Langkah-langkah untuk mengakses akun pengguna adalah sebagai berikut:

  1. Pengguna mengirim permintaan ke GFE.
  2. GFE menghentikan koneksi TLS dan meneruskan permintaan ke frontend layanan yang sesuai menggunakan ALTS.
  3. Frontend aplikasi mengautentikasi permintaan pengguna menggunakan layanan autentikasi pengguna akhir (EUA) terpusat dan, jika berhasil, menerima tiket konteks pengguna akhir kriptografis yang umurnya singkat.
  4. Frontend aplikasi membuat RPC melalui ALTS ke layanan backend penyimpanan, yang meneruskan tiket dalam permintaan backend.
  5. Layanan backend menggunakan pengelolaan akses layanan untuk memastikan kriteria berikut benar:
    • Frontend diautentikasi menggunakan sertifikat yang valid dan tidak dicabut. Pemeriksaan ini menunjukkan bahwa pengujian dijalankan pada host tepercaya dan pemeriksaan BAB telah berhasil.
    • Identitas ALTS layanan frontend diberi otorisasi untuk membuat permintaan ke layanan backend dan menunjukkan tiket EUC.
    • Tiket konteks pengguna akhir valid.
    • Pengguna dalam tiket EUC diberi otorisasi untuk mengakses data yang diminta.

Jika salah satu pemeriksaan ini gagal, permintaan akan ditolak.

Jika lulus pemeriksaan ini, data akan ditampilkan ke frontend aplikasi yang diotorisasi, dan ditayangkan kepada pengguna yang diberi otorisasi.

Dalam banyak kasus, ada rangkaian panggilan backend dan setiap layanan perantara melakukan pemeriksaan akses layanan pada RPC masuk, dan tiket diteruskan di RPC keluar.

Untuk mengetahui informasi lebih lanjut tentang cara traffic dirutekan di dalam infrastruktur kami, lihat Cara traffic dirutekan.

Membuat perubahan kode

Diagram di bawah menunjukkan cara penerapan perubahan kode.

Cara mengubah kode.

Langkah-langkah untuk membuat perubahan kode adalah sebagai berikut:

  1. Developer membuat perubahan pada microservice yang dilindungi oleh BAB. Perubahan dikirimkan ke repositori kode pusat kami, yang memberlakukan peninjauan kode. Setelah disetujui, perubahan akan dikirim ke sistem build pusat yang tepercaya yang menghasilkan paket dengan sertifikat manifes build yang dapat diverifikasi dan ditandatangani.

  2. Pada waktu deployment, BAB memverifikasi bahwa proses ini diikuti dengan memvalidasi sertifikat yang ditandatangani dari pipeline build.

  3. Borg menangani semua update workload menggunakan model keandalan yang memastikan sedikit gangguan pada layanan, baik itu peluncuran rutin maupun patch keamanan darurat.

  4. GFE memindahkan traffic ke deployment baru menggunakan load balancing untuk membantu memastikan keberlangsungan operasi.

Untuk informasi selengkapnya tentang proses ini, lihat Proses pengembangan dan produksi kami.

Semua workload memerlukan isolasi. Jika workload kurang tepercaya karena kode sumber berasal dari luar Google, workload tersebut mungkin di-deploy ke lingkungan yang dilindungi gVisor, atau menggunakan lapisan isolasi lainnya. Isolasi ini membantu menahan musuh yang berhasil menyusupi aplikasi.

Implikasi keamanan berbasis cloud

Bagian berikut memberikan perbandingan antara aspek keamanan infrastruktur tradisional dengan aspek tandingannya dalam arsitektur berbasis cloud.

Arsitektur aplikasi

Model keamanan yang lebih tradisional, yang berfokus pada keamanan berbasis perimeter, tidak dapat melindungi arsitektur berbasis cloud dengan sendirinya. Secara tradisional, aplikasi monolitik menggunakan arsitektur tiga tingkat dan di-deploy ke pusat data perusahaan pribadi yang memiliki kapasitas yang cukup untuk menangani beban puncak untuk peristiwa penting. Aplikasi dengan persyaratan hardware atau jaringan tertentu sengaja di-deploy ke komputer tertentu yang biasanya mempertahankan alamat IP tetap. Peluncuran bersifat jarang, besar, dan sulit dikoordinasikan karena perubahan yang dihasilkan secara bersamaan memengaruhi banyak bagian aplikasi. Hal ini menghasilkan aplikasi yang berumur sangat panjang, yang lebih jarang diupdate, dan patch keamanan biasanya lebih jarang diterapkan.

Namun, dalam model berbasis cloud, aplikasi harus portabel di antara lingkungan yang berbeda, karena dapat berjalan di cloud publik, pusat data pribadi, atau layanan yang dihosting pihak ketiga. Oleh karena itu, sebagai pengganti aplikasi monolitik, aplikasi dalam container yang dibagi menjadi beberapa microservice menjadi ideal untuk lingkungan cloud. Container memisahkan biner yang diperlukan aplikasi Anda dari sistem operasi host yang mendasarinya, dan menjadikan aplikasi lebih portabel. Container tidak dapat diubah, artinya container tidak berubah setelah di-deploy. Sebaliknya, container ini dibuat ulang dan sering di-deploy ulang.

Dengan container yang dimulai ulang, dihentikan, atau sering dijadwalkan ulang, penggunaan ulang dan berbagi hardware serta jaringan menjadi lebih sering. Dengan proses build dan distribusi standar yang umum, proses pengembangan akan lebih konsisten dan seragam antar-tim, meskipun tim mengelola pengembangan microservice mereka secara mandiri. Oleh karena itu, pertimbangan keamanan (seperti peninjauan keamanan, pemindaian kode, dan pengelolaan kerentanan), dapat diatasi lebih awal dalam siklus pengembangan.

Mesh layanan

Dengan membangun infrastruktur bersama yang didesain secara aman yang digunakan oleh semua developer, beban developer untuk mengetahui dan menerapkan persyaratan keamanan umum dapat diminimalkan. Fungsi keamanan harus memerlukan sedikit integrasi atau tidak sama sekali ke dalam setiap aplikasi, dan sebagai gantinya disediakan sebagai fabric yang membungkus dan menghubungkan semua microservice. Ini biasanya disebut mesh layanan. Ini juga berarti bahwa keamanan dapat dikelola dan diimplementasikan secara terpisah dari aktivitas pengembangan atau deployment reguler.

Mesh layanan adalah fabric bersama di lapisan infrastruktur yang membungkus dan menghubungkan semua microservice. Mesh layanan memungkinkan komunikasi layanan-ke-layanan, yang dapat mengontrol traffic, menerapkan kebijakan, dan menyediakan pemantauan terpusat untuk panggilan layanan.

Keamanan zero-trust

Dalam model keamanan tradisional yang menggunakan pusat data pribadi, aplikasi organisasi bergantung pada firewall untuk membantu melindungi workload dari ancaman berbasis jaringan eksternal.

Dengan model keamanan zero-trust, keputusan otorisasi tidak bergantung pada firewall. Sebagai gantinya, kontrol lain, seperti workload identity, autentikasi, dan otorisasi, membantu melindungi microservice dengan memastikan koneksi internal atau eksternal divalidasi sebelum dapat bertransaksi. Jika Anda menghapus ketergantungan pada firewall atau kontrol berbasis jaringan, Anda dapat menerapkan segmentasi tingkat microservice, tanpa kepercayaan yang melekat di antara layanan. Dengan segmentasi tingkat microservice, traffic dapat memiliki berbagai tingkat kepercayaan dengan kontrol yang berbeda-beda, dan Anda tidak lagi hanya membandingkan traffic internal dengan eksternal.

Persyaratan keamanan bersama yang diintegrasikan ke dalam stack layanan

Dalam model keamanan tradisional, setiap aplikasi bertanggung jawab untuk memenuhi persyaratan keamanannya sendiri secara terpisah dari layanan lainnya. Persyaratan tersebut mencakup pengelolaan identitas, TLS termination, dan pengelolaan akses data. Hal ini dapat menyebabkan implementasi yang tidak konsisten atau masalah keamanan yang belum terselesaikan karena masalah ini harus diperbaiki di banyak tempat, yang membuat perbaikan lebih sulit untuk diterapkan.

Dalam arsitektur berbasis cloud, komponen jauh lebih sering digunakan kembali di antara layanan. Choke point memungkinkan kebijakan diterapkan secara konsisten di seluruh layanan. Kebijakan yang berbeda dapat diterapkan menggunakan layanan keamanan yang berbeda. Daripada mengharuskan setiap aplikasi untuk mengimplementasikan layanan keamanan penting secara terpisah, Anda dapat membagi berbagai kebijakan ke dalam microservice yang terpisah. Misalnya, Anda dapat membuat satu kebijakan untuk memastikan akses terotorisasi ke data pengguna, dan membuat kebijakan lain untuk memastikan penggunaan cipher suite TLS terbaru.

Proses standar dengan peluncuran yang lebih sering

Dalam model keamanan tradisional, ada layanan bersama yang terbatas, dan kode sering kali digandakan serta digabungkan dengan pengembangan lokal. Berbagi dengan terbatas mempersulit penentuan dampak perubahan dan bagaimana perubahan tersebut dapat memengaruhi banyak bagian aplikasi. Akibatnya, peluncuran menjadi jarang dan sulit dikoordinasikan. Untuk melakukan perubahan, developer mungkin harus mengupdate setiap komponen secara langsung (misalnya, membuka koneksi SSH ke setiap mesin virtual untuk memperbarui konfigurasi). Secara keseluruhan, hal ini dapat menyebabkan aplikasi berumur sangat panjang.

Dari perspektif keamanan, karena kode sering diduplikasi, akan lebih sulit untuk ditinjau, dan bahkan lebih sulit untuk memastikan bahwa saat kerentanan diperbaiki, kerentanan akan diperbaiki di mana saja.

Dalam arsitektur berbasis cloud, peluncuran sering dilakukan dan terstandardisasi. Proses ini memungkinkan keamanan untuk menguji kemampuan awal dalam siklus pengembangan software. Pengujian kemampuan awal mengacu pada langkah-langkah awal dalam siklus proses pengembangan software, yang dapat mencakup langkah-langkah seperti membuat kode, membuat, menguji, memvalidasi, dan men-deploy. Pengujian kemampuan awal memungkinkan penerapan keamanan yang lebih sederhana dan konsisten, termasuk penerapan patch keamanan secara reguler.

Melakukan perubahan ke BeyondProd

Transisi Google ke BeyondProd memerlukan perubahan di dua area utama: dalam infrastruktur dan dalam proses pengembangan kami. Kami menangani perubahan ini secara bersamaan, tetapi Anda dapat mengatasinya secara terpisah jika ingin menyiapkan sesuatu yang serupa di lingkungan Anda.

Mengubah infrastruktur kami

Tujuan kami adalah mengotomatiskan keamanan di seluruh infrastruktur karena kami percaya keamanan harus menurunkan skala dengan cara yang sama seperti skala layanan. Layanan harus aman secara default dan tidak aman hanya setelah keputusan eksplisit dibuat untuk menerima risiko. Intervensi langsung manusia ke infrastruktur kami harus dilakukan dengan pengecualian, bukan rutin, dan intervensi tersebut harus dapat diaudit jika terjadi. Kemudian, kita dapat mengautentikasi layanan berdasarkan kode dan konfigurasi yang di-deploy untuk layanan tersebut, bukan berdasarkan orang yang men-deploy layanan.

Kami memulainya dengan membangun fondasi kuat untuk identitas, autentikasi, dan otorisasi layanan. Microservice menggunakan identitas layanan untuk mengautentikasi dirinya sendiri ke layanan lain yang berjalan dalam infrastruktur. Memiliki fondasi identitas layanan tepercaya memungkinkan kami mengimplementasikan kemampuan keamanan tingkat lebih tinggi yang bergantung pada validasi identitas layanan ini, seperti pengelolaan akses layanan dan tiket konteks pengguna akhir. Untuk mempermudah transisi ini bagi layanan baru dan yang sudah ada, ALTS pertama kali disediakan sebagai library dengan daemon helper tunggal. Daemon ini berjalan pada host yang dipanggil oleh setiap layanan, dan berkembang dari waktu ke waktu menjadi library yang menggunakan kredensial layanan. Library ALTS terintegrasi dengan lancar ke library RPC inti. Integrasi ini mempermudah untuk mendapatkan adopsi yang luas, tanpa beban yang signifikan pada tim pengembangan individu. Peluncuran ALTS adalah prasyarat untuk meluncurkan pengelolaan akses layanan dan tiket konteks pengguna akhir.

Mengubah proses pengembangan kami

Sangat penting bagi Google untuk membangun proses build dan peninjauan kode yang andal untuk memastikan integritas layanan yang sedang berjalan. Kami menciptakan proses build pusat tempat kami dapat mulai menerapkan persyaratan seperti peninjauan kode dua orang dan pengujian otomatis pada waktu build dan deployment. (Lihat Otorisasi Biner untuk Borg untuk mengetahui detail selengkapnya tentang deployment.)

Setelah mempelajari dasar-dasarnya, kami mulai mengatasi kebutuhan untuk menjalankan kode eksternal yang tidak tepercaya di lingkungan kami. Untuk mencapai sasaran ini, kami memulai melakukan sandbox, pertama dengan ptrace, lalu menggunakan gVisor. Demikian pula, blue-green deployment memberikan manfaat yang signifikan dalam hal keamanan (misalnya, patching) dan keandalan.

Kami dengan cepat menemukan bahwa lebih mudah jika layanan dimulai dengan mencatat pelanggaran kebijakan daripada memblokir pelanggaran. Pendekatan ini memiliki dua manfaat:

  • Hal ini memberi kesempatan kepada pemilik layanan untuk menguji perubahan dan mengukur dampaknya (jika ada) terhadap perpindahan ke lingkungan berbasis cloud terhadap layanan mereka.
  • Hal ini memungkinkan kami memperbaiki bug dan mengidentifikasi fungsi tambahan yang mungkin perlu kami berikan kepada tim layanan.

Misalnya, saat layanan diaktivasi ke BAB, pemilik layanan akan mengaktifkan mode hanya audit. Hal ini membantu mereka mengidentifikasi kode atau alur kerja yang tidak memenuhi persyaratan. Setelah mengatasi masalah yang ditandai oleh mode khusus audit, pemilik layanan beralih ke mode penerapan. Di gVisor, kami melakukannya dengan terlebih dahulu melakukan sandbox workload, bahkan dengan kesenjangan kompatibilitas dalam kemampuan sandbox, lalu mengatasi kesenjangan ini secara sistematis untuk meningkatkan sandbox.

Langkah berikutnya