Akses dan data aman untuk alur kerja di Azure Logic Apps

  • Artikel

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:

Untuk informasi selengkapnya tentang keamanan di Azure, tinjau topik berikut:

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

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 diperbolehkan, ikuti langkah-langkah ini untuk portal Azure atau templat Azure Resource Manager Anda:

Alur kerja untuk konsumsi

  1. Di portal Microsoft Azure, buka alur kerja aplikasi logika Anda di perancang.

  2. Pada menu aplikasi logika Anda, di bawah Setelan, pilih Setelan alur kerja.

  3. Di bawah Konfigurasi kontrol akses>Alamat IP masuk yang diizinkan, pilih Rentang IP tertentu.

  4. Di bawah Rentang IP untuk konten, tentukan rentang alamat IP yang dapat mengakses konten dari masukan dan keluaran.

Alur kerja yang standar

  1. Di portal Microsoft Azure, buka sumber daya aplikasi logika Anda.

  2. Pada menu aplikasi logika, di bawah Pengaturan, pilih Jaringan.

  3. Di bagian Lalu Lintas Masuk, pilih Pembatasan akses.

  4. Buat satu atau beberapa aturan untuk Mengizinkan atau Menolak permintaan dari rentang IP tertentu. Anda juga dapat menggunakan pengaturan filter header HTTP dan pengaturan penerusan.

    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 bawaanberikut ini 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
Jika
Variabel kenaikan
Menginisialisasi variabel
Kekambuhan
Lingkup
Atur variabel
Beralih
Mengakhiri
Hingga		 Tambahkan ke variabel array
Tambahkan ke variabel string
Menulis
Variabel pengurangan
Untuk masing-masing
Jika
Variabel kenaikan
Menginisialisasi variabel
Mengurai JSON
Kekambuhan
Respon
Lingkup
Atur variabel
Beralih
Mengakhiri
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.

    Output aman sebagai input dan dampak hilir pada sebagian besar 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.

    Output aman sebagai input dengan dampak hilir pada tindakan tertentu

    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 downstream secara eksplisit menggunakan output yang terlihat dari pemicu atau tindakan tersebut sebagai masukan, Azure Logic Apps menyembunyikan masukan tindakan hilir ini dalam riwayat proses, namun tidak mengaktifkanInput Aman di tindakan ini dan tidak menyembunyikan output tindakan ini.

    Input yang diamankan dan dampak hilir pada sebagian besar tindakan

    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 yang diamankan dan dampak hilir pada tindakan tertentu

Input dan output aman dalam desainer

  1. Di portal Microsoft Azure, buka alur kerja aplikasi logika Anda di perancang.

  2. Pada perancang, pilih pemicu atau tindakan tempat Anda ingin mengamankan data sensitif.

  3. Pada panel informasi yang terbuka, pilih Pengaturan, dan perluas Keamanan.

    Cuplikan layar memperlihatkan portal Azure, perancang alur kerja, dan pemicu atau tindakan dengan pengaturan yang dibuka.

  4. Aktifkan Input Aman, Keluaran Aman, atau keduanya.

    Cuplikan layar memperlihatkan alur kerja dengan pengaturan Input Aman atau Output Aman tindakan diaktifkan.

    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.

    Cuplikan layar memperlihatkan alur kerja dengan daftar konten dinamis tindakan berikutnya terbuka, dan token tindakan sebelumnya untuk output aman dengan ikon kunci.

  5. Setelah alur kerja berjalan, Anda bisa menampilkan riwayat untuk eksekusi tersebut.

    1. Pilih Gambaran Umum baik pada menu aplikasi logika Konsumsi atau pada menu alur kerja Standar.

    2. Di bawah Riwayat eksekusi, pilih eksekusi yang ingin Anda lihat.

    3. 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.

      Cuplikan layar memperlihatkan tampilan Riwayat eksekusi alur kerja standar dengan input dan output 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:

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:

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.

"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.

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 API Management Azure, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Sertifikat klien API Management Azure, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuth - Konsumsi: Azure API Management, Azure App Services, 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 API Management Azure, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, WEBhook HTTP
Identitas terkelola Konektor bawaan:

- Konsumsi: Azure API Management, Azure App Services, 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

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, enkripsi dukungan dan diamankan dengan Transport Layer Security (TLS ) minimal 1.2, sebelumnya dikenal sebagai Secure Sockets Layer (SSL). Azure Logic Apps menerapkan versi ini saat menerima panggilan masuk ke pemicu Permintaan atau panggilan balik ke pemicu atau tindakan HTTP Webhook. Jika Anda mendapatkan kesalahan jabat tangan TLS, pastikan Anda menggunakan TLS 1.2. Untuk informasi selengkapnya, tinjau 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

Catatan

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 cipher berikut jika Anda memeriksa pesan jabat tangan TLS saat menggunakan layanan 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 lebih banyak cara agar Anda dapat membatasi akses ke pemicu yang menerima panggilan masuk ke aplikasi logika Anda sehingga hanya klien yang berwenang yang dapat menghubungi aplikasi logika Anda:

Hasilkan tanda tangan akses bersama (SAS)

Setiap titik akhir permintaan pada aplikasi logika memiliki Tanda Tangan Akses Bersama (SAS) di URL titik akhir, yang mengikuti format ini:

https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>

Setiap URL berisi parameter kueri sp, sv, dan sig seperti yang dijelaskan dalam tabel ini:

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 disimpan terenkripsi, 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.

Panggilan masuk ke titik akhir permintaan hanya dapat menggunakan satu skema otorisasi, baik SAS atau OAuth dengan ID Microsoft Entra. Meskipun menggunakan satu skema tidak menonaktifkan skema lainnya, menggunakan kedua skema secara bersamaan menyebabkan kesalahan karena layanan tidak tahu skema mana yang harus dipilih.

Untuk informasi selengkapnya tentang mengamankan akses dengan SAS, tinjau bagian ini dalam topik ini:

Membuat ulang kunci akses

Untuk menghasilkan kunci akses keamanan baru kapan saja, gunakan Azure REST API atau portal Azure. Semua URL yang dihasilkan sebelumnya yang menggunakan kunci lama tidak valid dan tidak lagi memiliki otorisasi untuk memicu aplikasi logika. URL yang Anda ambil setelah regenerasi ditandatangani dengan kunci akses baru.

  1. Di portal Azure,buka aplikasi logika yang memiliki kunci yang ingin Anda regenerasi.

  2. Pada menu sumber daya aplikasi logika, di bawah Pengaturan, pilih Kunci Akses.

  3. Pilih kunci yang ingin Anda regenerasi dan selesaikan prosesnya.

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/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group-name>/providers/Microsoft.Logic/workflows/<workflow-name>/triggers/<trigger-name>/listCallbackUrl?api-version=2016-06-01

Dalam isi, NotAfter sertakan 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 membuat URL yang ditandatangani oleh kunci tertentu, gunakan Logic Apps REST API, misalnya:

POST /subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-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.

Mengaktifkan Autentikasi Terbuka ID Microsoft Entra (Microsoft Entra ID OAuth)

Dalam alur kerja aplikasi logika Konsumsi yang dimulai dengan pemicu berbasis permintaan, Anda dapat mengautentikasi panggilan masuk yang dikirim ke titik akhir yang dibuat oleh pemicu tersebut dengan mengaktifkan Microsoft Entra ID OAuth. Untuk menyiapkan autentikasi ini, tentukan atau tambahkan kebijakan otorisasi di tingkat 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 aplikasi logika Standar yang dimulai dengan pemicu Permintaan (tetapi bukan pemicu webhook), Anda dapat menggunakan ketentuan Azure Functions untuk mengautentikasi panggilan masuk yang dikirim ke titik akhir yang dibuat oleh pemicu tersebut dengan menggunakan identitas terkelola. Ketentuan ini dikenal juga sebagai "Easy Auth". Untuk informasi selengkapnya, tinjau Alur kerja pemicu di aplikasi logika Standar dengan Easy Auth.

Pertimbangan sebelum Anda mengaktifkan Microsoft Entra ID OAuth

  • Panggilan masuk ke titik akhir permintaan hanya dapat menggunakan satu skema otorisasi, baik OAuth dengan ID Microsoft Entra atau Tanda Tangan Akses Bersama (SAS). Meskipun menggunakan satu skema tidak menonaktifkan skema lainnya, menggunakan kedua skema secara bersamaan menyebabkan kesalahan karena Azure Logic Apps tidak tahu skema mana yang harus dipilih.

  • 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 menentukan Bearer jenis atau PoP jenisnya. Untuk informasi selengkapnya tentang cara mendapatkan dan menggunakan token PoP, lihat Mendapatkan token Proof of Possession (PoP).

  • Sumber daya aplikasi logika 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/ atau https://login.microsoftonline.com/ (OAuth V2) sebagai ID penerbit 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 dan iss 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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
    "unique_name": "SophiaOwen@fabrikam.com",
    "upn": "SophiaOwen@fabrikam.com",
    "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
    "ver": "1.0"
}

Aktifkan Microsoft Entra ID OAuth sebagai satu-satunya opsi untuk memanggil titik akhir permintaan

  1. Siapkan pemicu webhook Permintaan atau HTTP 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.

  2. Di portal Azure, buka alur kerja aplikasi logika Penggunaan Anda di perancang.

  3. Pada perancang, pilih pemicu. Pada panel informasi yang terbuka, pilih Pengaturan.

  4. 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 yang ingin Anda panggil memerlukan token PoP, Anda bisa mendapatkan token ini menggunakan pustaka MSAL. Sampel berikut menunjukkan cara memperoleh token PoP:

Untuk menggunakan token PoP dengan alur kerja aplikasi logika Konsumsi Anda, ikuti bagian berikutnya untuk menyiapkan OAuth dengan ID Microsoft Entra.

Mengaktifkan Microsoft Entra ID OAuth untuk sumber daya aplikasi logika Konsumsi Anda

Ikuti langkah-langkah ini untuk portal Azure atau templat Azure Resource Manager Anda:

Di portal Azure, tambahkan satu atau beberapa kebijakan otorisasi ke sumber daya aplikasi logika Konsumsi Anda:

  1. Di portal Azure, buka aplikasi logika Konsumsi Anda di perancang alur kerja.

  2. Pada menu sumber daya aplikasi logika, di bawah Pengaturan, pilih Otorisasi. Setelah panel Otorisasi terbuka, pilih Tambahkan kebijakan.

    Cuplikan layar yang memperlihatkan portal Azure, menu aplikasi logika Konsumsi, halaman Otorisasi, dan tombol yang dipilih untuk menambahkan kebijakan.

  3. 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:

    Cuplikan layar yang memperlihatkan portal Azure, halaman Otorisasi aplikasi logika Konsumsi, dan informasi untuk kebijakan otorisasi.

    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 dengan https://sts.windows.net/ atau https://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:

    Cuplikan layar yang memperlihatkan portal Azure, halaman Otorisasi aplikasi logika Konsumsi, dan informasi untuk kebijakan bukti kepemilikan.

  4. 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": "72f988bf-86f1-41af-91ab-2d7cd011db47".

  5. Untuk menambahkan kebijakan otorisasi lain, pilih Tambahkan kebijakan. Ulangi langkah-langkah sebelumnya untuk menyiapkan kebijakan.

  6. Jika sudah selesai, pilih Simpan.

  7. 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 ini contoh pemicu Permintaan:

"triggers": {
   "manual": {
      "inputs": {
         "schema": {}
      },
      "kind": "Http",
      "type": "Request",
      "operationOptions": "IncludeAuthorizationHeadersInOutputs"
   }
}

Untuk informasi selengkapnya, tinjau topik berikut ini:

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:

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 REST API Logic Apps: Pemicu Alur Kerja - Jalankan permintaan 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 REST API Azure Logic Apps: Alur Kerja - Operasi Buat Atau Perbarui.

Alur kerja untuk konsumsi

  1. Di portal Azure, buka aplikasi logika Konsumsi Anda di perancang alur kerja.

  2. Pada menu aplikasi logika, di bawah Pengaturan, pilih Pengaturan alur kerja.

  3. 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

  4. 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

  1. Di portal Microsoft Azure, buka sumber daya aplikasi logika Anda.

  2. Pada menu aplikasi logika, di bawah Pengaturan, pilih Jaringan.

  3. Di bagian Lalu Lintas Masuk, pilih Pembatasan akses.

  4. Buat satu atau beberapa aturan untuk Mengizinkan atau Menolak 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).

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

      1. Berdasarkan apakah Anda menambahkan pemicu atau tindakan API Management, ikuti langkah-langkah berikut:

        • Memicu:

          1. Pada perancang alur kerja, pilih Tambahkan pemicu.

          2. Setelah panel Tambahkan pemicu terbuka, di kotak pencarian, masukkan API Management.

          3. Dari daftar hasil pemicu, pilih Pilih Pemicu Azure API Management.

        • Tindakan:

          1. Pada perancang alur kerja, pilih tanda plus (+) tempat Anda ingin menambahkan tindakan.

          2. Setelah panel Tambahkan tindakan terbuka, di kotak pencarian, masukkan API Management.

          3. Dari daftar hasil tindakan, pilih Pilih tindakan Azure API Management.

        Contoh berikut menunjukkan menemukan pemicu Azure API Management:

        Cuplikan layar memperlihatkan portal Azure, perancang alur kerja Konsumsi, dan menemukan pemicu API Management.

      2. Dari daftar instans layanan API Management, pilih instans layanan API Management yang dibuat sebelumnya.

      3. 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.

      1. Pada perancang alur kerja, pilih tanda plus (+) tempat Anda ingin menambahkan tindakan.

      2. Setelah panel Tambahkan tindakan terbuka, di kotak pencarian, masukkan API Management.

      3. Dari daftar hasil tindakan, pilih Panggil API Api Management Azure.

        Cuplikan layar memperlihatkan portal Azure, perancang alur kerja Standar, dan tindakan Azure API Management.

      4. Dari daftar instans layanan API Management, pilih instans layanan API Management yang dibuat sebelumnya.

      5. Dari daftar operasi API, pilih operasi API untuk dipanggil, lalu pilih Buat Baru.

        Cuplikan layar memperlihatkan portal Azure, perancang alur kerja Standar, dan API yang dipilih untuk dipanggil.

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 Tambahkan parameter baru, dan pilih Autentikasi.

Penting

Untuk melindungi informasi sensitif yang ditangani aplikasi logika Anda, gunakan parameter aman dan enkode data seperlunya. Untuk informasi selengkapnya tentang menggunakan dan mengamankan parameter, tinjau Akses ke input parameter.

Autentikasi dasar

Jika opsi Dasar tersedia, 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": {}
}

Mengautentikasi sertifikat klien

Jika opsi Sertifikat Klien tersedia, 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:

  1. Hapus instalan semua instans OpenSSL.
  2. Instal OpenSSL versi 1.1.1t.
  3. Resign sertifikat Anda menggunakan pembaruan baru.
  4. 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:

Platform identitas Microsoft

Pada pemicu Permintaan, Anda dapat menggunakan platform identitas Microsoft, untuk mengautentikasi panggilan masuk setelah menyiapkan kebijakan otorisasi Microsoft Entra untuk aplikasi logika Anda. Untuk semua pemicu dan tindakan lain yang menyediakan tipe autentikasi OAuth Direktori Aktif untuk Anda pilih, tentukan nilai properti ini:

Properti (desainer) Properti (JSON) Wajib Nilai Deskripsi
Autentikasi type Ya Active Directory OAuth
atau
ActiveDirectoryOAuth		 Jenis autentikasi untuk digunakan. Azure Logic Apps saat ini mengikuti protokol OAuth 2.0.
Otoritas authority No <URL-untuk-penerbit-token-otorisasi> URL untuk otoritas yang menyediakan token 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 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.

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.

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.

  1. 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.

  2. Sebelum fungsi Azure dapat menggunakan identitas terkelola, pertama aktifkan autentikasi untuk fungsi Azure terlebih dahul.

  3. 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
    atau
    ManagedServiceIdentity    		 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, seperti https://fabrikamstorageaccount.blob.core.windows.net untuk akun penyimpanan tertentu.

    Catatan: Properti Pemirsa mungkin disembunyikan di beberapa pemicu atau tindakan. Untuk membuat properti ini terlihat, di pemicu atau tindakan, buka daftar Tambahkan parameter baru, 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 sebagai ManagedServiceIdentity 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.

Untuk informasi selengkapnya tentang isolasi, lihat dokumentasi berikut ini:

Langkah berikutnya