Alat Enkripsi Split-Trust (STET) memungkinkan transfer data kunci yang aman ke dan dari Google Cloud dengan cara yang dapat diverifikasi dan dilindungi secara kriptografis dari orang dalam Google Cloud .
Hal ini dicapai dengan menggunakan dua sistem pengelolaan kunci (KMS), satu internal untuk Google Cloud, dan yang lainnya eksternal. Meskipun satu KMS disusupi, KMS kedua tetap ada untuk membantu menjaga privasi data Anda.
Berikut adalah serangkaian contoh yang melibatkan data yang dikirim ke Cloud Storage dan dikomputasi menggunakan VM Compute Engine. Contoh-contoh ini menjelaskan peningkatan tingkat keamanan untuk membantu menjelaskan cara STET sesuai dengan alur keamanan Anda.
Level 1: Cloud Storage
Saat menyerap data ke Google Cloud, Anda dapat menggunakan Cloud Storage untuk menyediakan data bagi beban kerja cloud Anda. Anda dapat mengupload data dari lingkungan komputasi lokal ke bucket Cloud Storage, memberikan akses workload ke bucket tersebut, dan membuat workload (atau beberapa workload) menggunakan data tersebut jika diperlukan. Strategi ini menghindari kompleksitas dalam membuat koneksi aktif langsung ke beban kerja untuk mengirimkan data yang dibutuhkan.
Cloud Storage selalu mengenkripsi data Anda dalam penyimpanan. Namun, jika Anda mempercayakan Cloud Storage untuk melakukan enkripsi tersebut, Cloud Storage memiliki akses ke data yang tidak dienkripsi (plaintext) sebelum enkripsi, serta kunci enkripsi yang digunakan untuk membuat data terenkripsi (ciphertext). Bergantung pada model ancaman Anda, sebaiknya enkripsi data sebelum Anda mengirimkannya ke Cloud Storage, sehingga Cloud Storage tidak pernah dapat melihat teks biasa.
Level 2: Enkripsi sisi klien
Saat menggunakan enkripsi sisi klien, Anda mengenkripsi data sebelum diupload ke Cloud Storage dan hanya mendekripsinya setelah didownload ke beban kerja Anda. Akibatnya, Cloud Storage memiliki akses ke ciphertext, tetapi bukan plaintext. Cloud Storage menambahkan lapisan enkripsi lain sebelum menyimpannya, tetapi perlindungan utama untuk data adalah enkripsi yang dilakukan sebelum diupload.
Dengan pendekatan ini, Anda kini perlu memberi workload akses ke kunci enkripsi yang diperlukan untuk mendekripsi data. Tindakan ini sendiri berpotensi menjadi tugas yang sulit, karena kunci enkripsi memberikan kemampuan untuk menghapus lapisan enkripsi asli Anda dan mendapatkan visibilitas ke data.
Level 3: Pengelolaan kunci eksternal
Pendekatan umum untuk masalah pengelolaan kunci ini adalah dengan menggunakan Key Management Service (KMS) khusus yang menyimpan kunci dan mengelola akses ke kunci tersebut. Pada setiap upaya enkripsi atau dekripsi, permintaan harus dikirim ke KMS. KMS memiliki kemampuan untuk memberikan akses berdasarkan berbagai kriteria untuk memastikan bahwa hanya pihak yang berhak yang dapat mendekripsi data.
Sistem KMS memiliki kemampuan untuk mewajibkan sejumlah kriteria berbeda sebelum mengizinkan akses ke kunci enkripsi, tetapi biasanya memerlukan kredensial yang cocok dengan kebijakan yang dikonfigurasi di KMS. Oleh karena itu, pihak mana pun yang memiliki kredensial tersebut akan dapat mengakses kunci enkripsi dan dapat mendekripsi data.
Level 4: Confidential Computing
Instance Confidential VM berjalan dengan memori yang dienkripsi, sehingga memberikan perlindungan tambahan terhadap akses yang tidak diinginkan ke data saat sedang digunakan. Untuk banyak model ancaman, instance Confidential VM lebih tepercaya daripada instance standar, sehingga dapat digunakan untuk workload sensitif.
Jika model ancaman Anda mengandalkan Confidential Computing, salah satu masalahnya adalah memastikan bahwa workload berjalan di instance Confidential VM. Pengesahan jarak jauh adalah cara yang memungkinkan beban kerja membuktikan kepada pihak jarak jauh bahwa beban kerja tersebut berjalan di instance Confidential VM dan dapat mengonfirmasi banyak properti lain tentang konfigurasi dan lingkungan beban kerja. Karena pengesahan dibuat oleh platform, beban kerja tidak dapat membuat pengesahan palsu yang tidak mencerminkan lingkungan sebenarnya.
KMS dapat mewajibkan dan mengevaluasi pengesahan ini sebelum mengizinkan akses ke kunci. Persyaratan ini membantu memastikan bahwa hanya workload yang dimaksudkan yang diizinkan untuk mendekripsi data, meskipun kredensial normal disusupi.
Level 5: Kepercayaan terbagi
Saat menggunakan satu KMS, KMS tersebut memiliki kontrol tunggal atas kunci enkripsi. Jika operator KMS mendapatkan ciphertext data terenkripsi Anda, operator tersebut akan memiliki semua yang diperlukan untuk mendekripsinya menjadi teks biasa Anda. Meskipun risiko ini dapat diterima jika KMS dioperasikan oleh entitas yang sepenuhnya tepercaya, beberapa model ancaman menimbulkan kebutuhan untuk menghapus kontrol sepihak dari KMS.
Dengan STET, Anda memiliki opsi untuk membagi kepercayaan ini antara dua sistem KMS, dengan tidak ada KMS yang memiliki informasi yang cukup untuk mendekripsi data Anda. Hal ini memerlukan kolusi antara kedua operator KMS (dan akses ke ciphertext) untuk mendekripsi data Anda.
Jika Anda menggunakan Confidential VM, STET juga memfasilitasi enkripsi dan dekripsi data menggunakan kunci yang disimpan di KMS yang memerlukan pengesahan.
Secara keseluruhan, STET membantu memastikan bahwa satu-satunya entitas yang memiliki akses ke data teks biasa Anda adalah pembuat data (misalnya, sistem lokal) dan konsumen data (misalnya, workload yang berjalan di instance Confidential VM).
Untuk mengetahui informasi selengkapnya tentang cara menggunakan STET, lihat repositori GitHub dan panduan memulai cepat.
Confidential Space dengan STET
Jika Anda menggunakan Confidential Space, STET dapat menggunakan token pengesahan dari Confidential Space sebagai bukti pengesahan saat mengakses kunci enkripsi utama (KEK) yang disimpan di Cloud KMS.
STET menangani akses ke kunci Cloud KMS untuk beban kerja Anda, dan mendukung penggunaan Confidential Space untuk melakukan pengesahan untuk alur kerja enkripsi, alur kerja dekripsi, atau alur kerja enkripsi dan dekripsi.
Anda dapat membuat konfigurasi STET yang mencakup informasi seperti nama kumpulan identitas beban kerja (WIP), URI Cloud KMS, dan informasi dekripsi. STET kemudian menggunakan informasi tersebut untuk berintegrasi dengan penyiapan Ruang Rahasia Anda.
Untuk mengetahui informasi selengkapnya, lihat repositori GitHub dan panduan integrasi Ruang Rahasia.