Azure Logic Apps'te iş akışları için güvenli erişim ve veri

Azure Logic Apps, bekleyen verileri depolamak ve otomatik olarak şifrelemek için Azure Depolama'ya dayanır. Bu şifreleme, verilerinizi korur, kurumunuzun güvenlik ve uyumluluk gereksinimlerini karşılamanıza yardımcı olur. Varsayılan olarak Azure Depolama, verilerinizi şifrelemek için Microsoft tarafından yönetilen anahtarları kullanır. Daha fazla bilgi için bkz. Bekleyen veriler için Azure Depolama şifrelemesi.

Azure Logic Apps’te erişimi daha fazla denetlemek ve hassas verileri korumak için aşağıda belirtilen alanların güvenlik düzeyini artırabilirsiniz:

• Mantıksal uygulama işlemlerine erişim
• Çalıştırma geçmişi girişlerine ve çıkışlarına erişim
• Parametre girişlerine erişim
• Kimlik doğrulamasını destekleyen tetikleyiciler ve eylemler için kimlik doğrulama türleri
• İstek tabanlı tetikleyicilere gelen çağrılara erişim
• Diğer hizmetlere ve sistemlere giden çağrılar için erişim
• Belirli bağlayıcılar için bağlantı oluşturmayı engelleme
• Mantıksal uygulamalar için yalıtım kılavuzu
• Azure Logic Apps için Azure Güvenlik Temeli

Azure'da güvenlik hakkında daha fazla bilgi için şu konuları gözden geçirin:

• Azure'da şifrelemeye genel bakış
• Azure Bekleyen Verileri Şifreleme
• Microsoft bulut güvenliği karşılaştırması

Mantıksal uygulama işlemlerine erişim

Yalnızca Tüketim mantıksal uygulamaları için, mantıksal uygulamaları ve bunların bağlantılarını oluşturabilmeniz veya yönetebilmeniz için önce, Azure rol tabanlı erişim denetimi (Azure RBAC) kullanılarak roller aracılığıyla sağlanan belirli izinlere ihtiyacınız vardır. Ayrıca, yalnızca belirli kullanıcıların veya grupların mantıksal uygulamaları yönetme, düzenleme ve görüntüleme gibi belirli görevleri çalıştırabilmesi için izinleri ayarlayabilirsiniz. İzinlerini denetlemek için, Azure aboneliğinize erişimi olan üyelere yerleşik veya özelleştirilmiş roller atayabilirsiniz. Azure Logic Apps, Tüketim veya Standart mantıksal uygulama iş akışına bağlı olarak aşağıdaki belirli rollere sahiptir:

Tüketim iş akışları

Örneğin, oluşturmadığınız bir mantıksal uygulama iş akışıyla çalışmanız ve bu mantıksal uygulama iş akışı tarafından kullanılan bağlantıların kimliğini doğrulamanız gerekir. Azure aboneliğiniz, bu mantıksal uygulama kaynağını içeren kaynak grubu için Katkıda Bulunan izinleri gerektirir. Mantıksal uygulama kaynağı oluşturursanız, otomatik olarak Katkıda Bulunan erişiminiz olur.

Başkalarının mantıksal uygulama iş akışınızı değiştirmesini veya silmesini önlemek için Azure Kaynak Kilidi'ni kullanabilirsiniz. Bu özellik, başkalarının üretim kaynaklarını değiştirmesini veya silmesini engeller. Bağlantı güvenliği hakkında daha fazla bilgi için Bkz . Azure Logic Apps'te bağlantı yapılandırması ve Bağlantı güvenliği ve şifreleme.

Standart iş akışları

Çalıştırma geçmişi verilerine erişim

Mantıksal uygulama çalıştırması sırasında aktarım sırasında tüm veriler Aktarım Katmanı Güvenliği (TLS) ve bekleme sırasında şifrelenir. Mantıksal uygulamanızın çalışması tamamlandığında, her eylemin durumu, süresi, girişleri ve çıkışlarıyla birlikte çalışan adımlar da dahil olmak üzere bu çalıştırmanın geçmişini görüntüleyebilirsiniz. Bu zengin ayrıntı, mantıksal uygulamanızın nasıl çalıştığına ve ortaya çıkan sorunları gidermeye nereden başlayacağınıza ilişkin içgörü sağlar.

Mantıksal uygulamanızın çalıştırma geçmişini görüntülediğinizde, Azure Logic Apps erişiminizin kimliğini doğrular ve ardından her çalıştırma için istek ve yanıtlara yönelik giriş ve çıkışlara bağlantılar sağlar. Ancak, parolaları, gizli dizileri, anahtarları veya diğer hassas bilgileri işleyen eylemler için, başkalarının bu verileri görüntülemesini ve bunlara erişmesini engellemek istersiniz. Örneğin, mantıksal uygulamanız bir HTTP eyleminin kimliğini doğrularken kullanmak üzere Azure Key Vault'tan gizli dizi alırsa, bu gizli diziyi görünümden gizlemek istersiniz.

Mantıksal uygulamanızın çalıştırma geçmişindeki giriş ve çıkışlara erişimi denetlemek için şu seçeneklere sahipsiniz:

• ERIŞIMI IP adresi aralığına göre kısıtlayın.

  Bu seçenek, belirli bir IP adresi aralığından gelen isteklere göre çalıştırma geçmişine erişimin güvenliğini sağlamanıza yardımcı olur.

• Gizlemeyi kullanarak çalışma geçmişindeki verilerin güvenliğini sağlayın.

  Birçok tetikleyicide ve eylemde, bir mantıksal uygulamanın çalıştırma geçmişindeki girişlerin, çıkışların veya her ikisinin güvenliğini sağlayabilirsiniz.

IP adresi aralığına göre erişimi kısıtlama

Yalnızca belirli IP adresi aralıklarından gelen isteklerin bu verileri görüntüleyebilmesi için mantıksal uygulama iş akışlarınızın çalıştırma geçmişindeki giriş ve çıkışlara erişimi sınırlayabilirsiniz.

Örneğin, girişlere ve çıkışlara herkesin erişmesini engellemek için gibi 0.0.0.0-0.0.0.0bir IP adresi aralığı belirtin. Mantıksal uygulama iş akışlarınızdaki verilere "tam zamanında" erişim olanağı sağlayan bu kısıtlamayı yalnızca yönetici izinlerine sahip bir kişi kaldırabilir. Geçerli bir IP aralığı şu biçimleri kullanır: x.x.x.x/x veya x.x.x.x.x.x

İzin verilen IP aralıklarını belirtmek için, Azure portalında veya Azure Resource Manager şablonunuzda Tüketim veya Standart mantıksal uygulamanız için şu adımları izleyin:

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {<workflow-definition>},
            "parameters": {},
            "accessControl": {
               "contents": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     },
                     {
                        "addressRange": "2001:0db8::/64"
                     }
                  ]
               }
            }
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

Gizleme kullanarak çalışma geçmişindeki verilerin güvenliğini sağlama

Birçok tetikleyici ve eylem, bir mantıksal uygulamanın çalıştırma geçmişinden girişleri, çıkışları veya her ikisini de güvenli bir şekilde güvenlik altına almak için ayarlara sahiptir. Tüm yönetilen bağlayıcılar ve özel bağlayıcılar bu seçenekleri destekler. Ancak, aşağıdaki yerleşik işlemler bu seçenekleri desteklemez:

Girişleri ve çıkışları güvenli hale getirmek için dikkat edilmesi gerekenler

Bu verilerin güvenliğini sağlamaya yardımcı olmak için bu ayarları kullanmadan önce şu noktaları gözden geçirin:

• Bir tetikleyici veya eylemdeki girişleri veya çıkışları gizlediğinizde, Azure Logic Apps güvenli verileri Azure Log Analytics'e göndermez. Ayrıca, izleme için bu tetikleyiciye veya eyleme izlenen özellikler ekleyemezsiniz.

• İş akışı geçmişini işlemeye yönelik Azure Logic Apps API'sinde güvenli çıkışlar döndürülmüyor.

• Girişleri gizleyen veya çıkışları açıkça gizleyen bir eylemden gelen çıkışların güvenliğini sağlamak için, bu eylemde Güvenli Çıkışlar'ı el ile açın.

• Çalıştırma geçmişinin bu verileri gizlemesini beklediğiniz aşağı akış eylemlerinde Güvenli Girişler veya Güvenli Çıkışlar'ı açtığınızdan emin olun.

  Güvenli Çıkışlar ayarı

  Bir tetikleyicide veya eylemde Güvenli Çıkışlar'ı el ile açtığınızda, Azure Logic Apps bu çıkışları çalıştırma geçmişinde gizler. Aşağı akış eylemi bu güvenli çıkışları açıkça giriş olarak kullanıyorsa, Azure Logic Apps bu eylemin girişlerini çalıştırma geçmişinde gizler, ancak eylemin Güvenli Girişler ayarını etkinleştirmez.

  

  Oluştur, JSON Ayrıştır ve Yanıtla eylemleri yalnızca Güvenli Girişler ayarına sahiptir. Bu ayar açıldığında bu eylemlerin çıkışlarını da gizler. Bu eylemler yukarı akış güvenli çıkışlarını açıkça giriş olarak kullanıyorsa, Azure Logic Apps bu eylemlerin girişlerini ve çıkışlarını gizler, ancak bu eylemlerin Güvenli Girişler ayarını etkinleştirmez. Aşağı akış eylemi oluşturma, JSON Ayrıştırma veya Yanıt eylemlerinden gelen gizli çıkışları açıkça giriş olarak kullanıyorsa, Azure Logic Apps bu aşağı akış eyleminin girişlerini veya çıkışlarını gizlemez.

  

  Güvenli Girişler ayarı

  Bir tetikleyicide veya eylemde Güvenli Girişler'i el ile açtığınızda, Azure Logic Apps bu girişleri çalıştırma geçmişinde gizler. Aşağı akış eylemi bu tetikleyiciden veya eylemden gelen görünür çıkışları açıkça giriş olarak kullanıyorsa, Azure Logic Apps bu aşağı akış eyleminin girişlerini çalıştırma geçmişinde gizler, ancak bu eylemde Güvenli Girişleri etkinleştirmez ve bu eylemin çıkışlarını gizlemez.

  

  Oluştur, JSON Ayrıştır ve Yanıtla eylemleri tetikleyiciden veya güvenli girişlere sahip eylemden gelen görünür çıkışları açıkça kullanıyorsa, Azure Logic Apps bu eylemlerin girişlerini ve çıkışlarını gizler, ancak bu eylemin Güvenli Girişler ayarını etkinleştirmez. Aşağı akış eylemi oluşturma, JSON Ayrıştırma veya Yanıt eylemlerinden gelen gizli çıkışları açıkça giriş olarak kullanıyorsa, Azure Logic Apps bu aşağı akış eyleminin girişlerini veya çıkışlarını gizlemez.

  

Tasarımcıda girişlerin ve çıkışların güvenliğini sağlama

1. Azure portalında mantıksal uygulama iş akışınızı tasarımcıda açın.

2. Tasarımcıda, hassas verilerin güvenliğini sağlamak istediğiniz tetikleyiciyi veya eylemi seçin.

3. Açılan bilgi bölmesinde Ayarlar'ı seçin ve Güvenlik'i genişletin.

   

4. Güvenli Girişler, Güvenli Çıkışlar veya her ikisini de açın.

   

   Tetikleyici veya eylem artık başlık çubuğunda bir kilit simgesi gösterir. Önceki eylemlerden alınan güvenli çıkışları temsil eden tüm belirteçler kilit simgelerini de gösterir. Örneğin, sonraki bir eylemde, dinamik içerik listesinden güvenli bir çıkış için bir belirteç seçtikten sonra, bu belirteç bir kilit simgesi gösterir.

   

5. İş akışı çalıştırıldıktan sonra bu çalıştırmanın geçmişini görüntüleyebilirsiniz.

   1. Tüketim mantığı uygulaması menüsünden veya Standart iş akışı menüsünden Genel Bakış'ı seçin.

   2. Çalıştırma geçmişi'nin altında, görüntülemek istediğiniz çalıştırmayı seçin.

   3. İş akışı çalıştırma geçmişi bölmesinde gözden geçirmek istediğiniz eylemleri seçin.

      Hem girişleri hem de çıkışları gizlemeyi seçtiyseniz, bu değerler artık gizli görünür.

      

Kod görünümünde girişlerin ve çıkışların güvenliğini sağlama

Temel tetikleyicide veya eylem tanımında, diziyi runtimeConfiguration.secureData.properties şu değerlerden biriyle veya her ikisiyle de ekleyin veya güncelleştirin:

• "inputs": Çalıştırma geçmişindeki girişlerin güvenliğini sağlar.
• "outputs": Çalıştırma geçmişindeki çıkışların güvenliğini sağlar.

"<trigger-or-action-name>": {
   "type": "<trigger-or-action-type>",
   "inputs": {
      <trigger-or-action-inputs>
   },
   "runtimeConfiguration": {
      "secureData": {
         "properties": [
            "inputs",
            "outputs"
         ]
      }
   },
   <other-attributes>
}

Parametre girişlerine erişim

Farklı ortamlar arasında dağıtım yaparsanız, iş akışı tanımınızda bu ortamlara göre değişen değerleri parametreleştirmeyi göz önünde bulundurun. Bu şekilde, mantıksal uygulamanızı dağıtmak, güvenli parametreler tanımlayarak hassas verileri korumak ve bir parametre dosyası kullanarak bu verileri şablonun parametreleri aracılığıyla ayrı girişler olarak geçirmek için bir Azure Resource Manager şablonu kullanarak sabit kodlanmış verilerden kaçınabilirsiniz.

Örneğin, Microsoft Entra Id ile OAuth ile HTTP eylemlerinin kimliğini doğrularsanız, kimlik doğrulaması için kullanılan istemci kimliğini ve istemci gizli dizisini kabul eden parametreleri tanımlayabilir ve gizleyebilirsiniz. Mantıksal uygulama iş akışınızda bu parametreleri tanımlamak için mantıksal uygulamanızın parameters iş akışı tanımındaki ve dağıtım için Resource Manager şablonundaki bölümü kullanın. Mantıksal uygulamanızı düzenlerken veya çalıştırma geçmişini görüntülerken gösterilmesini istemediğiniz parametre değerlerinin güvenliğini sağlamaya yardımcı olmak için veya secureobject türünü kullanarak securestring parametreleri tanımlayın ve gerektiğinde kodlamayı kullanın. Bu türdeki parametreler kaynak tanımıyla döndürülmüyor ve dağıtımdan sonra kaynağı görüntülerken erişilebilir değil. Çalışma zamanı sırasında bu parametre değerlerine erişmek için iş akışı tanımınızın içindeki ifadeyi @parameters('<parameter-name>') kullanın. Bu ifade yalnızca çalışma zamanında değerlendirilir ve İş Akışı Tanım Dili tarafından açıklanır.

Daha fazla bilgi için bu konudaki şu bölümleri gözden geçirin:

• İş akışı tanımlarında parametrelerin güvenliğini sağlama
• Gizleme kullanarak çalışma geçmişindeki verilerin güvenliğini sağlama

Resource Manager şablonlarını kullanarak mantıksal uygulamalar için dağıtımı otomatikleştirirseniz ve secureobject türlerini kullanarak securestring dağıtımda değerlendirilen güvenli şablon parametreleri tanımlayabilirsiniz. Şablon parametrelerini tanımlamak için, iş akışı tanımınızın parameters bölümünden ayrı ve farklı olan şablonunuzun en üst düzey parameters bölümünü kullanın. Şablon parametrelerinin değerlerini sağlamak için ayrı bir parametre dosyası kullanın.

Örneğin, gizli diziler kullanıyorsanız, dağıtım sırasında Bu gizli dizileri Azure Key Vault'tan alan güvenli şablon parametreleri tanımlayabilir ve kullanabilirsiniz. Ardından parametre dosyanızda anahtar kasasına ve gizli diziye başvurabilirsiniz. Daha fazla bilgi için şu konuları gözden geçirin:

• Azure Key Vault kullanarak dağıtımda hassas değerleri geçirme
• Bu konunun devamında Azure Resource Manager şablonlarında parametrelerin güvenliğini sağlama

İş akışı tanımlarında parametrelerin güvenliğini sağlama (Tüketim iş akışı)

Mantıksal uygulamanızın iş akışı tanımındaki hassas bilgileri korumak için güvenli parametreler kullanın, böylece mantıksal uygulama iş akışınızı kaydettikten sonra bu bilgiler görünmez. Örneğin, bir HTTP eyleminizin kullanıcı adı ve parola kullanan temel kimlik doğrulaması gerektirdiğini varsayalım. İş akışı tanımındaparameters, bölümü ve parametrelerini türünü kullanarak securestring tanımlar basicAuthPasswordParam basicAuthUsernameParam. Eylem tanımı daha sonra bölümünde bu parametrelere başvurur 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": {}
}

Azure Resource Manager şablonlarında parametrelerin güvenliğini sağlama (Tüketim iş akışı)

Mantıksal uygulama kaynağı ve iş akışı için Resource Manager şablonunda birden çok parameters bölüm vardır. Parolaları, anahtarları, gizli dizileri ve diğer hassas bilgileri korumak için veya secureobject türünü kullanarak securestring şablon düzeyinde ve iş akışı tanımı düzeyinde güvenli parametreler tanımlayın. Ardından bu değerleri Azure Key Vault'ta depolayabilir ve anahtar kasasına ve gizli diziye başvurmak için parametre dosyasını kullanabilirsiniz. Ardından şablonunuz bu bilgileri dağıtımda alır. Daha fazla bilgi için Bkz . Azure Key Vault kullanarak dağıtımda hassas değerleri geçirme.

Bu liste, bu parameters bölümler hakkında daha fazla bilgi içerir:

• Şablonun en üst düzeyinde bir parameters bölüm, şablonun dağıtımda kullandığı değerlerin parametrelerini tanımlar. Örneğin, bu değerler belirli bir dağıtım ortamı için bağlantı dizesi içerebilir. Daha sonra bu değerleri ayrı bir parametre dosyasında depolayabilirsiniz ve bu da bu değerleri değiştirmeyi kolaylaştırır.

• Mantıksal uygulamanızın kaynak tanımının içinde, ancak iş akışı tanımınızın dışında bir parameters bölüm, iş akışı tanımınızın parametrelerinin değerlerini belirtir. Bu bölümde, şablonunuzun parametrelerine başvuran şablon ifadelerini kullanarak bu değerleri atayabilirsiniz. Bu ifadeler dağıtımda değerlendirilir.

• İş akışı tanımınızın içinde bir parameters bölüm, mantıksal uygulama iş akışınızın çalışma zamanında kullandığı parametreleri tanımlar. Ardından, çalışma zamanında değerlendirilen iş akışı tanımı ifadelerini kullanarak mantıksal uygulamanızın iş akışı içinde bu parametrelere başvurabilirsiniz.

Türünü kullanan securestring birden çok güvenli parametre tanımına sahip bu örnek şablon:

{
   "$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": {}
}

Kimlik doğrulamasını destekleyen bağlayıcılar için kimlik doğrulama türleri

Aşağıdaki tablo, bir kimlik doğrulama türü seçebileceğiniz bağlayıcı işlemlerinde kullanılabilen kimlik doğrulama türlerini tanımlar:

İstek tabanlı tetikleyicilere gelen çağrılara erişim

Bir mantıksal uygulamanın İstek tetikleyicisi veya HTTP Web kancası tetikleyicisi gibi istek tabanlı bir tetikleyici aracılığıyla aldığı gelen çağrılar şifrelemeyi destekler ve daha önce Güvenli Yuva Katmanı (SSL) olarak bilinen Aktarım Katmanı Güvenliği (TLS) 1.2 ile en az güvenli hale getirilir. Azure Logic Apps, bir İstek tetikleyicisine gelen çağrı veya HTTP Web kancası tetikleyicisine veya eylemine geri çağırma alırken bu sürümü zorlar.

Gelen çağrılar için aşağıdaki şifreleme paketlerini kullanın:

• 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

Aşağıdaki liste, yalnızca yetkili istemcilerin iş akışınızı çağırabilmesi için mantıksal uygulama iş akışınıza gelen çağrılar alan tetikleyicilere erişimi sınırlayabileceğiniz yolları içerir:

• Microsoft Entra Id ile OAuth'u etkinleştirme
• Paylaşılan erişim imzası (SAS) anahtarları veya belirteçleri oluşturma
• Paylaşılan erişim imzası (SAS) kimlik doğrulamayı devre dışı bırakma
• Gelen IP adreslerini kısıtlama
• Azure API Management ile mantıksal uygulamanızı kullanıma sunma

Microsoft Entra Id ile OAuth 2.0'ı etkinleştirme

İstek tabanlı tetikleyiciyle başlayan bir Tüketim iş akışında, Microsoft Entra Id ile OAuth 2.0'ı etkinleştirerek bu tetikleyici tarafından oluşturulan uç noktaya gönderilen gelen çağrıların kimliğini doğrulayabilir ve bu çağrıları yetkilendirirsiniz. Bu kimlik doğrulamasını ayarlamak için mantıksal uygulama kaynak düzeyinde bir yetkilendirme ilkesi tanımlayın veya ekleyin. Bu şekilde, gelen çağrılar yetkilendirme için OAuth erişim belirteçlerini kullanır.

Mantıksal uygulama iş akışınız OAuth erişim belirteci içeren bir gelen istek aldığında, Azure Logic Apps belirtecin taleplerini her yetkilendirme ilkesi tarafından belirtilen taleplerle karşılaştırır. Belirtecin talepleri ile en az bir ilkedeki tüm talepler arasında bir eşleşme varsa, gelen istek için yetkilendirme başarılı olur. Belirteç, yetkilendirme ilkesi tarafından belirtilen sayıdan daha fazla talep içerebilir.

İstek tetikleyicisiyle başlayan standart bir iş akışında (web kancası tetikleyicisi değil), yönetilen kimlik kullanarak İstek tetikleyicisi tarafından oluşturulan uç noktaya gönderilen gelen çağrıların kimliğini doğrulamak için Azure İşlevleri sağlamasını kullanabilirsiniz. Bu sağlama "Kolay Kimlik Doğrulaması" olarak da bilinir. Daha fazla bilgi için bkz . Easy Auth ile Standart mantıksal uygulamalarda iş akışlarını tetikleme.

Microsoft Entra Id ile OAuth 2.0'ı etkinleştirmeden önce dikkat edilmesi gerekenler

• En iyi güvenlik için Microsoft, mümkün olduğunda kimlik doğrulaması için yönetilen kimliklerle Microsoft Entra Id kullanılmasını önerir. Bu seçenek, kimlik bilgileri sağlamak zorunda kalmadan üstün güvenlik sağlar. Azure bu kimliği yönetir ve bu hassas bilgileri yönetmek zorunda kalmamak için kimlik doğrulama bilgilerinin güvenli kalmasına yardımcı olur. Azure Logic Apps için yönetilen kimlik ayarlamak için bkz . Azure Logic Apps'te yönetilen kimliklerle Azure kaynaklarına erişim ve bağlantıların kimliğini doğrulama.

• Tüketim iş akışlarında, istek tabanlı tetikleyici için uç nokta URL'sine gelen çağrılar, Microsoft Entra Kimliği veya Paylaşılan Erişim İmzası (SAS) ile OAuth 2.0 olmak üzere yalnızca bir yetkilendirme şeması kullanabilir. Bir düzenin kullanılması diğer düzeni devre dışı bırakmasa da, her iki düzeni de aynı anda kullanırsanız, hizmet hangi düzenin seçileceğini bilmediğinden Azure Logic Apps bir hata oluşturur. Tüketim iş akışınız İstek tetikleyicisiyle başlıyorsa SAS kimlik doğrulamasını devre dışı bırakabilir ve yetkilendirmeyi Yalnızca Microsoft Entra Id ile OAuth 2.0 kullanacak şekilde kısıtlayabilirsiniz. Standart iş akışları için SAS'yi devre dışı bırakmadan diğer kimlik doğrulama türlerini kullanabilirsiniz.

• Azure Logic Apps, Microsoft Entra Id OAuth erişim belirteçleri için taşıyıcı türünü veya sahiplik kanıtı türünü (yalnızca tüketim mantıksal uygulaması) yetkilendirme düzenlerini destekler. Ancak, Authorization erişim belirtecinin üst bilgisi türü veya PoP türünü belirtmelidirBearer. PoP belirtecini alma ve kullanma hakkında daha fazla bilgi için bkz . Sahiplik Kanıtı (PoP) belirteci alma.

• Tüketim mantıksal uygulaması kaynağınız en fazla yetkilendirme ilkesi sayısıyla sınırlıdır. Her yetkilendirme ilkesinin en fazla talep sayısı da vardır. Daha fazla bilgi için bkz . Azure Logic Apps için sınırlar ve yapılandırma.

• Yetkilendirme ilkesi, Microsoft Entra Id için veren olarak veya https://login.microsoftonline.com/ (OAuth V2) ile https://sts.windows.net/ başlayan bir değere sahip olan En azından Veren talebi içermelidir.

  Örneğin, mantıksal uygulama kaynağınızın hedef kitle ve Veren olmak üzere iki talep türü gerektiren bir yetkilendirme ilkesi olduğunu varsayalım. Kodu çözülen erişim belirtecinin bu örnek yük bölümü, hedef kitle değeri ve iss Veren değeri olan aud her iki talep türünü de içerir:

  {
      "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"
  }
  

bir istek uç noktasını çağırmak için tek seçenek olarak Microsoft Entra Id ile OAuth 2.0'ı etkinleştirin (Yalnızca tüketim)

İstek tabanlı uç noktalar için yetkilendirmeyi yalnızca Microsoft Entra Id ile OAuth 2.0 kullanacak şekilde kısıtlayabilirsiniz. Paylaşılan erişim imzası (SAS) kimlik doğrulamayı da devre dışı bıraksanız bile bu seçenek çalışır.

1. Tüketim iş akışınız için İstek veya HTTP web kancası tetikleyicisi çıkışlarına 'Yetkilendirme' üst bilgisini ekleme adımlarını izleyerek OAuth erişim belirtecini denetleme özelliğiyle İstek tetikleyicinizi veya HTTP Web Kancası tetikleyicinizi ayarlayın.

   Not

   Bu adım, üst bilginin iş akışının çalıştırma geçmişinde ve tetikleyicinin çıkışlarında görünür olmasını sağlar Authorization .

2. Azure portalında Tüketim iş akışınızı tasarımcıda açın.

3. Tasarımcıda tetikleyiciyi seçin. Açılan bilgi bölmesinde Ayarlar'ı seçin.

4. Genel>Tetikleyici koşulları'nın altında Ekle'yi seçin. Tetikleyici koşulu kutusuna, kullanmak istediğiniz belirteç türüne göre aşağıdaki ifadelerden birini girin:

   @startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')

   -veya-

   @startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')

Doğru yetkilendirme olmadan tetikleyici uç noktasını çağırırsanız, çalıştırma geçmişi tetikleyiciyi tetikleyici koşulunun başarısız olduğunu belirten bir ileti olmadan gösterir Skipped .

SahipLik Kanıtı (PoP) belirteci alma

Microsoft Kimlik Doğrulama Kitaplığı (MSAL) kitaplıkları, kullanmanız için PoP belirteçleri sağlar. Çağırmak istediğiniz Tüketim mantıksal uygulaması iş akışı bir PoP belirteci gerektiriyorsa, MSAL kitaplıklarını kullanarak bu belirteci alabilirsiniz. Aşağıdaki örneklerde PoP belirteçlerinin nasıl alınıyor olduğu gösterilmektedir:

• Korumalı bir Web API'sini kendi kimliğiyle çağıran bir .NET Core daemon konsol uygulaması

• PoP (Sahiplik Kanıtı) olarak da bilinen SignedHttpRequest

PoP belirtecini Tüketim mantıksal uygulaması iş akışınızla kullanmak için Microsoft Entra Id ile OAuth'u ayarlama adımlarını izleyin.

Tüketim mantıksal uygulama kaynağınız için Microsoft Entra Id ile OAuth'u etkinleştirme

Tüketim mantığı uygulamanıza yetkilendirme ilkesi eklemek için Azure portalı veya Azure Resource Manager şablonuna yönelik adımları izleyin:

"resources": [
   {
      // Start logic app resource definition
      "properties": {
         "state": "<Enabled-or-Disabled>",
         "definition": {<workflow-definition>},
         "parameters": {<workflow-definition-parameter-values>},
         "accessControl": {
            "triggers": {
               "openAuthenticationPolicies": {
                  "policies": {
                     "<policy-name>": {
                        "type": "AAD",
                        "claims": [
                           {
                              "name": "<claim-name>",
                              "value": "<claim-value>"
                           }
                        ]
                     }
                  }
               }
            },
         },
      },
      "name": "[parameters('LogicAppName')]",
      "type": "Microsoft.Logic/workflows",
      "location": "[parameters('LogicAppLocation')]",
      "apiVersion": "2016-06-01",
      "dependsOn": [
      ]
   }
   // End logic app resource definition
],

İstek veya HTTP web kancası tetikleyici çıkışlarına 'Authorization' üst bilgisi ekleme

İstek tabanlı tetikleyicilere erişim için gelen çağrıları yetkilendirmek için Microsoft Entra Id ile OAuth'u etkinleştiren mantıksal uygulamalar için İstek tetikleyicisini veya HTTP Web kancası tetikleyici çıkışlarını OAuth erişim belirtecinden üst bilgiyi içerecek Authorization şekilde etkinleştirebilirsiniz. Tetikleyicinin temel JSON tanımında operationOptions özelliğini ekleyin ve olarak IncludeAuthorizationHeadersInOutputsayarlayın. İstek tetikleyicisi için bir örnek aşağıda verilmişti:

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

Daha fazla bilgi için şu konuları gözden geçirin:

• Tetikleyici ve eylem türleri için şema başvurusu - İstek tetikleyicisi
• Tetikleyici ve eylem türleri için şema başvurusu - HTTP Web Kancası tetikleyicisi
• Tetikleyici ve eylem türleri için şema başvurusu - İşlem seçenekleri

Paylaşılan erişim imzası (SAS) anahtarı veya belirteci oluşturma

bir iş akışı istek tabanlı tetikleyiciyle başladığında ve bu iş akışını ilk kez kaydettiğinizde, Azure Logic Apps bu tetikleyicide çağrılabilir bir uç nokta oluşturur. Bu uç nokta, iş akışını başlatmak için gelen çağrıları veya istekleri alabilen bir URL'ye sahiptir. URL, depolama hizmetlerine izinler veren bir anahtar veya belirteç olan Paylaşılan Erişim İmzası (SAS) içerir. Bu uç nokta URL'si aşağıdaki biçimi kullanır:

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

Örneğin, bu URL'yi bir İstek tetikleyicisinde görüntülemek için tetikleyicinin HTTP URL özelliğini bulun:

URL'nin tamamı aşağıdaki örneğe benzer:

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

URL'deki SAS,aşağıdaki tabloda açıklanan sorgu parametrelerine sahiptir:

İstek tabanlı bir tetikleyicide uç noktaya gelen çağrılar, SAS veya Microsoft Entra Id ile OAuth 2.0 olmak üzere yalnızca bir yetkilendirme şeması kullanabilir. Bir düzenin kullanılması diğerini devre dışı bırakmasa da, her iki düzeni de aynı anda kullanırsanız, hizmet hangi düzenin seçileceğini bilmediğinden Azure Logic Apps bir hata oluşturur.

İstek tetikleyicisiyle başlayan bir Tüketim iş akışınız varsa SAS kimlik doğrulamasını devre dışı bırakabilirsiniz. Bu seçenek, yetkilendirmeyi Microsoft Entra Id ile yalnızca OAuth 2.0 kullanacak şekilde kısıtlasanız bile çalışır. Standart iş akışları için SAS'yi devre dışı bırakmadan diğer kimlik doğrulama türlerini kullanabilirsiniz.

SAS anahtarı kullanırken güvenlik hakkında daha fazla bilgi için bu kılavuzdaki aşağıdaki bölümlere bakın:

• Erişim anahtarlarını yeniden oluşturma
• Süresi dolan geri çağırma URL'leri oluşturma
• Birincil veya ikincil anahtarla URL'ler oluşturma

Paylaşılan erişim imzası (SAS) kimlik doğrulamayı devre dışı bırakma (Yalnızca tüketim)

Varsayılan olarak, istek tabanlı tetikleyicide SAS kimlik doğrulaması etkindir. Tetikleyicinin uç nokta URL'si, sorgu parametrelerinden başlayarak bir SAS içerir, sp-<permissions>sv-<SAS-version>sig=<signature>örneğin:

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

Tüketim iş akışınız İstek tetikleyicisiyle başlıyorsa ve Microsoft Entra ID ile OAuth kullanmak istiyorsanız, iş akışınızı çalıştıran hataları ve sorunları önlemek için SAS kimlik doğrulamasını devre dışı bırakabilirsiniz. Ayrıca gizli dizilere bağımlılığı kaldırarak bir güvenlik katmanı eklersiniz; bu da gizli dizilerin günlüğe kaydedilmesi veya sızdırılması riskini azaltır.

Bu seçenek, istek tabanlı uç noktayı çağırmak için tek seçenek olarak Microsoft Entra Id ile OAuth 2.0'ı da etkinleştirseniz bile çalışır. Standart iş akışları için SAS'yi devre dışı bırakmadan diğer kimlik doğrulama türlerini kullanabilirsiniz.

SAS kimlik doğrulamasını devre dışı bırakdıktan sonra, İstek tetikleyicisinin uç nokta URL'si artık SAS anahtarını içermiyor, örneğin:

https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01

Önkoşullar

Bu görev için REST API çağrıları göndermek için bir araç gerekir, örneğin:

• Visual Studio Market'ten uzantılı Visual Studio Code
• PowerShell Invoke-RestMethod
• Microsoft Edge - Ağ Konsolu aracı
• Bruno
• Curl

SAS etkin veya devre dışı tetikleyicileri denetleme

SAS kimlik doğrulaması devre dışı bırakıldığında tetikleyicinin uç nokta URL'si artık SAS anahtarını içermez. Ayrıca Consumption iş akışı tanımı sasAuthenticationPolicy JSON nesnesini içerir. Bu nesne devre dışı olarak ayarlanmış bir durum özelliğine sahiptir, örneğin:

"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}

SAS'nin etkin veya devre dışı olduğu Tüketim iş akışlarını bulmak için, iş akışı tanımının durum özelliğinin Devre Dışı olarak ayarlandığı sasAuthenticationPolicy nesnesini içerip içermediğini denetleyin.

1. REST API çağrıları gönderen aracınızla, aşağıdaki GET isteğini kullanarak İş Akışları - Alma işlemini çalıştırarak iş akışınız hakkında bilgi alın, örneğin:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. İş Akışları - Alma işleminin çıktısını alın ve durum özelliğinin Devre Dışı olarak ayarlandığı sasAuthenticationPolicy nesnesinin mevcut olup olmadığını denetleyin.

sasAuthenticationPolicy özelliğini iş akışı tanımınıza ekleme

SAS kimlik doğrulamasını devre dışı bırakmak istediğiniz Tüketim iş akışları için şu adımları izleyin:

1. Henüz yapmadıysanız, aşağıdaki GET isteğini kullanarak İş Akışları - Alma işlemini çalıştırarak iş akışınız hakkında bilgi edinin, örneğin:

   GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

2. İş Akışları - Alma işleminden çıktıyı alın ve aşağıdaki öğeleri el ile ekleyin:

   1. nesnesindeproperties, yoksa nesne içeren bir triggers nesne ekleyinaccessControl.

   2. nesnesinetriggers, olarak ayarlanmış Disabledözelliğini içeren state bir sasAuthenticationPolicy nesne ekleyin.

   Bitirdiğinizde, düzenlenen bölüm aşağıdaki örneğe benzer:

   "properties": {
       "accessControl": {
           "triggers": {
               "sasAuthenticationPolicy": {
                   "state": "Disabled"
               }
           }
       }
   }
   

3. İş Akışları - Güncelleştirme işlemini aşağıdaki PATCH isteğini kullanarak çalıştırarak, istek gövdesinde giriş olarak kullandığınız düzenlenmiş çıkışla iş akışınızı güncelleştirmek için başka bir istek gönderin, örneğin:

   PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01

4. Azure portalında tasarımcıda Tüketim iş akışınıza gidin ve İstek tetikleyicisinin URL'sinin artık SAS içermediğini onaylayın.

5. Microsoft Entra Id ile Oauth 2.0'ı etkinleştirmek için mantıksal uygulama kaynak düzeyinde Microsoft Entra Id ile OAuth için bir yetkilendirme ilkesi ekleyin.

   Daha fazla bilgi için bkz . Microsoft Entra Id ile OAuth 2.0'ı etkinleştirme.

Erişim anahtarlarını yeniden oluşturma

Mantıksal uygulama iş akışınıza güvenliği korumak ve erişimi korumak için, güvenlik ilkelerine uymaları veya güvenliği tehlikeye atmaları gerekebileceğinden erişim anahtarlarını düzenli bir zamanlamaya göre yeniden oluşturun. Bu şekilde, verilerinizi ve işlemlerinizi yetkisiz erişime karşı koruyan iş akışınızı yalnızca yetkili isteklerin tetikleyebildiğinden emin olabilirsiniz.

İstediğiniz zaman yeni bir erişim anahtarı oluşturmak için Azure REST API'sini veya Azure portalını kullanın. Daha önce oluşturulan tüm URL'ler veya eski anahtarı kullanan URL'ler geçersiz kılınır ve artık mantıksal uygulama iş akışınızı tetikleme yetkisi yoktur. Yeniden oluşturma işleminden sonra aldığınız URI'ler yeni erişim anahtarıyla imzalı.

1. Azure portalında, yeniden oluşturmak istediğiniz anahtarı kullanan mantıksal uygulama kaynağını açın.

2. Mantıksal uygulama kaynak menüsünde, Ayarlar'ın altında Erişim Anahtarları'nı seçin.

3. Yeniden oluşturmak istediğiniz anahtarı seçin ve işlemi tamamlayın.

Süresi dolan geri çağırma URL'leri oluşturma

İstek tabanlı tetikleyicinin uç nokta URL'sini diğer taraflarla paylaşırsanız, belirli anahtarları kullanan ve son kullanma tarihleri olan geri çağırma URL'leri oluşturabilirsiniz. Bu şekilde anahtarları sorunsuz bir şekilde alabilir veya belirli bir zaman aralığına göre mantıksal uygulamanızı tetikleme erişimini kısıtlayabilirsiniz. URL'nin son kullanma tarihini belirtmek için Azure Logic Apps REST API'sini kullanın, örneğin:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Gövdeye JSON tarih dizesi kullanarak özelliğini ekleyin NotAfter . Bu özellik yalnızca tarih ve saate kadar geçerli olan bir geri çağırma URL'si NotAfter döndürür.

Birincil veya ikincil gizli anahtarla URL'ler oluşturma

İstek tabanlı tetikleyici için geri çağırma URL'leri oluşturur veya listelerken, URL'yi imzalamak için kullanılacak anahtarı belirtebilirsiniz. Belirli bir anahtar tarafından imzalanan bir URL oluşturmak için Azure Logic Apps REST API'sini kullanın, örneğin:

POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01

Gövdeye özelliğini veya Secondaryolarak Primary ekleyinKeyType. Bu özellik, belirtilen güvenlik anahtarı tarafından imzalanan bir URL döndürür.

Azure API Management ile mantıksal uygulama iş akışınızı kullanıma sunma

Daha fazla kimlik doğrulama protokolü ve seçeneği için Azure API Management kullanarak mantıksal uygulama iş akışınızı API olarak kullanıma vermeyi göz önünde bulundurun. Bu hizmet herhangi bir uç nokta için zengin izleme, güvenlik, ilke ve belge özellikleri sağlar. API Management, mantıksal uygulamanız için genel veya özel uç noktayı kullanıma açabilir. Bu uç noktaya erişimi yetkilendirmek için Microsoft Entra Id, istemci sertifikası veya diğer güvenlik standartlarıyla OAuth kullanabilirsiniz. API Management bir istek aldığında, hizmet isteği mantıksal uygulamanıza gönderir ve yol boyunca gerekli dönüştürmeleri veya kısıtlamaları yapar. Yalnızca API Management'ın mantıksal uygulama iş akışınızı çağırmasına izin vermek için mantıksal uygulamanızın gelen IP adreslerini kısıtlayabilirsiniz.

Daha fazla bilgi için, aşağıdaki belgelere bakın:

• API Yönetimi hakkında
• Microsoft Entra Id ile OAuth 2.0 yetkilendirmesini kullanarak Azure API Management'ta bir web API'si arka ucu koruma
• API Management'ta istemci sertifikası kimlik doğrulaması kullanarak API'lerin güvenliğini sağlama
• API Management kimlik doğrulaması ilkeleri

Gelen IP adreslerini kısıtlama

Paylaşılan Erişim İmzası (SAS) ile birlikte mantıksal uygulama iş akışınızı çağırabilecek istemcileri özellikle sınırlamak isteyebilirsiniz. Örneğin, azure API Management kullanarak istek uç noktanızı yönetiyorsanız mantıksal uygulama iş akışınızı yalnızca oluşturduğunuz API Management hizmet örneğinin IP adresinden gelen istekleri kabul etmek üzere kısıtlayabilirsiniz.

Belirttiğiniz IP adreslerinden bağımsız olarak, İş Akışı Tetikleyicileri - Çalıştırma işlemi isteğini veya API Management'ı kullanarak istek tabanlı tetikleyicisi olan bir mantıksal uygulama iş akışını yine de çalıştırabilirsiniz. Ancak bu senaryo hala Azure REST API'sinde kimlik doğrulaması gerektirir. Tüm olaylar Azure Denetim Günlüğü'nde görünür. Erişim denetimi ilkelerini uygun şekilde ayarladığınızdan emin olun.

Mantıksal uygulama iş akışınızın gelen IP adreslerini kısıtlamak için Azure portalı veya Azure Resource Manager şablonunuz için ilgili adımları izleyin. Geçerli bir IP aralığı şu biçimleri kullanır: x.x.x.x/x veya x.x.x.x.x.x

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": []
               },
               "actions": {
                  "allowedCallerIpAddresses": []
               },
               // Optional
               "contents": {
                  "allowedCallerIpAddresses": []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
   "contentVersion": "1.0.0.0",
   "parameters": {},
   "variables": {},
   "resources": [
      {
         "name": "[parameters('LogicAppName')]",
         "type": "Microsoft.Logic/workflows",
         "location": "[parameters('LogicAppLocation')]",
         "tags": {
            "displayName": "LogicApp"
         },
         "apiVersion": "2016-06-01",
         "properties": {
            "definition": {
               <workflow-definition>
            },
            "parameters": {
            },
            "accessControl": {
               "triggers": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               },
               "actions": {
                  "allowedCallerIpAddresses": [
                     {
                        "addressRange": "192.168.12.0/23"
                     }
                  ]
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

{
   "type": "Microsoft.Web/sites/config",
   "apiVersion": "2022-09-01",
   "name": "[concat(parameters('sites_My_Standard_Logic_App_name'), '/web')]",
   "location": "West US",
   "dependsOn": [
      "[resourceId('Microsoft.Web/sites', parameters('sites_My_Standard_Logic_App_name'))]"
   ],
   "tags": {
      "hidden-link: /app-insights-resource-id": "/subscriptions/{subscriptionID}/resourceGroups/Standard-RG/providers/Microsoft.Insights/components/My-Standard-Logic-App"
   },
   "properties": {
      "numberOfWorkers": 1,
      "defaultDocuments": [
         "Default.htm",
         "Default.html",
         "Default.asp",
         "index.htm",
         "index.html",
         "iisstart.htm",
         "default.aspx",
         "index.php"
      ],
      "netFrameworkVersion": "v6.0",
      "requestTracingEnabled": false,
      "remoteDebuggingEnabled": false,
      "httpLoggingEnabled": false,
      "acrUseManagedIdentityCreds": false,
      "logsDirectorySizeLimit": 35,
      "detailedErrorLoggingEnabled": false,
      "publishingUsername": "$My-Standard-Logic-App",
      "scmType": "None",
      "use32BitWorkerProcess": false,
      "webSocketsEnabled": false,
      "alwaysOn": false,
      "managedPipelineMode": "Integrated",
      "virtualApplications": [
         {
            "virtualPath": "/",
            "physicalPath": "site\\wwwroot",
            "preloadEnabled": false
         }
      ],
      "loadBalancing": "LeastRequests",
      "experiments": {
         "rampUpRules": []
      },
      "autoHealEnabled": false,
      "vnetRouteAllEnabled": false,
      "vnetPrivatePortsCount": 0,
      "publicNetworkAccess": "Enabled",
      "cors": {
         "supportCredentials": false
      },
      "localMySqlEnabled": false,
      "managedServiceIdentityId": 3065,
      "ipSecurityRestrictions": [
         {
            "ipAddress": "208.130.0.0/16",
            "action": "Deny",
            "tag": "Default",
            "priority": 100,
            "name": "Ports"
         },
         {
            "ipAddress": "Any",
            "action": "Deny",
            "priority": 2147483647,
            "name": "Deny all",
            "description": "Deny all access"
         }
      ],
      "ipSecurityRestrictionsDefaultAction": "Deny",
      "scmIpSecurityRestrictions": [
         {
            "ipAddress": "Any",
            "action": "Allow",
            "priority": 2147483647,
            "name": "Allow all",
            "description": "Allow all access"
         }
      ],
      "scmIpSecurityRestrictionsDefaultAction": "Allow",
      "scmIpSecurityRestrictionsUseMain": false,
      "http20Enabled": false,
      "minTlsVersion": "1.2",
      "scmMinTlsVersion": "1.2",
      "ftpsState": "FtpsOnly",
      "preWarmedInstanceCount": 1,
      "functionAppScaleLimit": 0,
      "functionsRuntimeScaleMonitoringEnabled": true,
      "minimumElasticInstanceCount": 1,
      "azureStorageAccounts": {}
   }
},

Diğer hizmetlere ve sistemlere giden çağrılar için erişim

Hedef uç noktanın özelliğine bağlı olarak, HTTP tetikleyicisi veya HTTP eylemi tarafından gönderilen giden çağrılar şifrelemeyi destekler ve daha önce Güvenli Yuva Katmanı (SSL) olarak bilinen Aktarım Katmanı Güvenliği (TLS) 1.0, 1.1 veya 1.2 ile güvenlik altına alınır. Azure Logic Apps, desteklenen en yüksek olası sürümü kullanarak hedef uç noktayla anlaşma sağlar. Örneğin, hedef uç nokta 1.2'yi destekliyorsa, HTTP tetikleyicisi veya eylemi önce 1.2 kullanır. Aksi takdirde bağlayıcı, desteklenen sonraki en yüksek sürümü kullanır.

Bu liste TLS/SSL otomatik olarak imzalanan sertifikalar hakkında bilgi içerir:

• Çok kiracılı Azure Logic Apps ortamındaki Tüketim mantıksal uygulaması iş akışları için HTTP işlemleri otomatik olarak imzalanan TLS/SSL sertifikalarına izin vermez. Mantıksal uygulamanız bir sunucuya HTTP çağrısı yapar ve TLS/SSL otomatik olarak imzalanan bir sertifika sunarsa, HTTP çağrısı bir TrustFailure hatayla başarısız olur.

• Tek kiracılı Azure Logic Apps ortamındaki Standart mantıksal uygulama iş akışları için HTTP işlemleri otomatik olarak imzalanan TLS/SSL sertifikalarını destekler. Ancak, bu kimlik doğrulama türü için birkaç ek adımı tamamlamanız gerekir. Aksi takdirde çağrı başarısız olur. Daha fazla bilgi için, tek kiracılı Azure Logic Apps için TLS/SSL sertifika kimlik doğrulaması'nı gözden geçirin.

  Bunun yerine sertifika kimlik bilgisi türüyle microsoft Entra ID ile istemci sertifikası veya OAuth kullanmak istiyorsanız, yine de bu kimlik doğrulama türü için birkaç ek adımı tamamlamanız gerekir. Aksi takdirde çağrı başarısız olur. Daha fazla bilgi için bkz . İstemci sertifikası veya tek kiracılı Azure Logic Apps için "Sertifika" kimlik bilgisi türüne sahip Microsoft Entra Id ile OAuth.

Mantıksal uygulama iş akışlarınızdan gönderilen çağrıları işleyen uç noktaların güvenliğini sağlamaya yardımcı olmanın diğer yolları şunlardır:

• Giden isteklere kimlik doğrulaması ekleyin.

  Giden çağrıları göndermek için HTTP tetikleyicisini veya eylemini kullandığınızda, mantıksal uygulamanız tarafından gönderilen isteğe kimlik doğrulaması ekleyebilirsiniz. Örneğin, şu kimlik doğrulama türlerini seçebilirsiniz:

  • Temel kimlik doğrulaması

  • İstemci sertifikası kimlik doğrulaması

  • Active Directory OAuth (Microsoft Entra Id ile OAuth 2.0) kimlik doğrulaması

  • Yönetilen kimlik kimlik doğrulaması

• Mantıksal uygulama iş akışı IP adreslerinden erişimi kısıtlayın.

  Mantıksal uygulama iş akışlarından uç noktalara yapılan tüm çağrılar, mantıksal uygulamalarınızın bölgelerini temel alan belirli belirlenmiş IP adreslerinden kaynaklanır. Yalnızca bu IP adreslerinden gelen istekleri kabul eden filtreleme ekleyebilirsiniz. Bu IP adreslerini almak için Azure Logic Apps için sınırlar ve yapılandırma bölümünü gözden geçirin.

• Şirket içi sistemlere bağlantılar için güvenliği geliştirin.

  Azure Logic Apps, daha güvenli ve güvenilir şirket içi iletişim sağlamaya yardımcı olmak için bu hizmetlerle tümleştirme sağlar.

  • Şirket içi veri ağ geçidi

    Azure Logic Apps'teki birçok yönetilen bağlayıcı, Dosya Sistemi, SQL, SharePoint ve DB2 gibi şirket içi sistemlere güvenli bağlantıları kolaylaştırır. Ağ geçidi, Azure Service Bus aracılığıyla şifrelenmiş kanallardaki şirket içi kaynaklardan veri gönderir. Tüm trafik, ağ geçidi aracısından güvenli giden trafik olarak kaynaklanır. Şirket içi veri ağ geçidinin nasıl çalıştığını öğrenin.

  • Azure API Management aracılığıyla bağlanma

    Azure API Management , güvenli ara sunucu ve şirket içi sistemlere iletişim için siteden siteye sanal özel ağ ve ExpressRoute tümleştirmesi gibi şirket içi bağlantı seçenekleri sağlar. Şirket içi sisteminize erişim sağlayan bir API'niz varsa ve bir API Management hizmet örneği oluşturarak bu API'yi kullanıma sundıysanız, iş akışı tasarımcısında ilgili API Management işlemini seçerek bu API'yi mantıksal uygulamanızın iş akışından çağırabilirsiniz.

    Not

    Bağlayıcı yalnızca görüntüleme ve bağlanma izinlerine sahip olduğunuz ancak tüketim tabanlı API Management hizmetlerini göstermediğiniz API Management hizmetlerini gösterir.

    Mantıksal uygulama kaynak türünüz temelinde ilgili adımları izleyin:

    Tüketim iş akışları

    1. API Management tetikleyicisi veya eylemi ekleyip eklemediğinize bağlı olarak şu adımları izleyin:

       • Tetiklemek:

         1. İş akışı tasarımcısında Tetikleyici ekle'yi seçin.

         2. Tetikleyici ekle bölmesi açıldıktan sonra, arama kutusuna API Management yazın.

         3. Tetikleyici sonuçları listesinden Azure API Management Tetikleyicisi Seçin'i seçin.

       • Eylem:

         1. İş akışı tasarımcısında, eylemi eklemek istediğiniz artı işaretini (+) seçin.

         2. Eylem ekle bölmesi açıldıktan sonra, arama kutusuna API Management yazın.

         3. Eylem sonuçları listesinden Azure API Management eylemi seçin'i seçin.

       Aşağıdaki örnekte Azure API Management tetikleyicisini bulma işlemi gösterilmektedir:

       

    2. API Management hizmet örneği listesinden daha önce oluşturduğunuz API Management hizmet örneğini seçin.

    3. API işlemleri listesinden çağrılacak API işlemini seçin ve ardından Eylem Ekle'yi seçin.

    Standart iş akışları

    Standart iş akışları için tetikleyicileri değil yalnızca API Management eylemlerini ekleyebilirsiniz.

    1. İş akışı tasarımcısında, eylemi eklemek istediğiniz artı işaretini (+) seçin.

    2. Eylem ekle bölmesi açıldıktan sonra, arama kutusuna API Management yazın.

    3. Eylem sonuçları listesinden Azure API Management API'sini çağır'ı seçin.

       

    4. API Management hizmet örneği listesinden daha önce oluşturduğunuz API Management hizmet örneğini seçin.

    5. API işlemleri listesinden çağrılacak API işlemini seçin ve ardından Yeni Oluştur'u seçin.

       

Giden aramalara kimlik doğrulaması ekleme

HTTP ve HTTPS uç noktaları çeşitli kimlik doğrulama türlerini destekler. Bu uç noktalara giden çağrılar veya istekler göndermek için kullandığınız bazı tetikleyicilerde ve eylemlerde bir kimlik doğrulama türü belirtebilirsiniz. İş akışı tasarımcısında, kimlik doğrulama türü seçmeyi destekleyen tetikleyiciler ve eylemler bir Authentication özelliğine sahiptir. Ancak, bu özellik her zaman varsayılan olarak görünmeyebilir. Bu durumlarda, tetikleyicide veya eylemde Gelişmiş parametreler listesini açın ve Kimlik Doğrulaması'nı seçin.

Temel kimlik doğrulama

HTTP çağrıları için temel kimlik doğrulaması, istekte bulunmak için kullanıcı adı ve parola içeren base64 kodlu bir dize kullanır. Bu yöntem, kimlik bilgilerini şifreleme olmadan iletir ve bu seçeneği HTTPS/SSL protokolüyle kullanmadığınız sürece daha fazla güvenlik riski oluşturur.

Temel seçeneği kullanılabilir ve seçiliyse şu özellik değerlerini belirtin:

Hassas bilgileri işlemek ve güvenli hale getirmek için güvenli parametreler kullandığınızda( örneğin, dağıtımı otomatikleştirmeye yönelik bir Azure Resource Manager şablonunda), çalışma zamanında bu parametre değerlerine erişmek için ifadeleri kullanabilirsiniz. Bu örnek HTTP eylem tanımı kimlik doğrulamasını type olarak Basic belirtir ve parametre değerlerini almak için parameters() işlevini kullanır:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Basic",
         "username": "@parameters('userNameParam')",
         "password": "@parameters('passwordParam')"
      }
  },
  "runAfter": {}
}

İstemci sertifikası kimlik doğrulaması

İstemci sertifikası kimlik doğrulaması , kullanıcıların uygulamalar ve tarayıcı oturum açma işlemleri için Microsoft Entra kimliklerine göre X.509 sertifikalarıyla doğrudan kimlik doğrulaması yapmasına izin verir veya gerektirir. Bu özellik, kimlik avına dayanıklı kimlik doğrulaması benimsemenize ve Ortak Anahtar Altyapınızda (PKI) X.509 sertifikasıyla kimlik doğrulaması yapmanıza yardımcı olur.

İstemci sertifikası seçeneği kullanılabilir ve seçiliyse şu özellik değerlerini belirtin:

Hassas bilgileri işlemek ve güvenli hale getirmek için güvenli parametreler kullandığınızda( örneğin, dağıtımı otomatikleştirmeye yönelik bir Azure Resource Manager şablonunda), çalışma zamanında bu parametre değerlerine erişmek için ifadeleri kullanabilirsiniz. Bu örnek HTTP eylem tanımı kimlik doğrulamasını type olarak ClientCertificate belirtir ve parametre değerlerini almak için parameters() işlevini kullanır:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "ClientCertificate",
         "pfx": "@parameters('pfxParam')",
         "password": "@parameters('passwordParam')"
      }
   },
   "runAfter": {}
}

İstemci sertifikası kimlik doğrulamasını kullanarak hizmetlerin güvenliğini sağlama hakkında daha fazla bilgi için şu konuları gözden geçirin:

• Azure API Management'ta istemci sertifikası kimlik doğrulamasını kullanarak API'ler için güvenliği geliştirme
• Azure API Management'ta istemci sertifikası kimlik doğrulamasını kullanarak arka uç hizmetleri için güvenliği geliştirme
• İstemci sertifikalarını kullanarak RESTfuL hizmetinizin güvenliğini geliştirme
• Uygulama kimlik doğrulaması için sertifika kimlik bilgileri
• Azure App Service'te kodunuzda TLS/SSL sertifikası kullanma

Microsoft Entra platformu

İstek tetikleyicisinde, mantıksal uygulamanız için Microsoft Entra yetkilendirme ilkelerini ayarladıktan sonra gelen çağrıların kimliğini doğrulamak için Microsoft Entra platformunu kullanabilirsiniz.

Active Directory OAuth (Microsoft Entra Id ile OAuth 2.0) kimlik doğrulama türünü destekleyen diğer tüm tetikleyicilerde ve eylemlerde şu özellik değerlerini belirtin:

Hassas bilgileri işlemek ve güvenli hale getirmek için güvenli parametreler kullandığınızda( örneğin, dağıtımı otomatikleştirmeye yönelik bir Azure Resource Manager şablonunda), çalışma zamanında bu parametre değerlerine erişmek için ifadeleri kullanabilirsiniz. Bu örnek HTTP eylem tanımı kimlik doğrulamasını type olarak ActiveDirectoryOAuthbelirtir, kimlik bilgisi türü olarak Secretve parametre değerlerini almak için parameters() işlevini kullanır:

"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": {}
}

Ham kimlik doğrulaması

Ham seçeneği varsa, OAuth 2.0 protokolüne uymayen kimlik doğrulama düzenlerini kullanmanız gerektiğinde bu kimlik doğrulama türünü kullanabilirsiniz. Bu türle, giden istekle gönderdiğiniz yetkilendirme üst bilgisi değerini el ile oluşturur ve tetikleyicinizde veya eyleminizde bu üst bilgi değerini belirtirsiniz.

Aşağıdaki örnekte, OAuth 1.0 protokolunu izleyen bir HTTPS isteği için örnek üst bilgi gösterilmektedir:

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"

Ham kimlik doğrulamasını destekleyen tetikleyicide veya eylemde şu özellik değerlerini belirtin:

Hassas bilgileri işlemek ve güvenli hale getirmek için güvenli parametreler kullandığınızda( örneğin, dağıtımı otomatikleştirmeye yönelik bir Azure Resource Manager şablonunda), çalışma zamanında bu parametre değerlerine erişmek için ifadeleri kullanabilirsiniz. Bu örnek HTTP eylem tanımı kimlik doğrulamasını type olarak Rawbelirtir ve parametre değerlerini almak için parameters() işlevini kullanır:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "@parameters('endpointUrlParam')",
      "authentication": {
         "type": "Raw",
         "value": "@parameters('authHeaderParam')"
      }
   },
   "runAfter": {}
}

Yönetilen kimlik doğrulaması

Yönetilen kimlik doğrulamasını destekleyen tetikleyicide veya eylemde yönetilen kimlik seçeneği kullanılabilir olduğunda, mantıksal uygulamanız kimlik bilgileri, gizli diziler veya Microsoft Entra belirteçleri yerine Microsoft Entra Kimliği ile korunan Azure kaynaklarına erişimin kimliğini doğrulamak için bu kimliği kullanabilir. Azure bu kimliği sizin için yönetir ve gizli dizileri yönetmeniz veya doğrudan Microsoft Entra belirteçlerini kullanmanız gerekmeyen kimlik bilgilerinizin güvenliğini sağlamanıza yardımcı olur. Microsoft Entra kimlik doğrulaması için yönetilen kimlikleri destekleyen Azure hizmetleri hakkında daha fazla bilgi edinin.

• Tüketim mantıksal uygulaması kaynağı, sistem tarafından atanan kimliği veya el ile oluşturulan tek bir kullanıcı tarafından atanan kimliği kullanabilir.

• Standart mantıksal uygulama kaynağı, sistem tarafından atanan yönetilen kimliğin ve kullanıcı tarafından atanan birden çok yönetilen kimliğin aynı anda etkinleştirilmesini destekler, ancak yine de istediğiniz zaman yalnızca bir kimlik seçebilirsiniz.

  Not

  Varsayılan olarak, sistem tarafından atanan kimlik çalışma zamanında bağlantıların kimliğini doğrulamak için zaten etkindir. Bu kimlik, bağlantı oluştururken kullandığınız kimlik doğrulama kimlik bilgilerinden veya bağlantı dizesi farklıdır. Bu kimliği devre dışı bırakırsanız, bağlantılar çalışma zamanında çalışmaz. Bu ayarı görüntülemek için mantıksal uygulama menünüzün Ayarlar'ın altında Kimlik'i seçin.

1. Mantıksal uygulamanızın yönetilen kimlik kullanabilmesi için önce Azure Logic Apps'te yönetilen kimlikleri kullanarak Azure kaynaklarına erişimin kimliğini doğrulama bölümünde yer alan adımları izleyin. Bu adımlar mantıksal uygulamanızda yönetilen kimliği etkinleştirir ve bu kimliğin hedef Azure kaynağına erişimini ayarlar.

2. Bir Azure işlevinin yönetilen kimlik kullanabilmesi için önce Azure işlevleri için kimlik doğrulamasını etkinleştirin.

3. Yönetilen kimlik kullanmayı destekleyen tetikleyicide veya eylemde şu bilgileri sağlayın:

   Yerleşik tetikleyiciler ve eylemler

   Özellik (tasarımcı)	Özellik (JSON)	Zorunlu	Değer	Açıklama
   Kimlik Doğrulaması	type	Yes	Yönetilen Kimlik veya ManagedServiceIdentity	Kullanılacak kimlik doğrulama türü
   Yönetilen Kimlik	identity	Hayır	<user-assigned-identity-ID>	Kullanılacak kullanıcı tarafından atanan yönetilen kimlik. Not: Sistem tarafından atanan yönetilen kimliği kullanırken bu özelliği eklemeyin.
   Seyirci	audience	Yes	<target-resource-ID>	Erişmek istediğiniz hedef kaynağın kaynak kimliği. Örneğin, https://storage.azure.com/ kimlik doğrulaması için erişim belirteçlerini tüm depolama hesapları için geçerli hale getirir. Ancak, belirli bir depolama hesabı için olduğu gibi https://fabrikamstorageaccount.blob.core.windows.net bir kök hizmet URL'si de belirtebilirsiniz. Not: Audience özelliği bazı tetikleyicilerde veya eylemlerde gizlenmiş olabilir. Bu özelliği görünür hale getirmek için tetikleyicide veya eylemde Gelişmiş parametreler listesini açın ve hedef kitle'yi seçin. Önemli: Bu hedef kaynak kimliğinin , gerekli sondaki eğik çizgiler de dahil olmak üzere Microsoft Entra Id'nin beklediği değerle tam olarak eşleştiğinden emin olun. Bu nedenle, tüm Azure Blob Depolama hesaplarının https://storage.azure.com/ kaynak kimliği için sondaki eğik çizgi gerekir. Ancak, belirli bir depolama hesabının kaynak kimliği için sondaki eğik çizgi gerekmez. Bu kaynak kimliklerini bulmak için Microsoft Entra Id'yi destekleyen Azure hizmetlerini gözden geçirin.

   Hassas bilgileri işlemek ve güvenli hale getirmek için güvenli parametreler kullandığınızda( örneğin, dağıtımı otomatikleştirmeye yönelik bir Azure Resource Manager şablonunda), çalışma zamanında bu parametre değerlerine erişmek için ifadeleri kullanabilirsiniz. Örneğin, bu HTTP eylem tanımı kimlik doğrulamasını type olarak ManagedServiceIdentity belirtir ve parametre değerlerini almak için parameters() işlevini kullanır:

   "HTTP": {
      "type": "Http",
      "inputs": {
         "method": "GET",
         "uri": "@parameters('endpointUrlParam')",
         "authentication": {
            "type": "ManagedServiceIdentity",
            "audience": "https://management.azure.com/"
         },
      },
      "runAfter": {}
   }
   

   Yönetilen bağlayıcı tetikleyicileri ve eylemleri

   Özellik (tasarımcı)	Zorunlu	Değer	Açıklama
   Bağlantı adı	Yes	<bağlantı adı>
   Yönetilen kimlik	Yes	Sistem tarafından atanan yönetilen kimlik veya <user-assigned-managed-identity-name>	Kullanılacak kimlik doğrulama türü

Blok oluşturma bağlantıları

Kuruluşunuz Azure Logic Apps'te bağlayıcılarını kullanarak belirli kaynaklara bağlanmaya izin vermiyorsa, Azure İlkesi kullanarak mantıksal uygulama iş akışlarında belirli bağlayıcılar için bu bağlantıları oluşturma özelliğini engelleyebilirsiniz. Daha fazla bilgi için Bkz . Azure Logic Apps'te belirli bağlayıcılar tarafından oluşturulan bağlantıları engelleme.

Mantıksal uygulamalar için yalıtım kılavuzu

• Azure Kamu Etki Düzeyi 5 Yalıtım Kılavuzu tarafından açıklanan bölgelerdeki tüm etki düzeylerini destekleyen Azure Kamu Azure Logic Apps'i kullanabilirsiniz. Bu gereksinimleri karşılamak için Azure Logic Apps, mantıksal uygulamalarınızdaki diğer Azure kiracılarının performans etkisini azaltabilmeniz ve bilgi işlem kaynaklarını diğer kiracılarla paylaşmaktan kaçınmanız için ayrılmış kaynakları olan bir ortamda iş akışları oluşturmanızı ve çalıştırmanızı destekler.

• Standart mantıksal uygulama iş akışları, gelen trafik için ayarladığınız özel uç noktalar ve giden trafik için sanal ağ tümleştirmesi aracılığıyla bir Azure sanal ağıyla özel ve güvenli bir şekilde iletişim kurabilir. Daha fazla bilgi için özel uç noktaları kullanarak sanal ağlar ve tek kiracılı Azure Logic Apps arasındaki trafiğin güvenliğini sağlama konularını gözden geçirin.

• Kendi kodunuzu çalıştırmak veya XML dönüşümü gerçekleştirmek için sırasıyla satır içi kod özelliğini kullanmak veya eşleme olarak kullanılacak derlemeler sağlamak yerine bir Azure işlevi oluşturup çağırın. Ayrıca, yalıtım gereksinimlerinize uyması için işlev uygulamanızın barındırma ortamını ayarlayın.

  Örneğin, Etki Düzeyi 5 gereksinimlerini karşılamak için Yalıtılmış fiyatlandırma katmanını ve Yalıtılmış fiyatlandırma katmanını da kullanan bir App Service Ortamı (ASE) kullanarak işlev uygulamanızı App Service planıyla oluşturun. Bu ortamda işlev uygulamaları, ayrılmış Azure sanal makinelerinde ve ayrılmış Azure sanal ağlarında çalıştırılır. Bu ağ, uygulamalarınız için işlem yalıtımının yanı sıra maksimum ölçek genişletme özelliklerine göre ağ yalıtımı sağlar.

  Daha fazla bilgi için aşağıdaki belgeleri gözden geçirin:

  • hizmet planlarını Azure Uygulaması
  • Azure İşlevleri ağ seçenekleri
  • Sanal makineler için Azure Ayrılmış Konakları
  • Azure'da sanal makine yalıtımı
  • Ayrılmış Azure hizmetlerini sanal ağlara dağıtma

Yalıtım hakkında daha fazla bilgi için aşağıdaki belgelere bakın:

• Azure Genel Bulutu'nda yalıtım
• Azure'da son derece hassas IaaS uygulamaları için güvenlik

İlgili içerik

• Azure Logic Apps için Azure güvenlik temeli
• Azure Logic Apps için dağıtımı otomatikleştirme
• Mantıksal Uygulamaları izleme