Otorisasi Biner untuk Borg

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 kami menggunakan peninjauan kode, infrastruktur keamanan, dan pemeriksaan penegakan yang disebut Otorisasi Biner untuk Borg (BAB) untuk membantu melindungi supply chain software Google dari risiko pihak internal. BAB membantu mengurangi risiko pihak internal karena memastikan bahwa software produksi ditinjau dan disetujui sebelum di-deploy, terutama saat kode kita dapat mengakses data sensitif. BAB berlaku untuk semua layanan yang berjalan di Borg. Sejak publikasi asli dokumen ini, kami telah menyertakan konsep utama BAB ke dalam spesifikasi terbuka yang disebut Supply-chain Levels for Software Artifacts (SLSA).

Dokumen ini adalah bagian dari serangkaian makalah teknis yang menjelaskan beberapa project yang telah dikembangkan oleh tim keamanan Google untuk membantu meningkatkan keamanan, termasuk BeyondCorp dan BeyondProd. Untuk ringkasan keamanan infrastruktur kami, lihat Ringkasan desain keamanan infrastruktur Google.

Pengantar

Risiko pihak internal mewakili ancaman terhadap keamanan data pengguna, yang dapat mencakup data pekerjaan, data keuangan, atau data eksklusif atau bisnis lainnya. Risiko pihak internal adalah potensi bagi karyawan untuk menggunakan pengetahuan atau akses organisasinya untuk melakukan tindakan berbahaya, atau agar penyerang eksternal menggunakan kredensial karyawan yang telah disusupi untuk melakukan hal yang sama.

Untuk meminimalkan risiko pihak internal dalam supply chain software, kami menggunakan BAB. BAB adalah pemeriksaan penegakan internal yang terjadi saat software di-deploy. BAB memastikan penerapan kode dan konfigurasi memenuhi standar minimum tertentu dan mendukung keseragaman dalam sistem produksi kami.

Kami membantu melindungi data pengguna dalam sistem produksi kami dengan membatasi akses unilateral oleh karyawan kami. BAB membantu memastikan bahwa karyawan, saat bertindak sendiri, tidak dapat secara langsung maupun tidak langsung mengakses atau memengaruhi data pengguna tanpa otorisasi dan justifikasi yang tepat. BAB dan kontrol terkaitnya membantu kami menerapkan hak istimewa terendah, yang meningkatkan postur keamanan kami secara terpisah dari pelaku ancaman tertentu. Dengan kata lain, BAB membatasi akses sepihak terlepas dari apakah pelaku memiliki niat berbahaya, akun mereka telah disusupi, atau mereka tidak sengaja diberi akses.

Manfaat BAB

Mengadopsi BAB dan model deployment dalam container memberikan banyak manfaat keamanan bagi infrastruktur Google. Manfaatnya meliputi:

  • BAB membantu mengurangi risiko pihak internal secara keseluruhan: BAB mewajibkan kode untuk memenuhi standar dan praktik manajemen perubahan tertentu sebelum kode dapat mengakses data pengguna. Persyaratan ini mengurangi potensi karyawan yang bertindak sendiri (atau akun karyawan yang disusupi) mengakses data pengguna secara terprogram.
  • BAB mendukung keseragaman sistem produksi: Dengan menggunakan sistem dalam container dan memverifikasi persyaratan BAB-nya sebelum deployment, sistem kami menjadi lebih mudah untuk di-debug, lebih andal, dan telah didefinisikan dengan baik proses manajemen perubahan. Persyaratan BAB menyediakan bahasa umum untuk persyaratan sistem produksi.
  • BAB menentukan bahasa umum untuk perlindungan data: BAB melacak kesesuaian di seluruh sistem Google. Data tentang kesesuaian ini dipublikasikan secara internal dan tersedia untuk tim lain. Dengan memublikasikan data BAB tim dapat menggunakan istilah umum saat saling berkomunikasi tentang perlindungan akses data mereka. Bahasa yang sama ini mengurangi pekerjaan bolak-balik yang diperlukan saat bekerja dengan data lintas tim.
  • BAB memungkinkan pelacakan terprogram untuk persyaratan kepatuhan: BAB menyederhanakan tugas kepatuhan manual yang sebelumnya. Proses tertentu di Google memerlukan kontrol yang lebih ketat terkait cara kita menangani data. Misalnya, sistem pelaporan keuangan kami harus mematuhi Sarbanes-Oxley Act (SOX). Sebelum BAB, kami memiliki sistem yang membantu kami melakukan verifikasi secara manual untuk memastikan kepatuhan kami. Dengan diperkenalkannya BAB, banyak dari pemeriksaan ini diotomatiskan berdasarkan kebijakan BAB untuk layanan. Mengotomatiskan pemeriksaan ini memungkinkan tim kepatuhan untuk meningkatkan kedua cakupan layanan yang dicakup dan penerapan kontrol yang sesuai pada layanan ini.

BAB adalah bagian dari framework BeyondProd yang lebih besar yang kami gunakan untuk mengurangi risiko pihak internal.

Proses pengembangan dan produksi kami

Secara default, proses pengembangan dan produksi Google mencakup empat langkah wajib: peninjauan kode, build yang dapat diverifikasi, deployment dalam container, dan identitas berbasis layanan. Bagian berikut menjelaskan langkah-langkah ini secara lebih detail.

Langkah 1: Peninjauan kode

Sebagian besar kode sumber kami disimpan di repositori monolitik pusat, dan memerlukan peninjauan dan persetujuan dari setidaknya satu engineer selain penulis. Codebase monolitik memungkinkan penerapan satu titik choke untuk peninjauan kode.

Setidaknya, proses peninjauan kode kami mengharuskan pemilik sistem untuk menyetujui modifikasi kode pada sistem tersebut.

Saat mengimpor perubahan dari kode open source atau pihak ketiga, kami memverifikasi bahwa perubahan tersebut sesuai (misalnya, versi terbaru). Namun, sering kali kami tidak menerapkan kontrol peninjauan yang sama untuk setiap perubahan yang dibuat oleh developer eksternal terhadap kode open source atau pihak ketiga yang kami gunakan.

Langkah 2: Build yang dapat diverifikasi

Sistem build kami mirip dengan Bazel, yang mem-build dan mengompilasi kode sumber untuk membuat biner untuk deployment. Sistem build kami berjalan di lingkungan yang terisolasi dan terkunci yang terpisah dari karyawan yang melakukan build. Untuk setiap build, sistem menghasilkan provenance yang dihasilkan oleh build yang dapat diverifikasi . Provenance ini adalah sertifikat bertanda tangan yang menjelaskan sumber dan dependensi yang masuk ke build, hash kriptografi biner atau artefak build lainnya, dan parameter build yang lengkap. Provenance ini memungkinkan hal berikut:

  • Kemampuan untuk melacak biner ke kode sumber yang digunakan dalam pembuatannya. Dengan ekstensi, provenance juga dapat melacak proses seputar pembuatan dan pengiriman kode sumber yang dideskripsikannya.
  • Kemampuan untuk memverifikasi bahwa biner tidak dimodifikasi karena perubahan apa pun pada file akan otomatis membatalkan tanda tangannya.

Karena tindakan build dapat berupa kode arbitrer, sistem build kami telah diperkuat untuk multi-tenancy. Dengan kata lain, sistem build kami dirancang untuk mencegah satu build memengaruhi build lainnya. Sistem mencegah build melakukan perubahan yang dapat membahayakan integritas provenance build atau sistem itu sendiri. Setelah build selesai, perubahan akan di-deploy menggunakan Borg.

Langkah 3: Deployment dalam container

Setelah sistem build membuat biner, biner tersebut dikemas ke dalam image container dan di-deploy sebagai tugas Borg pada sistem orkestrasi cluster kami, Borg. Kami menjalankan ratusan ribu tugas dari berbagai aplikasi, di berbagai cluster, masing-masing hingga puluhan ribu mesin. Terlepas dari skala ini, lingkungan produksi kami cukup homogen. Hasilnya, poin kontak untuk akses ke data pengguna dapat lebih mudah dikontrol dan diaudit.

Container memberikan manfaat keamanan yang signifikan. Container dimaksudkan agar tidak dapat diubah, dengan deployment ulang yang sering dari rebuild image secara menyeluruh. Containerization memungkinkan kita untuk meninjau perubahan kode sesuai konteks, dan menyediakan satu choke point untuk perubahan yang di-deploy ke infrastruktur kami.

Konfigurasi tugas Borg menentukan persyaratan untuk tugas yang akan di-deploy: image penampung, parameter runtime, argumen, dan tanda. Borg menjadwalkan tugas, dengan mempertimbangkan batasan tugas, prioritas, kuota, dan persyaratan lain yang tercantum dalam konfigurasi. Setelah pekerjaan di-deploy, tugas Borg dapat berinteraksi dengan pekerjaan lain dalam produksi.

Langkah 4: Identitas berbasis layanan

Tugas Borg berjalan sebagai identitas layanan. Identitas ini digunakan untuk mengakses datastore atau metode remote procedure call (RPC) layanan lainnya. Beberapa tugas dapat dijalankan sebagai identitas yang sama. Hanya karyawan yang bertanggung jawab untuk menjalankan layanan (biasanya Site Reliability Engineers (SRE)) yang dapat men-deploy atau mengubah tugas dengan identitas tertentu.

Saat memulai tugas, Borg akan menyediakan tugas tersebut dengan kredensial kriptografis. Tugas ini menggunakan kredensial ini untuk membuktikan identitasnya saat membuat permintaan layanan lain menggunakan Application Layer Transport Security (ALTS). Agar layanan dapat mengakses data tertentu atau layanan lainnya, identitasnya harus memiliki izin yang diperlukan.

Kebijakan kami mewajibkan perlindungan BAB untuk identitas layanan yang memiliki akses ke data pengguna dan informasi sensitif lainnya. Tugas pengembangan dan uji mutu yang tidak memiliki akses ke data sensitif diizinkan untuk dijalankan dengan kontrol yang lebih sedikit.

Cara kerja BAB

BAB berintegrasi dengan Borg untuk memastikan bahwa hanya tugas resmi yang diizinkan untuk dijalankan dengan identitas setiap layanan. BAB juga membuat jejak audit kode dan konfigurasi yang digunakan dalam tugas dengan BAB aktif untuk memungkinkan pemantauan dan respons insiden.

BAB dirancang untuk memastikan bahwa semua software dan konfigurasi produksi ditinjau, diperiksa, di-build dengan benar, dan diotorisasi, terutama ketika kode tersebut dapat mengakses data pengguna.

Kebijakan khusus layanan

Saat pemilik layanan mengorientasi layanan mereka ke Borg, mereka membuat kebijakan BAB yang menentukan persyaratan keamanan untuk layanan mereka. Kebijakan ini disebut kebijakan khusus layanan. Menentukan atau mengubah kebijakan itu sendiri merupakan perubahan kode yang harus menjalani peninjauan.

Kebijakan khusus layanan menentukan kode dan konfigurasi yang diizinkan untuk berjalan sebagai identitas layanan, serta properti yang diperlukan dari kode dan konfigurasi tersebut. Semua tugas yang berjalan sebagai identitas layanan harus memenuhi kebijakan khusus layanan.

Semua layanan Borg di Google wajib mengonfigurasi kebijakan khusus layanan.

Secara default, praktik ini menerapkan persyaratan berikut:

  • Kode harus dapat diaudit: Kami dapat melacak image container kembali ke sumbernya yang dapat dibaca manusia melalui provenance yang dihasilkan oleh build yang dapat diverifikasi. Kebijakan retensi menyimpan sumber kode yang dapat dibaca manusia setidaknya selama 18 bulan, meskipun kodenya tidak dikirimkan.
  • Kode harus dikirimkan: Kode yang dibuat dari lokasi yang telah ditentukan dan ditetapkan dalam repositori sumber kami. Pengiriman biasanya menyiratkan bahwa kode tersebut telah menjalani peninjauan kode.
  • Konfigurasi harus dikirimkan: Konfigurasi apa pun yang disediakan selama deployment akan melalui proses peninjauan dan pengiriman yang sama seperti kode reguler. Oleh karena itu, nilai, argumen, dan parameter flag command-line tidak dapat diubah tanpa peninjauan.

Layanan yang tidak memiliki akses ke data sensitif — atau, dalam keadaan yang jarang terjadi, layanan yang memiliki pengecualian yang valid dan disetujui — mungkin memiliki kebijakan yang lebih permisif, seperti kebijakan yang hanya memerlukan auditabilitas kode, atau bahkan kebijakan yang menonaktifkan BAB sepenuhnya.

Sistem dan komponen yang menerapkan BAB dikontrol secara ketat menggunakan persyaratan otomatis yang ketat dan kontrol manual tambahan.

Mode penerapan

BAB menggunakan dua mode penerapan untuk memastikan tugas mematuhi kebijakan khusus layanan:

  • Penerapan waktu deploy, memblokir tugas yang tidak mematuhi kebijakan agar tidak di-deploy.
  • Validasi berkelanjutan, memantau dan memberi tahu tugas yang tidak mematuhi kebijakan yang di-deploy.

Selain itu, jika terjadi keadaan darurat, proses tanggap darurat dapat mengabaikan penerapan waktu deploy.

Mode penerapan waktu deploy

Borg Prime adalah pengontrol terpusat Borg yang bertindak sebagai certificate authority untuk ALTS. Saat tugas baru dikirim, Borg Prime akan menghubungi BAB untuk memastikan tugas tersebut memenuhi persyaratan kebijakan khusus layanan sebelum Borg Prime memberikan sertifikat ALTS ke tugas tersebut. Pemeriksaan ini bertindak sebagai pengontrol penerimaan: Borg hanya akan memulai tugas tersebut jika kebijakan khusus layanan terpenuhi. Pemeriksaan ini dilakukan bahkan saat karyawan atau layanan yang membuat permintaan deployment telah diberi otorisasi.

Dalam kasus yang jarang terjadi, layanan dapat menonaktifkan penerapan waktu deploy dengan justifikasi yang memadai.

Mode verifikasi berkelanjutan

Setelah di-deploy, tugas akan terus diverifikasi sepanjang waktu, terlepas dari mode penerapannya pada waktu deployment. Proses BAB berjalan setidaknya sekali sehari untuk memastikan tugas yang dimulai (dan mungkin masih berjalan) sesuai dengan semua update terhadap kebijakannya. Misalnya, mode verifikasi berkelanjutan terus memeriksa tugas yang dijalankan dengan kebijakan yang sudah tidak berlaku atau di-deploy menggunakan prosedur tanggap darurat. Jika ditemukan tugas yang tidak mematuhi kebijakan terbaru, maka BAB akan memberi tahu pemilik layanan sehingga mereka dapat memitigasi risiko.

Prosedur tanggap darurat

Saat terjadi insiden atau pemadaman layanan, prioritas utama kami adalah memulihkan layanan yang terpengaruh secepat mungkin. Dalam situasi darurat, Anda mungkin perlu menjalankan kode yang belum ditinjau atau di-build secara terverifikasi. Dengan demikian, mode penerapan dapat diganti menggunakan flag tanggap darurat. Prosedur tanggap darurat juga bertindak sebagai cadangan jika terjadi kegagalan BAB yang dapat memblokir deployment. Saat developer men-deploy tugas menggunakan prosedur tanggap darurat, mereka harus mengirimkan justifikasi sebagai bagian dari permintaan mereka.

Selama respons darurat, BAB mencatat detail tentang tugas Borg terkait dan mengirim notifikasi ke tim keamanan terpusat Google dan tim yang memiliki identitas layanan. Entri log menyertakan referensi ke snapshot kode yang di-deploy dan justifikasi yang diberikan pengguna. Prosedur tanggap darurat hanya dimaksudkan untuk digunakan sebagai upaya terakhir.

Memperluas BAB ke lingkungan lain

Awalnya, BAB hanya mendukung perlindungan tugas Borg dan mengharuskan software tersebut dikembangkan menggunakan pipeline kontrol sumber, build, dan pengemasan tradisional Google. Sekarang, BAB telah menambahkan dukungan untuk melindungi lingkungan deployment dan pengiriman software lainnya, serta dukungan untuk sistem kontrol sumber, build, dan pengemasan alternatif. Detail implementasi untuk berbagai lingkungan ini berbeda. Namun, manfaat BAB tetap ada.

Ada beberapa kasus yang tidak dapat ditangani dengan baik untuk peninjauan kode manual sebelum deployment, terutama pengembangan iteratif kode machine learning dan analisis data berfrekuensi tinggi. Dalam kasus ini, kami memiliki kontrol alternatif yang mengimbangi peninjauan manual.

Menerapkan kontrol serupa di organisasi Anda

Bagian ini menjelaskan praktik terbaik yang kami pelajari saat menerapkan BAB sehingga Anda dapat menerapkan kontrol serupa di organisasi Anda.

Membuat pipeline CI/CD homogen dalam container

Penerapan BAB jadi lebih mudah karena sebagian besar tim menggunakan sistem kontrol sumber tunggal, proses peninjauan kode, sistem build, dan sistem deployment. Peninjauan kode sudah menjadi bagian dari budaya kami, jadi perubahan dapat dibuat tanpa terlalu banyak perubahan signifikan yang terlihat oleh pengguna. Untuk menerapkan BAB, kami berfokus pada peninjauan kode, build yang dapat diverifikasi, deployment dalam container, dan identitas berbasis layanan untuk kontrol akses. Pendekatan ini menyederhanakan penerapan BAB dan memperkuat jaminan yang dapat diberikan oleh solusi seperti BAB.

Penggunaan microservice dan identitas berbasis layanan yang meluas (seperti akun layanan), bukan identitas berbasis host (seperti alamat IP), memungkinkan kami membangun kontrol terperinci atas software yang diizinkan untuk menjalankan setiap layanan.

Jika organisasi tidak dapat menerapkan identitas layanan secara langsung, Anda dapat mencoba melindungi token identitas menggunakan tindakan lain sebagai langkah sementara.

Tentukan sasaran dan kebijakan berdasarkan persyaratan Anda

Buat proses rilis berbasis kebijakan Anda secara bertahap. Anda mungkin perlu menerapkan perubahan tertentu lebih awal daripada yang lain di pipeline CI/CD. Misalnya, Anda mungkin perlu mulai melakukan peninjauan kode formal sebelum dapat menerapkannya pada waktu deployment.

Motivator terbaik bagi proses rilis berbasis kebijakan adalah kepatuhan. Jika Anda dapat mengenkode setidaknya beberapa persyaratan kepatuhan dalam kebijakan, hal ini dapat membantu mengotomatiskan pengujian dan memastikan persyaratan tersebut selalu berlaku. Mulailah dengan serangkaian persyaratan dasar dan kodifikasi persyaratan lanjutan seiring berjalannya waktu.

Menerapkan kebijakan sejak awal pengembangan

Sulit untuk menentukan kebijakan yang komprehensif pada suatu software tanpa terlebih dahulu mengetahui di mana software tersebut akan dijalankan dan data apa yang akan diaksesnya. Oleh karena itu, penerapan kebijakan khusus layanan dilakukan saat kode di-deploy dan mengakses data, bukan saat kode dibuat. Kebijakan ditentukan berdasarkan identitas runtime, sehingga kode yang sama dapat berjalan di lingkungan yang berbeda dan tunduk pada kebijakan yang berbeda.

Kami menggunakan BAB selain mekanisme akses lainnya untuk membatasi akses ke data pengguna. Pemilik layanan dapat memastikan lebih lanjut bahwa data hanya diakses oleh tugas yang memenuhi persyaratan BAB tertentu.

Melibatkan agen perubahan di seluruh tim

Saat membuat mandat di seluruh Google untuk deployment BAB, yang paling memengaruhi tingkat keberhasilan kami adalah menemukan pemilik untuk mendorong perubahan di setiap grup produk. Kami mengidentifikasi beberapa pemilik layanan yang melihat manfaat langsung dari penerapan ini dan bersedia memberikan masukan. Kami meminta para pemilik ini untuk menjadi sukarelawan sebelum mewajibkan perubahan apa pun. Setelah mendapatkan bantuan mereka, kami membentuk tim manajemen perubahan formal untuk melacak perubahan yang sedang berlangsung. Kami kemudian mengidentifikasi pemilik yang bertanggung jawab di setiap tim produk untuk menerapkan perubahan.

Menentukan cara mengelola kode pihak ketiga

Jika harus mengelola kode pihak ketiga, pertimbangkan cara Anda memperkenalkan persyaratan kebijakan ke codebase pihak ketiga. Misalnya, Anda dapat mulai dengan menyimpan repositori semua kode pihak ketiga yang digunakan. Sebaiknya periksa kode tersebut secara rutin berdasarkan persyaratan keamanan Anda.

Untuk informasi selengkapnya tentang cara mengelola kode pihak ketiga, lihat Keberhasilan bersama dalam membangun komunitas open source yang lebih aman.

Langkah selanjutnya