Men-deploy arsitektur serverless yang aman menggunakan Cloud Functions

Last reviewed 2023-08-06 UTC

Arsitektur serverless memungkinkan Anda mengembangkan software dan layanan tanpa menyediakan atau memelihara server. Anda dapat menggunakan arsitektur serverless untuk membangun 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 Functions (generasi ke-2). Dokumen tersebut merupakan bagian dari blueprint keamanan yang terdiri dari hal-hal berikut:

• Sebuah 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 Enterprise Foundation Google Cloud terlebih dahulu, dokumen ini mengasumsikan bahwa Anda telah mengonfigurasi serangkaian kontrol keamanan dasar seperti yang dijelaskan dalam blueprint Enterprise Foundation 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 mendukung kasus penggunaan berikut:

• Men-deploy arsitektur serverless menggunakan Cloud Functions (dokumen ini)
• Men-deploy arsitektur serverless menggunakan Cloud Run

Perbedaan antara Cloud Functions dan Cloud Run meliputi hal berikut:

• Cloud Functions 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.
• Cloud Functions dibatasi pada serangkaian runtime yang didukung. Anda dapat menggunakan Cloud Run dengan bahasa pemrograman apa pun.
• Cloud Functions 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 Cloud Functions, lihat Memilih opsi komputasi Google Cloud.

Arsitektur

blueprint ini menggunakan arsitektur VPC Bersama, di mana Cloud Functions di-deploy dalam project layanan dan dapat mengakses resource yang terletak di jaringan VPC lain.

Diagram berikut menunjukkan arsitektur tingkat tinggi, yang dijelaskan lebih lanjut dalam contoh arsitektur berikutnya.

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

• Cloud Functions memungkinkan Anda menjalankan functions as a service dan mengelola infrastruktur atas nama Anda. Secara default, arsitektur ini men-deploy Cloud Functions hanya dengan alamat IP internal dan tanpa akses ke internet publik.
• Peristiwa pemicu adalah peristiwa yang memicu Cloud Functions. Seperti yang dijelaskan lebih lanjut dalam contoh arsitektur, hal ini dapat berupa peristiwa Cloud Storage, interval terjadwal, atau perubahan di BigQuery.
• Artifact Registry menyimpan container sumber untuk aplikasi Cloud Functions Anda.
• VPC Bersama memungkinkan Anda menghubungkan konektor Akses VPC Serverless di project layanan Anda ke project host. Anda men-deploy jaringan VPC Bersama yang terpisah untuk setiap lingkungan (produksi, non-produksi, dan pengembangan). Desain jaringan ini menyediakan isolasi jaringan di antara lingkungan yang berbeda. Jaringan VPC Bersama memungkinkan Anda mengelola resource jaringan secara terpusat dalam jaringan umum sekaligus mendelegasikan tanggung jawab administratif untuk project layanan.

• Konektor Akses VPC Serverless menghubungkan aplikasi serverless ke jaringan VPC Anda 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 Functions berkomunikasi dengan layanan, sistem penyimpanan, dan resource lain yang mendukung Kontrol Layanan VPC.

  Anda dapat mengonfigurasi Akses VPC Serverless di project host VPC Bersama atau project layanan. Secara default, blueprint ini men-deploy akses VPC Serverless di project host VPC Bersama agar selaras dengan model VPC Bersama untuk memusatkan resource konfigurasi jaringan. Untuk informasi selengkapnya, lihat Perbandingan metode konfigurasi.

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

• Layanan konsumen adalah aplikasi yang ditindaklanjuti oleh Cloud Functions. Layanan konsumen dapat berupa server internal atau layanan Google Cloud lainnya seperti Cloud SQL. Bergantung pada kasus penggunaan Anda, layanan ini mungkin berada di belakang Cloud Next Generation Firewall, di subnet lain, dalam project layanan yang sama dengan Cloud Functions, atau di project layanan lain.

• Secure Web Proxy dirancang untuk mengamankan traffic web keluar, jika diperlukan. Hal ini memungkinkan kebijakan yang fleksibel dan terperinci berdasarkan identitas cloud dan aplikasi web. Blueprint ini menggunakan Secure Web Proxy untuk kebijakan akses terperinci ke traffic web keluar selama fase build Cloud Functions. Blueprint ini menambahkan daftar URL yang diizinkan pada Aturan Kebijakan Keamanan Gateway.

• Cloud NAT menyediakan koneksi keluar ke internet, jika diperlukan. Cloud NAT mendukung penafsiran alamat jaringan sumber (SNAT) untuk resource komputasi tanpa alamat IP publik. Paket respons masuk menggunakan penafsiran alamat jaringan tujuan (DNAT). Anda dapat menonaktifkan Cloud NAT jika Cloud Functions tidak memerlukan akses ke internet. Cloud NAT menerapkan kebijakan jaringan keluar yang terpasang ke Secure Web Proxy.

• 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 Functions.

• Secret Manager menyimpan secret Cloud Functions. Blueprint memasang secrets sebagai volume untuk memberikan tingkat keamanan yang lebih tinggi daripada meneruskan secret sebagai variabel lingkungan.

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

• Cloud Logging mengumpulkan semua log dari layanan Google Cloud untuk disimpan dan diambil oleh alat analisis dan investigasi Anda.

• Cloud Monitoring mengumpulkan dan menyimpan informasi performa dan metrik tentang layanan Google Cloud.

Contoh arsitektur dengan aplikasi serverless yang menggunakan Cloud Storage

Diagram berikut menunjukkan cara menjalankan aplikasi serverless yang mengakses server internal saat terjadi peristiwa tertentu di Cloud Storage.

Selain layanan yang dijelaskan dalam Arsitektur, contoh arsitektur ini menggunakan kombinasi layanan dan fitur Google Cloud berikut:

• Cloud Storage memunculkan peristiwa saat resource, aplikasi, atau pengguna cloud apa pun membuat objek web pada bucket.
• Eventarc merutekan peristiwa dari berbagai resource. Eventarc mengenkripsi peristiwa saat transit dan dalam penyimpanan.
• Pub/Sub peristiwa antrean yang digunakan sebagai input dan pemicu untuk Cloud Functions.
• Aturan firewall Virtual Private Cloud (VPC) mengontrol aliran data ke dalam subnet yang menghosting resource Anda, seperti server internal.
• Server internal berjalan di Compute Engine atau Google Kubernetes Engine dan menghosting aplikasi internal Anda. Jika Anda men-deploy Contoh Cloud Functions Aman dengan Server Internal, Anda akan men-deploy server Apache dengan halaman HTML Hello World. Contoh ini menyimulasikan akses ke aplikasi internal yang menjalankan VM atau container.

Contoh arsitektur dengan Cloud SQL

Diagram berikut menunjukkan cara menjalankan aplikasi serverless yang mengakses layanan yang dihosting Cloud SQL pada interval reguler yang ditentukan di Cloud Scheduler. Anda dapat menggunakan arsitektur ini ketika harus mengumpulkan log, menggabungkan data, dan seterusnya.

Selain layanan yang dijelaskan dalam Arsitektur, contoh arsitektur ini menggunakan kombinasi layanan dan fitur Google Cloud berikut:

• Cloud Scheduler memunculkan peristiwa secara berkala.
• Pub/Sub peristiwa antrean yang digunakan sebagai input dan pemicu untuk Cloud Functions.
• Aturan firewall Virtual Private Cloud (VPC) mengontrol aliran data ke dalam subnet yang menghosting resource Anda, seperti data perusahaan yang disimpan di Cloud SQL.
• Proxy Auth Cloud SQL mengontrol akses ke Cloud SQL.
• Cloud SQL menghosting layanan yang di-peering ke jaringan VPC dan dapat diakses oleh aplikasi serverless. Jika Anda men-deploy contoh Cloud Functions Aman dengan Cloud SQL, Anda akan men-deploy database MySQL dengan database sampel.

Contoh arsitektur dengan data warehouse BigQuery

Diagram berikut menunjukkan cara menjalankan aplikasi serverless yang dipicu saat suatu peristiwa terjadi di BigQuery (misalnya, data ditambahkan atau tabel dibuat).

Selain layanan yang dijelaskan dalam Arsitektur, contoh arsitektur ini menggunakan kombinasi layanan dan fitur Google Cloud berikut:

• BigQuery menghosting data warehouse. Jika Anda men-deploy contoh Cloud Functions Aman yang dipicu oleh BigQuery, Anda akan men-deploy sampel set data dan tabel BigQuery.
• Eventarc memicu Cloud Functions saat peristiwa tertentu terjadi di BigQuery.

Struktur organisasi

Resource Manager memungkinkan Anda 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-dasar perusahaan. Anda men-deploy project yang ditentukan oleh blueprint ke dalam folder berikut: Common, Production, Non-production, dan Dev.

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 Enterprise Foundation yang digunakan oleh blueprint ini.

Folder	Deskripsi
Bootstrap	Berisi resource yang diperlukan untuk men-deploy blueprint fondasi 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.
Development	Berisi project yang memiliki resource cloud yang saat ini sedang dikembangkan. Dalam blueprint ini, folder Development 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 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 VPC Bersama	Project ini mencakup aturan masuk firewall dan resource apa pun 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, tentukan nama project ini, dan blueprint akan men-deploy konektor Akses VPC Serverless, Cloud NAT, dan Cloud Secure Web Proxy.
Project layanan VPC Bersama	Project ini mencakup aplikasi serverless, Cloud Functions, dan konektor Akses VPC Serverless Anda. Anda dapat melampirkan 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 Functions dan layanan yang diperlukan untuk kasus penggunaan Anda, seperti Cloud SQL, Cloud Scheduler, Cloud Storage, atau BigQuery. Saat menerapkan kode Terraform, Anda menentukan nama project ini, dan blueprint akan men-deploy Cloud KMS. Jika Anda menggunakan modul Secure Serverless Harness dalam blueprint serverless untuk Cloud Functions, Artifact Registry juga akan di-deploy.
Project keamanan	Project ini mencakup layanan khusus keamanan Anda, seperti Cloud KMS dan Secret Manager. Nama default project keamanan adalah prj-bu1-p-sec. Jika Anda men-deploy blueprint ini setelah men-deploy blueprint security foundation, project project keamanan akan dibuat bersamaan dengan project secret blueprint enterprise foundation (prj-bu1-p-env-secrets). Untuk informasi selengkapnya tentang project blueprint foundation perusahaan, lihat Project. Jika Anda men-deploy beberapa instance blueprint ini tanpa blueprint dasar-dasar perusahaan, 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 [e-mail]	Project layanan	Cloud Functions Admin (roles/cloudfunctions.admin) Compute Network User (roles/compute.networkUser) Penampil Jaringan Compute (roles/compute.networkViewer) Cloud Run Admin (roles/run.admin)
Administrator keamanan serverless [e-mail]	Project keamanan	Pembaca Artifact Registry (roles/artifactregistry.reader) Cloud Functions Admin (roles/cloudfunctions.admin) Viewer Cloud KMS (roles/cloudkms.viewer) Cloud Run Viewer (roles/run.viewer)
Developer Cloud Functions [e-mail]	Project keamanan	Penulis Artifact Registry (roles/artifactregistry.writer) Cloud Functions Developer (roles/cloudfunctions.developer) Pengenkripsi Cloud KMS CryptoKey (roles/cloudkms.cryptoKeyEncrypter)
Pengguna Cloud Functions [e-mail]	Project layanan VPC Bersama	Cloud Functions Invoker (roles/cloudfunctions.invoker)

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 untuk melakukan tugas.
• Mengamankan koneksi jaringan melalui desain batas kepercayaan, yang mencakup segmentasi jaringan, kebijakan organisasi, dan kebijakan firewall.
• Amankan konfigurasi untuk setiap layanan.
• Identifikasi persyaratan kepatuhan atau peraturan apa pun untuk infrastruktur yang menghosting workload serverless dan menetapkan tingkat risiko.
• Konfigurasi pemantauan dan logging yang memadai guna mendukung jejak audit untuk operasi keamanan dan manajemen insiden.

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.

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 berikut:

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

Selain itu, Anda membuat data DNS untuk menyelesaikan *.googleapis.com menjadi restricted.googleapis.com.

Untuk informasi selengkapnya, lihat Mengonfigurasi Akses Google Pribadi.

Kontrol perimeter

Seperti ditunjukkan di bagian Arsitektur, Anda menempatkan resource untuk aplikasi serverless di perimeter keamanan Kontrol Layanan VPC yang terpisah. Perimeter ini membantu mengurangi dampak yang luas dari kompromi sistem atau layanan. Namun, perimeter keamanan ini tidak berlaku untuk proses build Cloud Functions saat Cloud Build otomatis mem-build kode Anda ke dalam image container dan mendorong image tersebut ke Artifact Registry. Dalam skenario ini, buat aturan masuk untuk akun layanan Cloud Build di perimeter layanan.

Kebijakan akses

Untuk membantu memastikan bahwa hanya akun utama tertentu (pengguna atau layanan) yang dapat mengakses resource dan data, Anda perlu 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 informasi selengkapnya, lihat Atribut tingkat akses.

Akun layanan dan kontrol akses

Akun layanan adalah akun untuk beban kerja aplikasi atau komputasi, bukan untuk pengguna akhir individu. Untuk menerapkan prinsip hak istimewa terendah dan prinsip pemisahan tugas, Anda membuat akun layanan dengan izin terperinci dan akses terbatas ke resource. Akun layanan tersebut adalah sebagai berikut:

• Akun layanan Cloud Functions (cloudfunction_sa) yang memiliki peran berikut:

  • Penampil Jaringan Compute (roles/compute.networkViewer)
  • Penerima Peristiwa Eventarc (roles/eventarc.eventReceiver)
  • Invoker Cloud Run (roles/run.invoker)
  • Secret Manager Secret Accessor (roles/secretmanager.secretAccessor)

  Untuk informasi selengkapnya, lihat Mengizinkan Cloud Functions untuk mengakses secret.

  Cloud Functions menggunakan akun layanan ini untuk memberikan izin hanya ke topik Pub/Sub tertentu dan membatasi sistem peristiwa Eventarc dari resource komputasi Cloud Functions di Contoh arsitektur dengan aplikasi serverless menggunakan Cloud Storage dan Contoh arsitektur dengan data warehouse BigQuery.

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

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

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

• Identitas layanan untuk menjalankan Cloud Functions (cloudfunction_sa) yang memiliki peran [Pengguna Akses VPC Serverless (roles/vpcaccess.user)](/iam/docs/understanding-roles#vpcaccess.user) dan Pengguna Akun Layanan (roles/iam.serviceAccountUser).

• Suatu akun layanan untuk Google API (cloud_services_sa ) yang memiliki Compute Network User (roles/compute.networkUser ) untuk menjalankan proses Google internal atas nama Anda.

• Suatu identitas layanan untuk Cloud Functions (cloud_serverless_sa) yang memiliki peran Pembaca Artifact Registry (roles/artifactregistry.reader). Akun layanan ini memberikan akses ke Artifact Registry dan CMEK.

• Identitas layanan untuk Eventarc (eventarc_sa) yang memiliki peran Cloud KMS CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) dan Cloud KMS CryptoKey Encrypter (roles/cloudkms.cryptoKeyEncrypter).

• Identitas layanan untuk Artifact Registry (artifact_sa) dengan peran CryptoKey Decrypter (roles/cloudkms.cryptoKeyDecrypter) dan Cloud KMS dalam Encrypter (roles/cloudkms.cryptoKeyEncrypter).

Pengelolaan kunci

Untuk memvalidasi integritas dan membantu melindungi data Anda dalam penyimpanan, gunakan CMEK dengan Artifact Registry, Cloud Functions, Cloud Storage, dan Eventarc. CMEK memberi Anda kontrol yang lebih besar atas kunci enkripsi. Berikut ini CMEK yang digunakan:

• Kunci software untuk Artifact Registry yang mengesahkan kode untuk aplikasi serverless Anda.
• Kunci enkripsi untuk mengenkripsi image container yang di-deploy oleh Cloud Functions.
• Kunci enkripsi untuk peristiwa Eventarc yang mengenkripsi saluran pesan dalam penyimpanan.
• Kunci enkripsi untuk membantu melindungi data di Cloud Storage.

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

Pengelolaan secret

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

Saat men-deploy blueprint ini dengan blueprint Enterprise Foundation, Anda harus menambahkan secret Anda ke project secret sebelum menerapkan kode Terraform. Blueprint akan memberikan peran Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) ke akun layanan Cloud Functions. Untuk informasi selengkapnya, lihat Menggunakan secret.

Kebijakan organisasi

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

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

Batasan kebijakan	Deskripsi	Nilai yang direkomendasikan
Setelan masuk yang diizinkan (Cloud Functions) constraints/cloudfunctions.allowedIngressSettings	Mengizinkan traffic masuk hanya dari layanan internal atau load balancer HTTP(S) eksternal. Nilai defaultnya adalah ALLOW_ALL.	ALLOW_INTERNAL_ONLY
Perlu Konektor VPC (Cloud Functions) constraints/cloudfunctions.requireVPCConnector	Memerlukan penentuan konektor Akses VPC Serverless saat men-deploy fungsi. Saat batasan ini diterapkan, fungsi harus menentukan konektor Akses VPC Serverless. Nilai defaultnya adalah false.	true
Setelan keluar Konektor VPC yang diizinkan (Cloud Functions) cloudfunctions.allowedVpcConnectorEgressSettings	Mewajibkan semua traffic keluar untuk Cloud Functions agar menggunakan konektor Akses VPC Serverless. Defaultnya adalah PRIVATE_RANGES_ONLY.	ALL_TRAFFIC

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 akses data.
• Memastikan bahwa audit yang tepat dilakukan.
• Mendukung operasi keamanan dan kemampuan manajemen insiden di organisasi Anda.

Logging

Untuk membantu memenuhi persyaratan audit dan mendapatkan insight tentang project, konfigurasikan Kemampuan Observasi Google Cloud 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.
• Tambahkan CMEK ke sink logging.

Untuk semua layanan dalam project, pastikan log Anda menyertakan informasi tentang penulisan data dan akses administratif. Untuk mengetahui informasi lebih lanjut 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 telah terjadi peristiwa keamanan. Misalnya, Anda dapat menggunakan pemberitahuan agar analis keamanan mengetahui saat izin diubah pada peran IAM. Untuk informasi selengkapnya tentang mengonfigurasi pemberitahuan Security Command Center, lihat Menyiapkan notifikasi temuan.

Dasbor Pemantauan Cloud Functions membantu Anda memantau performa dan kondisi Cloud Functions. Alat ini menyediakan berbagai metrik dan log yang dapat Anda gunakan untuk mengidentifikasi dan memecahkan masalah. Dasbor ini juga menyertakan sejumlah fitur yang dapat membantu Anda meningkatkan performa fungsi, seperti kemampuan untuk menetapkan pemberitahuan dan kuota.

Untuk informasi selengkapnya, lihat Pemantauan Cloud Functions.

Untuk mengekspor pemberitahuan, lihat dokumen berikut:

• Pengantar pemberitahuan
• Ekspor metrik Cloud Monitoring

Proses debug dan pemecahan masalah

Anda dapat menjalankan Uji Konektivitas untuk membantu Anda men-debug masalah konfigurasi jaringan antara Cloud Functions 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 mengaturnya secara terpisah. Untuk informasi selengkapnya, lihat Membuat dan menjalankan Uji Konektivitas.

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 fondasi perusahaan (direkomendasikan). Opsi ini men-deploy resource untuk blueprint ini di perimeter Kontrol Layanan VPC yang sama dengan yang digunakan oleh blueprint Enterprise Foundation. Untuk informasi selengkapnya, lihat Cara menyesuaikan Foundation v3.0.0 untuk deployment Cloud Functions Aman. Opsi ini juga menggunakan project secret yang Anda buat saat men-deploy blueprint Enterprise Foundation.	Gunakan modul Terraform ini: secure-cloud-function-core secure-serverless-net secure-web-proxy
Instal blueprint ini tanpa menginstal blueprint security foundation. Opsi ini mengharuskan Anda membuat perimeter Kontrol Layanan VPC.	Gunakan modul Terraform ini: secure-cloud-function-core secure-serverless-harness secure-serverless-net secure-cloud-function-security secure-web-proxy secure-cloud-function

Menyatukan semuanya

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

1. Tinjau README blueprint untuk memastikan bahwa Anda memenuhi semua prasyarat.
2. Di lingkungan pengujian Anda, untuk melihat cara kerja blueprint, deploy salah satu contoh. Contoh ini cocok dengan contoh arsitektur yang dijelaskan dalam Arsitektur. 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 (misalnya 1) dan jalankan melalui skenario deployment standar.
   3. Bekerjasamalah dengan tim engineering dan operasi aplikasi di perusahaan Anda untuk menguji akses mereka ke project dan memverifikasi apakah mereka dapat berinteraksi dengan solusi dengan cara yang diharapkan.
3. Deploy blueprint tersebut ke lingkungan Anda.

Langkah selanjutnya

• Tinjau blueprint Enterprise Foundation Google Cloud untuk lingkungan dasar yang aman.
• Untuk melihat detail blueprint, baca README konfigurasi Terraform.
• Untuk men-deploy aplikasi serverless menggunakan Cloud Run, lihat Men-deploy arsitektur serverless yang aman menggunakan Cloud Run.