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

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

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

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

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

• Azure 加密概述
• Azure 静态数据加密

对逻辑应用操作的访问

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

消耗型工作流

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

要防止他人更改或删除逻辑应用工作流，可以使用 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 资源管理器模板中的消费型或标准逻辑应用的步骤：

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

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

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

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

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

• 遮盖触发器或操作的输入或输出时，Azure 逻辑应用不会将安全数据发送到 Azure Log Analytics。 此外，不能将跟踪的属性添加到该触发器或操作进行监视。

• 用于处理工作流历史记录的 Azure 逻辑应用 API 不返回安全输出。

• 若要保护可遮盖输入或显式遮盖输出的操作的输出，请在该操作中手动打开“安全输出”。

• 请确保在你希望运行历史记录来遮盖该数据的下游操作中打开“安全输入”或“安全输出” 。

  安全输出设置

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

  

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

  

  安全输入设置

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

  

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

  

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

1. 在 Azure 门户中，打开设计器的逻辑应用工作流。

2. 在设计器上，选择要在其中保护敏感数据的触发器或操作。

3. 在打开的信息窗格中，选择“设置”，然后展开“安全性”。

   

4. 打开“安全输入”和/或“安全输出” 。

   

   触发器或操作现在显示标题栏中的锁图标。 表示以前操作的安全输出的令牌也显示锁图标。 例如，在后续操作中，为动态内容列表中的安全输出选择令牌后，该令牌将显示一个锁图标。

   

5. 运行工作流后，可以查看该运行的历史记录。

   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>') 表达式。 此表达式仅在运行时进行计算，由工作流定义语言描述。

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

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

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

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

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

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

若要在逻辑应用的工作流定义中保护敏感信息，请使用安全的参数，使该信息在保存逻辑应用工作流后不可见。 例如，假设某个 HTTP 操作需要使用用户名和密码进行基本身份验证。 在工作流定义中，parameters 节使用 securestring 类型定义 basicAuthPasswordParam 和 basicAuthUsernameParam 参数。 然后，操作定义将引用 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 资源管理器模板中保护参数（消耗型工作流）

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

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

• 在模板的最高级别，parameters 节定义了模板在部署时使用的值的参数。 例如，这些值可能包含特定部署环境的连接字符串。 然后，你可将这些值存储在单独的参数文件中，以方便更改这些值。

• 在逻辑应用的资源定义内部、工作流定义外部，parameters 节指定了工作流定义参数的值。 在此节中，可以使用引用模板参数的模板表达式来分配这些值。 这些表达式将在部署时计算。

• 在工作流定义中，parameters 部分定义了逻辑应用工作流在运行时使用的参数。 然后，你可以使用在运行时计算的工作流定义表达式，在逻辑应用工作流中引用这些参数。

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

{
   "$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]",
            "chinaeast",
            "chinanorth",
            "chinaeast2",
            "chinanorth2",
	    "chinanorth3"
         ],
         "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": {}
}

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

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

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

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

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

• 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

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

• 启用使用 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.chinacloudapi.cn/ 或 https://login.chinacloudapi.cn/ (OAuth V2) 开头。

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

  {
      "aud": "https://management.core.chinacloudapi.cn/",
      "iss": "https://sts.chinacloudapi.cn/<Azure-AD-issuer-ID>/",
      "iat": 1582056988,
      "nbf": 1582056988,
      "exp": 1582060888,
      "_claim_names": {
         "groups": "src1"
      },
      "_claim_sources": {
         "src1": {
            "endpoint": "https://graph.chinacloudapi.cn/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) 身份验证，此选项也能正常工作。

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

   注意

   此步骤使 Authorization 标头在工作流的运行历史记录和触发器的输出中可见。

2. 在 Azure 门户中，打开设计器中的消耗工作流。

3. 在设计器上，选择触发器。 在打开的信息窗格中，选择“设置”。

4. 在“常规”>“触发条件”下，选择“添加”。 在“触发条件”框中，根据要使用的令牌类型输入以下表达式之一：

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

   -或-

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

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

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

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

• 使用自己的标识调用受保护 Web API 的 .NET Core 守护程序控制台应用程序

• SignedHttpRequest，也称为 PoP（所有权证明）

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

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

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

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

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

• 触发器和操作类型的架构参考 - 请求触发器
• 触发器和操作类型的架构参考 - HTTP Webhook 触发器
• 触发器和操作类型的架构参考 - 操作选项

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

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

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

例如，若要在"请求"触发器中查看此 URL，请查找触发器的 HTTP 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 具有查询参数，下表描述了这些参数：

基于请求的触发器对终结点的入站调用只能使用一个授权方案，即 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> 开始，例如：

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

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

即使还启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用基于请求的终结点的唯一选项，此选项也可正常工作。 对于标准工作流，无需禁用 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 调用的工具，例如：

• Visual Studio Code，具有来自 Visual Studio Marketplace 的扩展
• PowerShell Invoke-RestMethod
• Bruno
• curl

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

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

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

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

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

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

2. 获取工作流 - 获取操作的输出，并检查 sasAuthenticationPolicy 对象是否存在，其中状态 属性设置为 Disabled。

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

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

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

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

2. 获取工作流 - 获取操作的输出，并手动添加以下元素：

   1. 在 properties 对象中，添加包含 triggers 对象的 accessControl 对象（如果不存在）。

   2. 在 triggers 对象中，添加一个 sasAuthenticationPolicy 对象，该对象包含设置为 Disabled 的 state 属性。

   完成后，编辑的部件如以下示例所示：

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

3. 通过使用以下 PATCH 请求，运行 工作流 - 更新操作，以使用编辑的输出（用作请求正文中的输入）发送另一个请求，例如：

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

4. 在 Azure 门户中，转到设计器中的消耗工作流，并确认“请求”触发器的 URL 不再包含 SAS。

5. 若要在逻辑应用资源级别启用使用 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 将使用新访问密钥进行签名。

1. 在 Azure 门户中，打开使用要重新生成的密钥的逻辑应用资源。

2. 在逻辑应用资源菜单中的“设置”下，选择“访问密钥”。

3. 选择要重新生成的密钥并完成生成过程。

创建具有到期日期的回调 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 地址。

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

• 关于 API 管理
• 在 Azure API 管理中使用 OAuth 2.0 授权和 Microsoft Entra ID 保护 Web API 后端
• 使用 API 管理中的客户端证书身份验证确保 API 安全
• API 管理身份验证策略

限制入站 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

{
   "$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": "China North",
   "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 触发器或操作来发送出站调用时，可以针对逻辑应用发送的请求添加身份验证。 例如，可以选择以下身份验证类型：

  • 基本身份验证

  • 客户端证书身份验证

  • Active Directory OAuth（使用 Microsoft Entra ID 的 OAuth 2.0）身份验证

  • 托管标识身份验证

• 限制来自逻辑应用工作流 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 协议，否则此方法传输不加密的凭据，并带来更高的安全风险。

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

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 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 证书进行身份验证。

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

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 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 API 管理中的客户端证书身份验证提高 API 的安全性
• 使用 Azure API 管理中的客户端证书身份验证提高后端服务的安全性
• 应用程序身份验证的证书凭据
• 在 Azure 应用服务中通过代码使用 TLS/SSL 证书

Microsoft Entra 平台

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

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

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 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.chinacloudapi.cn/",
         "clientId": "@parameters('clientIdParam')",
         "credentialType": "Secret",
         "secret": "@parameters('secretParam')"
     }
   },
   "runAfter": {}
}

原始身份验证

如果原始选项可用，在必须使用不遵循 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"

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

使用安全参数处理和保护敏感信息时，例如，在用于自动执行部署的 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 服务。

• “消耗”逻辑应用资源可以使用系统分配的标识或单个手动创建的用户分配标识。

• “标准”逻辑应用资源支持具有系统分配的托管标识并同时启用多个用户分配的托管标识，不过，你任何时候都还是只能选择一个标识。

  注意

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

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

2. 在 Azure 函数可以使用托管标识之前，请先为 Azure 函数启用身份验证。

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

   内置触发器和操作

   属性（设计器）	属性 (JSON)	必须	值	说明
   身份验证	type	是	托管标识 或 ManagedServiceIdentity	要使用的身份验证类型
   托管标识	identity	否	<user-assigned-identity-ID>	要使用的用户分配的托管标识。 注意：使用系统分配的托管标识时，请勿包含此属性。
   受众	audience	是	<target-resource-ID>	要访问的目标资源的资源 ID。 例如，https://storage.azure.com/ 使用于身份验证的访问令牌对所有存储帐户都有效。 但是，还可以为特定存储帐户指定根服务 URL，如 https://fabrikamstorageaccount.blob.core.chinacloudapi.cn。 注意：“受众”属性可能已在某些触发器或操作中隐藏。 若要显示此属性，请在触发器或操作中打开“高级参数”列表，然后选择“受众”。 重要提示：请确保此目标资源 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.chinacloudapi.cn/"
         },
      },
      "runAfter": {}
   }
   

   托管连接器触发器和操作

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

阻止创建连接

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

相关内容

• Azure 逻辑应用的 Azure 安全基线
• 自动化 Azure 逻辑应用的部署
• 监视逻辑应用