你当前正在访问 Microsoft Azure Global Edition 技术文档网站。如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

保护 Azure 逻辑应用中工作流的访问和数据

项目
10/15/2024

Azure 逻辑应用依赖 Azure 存储来存储和自动加密静态数据。此加密可保护数据，并帮助你履行组织的安全性和符合性承诺。默认情况下，Azure 存储使用 Microsoft 托管密钥来加密数据。有关详细信息，请查看静态数据的 Azure 存储加密。

若要在 Azure 逻辑应用中进一步控制访问并保护敏感数据，可以在以下方面设置更多安全性：

对逻辑应用操作的访问
对运行历史记录输入和输出的访问
对参数输入的访问
支持身份验证的触发器和操作的身份验证类型
对基于请求的触发器的入站调用的访问
对其他服务和系统的出站调用的访问
阻止为特定连接器创建连接
逻辑应用隔离指导
Azure 逻辑应用的 Azure 安全基线

有关 Azure 中的安全性的详细信息，请查看以下主题：

对逻辑应用操作的访问

对于消耗型逻辑应用，要创建或管理逻辑应用及其连接，你需要具有特定的权限，这些权限是使用 Azure 基于角色的访问控制 (Azure RBAC) 通过角色提供的。你还可以设置权限，以便仅允许特定用户或组运行特定任务，例如管理、编辑和查看逻辑应用。要控制其权限，你可以将内置或自定义角色分配给有权访问 Azure 订阅的成员。 Azure 逻辑应用具有以下特定角色，具体取决于你使用的是消耗型还是标准型逻辑应用工作流：

消耗型工作流

角色	说明
逻辑应用参与者	可以管理逻辑应用工作流，但不能更改对它们的访问权限。
逻辑应用操作员	可以读取、启用和禁用逻辑应用工作流，但不能对其进行编辑或更新。
参与者	具有管理所有资源的完全访问权限，但不能在 Azure RBAC 中分配角色或在 Azure 蓝图中管理分配，也不能共享映像库。

例如，假设你必须使用并非你创建的逻辑应用工作流，并对该逻辑应用的工作流使用的连接进行身份验证。 Azure 订阅需要具备包含该逻辑应用资源的资源组的参与者权限。如果创建逻辑应用资源，则会自动具有参与者访问权限。

要防止他人更改或删除逻辑应用工作流，可以使用 Azure 资源锁。此功能可以防止他人更改或删除生产资源。有关连接安全性的详细信息，请参阅 Azure 逻辑应用中的连接配置和连接安全性和加密。

标准型工作流

注意

此功能为预览版，受 Microsoft Azure 预览版补充使用条款限制。

角色	说明
标准型逻辑应用读取者（预览版）	对标准型逻辑应用和工作流中的所有资源（包括工作流运行及其历史记录）具有只读访问权限。
标准型逻辑应用操作者（预览版）	具有启用、重新提交和禁用工作流，以及为标准型逻辑应用创建与服务、系统和网络的连接的权限。操作者角色可以在 Azure 逻辑应用平台上执行管理和支持任务，但无权编辑工作流或设置。
标准型逻辑应用开发者（预览版）	具有为标准型逻辑应用创建和编辑工作流、连接和设置的权限。开发者角色无权在工作流范围之外进行更改，例如配置虚拟网络集成等应用程序范围的更改。不支持应用服务计划。
标准型逻辑应用参与者（预览版）	具有管理标准型逻辑应用各个方面的权限，但不能更改访问权限或所有权。

对运行历史记录数据的访问

在逻辑应用运行期间，所有数据都是使用传输层安全性 (TLS) 在传输过程中加密的以及静态加密的。运行逻辑应用后，可以查看该运行的历史记录，包括已运行的步骤以及每个操作的状态、持续时间、输入和输出。此丰富的详细信息可让你深入了解逻辑应用的运行方式，以及开始解决出现的任何问题的位置。

查看逻辑应用的运行历史记录时，Azure 逻辑应用对该访问进行身份验证，然后提供指向每次运行的请求和响应的输入和输出的链接。但是，对于处理任何密码、机密、密钥或其他敏感信息的操作，你需要阻止他人查看和访问该数据。例如，如果逻辑应用从 Azure Key Vault 获取机密，以便在对 HTTP 操作进行身份验证时使用，则你需要在视图中隐藏该机密。

若要控制对逻辑应用运行历史记录中的输入和输出的访问，可使用以下选项：

按 IP 地址范围限制访问。

此选项可帮助你基于来自特定 IP 地址范围的请求保护对运行历史记录的访问。
使用模糊处理保护运行历史记录中的数据。

在许多触发器和操作中，可以保护逻辑应用的运行历史记录中的输入和/或输出。

按 IP 地址范围限制访问

可以限制对逻辑应用工作流的运行历史记录中的输入和输出的访问，以便只有来自特定 IP 地址范围的请求才能查看该数据。

例如，若要阻止任何人访问输入和输出，请指定类似于 0.0.0.0-0.0.0.0 的 IP 地址范围。只有拥有管理员权限的人员才能移除此限制，使“实时”访问逻辑应用工作流中的数据成为可能。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x

若要指定允许的 IP 范围，请执行以下针对 Azure 门户或 Azure 资源管理器模板中的消费型或标准逻辑应用的步骤：

Portal
资源管理器模板

消耗型工作流

在 Azure 门户中，打开设计器中的消耗逻辑应用工作流。
在逻辑应用菜单的“设置”下，选择“工作流设置”。
在“访问控制配置”部分中，在“允许的入站 IP 地址”下，从“触发器访问选项”列表中选择“特定 IP 范围”。
在“内容的 IP 范围”下，指定可以访问输入和输出内容的 IP 地址范围。

标准型工作流

在 Azure 门户中，打开你的标准逻辑应用资源。
在逻辑应用菜单的“设置”下，选择“网络”。
在“入站流量配置”部分，选择“公用网络访问”旁边的“启用且没有访问限制”。
在“访问限制”页上，在“应用访问”下，选择“从选择虚拟网络和 IP 地址启用”。
在“站点访问和规则”下，在“主站点”选项卡上，添加一个或多个规则以“允许”或“拒绝”来自特定 IP 范围的请求。还可以使用 HTTP 标头筛选器设置和转发设置。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x

有关详细信息，请参阅在 Azure 逻辑应用（标准型）中阻止入站 IP 地址。

消耗型工作流

在 ARM 模板中逻辑应用的资源定义中使用 accessControl 节和 contents 节指定 IP 范围，例如：

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

标准型工作流

在 ARM 模板中，在逻辑应用的资源定义中使用 Microsoft.Web/sites/config 节指定允许的入站 IP 地址范围。在本部分，在 properties 下添加 ipSecurityRestrictions 部分，并使用 ipAddress、action="Deny" | "Allow"、tag=Default、priority 和 name="Ports" 部分来定义规则，并将 ipAddress 设置为采用 x.x.x.x/x 或 x.x.x.x-x.x.x.x 格式的允许的 IP 范围，例如：

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

使用模糊处理保护运行历史记录中的数据

许多触发器和操作具有用于保护逻辑应用的运行历史记录中的输入和/或输出的设置。所有托管连接器和自定义连接器都支持这些选项。但是，以下内置操作不支持这些选项：

安全输入 - 不受支持	安全输出 - 不受支持
追加到数组变量追加到字符串变量递减变量对每一个如果递增变量初始化变量定期作用域设置变量 Switch 终止截止	追加到数组变量追加到字符串变量撰写递减变量对每一个如果递增变量初始化变量分析 JSON 定期响应作用域设置变量 Switch 终止截止 Wait

保护输入和输出时的注意事项

在使用这些设置帮助保护此数据之前，请查看以下注意事项：

遮盖触发器或操作的输入或输出时，Azure 逻辑应用不会将安全数据发送到 Azure Log Analytics。此外，不能将跟踪的属性添加到该触发器或操作进行监视。
用于处理工作流历史记录的 Azure 逻辑应用 API 不返回安全输出。
若要保护可遮盖输入或显式遮盖输出的操作的输出，请在该操作中手动打开“安全输出”。
请确保在你希望运行历史记录来遮盖该数据的下游操作中打开“安全输入”或“安全输出” 。

安全输出设置

在触发器或操作中手动启用“安全输出”时，Azure 逻辑应用会隐藏运行历史记录中的这些输出。如果下游操作显式使用这些安全输出作为输入，则 Azure 逻辑应用会隐藏运行历史记录中的此操作的输入，但不会启用操作的“安全输入”设置。

“撰写”、“分析 JSON”和“响应”操作仅提供“保护输入”设置。启用后，此设置也会隐藏这些操作的输出。如果这些操作显式使用上游安全输出作为输入，则 Azure 逻辑应用会隐藏这些操作的输入和输出，但不会启用这些操作的“安全输入”设置。如果下游操作显式使用来自撰写、分析 JSON 或响应操作的隐藏输出作为输入，则 Azure 逻辑应用不会隐藏此下游操作的输入或输出。

安全输入设置

在触发器或操作中手动打开“安全输入”时，Azure 逻辑应用会隐藏运行历史记录中的这些输入。如果下游操作显式使用来自该触发器或操作的可见输出作为输入，则 Azure 逻辑应用将在运行历史记录中隐藏此下游操作的输入，但不会在此操作中启用“保护输入”，并且不会隐藏此操作的输出。

如果撰写、分析 JSON 和响应操作显式使用具有安全输入的触发器或操作的可见输出，则 Azure 逻辑应用会隐藏这些操作的输入和输出，但不会启用这些操作的“安全输入”设置。如果下游操作显式使用来自撰写、分析 JSON 或响应操作的隐藏输出作为输入，则 Azure 逻辑应用不会隐藏此下游操作的输入或输出。

保护设计器中的输入和输出

在 Azure 门户中，打开设计器的逻辑应用工作流。
在设计器上，选择要在其中保护敏感数据的触发器或操作。
在打开的信息窗格中，选择“设置”，然后展开“安全性”。
打开“安全输入”和/或“安全输出” 。

触发器或操作现在显示标题栏中的锁图标。表示以前操作的安全输出的令牌也显示锁图标。例如，在后续操作中，为动态内容列表中的安全输出选择令牌后，该令牌将显示一个锁图标。
运行工作流后，可以查看该运行的历史记录。
1. 在消耗逻辑应用菜单或标准工作流菜单中选择“概述”。
2. 在“运行历史记录”下，选择要查看的运行。
3. 在工作流运行历史记录窗格中，选择要查看的操作。
  
  如果已选择同时隐藏输入和输出，则这些值现在会隐藏。

保护代码视图中的输入和输出

在基础触发器或操作定义中，使用以下两个值中的一个或两个值添加或更新 runtimeConfiguration.secureData.properties 数组：

"inputs"：在运行历史记录中保护输入。
"outputs"：保护运行历史记录中的输出。

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

对参数输入的访问

如果跨不同的环境进行部署，请考虑参数化工作流定义中因这些环境而有所不同的值。这样，便可以通过使用 Azure 资源管理器模板部署逻辑应用来避免使用硬编码数据，通过定义安全的参数来保护敏感数据，并使用参数文件通过模板的参数将该数据作为单独输入传递。

例如，如果使用 Microsoft Entra ID OAuth 对 HTTP 操作进行身份验证，则可以定义并保护接受用于身份验证的客户端 ID 和客户端机密的参数。若要在逻辑应用工作流中定义这些参数，请使用逻辑应用的工作流定义中的 parameters 部分，以及用于部署的资源管理器模板。若要帮助保护在编辑逻辑应用或查看运行历史记录时不希望显示的参数值，请使用 securestring 或 secureobject 类型定义参数并根据需要使用编码。具有此类型的参数不会随资源定义一起返回，并且在部署后无法通过查看资源来访问这些参数。若要在运行时访问这些参数值，请在工作流定义中使用 @parameters('<parameter-name>') 表达式。此表达式仅在运行时进行计算，由工作流定义语言描述。

注意

如果在请求头或正文中使用参数，当查看工作流的运行历史记录和传出的 HTTP 请求时，该参数可能是可见的。请务必同时相应地设置内容访问策略。还可以使用模糊处理在运行历史记录中隐藏输入和输出。默认情况下，Authorization 标头在输入或输出中是不可见的。因此，如果在此处使用机密，则无法检索该机密。

有关详细信息，请查看本主题中的以下部分：

在工作流定义中保护参数
使用模糊处理保护运行历史记录中的数据

如果使用资源管理器模板自动执行逻辑应用部署，则可以使用 securestring 和 secureobject 类型定义在部署时计算的安全模板参数。若要定义模板参数，请使用模板的顶级 parameters 节，该节不同于工作流定义的 parameters 节。若要提供模板参数的值，请使用单独的参数文件。

例如，如果使用机密，则可以定义并使用可在部署时从 Azure Key Vault 检索这些机密的受保护模板参数。然后，可以在参数文件中引用 Key Vault 和机密。有关详细信息，请查看以下主题：

在部署时使用 Azure Key Vault 传递敏感值
本主题后面的在 Azure 资源管理器模板中保护参数

在工作流定义中保护参数（消耗型工作流）

若要在逻辑应用的工作流定义中保护敏感信息，请使用安全的参数，使该信息在保存逻辑应用工作流后不可见。例如，假设某个 HTTP 操作需要使用用户名和密码进行基本身份验证。在工作流定义中，parameters 节使用 securestring 类型定义 basicAuthPasswordParam 和 basicAuthUsernameParam 参数。然后，操作定义将引用 authentication 节中的这些参数。

重要

为了获得最佳安全性，Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。此选项提供卓越的安全性，无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全，这样你就无需管理这种敏感信息了。若要为 Azure 逻辑应用设置托管标识，请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。

"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 资源管理器模板中保护参数（消耗型工作流）

逻辑应用资源和工作流的资源管理器模板包含多个 parameters 部分。若要保护密码、密钥、机密和其他敏感信息，请使用 securestring 或 secureobject 类型在模板级别和工作流定义级别定义安全的参数。然后，可将这些值存储在 Azure Key Vault 中，并使用参数文件来引用 Key Vault 和机密。模板便会在部署时检索该信息。有关详细信息，请查看使用 Azure Key Vault 在部署时传递敏感值。

重要

此列表包含有关这些 parameters 部分的更多信息：

在模板的最高级别，parameters 节定义了模板在部署时使用的值的参数。例如，这些值可能包含特定部署环境的连接字符串。然后，你可将这些值存储在单独的参数文件中，以方便更改这些值。
在逻辑应用的资源定义内部、工作流定义外部，parameters 节指定了工作流定义参数的值。在此节中，可以使用引用模板参数的模板表达式来分配这些值。这些表达式将在部署时计算。
在工作流定义中，parameters 部分定义了逻辑应用工作流在运行时使用的参数。然后，你可以使用在运行时计算的工作流定义表达式，在逻辑应用工作流中引用这些参数。

此示例模板包含使用 securestring 类型的多个受保护参数定义：

参数名称	说明
`TemplatePasswordParam`	一个模板参数，它接受随后要传递到工作流定义的 `basicAuthPasswordParam` 参数的密码
`TemplateUsernameParam`	一个模板参数，它接受随后要传递到工作流定义的 `basicAuthUserNameParam` 参数的用户名
`basicAuthPasswordParam`	一个工作流定义参数，它接受 HTTP 操作中用于基本身份验证的密码
`basicAuthUserNameParam`	一个工作流定义参数，它接受 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": {}
}

支持身份验证的连接器的身份验证类型

下表列出了连接器操作中可用的身份验证类型，你可以在其中选择身份验证类型：

身份验证类型	逻辑应用和支持的连接器
基本	Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP Webhook
客户端证书	Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP Webhook
Active Directory OAuth（使用 Microsoft Entra ID 的 OAuth 2.0）	- 消耗：Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook - 标准：Azure 自动化、Azure Blob 存储、Azure 事件中心、Azure 队列、Azure 服务总线、Azure 表、HTTP、HTTP Webhook、SQL Server
Raw	Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook
托管的标识	内置连接器： - 消耗：Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP Webhook - 标准：Azure 自动化、Azure Blob 存储、Azure 事件中心、Azure 队列、Azure 服务总线、Azure 表、HTTP、HTTP Webhook、SQL Server 注意：目前，大多数基于服务提供商的内置连接器不支持选择用户分配的托管标识进行身份验证。托管连接器：Azure 应用服务、Azure 自动化、Azure Blob 存储、Azure 容器实例、Azure Cosmos DB、Azure 数据资源管理器、Azure 数据工厂、Azure Data Lake、Azure 事件网格、Azure 事件中心、Azure IoT Central V2、Azure IoT Central V3、Azure 密钥保管库、Azure Log Analytics、Azure 队列、Azure 资源管理器、Azure 服务总线、Azure Sentinel、Azure 表存储、使用 Microsoft Entra ID 的 HTTP、SQL Server

重要

对基于请求的触发器的入站调用的访问

逻辑应用通过基于请求的触发器（例如请求触发器或 HTTP Webhook 触发器）接收的入站调用支持加密，并至少使用传输层安全性 (TLS) 1.2（前称安全套接字层 (SSL)）进行保护。 Azure 逻辑应用在收到对请求触发器的入站调用或对 HTTP Webhook 触发器或操作的回调时强制实施此版本。

注意

如果出现 TLS 握手错误，请确保使用 TLS 1.2。有关详细信息，请参阅解决 TLS 1.0 问题。

对于入站调用，请使用以下密码套件：

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

重要

对于向后兼容性，Azure 逻辑应用当前支持一些较旧的密码套件。但是，请勿在开发新应用时使用较旧的密码套件，因为此类套件可能在未来不受支持。

例如，如果你在 Azure 逻辑应用中检查 TLS 握手消息，或者使用逻辑应用 URL 上的安全工具，则可能会找到以下密码套件。再次声明，请勿使用以下较旧的套件：

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

你可以使用以下列表包括的方法限制对触发器（这些触发器接收对逻辑应用工作流的入站调用）的访问，以便只有经过授权的客户端才能调用工作流：

启用使用 Microsoft Entra ID 的 OAuth
生成共享访问签名 (SAS) 密钥或令牌
禁用共享访问签名 (SAS) 身份验证
限制入站 IP 地址
通过 Azure API 管理公开逻辑应用

启用使用 Microsoft Entra ID 的 OAuth 2.0

在以基于请求的触发器开头的消耗工作流中，可以通过启用使用 Microsoft Entra ID 的 OAuth 2.0，对发送到该触发器创建的终结点的入站调用进行身份验证和授权。若要设置此身份验证，请在逻辑应用资源级别定义或添加授权策略。这样，入站调用将使用 OAuth 访问令牌进行授权。

当你的逻辑应用工作流收到包含 OAuth 访问令牌的入站请求时，Azure 逻辑应用会将令牌的声明与每个授权策略指定的声明进行比较。如果令牌的声明与至少一个策略中的所有声明之间存在匹配项，则入站请求的授权成功。令牌的声明数可以大于授权策略指定的声明数。

在以请求触发器（但不是 Webhook 触发器）开始的标准工作流中，可使用 Azure Functions 预配，通过托管标识对发送到由该请求触发器创建的终结点的入站调用进行身份验证。此预配也称为“简易身份验证”。有关详细信息，请查看使用简易身份验证在标准逻辑应用中触发工作流。

启用使用 Microsoft Entra ID 的 OAuth 2.0 之前的注意事项

为了获得最佳安全性，Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。此选项提供卓越的安全性，无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全，这样你就无需管理这种敏感信息了。若要为 Azure 逻辑应用设置托管标识，请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
在消耗工作流中，对基于请求的触发器的终结点 URL 的入站调用只能使用一个授权方案，即使用 Microsoft Entra ID 的 OAuth 2.0 或共享访问签名 (SAS) 二者之一。尽管使用一个方案不会禁用另一个方案，但如果同时使用这两种方案，Azure 逻辑应用会生成错误，因为服务不知道要选择哪个方案。如果消耗工作流以请求触发器开头，则可以禁用 SAS 身份验证，并限制授权以仅使用使用 Microsoft Entra ID 的 OAuth 2.0。对于标准工作流，无需禁用 SAS 即可使用其他身份验证类型。
Azure 逻辑应用支持 Microsoft Entra ID OAuth 访问令牌的授权方案持有者类型或所有权证明类型（仅消耗型逻辑应用）。但是，Authorization访问令牌的标头必须指定 Bearer 类型或 PoP 类型。有关如何获取和使用 PoP 令牌的详细信息，请参阅获取所有权证明 (PoP) 令牌。
消耗逻辑应用资源限制为最大授权策略数。每个授权策略还具有最大声明数。有关详细信息，请参阅 Azure 逻辑应用的限制和配置。

授权策略必须至少包含“颁发者”声明，该声明作为 Microsoft Entra ID 的颁发者，以 https://sts.windows.net/ 或 https://login.microsoftonline.com/ (OAuth V2) 开头。

例如，假定逻辑应用资源有一个需要两个声明类型（“受众”和“颁发者”）的授权策略。解码的访问令牌的此示例有效负载部分包括两种声明类型，其中 aud 是受众值，iss 是颁发者值：

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

启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用请求终结点的唯一选项（仅消耗）

对于基于请求的终结点，可以将授权限制为仅使用使用 Microsoft Entra ID 的 OAuth 2.0。即使禁用共享访问签名 (SAS) 身份验证，此选项也能正常工作。

对于消耗工作流，请按照在请求触发器或 HTTP Webhook 触发器输出中包含“Authorization”标头的步骤，设置请求或 HTTP Webhook 触发器，以检查 OAuth 访问令牌的功能。

注意

此步骤使 Authorization 标头在工作流的运行历史记录和触发器的输出中可见。
在 Azure 门户中，打开设计器中的消耗工作流。
在设计器上，选择触发器。在打开的信息窗格中，选择“设置”。
在“常规”>“触发条件”下，选择“添加”。在“触发条件”框中，根据要使用的令牌类型输入以下表达式之一：

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

-或-

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

如果在没有正确授权的情况下调用触发器终结点，则运行历史记录只将触发器显示为 Skipped，而不会显示有关触发器条件失败的任何消息。

获取所有权证明 (PoP) 令牌

Microsoft 身份验证库 (MSAL) 库提供 PoP 令牌供你使用。如果要调用的消耗逻辑应用工作流需要 PoP 令牌，可以使用 MSAL 库获取此令牌。以下示例演示如何获取 PoP 令牌：

若要将 PoP 令牌用于消耗逻辑应用工作流，请按照以下步骤设置使用 Microsoft Entra ID 的 OAuth。

为消耗逻辑应用资源启用使用 Microsoft Entra ID 的 OAuth

若要将授权策略添加到消耗逻辑应用，请遵循 Azure 门户或 Azure 资源管理器模板的步骤：

Portal
资源管理器模板

在 Azure 门户中，打开设计器中的消耗型逻辑应用和工作流。
在逻辑应用菜单的“设置”下，选择“授权” 。
在“授权”页上，选择“添加策略”。

在每次对请求触发器进行入站调用时提供的访问令牌中，逻辑应用需要一些声明类型和值，通过指定这些声明类型和值来提供有关授权策略的信息：

properties	必须	类型	说明
策略名称	是	String	要用于授权策略的名称
策略类型	是	字符串	表示持有者类型令牌的 AAD 或表示所有权证明类型令牌的 AADPOP。
申请	是	字符串	一个键值对，指定工作流的请求触发器在每次对触发器的入站调用所提供的访问令牌中所需的声明类型和值。可以通过选择“添加标准声明”来添加所需的任何标准声明。若要添加特定于 PoP 令牌的声明，请选择“添加自定义声明”。可用的标准声明类型： - 颁发者 - 受众 - 主题 - JWT ID（JSON Web 令牌标识符）要求： -“声明”列表必须至少包含“颁发者”声明，该声明的值（作为 Microsoft Entra 颁发者 ID）以 `https://sts.windows.net/` 或 `https://login.microsoftonline.com/` 开头。 - 每个声明必须是单个字符串值，而不是值的数组。例如，可以有“Role”作为类型，“Developer”作为值的声明。不能有将“Role”作为类型并将值设置为“Developer”和“Program Manager”的声明。 - 声明值将限制为最大字符数。有关这些声明类型的详细信息，请参阅 Microsoft Entra 安全令牌中的声明。你还可以指定自己的声明类型和值。

以下示例显示了 PoP 令牌的信息：

若要添加其他声明，请从以下选项中进行选择：
- 若要添加其他声明类型，请选择“添加标准声明”，选择声明类型，并指定声明值。
- 若要添加你自己的声明，请选择“添加自定义声明”。有关详细信息，请查看如何向应用提供可选声明。然后，自定义声明将存储为 JWT ID 的一部分；例如 "tid": "aaaabbbb-0000-cccc-1111-dddd2222eeee"。
若要添加其他授权策略，请选择“添加策略”。重复前面的步骤以设置策略。
完成后，选择“保存”。
若要在基于请求的触发器输出中包含访问令牌的 Authorization 标头，请查看在请求和 HTTP Webhook 触发器输出中包含“Authorization”标头。

工作流属性（例如策略）不会显示在 Azure 门户上工作流的代码视图中。若要以编程方式访问策略，请通过 Azure 资源管理器调用以下 API：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。请务必替换 Azure 订阅 ID、资源组名称和工作流名称的占位符值。

在 ARM 模板中，按照以下步骤和语法定义授权策略：

在逻辑应用的资源定义的 properties 部分中，如果不存在任何 accessControl 对象，请添加一个包含 triggers 对象的该对象。

有关 accessControl 对象的详细信息，请查看限制 Azure 资源管理器模板中的入站 IP 范围和 Microsoft.Logic 工作流模板参考。
在 triggers 对象中，添加一个 openAuthenticationPolicies 对象，后者包含你在其中定义了一个或多个授权策略的 policies 对象。
提供授权策略的名称，将策略类型设置为 AAD，并包括一个 claims 数组，你在其中指定一个或多个声明类型。

claims 数组至少必须包含以下颁发者声明类型：你在其中将声明的 name 属性设置为 iss，并将 value 设置为以 https://sts.windows.net/ 或 https://login.microsoftonline.com/ 开头的 Microsoft Entra 颁发者 ID。有关这些声明类型的详细信息，请参阅 Microsoft Entra 安全令牌中的声明。你还可以指定自己的声明类型和值。
若要在基于请求的触发器输出中包含访问令牌的 Authorization 标头，请参阅在请求触发器输出中包含“Authorization”标头。

下面是要遵循的语法：

"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
],

在请求或 HTTP Webhook 触发器输出中包括“Authorization”标头

如果逻辑应用启用 Microsoft Entra ID OAuth 来授权入站调用访问基于请求的触发器，则你可以使请求触发器或 HTTP Webhook 触发器输出包含 OAuth 访问令牌的 Authorization 标头。在触发器的基础 JSON 定义中，添加 operationOptions 属性并将其设置为 IncludeAuthorizationHeadersInOutputs。下面是请求触发器的示例：

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

有关详细信息，请查看以下主题：

生成共享访问签名 (SAS) 密钥或令牌

当工作流以基于请求的触发器开头，并且首次保存该工作流时，Azure 逻辑应用在该触发器上创建可调用的终结点。此终结点具有可以接收入站调用或启动工作流的请求的 URL。 URL 包括共享访问签名 (SAS)，这是授予存储服务权限的密钥或令牌。此终结点 URL 使用以下格式：

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

例如，若要在"请求"触发器中查看此 URL，请查找触发器的 HTTP URL 属性：

屏幕截图显示 Azure 门户、消耗工作流设计器和请求触发器终结点 URL。

完整的 URL 如以下示例所示：

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 中的 SAS 具有查询参数，下表描述了这些参数：

查询参数	说明
`sp`	指定允许使用的 HTTP 方法的权限。
`sv`	指定用于生成签名的 SAS 版本。
`sig`	指定用于对触发器访问进行身份验证的签名。此签名是使用 SHA256 算法生成的，所有 URL 路径和属性中都包含机密访问密钥。此密钥保持机密和加密状态，使用逻辑应用进行存储，并且永远不会公开或发布。逻辑应用仅向那些包含有效签名（使用密钥创建）的触发器授权。

重要

请确保保护 SAS 密钥，就像保护帐户密钥免受未经授权的使用一样。设置或具有撤消已泄露访问密钥的计划。在分发使用访问密钥的 URI 时，使用自由裁量权，并且仅通过安全连接（如 HTTPS）分发此类 URI。请确保仅执行通过 HTTPS 连接使用访问密钥的操作。具有有效密钥的 URI 的任何人都可以访问关联的资源。为了维护安全性和保护对逻辑应用工作流的访问，请定期重新生成访问密钥，因为它们可能需要遵守安全策略或已遭到入侵。这样，就可以确保只有授权的请求才能触发工作流，从而防止数据和进程受到未经授权的访问。

如果使用 SAS 密钥访问存储服务，Microsoft 建议创建用户委派 SAS，该 SAS 使用Microsoft Entra ID 受到保护，而不是帐户密钥。

为了获得最佳安全性，Microsoft 建议尽可能随时使用具有托管标识的 Microsoft Entra ID 进行身份验证。此选项提供卓越的安全性，无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全，这样你就无需管理这种敏感信息了。若要为 Azure 逻辑应用设置托管标识，请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。

基于请求的触发器对终结点的入站调用只能使用一个授权方案，即 SAS 或使用 Microsoft Entra ID 的 OAuth 2.0 二者之一。尽管使用一个方案不会禁用另一个方案，但同时使用这两个方案会导致错误，因为逻辑应用服务不知道要选择哪个方案。

如果有消耗工作流是以“请求”触发器开头的，则可以禁用 SAS 身份验证。即使将授权限制为仅使用 Microsoft Entra ID 的 OAuth 2.0，此选项也可正常工作。对于标准工作流，无需禁用 SAS 即可使用其他身份验证类型。

有关使用 SAS 密钥时的安全性的详细信息，请参阅本指南中的以下部分：

重新生成访问密钥
创建具有到期日期的回调 URL
使用主密钥或辅助密钥创建 URL

禁用共享访问签名 (SAS) 身份验证（仅消耗）

默认情况下，基于请求的触发器已启用 SAS 身份验证。触发器的终结点 URL 包括一个 SAS，从查询参数 sp-<permissions>sv-<SAS-version>sig=<signature> 开始，例如：

如果消耗工作流以“请求”触发器开头，并且想要使用使用 Microsoft Entra ID 的 OAuth，则可以禁用 SAS 身份验证以避免运行工作流时出现错误和问题。还可以通过删除对机密的依赖项来添加安全层，从而降低记录或泄露机密的风险。

即使还启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用基于请求的终结点的唯一选项，此选项也可正常工作。对于标准工作流，无需禁用 SAS 即可使用其他身份验证类型。

注意

此操作将禁用传入请求的 SAS 身份验证，并阻止现有 SAS 密钥或签名正常工作。但是，如果再次启用 SAS 身份验证，SAS 密钥或签名仍然有效，仍会工作。若要通过创建新版本禁用 SAS 密钥和签名，请参阅重新生成访问密钥。

禁用 SAS 身份验证后，"请求"触发器的终结点 URL 不再包含 SAS 密钥，例如：

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

先决条件

对于此任务，需要一个发送 REST API 调用的工具，例如：

注意

对于具有敏感数据（例如凭据、机密、访问令牌、API 密钥和其他类似信息）的情况，请务必使用具有必要安全功能可保护数据的工具，该工具可脱机或本地工作，不会将数据同步到云，并且不需要登录联机帐户。这样可以降低向公众公开敏感数据的风险。

检查是否启用或禁用 SAS 的触发器

禁用 SAS 身份验证后，触发器的终结点 URL 不再包含 SAS 密钥。此外，消耗工作流定义包括 sasAuthenticationPolicy JSON 对象。此对象具有设置为 Disabled 的状态属性，例如：

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

若要查找已启用或禁用 SAS 的消耗工作流，请检查工作流定义是否包括 sasAuthenticationPolicy 对象，其中状态属性设置为“已禁用” 。

使用发送 REST API 调用的工具，通过运行 工作流 - 获取操作来获取有关您的工作流程的信息，例如使用以下 GET 请求：

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
获取工作流 - 获取操作的输出，并检查 sasAuthenticationPolicy 对象是否存在，其中状态属性设置为 Disabled。

将 sasAuthenticationPolicy 属性添加到工作流定义

对于想要禁用 SAS 身份验证的消耗工作流，请执行以下步骤：

如果尚未执行此操作，请通过运行 工作流 - 获取操作来获取有关您的工作流程的信息，例如使用以下 GET 请求：

GET https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
获取工作流 - 获取操作的输出，并手动添加以下元素：
1. 在 properties 对象中，添加包含 triggers 对象的 accessControl 对象（如果不存在）。
2. 在 triggers 对象中，添加一个 sasAuthenticationPolicy 对象，该对象包含设置为 Disabled 的 state 属性。
完成后，编辑的部件如以下示例所示：
```
"properties": {
    "accessControl": {
        "triggers": {
            "sasAuthenticationPolicy": {
                "state": "Disabled"
            }
        }
    }
}
```
通过使用以下 PATCH 请求，运行工作流 - 更新操作，以使用编辑的输出（用作请求正文中的输入）发送另一个请求，例如：

PATCH https://management.azure.com/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
在 Azure 门户中，转到设计器中的消耗工作流，并确认“请求”触发器的 URL 不再包含 SAS。
若要在逻辑应用资源级别启用使用 Microsoft Entra ID 的 Oauth 2.0，请为使用 Microsoft Entra ID 的 OAuth 2.0 添加授权策略。

有关详细信息，请参阅启用使用 Microsoft Entra ID 的 OAuth 2.0。

重新生成访问密钥

为了维护安全性和保护对逻辑应用工作流的访问，请定期重新生成访问密钥，因为它们可能需要遵守安全策略或已遭到入侵。这样，就可以确保只有授权的请求才能触发工作流，从而防止数据和进程受到未经授权的访问。

若要随时重新生成新的访问密钥，请使用 Azure REST API 或 Azure 门户。以前使用旧密钥生成的所有 URI 或 URL 已失效，不再有权触发逻辑应用工作流。重新生成后检索的 URI 将使用新访问密钥进行签名。

在 Azure 门户中，打开使用要重新生成的密钥的逻辑应用资源。
在逻辑应用资源菜单中的“设置”下，选择“访问密钥”。
选择要重新生成的密钥并完成生成过程。

重要

确保保护访问密钥，就像保护帐户密钥免受未经授权的使用一样。设置或具有撤消已泄露访问密钥的计划。在分发使用访问密钥的 URI 时，使用自由裁量权，并且仅通过安全连接（如 HTTPS）分发此类 URI。请确保仅执行通过 HTTPS 连接使用访问密钥的操作。具有有效密钥的 URI 的任何人都可以访问关联的资源。

如果使用 SAS 密钥访问存储服务，Microsoft 建议创建用户委派 SAS，该 SAS 使用Microsoft Entra ID 受到保护，而不是帐户密钥。

创建具有到期日期的回调 URL

如果与其他各方共享基于请求的触发器的终结点 URL，可以生成使用特定密钥并具有过期日期的回调 URL。这样，就可以无缝滚动更新密钥，或者根据特定的时间跨度将触发逻辑应用的访问限制。若要为 URL 指定到期日期，请使用 Azure 逻辑应用 REST API，例如：

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

在正文中，使用 JSON 日期字符串包含 NotAfter 属性。该属性返回仅在 NotAfter 日期和时间之前有效的回调 URL。

创建附带主密钥或辅助密钥的 URL

生成或列出基于请求的触发器的回调 URL 时，可以指定用于对 URL 进行签名的密钥。若要生成由特定密钥签名的 URL，请使用 Azure 逻辑应用 REST API，例如：

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

在正文中，包含值为 Primary 或 Secondary 的 KeyType 属性。此属性返回由指定的安全密钥签名的 URL。

通过 Azure API 管理公开逻辑应用工作流

有关更多身份验证协议和选项，请考虑使用 Azure API 管理将逻辑应用工作流公开为 API。此服务可为任何终结点提供丰富的监视、安全性、策略和文档功能。 API 管理可以公开逻辑应用的公共或专用终结点。若要授予对此终结点的访问权限，可以使用 Microsoft Entra ID OAuth、客户端证书或其他安全标准来实现授权。当 API Management 收到请求时，此服务会将请求发送到逻辑应用，并会进行任何必要的转换或限制。若要仅让 API 管理调用你的逻辑应用工作流，可以限制逻辑应用的入站 IP 地址。

有关详细信息，请参阅以下文档：

限制入站 IP 地址

除了共享访问签名 (SAS) 外，你还需要特别限制可调用逻辑应用工作流的客户端。例如，如果使用 Azure API 管理来管理请求终结点，则可将逻辑应用工作流限制为仅接受来自你创建的 API 管理服务实例的 IP 地址的请求。

无论指定的 IP 地址如何，都仍可通过工作流触发器 - 运行操作请求或 API 管理来运行具有基于请求的触发器的逻辑应用工作流。不过，这种情况下仍需要针对 Azure REST API 进行身份验证。所有事件都会显示在 Azure 审核日志中。请确保相应地设置访问控制策略。

若要限制逻辑应用工作流的入站 IP 地址，请针对 Azure 门户或 Azure 资源管理器模板执行相应步骤。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x

Portal
资源管理器模板

在 Azure 门户中，IP 地址限制会影响触发器和操作，这与门户中“允许的入站 IP 地址”下的说明相反。若要为触发器和操作单独设置此筛选器，请在 Azure 资源管理器模板中为逻辑应用资源使用 accessControl 对象，或使用 Azure 逻辑应用 REST API 中的 工作流 - 创建或更新 操作。

消耗型工作流

在 Azure 门户中，在工作流设计器中打开消耗逻辑应用。
在逻辑应用菜单的“设置”下，选择“工作流设置”。
在“访问控制配置”部分的“允许的入站 IP 地址”下，选择方案的路径：
- 若要通过 Azure 逻辑应用内置操作使工作流可供调用（但仅作为嵌套工作流进行调用），请选择“仅其他逻辑应用”。仅当使用 Azure 逻辑应用操作调用嵌套工作流时，此选项才有效。
  
  此选项会将一个空数组写入逻辑应用资源，并要求只有使用内置 Azure 逻辑应用操作的父工作流发出的调用才能触发嵌套工作流。
- 若要通过 HTTP 操作使工作流可供调用（但仅作为嵌套工作流进行调用），请选择“特定 IP 范围”。出现“触发器的 IP 范围”框时，请输入父工作流的出站 IP 地址。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x
  
  备注
  
  如果使用“仅限其他逻辑应用”选项和 HTTP 操作来调用嵌套工作流，调用将被阻止，并出现“401 未授权”错误。
- 如果你想要限制来自其他 IP 的入站调用，当“触发器的 IP 范围”框出现时，请指定触发器接受的 IP 地址范围。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x
（可选）在“仅限提供的 IP 地址发出从运行历史记录中获取输入和输出消息的调用”下，可以指定能够访问运行历史记录中输入和输出消息的入站调用的 IP 地址范围。

标准型工作流

在 Azure 门户中，打开你的标准逻辑应用资源。
在逻辑应用菜单的“设置”下，选择“网络”。
在“入站流量配置”部分，选择“公用网络访问”旁边的“启用且没有访问限制”。
在“访问限制”页上，在“应用访问”下，选择“从选择虚拟网络和 IP 地址启用”。
在“站点访问和规则”下，在“主站点”选项卡上，添加一个或多个规则以“允许”或“拒绝”来自特定 IP 范围的请求。有效的 IP 范围使用这些格式：x.x.x.x/x 或 x.x.x.x-x.x.x.x

有关详细信息，请参阅在 Azure 逻辑应用（标准型）中阻止入站 IP 地址。

消耗型工作流

在 ARM 模板中，在逻辑应用的资源定义中使用 accessControl 节指定允许的入站 IP 地址范围。在此节中，适当地使用 triggers、actions 和可选的 contents 节，方法是包含具有 addressRange 属性的 allowedCallerIpAddresses 节，并将属性值设置为 x.x.x.x/x 或 x.x.x.x-x.x.x.x 格式的允许 IP 范围。

如果嵌套逻辑应用工作流使用“仅限其他逻辑应用”选项（该选项仅允许来自使用内置 Azure 逻辑应用操作的其他逻辑应用的入站调用），请将 allowedCallerIpAddresses 属性设置为空数组 ([]) 并省略 addressRange 属性。
如果嵌套逻辑应用工作流对其他入站调用使用“特定 IP 范围”选项（例如，使用 HTTP 操作的其他逻辑应用工作流），请包含 allowedCallerIpAddresses 部分，并将 addressRange 属性设置为允许的 IP 范围。

此示例显示了一个嵌套工作流的逻辑应用资源定义，该工作流只允许来自使用内置 Azure 逻辑应用操作的其他逻辑应用工作流的入站调用：

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

此示例显示了一个嵌套工作流的逻辑应用资源定义，该工作流允许来自使用 Azure 操作的逻辑应用工作流的入站调用：

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

对其他服务和系统的出站调用的访问

根据目标终结点的功能，HTTP 触发器或 HTTP 操作发送的出站调用支持加密，并使用传输层安全性 (TLS) 1.0、1.1 或 1.2（以前称为安全套接字层 (SSL)）进行保护。 Azure 逻辑应用会就是否使用受支持的最高可能版本一事与目标终结点进行协商。例如，如果目标终结点支持 1.2 版，则 HTTP 触发器或操作会首先使用 1.2 版。否则，连接器将使用下一个受支持的最高版本。

此列表包括有关 TLS/SSL 自签名证书的信息：

对于多租户 Azure 逻辑应用环境中的消耗型逻辑应用工作流，HTTP 操作不允许自签名的 TLS/SSL 证书。如果你的逻辑应用向服务器发出 HTTP 调用并提供了 TLS/SSL 自签名证书，则 HTTP 调用将失败并出现 TrustFailure 错误。
对于单租户 Azure 逻辑应用环境中的标准逻辑应用工作流，HTTP 操作支持自签名的 TLS/SSL 证书。但是，必须为此身份验证类型完成一些额外的步骤。否则，调用会失败。有关详细信息，请参阅单租户 Azure 逻辑应用的 TLS/SSL 证书身份验证。

如果要将客户端证书或 Microsoft Entra ID OAuth 与“证书”凭据类型一起使用，则仍必须为此身份验证类型完成一些额外的步骤。否则，调用会失败。有关详细信息，请参阅单租户 Azure 逻辑应用的客户端证书或凭据类型为“证书”的 Microsoft Entra ID OAuth。

下面提供了更多方法，它们有助于保护对逻辑应用工作流发送的调用进行处理的终结点：

针对出站请求添加身份验证。

当使用 HTTP 触发器或操作来发送出站调用时，可以针对逻辑应用发送的请求添加身份验证。例如，可以选择以下身份验证类型：
限制来自逻辑应用工作流 IP 地址的访问。

从逻辑应用工作流对终结点进行的所有调用都源自基于逻辑应用所在区域的具体指定 IP 地址。可以添加仅接受来自这些 IP 地址的请求的筛选规则。若要获取这些 IP 地址，请查看 Azure 逻辑应用的限制和配置。
提高与本地系统的连接的安全性。

Azure 逻辑应用可与这些服务集成，来帮助提供更安全可靠的本地通信。
- 本地数据网关
  
  Azure 逻辑应用中的许多托管连接器都可以安全连接到本地系统，例如，文件系统、SQL、SharePoint 和 DB2。网关通过 Azure 服务总线发送来自加密通道上的本地源的数据。所有流量最初都是网关代理的安全出站流量。了解本地数据网关的工作原理。
- 通过 Azure API 管理进行连接
  
  Azure API 管理提供本地连接选项，例如站点到站点虚拟专用网络和 ExpressRoute 集成，用于保护代理和与本地系统的通信。如果你有一个可访问本地系统的 API，并通过创建 API 管理服务实例公开了该 API，那么可以在工作流设计器中选择相应的 API 管理操作，从逻辑应用的工作流中调用该 API。
  
  注意
  
  连接器仅显示那些你有权在其中进行查看和连接操作的 API 管理服务，但不显示基于消耗的 API 管理服务。
  
  根据逻辑应用资源类型，执行相应的步骤：
  
  消耗型工作流
  1. 根据要添加的是 API 管理触发器还是操作，请按照以下步骤操作：
    - 触发器：
      1. 在工作流设计器上，选择“添加触发器”。
      2. “添加触发器”窗格打开后，在搜索框中输入“API 管理”。
      3. 从触发器结果列表中选择”选择 Azure API 管理触发器”。
    - 操作：
      1. 在工作流设计器上，选择要在其中添加操作的加号 (+)。
      2. “添加操作”窗格打开后，在搜索框中输入“API 管理”。
      3. 从操作结果列表中选择”选择 Azure API 管理操作”。
    以下示例演示如何查找 Azure API 管理触发器：
  2. 从 API 管理服务实例列表中，选择之前创建的 API 管理服务实例。
  3. 从 API 操作列表中选择要调用的 API 操作，然后选择“添加操作”。
  标准型工作流
  
  对于标准工作流，只能添加“API 管理”操作，而不能添加触发器。
  1. 在工作流设计器上，选择要在其中添加操作的加号 (+)。
  2. “添加操作”窗格打开后，在搜索框中输入“API 管理”。
  3. 从操作结果列表中选择”调用 Azure API 管理 API”。
  4. 从 API 管理服务实例列表中，选择之前创建的 API 管理服务实例。
  5. 从 API 操作列表中选择要调用的 API 操作，然后选择“新建”。

针对出站调用添加身份验证

HTTP 和 HTTPS 终结点支持各种身份验证。在用于向这些终结点发送出站调用或请求的某些触发器和操作上，可以指定身份验证类型。在工作流设计器中，支持选择身份验证类型的触发器和操作具有“身份验证”属性。但是，此属性可能并不总会默认显示。在这种情况下，请在触发器或操作中打开“高级参数”列表，然后选择“身份验证”。

重要

若要保护你的逻辑应用工作流处理的敏感信息，请使用受保护的参数，并根据需要对数据进行编码。有关使用和保护参数的详细信息，请查看对参数输入的访问。

基本身份验证

对于 HTTP 调用，基本身份验证使用 base64 编码的字符串，其中包含用户名和密码发出请求。除非将此选项用于 HTTPS/SSL 协议，否则此方法传输不加密的凭据，并带来更高的安全风险。

重要

如果基本选项可用并选中，请指定以下属性值：

属性（设计器）	属性 (JSON)	必须	值	说明
身份验证	`type`	是	基本	要使用的身份验证类型
用户名	`username`	是	<user-name>	用于对目标服务终结点访问进行身份验证的用户名
密码	`password`	是	<password>	用于对目标服务终结点访问进行身份验证的密码

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 Azure 资源管理器模板中，可以使用表达式在运行时访问这些参数值。此示例 HTTP 操作定义将身份验证 type 指定为 Basic，并使用 parameters() 函数获取参数值：

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

客户端证书身份验证

客户端证书身份验证允许或要求用户使用 X.509 证书直接向其 Microsoft Entra ID 进行身份验证，以便应用程序和浏览器登录。此功能可帮助你采用防钓鱼身份验证，并使用针对公钥基础结构 (PKI) 的 X.509 证书进行身份验证。

重要

如果客户端证书选项可用并选择，请指定以下属性值：

属性（设计器）	属性 (JSON)	必须	值	说明
身份验证	`type`	是	客户端证书或 `ClientCertificate`	可使用的身份验证类型。可以使用 Azure API 管理来管理证书。注意：对于入站和出站调用，自定义连接器不支持基于证书的身份验证。
Pfx	`pfx`	是	<encoded-pfx-file-content>	个人信息交换 (PFX) 文件中的 base64 编码内容若要将 PFX 文件转换为 base64 编码格式，可以使用 PowerShell 7 并执行以下步骤： 1.将证书内容保存到某个变量中： `$pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx')` 2.使用 `ToBase64String()` 函数转换证书内容，并将该内容保存到某个文本文件中： `[System.Convert]::ToBase64String($pfx_cert) \| Out-File 'pfx-encoded-bytes.txt'` 故障排除：如果使用 `cert mmc/PowerShell` 命令，可能会出现以下错误： `Could not load the certificate private key. Please check the authentication certificate password is correct and try again.` 若要解决此错误，请尝试使用 `openssl` 命令将 PFX 文件转换为 PEM 文件，再转换回来： `openssl pkcs12 -in certificate.pfx -out certificate.pem` `openssl pkcs12 -in certificate.pem -export -out certificate2.pfx` 然后，在获得证书的新转换 PFX 文件的 base64 编码字符串后，便可以在 Azure 逻辑应用中使用该字符串。
密码	`password`	否	<password-for-pfx-file>	用于访问 PFX 文件的密码

注意

如果尝试使用 OpenSSL 通过客户端证书进行身份验证，可能会收到以下错误：

BadRequest: Could not load private key

若要解决此错误，请执行以下步骤：

卸载所有 OpenSSL 实例。
安装 OpenSSL 版本 1.1.1t。
使用新的更新重新为证书签名。
使用客户端证书身份验证时，将新证书添加到 HTTP 操作。

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 Azure 资源管理器模板中，可以使用表达式在运行时访问这些参数值。此示例 HTTP 操作定义将身份验证 type 指定为 ClientCertificate，并使用 parameters() 函数获取参数值：

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

重要

如果你在单租户 Azure 逻辑应用中具有标准逻辑应用资源，并且想要使用带有 TSL/SSL 证书、客户端证书或凭据类型为 Certificate 的 Microsoft Entra ID Open Authorization (Microsoft Entra ID OAuth)，请确保为此身份验证类型完成额外的设置步骤。否则，调用会失败。有关详细信息，请参阅单租户环境中的身份验证。

有关使用客户端证书身份验证保护服务的详细信息，请查看以下主题：

Microsoft Entra 平台

在请求触发器上，可以在为逻辑应用设置 Microsoft Entra 授权策略后，使用 Microsoft Entra 平台对传入调用进行身份验证。

重要

对于支持 Active Directory OAuth（使用 Microsoft Entra ID 的 OAuth 2.0）身份验证类型的所有其他触发器和操作，请指定以下属性值：

属性（设计器）	属性 (JSON)	必须	值	说明
身份验证	`type`	是	Active Directory OAuth（使用 Microsoft Entra ID 的 OAuth 2.0）或 `ActiveDirectoryOAuth`	可使用的身份验证类型。 Azure 逻辑应用当前遵循 OAuth 2.0 协议。
颁发机构	`authority`	否	<URL-for-authority-token-issuer>	提供访问密钥的颁发机构的 URL，例如 Azure 全球服务区域的 `https://login.microsoftonline.com/`。对于其他国家云，请查看 Microsoft Entra 身份验证终结点 - 选择标识颁发机构。
租户	`tenant`	是	<tenant-ID>	Microsoft Entra 租户的租户 ID。
受众	`audience`	是	<resource-to-authorize>	要用于授权的资源，例如 `https://management.core.windows.net/`
客户端 ID	`clientId`	是	<client-ID>	请求授权的应用的客户端 ID
凭据类型	`credentialType`	是	证书或机密	客户端用来请求授权的凭据类型。此属性和值不会显示在逻辑应用的基础定义中，但确定了为选定凭据类型显示的属性。
机密	`secret`	是，但仅适用于“机密”凭据类型	<client-secret>	用于请求授权的客户端密码
Pfx	`pfx`	是，但仅适用于“证书”凭据类型	<encoded-pfx-file-content>	个人信息交换 (PFX) 文件中的 base64 编码内容
密码	`password`	是，但仅适用于“证书”凭据类型	<password-for-pfx-file>	用于访问 PFX 文件的密码

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 Azure 资源管理器模板中，可以使用表达式在运行时访问这些参数值。此示例 HTTP 操作定义将身份验证 type 指定为 ActiveDirectoryOAuth，将凭据类型指定为 Secret，并使用 parameters() function 获取参数值：

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

重要

如果在单租户 Azure 逻辑应用中有标准逻辑应用资源，并且想要使用带有 TSL/SSL 证书、客户端证书或凭据类型为 Certificate 的 Microsoft Entra ID OAuth，请确保为此身份验证类型完成额外的设置步骤。否则，调用会失败。有关详细信息，请参阅单租户环境中的身份验证。

原始身份验证

如果原始选项可用，在必须使用不遵循 OAuth 2.0 协议的身份验证方案时，可以使用此身份验证类型。使用此类型可以手动创建要与传出请求一起发送的授权标头值，并指定触发器或操作中的标头值。

重要

以下示例显示了遵循 OAuth 1.0 协议的 HTTPS 请求的示例标头：

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"

在支持原始身份验证的触发器或操作中指定以下属性值：

属性（设计器）	属性 (JSON)	必须	值	说明
身份验证	`type`	是	原始	要使用的身份验证类型
值	`value`	是	<authorization-header-value>	要用于身份验证的授权标头值

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 Azure 资源管理器模板中，可以使用表达式在运行时访问这些参数值。此示例 HTTP 操作定义将身份验证 type 指定为 Raw 并使用 parameters() function 获取参数值：

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

托管标识身份验证

当托管标识选项可用于支持托管标识身份验证的触发器或操作时，逻辑应用可以使用此标识，对访问受 Microsoft Entra ID 保护的 Azure 资源的操作进行身份验证，而无需使用凭据、机密或 Microsoft Entra 令牌。你无需管理机密或直接使用 Microsoft Entra 令牌，Azure 会为你管理此标识，并且会帮助你保护凭据。详细了解支持使用托管标识进行 Microsoft Entra 身份验证的 Azure 服务。

“消耗”逻辑应用资源可以使用系统分配的标识或单个手动创建的用户分配标识。
“标准”逻辑应用资源支持具有系统分配的托管标识并同时启用多个用户分配的托管标识，不过，你任何时候都还是只能选择一个标识。

注意

在默认情况下，已启用系统分配的标识，以便在运行时对连接进行身份验证。该标识与你在创建连接时使用的身份验证凭据或连接字符串不同。如果禁用该标识，则运行时连接无效。若要查看此设置，请在逻辑应用菜单的“设置”下，选择“标识”。

在逻辑应用可以使用托管标识之前，请按照使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问进行身份验证中的步骤进行操作。这些步骤将在逻辑应用上启用托管标识，并设置该标识对目标 Azure 资源的访问权限。
在 Azure 函数可以使用托管标识之前，请先为 Azure 函数启用身份验证。

在支持使用托管标识的触发器或操作中提供以下信息：

内置触发器和操作

属性（设计器）	属性 (JSON)	必须	值	说明
身份验证	`type`	是	托管标识或 `ManagedServiceIdentity`	要使用的身份验证类型
托管标识	`identity`	否	<user-assigned-identity-ID>	要使用的用户分配的托管标识。注意：使用系统分配的托管标识时，请勿包含此属性。
受众	`audience`	是	<target-resource-ID>	要访问的目标资源的资源 ID。例如，`https://storage.azure.com/` 使用于身份验证的访问令牌对所有存储帐户都有效。但是，还可以为特定存储帐户指定根服务 URL，如 `https://fabrikamstorageaccount.blob.core.windows.net`。注意：“受众”属性可能已在某些触发器或操作中隐藏。若要显示此属性，请在触发器或操作中打开“高级参数”列表，然后选择“受众”。重要提示：请确保此目标资源 ID 与 Microsoft Entra ID 所需的值完全匹配，包括所有必要的尾部斜杠。因此，所有 Azure Blob 存储帐户的 `https://storage.azure.com/` 资源 ID 都需要尾部反斜杠。但是，特定存储帐户的资源 ID 不需要尾部反斜杠。若要查找这些资源 ID，请查看支持 Microsoft Entra ID 的 Azure 服务。

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 Azure 资源管理器模板中，可以使用表达式在运行时访问这些参数值。例如，此 HTTP 操作定义将身份验证 type 指定为 ManagedServiceIdentity，并使用 parameters() 函数获取参数值：

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

托管连接器触发器和操作

属性（设计器）	必须	值	说明
连接名称	是	<connection-name>
托管的标识	是	系统分配的托管标识或 <用户分配的托管标识名称>	要使用的身份验证类型

阻止创建连接

如果组织不允许使用 Azure 逻辑应用中的连接器连接到特定资源，则可以在逻辑应用工作流中使用 Azure Policy 阻止为特定连接器创建这些连接的功能。有关详细信息，请查看在 Azure 逻辑应用中阻止特定连接器创建的连接。

逻辑应用隔离指导

你可以在 Azure 政府中使用 Azure 逻辑应用支持 Azure 政府影响级别 5 隔离指导中所述区域的所有影响级别。为了满足这些要求，Azure 逻辑应用支持在具有专用资源的环境中创建和运行工作流的功能，因此你可以减轻逻辑应用中其他 Azure 租户造成的性能影响，并避免与其他租户共享计算资源。
标准逻辑应用工作流可以通过为入站流量设置的专用终结点和为出站流量设置的虚拟网络集成，与 Azure 虚拟网络进行私密且安全的通信。有关详细信息，请参阅使用专用终结点保护虚拟网络和单租户 Azure 逻辑应用之间的流量。
若要运行自己的代码或执行 XML 转换，请创建并调用一个 Azure 函数，而不要使用内联代码功能或提供用作映射的程序集。此外，为函数应用设置托管环境，以符合隔离要求。

例如，若要满足影响级别 5 要求，请使用“隔离”定价层以及同样也使用“隔离”定价层的应用服务环境 (ASE)，在应用服务计划中创建函数应用。在此环境中，函数应用将在专用的 Azure 虚拟机和专用的 Azure 虚拟网络中运行，这些资源在计算隔离的基础上为应用提供网络隔离，并提供最大程度的横向扩展功能。

有关详细信息，请查看以下文档：

有关隔离的详细信息，请参阅以下文档：

通过

保护 Azure 逻辑应用中工作流的访问和数据

对逻辑应用操作的访问

消耗型工作流

标准型工作流

对运行历史记录数据的访问

按 IP 地址范围限制访问

消耗型工作流

标准型工作流

使用模糊处理保护运行历史记录中的数据

保护输入和输出时的注意事项

保护设计器中的输入和输出

保护代码视图中的输入和输出

对参数输入的访问

在工作流定义中保护参数（消耗型工作流）

在 Azure 资源管理器模板中保护参数（消耗型工作流）

支持身份验证的连接器的身份验证类型

对基于请求的触发器的入站调用的访问

启用使用 Microsoft Entra ID 的 OAuth 2.0

启用 使用 Microsoft Entra ID 的 OAuth 2.0 之前的注意事项

启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用请求终结点的唯一选项（仅消耗）

获取所有权证明 (PoP) 令牌

为消耗逻辑应用资源启用使用 Microsoft Entra ID 的 OAuth

在请求或 HTTP Webhook 触发器输出中包括“Authorization”标头

生成共享访问签名 (SAS) 密钥或令牌

禁用共享访问签名 (SAS) 身份验证（仅消耗）

先决条件

检查是否启用或禁用 SAS 的触发器

将 sasAuthenticationPolicy 属性添加到工作流定义

重新生成访问密钥

创建具有到期日期的回调 URL

创建附带主密钥或辅助密钥的 URL

通过 Azure API 管理公开逻辑应用工作流

限制入站 IP 地址

消耗型工作流

标准型工作流

对其他服务和系统的出站调用的访问

针对出站调用添加身份验证

基本身份验证

客户端证书身份验证

Microsoft Entra 平台

原始身份验证

托管标识身份验证

阻止创建连接

逻辑应用隔离指导

相关内容

反馈

其他资源

启用使用 Microsoft Entra ID 的 OAuth 2.0 之前的注意事项