Dokumen ini memberikan detail tentang enkripsi dalam pengiriman Google Distributed Cloud (GDC) dengan air gap.
Ringkasan level-CIO
- GDC menggunakan beberapa langkah keamanan untuk membantu memastikan keaslian, integritas, dan kerahasiaan data dalam pengiriman.
- Bergantung pada koneksi yang dibuat, GDC menerapkan perlindungan default terhadap data dalam pengiriman untuk komponen GDC. Misalnya, kami mengamankan komunikasi antara pengguna dan GDC Cloud Service Mesh Ingress Gateway menggunakan TLS.
Pengantar
Keamanan sering kali menjadi faktor penentu saat memilih penyedia cloud. Di Google, keamanan adalah yang paling penting. Kami bekerja tanpa lelah untuk melindungi data Anda, baik saat data tersebut dipindahkan melalui jaringan Anda, 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 Distributed Cloud air-gapped (GDC).
Untuk data dalam penyimpanan, lihat Enkripsi dalam Penyimpanan. 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 GDC.
Prasyarat: selain pengantar ini, kami berasumsi sudah ada pemahaman dasar tentang enkripsi dan primitif kriptografi.
Autentikasi, integritas, dan enkripsi
GDC menggunakan beberapa langkah keamanan untuk membantu memastikan keaslian, integritas, dan kerahasiaan data dalam pengiriman.
- Autentikasi: kami mengautentikasi tujuan data di lapisan jaringan. Sumber diautentikasi oleh AIS yang dikelola GDC.
- Integritas: kami memastikan data yang Anda kirim tiba di tujuannya tanpa perubahan, yang dilindungi dari perubahan yang tidak sah.
- Enkripsi: kami membuat data Anda tidak dapat dibaca saat dalam pengiriman agar data tersebut tetap rahasia. 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 mengetahui informasi selengkapnya tentang enkripsi, lihat Pengantar Kriptografi Modern.
Enkripsi dapat digunakan untuk melindungi data dalam beberapa 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) sering digunakan untuk mengenkripsi data dalam pengiriman untuk keamanan transportasi, dan Secure/Multipurpose Internet Mail Extensions (S/MIME) sering digunakan untuk enkripsi pesan email.
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 GDC terhadap enkripsi data dalam pengiriman dan tempat enkripsi tersebut diterapkan.
Infrastruktur jaringan GDC
Batas fisik
Batas fisik adalah penghalang ke ruang fisik yang dikontrol oleh atau berkoordinasi dengan Google, tempat kami dapat memastikan bahwa langkah-langkah keamanan yang ketat diterapkan. Akses fisik ke lokasi ini dibatasi, dipantau secara ketat, dan diaudit. Hanya sebagian kecil personel yang disetujui yang memiliki akses ke hardware. Data dalam pengiriman yang ada dalam batas fisik ini umumnya diautentikasi dan dienkripsi.
Untuk komunikasi yang masuk atau keluar dari batas fisik GDC, kami menggunakan autentikasi dan enkripsi yang kuat untuk melindungi data dalam pengiriman.
Cara perutean lalu lintas
Untuk memahami cara kerja enkripsi dalam pengiriman di GDC, Anda perlu menjelaskan cara perutean traffic ke dan melalui GDC. Bagian ini menjelaskan cara pengiriman permintaan dari pengguna akhir ke layanan GDC atau aplikasi pelanggan yang sesuai, dan cara perutean traffic antar-layanan lintas situs.
Layanan yang dikelola GDC adalah layanan cloud pribadi modular. Layanan ini mencakup komputasi, penyimpanan, dan machine learning. Misalnya, penyimpanan objek GDC adalah layanan yang dikelola GDC. Aplikasi pelanggan adalah aplikasi yang dihosting di GDC. Sebagai pelanggan GDC, Anda dapat membuat dan men-deploy aplikasi tersebut menggunakan layanan GDC. Aplikasi pelanggan atau solusi partner yang dihosting di GDC tidak dianggap sebagai layanan yang dikelola GDC. Misalnya, aplikasi yang Anda buat menggunakan VM GDC, Database Service, dan Vertex AI adalah aplikasi pelanggan.
Gambar 1 menunjukkan berbagai jenis permintaan pemilihan rute. Gambar 1 menunjukkan interaksi antara berbagai komponen jaringan, dan keamanan yang ada untuk setiap koneksi.
Gambar 1: Infrastruktur konektivitas antar-situs
Pengguna akhir (jaringan pelanggan) ke GDC API dan layanan terkelola
Untuk layanan terkelola yang dihosting di Gateway Ingress Cloud Service Mesh, layanan tersebut menerima permintaan dari jaringan pelanggan menggunakan Gateway Ingress Cloud Service Mesh. Gateway Ingress Cloud Service Mesh mem-proxy traffic untuk HTTP(S) yang masuk, serta merutekan dan melakukan load balancing traffic ke layanan yang dikelola GDC itu sendiri. Lapisan firewall lainnya menyediakan penanggulangan serangan DDoS dengan deteksi dan pencegahan intrusi. Koneksi ini diautentikasi dan dienkripsi dari Cloud Service Mesh Ingress Gateway ke frontend layanan yang dikelola GDC. Gambar 1 menunjukkan interaksi ini sebagai koneksi A.
Sebagian besar API GDC dan layanan terkelola dihosting di Gateway Ingress Cloud Service Mesh. Namun, beberapa layanan dihosting langsung di load balancer Layer 4 yang dikelola GDC. Misalnya, database DBS dihosting di load balancer eksternal GDC. Layanan ini dikonfigurasi untuk mengautentikasi dan mengenkripsi koneksi di lapisan aplikasi menggunakan TLS. Gambar 1 menunjukkan interaksi ini sebagai koneksi B.
Pengguna akhir (jaringan pelanggan) ke aplikasi pelanggan yang dihosting di GDC
Ada beberapa cara untuk merutekan traffic dari jaringan pelanggan ke aplikasi pelanggan yang dihosting di GDC. Cara traffic Anda dirutekan bergantung pada konfigurasi Anda.
Mengekspos aplikasi pelanggan melalui Gateway API pelanggan
GDC mendukung ekspos aplikasi pelanggan melalui Gateway API pelanggan. Layanan API Gateway pelanggan memungkinkan pengguna mengembangkan, men-deploy, mengamankan, mengelola, dan menskalakan API sesuai kebutuhan. Gambar 1 menunjukkan interaksi ini sebagai koneksi C.
Mengekspos workload pelanggan yang di-container melalui load balancer eksternal pelanggan
GDC mendukung pemaparan beban kerja yang di-container dan dikelola oleh pelanggan melalui load balancer eksternal. GDC memberikan kemampuan untuk mengonfigurasi kebijakan traffic masuk dan keluar kepada personel yang sesuai. Gambar 1 menunjukkan interaksi ini sebagai koneksi E.
Mengekspos workload virtual machine
GDC mendukung pengeksposan Virtual Machine yang dibuat pelanggan kepada pengguna akhir. GDC memberikan kemampuan untuk mengonfigurasi kebijakan traffic masuk dan keluar kepada personel yang sesuai. Gambar 1 menunjukkan interaksi ini sebagai koneksi F.
Layanan cross-site interconnect GDC
Pemilihan rute dari satu layanan terkelola ke layanan terkelola lainnya biasanya terjadi sepenuhnya dalam batas fisik GDC. Dalam beberapa kasus, seperti pencadangan lintas situs, data dirutekan di luar batas fisik GDC. Dalam hal ini, data dienkripsi di lapisan aplikasi, misalnya, TLS, dan juga dapat dienkripsi di lapisan jaringan. Gambar 1 menunjukkan interaksi ini sebagai koneksi G.
Mesin virtual ke mesin virtual
Koneksi VM-ke-VM dalam GDC tidak dienkripsi di tingkat jaringan. Pelanggan bertanggung jawab untuk mengenkripsi data menggunakan protokol terenkripsi yang sesuai atau teknologi tertentu seperti tunnel IPSec.
Enkripsi saat transit secara default
GDC 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. Bagian ini menjelaskan perlindungan default yang digunakan Google untuk melindungi data dalam pengiriman.
Selanjutnya, bagian ini menjelaskan perlindungan default yang digunakan Google untuk melindungi data dalam pengiriman.
Enkripsi Pengguna ke Cloud Service Mesh Ingress Gateway
Saat ini, banyak sistem menggunakan HTTPS untuk berkomunikasi melalui Internet. HTTPS memberikan keamanan dengan menggunakan koneksi TLS, yang memastikan keaslian, integritas, dan kerahasiaan permintaan dan respons. Untuk menerima permintaan HTTPS, penerima memerlukan pasangan kunci publik-pribadi dan sertifikat X.509 untuk autentikasi server dari Certificate Authority (CA). Pasangan kunci dan sertifikat membantu mengautentikasi permintaan pengguna di lapisan aplikasi (lapisan 7) dengan membuktikan bahwa penerima memiliki nama domain yang dimaksudkan untuk permintaan tersebut. Subbagian berikut membahas komponen enkripsi pengguna ke Cloud Service Mesh Ingress Gateway, yaitu: TLS, BoringSSL, dan Certificate Authority yang Dapat Dikonfigurasi GDC.
Transport Layer Security (TLS)
Saat Anda mengirim permintaan ke layanan GDC, kami mengamankan data dalam pengiriman; memberikan autentikasi, integritas, dan enkripsi, menggunakan HTTPS dengan sertifikat dari certificate authority tepercaya. Semua data yang dikirim pengguna ke Cloud Service Mesh Ingress Gateway untuk layanan yang dikelola GDC dienkripsi saat dalam pengiriman dengan transport layer security (TLS). Cloud Service Mesh Ingress Gateway menegosiasikan protokol enkripsi tertentu dengan klien, bergantung pada apa yang dapat didukung klien. GDC Cloud Service Mesh Ingress Gateway hanya menerapkan algoritma yang disetujui FIPS untuk memberikan keamanan yang lebih kuat.
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 Gateway Ingress Cloud Service Mesh diimplementasikan dengan BoringSSL. Tabel 1 menunjukkan protokol enkripsi yang didukung GDC 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 |
Tabel 1: Enkripsi yang Diimplementasikan di Gateway Ingress Cloud Service Mesh untuk Layanan GDC dan Diimplementasikan di Library Kriptografi BoringSSL
Certificate Authority yang dapat dikonfigurasi GDC
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 koneksi. Hasilnya, pengguna yang meminta koneksi ke server hanya perlu memercayai CA root. Jika server ingin diakses di mana-mana, CA root harus diketahui oleh setiap perangkat klien prospektif. Browser dan perangkat klien dikonfigurasi dengan serangkaian CA root yang dipercayai, berdasarkan lingkungan tempat klien beroperasi.
CA root untuk GDC bergantung pada lingkungan tempat CA tersebut di-deploy, dan persyaratan pelanggan di lingkungan tersebut.
Cloud Service Mesh Ingress Gateway ke front-end aplikasi
Dua kasus:
- Cloud Service Mesh Ingress Gateway menghentikan TLS, mengenkripsi ulang mTLS menggunakan sertifikat Istio Cloud Service Mesh
- mTLS dari Ingress Gateway ke Frontend Aplikasi Sidecar Istio
- Cloud Service Mesh Ingress Gateway menghentikan TLS, mengenkripsi ulang TLS ke server lain, dengan CA yang dikonfigurasi.
Enkripsi jaringan traffic penyimpanan
Dalam sistem penyimpanan file dan blok GDC, traffic dirutekan antara aplikasi yang menggunakan penyimpanan dan layanan penyimpanan. Data tersebut diautentikasi dan dienkripsi saat dalam pengiriman menggunakan IPSec. Enkripsi sisi klien untuk traffic penyimpanan akan segera tersedia. Mode transport IPSec digunakan antara traffic file dan blok ke host yang perlu mengakses penyimpanan. Autentikasi dilakukan dengan pre-shared key yang dibuat saat penerbangan dan disimpan dengan aman di GDC. Setelah SA IPSec dibuat, informasi akan dipertukarkan menggunakan tunnel IPSec. Paket dienkripsi dan didekripsi menggunakan kripto enkripsi yang mematuhi FIPS yang ditentukan dalam SA IPSec.
Enkripsi, integritas, dan autentikasi layanan-ke-layanan
Dalam infrastruktur GDC, pada lapisan aplikasi (lapisan 7), kami menggunakan mTLS atau TLS untuk autentikasi, integritas, dan enkripsi panggilan RPC dari Cloud Service Mesh Ingress Gateway ke layanan dan dari satu layanan GDC ke layanan GDC lainnya. Setiap layanan yang berjalan di GDC berjalan sebagai identitas akun layanan dengan kredensial kriptografis terkait. Saat berkomunikasi melalui mTLS melalui Cloud Service Mesh, layanan GDC menggunakan sertifikat klien untuk melakukan autentikasi ke layanan lain. Cloud Service Mesh memverifikasi sertifikat ini menggunakan certificate authority internal. Saat berkomunikasi melalui TLS, misalnya, ke Server API Kubernetes GDC, layanan GDC menggunakan token akun layanan Kubernetes untuk mengautentikasi layanan. Token akun layanan Kubernetes diverifikasi menggunakan kunci publik penerbit token Server API Kubernetes.