Mengapa Google Cloud Compute?
Sebagian besar perusahaan menggunakan data center karena menawarkan prediktabilitas biaya, kepastian perangkat keras, dan kontrol. Namun, menjalankan dan memelihara sumber daya di data center juga membutuhkan banyak biaya, termasuk:
Kapasistas: sumber daya yang cukup untuk menskalakan sesuai kebutuhan, dan penggunaan sumber daya tersebut secara efisien.
Keamanan: keamanan fisik untuk melindungi aset, serta keamanan tingkat jaringan dan OS.
Infrastruktur jaringan: komponen seperti kabel, sakelar, router, firewall, dan penyeimbang beban.
Dukungan: karyawan yang terampil untuk melakukan instalasi dan pemeliharaan dan untuk mengatasi masalah.
Bandwidth: bandwidth yang sesuai untuk beban puncak.
Sarana: Prasarana fisik, termasuk peralatan dan tenaga listrik.
Platform cloud berfitur lengkap seperti Cloud Platform membantu menghilangkan banyak overhead seputar masalah fisik, logistik, dan terkait sumber daya manusia ini, dan dapat membantu mengurangi banyak biaya bisnis terkait dalam prosesnya. Karena Cloud Platform dibangun di atas infrastruktur Google, Cloud Platform juga menawarkan manfaat tambahan yang biasanya berbiaya mahal di pusat data tradisional, termasuk:
Jaringan global
Redundansi multi-regional yang terintegrasi
Beberapa kawasan dan zona pusat data di seluruh dunia membantu memastikan redundansi dan ketersediaan yang kuat. Hal ini sangat penting ketika terdapat kebutuhan khusus geografis dan internasional untuk perluasan / pengembangan zona geografis dan multi-zona.
Penskalaan yang cepat dan dapat diandalkan
Cloud Platform dirancang untuk menyesuaikan skala seperti produk Google sendiri, bahkan saat Anda mengalami lonjakan lalu lintas yang besar. Layanan terkelola seperti Google App Engine, penghitung skala otomatis Google Compute Engine, dan Google Cloud Datastore memberi Anda penskalaan otomatis yang membantu aplikasi Anda berkembang dan menyusut kapasitasnya sesuai kebutuhan.
Kapasitas dan bandwidth
Di data center tradisional, Anda harus merencanakan kebutuhan sumber daya, memperoleh sumber daya yang cukup di awal sesuai kebutuhan, dan mengelola kapasitas dan distribusi beban kerja dengan hati-hati dalam batas sumber daya tersebut. Karena sifat sumber daya yang disediakan sebelumnya, tidak peduli seberapa hati-hati Anda mengelola kapasitas, Anda mungkin akan berakhir dengan pemanfaatan yang kurang optimal:
Gambar 1: Pemanfaatan sumber daya yang disediakan sebelumnya dari waktu ke waktu
Selain itu, pra-penyediaan sumber daya ini berarti Anda memiliki batas atas sumber daya. Jika Anda perlu mengukur lebih dari itu, Anda kurang beruntung.
Cloud Platform membantu menyelesaikan banyak dari masalah pemanfaatan dan ambang skalabilitas ini. Anda dapat meningkatkan dan menurunkan skala instance VM Anda sesuai kebutuhan. Karena Anda membayar untuk apa yang Anda gunakan dengan basis per detik, Anda dapat mengoptimalkan biaya tanpa harus membayar kelebihan kapasitas yang tidak Anda perlukan sepanjang waktu, atau hanya perlu pada waktu lalu lintas padat.
Keamanan
Model keamanan Google adalah proses hulu ke hilir, dibangun di atas pengalaman lebih dari 18 tahun yang berfokus pada menjaga keamanan pelanggan di aplikasi Google seperti Gmail dan Google Apps. Selain itu, tim teknisi keandalan situs Google mengawasi operasi sistem platform untuk membantu memastikan ketersediaan yang tinggi, dan mencegah penyalahgunaan sumber daya platform.
Infrastruktur jaringan
Di pusat data tradisional, Anda mengelola penyiapan jaringan yang kompleks, termasuk rak server, penyimpanan, beberapa lapisan sakelar, penyeimbang beban, router, dan perangkat firewall. Anda harus mengatur, memelihara, dan memantau perangkat lunak dan konfigurasi perangkat secara rinci. Selain itu, Anda harus mengkhawatirkan keamanan dan ketersediaan jaringan Anda, dan Anda harus menambah serta meningkatkan peralatan seiring dengan pertumbuhan kebutuhan jaringan Anda.
Sebaliknya, Cloud Platform menggunakan model jaringan yang ditentukan perangkat lunak (SDN) , memungkinkan Anda untuk mengkonfigurasi jaringan Anda sepenuhnya melalui API layanan dan antarmuka pengguna Cloud Platform. Anda tidak perlu membayar atau mengelola perangkat keras jaringan pusat data. Untuk detail lebih lanjut tentang tumpukan SDN Google, Andromeda, lihat entri blog Memasukkan zona Andromeda .
Fasilitas dan dukungan
Saat Anda menggunakan Cloud Platform, Anda tidak perlu lagi khawatir tentang menginstal atau memelihara perangkat keras pusat data fisik, Anda juga tidak perlu khawatir memiliki teknisi ahli untuk melakukannya. Google menangani lapisan perangkat keras dan teknisi, memungkinkan Anda untuk fokus menjalankan aplikasi Anda.
Pemenuhan
Google melakukan audit pihak ketiga independen secara berkala untuk memverifikasi bahwa Cloud Platform sejalan dengan kontrol keamanan, privasi, dan kepatuhan. Cloud Platform memiliki audit rutin untuk standar seperti ISO 27001, ISO 27017, ISO 27018, SOC 2, SOC 3, dan PCI DSS.
Berfokus pada manfaat Keamanan
Ekonomi dunia menderita kerugian miliaran dolar karena pembobolan data, pencurian, atau perusakan setiap tahun. Karena alasan ini, pelaku utama industri Cloud dan GCP telah berupaya keras untuk mencapai kepatuhan dengan standar bereputasi seperti:
FIPS 140-2
ISO/IEC 27001
PCI DSS
ISO 27017
ISO 27018, SOC 2, SOC 3
Enkripsi semua data saat istirahat dan saat transit
Google Cloud Computing telah menghasilkan jutaan dolar investasi selama beberapa tahun terakhir ini sehingga dapat sesuai dengan FIPS level 1, seperti yang Anda dapat memeriksanya di sini dan di sini.
Sebagai pengingat, FIPS adalah Standar Pemrosesan Informasi Federal, yang merupakan salah satu yang paling menuntut di dunia, awalnya dibuat oleh pemerintah Amerika untuk menjaga rahasia dan infrastruktur mereka tetap aman.
Hal berikut diterapkan oleh GCP dan kemungkinan besar TIDAK diterapkan pada tingkat jaringan lokal dari "penginstalan lokal":
| Teknologi | Google Cloud Compute | Penerapan standar perusahaan lakukan sendiri |
| Produk penyimpanan SSD lokal secara otomatis dienkripsi dengan cipher yang disetujui NIST | Diterapkan di semua penyimpanan | Jarang diterapkan |
| Enkripsi otomatis lalu lintas antara lokasi data internal dan eksternal menggunakan algoritma enkripsi yang disetujui NIST. | Diterapkan pada semua transfer data | Jarang diterapkan |
| Ketika klien terhubung ke infrastruktur, klien TLS mereka harus dikonfigurasi untuk meminta penggunaan algoritme aman yang sesuai FIPS; jika klien TLS dan pemilik infrastruktur layanan TLS menyetujui metode enkripsi yang tidak kompatibel dengan FIPS, implementasi enkripsi yang tidak divalidasi akan digunakan. | Diterapkan pada semua koneksi | SANGAT Jarang diterapkan |
| Aplikasi yang Anda bangun dan operasikan pada infrastruktur produksi mungkin menyertakan implementasi kriptografinya sendiri; agar data yang mereka proses diamankan dengan modul kriptografi yang divalidasi FIPS, Anda harus mengintegrasikan sendiri penerapan tersebut. | Siap digunakan | SANGAT Jarang diterapkan |
Lingkungan Google Cloud dan enkripsi saat tidak digunakan
CIO level
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Google menggunakan beberapa lapisan enkripsi untuk melindungi data pelanggan yang tersimpan di produk Google Cloud Platform. | Diterapkan sebagai Standar | Jarang diterapkan |
| Google Cloud Platform mengenkripsi konten pelanggan yang disimpan saat tidak digunakan, tanpa tindakan apa pun yang diperlukan dari pelanggan, menggunakan satu atau beberapa mekanisme enkripsi. Ada beberapa pengecualian kecil, yang dijelaskan lebih lanjut dalam dokumen ini. | Diterapkan sebagai Standar | Jarang diterapkan |
| Data untuk penyimpanan dibagi menjadi beberapa bagian, dan setiap bagian dienkripsi dengan kunci enkripsi data yang unik. Kunci enkripsi data ini disimpan dengan data, dienkripsi dengan ("dibungkus" oleh) kunci enkripsi kunci yang secara eksklusif disimpan dan digunakan di dalam Layanan Manajemen Kunci pusat Google. Layanan Manajemen Kunci Google redundan dan didistribusikan secara global. | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
| Data yang disimpan di Google Cloud Platform dienkripsi di tingkat penyimpanan menggunakan AES256 atau AES128. | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
| Google menggunakan pustaka kriptografi umum, Tink, untuk menerapkan enkripsi secara konsisten di hampir semua produk Google Cloud Platform. Karena pustaka umum ini dapat diakses secara luas, hanya tim kecil kriptografer yang perlu menerapkan dan memelihara kode yang dikontrol dan ditinjau ini dengan benar. | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
Lapisan enkripsi
Google menggunakan beberapa lapisan enkripsi untuk melindungi data. Menggunakan beberapa lapisan enkripsi menambahkan perlindungan data yang berlebihan dan memungkinkan kami memilih pendekatan yang optimal berdasarkan persyaratan aplikasi.
Setiap potongan didistribusikan ke seluruh sistem penyimpanan Google dan direplikasi dalam bentuk terenkripsi untuk pencadangan dan pemulihan dari bencana. Seorang individu jahat yang ingin mengakses data pelanggan perlu mengetahui dan dapat mengakses (1) semua potongan penyimpanan yang sesuai dengan data yang mereka inginkan, dan (2) kunci enkripsi yang sesuai dengan potongan tersebut.
Google menggunakan algoritme Advanced Encryption Standard (AES) untuk mengenkripsi data saat tidak digunakan. AES banyak digunakan karena (1) AES256 dan AES128 direkomendasikan oleh National Institute of Standards and Technology (NIST) untuk penggunaan penyimpanan jangka panjang (per Maret 2019), dan (2) AES sering disertakan sebagai bagian dari pelanggan persyaratan kepatuhan.
Data yang disimpan di Google Cloud Storage dienkripsi di tingkat penyimpanan menggunakan AES, dalam Galois / Counter Mode (GCM) di hampir semua kasus. Ini diterapkan di pustaka BoringSSL yang dikelola Google. Pustaka ini bercabang dari OpenSSL untuk penggunaan internal, setelah banyak kekurangan terekspos di OpenSSL. Dalam kasus tertentu, AES digunakan dalam mode Cipher Block Chaining (CBC) dengan kode otentikasi pesan berciri (HMAC) untuk otentikasi; dan untuk beberapa file yang direplikasi, AES digunakan dalam mode Counter (CTR) dengan HMAC. (Detail lebih lanjut tentang algoritme akan diberikan nanti dalam dokumen ini.) Pada produk Google Cloud Platform lainnya, AES digunakan dalam berbagai mode.
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Enkripsi multi-lapis asli | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Enkripsi AES asli dengan mode CTR | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| GCM asli | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
Enkripsi di lapisan perangkat penyimpanan
Selain enkripsi tingkat sistem penyimpanan yang dijelaskan di atas, dalam banyak kasus, data juga dienkripsi di tingkat perangkat penyimpanan, dengan setidaknya AES128 untuk hard disk (HDD) dan AES256 untuk solid-state drive (SSD) baru, menggunakan perangkat terpisah -tingkat kunci (yang berbeda dari kunci yang digunakan untuk mengenkripsi data di tingkat penyimpanan). Saat perangkat lama diganti, hanya AES256 yang akan digunakan untuk enkripsi tingkat perangkatEnkripsi cadangan
Sistem cadangan Google memastikan bahwa data tetap terenkripsi selama proses pencadangan. Pendekatan ini menghindari pemaparan data teks biasa yang tidak perlu.Selain itu, sistem cadangan mengenkripsi lebih lanjut setiap file cadangan secara independen dengan kunci enkripsi datanya (DEK) sendiri, yang berasal dari kunci yang disimpan di Layanan Manajemen Kunci (KMS) Google ditambah benih per file yang dibuat secara acak pada waktu pencadangan. DEK lain digunakan untuk semua metadata dalam backup, yang juga disimpan di KMS Google.
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Dengan cepat, enkripsi aliran cadangan | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
| Enkripsi Cadangan Penyimpanan | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
Manajemen Kunci oleh GCP
Kunci yang digunakan untuk mengenkripsi data dalam potongan disebut kunci enkripsi data (DEK). Karena tingginya volume kunci di Google, dan kebutuhan akan latensi rendah dan ketersediaan tinggi, kunci ini disimpan di dekat data yang dienkripsi. DEK dienkripsi dengan (atau "dibungkus" oleh) kunci enkripsi kunci (KEK). Ada satu atau beberapa KEK untuk setiap layanan Google Cloud Platform. KEK ini disimpan secara terpusat di Layanan Manajemen Kunci (KMS) Google, sebuah repositori yang dibuat khusus untuk menyimpan kunci. Memiliki jumlah KEK yang lebih kecil daripada DEK dan menggunakan layanan manajemen kunci pusat membuat penyimpanan dan enkripsi data pada skala Google dapat dikelola, dan memungkinkan kami untuk melacak dan mengontrol akses data dari titik pusat.
Untuk setiap pelanggan Google Cloud Platform, resource yang tidak dibagikan dibagi menjadi beberapa bagian data dan dienkripsi dengan kunci yang terpisah dari kunci yang digunakan untuk pelanggan lain. DEK ini bahkan terpisah dari DEK yang melindungi bagian lain dari data yang sama yang dimiliki oleh pelanggan yang sama.
DEK dibuat oleh sistem penyimpanan menggunakan pustaka kriptografi umum Google. Mereka kemudian dikirim ke KMS untuk dibungkus dengan KEK sistem penyimpanan itu, dan DEK yang dibungkus diteruskan kembali ke sistem penyimpanan untuk disimpan dengan potongan data. Saat sistem penyimpanan perlu mengambil data terenkripsi, sistem tersebut mengambil DEK yang dibungkus dan meneruskannya ke KMS. KMS kemudian memverifikasi bahwa layanan ini diizinkan untuk menggunakan KEK, dan jika demikian, membuka bungkusan dan mengembalikan DEK teks biasa ke layanan. Layanan kemudian menggunakan DEK untuk mendekripsi potongan data menjadi teks biasa dan memverifikasi integritasnya.
Sebagian besar KEK untuk mengenkripsi potongan data dibuat di dalam KMS, dan sisanya dibuat di dalam layanan penyimpanan. Untuk konsistensi, semua KEK dibuat menggunakan pustaka kriptografi umum Google, menggunakan pembuat nomor acak (RNG) yang dibuat oleh Google. RNG ini didasarkan pada NIST 800-90Ar1 CTR-DRBG dan menghasilkan AES256 KEK. RNG ini di-seed dari RNG kernel Linux, yang di-seed dari berbagai sumber entropi independen. Ini termasuk peristiwa entropik dari lingkungan pusat data, seperti pengukuran mendetail dari pencarian disk dan waktu kedatangan antar-paket, dan
intruksi RDRAND Intel jika tersedia (di Ivy Bridge dan CPU yang lebih baru).
Data yang disimpan di Google Cloud Platform dienkripsi dengan DEK menggunakan AES256 atau AES128, seperti yang dijelaskan di atas; dan semua data baru yang dienkripsi dalam persistent disk di Google Compute Engine dienkripsi menggunakan AES256. DEK dibungkus dengan KEK menggunakan AES256 atau AES128, bergantung pada layanan Google Cloud Platform. Kami sedang mengerjakan peningkatan semua KEK untuk layanan Cloud ke AES256.
KMS Google mengelola KEK, dan dibuat hanya untuk tujuan ini. Ini dirancang dengan mempertimbangkan keamanan. KEK tidak dapat diekspor dari KMS Google secara sengaja; semua enkripsi dan dekripsi dengan kunci ini harus dilakukan dalam KMS. Ini membantu mencegah kebocoran dan penyalahgunaan, dan memungkinkan KMS mengeluarkan jejak audit saat kunci digunakan.
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Integrasi KMS | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
| AES256 KEK | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
Jaringan & komunikasi
Manfaat Tingkat Premium
Kepemilikan jaringan penuh dari satu lokasi ke lokasi lain adalah sesuatu yang sebagian besar perusahaan tidak mampu membelinya. Namun, Google Cloud Compute mampu mencapai kepemilikan dan kontrol hulu-ke-hilir penuh.
| Teknologi | Google Cloud Compute | Penerapan standar perusahaan lakukan sendiri |
| Kepemilikan jaringan ujung ke ujung sepenuhnya | Diterapkan sebagai Standar | SANGAT Jarang diterapkan |
| Lebih dari 100 PoP di Seluruh Dunia untuk menawarkan cakupan yang luas dan redundansi / ketahanan jaringan | Dicapai sebagai standar | SANGAT Jarang diterapkan |
Stabilitas operasional / ketenangan / SLA
Standar tinggi di tingkat SLA
Google Cloud Compute adalah salah satu dari sedikit penyedia Cloud yang mampu menawarkan SLA terverifikasi yang unggul hingga 99% di semua layanannya.
| Layanan Tertanggung | Persentase Uptime Bulanan |
| Instance di Beberapa Zona | >= 99.99% |
| Sebuah Instance | >= 99.5% |
| Penyeimbang beban | >= 99.99% |
Jika Google tidak memenuhi Sasaran Tingkat Layanan (SLO), dan jika Pelanggan memenuhi kewajibannya berdasarkan SLA ini, Pelanggan berhak menerima Kredit Keuangan yang dijelaskan di bawah. SLA ini menyatakan upaya hukum satu-satunya dan eksklusif Pelanggan atas kegagalan Google dalam memenuhi SLO. Istilah dalam huruf besar yang digunakan dalam Perjanjian Tingkat Layanan ini, tetapi tidak didefinisikan dalam Perjanjian Tingkat Layanan ini, memiliki arti yang ditetapkan dalam Perjanjian. Jika Perjanjian mengizinkan penjualan kembali atau pasokan Google Cloud Platform di bawah mitra Google Cloud atau program pengecer, maka semua referensi ke Pelanggan dalam SLA ini berarti Mitra atau Pengecer (sebagaimana berlaku), dan Kredit Keuangan apa pun hanya akan berlaku untuk yang terkena dampak Pesanan Mitra atau Pengecer berdasarkan Perjanjian.
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Implementasi instans / server tunggal 99,5% SLA (artinya 354,5 Hari waktu aktif per tahun) | Dicapai sebagai standar | Jarang tercapai |
| Beberapa instans (beban seimbang yang berlebihan) / implementasi server 99,5% SLA (artinya 364,96 Hari waktu aktif per tahun) | Dicapai sebagai standar | SANGAT Jarang tercapai |
| SLA seumur hidup | Dicapai sebagai standar | SANGAT Jarang tercapai |
Standar Ketersediaan Tinggi
Mencapai tujuan ketersediaan 100% menyiratkan bahwa infrastruktur Anda mampu mencapai standar berikut:
| Teknologi | Google Cloud Compute | Penerapan standar lokal |
| Kapasitas perangkat keras yang dikelola sendiri | Diterapkan sebagai Standar | Jarang tercapai |
| Skalabilitas otomatis | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Penyediaan sumber daya otomatis | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Beberapa redundansi (penyimpanan) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Beberapa redundansi (Menghitung instance / Server) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Beberapa redundansi (perangkat dan transportasi jaringan) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Beberapa redundansi (perangkat dan transportasi jaringan) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Beberapa redundansi (penyimpanan) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Teknologi load-balancing | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Replikasi data waktu nyata pada penyimpanan pasif (data / file) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
| Replikasi data waktu nyata pada penyimpanan dinamis (database) | Diterapkan sebagai Standar | SANGAT Jarang tercapai |
Port Cities - Membantu Anda memilih solusi hosting yang paling sesuai untuk bisnis Anda
Port Cities bekerja sama dengan penyedia layanan cloud terbaik di dunia, termasuk Google Cloud Platform, untuk memastikan ERP Anda dapat diakses kapan saja, dari mana saja. Kami juga memastikan solusi hosting kami memenuhi kriteria paling menuntut dari sistem ERP Anda, dalam hal keamanan, kapasitas, atau stabilitas operasional. Bagaimanapun, tim server kami siap berdiskusi dengan Anda tentang solusi hosting server yang paling cocok untuk bisnis Anda.
.
