Konten ini terakhir diperbarui pada Desember 2022, dan menampilkan status quo 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 pendekatan Google untuk pengesahan mesin pusat data. Arsitektur yang dijelaskan dalam dokumen ini dirancang untuk diintegrasikan dengan standar terbuka seperti Trusted Platform Module (TPM), Security Protocol and Data Model (SPDM), dan Redfish. Untuk penerapan standar atau referensi baru yang diusulkan oleh Google dan terkait dengan pengesahan mesin pusat data, lihat project Integritas Platform (PINT) kami di GitHub. Dokumen ini ditujukan untuk eksekutif keamanan, arsitek keamanan, dan auditor.
Ringkasan
Semakin lama, Google akan mendesain dan men-deploy mesin pusat data yang terpilah. Bukannya memiliki satu root of trust, banyak mesin memiliki root of trust yang terpisah, termasuk root of trust untuk pengukuran (roots of trust for measurement/RTM), penyimpanan, pembaruan, dan pemulihan. Setiap RTM melayani subbagian dari seluruh mesin. Misalnya, sebuah mesin mungkin memiliki satu RTM yang mengukur dan membuktikan apa yang di-boot pada CPU utama, dan RTM lain yang mengukur dan mengesahkan apa yang di-boot pada SmartNIC yang dicolokkan ke slot PCIe. Diagram berikut menunjukkan mesin contoh.
Kompleksitas beberapa RTM dalam mesin menambah skala dan ekspektasi mesin pusat data yang sangat besar, serta banyak komplikasi yang dapat terjadi karena kesalahan manusia, hardware, atau software. Singkatnya, memastikan integritas firmware fleet kami merupakan upaya yang tidak sepele.
Sistem yang dijelaskan dalam dokumen ini dirancang untuk membuat masalah pengesahan jarak jauh untuk mesin yang terpilah lebih mudah dikelola. Infrastruktur pengesahan ini dapat diperluas, sehingga dapat beradaptasi untuk melayani mesin yang semakin kompleks ketika muncul di pusat data.
Dengan membagikan pekerjaan ini, kami ingin memberikan perspektif kami tentang cara melakukan pengesahan mesin yang terpisah dalam skala besar. Melalui kolaborasi dengan partner industri dan kontribusi kepada lembaga standardisasi seperti Distributed Management Task Force (DMTF), Trusted Computing Group (TCG), dan Open Compute Project (OCP), kami bermaksud untuk terus mendukung inovasi keamanan di bidang ini.
Properti RTM yang direkomendasikan
Bagian ini memperkenalkan beberapa properti yang kami rekomendasikan untuk RTM.
Integrasi hardware RTM
Saat prosesor disambungkan dengan RTM, RTM harus mengambil pengukuran melalui kode pertama yang dapat diubah yang berjalan pada prosesor tersebut. Pengukuran kode yang dapat diubah berikutnya harus dicatat dan dilaporkan ke root of trust sebelum kode berjalan. Pengaturan ini menghasilkan rantai booting terukur yang memungkinkan pengesahan yang kuat atas status penting keamanan dari prosesor.
Pengesahan identitas hardware dan firmware RTM
Setiap RTM harus memiliki pasangan kunci penandatanganan yang digunakan untuk menghasilkan pengesahan untuk validasi eksternal. Rantai sertifikat untuk pasangan kunci ini harus menyertakan bukti kriptografis identitas hardware RTM yang unik dan identitas firmware untuk setiap kode yang dapat diubah yang berjalan di dalam RTM. Rantai sertifikat harus di-root pada produsen RTM. Pendekatan ini memungkinkan mesin pulih dari kerentanan firmware RTM yang kritis.
Spesifikasi Device Identifier Composition Engine (DICE) adalah formalisasi pola yang digunakan dalam solusi pengesahan kami. Produsen RTM memberikan sertifikasi untuk pasangan kunci perangkat unik, yang mensertifikasi pasangan kunci alias yang bersifat spesifik untuk identitas hardware dan image firmware RTM. Rantai kunci sertifikat alias berisi pengukuran firmware RTM dan nomor seri RTM. Pemverifikasi dapat merasa yakin bahwa setiap data yang ditandatangani oleh kunci alias tertentu berasal dari RTM yang dideskripsikan oleh pengukuran identitas hardware dan firmware kriptografi yang disematkan dalam rantai sertifikat kunci alias tersebut.
Operasi pengesahan jarak jauh
Skema pengesahan dirancang untuk memastikan bahwa data dan tugas pengguna hanya dikeluarkan ke mesin yang menjalankan boot stack yang diinginkan, sekaligus tetap memungkinkan otomatisasi pemeliharaan inventaris dilakukan dalam skala besar untuk memperbaiki masalah. Layanan penjadwal tugas, yang dihosting di cloud internal kami, dapat mempersulit pengumpulan RTM di dalam mesin, dan membandingkan hasil pengukuran yang telah disahkan dengan kebijakan yang unik untuk mesin tersebut. Penjadwal hanya mengirimkan tugas dan data pengguna ke mesin jika pengukuran yang disahkan sesuai dengan kebijakan mesin.
Pengesahan jarak jauh mencakup dua operasi berikut:
Pembuatan kebijakan pengesahan, yang terjadi setiap kali hardware atau software yang diinginkan mesin diubah.
Verifikasi pengesahan, yang terjadi pada titik yang ditentukan dalam alur pengelolaan mesin kami. Salah satu poin ini adalah tepat sebelum pekerjaan dijadwalkan di mesin. Mesin hanya mendapatkan akses ke tugas dan data pengguna setelah verifikasi pengesahan lulus.
Kebijakan pengesahan
Google menggunakan dokumen bertanda tangan yang dapat dibaca mesin, disebut sebagai kebijakan, untuk menjelaskan hardware dan software yang diharapkan berjalan dalam sebuah mesin. Kebijakan ini dapat dibuktikan melalui pengumpulan RTM oleh mesin. Detail untuk setiap RTM berikut direpresentasikan dalam kebijakan:
- Root certificate identitas tepercaya yang dapat memvalidasi pengesahan yang dikeluarkan oleh RTM.
- Identitas hardware unik global yang mengidentifikasi RTM secara unik.
- Identitas firmware yang menjelaskan versi yang diharapkan yang harus dijalankan RTM.
- Ekspektasi pengukuran untuk setiap tahap booting yang dilaporkan oleh RTM.
- ID untuk RTM, yang serupa dengan nama resource Redfish.
- ID yang menautkan RTM ke lokasi fisiknya dalam sebuah mesin. ID ini serupa dengan nama resource Redfish, dan digunakan oleh sistem perbaikan mesin otomatis.
Selain itu, kebijakan ini juga berisi nomor seri pencabutan unik yang secara global yang membantu mencegah rollback kebijakan yang tidak sah. Diagram berikut menunjukkan kebijakan.
Diagram menunjukkan item berikut dalam kebijakan:
- Tanda tangan tersebut menyediakan otentikasi kebijakan.
- Nomor seri pencabutan akan memperbarui kebijakan untuk membantu mencegah rollback.
- Ekspektasi RTM menghitung detail untuk setiap RTM di mesin.
Bagian berikut menjelaskan item ini secara lebih detail.
Penyusun kebijakan
Saat hardware mesin dirakit atau diperbaiki, model hardware dibuat yang menentukan semua RTM yang diharapkan pada mesin tersebut. Bidang kontrol kami membantu memastikan bahwa informasi ini tetap terbaru di seluruh peristiwa seperti perbaikan yang melibatkan pertukaran komponen atau upgrade hardware.
Selain itu, bidang kontrol mempertahankan serangkaian ekspektasi tentang software yang dimaksudkan untuk diinstal pada mesin, bersama dengan ekspektasi tentang RTM mana yang harus mengukur software mana. Bidang kontrol menggunakan ekspektasi ini, beserta model hardware, untuk menghasilkan kebijakan pengesahan yang ditandatangani dan dapat dibatalkan, yang menjelaskan status mesin yang diharapkan.
Kebijakan yang ditandatangani kemudian ditulis ke penyimpanan persisten pada mesin yang dijelaskan. Pendekatan ini membantu mengurangi jumlah dependensi jaringan dan layanan yang diperlukan oleh pemverifikasi jarak jauh saat mengesahkan mesin. Daripada membuat kueri database untuk kebijakan, pemverifikasi dapat mengambil kebijakan dari mesin itu sendiri. Pendekatan ini adalah fitur desain yang penting, karena penjadwal tugas memiliki persyaratan SLO yang ketat dan harus selalu sangat tersedia. Mengurangi dependensi jaringan mesin ini pada layanan lain akan membantu mengurangi risiko pemadaman layanan. Diagram berikut menunjukkan alur peristiwa ini.
Diagram ini menjelaskan langkah-langkah berikut yang diselesaikan oleh bidang kontrol dalam proses perakitan kebijakan:
- Memperoleh kebijakan pengesahan dari penetapan paket software dan model hardware mesin.
- Menandatangani kebijakan.
- Menyimpan kebijakan di mesin pusat data.
Pencabutan kebijakan
Intent hardware dan software untuk mesin tertentu berubah dari waktu ke waktu. Jika intent berubah, kebijakan lama harus dicabut. Setiap kebijakan pengesahan yang ditandatangani menyertakan nomor seri pencabutan unik. Pemverifikasi mendapatkan kunci publik yang sesuai untuk mengautentikasi kebijakan yang ditandatangani, dan daftar pencabutan sertifikat yang sesuai untuk memastikan bahwa kebijakan masih valid.
Kueri server kunci atau database pencabutan secara interaktif akan memengaruhi ketersediaan penjadwal tugas. Sebagai gantinya, Google menggunakan model asinkron. Kumpulan kunci publik yang digunakan untuk mengautentikasi kebijakan pengesahan bertanda tangan dikirimkan sebagai bagian dari image sistem operasi dasar setiap mesin. CRL dikirim secara asinkron menggunakan sistem deployment pencabutan terpusat yang sama dengan yang digunakan Google untuk jenis kredensial lainnya. Sistem ini telah dirancang untuk operasi yang dapat diandalkan selama kondisi normal, dengan kemampuan untuk melakukan pengiriman darurat yang cepat selama kondisi respons insiden.
Dengan menggunakan kunci publik verifikasi dan file CRL yang disimpan secara lokal di mesin pemverifikasi, pemverifikasi dapat memvalidasi pernyataan pengesahan dari mesin jarak jauh tanpa memiliki layanan eksternal apa pun di jalur penting.
Mengambil kebijakan pengesahan dan memvalidasi pengukuran
Proses pengesahan mesin dari jarak jauh terdiri dari tahap-tahap berikut:
- Mengambil dan memvalidasi kebijakan pengesahan.
- Mendapatkan pengukuran yang disahkan dari RTM mesin.
- Mengevaluasi pengukuran yang telah disahkan terhadap kebijakan.
Diagram dan bagian berikut menjelaskan tahapan ini lebih lanjut.
Mengambil dan memvalidasi kebijakan pengesahan
Pemverifikasi jarak jauh akan mengambil kebijakan pengesahan bertanda tangan untuk mesin tersebut. Seperti yang disebutkan dalam Penyusunan kebijakan, untuk alasan ketersediaan, kebijakan disimpan sebagai dokumen yang ditandatangani di mesin target.
Untuk memverifikasi bahwa kebijakan yang ditampilkan autentik, pemverifikasi jarak jauh akan memeriksa salinan CRL yang relevan dari pemverifikasi. Tindakan ini membantu memastikan bahwa kebijakan yang diambil telah ditandatangani secara kriptografis oleh entitas tepercaya dan bahwa kebijakan tidak dicabut.
Mendapatkan pengukuran yang disahkan
Pemverifikasi jarak jauh mempersulit mesin, meminta pengukuran dari setiap RTM. Pemverifikasi memastikan keaktualan dengan menyertakan nonce kriptografi dalam permintaan ini. Entitas dalam mesin, seperti pengontrol pengelolaan baseboard (baseboard management controller/BMC), merutekan setiap permintaan ke RTM masing-masing, mengumpulkan respons yang ditandatangani, dan mengirimkannya kembali ke pemverifikasi jarak jauh. Entitas di mesin ini tidak memiliki hak istimewa dari perspektif pengesahan, karena hanya berfungsi sebagai transport untuk pengukuran yang ditandatangani RTM.
Google menggunakan API internal untuk mengesahkan pengukuran. Kami juga memberikan kontribusi peningkatan kualitas pada Redfish untuk memungkinkan pemverifikasi di luar mesin menguji BMC untuk pengukuran RTM dengan menggunakan SPDM. Perutean mesin internal dilakukan melalui protokol dan saluran khusus implementasi, termasuk yang berikut ini:
- Redfish over subnet
- Intelligent Platform Management Interface (IPMI)
- Management Component Transport Protocol (MCTP) over i2c/i3c
- PCIe
- Serial Peripheral Interface (SPI)
- USB
Mengevaluasi pengukuran yang disahkan
Pemverifikasi jarak jauh Google memvalidasi tanda tangan yang dimunculkan oleh setiap RTM, memastikan bahwa tanda tangan tersebut di-root kembali ke identitas RTM yang disertakan dalam kebijakan pengesahan mesin. Semua identitas hardware dan firmware yang ada dalam rantai sertifikat RTM divalidasi berdasarkan kebijakan, sehingga memastikan bahwa setiap RTM adalah instance yang benar dan menjalankan firmware yang benar. Untuk memastikan keaktualan, nonce kriptografi yang ditandatangani akan diperiksa. Terakhir, pengukuran yang disahkan akan dievaluasi untuk memastikan bahwa pengukuran tersebut sesuai dengan ekspektasi kebijakan untuk perangkat tersebut.
Bereaksi terhadap hasil pengesahan jarak jauh
Setelah pengesahan selesai, hasilnya harus digunakan untuk menentukan nasib mesin yang sedang melalui pengesahan. Seperti yang ditunjukkan dalam diagram, ada dua kemungkinan hasil: pengesahan berhasil dan mesin diberi kredensial tugas dan data pengguna, atau pengesahan gagal dan pemberitahuan dikirimkan ke infrastruktur perbaikan.
Bagian berikut memberikan informasi selengkapnya tentang proses ini.
Pengesahan yang gagal
Jika pengesahan mesin tidak berhasil, Google tidak akan menggunakan mesin tersebut untuk melayani pekerjaan pelanggan. Sebagai gantinya, peringatan dikirim ke infrastruktur perbaikan, yang mencoba untuk otomatis melakukan reimage mesin. Meskipun kegagalan pengesahan mungkin disebabkan oleh niat jahat, sebagian besar kegagalan pengesahan disebabkan oleh bug dalam peluncuran software. Oleh karena itu, peluncuran dengan kegagalan pengesahan yang meningkat akan dihentikan secara otomatis untuk membantu mencegah lebih banyak mesin agar tidak gagal dalam pengesahan. Saat peristiwa ini terjadi, notifikasi akan dikirimkan ke SRE. Untuk mesin yang tidak diperbaiki dengan reimage otomatis, peluncuran akan dibatalkan, atau akan dilakukan peluncuran software yang telah diperbaiki. Mesin tidak akan digunakan untuk melayani tugas pelanggan sebelum berhasil melakukan pengesahan jarak jauh lagi.
Pengesahan yang berhasil
Jika pengesahan mesin dari jarak jauh berhasil, Google akan menggunakan mesin tersebut untuk melayani tugas produksi, seperti VM untuk pelanggan Google Cloud atau pemrosesan gambar untuk Google Foto. Google mengharuskan semua tindakan tugas penting yang melibatkan layanan jaringan dilindungi dengan kredensial tugas LOAS berjangka pendek. Kredensial ini diberikan melalui koneksi aman setelah verifikasi pengesahan berhasil, dan memberikan hak istimewa yang diperlukan oleh tugas. Untuk informasi selengkapnya tentang kredensial ini, lihat Application Layer Transport Security.
Pengesahan software hanya akan sebaik infrastruktur yang membuat software tersebut. Untuk membantu memastikan bahwa artefak yang dihasilkan merupakan refleksi akurat dari intent kami, kami telah berinvestasi secara signifikan dalam integritas pipeline build. Untuk informasi selengkapnya tentang standar yang diusulkan oleh Google untuk menangani integritas dan keaslian supply chain software, lihat Integritas Supply Chain Software.
Langkah selanjutnya
Pelajari cara BeyondProd membantu mesin pusat data Google membuat koneksi yang aman.