Split-Trust Encryption Tool (STET) menyediakan mekanisme distribusi yang memungkinkan transfer data kunci yang aman masuk dan keluar 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 satu lagi 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 dihitung menggunakan VM Compute Engine. Contoh ini menjelaskan langkah-langkah untuk meningkatkan tingkat keamanan guna membantu menjelaskan kesesuaian STET dengan alur keamanan Anda.
Level 1: Cloud Storage
Saat menyerap data ke dalam Google Cloud, Anda dapat menggunakan Cloud Storage untuk menyediakan data ke 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 pembuatan koneksi aktif langsung ke beban kerja untuk mengirim data yang dibutuhkan.
Cloud Storage selalu mengenkripsi data Anda dalam penyimpanan. Namun, jika Anda mempercayakan Cloud Storage untuk melakukan enkripsi tersebut, Cloud Storage akan memiliki akses ke data yang tidak dienkripsi (teks biasa) sebelum enkripsi, serta kunci enkripsi yang digunakan untuk membuat data terenkripsi (ciphertext). Bergantung pada model ancaman Anda, sebaiknya enkripsi data sebelum Anda mengirimnya ke Cloud Storage, sehingga Cloud Storage tidak pernah memiliki visibilitas terhadap teks biasa.
Tingkat 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 tidak memiliki akses ke plaintext. Cloud Storage menambahkan lapisan enkripsi lain sebelum menyimpannya, tetapi perlindungan utama untuk data adalah enkripsi yang dilakukan sebelum upload.
Dengan pendekatan ini, Anda kini perlu memberi workload akses ke kunci enkripsi yang diperlukan untuk mendekripsi data. Hal ini sendiri berpotensi menjadi tugas yang sulit, karena kunci enkripsi memberikan kemampuan untuk menghapus lapisan enkripsi asli dan mendapatkan visibilitas ke data.
Level 3: Pengelolaan kunci enkripsi eksternal
Pendekatan umum untuk masalah pengelolaan kunci ini adalah 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 sesuai yang dapat mendekripsi data.
Sistem KMS memiliki kemampuan untuk mewajibkan sejumlah kriteria yang berbeda sebelum memberi otorisasi 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 akan dapat mendekripsi data.
Tingkat 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. Penafian jarak jauh adalah cara bagi beban kerja untuk membuktikan kepada pihak jarak jauh bahwa beban kerja tersebut berjalan di instance Confidential VM dan dapat mengonfirmasi banyak properti lainnya 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 dimaksud yang diizinkan untuk mendekripsi data, meskipun kredensial normal disusupi.
Level 5: Memisahkan kepercayaan
Saat menggunakan satu KMS, KMS tersebut memiliki kontrol penuh atas kunci enkripsi. Jika operator KMS memperoleh ciphertext data terenkripsi Anda, mereka akan memiliki semua yang diperlukan untuk mendekripsinya menjadi teks biasa. Meskipun risiko ini mungkin 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 di 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 mendekode 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 asal data (misalnya, sistem on-premise) dan konsumen data (misalnya, workload yang berjalan di instance Confidential VM).
Untuk 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 kunci (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 menyertakan informasi seperti nama kumpulan identitas beban kerja (WIP), URI Cloud KMS, dan informasi dekripsi. Kemudian, STET akan menggunakan informasi tersebut untuk berintegrasi ke dalam penyiapan Ruang Rahasia Anda.
Untuk mengetahui informasi selengkapnya, lihat repositori GitHub dan panduan integrasi Ruang Rahasia.