Men-deploy arsitektur serverless yang aman menggunakan Cloud Run

Last reviewed 2023-03-10 UTC

Konten ini terakhir diperbarui pada Maret 2023, dan menampilkan status quo pada saat konten tersebut ditulis. Kebijakan dan sistem keamanan Google Cloud Platform dapat berubah di masa mendatang, seiring upaya kami untuk terus meningkatkan (kualitas) perlindungan bagi pelanggan.

Arsitektur serverless memungkinkan Anda mengembangkan software dan layanan tanpa menyediakan atau memelihara server. Anda dapat menggunakan arsitektur serverless untuk mem-build aplikasi untuk berbagai layanan.

Dokumen ini memberikan panduan opini bagi engineer DevOps, arsitek keamanan, dan developer aplikasi tentang cara membantu melindungi aplikasi serverless yang menggunakan Cloud Run. Dokumen tersebut merupakan bagian dari blueprint keamanan yang terdiri dari hal-hal berikut:

  • Repositori GitHub yang berisi kumpulan konfigurasi dan skrip Terraform.
  • Panduan untuk arsitektur, desain, dan kontrol keamanan yang Anda terapkan dengan blueprint (dokumen ini).

Meskipun Anda dapat men-deploy blueprint ini tanpa men-deploy blueprint fondasi perusahaan Google Cloud terlebih dahulu, dokumen ini mengasumsikan bahwa Anda telah mengonfigurasi rangkaian kontrol keamanan dasar seperti yang dijelaskan dalam blueprint fondasi perusahaan Google Cloud. Arsitektur yang dijelaskan dalam dokumen ini membantu Anda melapisi kontrol tambahan ke fondasi Anda untuk membantu melindungi aplikasi serverless Anda.

Untuk membantu menentukan kontrol keamanan utama yang terkait dengan aplikasi serverless, Cloud Security Alliance (CSA) memublikasikan 12 Risiko Penting Teratas untuk Aplikasi Serverless. Kontrol keamanan yang digunakan dalam blueprint ini didesain untuk mengatasi risiko yang relevan dengan berbagai kasus penggunaan yang dijelaskan dalam dokumen ini.

Kasus penggunaan serverless

Blueprint ini mendukung kasus penggunaan berikut:

Perbedaan antara fungsi Cloud Run dan Cloud Run meliputi hal berikut:

  • Fungsi Cloud Run dipicu oleh peristiwa, seperti perubahan pada data dalam database atau penerimaan pesan dari sistem pesan seperti Pub/Sub. Cloud Run dipicu oleh permintaan, seperti permintaan HTTP.
  • Fungsi Cloud Run dibatasi pada serangkaian runtime yang didukung. Anda dapat menggunakan Cloud Run dengan bahasa pemrograman apa pun.
  • Fungsi Cloud Run mengelola container dan infrastruktur yang mengontrol server web atau runtime bahasa, sehingga Anda dapat berfokus pada kode. Cloud Run memberi Anda fleksibilitas untuk menjalankan layanan ini sendiri, sehingga Anda dapat mengontrol konfigurasi container.

Untuk informasi selengkapnya tentang perbedaan antara Cloud Run dan fungsi Cloud Run, lihat Memilih opsi komputasi Google Cloud.

Arsitektur

Blueprint ini memungkinkan Anda menjalankan aplikasi serverless di Cloud Run dengan VPC Bersama. Sebaiknya gunakan VPC Bersama karena kebijakan ini memusatkan kebijakan dan kontrol jaringan untuk semua resource jaringan. Selain itu, VPC Bersama di-deploy dalam blueprint dasar-dasar perusahaan.

Gambar berikut menunjukkan cara menjalankan aplikasi serverless dalam jaringan VPC Bersama.

Arsitektur untuk blueprint serverless.

Arsitektur yang ditampilkan dalam diagram sebelumnya menggunakan kombinasi layanan dan fitur Google Cloud berikut:

  • Load Balancer Aplikasi eksternal menerima data yang diperlukan aplikasi serverless dari internet dan meneruskannya ke Cloud Run. Load Balancer Aplikasi eksternal adalah load balancer Lapisan 7.
  • Google Cloud Armor bertindak sebagai firewall aplikasi web untuk membantu melindungi aplikasi serverless Anda dari denial of service (DoS) dan serangan web.
  • Cloud Run memungkinkan Anda menjalankan kode aplikasi dalam container dan mengelola infrastruktur untuk Anda. Pada blueprint ini, setelan internal dan ingress Cloud Load Balancing akan membatasi akses ke Cloud Run, sehingga Cloud Run hanya akan menerima permintaan dari Load Balancer Aplikasi eksternal.

  • Konektor Akses VPC Serverless menghubungkan aplikasi serverless Anda ke jaringan VPC menggunakan Akses VPC Serverless. Akses VPC Serverless membantu memastikan permintaan dari aplikasi serverless Anda ke jaringan VPC tidak terekspos ke internet. Akses VPC Serverless memungkinkan Cloud Run berkomunikasi dengan layanan, sistem penyimpanan, dan resource lain yang mendukung Kontrol Layanan VPC.

    Secara default, Anda membuat konektor Akses VPC Serverless dalam project layanan. Anda dapat membuat konektor Akses VPC Serverless di project host dengan menentukan true untuk variabel input connector_on_host_project saat menjalankan modul Jaringan Cloud Run yang Aman. Untuk informasi selengkapnya, lihat Perbandingan metode konfigurasi.

  • Aturan firewall Virtual Private Cloud (VPC) mengontrol aliran data ke dalam subnet yang menghosting resource Anda, seperti server perusahaan yang dihosting di Compute Engine, atau data perusahaan yang disimpan di Cloud Storage.

  • Kontrol Layanan VPC menciptakan perimeter keamanan yang mengisolasi layanan dan resource Cloud Run dengan menyiapkan otorisasi, kontrol akses, dan pertukaran data yang aman. Perimeter ini dirancang untuk melindungi konten yang masuk, mengisolasi aplikasi Anda dengan menyiapkan kontrol dan pemantauan akses tambahan, serta memisahkan tata kelola Google Cloud Anda dari aplikasi. Tata kelola Anda mencakup pengelolaan kunci dan logging

  • VPC Bersama memungkinkan Anda menghubungkan konektor Akses VPC Serverless di project layanan Anda ke project host.

  • Cloud Key Management Service (Cloud KMS) menyimpan kunci enkripsi yang dikelola pelanggan (CMEK) yang digunakan oleh layanan dalam blueprint ini, termasuk aplikasi serverless Anda, Artifact Registry, dan Cloud Run.

  • Identity and Access Management (IAM) dan Resource Manager membantu membatasi akses dan mengisolasi resource. Kontrol akses dan hierarki resource mengikuti prinsip hak istimewa terendah.

Arsitektur alternatif: Cloud Run tanpa jaringan VPC Bersama

Jika tidak menggunakan jaringan VPC Bersama, Anda dapat men-deploy Cloud Run dan aplikasi serverless Anda di perimeter Kontrol Layanan VPC tanpa jaringan VPC Bersama. Anda dapat menerapkan arsitektur alternatif ini jika menggunakan topologi hub-and-spoke.

Gambar berikut menunjukkan cara menjalankan aplikasi serverless tanpa VPC Bersama.

Arsitektur alternatif untuk blueprint serverless.

Arsitektur yang ditunjukkan pada diagram sebelumnya menggunakan kombinasi layanan dan fitur Google Cloud yang mirip dengan yang dijelaskan di bagian sebelumnya, Arsitektur yang direkomendasikan: Cloud Run dengan VPC bersama.

Struktur organisasi

Anda mengelompokkan resource agar dapat mengelolanya serta memisahkan lingkungan pengembangan dan pengujian dari lingkungan produksi. Resource Manager memungkinkan Anda untuk dapat mengelompokkan resource secara logis berdasarkan project, folder, dan organisasi.

Diagram berikut menunjukkan hierarki resource dengan folder yang mewakili lingkungan yang berbeda, seperti bootstrap, umum, produksi, non-produksi (atau pengujian), dan pengembangan. Hierarki resource ini didasarkan pada hierarki yang dijelaskan dalam blueprint dasar perusahaan. Anda men-deploy project yang ditentukan oleh blueprint ke dalam folder berikut: Common, Production, Non-production, dan Dev.

Struktur organisasi untuk blueprint serverless.

Bagian berikut menjelaskan diagram ini secara lebih mendetail.

Folder

Anda menggunakan folder untuk mengisolasi lingkungan produksi dan layanan tata kelola dari lingkungan non-produksi dan pengujian Anda. Tabel berikut menjelaskan folder dari blueprint dasar perusahaan yang digunakan oleh blueprint ini.

Folder Deskripsi
Bootstrap Berisi resource yang diperlukan untuk men-deploy blueprint foundation perusahaan.
Common Berisi layanan terpusat untuk organisasi, seperti project keamanan.
Production Berisi project yang memiliki resource cloud yang telah diuji dan siap digunakan oleh pelanggan. Dalam blueprint ini, folder Production berisi project layanan dan project host.
Non-production Berisi project yang memiliki resource cloud yang saat ini sedang diuji dan direncanakan untuk dirilis. Dalam blueprint ini, folder Non-production berisi project layanan dan project host.
Dev Berisi project yang memiliki resource cloud yang saat ini sedang dikembangkan. Dalam blueprint ini, folder Dev berisi project layanan dan project host.

Anda dapat mengubah nama folder ini agar selaras dengan struktur folder organisasi, tetapi sebaiknya Anda mempertahankan struktur yang serupa. Untuk mengetahui informasi selengkapnya, lihat Struktur organisasi. Untuk struktur folder lainnya, lihat Menentukan hierarki resource untuk zona landing Google Cloud Anda.

Project

Anda mengisolasi resource di lingkungan Anda menggunakan project. Tabel berikut menjelaskan project yang diperlukan dalam organisasi. Anda dapat mengubah nama project ini, tetapi sebaiknya pertahankan struktur project yang serupa.

Project Deskripsi
Project host Project ini mencakup aturan masuk firewall dan semua resource yang memiliki alamat IP internal (seperti yang dijelaskan dalam Menghubungkan ke jaringan VPC). Saat menggunakan VPC bersama, Anda menetapkan suatu project sebagai project host dan menautkan satu atau beberapa project layanan lain padanya.

Saat menerapkan kode Terraform, Anda menentukan nama project ini, dan blueprint akan men-deploy layanan.
Project layanan Project ini mencakup aplikasi serverless, Cloud Run, dan konektor Akses VPC Serverless Anda. Anda dapat mengaitkan project layanan ke project host sehingga project layanan tersebut dapat berpartisipasi dalam Jaringan VPC Bersama.

Saat menerapkan kode Terraform, Anda menentukan nama project ini. Blueprint ini men-deploy Cloud Run, Google Cloud Armor, konektor Akses VPC Serverless, dan load balancer.
Project keamanan Project ini mencakup layanan khusus keamanan Anda, seperti Cloud KMS dan Secret Manager.

Saat menerapkan kode Terraform, Anda menentukan nama project ini, dan blueprint akan men-deploy Cloud KMS. Jika Anda menggunakan modul Secure Cloud Run Harness, Artifact Registry juga akan di-deploy.

Jika Anda men-deploy blueprint ini setelah men-deploy blueprint security foundation, project ini adalah project secret yang dibuat oleh blueprint enterprise foundation. Untuk mengetahui informasi selengkapnya tentang project blueprint fondasi perusahaan, lihat Project.

Jika Anda men-deploy beberapa instance blueprint ini tanpa blueprint enterprise foundation, setiap instance akan memiliki project keamanannya sendiri.

Memetakan peran dan grup ke project

Anda harus memberikan akses ke project yang membentuk arsitektur serverless kepada grup pengguna yang berbeda di organisasi Anda. Tabel berikut menjelaskan rekomendasi blueprint untuk grup pengguna dan penetapan peran dalam project yang Anda buat. Anda dapat menyesuaikan grup agar cocok dengan struktur organisasi yang ada, tetapi sebaiknya Anda mempertahankan pemisahan tugas dan penetapan peran yang serupa.

Grup Project Peran
Administrator serverless

grp-gcp-serverless-admin@example.com		 Project layanan
Administrator keamanan serverless

grp-gcp-serverless-security-admin@example.com		 Project keamanan
Developer Cloud Run

grp-gcp-secure-cloud-run-developer@example.com		 Project keamanan
Pengguna Cloud Run

grp-gcp-secure-cloud-run-user@example.com		 Project layanan

Kontrol keamanan

Bagian ini membahas kontrol keamanan di Google Cloud yang Anda gunakan untuk membantu mengamankan arsitektur serverless. Prinsip keamanan utama yang perlu dipertimbangkan adalah sebagai berikut:

  • Amankan akses sesuai dengan prinsip hak istimewa terendah, sehingga hanya memberikan hak istimewa yang diperlukan kepada entitas untuk melakukan tugasnya.
  • Amankan koneksi jaringan melalui desain segmentasi, kebijakan organisasi, dan kebijakan firewall.
  • Amankan konfigurasi untuk setiap layanan.
  • Pahami tingkat risiko dan persyaratan keamanan untuk lingkungan yang menghosting beban kerja serverless Anda.
  • Konfigurasikan pemantauan dan logging yang memadai untuk memungkinkan deteksi, investigasi, dan respons.

Kontrol keamanan untuk aplikasi serverless

Anda dapat membantu melindungi aplikasi serverless menggunakan kontrol yang melindungi traffic di jaringan, mengontrol akses, dan mengenkripsi data.

Kontrol sistem build

Saat men-deploy aplikasi serverless, Anda menggunakan Artifact Registry untuk menyimpan biner dan image container. Artifact Registry mendukung CMEK sehingga Anda dapat mengenkripsi repositori menggunakan kunci enkripsi Anda sendiri.

Traffic SSL

Untuk mendukung traffic HTTPS ke aplikasi serverless, Anda harus mengonfigurasi sertifikat SSL untuk Load Balancer Aplikasi eksternal Anda. Secara default, Anda menggunakan sertifikat yang ditandatangani sendiri dan dapat diubah menjadi sertifikat terkelola setelah Anda menerapkan kode Terraform. Untuk informasi selengkapnya tentang cara menginstal dan menggunakan sertifikat terkelola, lihat Menggunakan sertifikat SSL yang dikelola Google.

Aturan jaringan dan firewall

Aturan firewall Virtual Private Cloud (VPC) mengontrol aliran data ke dalam perimeter. Anda membuat aturan firewall yang menolak semua traffic keluar, kecuali untuk koneksi port 443 TCP tertentu dari nama domain khusus restricted.googleapis.com. Penggunaan domain restricted.googleapis.com memiliki manfaat sebagai berikut:

  • Membantu mengurangi permukaan serangan jaringan Anda dengan menggunakan Akses Google Pribadi saat beban kerja berkomunikasi dengan API dan layanan Google.
  • Memastikan bahwa Anda hanya menggunakan layanan yang mendukung Kontrol Layanan VPC.

Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Google Pribadi.

Kontrol perimeter

Seperti yang ditunjukkan dalam diagram arsitektur yang direkomendasikan, Anda menempatkan resource untuk aplikasi serverless di perimeter terpisah. Perimeter ini membantu melindungi aplikasi serverless dari akses yang tidak diinginkan dan pemindahan data yang tidak sah.

Kebijakan akses

Untuk membantu memastikan bahwa hanya identitas tertentu (pengguna atau layanan) yang dapat mengakses resource dan data, Anda harus mengaktifkan grup dan peran IAM.

Untuk membantu memastikan bahwa hanya resource tertentu yang dapat mengakses project Anda, aktifkan kebijakan akses untuk organisasi Google Anda. Untuk mengetahui informasi selengkapnya, lihat Atribut tingkat akses.

Identity and Access Proxy

Jika lingkungan Anda sudah menyertakan Identity and Access Proxy (IAP), Anda dapat mengonfigurasi Load Balancer Aplikasi eksternal agar menggunakan IAP untuk mengizinkan traffic bagi aplikasi serverless Anda. Dengan IAP, Anda dapat membuat lapisan otorisasi pusat untuk aplikasi serverless sehingga Anda dapat menggunakan kontrol akses tingkat aplikasi, bukan mengandalkan firewall tingkat jaringan.

Untuk mengaktifkan IAP untuk aplikasi Anda, dalam file loadbalancer.tf, setel iap_config.enable ke true.

Untuk mengetahui informasi selengkapnya tentang IAP, lihat ringkasan Identity-Aware Proxy.

Akun layanan dan kontrol akses

Akun layanan adalah identitas yang dapat digunakan Google Cloud untuk menjalankan permintaan API atas nama Anda. Untuk menerapkan pemisahan tugas, Anda membuat akun layanan yang memiliki peran berbeda untuk tujuan tertentu. Akun layanan tersebut adalah sebagai berikut:

  • Akun layanan Cloud Run (cloud_run_sa) yang memiliki peran berikut:

    • roles/run.invoker
    • roles/secretmanager.secretAccessor

    Untuk mengetahui informasi selengkapnya, lihat Mengizinkan Cloud Run mengakses secret.

  • Akun konektor Akses VPC Serverless (gcp_sa_vpcaccess) yang memiliki peran roles/compute.networkUser.

  • Akun konektor Akses VPC Serverless kedua (cloud_services) yang memiliki peran roles/compute.networkUser.

    Akun layanan untuk konektor Akses VPC Serverless ini diperlukan agar konektor dapat membuat aturan masuk dan keluar firewall di project host. Untuk mengetahui informasi selengkapnya, lihat Memberikan izin ke akun layanan di project layanan.

  • Identitas layanan untuk menjalankan Cloud Run (run_identity_services) yang memiliki peran roles/vpcaccess.user.

  • Agen layanan untuk Google API (cloud_services_sa) yang memiliki peran roles/editor. Akun layanan ini memungkinkan Cloud Run berkomunikasi dengan konektor Akses VPC Serverless.

  • Sebuah identitas layanan untuk Cloud Run (serverless_sa) yang memiliki peran roles/artifactregistry.reader. Akun layanan ini menyediakan akses ke kunci enkripsi dan dekripsi Artifact Registry dan CMEK.

Pengelolaan kunci

Anda dapat menggunakan kunci CMEK untuk membantu melindungi data di Artifact Registry dan di Cloud Run. Anda menggunakan kunci enkripsi berikut:

  • Kunci software untuk Artifact Registry yang mengesahkan kode untuk aplikasi serverless Anda.
  • Kunci enkripsi untuk mengenkripsi image container yang di-deploy Cloud Run.

Saat menerapkan konfigurasi Terraform, Anda menentukan lokasi CMEK, yang menentukan lokasi geografis tempat kunci disimpan. Anda harus memastikan bahwa kunci CMEK berada di region yang sama dengan resource Anda. Secara default, kunci CMEK dirotasi setiap 30 hari.

Pengelolaan secret

Cloud Run mendukung Secret Manager untuk menyimpan secret yang mungkin diperlukan oleh aplikasi serverless Anda. Secret ini dapat mencakup kunci API serta nama pengguna dan sandi database. Untuk menampilkan secret sebagai volume yang terpasang, gunakan variabel volume_mounts dan volumes di modul utama.

Saat men-deploy blueprint ini dengan blueprint enterprise foundation, Anda harus menambahkan secret ke project secret sebelum menerapkan kode Terraform. Blueprint akan memberikan peran Secret Manager Secret Accessor ke akun layanan Cloud Run. Untuk mengetahui informasi selengkapnya, lihat Menggunakan secret.

Kebijakan organisasi

Blueprint ini menambahkan batasan pada batasan kebijakan organisasi. Untuk informasi selengkapnya tentang batasan yang digunakan oleh blueprint fondasi perusahaan, lihat Batasan kebijakan organisasi.

Tabel berikut menjelaskan batasan kebijakan organisasi tambahan yang ditentukan dalam modul Keamanan Cloud Run dari blueprint ini.

Batasan kebijakan Deskripsi Nilai yang direkomendasikan
constraints/run.allowedIngress Mengizinkan traffic masuk hanya dari layanan internal atau Load Balancer Aplikasi eksternal. internal-and-cloud-load-balancing
constraints/run.allowedVPCEgress Mewajibkan revisi layanan Cloud Run untuk menggunakan konektor Akses VPC Serverless, dan pastikan bahwa setelan egress VPC revisi ditetapkan untuk mengizinkan rentang pribadi saja. private-ranges-only

Kontrol operasional

Anda dapat mengaktifkan logging dan fitur paket Premium Security Command Center seperti analisis kondisi keamanan dan deteksi ancaman. Kontrol ini membantu Anda melakukan hal berikut:

  • Memantau siapa yang mengakses data Anda.
  • Memastikan bahwa audit yang tepat dilakukan.
  • Mendukung kemampuan tim manajemen dan operasi insiden Anda untuk merespons masalah yang mungkin terjadi.

Logging

Untuk membantu Anda memenuhi persyaratan audit dan mendapatkan insight tentang project, konfigurasi Google Cloud Observability dengan log data untuk layanan yang ingin Anda lacak. Deploy Cloud Logging di project sebelum Anda menerapkan kode Terraform guna memastikan bahwa blueprint dapat mengonfigurasi logging untuk firewall, load balancer, dan jaringan VPC.

Setelah men-deploy blueprint, sebaiknya Anda mengonfigurasi hal berikut:

  • Buat sink log gabungan di semua project.
  • Pilih region yang sesuai untuk menyimpan log Anda
  • Tambahkan kunci CMEK ke sink logging Anda.

Untuk semua layanan dalam project, pastikan log Anda menyertakan informasi tentang pembacaan dan penulisan data, dan pastikan log tersebut menyertakan informasi tentang apa yang diakses administrator. Untuk informasi selengkapnya tentang praktik terbaik logging, lihat Kontrol detektif.

Pemantauan dan pemberitahuan

Setelah men-deploy blueprint tersebut, Anda dapat menyiapkan pemberitahuan untuk memberi tahu pusat operasi keamanan (SOC) bahwa mungkin terjadi insiden keamanan. Misalnya, Anda dapat menggunakan pemberitahuan agar analis keamanan mengetahui saat izin telah berubah dalam peran IAM. Untuk informasi selengkapnya tentang mengonfigurasi pemberitahuan Security Command Center, lihat Menyiapkan notifikasi temuan.

Dasbor Cloud Run Monitoring, yang merupakan bagian dari contoh library dasbor, memberi Anda informasi berikut:

  • Jumlah permintaan
  • Latensi permintaan
  • Waktu instance yang dapat ditagih
  • Alokasi CPU container
  • Alokasi memori container
  • Pemakaian CPU container
  • Pemakaian memori container

Untuk petunjuk tentang cara mengimpor dasbor, lihat Menginstal contoh dasbor. Untuk mengekspor pemberitahuan, lihat dokumen berikut:

Proses debug dan pemecahan masalah

Anda dapat menjalankan Uji Konektivitas untuk membantu Anda men-debug masalah konfigurasi jaringan antara Cloud Run dan resource dalam subnet Anda. Uji Konektivitas menyimulasikan jalur paket yang diharapkan dan memberikan detail tentang konektivitas, termasuk analisis konektivitas resource ke resource.

Uji Konektivitas tidak diaktifkan oleh kode Terraform; Anda harus menyiapkannya secara terpisah. Untuk mengetahui informasi selengkapnya, lihat Membuat dan menjalankan Uji Konektivitas.

Kontrol detektif

Bagian ini menjelaskan kontrol detektif yang tercakup dalam blueprint.

Google Cloud Armor dan WAF

Anda menggunakan Load Balancer Aplikasi eksternal dan Google Cloud Armor untuk memberikan perlindungan denial of service (DDoS) terdistribusi untuk aplikasi serverless Anda. Google Cloud Armor adalah firewall aplikasi web (WAF) yang disertakan dalam Google Cloud.

Anda mengonfigurasi aturan Google Cloud Armor yang dijelaskan dalam tabel berikut untuk membantu melindungi aplikasi serverless. Aturan ini dirancang untuk membantu mengurangi 10 risiko teratas OWASP.

Nama aturan Google Cloud Armor Nama aturan ModSecurity
Eksekusi kode jarak jauh rce-v33-stable
File lokal mencakup lfi-v33-stable
Serangan protokol protocolattack-v33-stable
Penyertaan file jarak jauh rfi-v33-stable
Deteksi pemindai scannerdetection-v33-stable
Serangan fiksasi sesi sessionfixation-v33-stable
Injeksi SQL sqli-v33-stable
Pembuatan skrip antarsitus xss-v33-stable

Saat aturan ini diaktifkan, Google Cloud Armor akan secara otomatis menolak traffic yang cocok dengan aturan tersebut.

Untuk mengetahui informasi selengkapnya mengenai aturan ini, lihat Menyesuaikan aturan WAF yang telah dikonfigurasi sebelumnya oleh Google Cloud Armor.

Deteksi masalah keamanan di Cloud Run

Anda dapat mendeteksi potensi masalah keamanan di Cloud Run menggunakan Recommender. Pemberi rekomendasi dapat mendeteksi masalah keamanan seperti berikut:

  • Kunci API atau sandi yang disimpan di variabel lingkungan, bukan di Secret Manager.
  • Container yang menyertakan kredensial hard code, bukan menggunakan identitas layanan.

Sekitar sehari setelah Anda men-deploy Cloud Run, Pemberi rekomendasi mulai memberikan temuan dan rekomendasinya. Pemberi rekomendasi menampilkan temuan dan tindakan perbaikan yang direkomendasikan di daftar layanan Cloud Run atau Hub Rekomendasi.

Mode deployment Terraform

Tabel berikut menjelaskan cara men-deploy blueprint ini, dan modul Terraform mana yang diterapkan untuk setiap mode deployment.

Mode deployment Modul Terraform
Deploy blueprint ini setelah men-deploy blueprint dasar-dasar perusahaan (direkomendasikan).

Opsi ini men-deploy resource untuk blueprint ini di perimeter Kontrol Layanan VPC yang sama dengan yang digunakan oleh blueprint foundation perusahaan. Untuk informasi selengkapnya, lihat Cara menyesuaikan Foundation v2.3.1 untuk deployment Serverless Aman.

Opsi ini juga menggunakan project secret yang Anda buat saat men-deploy blueprint foundation perusahaan.		 Gunakan modul Terraform ini:
Instal blueprint ini tanpa menginstal blueprint dasar-dasar perusahaan.

Opsi ini mengharuskan Anda membuat perimeter Kontrol Layanan VPC.		 Gunakan modul Terraform ini:

Menyatukan semuanya

Untuk menerapkan arsitektur yang dijelaskan dalam dokumen ini, lakukan hal berikut:

  1. Tinjau README untuk blueprint dan pastikan Anda memenuhi semua prasyarat.
  2. Buat sertifikat SSL untuk digunakan dengan Load Balancer Aplikasi eksternal.
    Jika Anda tidak menyelesaikan langkah ini, blueprint akan menggunakan sertifikat yang ditandatangani sendiri untuk men-deploy load balancer, dan browser akan menampilkan peringatan tentang koneksi tidak aman saat Anda mencoba mengakses aplikasi serverless Anda.
  3. Di lingkungan pengujian Anda, deploy Contoh Cloud Run yang Aman untuk melihat cara kerja blueprint. Sebagai bagian dari proses pengujian, pertimbangkan untuk melakukan hal berikut:
    1. Gunakan Security Command Center untuk memindai project terhadap persyaratan kepatuhan umum.
    2. Ganti aplikasi contoh dengan aplikasi sungguhan dan jalankan melalui skenario deployment standar.
    3. Bekerjasamalah dengan tim engineering dan operasi aplikasi di perusahaan Anda untuk menguji akses mereka ke project dan untuk memverifikasi apakah mereka dapat berinteraksi dengan solusi dengan cara yang diharapkan.
  4. Deploy blueprint tersebut ke lingkungan Anda.

Pemetaan kepatuhan

Untuk membantu menentukan kontrol keamanan utama yang terkait dengan aplikasi serverless, Cloud Security Alliance (CSA) memublikasikan 12 Risiko Penting Teratas untuk Aplikasi Serverless. Kontrol keamanan yang digunakan dalam blueprint ini membantu Anda mengatasi sebagian besar risiko ini, seperti yang dijelaskan dalam tabel berikut.

Risiko Mitigasi blueprint Tanggung jawab Anda
1. Injeksi data peristiwa fungsi Google Cloud Armor dan Load Balancer Aplikasi eksternal membantu melindungi dari 10 Teratas OWASP, seperti yang dijelaskan dalam Opsi mitigasi OWASP Top 10 2021 di Google Cloud Praktik coding yang aman seperti penanganan pengecualian, seperti yang dijelaskan dalam Praktik Coding Aman OWASP dan Supply chain Levels for Software Artifacts (SLSA)
2. Autentikasi rusak Tidak ada IAP dan Identity Platform untuk mengautentikasi pengguna layanan
3. Konfigurasi deployment serverless yang tidak aman CMEK dengan Cloud KMS
 Pengelolaan kunci enkripsi Anda sendiri
4. Izin dan peran fungsi dengan hak istimewa berlebih
  • Akun layanan kustom untuk autentikasi layanan (bukan akun layanan Compute Engine default)
  • Peran IAM yang sangat tercakup di akun layanan Cloud Run
  • Kontrol Layanan VPC untuk membatasi cakupan akses Google Cloud API (sebagaimana disediakan menggunakan blueprint foundation perusahaan Google Cloud)
 Tidak ada
5. Pemantauan dan logging fungsi tidak memadai Cloud Logging Dasbor dan struktur pemberitahuan Cloud Monitoring
6. Dependensi pihak ketiga yang tidak aman Tidak ada Lindungi pipeline CI/CD menggunakan pemindaian kode dan analisis pra-deployment
7. Penyimpanan rahasia aplikasi yang tidak aman Secret Manager Pengelolaan rahasia dalam kode aplikasi
8. Denial of service dan kehabisan sumber daya keuangan
  • Google Cloud Armor
  • Waktu tunggu layanan Cloud Run (defaultnya adalah 120 detik)
 Tidak ada
9. Manipulasi logika bisnis serverless Kontrol Layanan VPC untuk membatasi cakupan akses Google Cloud API (disediakan menggunakan blueprint foundation perusahaan) Tidak ada
10. Penanganan pengecualian yang tidak tepat dan pesan error panjang Tidak ada Praktik terbaik pemrograman yang aman
11. Fungsi, resource cloud, dan pemicu peristiwa yang tidak digunakan lagi Gunakan revisi untuk meminimalkan permukaan serangan. Revisi membantu mengurangi kemungkinan pengaktifan secara tidak sengaja iterasi layanan sebelumnya yang tidak digunakan lagi. Revisi juga membantu Anda menguji postur keamanan revisi baru menggunakan pengujian A/B bersama dengan alat pemantauan dan logging.
  • Infrastructure as code (IaC) untuk mengelola resource cloud
  • Pemantauan resource cloud menggunakan Security Command Center
  • Pemantauan Penagihan Cloud
  • Pembersihan resource cloud yang tidak digunakan untuk meminimalkan permukaan serangan
12. Persistensi data lintas eksekusi Tidak ada Tidak ada

Langkah selanjutnya