Ini adalah laporan resmi ketiga tentang cara Google menggunakan enkripsi untuk melindungi data Anda. Dalam laporan resmi ini, Anda akan menemukan detail selengkapnya tentang enkripsi dalam pengiriman untuk Google Cloud dan Google Workspace.
Untuk semua produk Google, kami berupaya untuk menjaga data pelanggan tetap terlindungi dan setransparan mungkin mengenai cara kami mengamankannya.
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.
Ringkasan level-CIO
- Google memiliki beberapa langkah keamanan untuk membantu memastikan keaslian, integritas, dan privasi data dalam pengiriman.
- Untuk kasus penggunaan yang dibahas dalam laporan resmi ini, Google mengenkripsi dan mengautentikasi data dalam pengiriman di satu atau beberapa lapisan jaringan saat data dipindahkan ke luar batas fisik yang tidak dikontrol oleh Google atau atas nama Google. Semua traffic VM-ke-VM dalam jaringan VPC dan jaringan VPC yang di-peering dienkripsi.
- Bergantung pada koneksi yang dibuat, Google menerapkan perlindungan default terhadap data dalam pengiriman. Misalnya, kami mengamankan komunikasi antara pengguna dan Google Front End (GFE) menggunakan TLS.
- Pelanggan Google Cloud dengan persyaratan tambahan untuk enkripsi data melalui WAN dapat memilih untuk menerapkan perlindungan lebih lanjut untuk data saat data berpindah dari pengguna ke aplikasi, atau virtual machine ke virtual machine. Perlindungan ini mencakup tunnel IPSec, S/MIME Gmail, sertifikat SSL terkelola, dan Istio.
- Google secara aktif bekerja sama dengan industri untuk membantu menghadirkan enkripsi saat dikirim ke semua orang, di mana saja. Kami memiliki beberapa project open source yang mendorong penggunaan enkripsi dalam pengiriman dan keamanan data di Internet secara umum, termasuk Transparansi Sertifikat, Chrome API, dan SMTP aman.
- Google ingin terus menjadi yang terdepan di industri enkripsi dalam pengiriman. Untuk mencapai hal ini, kami mendedikasikan resource untuk pengembangan dan peningkatan teknologi enkripsi. Pekerjaan kami di bidang ini mencakup inovasi di bidang Transparansi Kunci dan kriptografi pasca-kuantum.
Pengantar
Keamanan sering kali menjadi faktor penentu saat memilih penyedia cloud publik. Di Google, keamanan adalah yang paling penting. Kami bekerja tanpa lelah untuk melindungi data Anda, baik saat data tersebut dipindahkan melalui Internet, berpindah di dalam infrastruktur Google, atau disimpan di server kami.
Pusat strategi keamanan Google adalah autentikasi, integritas, dan enkripsi, baik untuk data dalam penyimpanan maupun data dalam pengiriman. Laporan ini menjelaskan pendekatan kami terhadap enkripsi dalam pengiriman untuk Google Cloud.
Untuk data dalam penyimpanan, lihat Enkripsi dalam Penyimpanan di Google Cloud Platform. Untuk ringkasan tentang semua Keamanan Google, lihat Ringkasan Desain Keamanan Infrastruktur Google.
Audiens: dokumen ini ditujukan untuk CISO dan tim operasi keamanan yang menggunakan atau mempertimbangkan untuk menggunakan Google Cloud.
Prasyarat: selain pengantar ini, kami berasumsi sudah ada pemahaman dasar tentang enkripsi dan primitif kriptografi.
Autentikasi, Integritas, dan Enkripsi
Google memiliki beberapa langkah keamanan untuk membantu memastikan keaslian, integritas, dan privasi data dalam pengiriman.
- Autentikasi: kami memverifikasi sumber data, baik manusia maupun proses, dan tujuan.
- Integritas: kami memastikan data yang Anda kirim tiba di tujuannya tanpa perubahan.
- Enkripsi: kami membuat data Anda tidak dapat dibaca saat dalam pengiriman agar data tersebut tetap bersifat pribadi. Enkripsi adalah proses membuat data yang dapat dibaca (teks biasa) menjadi tidak terbaca (ciphertext) dengan tujuan memastikan teks biasa hanya dapat diakses oleh pihak yang diizinkan oleh pemilik data. Algoritma yang digunakan dalam proses enkripsi bersifat publik, tetapi kunci yang diperlukan untuk mendekripsi ciphertext bersifat pribadi. Enkripsi dalam pengiriman sering kali menggunakan pertukaran kunci asimetris, seperti Diffie-Hellman berbasis kurva eliptik, guna membuat kunci simetris bersama yang digunakan untuk enkripsi data. Untuk informasi selengkapnya tentang enkripsi, lihat Pengantar Kriptografi Modern.
Enkripsi dapat digunakan untuk melindungi data dalam tiga status:
- Enkripsi dalam penyimpanan melindungi data Anda dari penyusupan sistem atau pemindahan data yang tidak sah dengan mengenkripsi data saat disimpan. Advanced Encryption Standard (AES) sering digunakan untuk mengenkripsi data dalam penyimpanan.
- Enkripsi dalam pengiriman: melindungi data Anda jika komunikasi disadap saat data berpindah antara situs Anda dan penyedia cloud atau antara dua layanan. Perlindungan ini dilakukan dengan mengenkripsi data sebelum transmisi; mengautentikasi endpoint; serta mendekripsi dan memverifikasi bahwa data tidak dimodifikasi pada saat data tiba di tujuan. Misalnya, Transport Layer Security (TLS) biasanya digunakan mengenkripsi data dalam pengiriman untuk keamanan transportasi, dan Secure/Multipurpose Internet Mail Extensions (S/MIME) biasanya digunakan untuk enkripsi pesan email.
- Enkripsi dalam penggunaan: melindungi data Anda dalam memori dari penyusupan atau pemindahan data yang tidak sah dengan mengenkripsi data saat sedang diproses. Untuk informasi selengkapnya, lihat Confidential Computing.
Enkripsi adalah satu komponen dari strategi keamanan yang lebih luas. Enkripsi dalam pengiriman melindungi data Anda, setelah koneksi dibuat dan diautentikasi, terhadap calon penyerang dengan:
- Meniadakan kebutuhan untuk memercayai lapisan jaringan yang lebih rendah yang biasanya disediakan oleh pihak ketiga
- Mengurangi potensi permukaan serangan
- Mencegah penyerang mengakses data jika komunikasi disadap
Dengan autentikasi, integritas, dan enkripsi yang memadai, data yang berpindah antar-pengguna, perangkat, atau proses dapat dilindungi di lingkungan yang berbahaya. Bagian selanjutnya dari laporan ini menjelaskan pendekatan Google terhadap enkripsi data dalam pengiriman dan tempat enkripsi tersebut diterapkan.
Infrastruktur Jaringan Google
Batas fisik
Batas fisik adalah penghalang ke ruang fisik yang dikontrol oleh atau atas nama Google, tempat kami dapat memastikan bahwa langkah-langkah keamanan yang ketat diterapkan. Akses fisik ke lokasi ini dibatasi dan dipantau secara ketat. Hanya sebagian kecil karyawan Google yang memiliki akses ke hardware. Data dalam pengiriman yang ada dalam batas-batas fisik ini umumnya diautentikasi, tetapi mungkin tidak dienkripsi secara default.
Karena skala Internet global, kami tidak dapat menerapkan kontrol keamanan fisik yang sama untuk link fiber di WAN kami, atau di mana pun di luar batas fisik yang dikontrol oleh atau atas nama Google. Karena alasan ini, kami otomatis menerapkan perlindungan tambahan di luar batas kepercayaan fisik kami. Perlindungan ini mencakup enkripsi data dalam pengiriman untuk semua traffic di luar batas fisik kami.
Cara perutean lalu lintas
Untuk memahami sepenuhnya cara kerja enkripsi dalam pengiriman di Google, Anda juga perlu menjelaskan cara perutean traffic melalui Internet. Bagian ini menjelaskan cara pengiriman permintaan dari pengguna akhir ke layanan Google Cloud atau aplikasi pelanggan yang sesuai, dan cara perutean traffic antarlayanan.
Layanan Google Cloud adalah layanan cloud modular yang kami tawarkan kepada pelanggan. Layanan ini mencakup komputasi, penyimpanan data, analisis data, dan machine learning. Misalnya, Cloud Storage adalah layanan Google Cloud. Aplikasi pelanggan adalah aplikasi yang dihosting di Google Cloud. Sebagai pelanggan Google, Anda dapat membuat dan men-deploy aplikasi tersebut menggunakan layanan Google Cloud. Aplikasi pelanggan atau solusi partner yang dihosting di Google Cloud tidak dianggap sebagai layanan Google Cloud1. Misalnya, aplikasi yang Anda buat menggunakan Google App Engine, Google Kubernetes Engine, atau VM di Google Compute Engine adalah aplikasi pelanggan.
Kelima jenis permintaan pemilihan rute yang dibahas di bawah ditampilkan pada Gambar 1. Gambar ini menunjukkan interaksi antara berbagai komponen jaringan dan keamanan yang ada untuk setiap koneksi.
Pengguna akhir (Internet) ke Layanan Google Cloud
Layanan Google Cloud menerima permintaan dari seluruh dunia menggunakan sistem yang didistribusikan secara global yang disebut Google Front End (GFE). GFE menghentikan traffic untuk traffic proxy HTTP(S), TCP, dan TLS yang masuk, memberikan penanggulangan serangan DDoS, serta merutekan dan melakukan load balancing traffic ke layanan Google Cloud itu sendiri. Terdapat titik kehadiran GFE di seluruh dunia dengan rute yang diiklankan melalui unicast atau Anycast.
Traffic proxy GFE ke layanan Google Cloud. GFE merutekan permintaan pengguna melalui backbone jaringan kami ke layanan Google Cloud. Koneksi ini diautentikasi dan dienkripsi dari GFE ke front-end layanan Google Cloud atau aplikasi pelanggan, saat komunikasi tersebut meninggalkan batas fisik yang dikontrol oleh Google atau atas nama Google. Gambar 1 menunjukkan interaksi ini (koneksi berlabel A).
Pengguna akhir (Internet) ke aplikasi pelanggan yang dihosting di Google Cloud
Ada beberapa cara traffic dari Internet dapat dirutekan ke aplikasi pelanggan yang Anda hosting di Google Cloud. Cara traffic dirutekan bergantung pada konfigurasi Anda, seperti yang dijelaskan di bawah ini. Gambar 1 menunjukkan interaksi ini (koneksi berlabel B).
Jika Anda menggunakan Load Balancer Aplikasi eksternal atau Load Balancer Jaringan proxy eksternal (dengan proxy SSL), lihat Enkripsi dari load balancer ke backend.
Virtual Machine ke Virtual Machine
Koneksi VM-ke-VM dalam jaringan VPC dan jaringan VPC yang di-peering di dalam jaringan produksi Google diautentikasi dan dienkripsi. Hal ini termasuk koneksi antara VM pelanggan dan antara VM pelanggan dan VM yang dikelola Google seperti Cloud SQL. Gambar 1 menunjukkan interaksi ini (koneksi berlabel C). Perlu diperhatikan bahwa koneksi VM-ke-VM yang menggunakan alamat IP eksternal tidak dienkripsi.
Konektivitas ke Google API dan layanan Google
Penanganan traffic berbeda-beda bergantung pada lokasi layanan Google Cloud:
Sebagian besar Google API dan layanan Google dihosting di Google Front End (GFE), tetapi beberapa layanan dihosting pada instance yang dikelola Google. Misalnya, akses layanan pribadi dan master GKE untuk cluster pribadi dihosting di instance yang dikelola Google.
Dengan Akses Google Pribadi, VM yang tidak memiliki alamat IP eksternal dapat mengakses Google API dan layanan Google yang didukung, termasuk aplikasi pelanggan yang dihosting di App Engine. Untuk informasi selengkapnya tentang akses ke Google API dan layanan Google, lihat Opsi akses pribadi untuk layanan.
Jika instance VM Compute Engine terhubung ke alamat IP eksternal instance VM Compute Engine lainnya, traffic akan tetap berada di jaringan produksi Google, tetapi tidak dienkripsi karena penggunaan alamat IP eksternal. Sistem di luar jaringan produksi Google yang terhubung ke alamat IP eksternal instance VM Compute Engine merutekan traffic melalui internet.
Gambar 1 menunjukkan jalur eksternal (koneksi berlabel D). Kasus umum dari permintaan perutean ini adalah:
- Dari VM Compute Engine ke Google Cloud Storage
- Dari VM Compute Engine ke Machine Learning API
Mulai dari VM hingga GFE, layanan Google Cloud mendukung perlindungan koneksi ini dengan TLS secara default2. Koneksi diautentikasi dari GFE ke layanan dan dienkripsi jika koneksi meninggalkan batas fisik. Selain perlindungan default ini, Anda dapat menerapkan enkripsi menyeluruh. Untuk informasi selengkapnya, baca Mengenkripsi data.
Layanan Google Cloud ke layanan Google Cloud
Pemilihan rute dari satu layanan produksi ke layanan produksi lainnya dilakukan di backbone jaringan kami dan mungkin memerlukan pemilihan rute traffic ke luar batas fisik yang dikontrol oleh atau atas nama Google. Gambar 1 menunjukkan interaksi ini (koneksi berlabel E). Contoh jenis traffic ini adalah peristiwa Google Cloud Storage yang memicu Google Cloud Functions. Koneksi antara layanan produksi dienkripsi jika meninggalkan batas fisik, dan diautentikasi dalam batas fisik tersebut.
Gambar 1: Perlindungan secara default dan opsi yang ditempatkan di jaringan VPC
Enkripsi dalam Pengiriman secara Default
Google menggunakan berbagai metode enkripsi, baik default maupun yang dapat dikonfigurasi pengguna, untuk data dalam pengiriman. Jenis enkripsi yang digunakan bergantung pada lapisan OSI, jenis layanan, dan komponen fisik infrastruktur. Gambar 2 dan 3 di bawah mengilustrasikan perlindungan opsional dan default yang dimiliki Google Cloud untuk lapisan 3, 4, dan 7.
Gambar 2: Perlindungan secara Default dan Opsi di Lapisan 3 dan 4 di Google Cloud
Gambar 3: Perlindungan secara Default dan Opsi di Lapisan 7 di Google Cloud3
Selanjutnya, bagian ini menjelaskan perlindungan default yang digunakan Google untuk melindungi data dalam pengiriman.
Enkripsi Pengguna ke Google Front End
Saat ini, banyak sistem menggunakan HTTPS untuk berkomunikasi melalui Internet. HTTPS memberikan keamanan dengan menggunakan koneksi TLS, yang memastikan keaslian, integritas, serta privasi permintaan dan respons. Untuk menerima permintaan HTTPS, penerima memerlukan pasangan kunci umum-pribadi dan sertifikat X.509 untuk autentikasi server dari Certificate Authority (CA). Pasangan kunci dan sertifikat membantu melindungi permintaan pengguna pada lapisan aplikasi (lapisan 7) dengan membuktikan bahwa penerima memiliki nama domain yang dimaksudkan untuk permintaan tersebut. Subbagian berikut membahas komponen enkripsi pengguna ke GFE, yaitu: TLS, BoringSSL, dan Certificate Authority Google. Ingat bahwa tidak semua jalur pelanggan dirutekan melalui GFE; terutama, GFE digunakan untuk traffic dari pengguna ke layanan Google Cloud, dan dari pengguna ke aplikasi pelanggan yang dihosting di Google Cloud yang menggunakan Load Balancing Google Cloud.
Transport Layer Security (TLS)
Saat pengguna mengirim permintaan ke layanan Google Cloud, kami mengamankan data dalam pengiriman; memberikan autentikasi, integritas, dan enkripsi, menggunakan HTTPS dengan sertifikat dari certificate authority web (publik). Semua data yang dikirim pengguna ke GFE dienkripsi saat dalam pengiriman dengan Transport Layer Security (TLS) atau QUIC. GFE menegosiasikan protokol enkripsi tertentu dengan klien, bergantung pada apa yang dapat didukung klien. GFE menegosiasikan protokol enkripsi yang lebih modern jika memungkinkan.
Enkripsi TLS yang diskalakan pada GFE tidak hanya berlaku untuk interaksi pengguna akhir dengan Google, tetapi juga memfasilitasi interaksi API dengan Google melalui TLS, termasuk Google Cloud. Selain itu, enkripsi TLS kami digunakan di Gmail untuk pertukaran email dengan server email eksternal (lihat detail selengkapnya di bagian Mewajibkan TLS di Gmail).
Google adalah pemimpin industri dalam penggunaan TLS dan penguatan penerapannya. Untuk mencapainya, kami telah mengaktifkan banyak fitur keamanan TLS secara default. Misalnya, sejak 2011 kami telah menggunakan forward secrecy dalam implementasi TLS. Forward secrecy memastikan bahwa kunci yang melindungi koneksi tidak bertahan, sehingga penyerang yang menyadap dan membaca satu pesan tidak dapat membaca pesan sebelumnya.
BoringSSL
BoringSSL adalah implementasi protokol TLS open source yang dikelola Google, yang diambil dari OpenSSL, dan sebagian besar kompatibel dengan antarmuka OpenSSL. Google mengambil BoringSSL dari OpenSSL untuk menyederhanakan OpenSSL, baik untuk penggunaan internal maupun untuk mendukung Project Open Source Chromium dan Android dengan lebih baik. BoringCrypto, inti dari BoringSSL, telah divalidasi dengan FIPS 140-2 level 1.
TLS di GFE diimplementasikan dengan BoringSSL. Tabel 1 menunjukkan protokol enkripsi yang didukung GFE saat berkomunikasi dengan klien.
| Protokol | Autentikasi | Pertukaran kunci | Enkripsi | Fungsi Hash |
|---|---|---|---|---|
| TLS 1.3 | RSA 2048 | Curve25519 | AES-128-GCM | SHA384 |
| TLS 1.2 | ECDSA P-256 | P-256 (NIST secp256r1) | AES-256-GCM | SHA256 |
| TLS 1.1 | AES-128-CBC | SHA17 | ||
| TLS 1.04 | AES-256-CBC | MD58 | ||
| QUIC5 | ChaCha20-Poly1305 | |||
| 3DES6 |
Tabel 1: Enkripsi yang Diimplementasikan di Google Front End untuk Layanan Google Cloud dan Diimplementasikan di Library Kriptografi BoringSSL
Certificate Authority Google
Sebagai bagian dari TLS, server harus membuktikan identitasnya kepada pengguna saat menerima permintaan koneksi. Verifikasi identitas ini dilakukan dalam protokol TLS dengan meminta server memberikan sertifikat berisi identitas yang diklaim. Sertifikat ini berisi nama host DNS server dan kunci publiknya. Setelah ditampilkan, sertifikat ditandatangani oleh Certificate Authority (CA) penerbit yang dipercaya oleh pengguna yang meminta koneksi9. Hasilnya, pengguna yang meminta koneksi ke server hanya perlu memercayai CA root. Jika server ingin diakses di mana-mana, CA root harus diketahui oleh perangkat klien di seluruh dunia. Saat ini, sebagian besar browser dan implementasi klien TLS lainnya masing-masing memiliki kumpulan CA root sendiri yang dikonfigurasi sebagai tepercaya di "root store".
Sebelumnya, Google mengoperasikan CA penerbitnya sendiri, yang kami gunakan untuk menandatangani sertifikat bagi domain Google. Namun, kami tidak mengoperasikan CA root sendiri. Saat ini, sertifikat CA kami ditandatangani oleh beberapa CA root yang didistribusikan di mana-mana, termasuk DigiCert dan root yang sebelumnya dioperasikan oleh GlobalSign ("GS Root R2" dan "GS Root R4").
Pada bulan Juni 2017, kami mengumumkan transisi untuk menggunakan CA root milik Google. Seiring waktu, kami berencana mengoperasikan CA root yang didistribusikan secara merata yang akan menerbitkan sertifikat untuk domain Google dan untuk pelanggan kami.
Migrasi kunci root dan rotasi kunci
Kunci CA root tidak sering diubah, karena migrasi ke CA root baru mengharuskan semua browser dan perangkat menyematkan kepercayaan dari sertifikat tersebut, yang membutuhkan waktu lama. Akibatnya, meskipun Google kini mengoperasikan CA root-nya sendiri, kami akan tetap mengandalkan beberapa CA root pihak ketiga selama periode transisi untuk memperhitungkan perangkat lama saat bermigrasi ke CA root kami sendiri.
Pembuatan kunci CA root baru memerlukan key ceremony. Di Google, ceremony tersebut mewajibkan minimal 3 dari 6 orang yang memiliki izin berkumpul secara fisik untuk menggunakan kunci hardware yang disimpan di brankas. Orang-orang ini bertemu di ruang khusus yang terlindung dari gangguan elektromagnetik, dengan Hardware Security Module (HSM) air-gapped, untuk membuat serangkaian kunci dan sertifikat. Ruangan khusus berada di lokasi yang aman di pusat data Google. Kontrol tambahan, seperti langkah keamanan fisik, kamera, dan pengamat manusia lainnya, memastikan bahwa proses berjalan sesuai rencana. Jika ceremony berhasil, sertifikat yang dihasilkan identik dengan sertifikat sampel, kecuali untuk nama penerbit, kunci publik, dan tanda tangan. Sertifikat CA root yang dihasilkan kemudian dikirim ke program root browser dan perangkat untuk disertakan. Proses ini dirancang untuk memastikan bahwa privasi dan keamanan kunci pribadi yang terkait dapat dipahami dengan baik sehingga kunci tersebut dapat digunakan selama satu dekade atau lebih.
Seperti yang dijelaskan sebelumnya, CA menggunakan kunci pribadinya untuk menandatangani sertifikat, dan sertifikat ini memverifikasi identitas saat memulai TLS handshake sebagai bagian dari sesi pengguna. Sertifikat server ditandatangani dengan CA perantara, yang pembuatannya mirip dengan pembuatan CA root. Sertifikat CA perantara didistribusikan sebagai bagian dari sesi TLS sehingga lebih mudah bermigrasi ke CA perantara baru. Metode distribusi ini juga memungkinkan operator CA untuk menyimpan materi kunci CA root dalam keadaan offline.
Keamanan sesi TLS bergantung pada seberapa baik perlindungan kunci server. Untuk mengurangi risiko penyusupan kunci lebih lanjut, masa aktif sertifikat TLS Google dibatasi hingga sekitar tiga bulan dan sertifikat dirotasi kira-kira setiap dua minggu.
Klien yang sebelumnya telah terhubung ke server dapat menggunakan kunci tiket pribadi10 untuk melanjutkan sesi sebelumnya dengan TLS handshake yang disingkat, sehingga tiket ini menjadi sangat berharga bagi penyerang. Google merotasi kunci tiket minimal sekali sehari dan mengakhiri masa berlaku kunci di semua properti setiap 3 hari. Untuk mempelajari rotasi tiket kunci sesi lebih lanjut, lihat Mengukur Bahaya Keamanan Pintasan Kriptografi TLS.
Google Front End ke Front End Aplikasi
Dalam beberapa kasus, seperti yang dibahas dalam Cara perutean traffic, pengguna terhubung ke GFE di dalam batas fisik yang berbeda dari layanan yang diinginkan dan Front End Aplikasi terkait. Saat ini terjadi, permintaan pengguna dan protokol lapisan 7 lainnya, seperti HTTP, akan dilindungi oleh TLS atau dienkapsulasi dalam RPC yang dilindungi menggunakan Application Layer Transport Security (ALTS), yang dibahas di Autentikasi, integritas, dan enkripsi layanan ke layanan. RPC ini diautentikasi dan dienkripsi.
Untuk layanan Google Cloud, RPC dilindungi menggunakan ALTS. Untuk aplikasi pelanggan yang dihosting di Google Cloud, jika traffic dirutekan melalui Google Front End, misalnya jika menggunakan Load Balancer Google Cloud, traffic ke VM dilindungi menggunakan enkripsi jaringan virtual Google Cloud, yang dijelaskan di bagian berikutnya.
Enkripsi dan autentikasi jaringan virtual Google Cloud
Enkripsi traffic IP pribadi dalam VPC yang sama atau di seluruh jaringan VPC yang di-peering dalam jaringan virtual Google Cloud dilakukan pada lapisan jaringan.
Kami menggunakan Advanced Encryption Standard (AES) dalam Galois/Counter Mode (GCM) dengan kunci 128 bit (AES-128-GCM) untuk mengimplementasikan enkripsi pada lapisan jaringan. Setiap pasangan host yang berkomunikasi membuat kunci sesi melalui saluran kontrol yang dilindungi oleh ALTS untuk komunikasi yang diautentikasi dan dienkripsi. Kunci sesi digunakan untuk mengenkripsi semua komunikasi VM-ke-VM antara host tersebut, dan kunci sesi dirotasi secara berkala.
Pada lapisan jaringan (lapisan 3), jaringan virtual Google Cloud mengautentikasi semua traffic antar-VM. Autentikasi yang dilakukan melalui token keamanan ini melindungi host yang disusupi dari paket spoofing di jaringan.
Selama autentikasi, token keamanan dienkapsulasi dalam header tunnel yang berisi informasi autentikasi tentang pengirim dan penerima. Bidang kontrol11 di sisi pengirim menetapkan token, dan host penerima memvalidasi token. Token keamanan telah dibuat sebelumnya untuk setiap alur, dan terdiri dari kunci token (berisi informasi pengirim) dan secret host. Ada satu secret untuk setiap pasangan batas fisik sumber-penerima yang dikontrol oleh atau atas nama Google.
Gambar 4 menunjukkan cara pembuatan kunci token, secret host, dan token keamanan.
Gambar 4: Token Keamanan
Secret batas fisik adalah angka pseudorandom 128-bit, yang merupakan tempat secret host diperoleh dengan mengambil HMAC-SHA1. Secret batas fisik dinegosiasikan melalui handshake antara bidang kontrol jaringan dari sepasang batas fisik dan dinegosiasi ulang setiap beberapa jam. Token keamanan yang digunakan untuk autentikasi VM-ke-VM individu, yang berasal dari input ini dan input lainnya, adalah HMAC, yang dinegosiasikan untuk pasangan pengirim dan penerima tertentu.
Enkripsi virtual machine ke Google Front End
Traffic VM ke GFE menggunakan IP eksternal untuk menjangkau layanan Google, tetapi Anda dapat mengonfigurasi Akses pribadi agar hanya menggunakan alamat IP khusus Google untuk permintaan tersebut.
Secara default, kami mendukung traffic TLS dari VM ke GFE. Koneksi dibuat dengan cara yang sama seperti koneksi eksternal lainnya. Untuk informasi selengkapnya tentang TLS, lihat Transport Layer Security (TLS).
Enkripsi, integritas, dan autentikasi layanan-ke-layanan
Dalam infrastruktur Google, pada lapisan aplikasi (lapisan 7), kami menggunakan Application Layer Transport Security (ALTS) untuk autentikasi, integritas, dan enkripsi panggilan Google RPC dari GFE ke layanan, dan dari layanan ke layanan.
ALTS menggunakan akun layanan untuk autentikasi. Setiap layanan yang berjalan di infrastruktur Google berjalan sebagai identitas akun layanan dengan kredensial kriptografis terkait. Saat membuat atau menerima RPC dari layanan lain, layanan menggunakan kredensialnya untuk melakukan autentikasi. ALTS memverifikasi kredensial ini menggunakan certificate authority internal.
Dalam batas fisik yang dikontrol oleh atau atas nama Google, ALTS menyediakan autentikasi dan integritas untuk RPC dalam mode “autentikasi dan integritas”. Untuk traffic melalui WAN di luar batas fisik yang dikontrol oleh atau atas nama Google, ALTS menerapkan enkripsi untuk traffic RPC infrastruktur secara otomatis dalam mode "autentikasi, integritas, dan privasi". Saat ini, semua traffic ke layanan Google, termasuk layanan Google Cloud, mendapatkan manfaat dari perlindungan yang sama.
ALTS juga digunakan untuk mengenkapsulasi protokol lapisan 7 lainnya, seperti HTTP, dalam mekanisme RPC infrastruktur untuk traffic yang berpindah dari Google Front End ke Front End Aplikasi. Perlindungan ini mengisolasi lapisan aplikasi dan menghapus semua dependensi pada keamanan jalur jaringan.
Layanan infrastruktur keamanan hanya menerima dan mengirim komunikasi ALTS dalam mode “autentikasi, integritas, dan privasi”, bahkan dalam batas fisik yang dikontrol oleh atau atas nama Google sekalipun. Salah satu contohnya adalah Keystore, yang menyimpan dan mengelola kunci enkripsi yang digunakan untuk melindungi data yang disimpan dalam keadaan nonaktif di infrastruktur Google.
Enkripsi jaringan menggunakan PSP
PSP Security Protocol (PSP) tidak bergantung pada transport sehingga memungkinkan keamanan per koneksi dan mendukung pemindahan enkripsi ke hardware kartu antarmuka jaringan smart (SmartNIC). Setiap kali SmartNIC tersedia, kami menggunakan PSP untuk mengenkripsi data dalam pengiriman di seluruh jaringan.
PSP dirancang untuk memenuhi persyaratan traffic pusat data berskala besar. Kami menggunakan PSP untuk mengenkripsi traffic di dalam dan di antara pusat data kami. PSP mendukung protokol non-TCP seperti UDP dan menggunakan kunci enkripsi untuk setiap koneksi Lapisan 4.
Untuk informasi selengkapnya tentang cara kami menggunakan PSP, lihat Mengumumkan pengurangan beban hardware kriptografis PSP dalam skala besar kini bersifat open source.
Protokol ALTS
ALTS memiliki protokol handshake aman yang mirip dengan TLS. Dua layanan yang ingin berkomunikasi menggunakan ALTS memanfaatkan protokol handshake ini untuk mengautentikasi dan menegosiasikan parameter komunikasi sebelum mengirim informasi sensitif apa pun. Protokol ini merupakan proses dua langkah:
- Langkah 1:Handshake Klien memulai handshake Diffie Hellman berbasis kurva eliptik (ECDH) dengan server menggunakan Curve25519. Klien dan server telah melakukan sertifikasi parameter publik ECDH sebagai bagian dari sertifikat mereka, yang digunakan selama pertukaran kunci Diffie Hellman. Handshake menghasilkan kunci traffic umum yang tersedia di klien dan server. Identitas pembanding dari sertifikat ditampilkan ke lapisan aplikasi untuk digunakan dalam keputusan otorisasi.
- Langkah 2: Rekam enkripsi Dengan kunci traffic umum dari Langkah 1, data dikirim dari klien ke server dengan aman. Enkripsi di ALTS diimplementasikan menggunakan BoringSSL dan library enkripsi lainnya. Enkripsi umumnya menggunakan AES-128-GCM, sedangkan integritas disediakan oleh GMAC AES-GCM.
Diagram berikut menunjukkan proses handshake ALTS secara mendetail. Dalam implementasi yang lebih baru, helper proses melakukan handshake; masih ada beberapa kasus di mana proses ini dilakukan langsung oleh aplikasi.
Gambar 5: Handshake ALTS
Seperti yang dijelaskan di awal bagian Autentikasi, integritas, dan enkripsi layanan-ke-layanan, ALTS menggunakan akun layanan untuk autentikasi, dengan setiap layanan di infrastruktur Google berjalan sebagai identitas layanan dengan kredensial kriptografis terkait. Selama handshake ALTS, helper proses mengakses kunci pribadi dan sertifikat yang sesuai yang digunakan setiap pasangan klien-server dalam komunikasi. Kunci pribadi dan sertifikat yang sesuai (ditandatangani)buffering protokol yang ditandatangani) telah disediakan untuk identitas akun layanan.
Sertifikat ALTS Ada beberapa jenis sertifikat ALTS:
- Sertifikat mesin: memberikan identitas untuk layanan inti di mesin tertentu. Sertifikat ini dirotasi sekitar 6 jam sekali.
- Sertifikat pengguna: memberikan identitas pengguna akhir untuk kode yang dikembangkan oleh engineer Google. Sertifikat ini dirotasi sekitar 20 jam sekali.
- Sertifikat tugas Borg: memberikan identitas ke tugas yang berjalan dalam infrastruktur Google. Sertifikat ini dirotasi sekitar 48 jam sekali.
Kunci penandatanganan sertifikasi root disimpan di certificate authority (CA) internal Google, yang tidak terkait dan terpisah dari CA eksternal kami.
Enkripsi dalam ALTS
Enkripsi dalam ALTS dapat diimplementasikan menggunakan berbagai algoritma, bergantung pada mesin yang digunakan. Misalnya, sebagian besar layanan menggunakan AES-128-GCM12. Informasi lebih lanjut tentang enkripsi ALTS dapat ditemukan pada Tabel 2.
| Mesin | Enkripsi pesan yang digunakan | |
|---|---|---|
| Paling umum | AES-128-GCM | |
| Sandy Bridge atau yang lebih lama | AES-128-VCM | Menggunakan VMAC, bukan GMAC, dan sedikit lebih efisien pada mesin lama ini. |
Tabel 2: Enkripsi dalam ALTS
Sebagian besar layanan Google menggunakan ALTS atau enkapsulasi RPC yang menggunakan ALTS. Jika ALTS tidak digunakan, perlindungan lain akan digunakan. Contoh:
- Beberapa layanan pengelolaan mesin dan bootstrap level rendah menggunakan SSH
- Beberapa layanan logging infrastruktur level rendah menggunakan TLS atau Datagram TLS (DTLS)13
- Beberapa layanan yang menggunakan transport non-TCP menggunakan protokol kriptografi lain atau perlindungan tingkat jaringan saat berada di dalam batas fisik yang dikontrol oleh atau atas nama Google
Komunikasi antara VM dan layanan Google Cloud Platform menggunakan TLS untuk berkomunikasi dengan Google Front End, bukan ALTS. Kami menjelaskan komunikasi ini dalam Enkripsi virtual machine ke Google Front End.
Mengonfigurasi opsi lain enkripsi dalam pengiriman
Anda dapat mengonfigurasi perlindungan untuk data saat dalam pengiriman antara Google Cloud dan pusat data Anda, atau saat dalam pengiriman antar-aplikasi yang dihosting di Google Cloud dan perangkat pengguna.
Jika Anda menghubungkan pusat data ke Google Cloud, pertimbangkan hal berikut:
- Gunakan TLS dengan Load Balancer Aplikasi eksternal atau Load Balancer Jaringan proxy eksternal untuk terhubung ke layanan cloud Anda. GFE menghentikan koneksi TLS dari pengguna menggunakan sertifikat SSL yang Anda sediakan dan kontrol. Untuk informasi selengkapnya tentang cara menyesuaikan sertifikat, lihat Ringkasan sertifikat SSL.
- Buat tunnel IPSec menggunakan Cloud VPN atau gunakan Cloud Interconnect untuk menghubungkan jaringan lokal ke jaringan Virtual Private Cloud dengan aman. Untuk informasi selengkapnya, lihat Memilih produk Network Connectivity.
- Gunakan MACsec untuk Cloud Interconnect guna membantu mengamankan traffic antara router lokal dan router edge Google. Untuk mengetahui informasi selengkapnya, lihat Ringkasan MACsec untuk Cloud Interconnect.
Jika Anda menghubungkan perangkat pengguna ke aplikasi yang berjalan di Google Cloud, pertimbangkan hal berikut:
- Gunakan dukungan TLS untuk GFE dengan mengonfigurasi sertifikat SSL yang Anda gunakan. Misalnya, Anda dapat menghentikan sesi TLS di aplikasi Anda.
- Pertimbangkan sertifikat SSL gratis dan otomatis kami, yang tersedia untuk domain kustom Firebase Hosting dan App Engine. Dengan domain kustom App Engine, Anda juga dapat menyediakan sertifikat SSL sendiri dan menggunakan header HTTP Strict Transport Security (HSTS).
- Untuk workload di GKE dan Compute Engine, pertimbangkan mesh layanan GKE Enterprise agar Anda dapat menggunakan mTLS untuk autentikasi, yang memastikan bahwa semua komunikasi TCP dienkripsi dalam pengiriman.
Jika Anda menggunakan Google Workspace, konfigurasikan Gmail guna mengaktifkan S/MIME untuk email keluar, siapkan kebijakan untuk kepatuhan konten dan lampiran, serta buat aturan pemilihan rute untuk email masuk dan keluar.
Penelitian dan inovasi untuk enkripsi dalam pengiriman
Selama bertahun-tahun, kami telah terlibat dalam beberapa project open source dan upaya lain yang mendorong penggunaan enkripsi dalam pengiriman di internet.
Upaya tersebut mencakup:
- Transparansi Sertifikat (CT) adalah upaya yang kami luncurkan agar operator situs dan pemegang domain dapat mendeteksi apakah CA telah menerbitkan sertifikat yang tidak sah atau salah.
- Laporan Transparansi HTTPS tahunan kami melacak progres kami dalam mencapai sasaran 100% enkripsi dalam pengiriman untuk semua properti kami, termasuk Google Cloud.
- Pengembangan kombinasi algoritma kurva eliptik dan pasca-kuantum (CECPQ2), yang membantu melindungi koneksi TLS dari serangan komputer kuantum.
Untuk informasi selengkapnya tentang kontribusi terbaru kami, lihat Kolaborasi dengan komunitas riset keamanan.
Langkah berikutnya
- Untuk mengetahui informasi umum tentang keamanan Google Cloud, termasuk praktik terbaik keamanan, lihat bagian Keamanan di situs Google Cloud.
- Untuk informasi tentang kepatuhan Google Cloud Platform dan sertifikasi kepatuhan, lihat bagian Kepatuhan di situs Google Cloud Platform, yang mencakup laporan audit SOC3 publik Google.
- Untuk mengetahui praktik terbaik tentang cara mengamankan data dalam pengiriman, lihat blueprint fondasi perusahaan dan Framework Arsitektur Google Cloud: Keamanan, privasi, dan kepatuhan, dan Menentukan cara memenuhi persyaratan peraturan untuk enkripsi dalam pengiriman.