Tentukan keamanan untuk zona landing Google Cloud Anda

Last reviewed 2023-08-31 UTC

Dokumen ini memperkenalkan keputusan keamanan penting dan opsi yang direkomendasikan untuk dipertimbangkan saat mendesain zona landing Google Cloud. Ini adalah bagian dari rangkaian tentang zona landing, dan ditujukan untuk spesialis keamanan, CISO, dan arsitek yang ingin memahami keputusan yang perlu mereka ambil saat merancang zona landing di Google Cloud.

Dalam dokumen ini, diasumsikan bahwa tim pusat, seperti tim keamanan atau tim platform, yang menerapkan kontrol keamanan zona landing ini. Karena fokus dari dokumen ini adalah desain lingkungan berskala perusahaan, beberapa strategi yang dijelaskan mungkin kurang relevan untuk tim kecil.

Poin keputusan untuk mengamankan zona landing Google Cloud Anda

Untuk memilih desain keamanan terbaik bagi organisasi, Anda harus mengambil keputusan berikut:

Diagram Arsitektur

Contoh arsitektur yang dijelaskan dalam dokumen ini menggunakan pola desain keamanan umum. Kontrol spesifik Anda dapat bervariasi berdasarkan faktor seperti industri organisasi, beban kerja target, atau persyaratan kepatuhan tambahan. Diagram berikut menunjukkan arsitektur kontrol keamanan yang Anda terapkan di zona landing jika Anda mengikuti rekomendasi dalam dokumen ini.

Contoh arsitektur kontrol keamanan.

Diagram sebelumnya menunjukkan hal berikut:

  • Pengelolaan kunci akun layanan membantu memitigasi risiko dari kredensial akun layanan yang aktif dalam waktu lama.
  • Kontrol Layanan VPC menentukan perimeter di sekitar resource sensitif yang membantu membatasi akses dari luar perimeter.
  • Security Command Center memantau lingkungan akan adanya konfigurasi dan ancaman yang tidak aman.
  • Sink log terpusat mengumpulkan log audit dari semua project.
  • Enkripsi dalam penyimpanan default Google mengenkripsi semua data yang tetap tersimpan di disk.
  • Enkripsi dalam pengiriman default Google berlaku untuk jalur jaringan lapisan 3 dan lapisan 4.
  • Transparansi Akses memberi Anda visibilitas dan kontrol atas cara Google dapat mengakses lingkungan Anda.

Menentukan cara membatasi kredensial persisten untuk akun layanan

Akun layanan adalah identitas mesin yang Anda gunakan untuk memberikan peran IAM ke beban kerja dan memungkinkan beban kerja mengakses Google Cloud API. Kunci akun layanan adalah kredensial yang persisten, dan semua kredensial yang persisten berpotensi berisiko tinggi. Sebaiknya jangan izinkan developer membuat kunci akun layanan dengan bebas.

Misalnya, jika developer tidak sengaja meng-commit kunci akun layanan ke repositori Git publik, penyerang eksternal dapat melakukan autentikasi menggunakan kredensial tersebut. Contoh lain, jika kunci akun layanan disimpan di repositori internal, orang dalam berbahaya yang dapat membaca kunci tersebut dapat menggunakan kredensial untuk mengeskalasikan hak istimewa Google Cloud mereka sendiri.

Untuk menentukan strategi untuk mengelola kredensial persisten ini, Anda harus menyediakan alternatif yang valid, membatasi proliferasi kredensial persisten, dan mengelola cara penggunaannya. Untuk mengetahui informasi tentang alternatif kunci akun layanan, lihat Memilih metode autentikasi terbaik untuk kasus penggunaan Anda.

Bagian berikut menjelaskan opsi untuk membatasi kredensial persisten. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah alternatif yang dapat Anda pertimbangkan jika opsi 1 tidak berlaku untuk organisasi tertentu.

Opsi 1: Batasi penggunaan kunci akun layanan persisten

Sebaiknya Anda tidak mengizinkan pengguna untuk mendownload kunci akun layanan karena kunci yang diekspos adalah vektor serangan yang umum. Membatasi penggunaan kunci akun layanan persisten adalah opsi yang dapat membantu mengurangi risiko dan overhead untuk mengelola kunci akun layanan secara manual.

Untuk menerapkan opsi ini, pertimbangkan hal berikut:

  • Untuk mencegah developer membuat dan mendownload kredensial persisten, konfigurasikan batasan kebijakan organisasi constraints/iam.disableServiceAccountKeyCreation.
  • Berikan edukasi kepada tim Anda tentang alternatif yang lebih aman untuk kunci akun layanan. Misalnya, jika pengguna dan aplikasi yang berada di luar lingkungan Google Cloud Anda perlu menggunakan akun layanan, mereka dapat melakukan autentikasi dengan peniruan identitas akun layanan atau beban kerja. gabungan identitas dan bukan kunci akun layanan.
  • Desain sebuah proses bagi tim untuk meminta pengecualian terhadap kebijakan ini jika mendownload kunci akun layanan adalah satu-satunya opsi yang memungkinkan. Misalnya, produk SaaS pihak ketiga mungkin memerlukan kunci akun layanan untuk membaca log dari lingkungan Google Cloud Anda.

Hindari opsi ini jika Anda sudah memiliki alat untuk membuat kredensial API jangka pendek untuk akun layanan.

Untuk informasi selengkapnya, lihat referensi berikut:

Opsi 2: Gunakan alat pengelolaan akses tambahan untuk membuat kredensial jangka pendek

Sebagai alternatif untuk Membatasi penggunaan kunci akun layanan persisten, Anda dapat membuat kredensial jangka pendek untuk akun layanan. Kredensial jangka pendek menimbulkan lebih sedikit risiko dibandingkan kredensial persisten seperti kunci akun layanan. Anda dapat mengembangkan alat Anda sendiri atau menggunakan solusi pihak ketiga seperti Hashicorp Vault untuk membuat kredensial akses jangka pendek.

Gunakan opsi ini jika Anda telah menggunakan alat pihak ketiga untuk membuat kredensial jangka pendek untuk kontrol akses, atau memiliki anggaran dan kapasitas yang memadai untuk mengembangkan solusi Anda sendiri.

Hindari penggunaan opsi ini jika Anda tidak memiliki alat untuk memberikan kredensial jangka pendek, atau tidak memiliki kapasitas untuk membangun solusi Anda sendiri.

Untuk informasi selengkapnya, lihat Membuat kredensial akun layanan jangka pendek.

Menentukan cara memitigasi pemindahan data yang tidak sah melalui Google API

Google API memiliki endpoint publik yang tersedia untuk semua pelanggan. Meskipun setiap resource API di lingkungan Google Cloud Anda tunduk pada kontrol akses IAM, ada risiko bahwa data dapat diakses menggunakan kredensial curian, diambil oleh orang dalam yang berniat jahat atau kode yang telah disusupi, atau terekspos melalui kebijakan IAM yang salah dikonfigurasi.

Kontrol Layanan VPC adalah solusi yang menangani risiko tersebut. Namun, Kontrol Layanan VPC juga menimbulkan kompleksitas pada model akses Anda, sehingga Anda harus mendesain Kontrol Layanan VPC agar sesuai dengan lingkungan dan kasus penggunaan Anda yang unik.

Bagian berikut menjelaskan opsi untuk memitigasi pemindahan data yang tidak sah melalui Google API. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah alternatif yang dapat Anda pertimbangkan jika opsi 1 tidak berlaku untuk kasus penggunaan tertentu Anda.

Opsi 1: Konfigurasikan Kontrol Layanan VPC secara luas di seluruh lingkungan Anda

Sebaiknya desain lingkungan Anda dalam satu atau beberapa perimeter Kontrol Layanan VPC yang membatasi semua API yang didukung. Konfigurasikan pengecualian ke perimeter dengan tingkat akses atau kebijakan ingress sehingga developer dapat mengakses layanan yang mereka perlukan, termasuk akses konsol jika diperlukan.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Layanan yang ingin Anda gunakan mendukung Kontrol Layanan VPC, dan beban kerja Anda tidak memerlukan akses internet tanpa batas.
  • Anda menyimpan data sensitif di Google Cloud yang bisa menjadi kerugian signifikan jika dipindahkan.
  • Anda memiliki atribut yang konsisten untuk akses developer yang dapat dikonfigurasi sebagai pengecualian untuk perimeter, sehingga pengguna dapat mengakses data yang mereka butuhkan.

Hindari opsi ini saat beban kerja Anda memerlukan akses internet tanpa batas atau layanan yang tidak didukung oleh Kontrol Layanan VPC.

Untuk informasi selengkapnya, lihat referensi berikut:

Opsi 2: Konfigurasikan Kontrol Layanan VPC untuk subset lingkungan Anda

Daripada mengonfigurasi Kontrol Layanan VPC secara luas di seluruh lingkungan Anda, Anda dapat mengonfigurasi Kontrol Layanan VPC hanya pada subset project yang berisi data sensitif dan beban kerja khusus internal. Dengan opsi ini, Anda dapat menggunakan desain dan operasi yang lebih sederhana untuk sebagian besar project, sambil tetap memprioritaskan perlindungan data untuk project dengan data sensitif.

Misalnya, Anda dapat mempertimbangkan alternatif ini jika sejumlah project berisi set data BigQuery dengan data sensitif. Anda dapat menentukan perimeter layanan hanya di sekitar project ini, dan menentukan aturan masuk dan keluar untuk memberikan pengecualian yang sempit bagi analis yang perlu menggunakan set data ini.

Untuk contoh lain, dalam aplikasi dengan arsitektur tiga tingkat, beberapa komponen mungkin berada di luar perimeter. Tingkat presentasi yang memungkinkan akses masuk dari traffic pengguna mungkin merupakan project di luar perimeter, dan tingkat aplikasi serta tingkat data yang berisi data sensitif mungkin merupakan project terpisah di dalam perimeter layanan. Anda menentukan aturan traffic masuk dan keluar ke perimeter agar tingkat dapat berkomunikasi ke seluruh perimeter dengan akses terperinci.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Hanya proyek yang terbatas dan terdefinisi dengan baik yang berisi data sensitif. Proyek lain berisi data risiko yang lebih rendah.
  • Beberapa beban kerja hanya bersifat internal, tetapi beberapa beban kerja memerlukan akses internet publik atau memiliki dependensi pada layanan yang tidak didukung oleh Kontrol Layanan VPC.
  • Mengonfigurasi Kontrol Layanan VPC di semua project menghasilkan terlalu banyak overhead atau memerlukan terlalu banyak solusi

Hindari opsi ini jika banyak project yang berpotensi berisi data sensitif.

Untuk mengetahui informasi selengkapnya, lihat Praktik terbaik untuk mengaktifkan Kontrol Layanan VPC.

Opsi 3: Jangan konfigurasikan Kontrol Layanan VPC

Sebagai alternatif lain untuk mengonfigurasi Kontrol Layanan VPC secara luas di seluruh lingkungan Anda, Anda dapat memilih untuk tidak menggunakan Kontrol Layanan VPC, terutama jika overhead operasional melebihi nilai Layanan VPC Kontrol.

Misalnya, organisasi Anda mungkin tidak memiliki pola akses developer yang konsisten yang dapat menjadi dasar kebijakan ingress. Mungkin operasi IT Anda dialihkan ke beberapa pihak ketiga, sehingga developer tidak memiliki perangkat terkelola atau akses dari alamat IP yang konsisten. Dalam skenario ini, Anda mungkin tidak dapat menentukan aturan traffic masuk untuk mengizinkan pengecualian pada perimeter yang diperlukan developer untuk menyelesaikan operasi harian mereka.

Gunakan opsi ini saat:

  • Anda menggunakan layanan yang tidak mendukung Kontrol Layanan VPC.
  • Beban kerja terhubung ke internet dan tidak berisi data sensitif.
  • Anda tidak memiliki atribut akses developer yang konsisten seperti perangkat terkelola atau rentang IP yang diketahui.

Hindari opsi ini jika Anda memiliki data sensitif di lingkungan Google Cloud.

Menentukan cara untuk terus memantau konfigurasi dan ancaman yang tidak aman

Penggunaan layanan cloud memunculkan tantangan dan ancaman baru jika dibandingkan dengan menggunakan layanan yang berada di infrastruktur lokal. Alat yang ada untuk memantau server yang berumur panjang mungkin tidak cocok untuk penskalaan otomatis atau layanan ephemeral, dan mungkin tidak memantau resource serverless sama sekali. Oleh karena itu, Anda harus mengevaluasi alat keamanan yang berfungsi dengan berbagai layanan cloud yang mungkin Anda gunakan. Anda juga harus terus memantau standar cloud yang aman, seperti CIS Benchmarks untuk Google Cloud.

Bagian berikut menjelaskan opsi untuk pemantauan berkelanjutan. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah alternatif yang dapat Anda pertimbangkan jika opsi 1 tidak berlaku untuk kasus penggunaan tertentu Anda.

Opsi 1: Gunakan Security Command Center Premium

Sebaiknya aktifkan paket Premium Security Command Center di level organisasi, yang membantu Anda memperkuat postur keamanan dengan melakukan hal berikut:

  • Mengevaluasi area permukaan serangan data dan keamanan Anda.
  • Menyediakan inventaris dan penemuan aset
  • Mengidentifikasi kesalahan konfigurasi, kerentanan, dan ancaman
  • Membantu Anda memitigasi dan memulihkan risiko

Saat Anda mengaktifkan Security Command Center di awal pembuatan zona landing, tim keamanan organisasi Anda memiliki visibilitas yang mendekati real-time terkait konfigurasi, ancaman, dan opsi perbaikan yang tidak aman. Visibilitas ini membantu tim keamanan Anda menilai apakah zona landing memenuhi persyaratan mereka dan siap bagi developer untuk mulai men-deploy aplikasi.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Anda menginginkan alat pengelolaan postur keamanan dan deteksi ancaman yang terintegrasi dengan semua layanan Google Cloud tanpa upaya integrasi tambahan.
  • Anda ingin menggunakan kecerdasan ancaman, machine learning, dan metode canggih lain yang sama dengan yang digunakan Google untuk melindungi layanannya sendiri.
  • Pusat operasi keamanan (SOC) Anda yang ada tidak memiliki keterampilan atau kapasitas untuk menghasilkan insight ancaman dari log cloud dalam jumlah besar.

Hindari opsi ini jika alat keamanan yang sudah ada dapat sepenuhnya mengatasi resource cloud ephemeral atau serverless, memantau konfigurasi yang tidak aman, dan mengidentifikasi ancaman dalam skala besar di lingkungan cloud.

Opsi 2: Gunakan alat keamanan yang ada untuk pengelolaan postur keamanan cloud dan deteksi ancaman

Sebagai opsi alternatif untuk Gunakan paket Security Command Center Premium, Anda dapat mempertimbangkan alat pengelolaan postur keamanan cloud lainnya. Ada berbagai alat pihak ketiga yang memiliki fungsi mirip dengan Security Command Center, dan Anda mungkin telah menggunakan alat berbasis cloud yang berfokus pada lingkungan multi-cloud.

Anda juga dapat menggunakan Security Command Center dan alat pihak ketiga secara bersamaan. Misalnya, Anda dapat menyerap mencari notifikasi dari Security Command Center ke alat lain, atau Anda mungkin menambahkan layanan keamanan pihak ketiga ke dasbor Security Command Center. Sebagai contoh lainnya, Anda mungkin memiliki persyaratan untuk menyimpan log di sistem SIEM yang ada untuk dianalisis tim SOC akan adanya ancaman. Anda dapat mengonfigurasi SIEM yang ada untuk hanya menyerap menemukan notifikasi yang dihasilkan Security Command Center, bukan menyerap log dalam jumlah besar dan mengharapkan tim SOC untuk menganalisisnya log mentah untuk insight.

Hindari opsi ini jika alat keamanan yang sudah ada dapat sepenuhnya mengatasi resource cloud ephemeral atau serverless, memantau konfigurasi yang tidak aman, dan mengidentifikasi ancaman dalam skala besar di lingkungan cloud.

Hindari opsi ini jika hal berikut berlaku:

  • SOC Anda yang ada tidak memiliki keterampilan atau kapasitas untuk menghasilkan analisis ancaman dari volume log cloud yang sangat besar.
  • Pengintegrasian beberapa alat pihak ketiga dengan beberapa layanan Google Cloud menghasilkan lebih banyak kompleksitas daripada nilai.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan cara menggabungkan log yang diperlukan secara terpusat

Sebagian besar log audit disimpan di project Google Cloud yang menghasilkannya. Seiring dengan berkembangnya lingkungan, auditor mungkin tidak dapat lagi memeriksa log di setiap project individu. Oleh karena itu, Anda perlu mengambil keputusan terkait cara log akan dipusatkan dan digabungkan untuk membantu audit internal dan operasi keamanan Anda.

Bagian berikut menjelaskan opsi untuk menggabungkan log. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah alternatif yang dapat Anda pertimbangkan jika opsi 1 tidak berlaku untuk kasus penggunaan tertentu Anda.

Opsi 1: Pertahankan log di Google Cloud menggunakan sink log gabungan

Sebaiknya konfigurasikan sink log di seluruh organisasi terpusat untuk log audit dan log lain yang diperlukan oleh tim keamanan Anda. Anda dapat melihat alat pencakupan log untuk mengidentifikasi log yang diperlukan tim keamanan Anda dan apakah jenis log ini memerlukan pengaktifan eksplisit atau tidak.

Misalnya, tim keamanan mengharapkan data sentral dari setiap resource yang dibuat pengguna sehingga tim keamanan dapat memantau dan menyelidiki perubahan mencurigakan. Tim keamanan juga mewajibkan data akses data yang tidak dapat diubah untuk beban kerja tertentu yang sangat sensitif. Oleh karena itu, tim keamanan mengonfigurasi satu sink log untuk menggabungkan log audit aktivitas admin dari semua project ke dalam bucket analisis log di project pusat yang dapat mereka lihat untuk investigasi mendadak singkat ini. Mereka kemudian mengonfigurasi sink log kedua untuk log audit akses data dari project dengan beban kerja sensitif ke dalam bucket Cloud Storage untuk retensi jangka panjang.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Tim keamanan Anda mengharapkan data pusat dari semua log audit atau jenis log spesifik lainnya.
  • Tim keamanan Anda perlu menyimpan log di lingkungan dengan akses terbatas, di luar kendali beban kerja atau tim yang membuat log.

Hindari opsi ini jika hal berikut berlaku: - Organisasi Anda tidak memiliki persyaratan utama untuk log audit yang konsisten di seluruh workload. - Setiap pemilik project memiliki tanggung jawab penuh untuk mengelola log audit mereka sendiri.

Untuk informasi selengkapnya, lihat referensi berikut:

Opsi 2: Ekspor log audit yang diperlukan ke penyimpanan di luar Google Cloud

Sebagai alternatif untuk menyimpan log hanya di Google Cloud, pertimbangkan untuk mengekspor log audit di luar Google Cloud. Setelah Anda memusatkan jenis log yang diperlukan ke dalam sink log gabungan di Google Cloud, serap konten sink tersebut ke platform lain di luar Google Cloud untuk menyimpan dan menganalisis log.

Misalnya, Anda dapat menggunakan SIEM pihak ketiga untuk menggabungkan dan menganalisis log audit di beberapa penyedia cloud. Alat ini memiliki kemampuan yang memadai untuk bekerja dengan resource cloud tanpa server, dan tim SOC Anda memiliki keterampilan serta kapasitas untuk menghasilkan insight dari volume log yang besar ini.

Opsi ini berpotensi sangat mahal karena biaya traffic keluar jaringan di Google Cloud, serta biaya penyimpanan dan kapasitas di lingkungan lain. Daripada mengekspor setiap log yang tersedia, sebaiknya Anda selektif dalam memilih log mana yang diperlukan di lingkungan eksternal.

Gunakan opsi ini jika Anda memiliki persyaratan untuk menyimpan log dari semua lingkungan dan penyedia cloud di satu lokasi terpusat.

Hindari opsi ini jika hal berikut berlaku:

  • Sistem Anda yang ada tidak memiliki kapasitas atau anggaran untuk menyerap log cloud tambahan dalam jumlah besar.
  • Sistem Anda yang ada memerlukan upaya integrasi untuk setiap jenis dan format log.
  • Anda mengumpulkan log tanpa tujuan yang jelas tentang bagaimana mereka akan digunakan.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan cara memenuhi persyaratan kepatuhan untuk enkripsi dalam penyimpanan

Google Cloud otomatis mengenkripsi semua konten Anda yang disimpan dalam penyimpanan, menggunakan satu atau beberapa mekanisme enkripsi. Bergantung pada persyaratan kepatuhan, Anda mungkin memiliki kewajiban untuk mengelola kunci enkripsi sendiri.

Bagian berikut menjelaskan opsi untuk enkripsi dalam penyimpanan. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah alternatif yang dapat Anda pertimbangkan jika opsi 1 tidak berlaku untuk kasus penggunaan tertentu Anda.

Opsi 1: Terima penggunaan enkripsi default saat dalam penyimpanan

Enkripsi dalam penyimpanan default sudah cukup untuk banyak kasus penggunaan yang tidak memiliki persyaratan kepatuhan tertentu terkait pengelolaan kunci enkripsi.

Misalnya, tim keamanan di sebuah perusahaan game online mewajibkan semua data pelanggan dienkripsi saat dalam penyimpanan. Mereka tidak memiliki persyaratan peraturan tentang pengelolaan kunci, dan setelah meninjau enkripsi dalam penyimpanan default Google, mereka puas bahwa enkripsi tersebut merupakan kontrol yang memadai untuk kebutuhan mereka.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Anda tidak memiliki persyaratan khusus tentang cara mengenkripsi data atau cara kunci enkripsi dikelola.
  • Anda lebih memilih layanan terkelola daripada biaya dan overhead operasional untuk mengelola kunci enkripsi Anda sendiri.

Hindari opsi ini jika Anda memiliki persyaratan kepatuhan untuk mengelola kunci enkripsi Anda sendiri.

Untuk mengetahui informasi selengkapnya, lihat Enkripsi dalam penyimpanan di Google Cloud.

Opsi 2: Kelola kunci enkripsi menggunakan Cloud KMS

Selain enkripsi dalam penyimpanan default, Anda mungkin memerlukan lebih banyak kontrol atas kunci yang digunakan untuk mengenkripsi data dalam penyimpanan dalam project Google Cloud. Cloud Key Management Service (Cloud KMS) menawarkan kemampuan untuk melindungi data Anda menggunakan kunci enkripsi yang dikelola pelanggan (CMEK). Misalnya, di industri jasa keuangan, Anda mungkin memiliki persyaratan untuk melaporkan kepada auditor eksternal tentang cara Anda mengelola kunci enkripsi sendiri untuk data sensitif.

Untuk lapisan kontrol tambahan, Anda dapat mengonfigurasi modul keamanan hardware (HSM) atau pengelolaan kunci eksternal (EKM) dengan CMEK. Kunci enkripsi yang disediakan pelanggan (CSEK) tidak direkomendasikan; skenario yang sebelumnya ditangani oleh CSEK kini dapat ditangani dengan lebih baik oleh Cloud External Key Manager (Cloud EKM) karena Cloud EKM memiliki dukungan untuk lebih banyak layanan dan ketersediaan yang lebih tinggi.

Opsi ini mengalihkan beberapa tanggung jawab kepada developer aplikasi untuk mengikuti pengelolaan kunci yang diwajibkan oleh tim keamanan Anda. Tim keamanan dapat menegakkan persyaratan dengan memblokir pembuatan resource yang tidak mematuhi kebijakan dengan kebijakan organisasi CMEK.

Gunakan opsi ini jika satu atau beberapa hal berikut berlaku:

  • Anda memiliki persyaratan untuk mengelola siklus proses kunci Anda sendiri.
  • Anda memiliki persyaratan untuk membuat materi kunci kriptografis dengan HSM tersertifikasi FIPS 140-2 Level 3.
  • Anda memiliki persyaratan untuk menyimpan materi kunci kriptografis di luar Google Cloud menggunakan Cloud EKM.

Hindari opsi ini jika hal berikut berlaku:

  • Anda tidak memiliki persyaratan khusus tentang cara mengenkripsi data atau cara kunci enkripsi dikelola.
  • Anda lebih memilih layanan terkelola daripada biaya dan overhead operasional untuk mengelola kunci enkripsi Anda sendiri.

Untuk informasi selengkapnya, lihat referensi berikut:

Opsi 3: Buat token data di lapisan aplikasi sebelum mempertahankannya di penyimpanan

Selain enkripsi default yang disediakan oleh Google, Anda juga dapat mengembangkan solusi Anda sendiri untuk membuat token data sebelum menyimpannya di Google Cloud.

Misalnya, data scientist harus menganalisis set data yang berisi informasi PII, tetapi data scientist tidak boleh memiliki akses untuk membaca data mentah dari beberapa kolom sensitif. Untuk membatasi akses kontrol ke data mentah, Anda dapat mengembangkan pipeline penyerapan dengan Perlindungan Data Sensitif untuk menyerap dan membuat token data sensitif, lalu mempertahankan data berupa token ke BigQuery.

Membuat token data bukanlah kontrol yang dapat Anda terapkan secara terpusat di zona landing. Sebaliknya, opsi ini mengalihkan tanggung jawab kepada developer aplikasi untuk mengonfigurasi enkripsi mereka sendiri, atau kepada tim platform yang mengembangkan pipeline enkripsi sebagai layanan bersama untuk digunakan oleh developer aplikasi.

Gunakan opsi ini saat beban kerja tertentu memiliki data yang sangat sensitif yang tidak boleh digunakan dalam bentuk mentah.

Hindari opsi ini jika Cloud KMS cukup untuk memenuhi persyaratan Anda, seperti yang dijelaskan di bagian Mengelola kunci enkripsi menggunakan Cloud KMS. Memindahkan data melalui pipeline enkripsi dan dekripsi tambahan akan menambah biaya, latensi, dan kompleksitas pada aplikasi.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan cara memenuhi persyaratan kepatuhan untuk enkripsi dalam pengiriman

Google Cloud memiliki beberapa langkah keamanan untuk membantu memastikan keaslian, integritas, dan privasi data dalam pengiriman. Bergantung pada persyaratan keamanan dan kepatuhan, Anda juga dapat mengonfigurasi enkripsi lapisan aplikasi.

Bagian berikut menjelaskan opsi untuk enkripsi dalam pengiriman. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah fitur tambahan yang dapat Anda pertimbangkan jika opsi 1 tidak cukup untuk kasus penggunaan spesifik Anda.

Opsi 1: Evaluasi apakah enkripsi default dalam pengiriman sudah memadai

Banyak pola lalu lintas mendapatkan manfaat dari enkripsi dalam pengiriman default Google tanpa memerlukan konfigurasi tambahan. Semua traffic VM-ke-VM dalam jaringan VPC dan jaringan VPC yang terhubung dienkripsi pada lapisan 3 atau lapisan 4. Traffic dari internet ke layanan Google dihentikan di Google Front End (GFE). GFE juga melakukan hal berikut:

  • Menghentikan traffic untuk traffic proxy HTTP(S), TCP, dan TLS yang masuk
  • Menyediakan penanggulangan serangan DDoS
  • Merutekan dan melakukan load balancing pada traffic ke layanan Google Cloud

Misalnya, jika Anda mendesain aplikasi internal serverless menggunakan Google API, jalur jaringan untuk layanan akan otomatis menggunakan enkripsi dalam pengiriman default. Anda tidak perlu mengonfigurasi kontrol enkripsi dalam pengiriman tambahan agar traffic dapat dienkripsi.

Gunakan opsi ini saat enkripsi dalam pengiriman default Google sudah cukup untuk beban kerja internal Anda.

Hindari opsi ini jika hal berikut berlaku:

  • Anda memerlukan enkripsi untuk semua traffic melalui Cloud Interconnect.
  • Anda mengizinkan traffic masuk internet ke jaringan VPC Anda.
  • Anda memerlukan enkripsi dalam pengiriman Lapisan 7 di antara semua resource komputasi internal.

Dalam kasus tersebut, Anda harus mengonfigurasi kontrol tambahan, seperti yang dibahas dalam Opsi 2: Mewajibkan aplikasi mengonfigurasi enkripsi dalam pengiriman Lapisan 7. Untuk mengetahui informasi selengkapnya, lihat Enkripsi dalam pengiriman di Google Cloud.

Opsi 2: Wajibkan aplikasi untuk mengonfigurasi enkripsi dalam pengiriman Lapisan 7

Selain enkripsi dalam pengiriman default, Anda dapat mengonfigurasi enkripsi Lapisan 7 untuk traffic aplikasi. Google Cloud menyediakan layanan terkelola untuk mendukung aplikasi yang memerlukan enkripsi dalam pengiriman lapisan aplikasi, termasuk sertifikat terkelola, Anthos Service Mesh, dan Traffic Director.

Misalnya, developer memmangun aplikasi baru yang menerima traffic masuk dari internet. Load Balancer Aplikasi eksternal dengan sertifikat SSL yang dikelola Google untuk menjalankan dan menskalakan layanan di balik satu alamat IP.

Enkripsi lapisan aplikasi bukanlah kontrol yang dapat Anda terapkan secara terpusat di zona landing. Sebaliknya, opsi ini mengalihkan sebagian tanggung jawab kepada developer aplikasi untuk mengonfigurasi enkripsi dalam pengiriman.

Gunakan opsi ini saat aplikasi memerlukan traffic HTTPS atau SSL di antara komponen.

Pertimbangkan untuk mengizinkan pengecualian terbatas pada opsi ini saat Anda memigrasikan beban kerja komputasi ke cloud yang sebelumnya tidak memerlukan enkripsi dalam pengiriman untuk traffic internal saat aplikasi berada di infrastruktur lokal. Selama migrasi berskala besar, memaksa aplikasi lama untuk dimodernisasi sebelum migrasi dapat menyebabkan penundaan program yang tidak dapat diterima.

Untuk informasi selengkapnya, lihat referensi berikut:

Menentukan kontrol tambahan mana yang diperlukan untuk mengelola akses penyedia layanan cloud

Kebutuhan untuk mengaudit akses penyedia layanan cloud (CSP) dapat menjadi kekhawatiran selama adopsi cloud. Google Cloud menyediakan kontrol berlapis yang dapat mengaktifkan verifikasi akses penyedia cloud.

Bagian berikut menjelaskan opsi untuk mengelola akses CSP. Sebaiknya gunakan opsi 1 untuk sebagian besar kasus penggunaan. Opsi lain yang dibahas di bagian berikut adalah fitur tambahan yang dapat Anda pertimbangkan jika opsi 1 tidak cukup untuk kasus penggunaan spesifik Anda.

Opsi 1: Aktifkan log Transparansi Akses

Log Transparansi Akses mencatat tindakan yang dilakukan oleh staf Google Cloud di lingkungan Anda, seperti saat mereka memecahkan masalah kasus dukungan.

Misalnya, developer Anda mengajukan masalah pemecahan masalah ke Cloud Customer Care, dan meminta agen dukungan untuk membantu memecahkan masalah lingkungan mereka. Log Transparansi Akses dibuat untuk menunjukkan tindakan yang dilakukan staf dukungan, termasuk nomor kasus dukungan yang sesuai.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Anda memiliki persyaratan untuk memastikan bahwa personel Google Cloud mengakses konten Anda hanya untuk alasan bisnis yang valid, seperti memperbaiki pemadaman layanan atau menangani permintaan dukungan Anda.
  • Anda memiliki persyaratan kepatuhan untuk melacak akses ke data sensitif.

Opsi 2: Aktifkan log Transparansi Akses dan pengelolaan akses penyedia

Jika bisnis Anda memiliki persyaratan kepatuhan untuk memberikan persetujuan eksplisit sebelum CSP dapat mengakses lingkungan Anda, selain Opsi 1, Anda dapat menggunakan Transparansi Akses dengan kontrol lain yang memungkinkan Anda menyetujui atau menolak akses secara eksplisit dengan data Anda.

Persetujuan Akses adalah solusi manual yang memastikan bahwa Layanan Pelanggan dan engineer Google memerlukan persetujuan eksplisit Anda (melalui email atau melalui webhook) setiap kali mereka perlu mengakses konten Anda.

Key Access Justifications adalah solusi terprogram yang menambahkan kolom justifikasi ke setiap permintaan kunci enkripsi yang dikonfigurasi dengan Cloud EKM.

Gunakan opsi ini jika hal berikut terpenuhi:

  • Anda ingin tim pusat mengelola akses ke konten Anda secara langsung oleh personel Google.
  • Untuk Persetujuan Akses, Anda dapat menerima risiko bahwa kemampuan pusat untuk menyetujui atau menolak setiap permintaan akses lebih penting daripada kompromi operasional, yang dapat menjadi penyelesaian kasus dukungan yang lebih lambat.
  • Untuk Key Access Justifications, bisnis Anda sudah menggunakan Cloud External Key Manager sebagai bagian dari strategi enkripsi Anda, dan menginginkan kontrol terprogram atas semua jenis akses ke data terenkripsi (tidak hanya akses personel Google ke data).

Hindari opsi ini jika hal berikut berlaku:

  • Penundaan operasional yang dapat terjadi ketika tim pusat dengan otoritas Persetujuan Akses harus merespons adalah risiko yang tidak dapat diterima terhadap beban kerja yang memerlukan ketersediaan tinggi dan respons cepat dari Layanan Pelanggan.

Untuk informasi selengkapnya, lihat referensi berikut:

Praktik terbaik keamanan untuk zona landing Google Cloud

Selain keputusan yang diperkenalkan dalam dokumen ini, pertimbangkan praktik terbaik keamanan berikut:

Langkah selanjutnya