Enkripsi default dalam penyimpanan

Konten ini terakhir diperbarui pada September 2022 dan menampilkan status quo pada saat konten ditulis. Kebijakan dan sistem keamanan Google dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan perlindungan bagi pelanggan.

Di Google, strategi keamanan komprehensif kami mencakup enkripsi dalam penyimpanan, yang membantu melindungi konten pelanggan dari penyerang. Kami mengenkripsi semua konten pelanggan Google dalam penyimpanan menggunakan satu atau beberapa mekanisme enkripsi dan Anda tidak perlu melakukan tindakan apa pun. Dokumen ini menjelaskan pendekatan kami terhadap enkripsi dalam penyimpanan default untuk infrastruktur Google dan Google Cloud, serta cara kami menggunakannya untuk menjaga informasi pelanggan lebih aman.

Dokumen ini ditujukan untuk arsitek keamanan dan tim keamanan yang saat ini menggunakan atau mempertimbangkan untuk menggunakan Google. Dokumen ini mengasumsikan sudah ada pemahaman dasar tentang enkripsi dan primitif kriptografi. Untuk informasi selengkapnya tentang kriptografi, lihat Pengantar Kriptografi Modern.

Enkripsi dalam penyimpanan adalah enkripsi yang digunakan untuk membantu melindungi data yang disimpan di disk (termasuk solid-state drive) atau media cadangan. Semua data yang disimpan oleh Google dienkripsi pada lapisan penyimpanan menggunakan algoritma Advanced Encryption Standard (AES), AES-256. Kami menggunakan library kriptografi umum, Tink, yang menyertakan modul tervalidasi FIPS 140-2 (bernama BoringCrypto) untuk mengimplementasikan enkripsi secara konsisten di Google Cloud.

Kami mengelola kunci yang digunakan dalam enkripsi default dalam penyimpanan. Jika Anda menggunakan Google Cloud, Cloud Key Management Service memungkinkan Anda membuat kunci enkripsi sendiri yang dapat digunakan untuk menambahkan enkripsi menyeluruh ke data Anda. Dengan Cloud KMS, Anda dapat membuat, merotasi, melacak, dan menghapus kunci. Untuk informasi selengkapnya, lihat Mempelajari Cloud Key Management Service secara mendalam.

Cara enkripsi dalam penyimpanan membantu mengamankan data

Enkripsi dalam penyimpanan adalah salah satu bagian dari strategi keamanan yang lebih luas. Enkripsi memiliki manfaat sebagai berikut:

  • Membantu memastikan bahwa jika data jatuh ke tangan penyerang, penyerang tidak dapat membaca data tanpa akses ke kunci enkripsi. Meskipun penyerang mendapatkan perangkat penyimpanan yang berisi data pelanggan, mereka tidak akan dapat memahami atau mendekripsinya.
  • Membantu mengurangi permukaan serangan dengan memotong lapisan bawah stack hardware dan software.
  • Berfungsi sebagai chokepoint karena kunci enkripsi yang dikelola secara terpusat membuat satu tempat untuk menerapkan akses ke data dan dapat diaudit.
  • Membantu mengurangi permukaan serangan karena bisnis dapat memfokuskan strategi perlindungan pada kunci enkripsi, tanpa harus melindungi semua data.
  • Menyediakan mekanisme privasi yang penting bagi pelanggan kami. Saat data dienkripsi dalam penyimpanan, akses yang dimiliki sistem dan engineer ke data akan dibatasi

Apa itu data pelanggan?

Seperti yang dijelaskan dalam persyaratan layanan Google Cloud, data pelanggan adalah data yang diberikan pelanggan atau pengguna akhir kepada Google melalui layanan yang terkait dengan akun pelanggan. Data pelanggan mencakup konten dan metadata pelanggan.

Konten pelanggan adalah data yang Anda buat sendiri atau Anda berikan kepada kami, seperti data yang disimpan di Cloud Storage, snapshot disk yang digunakan oleh Compute Engine, dan kebijakan IAM. Dokumen ini berfokus pada enkripsi default dalam penyimpanan untuk konten pelanggan.

Metadata pelanggan merupakan seluruh data Anda. Metadata pelanggan dapat mencakup nomor project yang dihasilkan secara otomatis, stempel waktu, alamat IP, ukuran byte objek di Cloud Storage, atau jenis mesin di Compute Engine. Metadata dilindungi hingga suatu tingkat yang wajar untuk mendukung performa dan operasi yang berkelanjutan.

Enkripsi default data dalam penyimpanan

Google mengenkripsi semua konten pelanggan yang tersimpan dalam status nonaktif menggunakan satu atau beberapa mekanisme enkripsi dan Anda tidak perlu melakukan tindakan apa pun. Bagian berikut menjelaskan mekanisme yang kami gunakan untuk mengenkripsi konten pelanggan.

Lapisan enkripsi

Google menggunakan beberapa lapisan enkripsi untuk membantu melindungi data. Penggunaan beberapa lapisan enkripsi ini menambahkan perlindungan data redundan dan memungkinkan kami memilih pendekatan yang optimal berdasarkan persyaratan aplikasi.

Diagram berikut menunjukkan beberapa lapisan enkripsi yang umumnya digunakan untuk melindungi data pengguna di pusat data produksi Google. Enkripsi sistem file terdistribusi atau enkripsi database dan penyimpanan file diterapkan untuk semua data pengguna, dan enkripsi perangkat penyimpanan diterapkan untuk semua data di pusat data produksi Google.

Beberapa lapisan enkripsi.

Enkripsi pada lapisan perangkat keras dan infrastruktur

Semua sistem penyimpanan Google menggunakan arsitektur enkripsi yang serupa, meskipun detail implementasinya berbeda antara satu sistem dengan sistem lainnya. Data dibagi menjadi potongan-potongan subfile untuk penyimpanan; setiap potongan dapat berukuran hingga beberapa gigabyte. Setiap potongan dienkripsi di level penyimpanan dengan kunci enkripsi data (DEK) individu: dua potongan tidak akan memiliki DEK yang sama, meskipun dimiliki oleh pelanggan yang sama atau disimpan di mesin yang sama. (Potongan data di Datastore, App Engine, dan Pub/Sub dapat berisi data dari beberapa pelanggan.

Jika suatu potongan data diperbarui, potongan data tersebut akan dienkripsi dengan kunci baru, bukan dengan menggunakan kembali kunci yang sudah ada. Partisi data ini, masing-masing menggunakan kunci yang berbeda, membatasi risiko potensi penyusupan kunci enkripsi data hanya pada bagian data tersebut.

Google mengenkripsi data sebelum ditulis ke sistem penyimpanan database atau disk hardware. Enkripsi melekat pada semua sistem penyimpanan, bukan ditambahkan setelahnya.

Setiap potongan data memiliki ID unik. Daftar kontrol akses (ACL) membantu memastikan bahwa setiap potongan hanya dapat didekripsi oleh layanan Google yang beroperasi dengan peran yang diizinkan, yang hanya diberikan akses pada waktu tersebut. Pembatasan akses ini membantu mencegah akses ke data tanpa otorisasi, sehingga memperkuat keamanan dan privasi data.

Setiap potongan didistribusikan ke seluruh sistem penyimpanan dan direplikasi dalam bentuk terenkripsi untuk cadangan dan pemulihan dari bencana (disaster recovery). Penyerang yang ingin mengakses data pelanggan perlu mengetahui dan dapat mengakses dua hal: semua potongan penyimpanan yang berhubungan dengan data yang mereka inginkan dan semua kunci enkripsi yang terkait pada potongan tersebut.

Diagram berikut menunjukkan cara data diupload ke infrastruktur kita, lalu dipecah menjadi potongan-potongan terenkripsi untuk penyimpanan.

Cara data diupload.

Kami menggunakan algoritma AES untuk mengenkripsi data dalam penyimpanan. Semua data di level penyimpanan dienkripsi oleh DEK, yang secara default menggunakan AES-256, kecuali sebagian kecil Persistent Disk yang dibuat sebelum 2015 yang menggunakan AES-128. AES digunakan secara luas karena AES-256 dan AES-128 direkomendasikan oleh National Institute of Standards and Technology (NIST) untuk penggunaan penyimpanan jangka panjang, dan AES sering kali disertakan sebagai bagian dari persyaratan kepatuhan pelanggan.

Enkripsi pada lapisan perangkat penyimpanan

Selain enkripsi level sistem penyimpanan, data juga dienkripsi pada level perangkat penyimpanan dengan AES-256 untuk hard disk drive (HDD) dan solid-state drive (SSD), menggunakan kunci level perangkat terpisah (yang berbeda dengan kunci yang digunakan untuk mengenkripsi data di level penyimpanan). Sebagian kecil HDD lama menggunakan AES-128. SSD yang digunakan oleh Google mengimplementasikan AES-256 untuk data pengguna secara eksklusif.

Enkripsi cadangan

Sistem pencadangan kami memastikan bahwa data tetap terenkripsi selama proses pencadangan. Pendekatan ini menghindari tereksposnya data teks biasa secara tidak perlu.

Selain itu, sistem pencadangan mengenkripsi lebih lanjut sebagian besar file cadangan secara independen dengan DEK-nya sendiri. DEK berasal dari kunci yang disimpan di Keystore dan seed per file yang dihasilkan secara acak pada waktu pencadangan. DEK lain digunakan untuk semua metadata di cadangan, yang juga disimpan di Keystore.

Kepatuhan FIPS untuk data dalam penyimpanan

Google menggunakan modul enkripsi tervalidasi FIPS 140-2 (sertifikat 4407) di lingkungan produksi kami.

Pengelolaan kunci

Karena tingginya volume kunci di Google dan adanya kebutuhan untuk latensi rendah dan ketersediaan tinggi, kunci ini disimpan di dekat data yang dienkripsi. DEK dienkripsi (digabungkan oleh) kunci enkripsi kunci (KEK), menggunakan teknik yang dikenal sebagai enkripsi menyeluruh. KEK ini tidak dikhususkan untuk pelanggan; namun, ada satu atau lebih KEK untuk setiap layanan.

KEK ini disimpan secara terpusat di Keystore, repositori yang dibuat khusus untuk menyimpan kunci. Memiliki jumlah KEK yang lebih sedikit daripada DEK dan menggunakan Keystore pusat membuat penyimpanan dan enkripsi data pada skala kami mudah dikelola dan memungkinkan kami melacak dan mengontrol akses data dari titik pusat.

Di Google Cloud, setiap pelanggan dapat memiliki resource yang digunakan bersama dan tidak digunakan bersama. Contoh resource bersama adalah image dasar bersama di Compute Engine. Untuk resource bersama, beberapa pelanggan merujuk ke satu salinan yang dienkripsi dengan DEK tunggal. Resource yang tidak digunakan bersama dibagi ke dalam potongan data dan dienkripsi dengan kunci yang terpisah dari kunci yang digunakan untuk pelanggan lain. Kunci ini bahkan terpisah dari kunci yang melindungi bagian lain dari data yang sama yang dimiliki oleh pelanggan yang sama. Pengecualiannya adalah data yang disimpan di Datastore, App Engine, atau Pub/Sub, yang mana lebih dari satu data pelanggan dapat dienkripsi dengan DEK yang sama.

Membuat DEK

Sistem penyimpanan menghasilkan DEK menggunakan library kriptografi umum Google. Secara umum, DEKS kemudian dikirim ke Keystore untuk digabungkan dengan KEK sistem penyimpanan tersebut, dan DEK yang digabungkan diteruskan kembali ke sistem penyimpanan untuk disimpan bersama potongan data. Saat perlu mengambil data terenkripsi, sistem penyimpanan akan mengambil DEK yang digabungkan dan meneruskannya ke Keystore. Keystore kemudian memverifikasi bahwa layanan ini memiliki izin untuk menggunakan KEK dan, jika demikian, akan membuka dan menampilkan DEK teks biasa ke layanan. Kemudian, layanan akan menggunakan DEK untuk mendekripsi potongan data menjadi teks biasa dan memverifikasi integritasnya.

Semua sistem penyimpanan Google Cloud mematuhi model pengelolaan kunci ini, tetapi sebagian besar sistem juga menerapkan level KEK sisi penyimpanan tambahan untuk membuat hierarki kunci. Hal ini memungkinkan sistem memberikan latensi rendah saat menggunakan KEK level tertinggi (yang disimpan di Keystore) sebagai root of trust.

Membuat KEK

Sebagian besar KEK untuk mengenkripsi potongan data dihasilkan di dalam Keystore, dan sisanya dihasilkan di dalam layanan penyimpanan. Untuk konsistensi, semua KEK dihasilkan menggunakan library kriptografi umum Google, menggunakan generator angka acak (RNG) yang dibuat oleh Google. RNG ini didasarkan pada NIST 800-90Ar1 CTR-DRBG dan menghasilkan AES-256 KEK. (Sebelumnya, yang digunakan adalah AES-128, dan beberapa kunci ini masih aktif untuk mendekripsi data).

RNG di-seed dari petunjuk RDRAND Intel dan RNG kernel Linux. Kemudian, RNG kernel Linux di-seed dari beberapa sumber entropi independen, termasuk RDRAND dan peristiwa entropi dari lingkungan pusat data (misalnya, pengukuran mendetail atas pencarian disk dan waktu kedatangan antar-paket).

DEK digabungkan dengan KEK menggunakan AES-256 atau AES-128, bergantung pada layanan Google Cloud. Saat ini kami sedang berupaya mengupgrade semua KEK untuk layanan Google Cloud ke AES-256.

Pengelolaan KEK

Keystore dibuat hanya untuk tujuan mengelola KEK. Secara desain, KEK yang digunakan oleh sistem penyimpanan tidak dapat diekspor dari Keystore; semua enkripsi dan dekripsi dengan kunci ini harus dilakukan dalam Keystore. Hal ini membantu mencegah kebocoran dan penyalahgunaan, serta memungkinkan Keystore membuat jejak audit saat kunci digunakan.

Keystore dapat merotasi KEK secara otomatis pada interval waktu yang teratur, menggunakan library kriptografi umum Google untuk menghasilkan kunci baru. Meskipun kami sering merujuk pada satu kunci saja, maksud kami sebenarnya adalah bahwa data dilindungi menggunakan set kunci: satu kunci aktif untuk enkripsi, dan satu set kunci historis aktif untuk dekripsi. Jumlah kunci historis ditentukan oleh jadwal rotasi kunci. KEK dicadangkan untuk tujuan pemulihan dari bencana (disaster recovery) dan dapat dipulihkan tanpa batas waktu.

Penggunaan KEK dikelola oleh ACL di Keystore untuk setiap kunci, dengan kebijakan per kunci. Hanya layanan dan pengguna Google dengan otorisasi yang diizinkan untuk mengakses kunci. Penggunaan setiap kunci dilacak pada level operasi individu yang memerlukan kunci tersebut—sehingga setiap kali menggunakan kunci, pengguna akan diautentikasi dan dicatat ke dalam log. Semua akses data oleh pengguna dapat diaudit sebagai bagian dari keseluruhan kebijakan keamanan dan privasi Google.

Proses untuk mengakses potongan data terenkripsi

Saat layanan Google mengakses potongan data terenkripsi, hal berikut akan terjadi:

  1. Layanan membuat panggilan ke sistem penyimpanan untuk data yang dibutuhkannya.
  2. Sistem penyimpanan mengidentifikasi potongan-potongan tempat data disimpan (ID potongan) dan lokasi penyimpanannya.
  3. Untuk setiap potongan, sistem penyimpanan menarik DEK yang digabungkan yang disimpan bersama potongan tersebut (dalam beberapa kasus, langkah ini dilakukan oleh layanan), dan mengirimkannya ke Keystore untuk dibuka.
  4. Sistem penyimpanan memverifikasi bahwa tugas yang diidentifikasi diizinkan untuk mengakses potongan data tersebut berdasarkan ID tugas dan menggunakan ID potongan. Keystore memverifikasi bahwa sistem penyimpanan diizinkan untuk menggunakan KEK yang terkait dengan layanan dan untuk membuka DEK tersebut.
  5. Keystore melakukan salah satu hal berikut:
    • Mengembalikan DEK yang sudah tidak digabungkan ke sistem penyimpanan, yang mendekripsi potongan data tersebut dan meneruskannya ke layanan.
    • Dalam beberapa kasus yang jarang terjadi, meneruskan DEK yang tidak digabungkan ke layanan. Sistem penyimpanan meneruskan potongan data terenkripsi ke layanan, yang akan mendekripsi potongan data tersebut dan menggunakannya.

Proses ini berbeda pada perangkat penyimpanan khusus, yang mana perangkat mengelola dan melindungi DEK tingkat perangkat.

Diagram berikut menunjukkan proses ini. Untuk mendekripsi potongan data, layanan penyimpanan memanggil Keystore untuk mengambil DEK yang tidak digabungkan untuk potongan data tersebut.

Proses untuk mengenkripsi potongan data.

Hierarki kunci enkripsi dan root of trust

Keystore dilindungi oleh kunci root yang disebut kunci master keystore, yang menggabungkan semua KEK di Keystore. Kunci master keystore ini adalah AES-256 dan tersimpan sendiri di key management service lain, yang disebut Root Keystore. (Sebelumnya, kunci master keystore adalah AES-128, dan beberapa kunci ini masih aktif untuk mendekripsi data). Root Keystore menyimpan jumlah kunci yang jauh lebih sedikit—sekitar selusin per region. Untuk keamanan tambahan, Root Keystore tidak dijalankan pada mesin produksi umum, tetapi hanya dijalankan pada mesin khusus di setiap pusat data Google.

Selanjutnya, Root Keystore memiliki kunci root sendiri, yang disebut kunci master keystore root, yang juga merupakan AES-256 dan disimpan dalam infrastruktur peer-to-peer, yang disebut distributor kunci master root keystore, yang mereplikasi kunci tersebut secara global. (Sebelumnya, kunci master root keystore adalah AES-128, dan beberapa kunci ini masih aktif untuk mendekripsi data). Distributor kunci master keystore root hanya menyimpan kunci di RAM pada mesin khusus yang sama dengan Root Keystore dan menggunakan logging untuk memverifikasi penggunaan yang tepat. Satu instance distributor kunci master root keystore berjalan untuk setiap instance Root Keystore.

Ketika instance baru distributor kunci master root keystore dimulai, instance baru tersebut akan dikonfigurasi dengan daftar nama host yang sudah menjalankan instance distributor. Instance distributor selanjutnya dapat memperoleh kunci master root keystore dari instance lain yang berjalan. Selain mekanisme pemulihan dari bencana (disaster recovery) yang dijelaskan dalam Ketersediaan dan replikasi global, kunci master root keystore hanya ada di RAM pada mesin yang diamankan secara khusus dalam jumlah terbatas.

Untuk mengatasi skenario ketika semua instance distributor kunci master root keystore di suatu region dimulai ulang secara bersamaan, kunci master root keystore juga dicadangkan di perangkat hardware aman yang disimpan di brankas fisik dengan kondisi aman di beberapa lokasi yang terdistribusi secara geografis. Cadangan ini hanya diperlukan jika semua instance distributor di suatu region terhenti bersamaan. Brankas ini hanya dapat diakses oleh kurang dari 100 karyawan Google.

Diagram berikut menunjukkan hierarki kunci enkripsi. Hierarki kunci enkripsi melindungi potongan data dengan DEK, yang digabungkan dengan KEK di Keystore, yang kemudian dilindungi oleh Root Keystore dan distributor kunci master root keystore.

Hierarki kunci enkripsi.

Ringkasan pengelolaan kunci

Daftar berikut meringkas pengelolaan kunci di Google:

  • Data dipecah menjadi potongan dan dienkripsi dengan DEK.
  • DEK dienkripsi dengan KEK.
  • KEK disimpan di Keystore.
  • Keystore berjalan pada beberapa mesin di pusat data secara global.
  • Kunci keystore digabungkan dengan kunci master Keystore, yang disimpan di Root Keystore.
  • Root Keystore jauh lebih kecil daripada Keystore dan hanya berjalan pada mesin khusus di setiap pusat data.
  • Kunci Root Keystore digabungkan dengan kunci master root keystore, yang disimpan dalam distributor kunci master root keystore.
  • Distributor kunci master Root Keystore adalah infrastruktur peer-to-peer yang berjalan serentak di RAM pada mesin khusus secara global. Setiap mesin mendapatkan material kuncinya dari instance lain yang sedang berjalan di region tersebut.
  • Jika semua instance distributor di suatu wilayah terhenti, kunci master disimpan di hardware aman yang berbeda di brankas fisik di lokasi Google yang terbatas.

Ketersediaan dan replikasi global

Di setiap level, ketersediaan tinggi, latensi rendah, dan akses global ke kunci sangatlah penting. Karakteristik ini diperlukan agar key management service dapat digunakan di seluruh Google.

Karena alasan ini, Keystore sangat skalabel dan direplikasi ribuan kali di pusat data kami secara global. Keystore ini dijalankan pada mesin reguler di fleet produksi kami dan instance Keystore berjalan secara global untuk mendukung operasi Google. Hasilnya, latensi operasi kunci tunggal apa pun sangat rendah.

Root Keystore berjalan pada beberapa mesin yang dikhususkan untuk operasi keamanan, di setiap pusat data. Distributor kunci master Root Keystore dijalankan pada mesin yang sama, one-to-one dengan Root Keystore. Distributor kunci master Root Keystore menyediakan mekanisme distribusi menggunakan protokol gossiping. Pada interval waktu tetap, setiap instance distributor memilih instance lain secara acak untuk membandingkan kuncinya dan merekonsiliasi setiap perbedaan dalam versi kunci. Dengan model ini, tidak ada node pusat yang menjadi tumpuan semua infrastruktur kami. Metode distribusi ini memungkinkan kami memelihara dan melindungi materi kunci dengan ketersediaan tinggi.

Library kriptografi umum Google

Library kriptografi umum Google adalah Tink, yang menggabungkan modul tervalidasi FIPS 140-2 kami, BoringCrypto. Tink tersedia untuk semua developer Google. Penggunaan library umum yang konsisten berarti bahwa hanya tim kecil kriptografer yang perlu menerapkan kode yang dikontrol dan ditinjau secara ketat ini, sehingga setiap tim di Google tidak perlu mengembangkan kriptografi sendiri secara terpisah. Ada tim keamanan Google khusus yang bertanggung jawab mengelola library kriptografi umum ini untuk semua produk.

Library enkripsi Tink mendukung berbagai jenis dan mode kunci enkripsi, dan ditinjau secara rutin untuk memastikan kebaruannya dalam mengantisipasi serangan terbaru.

Saat ini, kami menggunakan algoritma enkripsi berikut untuk enkripsi dalam penyimpanan untuk DEK dan KEK. Algoritma ini dapat berubah sewaktu-waktu seiring peningkatan kemampuan dan keamanan yang kami lakukan.

Primitif kriptografi Protokol yang dipilih Protokol lainnya yang didukung
Enkripsi simetris AES-GCM (256 bit)
  • AES-CBC dan AES-CTR (128 dan 256 bit)
  • AES-EAX (128 dan 256 bit)
Tanda tangan simetris (jika digunakan dengan AES-CBC dan AES-CTR di atas untuk autentikasi) HMAC-SHA256
  • HMAC-SHA512
  • HMAC-SHA1

Protokol kriptografi lain ada di library ini dan secara historis didukung, tetapi tabel ini mencakup protokol utama yang digunakan di Google.

Penelitian dan inovasi dalam kriptografi

Untuk mengimbangi perkembangan teknologi enkripsi, kami memiliki tim engineer keamanan kelas dunia yang ditugaskan mengikuti, mengembangkan, dan meningkatkan teknologi enkripsi. Para engineer kami berpartisipasi dalam proses standardisasi dan pemeliharaan software enkripsi yang banyak digunakan. Kami secara teratur memublikasikan penelitian kami di bidang enkripsi agar semua orang, termasuk masyarakat umum, dapat memperoleh manfaat dari pengetahuan kami.

Misalnya, dalam penelitian kriptografi pasca-kuantum, kami menangani area berikut:

Langkah selanjutnya