Mengamankan Azure Functions
Dalam banyak hal, merencanakan pengembangan, penyebaran, dan pengoperasian fungsi tanpa server yang aman sama halnya dengan aplikasi berbasis web atau cloud. Azure App Service menyediakan infrastruktur hosting untuk aplikasi fungsi Anda. Artikel ini menyediakan strategi keamanan untuk menjalankan kode fungsi Anda, dan bagaimana App Service dapat membantu mengamankan fungsi Anda.
Komponen platform App Services, termasuk VM Azure, penyimpanan, koneksi jaringan, kerangka kerja web, fitur manajemen dan integrasi, diamankan dan diperkuat secara aktif. App Service menjalani pemeriksaan kepatuhan yang ketat secara berkelanjutan untuk memastikan bahwa:
- Sumber daya aplikasi Anda dilindungi dari sumber daya Azure pelanggan lain.
- Instans VM dan perangkat lunak runtime diperbarui secara berkala untuk mengatasi kerentanan yang baru ditemukan.
- Komunikasi rahasia (seperti string koneksi) antara aplikasi Anda dan sumber daya Azure lainnya (seperti SQL Database) tetap berada dalam Azure dan tidak melewati batas jaringan apa pun. Rahasia selalu dienkripsi saat disimpan.
- Semua komunikasi melalui fitur konektivitas App Service, seperti koneksi hibrid, dienkripsi.
- Koneksi dengan alat manajemen jarak jauh seperti Azure PowerShell, Azure CLI, SDK Azure, REST API, semuanya dienkripsi.
- Manajemen ancaman 24 jam melindungi infrastruktur dan platform dari malware, distributed denial-of-service (DDoS), man-in-the-middle (MITM), dan ancaman lainnya.
Untuk informasi selengkapnya tentang infrastruktur dan keamanan platform di Azure, lihat Pusat Kepercayaan Azure.
Untuk serangkaian rekomendasi keamanan yang mengikuti tolok ukur keamanan cloud Microsoft, lihat Garis Besar Keamanan Azure untuk Azure Functions.
Mengamankan operasi
Bagian ini memandu Anda mengonfigurasi dan menjalankan aplikasi fungsi seaman mungkin.
Defender for Cloud
Defender for Cloud terintegrasi dengan aplikasi fungsi Anda di portal. Layanan gratis ini menilai dengan cepat potensi kerentanan keamanan yang terkait dengan konfigurasi. Aplikasi fungsi yang berjalan dalam paket khusus juga dapat menggunakan fitur keamanan yang ditingkatkan dari Defender for Cloud dengan biaya tambahan. Untuk mempelajari selengkapnya, lihat Memproteksi aplikasi web dan API Azure App Service Anda.
Mencatat dan memantau
Salah satu cara untuk mendeteksi serangan adalah melalui pemantauan aktivitas dan analitik pengelogan. Fungsi terintegrasi dengan Application Insights untuk mengumpulkan data log, performa, dan kesalahan untuk aplikasi fungsi Anda. Application Insights secara otomatis mendeteksi anomali performa dan menyertakan alat analitik yang canggih untuk membantu Anda mendiagnosis masalah dan memahami bagaimana aplikasi web Anda digunakan. Untuk mempelajari selengkapnya, lihat Memantau Azure Functions.
Azure Functions juga terintegrasi dengan Log Azure Monitor agar Anda dapat memperkuat log aplikasi fungsi dengan peristiwa sistem untuk mempermudah analisis. Anda dapat menggunakan setelan diagnostik untuk mengonfigurasi ekspor streaming log platform dan metrik fungsi Anda ke tujuan yang dipilih, misalnya ruang kerja Analitik Log. Untuk mempelajari selengkapnya, lihat Memantau Azure Functions dengan Log Azure Monitor.
Untuk deteksi ancaman tingkat perusahaan dan otomatisasi respons, alirkan log dan peristiwa Anda ke ruang kerja Analitik Logs. Anda kemudian dapat menghubungkan Microsoft Azure Sentinel ke ruang kerja ini. Untuk mempelajari lebih lanjut, lihat Apa itu Microsoft Azure Sentinel.
Untuk rekomendasi pengamatan keamanan lainnya, lihat Garis besar keamanan Azure untuk Azure Functions.
Memerlukan HTTPS
Secara default, klien dapat terhubung ke titik akhir fungsi menggunakan HTTP atau HTTPS. Anda harus mengalihkan HTTP ke HTTP karena HTTPS menggunakan protokol SSL/TLS untuk menyediakan koneksi aman yang terenkripsi dan terautentikasi. Untuk mempelajari caranya, lihat Memberlakukan HTTPS.
Ketika Anda memerlukan HTTPS, Anda juga akan Memerlukan versi TLS terbaru. Untuk mempelajari caranya, lihat Menerapkan versi TLS.
Untuk informasi selengkapnya, lihat Mengamankan koneksi (TSL).
Kunci akses fungsi
Azure Functions memungkinkan Anda menggunakan kunci untuk mempersulit akses titik akhir fungsi HTTP Anda selama pengembangan. Kecuali tingkat akses HTTP pada fungsi yang dipicu HTTP diatur ke anonymous, permintaan harus menyertakan kunci akses API dalam permintaan.
Meskipun kunci menyediakan mekanisme keamanan default, Anda mungkin ingin mempertimbangkan opsi lain untuk mengamankan titik akhir HTTP dalam produksi. Misalnya, ini bukan praktik yang baik untuk mendistribusikan rahasia bersama di aplikasi publik. Jika fungsi Anda dipanggil dari klien publik, Anda mungkin ingin mempertimbangkan untuk menerapkan mekanisme keamanan lain. Untuk mempelajari lebih lanjut, lihat Mengamankan titik akhir HTTP dalam produksi.
Saat memperpanjang nilai kunci fungsi, Anda harus mendistribusikan ulang nilai kunci yang diperbarui secara manual ke semua klien yang memanggil fungsi Anda.
Cakupan otorisasi (tingkat fungsi)
Ada dua ruang lingkup akses untuk kunci tingkat fungsi:
Fungsi: Kunci ini hanya berlaku untuk fungsi tertentu di mana kunci tersebut ditentukan. Ketika digunakan sebagai kunci API, ini hanya memungkinkan akses ke fungsi tersebut.
Host: Kunci dengan lingkup host dapat digunakan untuk mengakses semua fungsi dalam aplikasi fungsi. Saat digunakan sebagai kunci API, ini memungkinkan akses ke fungsi apa pun dalam aplikasi fungsi.
Setiap kunci diberi nama untuk referensi, dan ada kunci default (bernama "default") di tingkat fungsi dan host. Kunci fungsi lebih diprioritaskan daripada kunci host. Ketika dua kunci didefinisikan dengan nama yang sama, kunci fungsi selalu digunakan.
Kunci master (tingkat admin)
Setiap aplikasi fungsi juga memiliki kunci host tingkat admin bernama _master. Selain menyediakan akses tingkat host ke semua fungsi di aplikasi, kunci master juga menyediakan akses administratif ke API REST runtime. Kunci ini tidak dapat dicabut. Ketika Anda mengatur tingkat akses admin, permintaan harus menggunakan kunci master; kunci lainnya mengakibatkan kegagalan akses.
Perhatian
Karena izin yang ditinggikan di aplikasi fungsi yang diberikan oleh kunci master, Anda tidak boleh berbagi kunci ini dengan pihak ketiga atau mendistribusikannya di aplikasi klien asli. Berhati-hatilah saat memilih tingkat akses admin.
Kunci sistem
Ekstensi tertentu mungkin memerlukan kunci yang dikelola sistem untuk mengakses titik akhir webhook. Kunci sistem dirancang untuk titik akhir fungsi khusus ekstensi yang dipanggil oleh komponen internal. Misalnya, pemicu Event Grid mengharuskan langganan menggunakan kunci sistem saat memanggil titik akhir pemicu. Durable Functions juga menggunakan kunci sistem untuk memanggil API ekstensi Durable Task.
Ruang lingkup kunci sistem ditentukan oleh ekstensi, tetapi umumnya berlaku untuk seluruh aplikasi fungsi. Kunci sistem hanya dapat dibuat oleh ekstensi tertentu, dan Anda tidak dapat secara eksplisit mengatur nilainya. Seperti kunci lainnya, Anda dapat menghasilkan nilai baru untuk kunci dari portal atau dengan menggunakan API utama.
Perbandingan kunci
Tabel berikut membandingkan penggunaan untuk berbagai jenis kunci akses:
| Perbuatan | Cakupan | Kunci yang valid |
|---|---|---|
| Menjalankan fungsi | Fungsi spesifik | Fungsi |
| Menjalankan fungsi | Fungsi any | Fungsi atau host |
| Memanggil titik akhir admin | Aplikasi Fungsi | Host (hanya master) |
| Memanggil API ekstensi Durable Task | Aplikasi fungsi1 | Sistem2 |
| Memanggil Webhook khusus ekstensi (internal) | Aplikasi fungsi1 | sistem2 |
1Ruang lingkup ditentukan oleh ekstensi.
2Nama tertentu yang ditetapkan oleh ekstensi.
Untuk mempelajari selengkapnya tentang kunci akses, lihat artikel pengikatan pemicu HTTP.
Repositori rahasia
Secara default, kunci disimpan dalam kontainer penyimpanan Blob di akun yang disediakan oleh pengaturan AzureWebJobsStorage. Anda dapat menggunakan pengaturan AzureWebJobsSecretStorageType untuk mengambil alih perilaku ini dan menyimpan kunci di lokasi yang berbeda.
| Lokasi | Nilai | Deskripsi |
|---|---|---|
| Akun penyimpanan kedua | blob |
Menyimpan kunci dalam penyimpanan Blob dari akun penyimpanan yang berbeda, berdasarkan URL SAS di AzureWebJobsSecretStorageSas. |
| Sistem file | files |
Kunci dipertahankan pada sistem file, yang merupakan default di Fungsi v1.x. |
| Azure Key Vault | keyvault |
Brankas kunci yang diatur di AzureWebJobsSecretStorageKeyVaultUri digunakan untuk menyimpan kunci. |
| Rahasia Kubernetes | kubernetes |
Sumber daya yang diatur di AzureWebJobsKubernetesSecretName digunakan untuk menyimpan kunci. Hanya didukung saat menjalankan runtime Functions di Kube. Azure Functions Core Tools menghasilkan nilai secara otomatis saat disebarkan ke Kubernetes. |
Saat menggunakan Key Vault untuk penyimpanan kunci, pengaturan aplikasi yang Anda butuhkan bergantung pada jenis identitas terkelola. Fungsi runtime versi 3.x hanya mendukung identitas terkelola yang ditetapkan sistem.
| Nama pengaturan | Ditetapkan sistem | Ditetapkan pengguna | Pendaftaran aplikasi |
|---|---|---|---|
| AzureWebJobsSecretStorageKeyVaultUri | ✓ | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientId | X | ✓ | ✓ |
| AzureWebJobsSecretStorageKeyVaultClientSecret | X | X | ✓ |
| AzureWebJobsSecretStorageKeyVaultTenantId | X | X | ✓ |
Autentikasi/otorisasi
Meskipun tombol fungsi dapat memberikan beberapa mitigasi untuk akses yang tidak diinginkan, satu-satunya cara untuk benar-benar mengamankan titik akhir fungsi Anda adalah dengan menerapkan autentikasi positif dari klien yang mengakses fungsi Anda. Anda kemudian dapat membuat keputusan otorisasi berdasarkan identitas.
Mengaktifkan Autentikasi/Otorisasi App Service
Platform App Service memungkinkan Anda menggunakan ID Microsoft Entra dan beberapa idP pihak ketiga untuk mengautentikasi klien. Anda dapat menggunakan strategi ini untuk menerapkan aturan otorisasi kustom untuk fungsi Anda, dan Anda dapat bekerja dengan informasi pengguna dari kode fungsi Anda. Untuk mempelajari lebih lanjut, lihat Autentikasi dan otorisasi di Azure App Service dan Bekerja dengan identitas klien.
Menggunakan Azure API Management (APIM) untuk mengautentikasi permintaan
APIM menyediakan berbagai opsi keamanan API untuk permintaan yang masuk. Untuk mempelajari lebih lanjut, lihat Kebijakan autentikasi API Management. Dengan berlakunya APIM, Anda dapat mengonfigurasi aplikasi fungsi untuk menerima permintaan hanya dari alamat IP instans APIM Anda. Untuk mempelajari lebih lanjut, lihat Pembatasan alamat IP.
Izin
Seperti halnya aplikasi atau layanan apa pun, tujuannya adalah menjalankan aplikasi fungsi Anda dengan izin serendah mungkin.
Izin pengelolaan pengguna
Functions mendukung kontrol akses berbasis peran Azure (Azure RBAC) bawaan. Peran Azure yang didukung oleh Functions adalah Kontributor, Pemilik, dan Pembaca.
Izin menjadi efektif di tingkat aplikasi fungsi. Peran Kontributor diperlukan untuk melakukan sebagian besar tugas tingkat aplikasi fungsi. Anda juga memerlukan peran Kontributor bersama dengan izin Pembaca Pemantauan untuk dapat menampilkan data log di Application Insights. Hanya peran Pemilik yang dapat menghapus aplikasi fungsi.
Menata fungsi menurut hak istimewa
String koneksi dan kredensial lain yang disimpan dalam pengaturan aplikasi memberikan sekumpulan izin yang sama di sumber daya terkait pada semua fungsi dalam aplikasi fungsi. Pertimbangkan untuk mengurangi jumlah fungsi dengan akses ke kredensial tertentu dengan memindahkan fungsi yang tidak menggunakan kredensial tersebut ke aplikasi fungsi terpisah. Anda selalu dapat menggunakan teknik seperti penautan fungsi untuk meneruskan data antar fungsi di berbagai aplikasi fungsi.
Identitas Terkelola
Identitas terkelola dari MICROSOFT Entra ID memungkinkan aplikasi Anda mengakses sumber daya lain yang dilindungi Microsoft Entra dengan mudah seperti Azure Key Vault. Identitas dikelola oleh platform Azure dan tidak mengharuskan Anda memprovisikan atau memutar rahasia. Untuk informasi selengkapnya tentang identitas terkelola di ID Microsoft Entra, lihat Identitas terkelola untuk sumber daya Azure.
Aplikasi Anda dapat diberikan dua jenis identitas:
- Identitas yang ditetapkan sistem terkait dengan aplikasi Anda dan dihapus jika aplikasi Anda dihapus. Aplikasi hanya dapat memiliki satu identitas yang ditetapkan sistem.
- Identitas yang ditetapkan pengguna adalah sumber daya Azure mandiri yang dapat ditetapkan ke aplikasi Anda. Aplikasi dapat memiliki beberapa identitas yang ditetapkan pengguna.
Identitas terkelola dapat digunakan sebagai tempat rahasia untuk koneksi dari beberapa pemicu dan pengikatan. Lihat Koneksi berbasis identitas.
Untuk informasi selengkapnya, lihat Cara menggunakan identitas terkelola untuk App Service dan Azure Functions.
Membatasi akses CORS
Berbagi sumber daya lintas asal (CORS) adalah cara untuk memungkinkan aplikasi web berjalan di domain lain untuk membuat permintaan ke titik akhir pemicu HTTP Anda. App Service menyediakan dukungan bawaan untuk menyerahkan header CORS yang diperlukan dalam permintaan HTTP. Aturan CORS didefinisikan pada tingkat aplikasi fungsi.
Meskipun sangat diinginkan untuk menggunakan wildcard yang memungkinkan semua situs mengakses titik akhir Anda, langkah ini bertentangan dengan tujuan CORS untuk membantu mencegah serangan scripting lintas situs. Sebagai gantinya, tambahkan entri CORS terpisah untuk domain setiap aplikasi web yang harus mengakses titik akhir Anda.
Mengelola rahasia
Agar dapat terhubung ke berbagai layanan dan sumber daya yang diperlukan untuk menjalankan kode Anda, aplikasi fungsi harus dapat mengakses rahasia, seperti string koneksi dan kunci layanan. Bagian ini menjelaskan cara menyimpan rahasia yang diperlukan oleh fungsi Anda.
Jangan pernah menyimpan rahasia dalam kode fungsi Anda.
Pengaturan aplikasi
Secara default, Anda menyimpan string koneksi dan rahasia yang digunakan oleh aplikasi fungsi dan pengikatan sebagai pengaturan aplikasi. Hal ini membuat kredensial tersedia untuk kode fungsi Anda dan berbagai pengikatan yang digunakan oleh fungsi. Nama pengaturan aplikasi (kunci) digunakan untuk mengambil nilai aktual, yang bersifat rahasia.
Misalnya, setiap aplikasi fungsi memerlukan akun penyimpanan terkait yang digunakan oleh runtime. Secara default, koneksi ke akun penyimpanan ini disimpan dalam pengaturan aplikasi bernama AzureWebJobsStorage.
Pengaturan aplikasi dan string koneksi disimpan dalam enkripsi pada Azure. Mereka didekripsi hanya sebelum disuntikkan ke memori proses aplikasi Anda saat aplikasi dimulai. Kunci enkripsi diputar secara teratur. Jika Anda lebih suka mengelola penyimpanan aman atas rahasia Anda, pengaturan aplikasi seharusnya menjadi referensi ke Azure Key Vault.
Anda juga dapat mengenkripsi pengaturan secara default di file local.settings.json saat mengembangkan fungsi di komputer lokal Anda. Untuk informasi selengkapnya, lihat Mengenkripsi file pengaturan lokal.
Referensi Key Vault
Meskipun pengaturan aplikasi cukup untuk sebagian besar fungsi, Anda mungkin ingin berbagi rahasia yang sama di beberapa layanan. Dalam hal ini, penyimpanan rahasia yang berlebihan memperbesar potensi kerentanan. Pendekatan yang lebih aman adalah ke layanan penyimpanan rahasia pusat dan menggunakan referensi ke layanan ini, alih-alih rahasia itu sendiri.
Azure Key Vault adalah layanan yang menyediakan manajemen rahasia terpusat, dengan kontrol penuh atas kebijakan akses dan riwayat audit. Anda dapat menggunakan referensi Key Vault di tempat string atau kunci koneksi di pengaturan aplikasi Anda. Untuk mempelajari selengkapnya, lihat Menggunakan referensi Key Vault untuk App Service dan Azure Functions.
Koneksi berbasis identitas
Identitas dapat digunakan sebagai pengganti rahasia untuk menghubungkan ke beberapa sumber daya. Keuntungannya adalah Anda tidak memerlukan manajemen rahasia dan memperlancar kontrol akses dan audit.
Saat Anda menulis kode yang membuat koneksi ke layanan Azure yang mendukung autentikasi Microsoft Entra, Anda dapat memilih untuk menggunakan identitas alih-alih rahasia atau string koneksi. Detail untuk kedua metode koneksi tercakup dalam dokumentasi untuk setiap layanan.
Beberapa ekstensi pemicu dan pengikatan Azure Functions dapat dikonfigurasi menggunakan koneksi berbasis identitas. Saat ini, yang termasuk dalam ekstensi tersebut adalah Azure Blob dan Azure Queue. Untuk informasi tentang cara mengonfigurasi ekstensi ini dalam menggunakan identitas, lihat Cara menggunakan koneksi berbasis identitas di Azure Functions.
Atur kuota penggunaan
Pertimbangkan untuk mengatur kuota penggunaan pada fungsi yang berjalan dalam rencana Consumption. Saat Anda menetapkan batas harian GB/detik pada jumlah total eksekusi fungsi di aplikasi fungsi Anda, eksekusi dihentikan saat batas tercapai. Ini berpotensi membantu mengurangi kode berbahaya yang menjalankan fungsi Anda. Untuk mempelajari cara memperkirakan konsumsi untuk fungsi Anda, lihat Memperkirakan biaya rencana Consumption.
Validasi Data
Pemicu dan pengikatan yang digunakan oleh fungsi Anda tidak memberikan validasi data tambahan. Kode Anda harus memvalidasi data apa pun yang diterima dari pemicu atau pengikatan input. Jika layanan upstream disusupi, jangan biarkan input yang tak tervalidasi mengalir melalui fungsi Anda. Misalnya, jika fungsi Anda menyimpan data dari antrean Azure Storage dalam database hubungan, validasikan data dan buatlah parameter perintah untuk menghindari serangan injeksi SQL.
Jangan berasumsi bahwa data yang masuk ke fungsi Anda telah divalidasi atau dibersihkan. Ada baiknya juga untuk memastikan validitas data yang ditulis ke pengikatan output.
Menangani kesalahan
Meskipun tampaknya sepele, penting untuk menulis penanganan kesalahan yang baik dalam fungsi Anda. Kesalahan yang tidak tertangani akan meluap ke host dan ditangani oleh runtime. Pengikatan yang berbeda menangani pemrosesan kesalahan yang berbeda pula. Untuk mempelajari selengkapnya, lihat Penanganan kesalahan Azure Functions.
Menonaktifkan penelusuran kesalahan jarak jauh
Pastikan penelusuran kesalahan jarak jauh dinonaktifkan, kecuali ketika Anda secara aktif menelusur kesalahan fungsi Anda. Anda dapat menonaktifkan pengaturan jarak jauh di tab Pengaturan Umum di Konfigurasi aplikasi fungsi Anda di portal.
Membatasi akses CORS
Azure Functions mendukung berbagi sumber daya lintas asal (CORS). CORS dikonfigurasi di portal dan melalui Azure CLI. Daftar asal yang diizinkan CORS berlaku di tingkat aplikasi fungsi. Dengan mengaktifkan CORS, respons menyertakan header Access-Control-Allow-Origin. Untuk mengetahui informasi selengkapnya, lihat Berbagi sumber daya lintas asal.
Jangan gunakan kartu bebas dalam daftar asal yang diizinkan. Sebagai gantinya, cantumkan domain tertentu yang Anda harapkan untuk mendapatkan permintaan.
Menyimpan data terenkripsi
Azure Storage mengenkripsi semua data di akun penyimpanan ketika tidak aktif. Untuk informasi lebih lanjut, lihat Enkripsi Azure Storage untuk data tidak aktif.
Secara default, data dienkripsi dengan kunci yang dikelola Microsoft. Untuk kontrol tambahan atas kunci enkripsi, Anda dapat menyediakan kunci yang dikelola pelanggan untuk digunakan pada enkripsi blob dan data file. Kunci ini harus ada di Azure Key Vault for Functions untuk dapat mengakses akun penyimpanan. Untuk mempelajari lebih lanjut, lihat Enkripsi ketika tidak aktif menggunakan kunci yang dikelola pelanggan.
Mengamankan sumber daya terkait
Aplikasi fungsi sering bergantung pada sumber daya tambahan, jadi bagian dari mengamankan aplikasi mengamankan sumber daya eksternal ini. Minimal, sebagian besar aplikasi fungsi menyertakan dependensi pada Application Insights dan Azure Storage. Lihat garis besar keamanan Azure untuk Azure Monitor dan garis besar keamanan Azure untuk Penyimpanan untuk panduan tentang mengamankan sumber daya ini.
Penting
Akun penyimpanan digunakan untuk menyimpan data aplikasi penting, terkadang termasuk kode aplikasi itu sendiri. Anda harus membatasi akses dari aplikasi dan pengguna lain ke akun penyimpanan.
Anda juga harus berkonsultasi dengan panduan untuk jenis sumber daya apa pun yang bergantung pada logika aplikasi Anda, baik sebagai pemicu dan pengikatan dan dari kode fungsi Anda.
Mengamankan penyebaran
Implementasi integrasi Azure Functions mempermudah penerbitan kode proyek fungsi lokal ke Azure. Penting untuk memahami cara kerja penyebaran saat mempertimbangkan keamanan untuk topologi Azure Functions.
Kredensial penyebaran
Penyebaran App Service memerlukan sekumpulan kredensial penyebaran. Kredensial penyebaran ini digunakan untuk mengamankan penyebaran aplikasi fungsi Anda. Kredensial penyebaran dikelola oleh platform App Service dan dienkripsi saat istirahat.
Ada dua jenis kredensial penyebaran:
Kredensial tingkat pengguna: satu set kredensial untuk seluruh akun Azure. Ini dapat digunakan untuk menerapkan ke Layanan Aplikasi untuk aplikasi apa pun, dalam langganan apa pun, bahwa akun Azure memiliki izin untuk mengakses. Ini adalah set default yang muncul di GUI portal (seperti Ringkasan dan Propertihalaman sumber aplikasi). Saat pengguna diberikan akses aplikasi melalui Role-Based Access Control (RBAC) atau izin koadmin, pengguna tersebut dapat menggunakan kredensial tingkat pengguna sendiri hingga akses dicabut. Jangan bagikan kredensial ini dengan pengguna Azure lainnya.
Kredensial tingkat aplikasi: satu set kredensial untuk setiap aplikasi. Ini dapat digunakan untuk diterapkan ke aplikasi itu saja. Kredensial untuk setiap aplikasi dibuat secara otomatis saat pembuatan aplikasi. Mereka tidak dapat dikonfigurasi secara manual, tetapi dapat direset kapan saja. Agar pengguna diberikan akses ke kredensial tingkat aplikasi melalui (RBAC), pengguna tersebut harus menjadi kontributor atau lebih tinggi pada aplikasi (termasuk peran bawaan Kontributor Situs Web). Pembaca tidak diizinkan untuk menerbitkan, dan tidak dapat mengakses kredensial tersebut.
Saat ini, Key Vault tidak didukung untuk kredensial penyebaran. Untuk mempelajari selengkapnya tentang mengelola kredensial penggunaan, lihat Mengonfigurasi kredensial penggunaan untuk Azure App Service.
Nonaktifkan FTP
Secara default, setiap aplikasi fungsi memiliki titik akhir FTP diaktifkan. Titik akhir FTP diakses menggunakan kredensial penyebaran.
FTP tidak disarankan untuk menyebarkan kode fungsi Anda. Penyebaran FTP bersifat manual dan mengharuskan Anda untuk menyinkronkan pemicu. Untuk mempelajari lebih lanjut, lihat Penyebaran FTP.
Ketika Anda tidak berencana menggunakan FTP, Anda harus menonaktifkannya di portal. Jika Anda memilih untuk menggunakan FTP, Anda harus memberlakukan FTPS.
Mengamankan titik akhir scm
Setiap aplikasi fungsi memiliki scm titik akhir layanan yang sesuai yang digunakan oleh layanan Advanced Tools (Kudu) untuk penyebaran dan ekstensi situs App Service lainnya. Titik akhir scm untuk aplikasi fungsi selalu berupa URL dalam format https://<FUNCTION_APP_NAME.scm.azurewebsites.net>. Ketika Anda menggunakan isolasi jaringan untuk mengamankan fungsi Anda, perhitungkan pula titik akhir ini.
Dengan memiliki titik akhir scm terpisah, Anda dapat mengontrol penyebaran dan fungsionalitas alat canggih lainnya untuk aplikasi fungsi yang terisolasi atau berjalan di jaringan virtual. Titik akhir scm mendukung autentikasi dasar (menggunakan kredensial penyebaran) dan akses menyeluruh (SSO) dengan kredensial portal Microsoft Azure Anda. Untuk mempelajari lebih lanjut, lihat Mengakses layanan Kudu.
Validasi keamanan berkelanjutan
Karena keamanan perlu dipertimbangkan di setiap langkah dalam proses pengembangan, masuk akal untuk juga menerapkan validasi keamanan di lingkungan penyebaran berkelanjutan. Terkadang ini dinamakan DevSecOps. Menggunakan Azure DevOps untuk alur penyebaran memungkinkan Anda mengintegrasikan validasi ke dalam proses penyebaran. Untuk informasi selengkapnya, lihat Mempelajari cara menambahkan validasi keamanan berkelanjutan ke alur CI/CD Anda.
Keamanan jaringan
Membatasi akses jaringan ke aplikasi fungsi memungkinkan Anda mengontrol siapa yang dapat mengakses titik akhir fungsi Anda. Functions memanfaatkan infrastruktur App Service untuk mengizinkan fungsi Anda mengakses sumber daya tanpa menggunakan alamat yang dapat dirutekan oleh internet atau membatasi akses internet ke titik akhir fungsi. Untuk mempelajari selengkapnya tentang opsi jaringan ini, lihat Opsi jaringan Azure Functions.
Mengatur pembatasan akses
Pembatasan akses memungkinkan Anda menentukan daftar aturan izin/tolak untuk mengontrol lalu lintas ke aplikasi Anda. Aturan dievaluasi dalam urutan prioritas. Jika tidak ada aturan yang ditentukan, aplikasi Anda akan menerima lalu lintas dari alamat apa pun. Untuk mempelajari selengkapnya, lihat Pembatasan Akses Azure App Service.
Mengamankan akun penyimpanan
Saat membuat aplikasi fungsi, Anda harus membuat atau menautkan ke akun tujuan umum Azure Storage yang mendukung penyimpanan Blob, Queue, dan Table. Anda dapat mengganti akun penyimpanan ini dengan akun yang diamankan dengan titik akhir layanan atau titik akhir privat. Untuk informasi selengkapnya, lihat Membatasi akun penyimpanan Anda ke jaringan virtual.
Akses situs privat
Azure Private Endpoint adalah antarmuka jaringan yang menghubungkan Anda secara privat dan aman ke layanan yang didukung oleh Azure Private Link. Titik Akhir Privat menggunakan alamat IP privat dari jaringan virtual Anda, membawa layanan ke dalam jaringan virtual Anda secara efektif.
Anda dapat menggunakan Titik Akhir Pribadi untuk fungsi yang dihosting dalam paket Premium dan App Service.
Jika Anda ingin melakukan panggilan ke Titik Akhir Privat, Anda harus memastikan pencarian DNS Anda menentukan titik akhir privat. Anda dapat menerapkan perilaku ini di salah satu cara berikut:
- Integrasikan dengan zona privat Azure DNS. Ketika jaringan virtual Anda tidak memiliki server DNS kustom, integrasi dilakukan secara otomatis.
- Kelola titik akhir privat di server DNS yang digunakan oleh aplikasi Anda. Untuk melakukan ini, Anda harus mengetahui alamat titik akhir privat, lalu mengarahkan titik akhir yang Anda coba jangkau ke alamat tersebut menggunakan rekaman A.
- Konfigurasikan server DNS Anda sendiri untuk diteruskan ke zona privat Azure DNS.
Untuk mempelajari selengkapnya, lihat menggunakan Titik Akhir Pribadi untuk Aplikasi Web.
Menyebarkan aplikasi fungsi Anda dalam isolasi
Lingkungan Azure App Service (ASE) menyediakan lingkungan hosting khusus untuk menjalankan fungsi Anda. ASE memungkinkan Anda mengonfigurasi gateway front-end tunggal yang dapat digunakan untuk mengautentikasi semua permintaan yang masuk. Untuk informasi selengkapnya, lihat Mengonfigurasi Web Application Firewall (WAF) untuk Lingkungan App Service.
Menggunakan layanan gateway
Layanan gateway, seperti Azure Application Gateway dan Azure Front Door memungkinkan Anda menyiapkan Web Application Firewall (WAF). Aturan WAF digunakan untuk memantau atau memblokir serangan yang terdeteksi, sebagai lapisan perlindungan ekstra untuk fungsi Anda. Untuk menyiapkan WAF, aplikasi fungsi Anda harus berjalan di ASE atau menggunakan Titik Akhir Privat (pratinjau). Untuk mempelajari selengkapnya, lihat Menggunakan Titik Akhir Privat.