Akses dan data aman untuk alur kerja di Azure Logic Apps
Azure Logic Apps mengandalkan Azure Storage untuk menyimpan dan secara otomatis mengenkripsi data saat tidak aktif. Enkripsi ini melindungi data dan membantu Anda memenuhi komitmen keamanan dan kepatuhan organisasi Anda. Secara default, Azure Storage menggunakan kunci yang dikelola Microsoft untuk mengenkripsi data Anda. Untuk informasi lebih lanjut, tinjau enkripsi Azure Storage untuk data tidak aktif.
Untuk lebih mengontrol akses dan melindungi data sensitif di Azure Logic Apps, Anda dapat menyiapkan lebih banyak keamanan di area berikut:
- Akses ke operasi aplikasi logika
- Akses untuk menjalankan input dan output riwayat
- Mengakses ke input parameter
- Jenis autentikasi untuk pemicu dan tindakan yang mendukung autentikasi
- Akses untuk panggilan masuk ke pemicu berbasis permintaan
- Akses untuk panggilan keluar ke layanan dan sistem lain
- Blokir pembuatan sambungan untuk konektor tertentu
- Panduan isolasi untuk aplikasi logika
- Azure Security Baseline untuk Azure Logic Apps
Untuk informasi selengkapnya tentang keamanan di Azure, tinjau topik berikut:
- Gambaran umum tentang enkripsi Azure
- Enkripsi data Azure saat tidak aktif
- Tolok ukur keamanan cloud Microsoft
Akses ke operasi aplikasi logika
Hanya untuk aplikasi logika Konsumsi, sebelum Anda dapat membuat atau mengelola aplikasi logika dan koneksinya, Anda memerlukan izin khusus, yang diberikan melalui peran menggunakan Kontrol akses berbasis peran Azure (Azure RBAC). Anda juga dapat menyiapkan izin sehingga hanya pengguna atau grup tertentu yang dapat menjalankan tugas tertentu, seperti mengelola, mengedit, dan melihat aplikasi logika. Anda dapat menetapkan peran bawaan atau terkelola kepada anggota yang memiliki akses ke langganan Azure Anda. Azure Logic Apps memiliki peran spesifik berikut, berdasarkan apakah Anda memiliki alur kerja aplikasi logika Konsumsi atau Standar:
Alur kerja untuk konsumsi
Peran | Deskripsi |
---|---|
Kontributor Aplikasi Logika | Anda dapat mengelola alur kerja aplikasi logika, tetapi Anda tidak dapat mengubah akses ke alur kerja tersebut. |
Operator Aplikasi Logika | Anda dapat membaca, mengaktifkan, dan menonaktifkan alur kerja aplikasi logika, tetapi Anda tidak dapat mengedit atau memperbaruinya. |
Kontributor | Anda memiliki akses penuh untuk mengelola semua sumber daya, tetapi Anda tidak dapat menetapkan peran di Azure RBAC, mengelola penugasan di Azure Blueprints, atau berbagi galeri gambar. |
Misalnya, Anda harus bekerja dengan alur kerja aplikasi logika yang tidak Anda buat dan autentikasi koneksi yang digunakan oleh alur kerja aplikasi logika tersebut. Langganan Azure Anda memerlukan izin Kontributor untuk grup sumber daya yang berisi sumber daya aplikasi logika tersebut. Jika Anda membuat sumber daya aplikasi logika, Anda secara otomatis memiliki akses Kontributor.
Untuk mencegah orang lain mengubah atau menghapus alur kerja aplikasi logika, Anda dapat menggunakan Azure Resource Lock. Kemampuan ini mencegah orang lain mengubah atau menghapus sumber daya produksi. Untuk informasi selengkapnya tentang keamanan koneksi, tinjau konfigurasi koneksi di Azure Logic Apps dan keamanan koneksi dan enkripsi.
Alur kerja yang standar
Catatan
Kemampuan ini masih dalam pratinjau dan mengacu pada Ketentuan Penggunaan Tambahan untuk Pratinjau Microsoft Azure.
Peran | Deskripsi |
---|---|
Pembaca Standar Logic Apps (Pratinjau) | Anda memiliki akses baca-saja ke semua sumber daya dalam aplikasi logika Standar dan alur kerja, termasuk alur kerja yang berjalan dan riwayatnya. |
Operator Standar Logic Apps (Pratinjau) | Anda memiliki akses untuk mengaktifkan, mengirim ulang, dan menonaktifkan alur kerja dan membuat koneksi ke layanan, sistem, dan jaringan untuk aplikasi logika Standar. Peran Operator dapat melakukan tugas administrasi dan dukungan di platform Azure Logic Apps, tetapi tidak memiliki izin untuk mengedit alur kerja atau pengaturan. |
Pengembang Standar Logic Apps (Pratinjau) | Anda memiliki akses untuk membuat dan mengedit alur kerja, koneksi, dan pengaturan untuk aplikasi logika Standar. Peran Pengembang tidak memiliki izin untuk membuat perubahan di luar lingkup alur kerja, misalnya, perubahan di seluruh aplikasi seperti mengonfigurasi integrasi jaringan virtual. Paket App Service tidak didukung. |
Kontributor Standar Logic Apps (Pratinjau) | Anda memiliki akses untuk mengelola semua aspek aplikasi logika Standar, tetapi Anda tidak dapat mengubah akses atau kepemilikan. |
Akses untuk menjalankan data riwayat
Selama aplikasi logika berjalan, semua data dienkripsi selama transit dengan menggunakan Transport Layer Security (TLS) dan saat istirahat. Saat aplikasi logika selesai dijalankan, Anda dapat melihat riwayat untuk menjalankannya, termasuk langkah-langkah yang berjalan bersama dengan status, durasi, input, dan output untuk setiap tindakan. Detail kaya ini memberikan wawasan tentang bagaimana aplikasi logika Anda berjalan dan di mana Anda mungkin mulai memecahkan masalah yang muncul.
Saat Anda melihat riwayat menjalankan aplikasi logika Anda, Azure Logic Apps mengautentikasi akses Anda dan kemudian menyediakan tautan ke input dan output untuk permintaan dan respons untuk setiap proses. Namun, untuk tindakan yang menangani kata sandi, rahasia, kunci, atau informasi sensitif lainnya, Anda harus mencegah orang lain menampilkan dan mengakses data tersebut. Misalnya, jika aplikasi logika Anda mendapatkan rahasia dari Azure Key Vault untuk digunakan saat mengautentikasi tindakan HTTP, Anda ingin menyembunyikan rahasia itu dari tampilan.
Untuk mengontrol akses ke input dan output dalam riwayat jalankan aplikasi logika, Anda memiliki opsi berikut:
Membatasi akses menurut rentang alamat IP.
Opsi ini membantu Anda mengamankan akses untuk menjalankan riwayat berdasarkan permintaan dari rentang alamat IP tertentu.
Amankan data dalam riwayat jalankan dengan menggunakan obfuscation.
Dalam banyak pemicu dan tindakan, Anda dapat mengamankan input, output, atau keduanya dalam riwayat jalankan aplikasi logika.
Membatasi akses menurut rentang alamat IP
Anda dapat membatasi akses ke input dan output dalam riwayat eksekusi untuk alur kerja aplikasi logika Anda sehingga hanya permintaan dari rentang alamat IP tertentu yang dapat melihat data tersebut.
Misalnya, untuk memblokir siapa pun agar tidak mengakses input dan output, tentukan rentang alamat IP seperti 0.0.0.0-0.0.0.0
. Hanya orang dengan izin administrator yang dapat menghapus pembatasan ini, yang memberikan kemungkinan untuk akses "just-in-time" ke data di alur kerja aplikasi logika Anda. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Untuk menentukan rentang IP yang diizinkan, ikuti langkah-langkah ini untuk aplikasi logika Konsumsi atau Standar Anda di portal Azure atau templat Azure Resource Manager Anda:
Alur kerja untuk konsumsi
Di portal Azure, buka alur kerja aplikasi logika Penggunaan Anda di perancang.
Pada menu aplikasi logika, di bawah Pengaturan, pilih Pengaturan alur kerja.
Di bagian Konfigurasi kontrol akses , di bawah Alamat IP masuk yang diizinkan, dari daftar Opsi akses pemicu, pilih Rentang IP tertentu.
Dalam kotak Rentang IP untuk konten , tentukan rentang alamat IP yang dapat mengakses konten dari input dan output.
Alur kerja yang standar
Di portal Azure, buka sumber daya aplikasi logika Standard Anda.
Pada menu aplikasi logika, di bawah Pengaturan, pilih Jaringan.
Di bagian Konfigurasi lalu lintas masuk, di samping Akses jaringan publik, pilih Diaktifkan tanpa batasan akses.
Pada halaman Pembatasan akses, di bawah Akses aplikasi, pilih Diaktifkan dari jaringan virtual dan alamat IP tertentu.
Di bawah Akses dan aturan situs, pada tab Situs utama, tambahkan satu atau beberapa aturan ke Izinkan atau Tolak permintaan dari rentang IP tertentu. Anda juga dapat menggunakan pengaturan filter header HTTP dan pengaturan penerusan. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Untuk informasi selengkapnya, lihat Memblokir alamat IP masuk di Azure Logic Apps (Standar).
Mengamankan data dalam riwayat jalankan dengan menggunakan obfuscation
Banyak pemicu dan tindakan memiliki pengaturan untuk mengamankan input, output, atau keduanya dari riwayat jalankan aplikasi logika. Semua konektor terkelola dan konektor kustom mendukung opsi ini. Namun, operasi bawaan berikut tidak mendukung opsi ini:
Input Aman - Tidak Didukung | Output Aman - Tidak didukung |
---|---|
Tambahkan ke variabel array Tambahkan ke variabel string Variabel pengurangan Untuk masing-masing Kalau Variabel kenaikan Menginisialisasi variabel Kekambuhan Ruang lingkup Atur variabel Sakelar Menyelesaikan Hingga |
Tambahkan ke variabel array Tambahkan ke variabel string Karang Variabel pengurangan Untuk masing-masing Kalau Variabel kenaikan Menginisialisasi variabel Mengurai JSON Kekambuhan Jawaban Ruang lingkup Atur variabel Sakelar Menyelesaikan Sampai Tunggu |
Pertimbangan saat mengamankan input dan output
Sebelum menggunakan pengaturan ini untuk membantu Anda mengamankan data ini, tinjau pertimbangan berikut:
Saat Anda mengaburkan input atau output pada pemicu atau tindakan, Azure Logic Apps tidak mengirim data aman ke Azure Log Analytics. Selain itu, Anda tidak dapat menambahkan properti terlacak ke pemicu atau tindakan tersebut untuk pemantauan.
API Azure Logic Apps untuk menangani riwayat alur kerja tidak mengembalikan keluaran aman.
Untuk mengamankan keluaran dari tindakan yang mengaburkan masukan atau secara eksplisit mengaburkan keluaran, aktifkan Keluaran Aman secara manual dalam tindakan tersebut.
Pastikan Anda mengaktifkan Input Aman atau Keluaran Aman dalam tindakan hilir di mana Anda mengharapkan riwayat proses mengaburkan data tersebut.
Setelan Keluaran Aman
Saat Anda mengaktifkan Output Aman secara manual dalam pemicu atau tindakan, Azure Logic Apps menyembunyikan keluaran ini dalam riwayat proses. Jika tindakan downstream secara eksplisit menggunakan keluaran aman ini sebagai masukan, Azure Logic Apps menyembunyikan masukan tindakan ini dalam riwayat proses, namun tidak mengaktifkan setelan Input Aman tindakan.
Tindakan Buat,Uraikan JSON, dan Respons hanya memiliki pengaturan Input Aman. Saat dinyalakan, pengaturan juga menyembunyikan output tindakan ini. Jika tindakan ini secara eksplisit menggunakan keluaran aman upstram sebagai masukan, Azure Logic Apps menyembunyikan masukan dan keluaran tindakan ini, namun tidak mengaktifkan setelan Input Aman tindakan ini. Jika tindakan downstream secara eksplisit menggunakan output tersembunyi dari tindakan Compose, Parse JSON, atau Response sebagai input, Azure Logic Apps tidak menyembunyikan input atau output tindakan downstream ini.
Pengaturan Input Aman
Saat Anda mengaktifkan Input Aman secara manual dalam pemicu atau tindakan, Azure Logic Apps menyembunyikan input ini dalam riwayat proses. Jika tindakan hilir secara eksplisit menggunakan output yang terlihat dari pemicu atau tindakan tersebut sebagai input, Azure Logic Apps menyembunyikan input tindakan hilir ini dalam riwayat eksekusi, tetapi tidak mengaktifkan Input Aman dalam tindakan ini dan tidak menyembunyikan output tindakan ini.
Jika tindakan Compose, Parse JSON, dan Response secara eksplisit menggunakan output yang terlihat dari pemicu atau tindakan yang memiliki masukan aman, Azure Logic Apps menyembunyikan input dan output tindakan ini, namun tidak mengaktifkan tindakan ini setelan Input Aman. Jika tindakan downstream secara eksplisit menggunakan output tersembunyi dari tindakan Compose, Parse JSON, atau Response sebagai input, Azure Logic Apps tidak menyembunyikan input atau output tindakan downstream ini.
Input dan output aman dalam desainer
Di portal Microsoft Azure, buka alur kerja aplikasi logika Anda di perancang.
Pada perancang, pilih pemicu atau tindakan tempat Anda ingin mengamankan data sensitif.
Pada panel informasi yang terbuka, pilih Pengaturan, dan perluas Keamanan.
Aktifkan Input Aman, Keluaran Aman, atau keduanya.
Pemicu atau tindakan sekarang menampilkan ikon kunci di bilah judul. Token apa pun yang mewakili output aman dari tindakan sebelumnya juga menampilkan ikon kunci. Misalnya, dalam tindakan berikutnya, setelah Anda memilih token untuk output aman dari daftar konten dinamis, token tersebut menampilkan ikon kunci.
Setelah alur kerja berjalan, Anda bisa menampilkan riwayat untuk eksekusi tersebut.
Pilih Gambaran Umum baik pada menu aplikasi logika Konsumsi atau pada menu alur kerja Standar.
Di bawah Riwayat eksekusi, pilih eksekusi yang ingin Anda lihat.
Pada panel riwayat eksekusi alur kerja, pilih tindakan yang ingin Anda tinjau.
Jika Anda memilih untuk menyembunyikan input dan output, nilai-nilai tersebut sekarang muncul tersembunyi.
Input dan output aman dalam tampilan kode
Dalam definisi pemicu atau tindakan yang mendasari, tambahkan atau perbarui array runtimeConfiguration.secureData.properties
dengan salah satu atau kedua nilai berikut:
"inputs"
: Mengamankan input dalam riwayat jalankan."outputs"
: Mengamankan output dalam riwayat jalankan.
"<trigger-or-action-name>": {
"type": "<trigger-or-action-type>",
"inputs": {
<trigger-or-action-inputs>
},
"runtimeConfiguration": {
"secureData": {
"properties": [
"inputs",
"outputs"
]
}
},
<other-attributes>
}
Mengakses ke input parameter
Jika Anda menggunakan berbagai lingkungan, pertimbangkan untuk meng parameterisasi nilai dalam definisi alur kerja Anda yang bervariasi berdasarkan lingkungan tersebut. Dengan demikian, Anda dapat menghindari data yang dikodekan secara permanen dengan menggunakan templat Azure Resource Manager untuk menyebarkan logic app, melindungi data sensitif dengan menentukan parameter aman, dan meneruskan data tersebut sebagai input terpisah melalui parameter templat dengan menggunakan file parameter.
Misalnya, jika Anda mengautentikasi tindakan HTTP dengan OAuth dengan MICROSOFT Entra ID, Anda dapat menentukan dan mengaburkan parameter yang menerima ID klien dan rahasia klien yang digunakan untuk autentikasi. Untuk menentukan parameter ini di alur kerja aplikasi logika Anda, gunakan parameters
bagian dalam definisi alur kerja aplikasi logika Anda dan templat Resource Manager untuk penyebaran. Untuk membantu mengamankan nilai parameter yang tidak ingin Anda tampilkan saat mengedit aplikasi logika atau melihat riwayat jalankan, tentukan parameter dengan menggunakan securestring
atau ketik dan gunakan secureobject
pengkodean seperlunya. Parameter yang memiliki jenis ini tidak dikembalikan dengan definisi sumber daya dan tidak dapat diakses saat melihat sumber daya setelah penyebaran. Untuk mengakses nilai parameter ini selama runtime, gunakan ekspresi di @parameters('<parameter-name>')
dalam definisi alur kerja Anda. Ekspresi ini dievaluasi hanya pada waktu proses dan dijelaskan oleh Bahasa Definisi Alur Kerja.
Catatan
Jika Anda menggunakan parameter di header permintaan atau isi, parameter tersebut mungkin terlihat saat Anda melihat riwayat eksekusi alur kerja dan permintaan HTTP keluar. Pastikan Anda juga menetapkan kebijakan akses konten Sesuai. Anda juga dapat menggunakan obfuscation untuk menyembunyikan input dan output dalam riwayat lari Anda.
Secara default, Authorization
header tidak terlihat melalui input atau output.
Jadi jika rahasia digunakan di sana, rahasia itu tidak dapat diambil.
Untuk informasi lebih lanjut, tinjau bagian ini dalam topik ini:
- Parameter aman dalam definisi alur kerja
- Mengamankan data dalam riwayat jalankan dengan menggunakan obfuscation
Jika Anda mengotomatiskan penerapan untuk aplikasi logika dengan menggunakan template Resource Manager, Anda dapat menentukan parameter template aman, yang dievaluasi saat penerapan, dengan menggunakan jenis securestring
dan secureobject
. Untuk menentukan parameter kerangka, gunakan bagian parameters
tingkat atas kerangka Anda, yang terpisah dan berbeda dari bagian parameters
definisi alur kerja Anda. Untuk menyediakan nilai untuk parameter template, gunakan file parameter terpisah.
Misalnya, jika Anda menggunakan rahasia, Anda dapat menentukan dan menggunakan parameter template aman yang mengambil rahasia tersebut dari Azure Key Vault saat penyebaran. Anda kemudian dapat mereferensikan kubah kunci dan rahasia dalam file parameter Anda. Untuk informasi selengkapnya, tinjau topik berikut ini:
- Meneruskan nilai sensitif saat penerapan dengan menggunakan Azure Key Vault
- Parameter aman di template Azure Resource Manager nanti di topik ini
Parameter aman dalam definisi alur kerja (Alur kerja konsumsi)
Untuk melindungi informasi sensitif dalam definisi alur kerja aplikasi logika Anda, gunakan parameter aman sehingga informasi ini tidak terlihat setelah Anda menyimpan alur kerja aplikasi logika Anda. Misalnya, Anda memiliki tindakan HTTP memerlukan autentikasi dasar, yang menggunakan nama pengguna dan kata sandi. Dalam definisi alur kerja, bagian parameters
mendefinisikan parameter basicAuthPasswordParam
dan basicAuthUsernameParam
dengan menggunakan jenis securestring
. Definisi tindakan kemudian merujuk parameter ini di bagian authentication
.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
}
Parameter aman dalam templat Azure Resource Manager (Alur kerja Konsumsi)
Templat Resource Manager untuk sumber daya dan alur kerja aplikasi logika memiliki beberapa parameters
bagian. Untuk melindungi kata sandi, kunci, rahasia, dan informasi sensitif lainnya, tentukan parameter aman di tingkat template dan tingkat definisi alur kerja dengan menggunakan tipe securestring
atau secureobject
. Anda kemudian dapat menyimpan nilai ini di Azure Key Vault dan menggunakan file parameter untuk mereferensikan key vault dan secret. Templat Anda kemudian mengambil informasi tersebut saat penyebaran. Untuk informasi selengkapnya, tinjau Luluskan nilai sensitif saat penyebaran menggunakan Azure Key Vault.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Daftar ini mencakup informasi lebih lanjut tentang bagian parameters
ini:
Di tingkat atas kerangka, bagian
parameters
menentukan parameter untuk nilai yang digunakan kerangka di penerapan. Misalnya, nilai-nilai ini dapat menyertakan string koneksi untuk lingkungan penyebaran tertentu. Anda kemudian dapat menyimpan nilai ini dalam file parameter terpisah, yang membuat perubahan nilai ini lebih mudah.Di dalam definisi sumber daya aplikasi logika Anda, tetapi di luar definisi alur
parameters
kerja Anda, sebuah bagian menentukan nilai untuk parameter definisi alur kerja Anda. Di bagian ini, Anda dapat menetapkan nilai ini dengan menggunakan ekspresi templat yang mereferensikan parameter templat Anda. Ekspresi ini dievaluasi saat penyebaran.Di dalam definisi alur kerja Anda, bagian
parameters
menentukan parameter yang digunakan alur kerja aplikasi logika Anda saat runtime. Anda kemudian dapat mereferensikan parameter ini di dalam alur kerja aplikasi logika Anda dengan menggunakan ekspresi definisi alur kerja, yang dievaluasi pada waktu proses.
Contoh templat ini yang memiliki beberapa definisi parameter aman yang menggunakan securestring
tipe:
Nama Parameter | Deskripsi |
---|---|
TemplatePasswordParam |
Parameter templat yang menerima kata sandi yang kemudian diteruskan ke parameter definisi alur basicAuthPasswordParam kerja |
TemplateUsernameParam |
Parameter template yang menerima nama pengguna yang kemudian diteruskan ke parameter basicAuthUserNameParam definisi alur kerja |
basicAuthPasswordParam |
Parameter definisi alur kerja yang menerima kata sandi untuk autentikasi dasar dalam tindakan HTTP |
basicAuthUserNameParam |
Parameter definisi alur kerja yang menerima nama pengguna untuk autentikasi dasar dalam tindakan HTTP |
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"LogicAppName": {
"type": "string",
"minLength": 1,
"maxLength": 80,
"metadata": {
"description": "Name of the Logic App."
}
},
"TemplatePasswordParam": {
"type": "securestring"
},
"TemplateUsernameParam": {
"type": "securestring"
},
"LogicAppLocation": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"allowedValues": [
"[resourceGroup().location]",
"eastasia",
"southeastasia",
"centralus",
"eastus",
"eastus2",
"westus",
"northcentralus",
"southcentralus",
"northeurope",
"westeurope",
"japanwest",
"japaneast",
"brazilsouth",
"australiaeast",
"australiasoutheast",
"southindia",
"centralindia",
"westindia",
"canadacentral",
"canadaeast",
"uksouth",
"ukwest",
"westcentralus",
"westus2"
],
"metadata": {
"description": "Location of the Logic App."
}
}
},
"variables": {},
"resources": [
{
"name": "[parameters('LogicAppName')]",
"type": "Microsoft.Logic/workflows",
"location": "[parameters('LogicAppLocation')]",
"tags": {
"displayName": "LogicApp"
},
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
},
"parameters": {
"basicAuthPasswordParam": {
"value": "[parameters('TemplatePasswordParam')]"
},
"basicAuthUsernameParam": {
"value": "[parameters('TemplateUsernameParam')]"
}
}
}
}
],
"outputs": {}
}
Jenis autentikasi untuk konektor yang mendukung autentikasi
Tabel berikut mengidentifikasi jenis autentikasi yang tersedia pada operasi konektor tempat Anda dapat memilih jenis autentikasi:
Jenis autentikasi | Aplikasi logika & konektor yang didukung |
---|---|
Dasar | Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook |
Sertifikat klien | Azure API Management, Azure App Service, HTTP, HTTP + Swagger, HTTP Webhook |
Active Directory OAuth (OAuth 2.0 dengan MICROSOFT Entra ID) | - Konsumsi: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook - Standar: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Bus Layanan, Azure Tables, HTTP, HTTP Webhook, SQL Server |
Mentah | Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook |
Identitas terkelola | Konektor bawaan: - Konsumsi: Azure API Management, Azure App Service, Azure Functions, HTTP, HTTP Webhook - Standar: Azure Automation, Azure Blob Storage, Azure Event Hubs, Azure Queues, Azure Bus Layanan, Azure Tables, HTTP, HTTP Webhook, SQL Server Catatan: Saat ini, sebagian besar konektor berbasis penyedia layanan bawaan tidak mendukung pemilihan identitas terkelola yang ditetapkan pengguna untuk autentikasi. Konektor terkelola: Azure App Service, Azure Automation, Azure Blob Storage, Azure Container Instance, Azure Cosmos DB, Azure Data Explorer, Azure Data Factory, Azure Data Lake, Azure Event Grid, Azure Event Hubs, Azure IoT Central V2, Azure IoT Central V3, Azure Key Vault, Azure Log Analytics, Azure Queues, Azure Resource Manager, Azure Bus Layanan, Azure Sentinel, Azure Table Storage, Azure VM, HTTP dengan MICROSOFT Entra ID, SQL Server |
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Akses untuk panggilan masuk ke pemicu berbasis permintaan
Panggilan masuk yang diterima aplikasi logika melalui pemicu berbasis permintaan, seperti pemicu Permintaan atau pemicu HTTP Webhook, mendukung enkripsi dan diamankan dengan Keamanan Lapisan Transportasi (TLS) 1.2 minimal, sebelumnya dikenal sebagai Secure Sockets Layer (SSL). Azure Logic Apps memberlakukan versi ini saat menerima panggilan masuk ke pemicu Permintaan atau panggilan balik ke pemicu atau tindakan HTTP Webhook.
Catatan
Jika Anda mendapatkan kesalahan jabat tangan TLS, pastikan Anda menggunakan TLS 1.2. Untuk informasi selengkapnya, lihat Memecahkan masalah TLS 1.0.
Untuk panggilan masuk, gunakan suite cipher berikut:
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
Penting
Untuk kompatibilitas mundur, saat ini Azure Logic Apps mendukung beberapa suite cipher yang lebih tua. Namun, jangan menggunakan suite cipher yang lebih tua ketika Anda mengembangkan aplikasi baru karena suite tersebut mungkin tidak didukung di masa mendatang.
Misalnya, Anda mungkin menemukan suite sandi berikut jika Anda memeriksa pesan jabat tangan TLS di Azure Logic Apps atau dengan menggunakan alat keamanan di URL aplikasi logika Anda. Sekali lagi, jangan menggunakan suite yang lebih lama ini:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
Daftar berikut ini mencakup cara untuk membatasi akses ke pemicu yang menerima panggilan masuk ke alur kerja aplikasi logika Anda sehingga hanya klien yang berwenang yang dapat memanggil alur kerja Anda:
- Mengaktifkan OAuth dengan ID Microsoft Entra
- Membuat kunci atau token tanda tangan akses bersama (SAS)
- Menonaktifkan autentikasi tanda tangan akses bersama (SAS)
- Membatasi alamat IP masuk
- Mengekspos aplikasi logika Anda dengan Azure API Management
Mengaktifkan OAuth 2.0 dengan MICROSOFT Entra ID
Dalam alur kerja Konsumsi yang dimulai dengan pemicu berbasis permintaan, Anda dapat mengautentikasi dan mengotorisasi panggilan masuk yang dikirim ke titik akhir yang dibuat oleh pemicu tersebut dengan mengaktifkan OAuth 2.0 dengan ID Microsoft Entra. Untuk menyiapkan autentikasi ini, tentukan atau tambahkan kebijakan otorisasi di tingkat sumber daya aplikasi logika. Dengan cara ini, panggilan masuk menggunakan token akses OAuth untuk otorisasi.
Saat alur kerja aplikasi logika Anda menerima permintaan masuk yang menyertakan token akses OAuth, Azure Logic Apps membandingkan klaim token dengan klaim yang ditentukan oleh setiap kebijakan otorisasi. Jika ada kecocokan antara klaim token dan semua klaim dalam setidaknya satu kebijakan, otorisasi berhasil untuk permintaan masuk. Token dapat memiliki lebih banyak klaim daripada jumlah yang ditentukan oleh kebijakan otorisasi.
Dalam alur kerja Standar yang dimulai dengan pemicu Permintaan (tetapi bukan pemicu webhook), Anda dapat menggunakan provisi Azure Functions untuk mengautentikasi panggilan masuk yang dikirim ke titik akhir yang dibuat oleh pemicu Permintaan dengan menggunakan identitas terkelola. Ketentuan ini dikenal juga sebagai "Easy Auth". Untuk informasi selengkapnya, lihat Memicu alur kerja di aplikasi logika Standar dengan Easy Auth.
Pertimbangan sebelum Anda mengaktifkan OAuth 2.0 dengan ID Microsoft Entra
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Dalam alur kerja Konsumsi, panggilan masuk ke URL titik akhir untuk pemicu berbasis permintaan hanya dapat menggunakan satu skema otorisasi, baik OAuth 2.0 dengan ID Microsoft Entra atau Tanda Tangan Akses Bersama (SAS). Meskipun menggunakan satu skema tidak menonaktifkan skema lain, jika Anda menggunakan kedua skema pada saat yang sama, Azure Logic Apps menghasilkan kesalahan karena layanan tidak tahu skema mana yang akan dipilih. Jika alur kerja Konsumsi Anda dimulai dengan pemicu Permintaan , Anda dapat menonaktifkan autentikasi SAS serta membatasi otorisasi untuk hanya menggunakan OAuth 2.0 dengan ID Microsoft Entra. Untuk alur kerja Standar, Anda dapat menggunakan jenis autentikasi lain tanpa menonaktifkan SAS.
Azure Logic Apps mendukung skema otorisasi jenis pembawa atau jenis bukti kepemilikan (hanya aplikasi logika Konsumsi) untuk token akses OAuth ID Microsoft Entra. Namun,
Authorization
header untuk token akses harus menentukanBearer
jenis atauPoP
jenisnya. Untuk informasi selengkapnya tentang cara mendapatkan dan menggunakan token PoP, lihat Mendapatkan token Proof of Possession (PoP).Sumber daya aplikasi logika Konsumsi Anda terbatas pada jumlah maksimum kebijakan otorisasi. Setiap kebijakan otorisasi juga memiliki jumlah klaim maksimum. Untuk informasi selengkapnya, tinjau Batasan dan konfigurasi untuk Azure Logic Apps.
Kebijakan otorisasi harus menyertakan setidaknya klaim Pengeluar Sertifikat , yang memiliki nilai yang dimulai dengan
https://sts.windows.net/
atauhttps://login.microsoftonline.com/
(OAuth V2) sebagai penerbit untuk ID Microsoft Entra.Misalnya, sumber daya aplikasi logika Anda memiliki kebijakan otorisasi yang memerlukan dua jenis klaim, Audiens dan Penerbit. Bagian muatan sampel untuk token akses yang diterjemahkan mencakup kedua jenis klaim di mana
aud
nilai Audiens daniss
merupakan nilai Penerbit:{ "aud": "https://management.core.windows.net/", "iss": "https://sts.windows.net/<Azure-AD-issuer-ID>/", "iat": 1582056988, "nbf": 1582056988, "exp": 1582060888, "_claim_names": { "groups": "src1" }, "_claim_sources": { "src1": { "endpoint": "https://graph.windows.net/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects" } }, "acr": "1", "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=", "amr": [ "rsa", "mfa" ], "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c", "appidacr": "2", "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab", "family_name": "Sophia Owen", "given_name": "Sophia Owen (Fabrikam)", "ipaddr": "167.220.2.46", "name": "sophiaowen", "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7", "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475", "puid": "1003000000098FE48CE", "scp": "user_impersonation", "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k", "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee", "unique_name": "SophiaOwen@fabrikam.com", "upn": "SophiaOwen@fabrikam.com", "uti": "TPJ7nNNMMZkOSx6_uVczUAA", "ver": "1.0" }
Aktifkan OAuth 2.0 dengan MICROSOFT Entra ID sebagai satu-satunya opsi untuk memanggil titik akhir permintaan (Hanya konsumsi)
Untuk titik akhir berbasis permintaan, Anda dapat membatasi otorisasi untuk hanya menggunakan OAuth 2.0 dengan ID Microsoft Entra. Opsi ini berfungsi bahkan jika Anda juga menonaktifkan autentikasi tanda tangan akses bersama (SAS).
Untuk alur kerja Konsumsi Anda, siapkan pemicu Permintaan atau pemicu HTTP Webhook Anda dengan kemampuan untuk memeriksa token akses OAuth dengan mengikuti langkah-langkah untuk menyertakan header 'Otorisasi' di output pemicu permintaan atau http webhook.
Catatan
Langkah ini membuat
Authorization
header terlihat dalam riwayat eksekusi alur kerja dan dalam output pemicu.Di portal Azure, buka alur kerja Konsumsi Anda di perancang.
Pada perancang, pilih pemicu. Pada panel informasi yang terbuka, pilih Pengaturan.
Di bawah Kondisi Pemicu Umum>, pilih Tambahkan. Dalam kotak kondisi pemicu, masukkan salah satu ekspresi berikut, berdasarkan jenis token yang ingin Anda gunakan:
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')
-atau-
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')
Jika Anda memanggil titik akhir pemicu tanpa otorisasi yang benar, riwayat proses hanya menampilkan pemicu sebagai Skipped
tanpa pesan bahwa kondisi pemicu telah gagal.
Dapatkan token Proof-of-Possession (PoP)
Pustaka Microsoft Authentication Library (MSAL) menyediakan token PoP untuk Anda gunakan. Jika alur kerja aplikasi logika Konsumsi yang ingin Anda panggil memerlukan token PoP, Anda bisa mendapatkan token ini menggunakan pustaka MSAL. Sampel berikut menunjukkan cara memperoleh token PoP:
Aplikasi konsol daemon .NET Core yang memanggil API Web yang dilindungi dengan identitasnya sendiri
SignedHttpRequest, juga dikenal sebagai PoP (Bukti Kepemilikan)
Untuk menggunakan token PoP dengan alur kerja aplikasi logika Konsumsi Anda, ikuti langkah-langkah untuk menyiapkan OAuth dengan ID Microsoft Entra.
Mengaktifkan OAuth dengan ID Microsoft Entra untuk sumber daya aplikasi logika Konsumsi Anda
Untuk menambahkan kebijakan otorisasi ke aplikasi logika Konsumsi Anda, ikuti langkah-langkah untuk templat portal Azure atau Azure Resource Manager:
Di portal Azure, buka aplikasi logika Konsumsi dan alur kerja Anda di perancang.
Pada menu aplikasi logika, di bawah Setelan, pilih Otorisasi.
Pada halaman Otorisasi , pilih Tambahkan kebijakan.
Berikan informasi tentang kebijakan otorisasi dengan menentukan jenis klaim dan nilai yang diharapkan aplikasi logika Anda dalam token akses yang disajikan oleh setiap panggilan masuk ke pemicu Permintaan :
Properti Wajib Tipe Deskripsi Nama kebijakan Ya String Nama yang ingin Anda gunakan untuk kebijakan otorisasi Jenis kebijakan Ya String Baik AAD untuk token jenis pembawa atau AADPOP untuk token jenis Bukti Kepemilikan. Klaim Ya String Pasangan kunci-nilai yang menentukan jenis dan nilai klaim yang diharapkan pemicu Permintaan alur kerja dalam token akses yang disajikan oleh setiap panggilan masuk ke pemicu. Anda dapat menambahkan klaim standar apa pun yang Anda inginkan dengan memilih Tambahkan klaim standar. Untuk menambahkan klaim yang khusus untuk token PoP, pilih Tambahkan klaim kustom.
Jenis klaim standar yang tersedia:
- Penerbit
- Audiens
- Subjek
- ID JWT (pengidentifikasi JSON Web Token)
Persyaratan:
- Minimal, daftar Klaim harus menyertakan klaim Pengeluar Sertifikat , yang memiliki nilai yang dimulai denganhttps://sts.windows.net/
atauhttps://login.microsoftonline.com/
sebagai ID penerbit Microsoft Entra.
- Setiap klaim harus berupa nilai string tunggal dan bukan array nilai. Sebagai contoh, Anda dapat memiliki klaim dengan Peran sebagai jenis dan Pengembang sebagai nilai. Anda tidak bisa memiliki klaim yang memiliki Peran sebagai jenis dan nilai yang diatur ke Pengembang dan Manajer Program.
- Nilai klaim dibatasi hingga jumlah karakter maksimum.
Untuk informasi selengkapnya tentang jenis klaim ini, tinjau Klaim di token keamanan Microsoft Entra. Anda juga dapat menentukan jenis dan nilai klaim Anda sendiri.Contoh berikut menunjukkan informasi untuk token PoP:
Untuk menambahkan klaim lain, pilih dari opsi ini:
Untuk menambahkan jenis klaim lain, pilih Tambahkan klaim standar, pilih jenis klaim, dan tentukan nilai klaim.
Untuk menambahkan klaim Anda sendiri, pilih Tambahkan klaim kustom. Untuk informasi selengkapnya, tinjau cara memberikan klaim opsional untuk aplikasi Anda. Klaim kustom Anda kemudian disimpan sebagai bagian dari ID JWT Anda; contohnya,
"tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"
.
Untuk menambahkan kebijakan otorisasi lain, pilih Tambahkan kebijakan. Ulangi langkah-langkah sebelumnya untuk menyiapkan kebijakan.
Jika sudah selesai, pilih Simpan.
Untuk menyertakan
Authorization
header dari token akses dalam output pemicu berbasis permintaan, tinjau Menyertakan header 'Otorisasi' dalam permintaan dan output pemicu webhook HTTP.
Properti alur kerja seperti kebijakan tidak muncul dalam tampilan kode alur kerja Anda di portal Azure. Untuk mengakses kebijakan Anda secara terprogram, hubungi API berikut melalui Azure Resource Manager: https://management.azure.com/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820
. Pastikan Anda mengganti nilai tempat penampung untuk ID langganan Azure, nama grup sumber daya, dan nama alur kerja Anda.
Menyertakan header 'Otorisasi' dalam permintaan atau output pemicu webhook HTTP
Untuk aplikasi logika yang mengaktifkan OAuth dengan MICROSOFT Entra ID untuk mengotorisasi panggilan masuk untuk mengakses pemicu berbasis permintaan, Anda dapat mengaktifkan pemicu Permintaan atau output pemicu HTTP Webhook untuk menyertakan Authorization
header dari token akses OAuth. Dalam definisi JSON pemicu yang mendasarinya, tambahkan dan atur operationOptions
properti ke IncludeAuthorizationHeadersInOutputs
. Berikut adalah contoh untuk pemicu Permintaan :
"triggers": {
"manual": {
"inputs": {
"schema": {}
},
"kind": "Http",
"type": "Request",
"operationOptions": "IncludeAuthorizationHeadersInOutputs"
}
}
Untuk informasi selengkapnya, tinjau topik berikut ini:
- Referensi skema untuk pemicu dan jenis tindakan - Permintaan pemicu
- Referensi skema untuk pemicu dan jenis tindakan - Pemicu HTTP Webhook
- Referensi skema untuk tipe pemicu dan tindakan - Opsi operasi
Membuat kunci atau token tanda tangan akses bersama (SAS)
Saat alur kerja dimulai dengan pemicu berbasis permintaan, dan Anda menyimpan alur kerja tersebut untuk pertama kalinya, Azure Logic Apps membuat titik akhir yang dapat dipanggil pada pemicu tersebut. Titik akhir ini memiliki URL yang dapat menerima panggilan masuk atau permintaan untuk memulai alur kerja. URL menyertakan Tanda Tangan Akses Bersama (SAS), yang merupakan kunci atau token yang memberikan izin, misalnya, ke layanan penyimpanan. URL titik akhir ini menggunakan format berikut:
https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>
Misalnya, untuk melihat URL ini dalam pemicu Permintaan, temukan properti URL HTTP pemicu:
URL lengkap terlihat seperti contoh berikut:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
SAS di URL memiliki parameter kueri, yang dijelaskan tabel berikut:
Parameter kueri | Deskripsi |
---|---|
sp |
Menentukan ijin untuk metode HTTP yang diperbolehkan untuk digunakan. |
sv |
Menentukan versi SAS yang digunakan untuk menghasilkan tanda tangan. |
sig |
Menentukan tanda tangan yang akan digunakan untuk mengautentikasi akses ke pemicu. Tanda tangan ini dihasilkan dengan menggunakan algoritma SHA256 dengan kunci akses rahasia pada semua jalur dan properti URL. Kunci ini dirahasiakan dan dienkripsi, disimpan dengan aplikasi logika, dan tidak pernah diekspos atau diterbitkan. Aplikasi logika Anda hanya mengesahkan pemicu yang berisi tanda tangan valid yang dibuat dengan kunci rahasia. |
Penting
Pastikan untuk melindungi kunci SAS sama seperti Anda melindungi kunci akun dari penggunaan yang tidak sah. Menyiapkan atau memiliki rencana untuk mencabut kunci akses yang disusupi. Gunakan kebijaksanaan saat Anda mendistribusikan URI yang menggunakan kunci akses, dan hanya mendistribusikan URI tersebut melalui koneksi aman seperti HTTPS. Pastikan untuk hanya melakukan operasi yang menggunakan kunci akses melalui koneksi HTTPS. Siapa pun yang memiliki URI dengan kunci yang valid dapat mengakses sumber daya terkait. Untuk menjaga keamanan dan melindungi akses ke alur kerja aplikasi logika Anda, regenerasi kunci akses pada jadwal reguler karena mungkin perlu mematuhi kebijakan keamanan atau disusupi. Dengan cara ini, Anda dapat memastikan bahwa hanya permintaan yang diotorisasi yang dapat memicu alur kerja Anda, yang melindungi data dan proses Anda dari akses yang tidak sah.
Jika Anda menggunakan kunci SAS untuk mengakses layanan penyimpanan, Microsoft menyarankan agar Anda membuat SAS delegasi pengguna, yang diamankan dengan ID Microsoft Entra, bukan kunci akun.
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Panggilan masuk ke titik akhir pada pemicu berbasis permintaan hanya dapat menggunakan satu skema otorisasi, baik SAS atau OAuth 2.0 dengan ID Microsoft Entra. Meskipun menggunakan satu skema tidak menonaktifkan yang lain, jika Anda menggunakan kedua skema secara bersamaan, Azure Logic Apps menghasilkan kesalahan karena layanan tidak tahu skema mana yang akan dipilih.
Jika Anda memiliki alur kerja Konsumsi yang dimulai dengan pemicu Permintaan , Anda dapat menonaktifkan autentikasi SAS. Opsi ini berfungsi bahkan jika Anda juga membatasi otorisasi untuk hanya menggunakan OAuth 2.0 dengan ID Microsoft Entra. Untuk alur kerja Standar, Anda dapat menggunakan jenis autentikasi lain tanpa menonaktifkan SAS.
Untuk informasi selengkapnya tentang keamanan saat Anda menggunakan kunci SAS, lihat bagian berikut dalam panduan ini:
- Membuat ulang kunci akses
- Membuat URL panggilan balik yang kedaluwarsa
- Membuat URL dengan kunci utama atau sekunder
Menonaktifkan autentikasi tanda tangan akses bersama (SAS) (Hanya konsumsi)
Secara default, pemicu berbasis permintaan mengaktifkan autentikasi SAS. URL titik akhir pemicu mencakup SAS, dimulai dengan parameter kueri, sp-<permissions>sv-<SAS-version>sig=<signature>
, misalnya:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Jika alur kerja Konsumsi Anda dimulai dengan pemicu Permintaan , dan Anda ingin menggunakan OAuth dengan MICROSOFT Entra ID, Anda dapat menonaktifkan autentikasi SAS untuk menghindari kesalahan dan masalah dalam menjalankan alur kerja Anda. Anda juga menambahkan lapisan keamanan dengan menghapus dependensi pada rahasia, yang mengurangi risiko dalam memiliki rahasia yang dicatat atau bocor.
Opsi ini berfungsi bahkan jika Anda juga mengaktifkan OAuth 2.0 dengan MICROSOFT Entra ID sebagai satu-satunya opsi untuk memanggil titik akhir berbasis permintaan. Untuk alur kerja Standar, Anda dapat menggunakan jenis autentikasi lain tanpa menonaktifkan SAS.
Catatan
Tindakan ini menonaktifkan autentikasi SAS untuk permintaan masuk dan memblokir kunci SAS atau tanda tangan yang ada agar tidak berfungsi. Namun, kunci atau tanda tangan SAS Anda tetap valid dan masih berfungsi jika Anda mengaktifkan autentikasi SAS lagi. Untuk menonaktifkan kunci dan tanda tangan SAS dengan membuat versi baru, lihat Meregenerasi kunci akses.
Setelah Anda menonaktifkan autentikasi SAS, URL titik akhir untuk pemicu Permintaan tidak lagi menyertakan kunci SAS, misalnya:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01
Prasyarat
Untuk tugas ini, Anda memerlukan alat untuk mengirim panggilan REST API, misalnya:
- Visual Studio Code dengan ekstensi dari Visual Studio Marketplace
- PowerShell Invoke-RestMethod
- Microsoft Edge - Alat Konsol Jaringan
- Bruno
- curl
Perhatian
Untuk skenario di mana Anda memiliki data sensitif, seperti kredensial, rahasia, token akses, kunci API, dan informasi serupa lainnya, pastikan untuk menggunakan alat yang melindungi data Anda dengan fitur keamanan yang diperlukan, berfungsi offline atau lokal, tidak menyinkronkan data Anda ke cloud, dan tidak mengharuskan Anda masuk ke akun online. Dengan cara ini, Anda mengurangi risiko sekeliling mengekspos data sensitif ke publik.
Periksa pemicu dengan SAS diaktifkan atau dinonaktifkan
Saat autentikasi SAS dinonaktifkan, URL titik akhir pemicu tidak menyertakan kunci SAS lagi. Selain itu, definisi alur kerja Konsumsi mencakup objek JSON sasAuthenticationPolicy . Objek ini memiliki properti status yang diatur ke Dinonaktifkan, misalnya:
"properties": {
"accessControl": {
"triggers": {
"sasAuthenticationPolicy": {
"state": "Disabled"
}
}
}
}
Untuk menemukan alur kerja Konsumsi di mana SAS diaktifkan atau dinonaktifkan, periksa apakah definisi alur kerja menyertakan objek sasAuthenticationPolicy tempat properti status diatur ke Dinonaktifkan.
Dengan alat Anda yang mengirim panggilan REST API, dapatkan informasi tentang alur kerja Anda dengan menjalankan Alur Kerja - Dapatkan operasi menggunakan permintaan GET berikut, misalnya:
GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Ambil output dari Alur Kerja - Dapatkan operasi, dan periksa apakah objek sasAuthenticationPolicy ada di mana properti status diatur ke Dinonaktifkan.
Menambahkan properti sasAuthenticationPolicy ke definisi alur kerja Anda
Untuk alur kerja Konsumsi tempat Anda ingin menonaktifkan autentikasi SAS, ikuti langkah-langkah berikut:
Jika Anda belum melakukannya, dapatkan informasi tentang alur kerja Anda dengan menjalankan Alur Kerja - Dapatkan operasi menggunakan permintaan GET berikut, misalnya:
GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Ambil output dari Alur Kerja - Dapatkan operasi, dan tambahkan elemen berikut secara manual:
properties
Di objek, tambahkanaccessControl
objek yang berisitriggers
objek, jika tidak ada.triggers
Di objek , tambahkansasAuthenticationPolicy
objek yang berisi properti yangstate
diatur keDisabled
.
Setelah selesai, bagian yang diedit terlihat seperti contoh berikut:
"properties": { "accessControl": { "triggers": { "sasAuthenticationPolicy": { "state": "Disabled" } } } }
Kirim permintaan lain untuk memperbarui alur kerja Anda dengan output yang diedit, yang Anda gunakan sebagai input dalam isi permintaan, dengan menjalankan operasi Alur Kerja - Perbarui menggunakan permintaan PATCH berikut, misalnya:
PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
Di portal Azure, buka alur kerja Konsumsi Anda di perancang, dan konfirmasikan bahwa URL pemicu Permintaan tidak lagi menyertakan SAS.
Untuk mengaktifkan Oauth 2.0 dengan MICROSOFT Entra ID, di tingkat sumber daya aplikasi logika, tambahkan kebijakan otorisasi untuk OAuth dengan ID Microsoft Entra.
Untuk informasi selengkapnya, lihat Mengaktifkan OAuth 2.0 dengan ID Microsoft Entra.
Membuat ulang kunci akses
Untuk menjaga keamanan dan melindungi akses ke alur kerja aplikasi logika Anda, regenerasi kunci akses pada jadwal reguler karena mungkin perlu mematuhi kebijakan keamanan atau disusupi. Dengan cara ini, Anda dapat memastikan bahwa hanya permintaan yang diotorisasi yang dapat memicu alur kerja Anda, yang melindungi data dan proses Anda dari akses yang tidak sah.
Untuk menghasilkan kunci akses baru kapan saja, gunakan Azure REST API atau portal Azure. Semua URI atau URL yang dibuat sebelumnya yang menggunakan kunci lama tidak valid dan tidak lagi memiliki otorisasi untuk memicu alur kerja aplikasi logika Anda. URI yang Anda ambil setelah regenerasi ditandatangani dengan kunci akses baru.
Di portal Azure, buka sumber daya aplikasi logika yang menggunakan kunci yang ingin Anda regenerasi.
Pada menu sumber daya aplikasi logika, di bawah Pengaturan, pilih Kunci Akses.
Pilih kunci yang ingin Anda regenerasi dan selesaikan prosesnya.
Penting
Pastikan untuk melindungi kunci akses sama seperti Anda melindungi kunci akun dari penggunaan yang tidak sah. Menyiapkan atau memiliki rencana untuk mencabut kunci akses yang disusupi. Gunakan kebijaksanaan saat Anda mendistribusikan URI yang menggunakan kunci akses, dan hanya mendistribusikan URI tersebut melalui koneksi aman seperti HTTPS. Pastikan untuk hanya melakukan operasi yang menggunakan kunci akses melalui koneksi HTTPS. Siapa pun yang memiliki URI dengan kunci yang valid dapat mengakses sumber daya terkait.
Jika Anda menggunakan kunci SAS untuk mengakses layanan penyimpanan, Microsoft menyarankan agar Anda membuat SAS delegasi pengguna, yang diamankan dengan ID Microsoft Entra, bukan kunci akun.
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Membuat URL panggilan balik yang kedaluwarsa
Jika Anda membagikan URL titik akhir untuk pemicu berbasis permintaan dengan pihak lain, Anda dapat membuat URL panggilan balik yang menggunakan kunci tertentu dan memiliki tanggal kedaluwarsa. Dengan demikian, Anda dapat menggulung kunci atau membatasi akses dengan mulus untuk memicu aplikasi logika berdasarkan rentang waktu tertentu. Untuk menentukan tanggal kedaluwarsa untuk URL, gunakan Azure Logic Apps REST API, misalnya:
POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01
Dalam isi, sertakan NotAfter
properti dengan menggunakan string tanggal JSON. Properti ini mengembalikan URL panggil balik yang hanya valid hingga NotAfter
tanggal dan waktu.
Membuat URL dengan kunci rahasia primer atau sekunder
Saat Anda membuat atau mencantumkan URL panggil balik untuk pemicu berbasis permintaan, Anda dapat menentukan kunci yang akan digunakan untuk menandatangani URL. Untuk menghasilkan URL yang ditandatangani oleh kunci tertentu, gunakan REST API Azure Logic Apps, misalnya:
POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01
Dalam tubuh, KeyType
sertakan properti sebagai Primary
atau Secondary
. Properti ini mengembalikan URL yang ditandatangani oleh kunci keamanan yang ditentukan.
Mengekspos alur kerja aplikasi logika Anda dengan Azure API Management
Untuk protokol dan opsi autentikasi lainnya, pertimbangkan untuk mengekspos alur kerja aplikasi logika Anda sebagai API dengan menggunakan Azure API Management. Layanan ini menyediakan kemampuan pemantauan, keamanan, kebijakan, dan dokumentasi yang kaya untuk titik akhir apa pun. API Management dapat mengekspos titik akhir publik atau pribadi untuk aplikasi logika Anda. Untuk mengotorisasi akses ke titik akhir ini, Anda dapat menggunakan OAuth dengan ID Microsoft Entra, sertifikat klien, atau standar keamanan lainnya. Ketika API Management menerima permintaan, layanan mengirimkan permintaan ke aplikasi logika Anda dan membuat transformasi atau pembatasan yang diperlukan di sepanjang jalan. Untuk mengizinkan hanya API Management memanggil alur kerja aplikasi logika, Anda dapat membatasi alamat IP masuk aplikasi logika Anda.
Untuk informasi selengkapnya, lihat dokumentasi berikut:
- Tentang API Management
- Melindungi backend API web di Azure API Management dengan menggunakan otorisasi OAuth 2.0 dengan ID Microsoft Entra
- MENGAmankan API menggunakan autentikasi sertifikat klien di API Management
- Kebijakan autentikasi API Management
Membatasi alamat IP masuk
Bersama dengan Tanda Tangan Akses Bersama (SAS), Anda mungkin ingin secara khusus membatasi klien yang dapat memanggil alur kerja aplikasi logika Anda. Misalnya, jika Mengelola titik akhir permintaan dengan menggunakan Azure API Management, Anda dapat membatasi alur kerja aplikasi logika untuk menerima permintaan hanya dari alamat IP untuk instans layanan API Management yang Anda buat.
Terlepas dari alamat IP apa pun yang Anda tentukan, Anda masih dapat menjalankan alur kerja aplikasi logika yang memiliki pemicu berbasis permintaan dengan menggunakan Permintaan operasi Pemicu Alur Kerja - Jalankan atau dengan menggunakan API Management. Namun, skenario ini masih memerlukan autentikasi terhadap Azure REST API. Semua peristiwa muncul di Log Audit Azure. Pastikan Anda menetapkan kebijakan kontrol akses yang sesuai.
Untuk membatasi alamat IP masuk untuk alur kerja aplikasi logika Anda, ikuti langkah-langkah yang sesuai untuk templat portal Azure atau Azure Resource Manager Anda. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Dalam portal Azure, pembatasan alamat IP memengaruhi pemicu dan tindakan, bertentangan dengan deskripsi di portal di bawah Alamat IP masuk yang diizinkan. Untuk menyiapkan filter ini secara terpisah untuk pemicu dan untuk tindakan, gunakan accessControl
objek dalam templat Azure Resource Manager untuk sumber daya aplikasi logika Anda atau operasi Alur Kerja - Buat Atau Perbarui di REST API Azure Logic Apps.
Alur kerja untuk konsumsi
Di portal Azure, buka aplikasi logika Konsumsi Anda di perancang alur kerja.
Pada menu aplikasi logika, di bawah Pengaturan, pilih Pengaturan alur kerja.
Di bagian Konfigurasi kontrol akses, di bawah Alamat IP masuk yang diizinkan, pilih jalur untuk skenario Anda:
Agar alur kerja Anda dapat dipanggil menggunakan tindakan bawaan Azure Logic Apps, tetapi hanya sebagai alur kerja berlapis, pilih Hanya Logic Apps lainnya. Opsi ini hanya berfungsi saat Anda menggunakan tindakan Azure Logic Apps untuk memanggil alur kerja berlapis.
Opsi ini menulis array kosong ke sumber daya aplikasi logika Anda dan mengharuskan hanya panggilan dari alur kerja induk yang menggunakan tindakan Azure Logic Apps bawaan yang dapat memicu alur kerja berlapis.
Untuk membuat alur kerja Anda dapat dipanggil menggunakan tindakan HTTP, tetapi hanya sebagai alur kerja berlapis, pilih Rentang IP tertentu. Saat kotak Rentang IP untuk pemicu muncul, masukkan alamat IP keluar alur kerja induk. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Catatan
Jika Anda menggunakan opsi Hanya Logic Apps lainnya dan tindakan HTTP untuk memanggil alur kerja berlapis Anda, panggilan diblokir, dan Anda mendapatkan kesalahan "401 Tidak Sah".
Untuk skenario di mana Anda ingin membatasi panggilan masuk dari IP lain, saat kotak Rentang IP untuk pemicu muncul, tentukan rentang alamat IP yang diterima pemicu. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Secara opsional, di bawah Batasi panggilan untuk mendapatkan pesan masukan dan keluaran dari riwayat proses ke alamat IP yang diberikan, Anda dapat menentukan rentang alamat IP untuk panggilan masuk yang dapat mengakses pesan masukan dan keluaran dalam riwayat proses.
Alur kerja yang standar
Di portal Azure, buka sumber daya aplikasi logika Standard Anda.
Pada menu aplikasi logika, di bawah Pengaturan, pilih Jaringan.
Di bagian Konfigurasi lalu lintas masuk, di samping Akses jaringan publik, pilih Diaktifkan tanpa batasan akses.
Pada halaman Pembatasan akses, di bawah Akses aplikasi, pilih Diaktifkan dari jaringan virtual dan alamat IP tertentu.
Di bawah Akses dan aturan situs, pada tab Situs utama, tambahkan satu atau beberapa aturan ke Izinkan atau Tolak permintaan dari rentang IP tertentu. Rentang IP yang valid menggunakan format ini: x.x.x.x/x atau x.x.x.x-x-x.x
Untuk informasi selengkapnya, lihat Memblokir alamat IP masuk di Azure Logic Apps (Standar).
Akses untuk panggilan keluar ke layanan dan sistem lain
Berdasarkan kemampuan titik akhir target, panggilan keluar yang dikirim oleh pemicu HTTP atau tindakan HTTP, mendukung enkripsi dan diamankan dengan Transport Layer Security (TLS) 1.0, 1.1, atau 1.2, sebelumnya dikenal sebagai Secure Sockets Layer (SSL). Azure Logic Apps bernegosiasi dengan titik akhir target untuk menggunakan versi setinggi mungkin yang didukung. Misalnya, jika target endpoint mendukung 1.2, pemicu atau tindakan HTTP menggunakan 1.2 terlebih dahulu. Jika tidak, konektor menggunakan versi tertinggi berikutnya yang didukung.
Daftar ini mencakup informasi tentang sertifikat yang ditandatangani sendiri TLS/SSL:
Untuk alur kerja aplikasi logika Konsumsi di lingkungan Azure Logic Apps multipenyewa, operasi HTTP tidak mengizinkan sertifikat TLS/SSL yang ditandatangani sendiri. Jika aplikasi logika Anda melakukan panggilan HTTP ke server dan menyajikan sertifikat TLS / SSL yang ditandatangani sendiri, panggilan HTTP gagal dengan
TrustFailure
kesalahan.Untuk alur kerja aplikasi logika Standar di lingkungan Azure Logic Apps penyewa tunggal, operasi HTTP mendukung sertifikat TLS/SSL yang ditandatangani sendiri. Namun, Anda harus menyelesaikan beberapa langkah tambahan untuk tipe autentikasi ini. Jika tidak, panggilan gagal. Untuk informasi selengkapnya, tinjau Autentikasi sertifikat TLS/SSL untuk Azure Logic Apps penyewa tunggal.
Jika Anda ingin menggunakan sertifikat klien atau OAuth dengan ID Microsoft Entra dengan jenis kredensial Sertifikat , Anda masih harus menyelesaikan beberapa langkah tambahan untuk jenis autentikasi ini. Jika tidak, panggilan gagal. Untuk informasi selengkapnya, lihat Sertifikat klien atau OAuth dengan ID Microsoft Entra dengan jenis kredensial "Sertifikat" untuk Azure Logic Apps penyewa tunggal.
Berikut adalah cara lainnya untuk membantu mengamankan titik akhir yang menangani panggilan yang dikirim dari alur kerja aplikasi logika Anda:
Tambahkan autentikasi ke permintaan keluar.
Saat Anda menggunakan pemicu atau tindakan HTTP untuk mengirim panggilan keluar, Anda dapat menambahkan autentikasi ke permintaan yang dikirim oleh aplikasi logika Anda. Contohnya, Anda dapat memilih tipe autentikasi ini:
Membatasi akses dari alamat IP alur kerja aplikasi logika.
Semua panggilan ke titik akhir dari alur kerja aplikasi logika berasal dari alamat IP tertentu yang ditunjuk yang didasarkan pada wilayah aplikasi logika Anda. Anda dapat menambahkan pemfilteran yang hanya menerima permintaan dari alamat IP tersebut. Untuk mendapatkan alamat IP ini, tinjau Batas dan konfigurasi untuk Azure Logic Apps.
Meningkatkan keamanan untuk koneksi ke sistem lokal.
Azure Logic Apps menyediakan integrasi dengan layanan ini untuk membantu menyediakan komunikasi lokal yang lebih aman dan andal.
Gateway data lokal
Banyak konektor terkelola di Azure Logic Apps memfasilitasi koneksi aman ke sistem lokal, seperti Sistem File, SQL, SharePoint, dan DB2. Gateway mengirim data dari sumber lokal di saluran terenkripsi melalui Azure Service Bus. Semua lalu lintas berasal sebagai lalu lintas keluar yang diamankan dari agen gateway. Pelajari cara kerja gateway data di tempat.
Menyambungkan melalui API Management Azure
Azure API Management menyediakan opsi koneksi lokal, seperti jaringan pribadi virtual situs-ke-situs dan integrasi ExpressRoute untuk proksi dan komunikasi yang aman ke sistem lokal. Jika Anda memiliki API yang menyediakan akses ke sistem lokal Anda, dan Anda mengekspos API tersebut dengan membuat instans layanan API Management, Anda dapat memanggil API tersebut dari alur kerja aplikasi logika Anda dengan memilih operasi API Management yang sesuai di perancang alur kerja.
Catatan
Konektor hanya menampilkan layanan API Management di mana Anda memiliki izin untuk melihat dan terhubung, tetapi tidak menampilkan layanan API Management berbasis konsumsi.
Berdasarkan jenis sumber daya aplikasi logika Anda, ikuti langkah-langkah yang sesuai:
Alur kerja konsumsi
Berdasarkan apakah Anda menambahkan pemicu atau tindakan API Management, ikuti langkah-langkah berikut:
Pelatuk:
Pada perancang alur kerja, pilih Tambahkan pemicu.
Setelah panel Tambahkan pemicu terbuka, di kotak pencarian, masukkan API Management.
Dari daftar hasil pemicu, pilih Pilih Pemicu Azure API Management.
Tindakan:
Pada perancang alur kerja, pilih tanda plus (+) tempat Anda ingin menambahkan tindakan.
Setelah panel Tambahkan tindakan terbuka, di kotak pencarian, masukkan API Management.
Dari daftar hasil tindakan, pilih Pilih tindakan Azure API Management.
Contoh berikut menunjukkan menemukan pemicu Azure API Management:
Dari daftar instans layanan API Management, pilih instans layanan API Management yang dibuat sebelumnya.
Dari daftar operasi API, pilih operasi API untuk dipanggil, lalu pilih Tambahkan Tindakan.
Alur kerja standar
Untuk alur kerja Standar, Anda hanya dapat menambahkan tindakan API Management , bukan pemicu.
Pada perancang alur kerja, pilih tanda plus (+) tempat Anda ingin menambahkan tindakan.
Setelah panel Tambahkan tindakan terbuka, di kotak pencarian, masukkan API Management.
Dari daftar hasil tindakan, pilih Panggil API Api Management Azure.
Dari daftar instans layanan API Management, pilih instans layanan API Management yang dibuat sebelumnya.
Dari daftar operasi API, pilih operasi API untuk dipanggil, lalu pilih Buat Baru.
Menambahkan autentikasi ke panggilan keluar
Titik akhir HTTP dan HTTPS mendukung berbagai jenis autentikasi. Pada beberapa pemicu dan tindakan yang Anda gunakan untuk mengirim panggilan keluar atau permintaan ke titik akhir ini, Anda bisa menentukan tipe autentikasi. Dalam perancang alur kerja, pemicu dan tindakan yang mendukung pemilihan jenis autentikasi memiliki properti Autentikasi. Namun, properti ini mungkin tidak selalu muncul secara default. Dalam kasus ini, pada pemicu atau tindakan, buka daftar Parameter tingkat lanjut, dan pilih Autentikasi.
Penting
Untuk melindungi informasi sensitif yang ditangani alur kerja aplikasi logika Anda, gunakan parameter aman dan kodekan data seperlunya. Untuk informasi selengkapnya tentang menggunakan dan mengamankan parameter, tinjau Akses ke input parameter.
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Autentikasi dasar
Untuk panggilan HTTP, autentikasi dasar menggunakan string yang dikodekan base64 yang berisi nama pengguna dan kata sandi untuk membuat permintaan. Metode ini mengirimkan kredensial tanpa enkripsi dan menimbulkan peningkatan risiko keamanan kecuali Anda menggunakan opsi ini dengan protokol HTTPS/SSL.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Jika opsi Dasar tersedia dan dipilih, tentukan nilai properti ini:
Properti (desainer) | Properti (JSON) | Wajib | Nilai | Deskripsi |
---|---|---|---|---|
Autentikasi | type |
Ya | Dasar | Jenis autentikasi untuk digunakan |
Username | username |
Ya | <user-name> | Nama pengguna untuk mengautentikasi akses ke titik akhir layanan target |
Password | password |
Ya | <kata sandi> | Kata sandi untuk mengautentikasi akses ke titik akhir layanan target |
Saat Anda menggunakan parameter aman untuk menangani dan mengamankan informasi sensitif, misalnya, dalam templat Azure Resource Manager untuk mengotomatiskan penyebaran,Anda dapat menggunakan ekspresi untuk mengakses nilai parameter ini pada waktu proses. Contoh definisi tindakan HTTP ini menetapkan autentikasi type
sebagai Basic
dan menggunakan fungsi parameters() untuk mendapatkan nilai parameter:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Basic",
"username": "@parameters('userNameParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
Autentikasi sertifikat klien
Autentikasi sertifikat klien memungkinkan atau mengharuskan pengguna untuk mengautentikasi langsung dengan sertifikat X.509 terhadap ID Microsoft Entra mereka untuk aplikasi dan masuk browser. Kemampuan ini membantu Anda mengadopsi autentikasi tahan pengelabuan dan mengautentikasi dengan sertifikat X.509 terhadap Infrastruktur Kunci Umum (PKI) Anda.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Jika opsi Sertifikat klien tersedia dan dipilih, tentukan nilai properti ini:
Properti (desainer) | Properti (JSON) | Wajib | Nilai | Deskripsi |
---|---|---|---|---|
Autentikasi | type |
Ya | Sertifikat klien atau ClientCertificate |
Jenis autentikasi untuk digunakan. Anda dapat mengelola sertifikat dengan Azure API Management. Catatan: Konektor khusus tidak mendukung autentikasi berbasis sertifikat untuk panggilan masuk dan keluar. |
Pfx | pfx |
Ya | <encoded-pfx-file-content> | Konten yang dikodekan base64 dari file Pertukaran Informasi Pribadi (PFX) Untuk mengonversi file PFX menjadi format yang dikodekan base64, Anda bisa menggunakan PowerShell 7 dengan mengikuti langkah-langkah berikut: 1. Simpan konten sertifikat ke dalam variabel: $pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx') 2. Konversikan konten sertifikat dengan menggunakan fungsi dan simpan konten tersebut ToBase64String() ke file teks: [System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt' Pemecahan masalah: Jika Anda menggunakan cert mmc/PowerShell perintah , Anda mungkin mendapatkan kesalahan ini: Could not load the certificate private key. Please check the authentication certificate password is correct and try again. Untuk mengatasi kesalahan ini, coba konversi file PFX ke file PEM dan kembali lagi dengan menggunakan openssl perintah : openssl pkcs12 -in certificate.pfx -out certificate.pem openssl pkcs12 -in certificate.pem -export -out certificate2.pfx Setelah itu, ketika Anda mendapatkan string bersandi base64 untuk file PFX sertifikat yang baru dikonversi, string sekarang berfungsi di Azure Logic Apps. |
Password | password |
No | <file-sandi-untuk-pfx> | Kata sandi untuk mengakses file PFX |
Catatan
Jika Anda mencoba mengautentikasi dengan sertifikat klien menggunakan OpenSSL, Anda mungkin mendapatkan kesalahan berikut:
BadRequest: Could not load private key
Untuk mengatasi kesalahan ini, ikuti langkah-langkah ini:
- Hapus instalan semua instans OpenSSL.
- Instal OpenSSL versi 1.1.1t.
- Resign sertifikat Anda menggunakan pembaruan baru.
- Tambahkan sertifikat baru ke operasi HTTP saat menggunakan autentikasi sertifikat klien.
Saat Anda menggunakan parameter aman untuk menangani dan mengamankan informasi sensitif, misalnya, dalam templat Azure Resource Manager untuk mengotomatiskan penyebaran,Anda dapat menggunakan ekspresi untuk mengakses nilai parameter ini pada waktu proses. Contoh definisi tindakan HTTP ini menetapkan autentikasi type
sebagai ClientCertificate
dan menggunakan fungsi parameters() untuk mendapatkan nilai parameter:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ClientCertificate",
"pfx": "@parameters('pfxParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
Penting
Jika Anda memiliki sumber daya aplikasi logika Standar di Azure Logic Apps penyewa tunggal, dan Anda ingin menggunakan operasi HTTP dengan sertifikat TSL/SSL, sertifikat klien, atau Autentikasi Terbuka ID Entra Microsoft (Microsoft Entra ID OAuth) dengan Certificate
jenis kredensial, pastikan untuk menyelesaikan langkah-langkah penyiapan tambahan untuk jenis autentikasi ini. Jika tidak, panggilan gagal. Untuk informasi selengkapnya, tinjau Autentikasi di lingkungan penyewa tunggal.
Untuk informasi selengkapnya tentang mengamankan layanan dengan menggunakan autentikasi sertifikat klien, tinjau topik berikut:
- Meningkatkan keamanan untuk API dengan menggunakan autentikasi sertifikat klien di Azure API Management
- Meningkatkan keamanan untuk layanan back-end dengan menggunakan autentikasi sertifikat klien di Azure API Management
- Tingkatkan keamanan untuk layanan RESTfuL Anda dengan menggunakan sertifikat klien
- Mandat sertifikat untuk autentikasi aplikasi
- Menggunakan sertifikat TLS/SSL dalam kode Anda di Azure App Service
Platform Microsoft Entra
Pada pemicu Permintaan , Anda dapat menggunakan platform Microsoft Entra untuk mengautentikasi panggilan masuk setelah menyiapkan kebijakan otorisasi Microsoft Entra untuk aplikasi logika Anda.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Pada semua pemicu dan tindakan lain yang mendukung jenis autentikasi Active Directory OAuth (OAuth 2.0 dengan MICROSOFT Entra ID), tentukan nilai properti ini:
Properti (desainer) | Properti (JSON) | Wajib | Nilai | Deskripsi |
---|---|---|---|---|
Autentikasi | type |
Ya | Active Directory OAuth (OAuth 2.0 dengan MICROSOFT Entra ID) atau ActiveDirectoryOAuth |
Jenis autentikasi untuk digunakan. Azure Logic Apps saat ini mengikuti protokol OAuth 2.0. |
Wewenang | authority |
No | <URL-untuk-penerbit-token-otorisasi> | URL untuk otoritas yang menyediakan kunci akses, seperti https://login.microsoftonline.com/ untuk wilayah layanan global Azure. Untuk cloud nasional lainnya, tinjau titik akhir autentikasi Microsoft Entra - Memilih otoritas identitas Anda. |
Penyewa | tenant |
Ya | <tenant-ID> | ID penyewa untuk penyewa Microsoft Entra |
Audiens | audience |
Ya | <sumber daya untuk diotorisasi> | Sumber daya yang ingin Anda gunakan untuk otorisasi, misalnya, https://management.core.windows.net/ |
ID klien | clientId |
Ya | <client-ID> | ID klien untuk aplikasi yang meminta otorisasi |
Jenis Informasi masuk | credentialType |
Ya | Sertifikat atau Rahasia |
Tipe kredensial yang digunakan klien untuk meminta otorisasi. Properti dan nilai ini tidak muncul dalam definisi yang mendasari aplikasi logika Anda, tetapi menentukan properti yang muncul untuk tipe kredensial yang dipilih. |
Rahasia | secret |
Ya, tetapi hanya untuk jenis kredensial "Rahasia" | <client-secret> | Rahasia klien untuk meminta otorisasi |
Pfx | pfx |
Ya, tetapi hanya untuk tipe kredensial "Sertifikat" | <encoded-pfx-file-content> | Konten berkode base64 dari file Pertukaran Informasi Pribadi (PFX) |
Password | password |
Ya, tetapi hanya untuk tipe kredensial "Sertifikat" | <file-sandi-untuk-pfx> | Kata sandi untuk mengakses file PFX |
Saat Anda menggunakan parameter aman untuk menangani dan mengamankan informasi sensitif, misalnya, dalam templat Azure Resource Manager untuk mengotomatiskan penyebaran,Anda dapat menggunakan ekspresi untuk mengakses nilai parameter ini pada waktu proses. Contoh definisi tindakan HTTP ini menetapkan autentikasi type
sebagai ActiveDirectoryOAuth
, jenis kredensial sebagai Secret
, dan menggunakan fungsi parameter() untuk mendapatkan nilai parameter:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ActiveDirectoryOAuth",
"tenant": "@parameters('tenantIdParam')",
"audience": "https://management.core.windows.net/",
"clientId": "@parameters('clientIdParam')",
"credentialType": "Secret",
"secret": "@parameters('secretParam')"
}
},
"runAfter": {}
}
Penting
Jika Anda memiliki sumber daya aplikasi logika Standar di Azure Logic Apps penyewa tunggal, dan Anda ingin menggunakan operasi HTTP dengan sertifikat TSL/SSL, sertifikat klien, atau Microsoft Entra ID OAuth dengan Certificate
jenis kredensial, pastikan untuk menyelesaikan langkah-langkah penyiapan tambahan untuk jenis autentikasi ini. Jika tidak, panggilan gagal. Untuk informasi selengkapnya, lihat Autentikasi di lingkungan penyewa tunggal.
Autentikasi Raw
Jika opsi Raw tersedia, Anda dapat menggunakan jenis autentikasi ini bila harus menggunakan skema autentikasi yang tidak mengikuti protokol OAuth 2.0. Dengan tipe ini, Anda secara manual membuat nilai header otorisasi yang Anda kirim dengan permintaan keluar, dan menentukan nilai header tersebut dalam pemicu atau tindakan Anda.
Penting
Untuk keamanan yang optimal, Microsoft merekomendasikan penggunaan ID Microsoft Entra dengan identitas terkelola untuk autentikasi jika memungkinkan. Opsi ini memberikan keamanan yang unggul tanpa harus memberikan kredensial. Azure mengelola identitas ini dan membantu menjaga keamanan informasi autentikasi sehingga Anda tidak perlu mengelola informasi sensitif ini. Untuk menyiapkan identitas terkelola untuk Azure Logic Apps, lihat Mengautentikasi akses dan koneksi ke sumber daya Azure dengan identitas terkelola di Azure Logic Apps.
Contoh berikut menunjukkan contoh tajuk untuk permintaan HTTPS yang mengikuti protokol OAuth 1.0:
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
Dalam pemicu atau tindakan yang mendukung autentikasi raw, tentukan nilai properti ini:
Properti (desainer) | Properti (JSON) | Wajib | Nilai | Deskripsi |
---|---|---|---|---|
Autentikasi | type |
Ya | Mentah | Jenis autentikasi untuk digunakan |
Nilai | value |
Ya | <nilai header-otorisasi> | Nilai header otorisasi yang digunakan untuk autentikasi |
Saat Anda menggunakan parameter aman untuk menangani dan mengamankan informasi sensitif, misalnya, dalam templat Azure Resource Manager untuk mengotomatiskan penyebaran,Anda dapat menggunakan ekspresi untuk mengakses nilai parameter ini pada waktu proses. Contoh definisi tindakan HTTP ini menetapkan autentikasi type
sebagaiRaw
dan menggunakan fungsi parameters() untuk mendapatkan nilai parameter:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Raw",
"value": "@parameters('authHeaderParam')"
}
},
"runAfter": {}
}
Autentikasi identitas terkelola
Saat opsi identitas terkelola tersedia pada pemicu atau tindakan yang mendukung autentikasi identitas terkelola, aplikasi logika Anda dapat menggunakan identitas ini untuk mengautentikasi akses ke sumber daya Azure yang dilindungi oleh ID Microsoft Entra, bukan kredensial, rahasia, atau token Microsoft Entra. Azure mengelola identitas ini untuk Anda dan membantu Anda mengamankan kredensial karena Anda tidak perlu mengelola rahasia atau langsung menggunakan token Microsoft Entra. Pelajari selengkapnya tentang layanan Azure yang mendukung identitas terkelola untuk autentikasi Microsoft Entra.
Sumber daya aplikasi logika Konsumsi dapat menggunakan identitas yang ditetapkan sistem atau satu identitas yang ditetapkan pengguna yang dibuat secara manual.
Sumber daya aplikasi logika Standar mendukung identitas terkelola yang ditetapkan sistem dan beberapa identitas terkelola yang ditetapkan pengguna yang diaktifkan secara bersamaan, meskipun Anda masih hanya dapat memilih satu identitas untuk digunakan kapan saja.
Catatan
Secara default, identitas yang ditetapkan sistem sudah diaktifkan untuk mengotentikasi koneksi pada waktu proses. Identitas ini berbeda dari info masuk autentikasi atau string koneksi yang digunakan saat membuat koneksi. Jika Anda menonaktifkan identitas ini, koneksi tidak akan berfungsi saat runtime. Untuk melihat pengaturan ini, pada menu aplikasi logika Anda, di bawah Pengaturan, pilih Identitas.
Sebelum aplikasi logika Anda dapat menggunakan identitas terkelola, ikuti langkah-langkah dalam Mengautentikasi akses ke sumber daya Azure dengan menggunakan identitas terkelola di Azure Logic Apps. Langkah-langkah ini memungkinkan identitas terkelola pada aplikasi logika Anda dan menyiapkan akses identitas tersebut ke sumber daya Azure target.
Sebelum fungsi Azure dapat menggunakan identitas terkelola, pertama aktifkan autentikasi untuk fungsi Azure terlebih dahul.
Dalam pemicu atau tindakan yang mendukung penggunaan identitas terkelola, berikan informasi ini:
Pemicu dan tindakan bawaan
Properti (desainer) Properti (JSON) Wajib Nilai Deskripsi Autentikasi type
Ya Identitas Terkelola
atauManagedServiceIdentity
Jenis autentikasi untuk digunakan Identitas Terkelola identity
No <ID-identitas-ditetapkan-pengguna> Identitas terkelola yang ditetapkan pengguna untuk digunakan. Catatan: Jangan sertakan properti ini saat menggunakan identitas terkelola yang ditetapkan sistem. Audiens audience
Ya <ID sumber daya target> ID sumber daya untuk sumber daya target yang ingin Anda akses.
Misalnya,https://storage.azure.com/
membuat token akses untuk autentikasi valid untuk semua akun penyimpanan. Namun, Anda juga dapat menentukan URL layanan root, sepertihttps://fabrikamstorageaccount.blob.core.windows.net
untuk akun penyimpanan tertentu.
Catatan: Properti Pemirsa mungkin disembunyikan di beberapa pemicu atau tindakan. Untuk membuat properti ini terlihat, dalam pemicu atau tindakan, buka daftar Parameter tingkat lanjut, dan pilih Audiens.
Penting: Pastikan ID sumber daya target ini sama persis dengan nilai yang diharapkan ID Microsoft Entra, termasuk garis miring berikutnya yang diperlukan. Jadi,https://storage.azure.com/
ID sumber daya untuk semua akun Azure Blob Storage memerlukan garis miring. Namun, ID sumber daya untuk akun penyimpanan tertentu tidak memerlukan garis miring. Untuk menemukan ID sumber daya ini, tinjau layanan Azure yang mendukung ID Microsoft Entra.Saat Anda menggunakan parameter aman untuk menangani dan mengamankan informasi sensitif, misalnya, dalam templat Azure Resource Manager untuk mengotomatiskan penyebaran,Anda dapat menggunakan ekspresi untuk mengakses nilai parameter ini pada waktu proses. Misalnya, definisi tindakan HTTP ini menetapkan autentikasi
type
sebagaiManagedServiceIdentity
dan menggunakan fungsi parameters() untuk mendapatkan nilai parameter:"HTTP": { "type": "Http", "inputs": { "method": "GET", "uri": "@parameters('endpointUrlParam')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.azure.com/" }, }, "runAfter": {} }
Pemicu dan tindakan konektor terkelola
Properti (desainer) Wajib Nilai Deskripsi Nama koneksi Ya <nama-koneksi> Identitas terkelola Ya Identitas terkelola yang ditetapkan sistem
atau
<user-assigned-managed-identity-name>Jenis autentikasi untuk digunakan
Memblokir pembuatan sambungan
Jika organisasi Anda tidak mengizinkan penyambungan ke sumber daya tertentu dengan menggunakan konektornya di Azure Logic Apps, Anda dapat memblokir kemampuan untuk membuat sambungan tersebut untuk konektor tertentu dalam alur kerja aplikasi logika dengan menggunakan Azure Policy. Untuk informasi selengkapnya, tinjau Blokir koneksi yang dibuat oleh konektor tertentu di Azure Logic Apps.
Panduan isolasi untuk aplikasi logika
Anda dapat menggunakan Azure Logic Apps di Azure Government yang mendukung semua tingkat dampak di wilayah yang dijelaskan oleh Panduan Isolasi Tingkat 5 Dampak Azure Pemerintah. Untuk memenuhi persyaratan ini, Azure Logic Apps mendukung kemampuan Anda untuk membuat dan menjalankan alur kerja di lingkungan dengan sumber daya khusus sehingga Anda dapat mengurangi dampak performa oleh penyewa Azure lainnya pada logic apps Anda dan menghindari berbagi sumber daya komputasi dengan penyewa lain.
Alur kerja aplikasi logika standar dapat berkomunikasi secara privat dan aman dengan jaringan virtual Azure melalui titik akhir privat yang Anda siapkan untuk lalu lintas masuk dan integrasi jaringan virtual untuk lalu lintas keluar. Untuk informasi selengkapnya, tinjau lalu lintas aman antara jaringan virtual dan Azure Logic Apps penyewa tunggal menggunakan titik akhir privat.
Untuk menjalankan kode Anda sendiri atau melakukan transformasi XML, buat dan panggil fungsi Azure, daripada menggunakan kemampuan kode sebaris atau menyediakan rakitan untuk digunakan sebagai peta, masing-masing. Selain itu, siapkan lingkungan hosting untuk aplikasi fungsi Anda untuk mematuhi persyaratan isolasi Anda.
Misalnya, untuk memenuhi persyaratan Impact Level 5, buat aplikasi fungsi Anda dengan paket App Service menggunakan tingkat harga Terisolasi bersama dengan App Service Environtment (ASE) yang juga menggunakan tingkat harga Terisolasi. Dalam lingkungan ini, aplikasi fungsi berjalan pada mesin virtual Azure khusus dan jaringan virtual Azure khusus, yang menyediakan isolasi jaringan di atas isolasi komputasi untuk aplikasi Anda dan kemampuan peluasan skala maksimum.
Untuk informasi selengkapnya, tinjau dokumentasi berikut ini:
Untuk informasi selengkapnya tentang isolasi, lihat dokumentasi berikut ini: