在 Azure 逻辑应用中确保工作流访问和数据的安全

Azure 逻辑应用 通过使用 Azure 存储 存储并自动加密静态数据。 这种加密通过使用Microsoft管理的密钥保护您的数据，帮助您实现组织的安全和合规承诺。 有关详细信息，请参阅静态数据的 Azure 存储加密。

本指南展示了如何在 Azure 逻辑应用 的以下主要领域进一步保护和保护敏感数据：

有关Azure范围安全的信息，请参见：

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

使用 Azure RBAC 安全地访问逻辑应用操作

在 Azure 中，基于角色的访问控制（RBAC）控制谁有权限和访问资源。 在别人创建或管理逻辑应用、工作流和连接之前，你需要先分配一个提供必要权限的角色。 你可以设置权限，只有特定用户或组能执行特定任务，比如管理、编辑和查看逻辑应用。 为了控制他们的权限，可以为有权访问你 Azure 订阅的成员分配内置或自定义的角色。

Azure 逻辑应用 具有以下特定角色，具体取决于你使用的是消耗型工作流还是标准型工作流：

消耗型工作流

举个例子，假设你需要使用一个你没创建的逻辑应用工作流程，并验证该逻辑应用工作流程中使用的连接。 您的 Azure 订阅需要对包含该逻辑应用资源的资源组拥有 贡献者 权限。 如果你创建了 Logic 应用资源，你会自动获得 贡献者 访问权限。

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

标准工作流

访问工作流程运行历史

在工作流运行过程中，所有数据在 传输过程中 通过传输层安全（TLS）和 静止状态进行加密。 逻辑应用运行完成后，您可以查看此运行的历史记录，包括所执行步骤的状态、持续时间、输入和输出。 此丰富的详细信息可让你深入了解逻辑应用的运行方式，以及开始解决出现的任何问题的位置。

查看逻辑应用的运行历史记录时，Azure 逻辑应用会验证访问权限，然后提供指向每个运行的请求和响应的输入和输出的链接。 但是，对于处理任何密码、机密、密钥或其他敏感信息的操作，你需要阻止他人查看和访问该数据。 例如，如果逻辑应用从 Azure 密钥保管库 获取机密，以便在对 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.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 3",
   "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 逻辑应用会隐藏运行历史记录中的此操作的输入，但不会启用操作的“安全输入”设置。

  

  Compose、Parse JSON 和响应操作仅具有安全输入设置。 启用后，此设置也会隐藏这些操作的输出。 如果这些操作显式使用上游安全输出作为输入，则 Azure 逻辑应用会隐藏这些操作的输入和输出，但不会启用这些操作的“安全输入”设置。 如果下游操作显式使用 Compose、Parse JSON 或响应操作的隐藏输出作为输入，Azure 逻辑应用不会隐藏此下游操作的输入和输出。

  

  安全输入设置

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

  

  如果 Compose、Parse JSON 和 Response 动作显式使用了具有安全输入的触发器或动作的可见输出，Azure 逻辑应用 会隐藏这些动作的输入和输出，但不会启用这些动作的 Secure Inputs 设置。 如果下游操作显式使用 Compose、Parse 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 密钥保管库 检索这些机密的受保护模板参数。 然后，可以在参数文件中引用密钥保管库和秘密。 有关详细信息，请参见:

• 在部署时通过使用 Azure 密钥保管库 传递敏感值。
• 本文后面的部分会提到Azure 资源管理器 模板中的安全参数。

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

若要保护逻辑应用的工作流定义中的敏感信息，请使用受保护的参数，以便在保存逻辑应用工作流后此信息不可见。 例如，假设你有一个需要基本认证的HTTP操作，使用用户名和密码。 在工作流定义中，parameters 节使用 basicAuthPasswordParam 类型定义 basicAuthUsernameParam 和 securestring 参数。 然后，操作定义在 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 密钥保管库 中，并使用 参数文件 引用密钥保管库和机密。 然后，模板会在部署时检索该信息。 有关详细信息，请参阅 使用 Azure 密钥保管库 在部署时传递敏感值。

此列表包含有关以下 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]",
            "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。

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

• 启用 OAuth with Microsoft Entra ID。
• 生成共享访问签名（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 逻辑应用会生成错误，因为服务不知道要选择哪个方案。 如果你的 Consumption 工作流以 请求 触发器开头，则可以 禁用 SAS 身份验证，并 限制授权仅限使用 Microsoft Entra ID 的 OAuth 2.0。 对于标准工作流，无需禁用 SAS 即可使用其他身份验证类型。

• Azure 逻辑应用支持Microsoft Entra ID OAuth 访问令牌的 持有者类型 或 所有权证明类型（仅限消耗逻辑应用） 授权方案。 但是，Authorization访问令牌的标头必须指定 Bearer 类型或 PoP 类型。 有关如何获取和使用 PoP 令牌的详细信息，请参阅 获取所有权证明（PoP）令牌。

• 您的消费逻辑应用资源受到授权策略数量上限的限制。 每个授权策略还具有最大声明数。 有关详细信息，请参阅 Azure 逻辑应用的限制和配置。

• 授权政策必须至少包含 发行人 和 受众 权利要求。 发行者声明的值以 https://sts.chinacloudapi.cn/ 或 https://login.chinacloudapi.cn/（OAuth V2）开头，作为 Microsoft Entra ID 的颁发者。 受众声明有一个值，即你的逻辑应用资源的预期受众。

  例如，假设逻辑应用资源具有一个授权策略，该策略需要两种声明类型： 受众 和 颁发者。 解码的访问令牌的此示例有效负载部分包括两种声明类型，其中 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 作为调用请求终结点的唯一选项

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

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

   注意

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

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

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

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

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

   -或者-

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

如果你在没有正确的授权的情况下调用触发器端点，运行历史会将该触发器显示为 Skipped，且没有任何消息表明触发条件已失败。

获取所有权证明（PoP）令牌

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

• 一个 .NET Core 守护进程控制台应用程序调用具有自身身份的受保护 Web API。

• 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。 尽管使用一个方案不会禁用另一种方案，但如果同时使用这两种方案，Azure 逻辑应用会生成错误，因为该服务不知道要选择哪个方案。

如果拥有一个以请求触发器开头的消费工作流，则可以禁用 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

如果工作流以请求触发器开头，并且想要将 OAuth 与Microsoft Entra ID一起使用，则可以禁用 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

禁用SAS认证的前提条件

要禁用基于请求的触发器的SAS认证，你需要一个工具发送REST API调用，例如：

• Visual Studio Code，配有从 Visual Studio Marketplace 获取的扩展
• PowerShell Invoke-RestMethod
• 布鲁诺
• curl

检查触发器在启用或禁用 SAS 时的状态

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

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

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

1. 借助发送 REST API 调用的工具，通过运行 Workflows - Get 操作，使用以下 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. 如果尚未这样做，请通过运行Workflows - Get 操作获取有关工作流的信息，方法是使用以下 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. 从Workflows - Get操作获取输出，并手动添加以下元素：

   1. 如果不存在 properties 对象，在 accessControl 对象中添加一个包含 properties 对象的 对象。

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

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

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

3. 执行 工作流 - 更新 操作 时，使用以下 PUT 请求发送另一个请求，以更新您的工作流程，采用编辑后的输出作为请求正文中的输入，例如：

   PUT 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 属性。 该属性返回的回调 URL 仅在 NotAfter 日期和时间之前有效。

使用主密钥或辅助密钥创建 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

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

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

有关更多身份验证协议和选项，请考虑使用 Azure API 管理将逻辑应用工作流公开为 API。 此服务为任何终结点提供丰富的监视、安全、策略和文档功能。 API 管理可以为逻辑应用公开公共或专用终结点。 若要授权访问此终结点，可以将 OAuth 与 Microsoft Entra ID、客户端证书或其他安全标准一起使用。 当 API 管理收到请求时，服务会将请求发送到逻辑应用，并在此过程中进行任何必要的转换或限制。 若要仅让 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.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 3",
   "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 或 1.3（以前称为安全套接字层（SSL）进行保护。 Azure 逻辑应用会就是否使用受支持的最高可能版本一事与目标终结点进行协商。 例如，如果目标终结点支持 1.3，则 HTTP 触发器或作首先使用 1.3。 否则，连接器将使用下一个受支持的最高版本。

此列表包含有关 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（OAuth 2.0 with Microsoft Entra ID）身份验证。

  • 管理身份认证。

• 限制来自逻辑应用工作流 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 管理触发器还是操作，请按照以下步骤操作：

       • Trigger: 按照常规步骤添加名为Choose an Azure API 管理 Trigger的触发器。

       • 动作：通过遵循一般步骤添加名为“选择 Azure API 管理 动作”的动作。

    2. 从 API 管理服务实例列表中，选择之前创建的 API 管理服务实例。

    3. 从 API操作列表中选择要调用的 API操作，然后选择“添加操作”。

    标准工作流

    对于标准工作流，只能添加“API 管理”操作，而不能添加触发器。

    1. 在工作流设计器中，按照一般步骤添加名为“调用 Azure API 管理 API”的操作。

    2. 从 API 管理服务实例列表中，选择之前创建的 API 管理服务实例。

    3. 从 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 进行身份验证，以用于应用程序和浏览器登录。 该功能帮助您采用抗钓鱼认证，并用X.509证书对公钥基础设施（PKI）进行认证。

如果 “客户端证书 ”选项可用且处于选中状态，请指定以下属性值：

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

Active Directory OAuth （OAuth 2.0 with Microsoft Entra ID） 认证

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

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

使用 安全参数 来处理和保护敏感信息（例如，在 用于自动部署的 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": {}
}

原始身份验证

如果有 Raw 选项，当你需要使用不遵循 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 令牌。 Azure 会为你管理此标识并帮助保护凭据，因为无需管理机密或直接使用 Microsoft Entra 令牌。 详细了解支持使用托管标识进行 Microsoft Entra 身份验证的 Azure 服务。

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

• 标准逻辑应用资源支持同时启用 系统分配的托管标识 和 多个用户分配的托管标识 ，不过你仍只能选择一个标识随时使用。

  注意

  在默认情况下，已启用系统分配的标识，以便在运行时对连接进行身份验证。 此标识不同于创建连接时使用的身份验证凭据或连接字符串。 如果你禁用了这个身份，连接在运行时就无法正常工作。 要查看此设置，可以在你的 Logic 应用侧边 栏设置中选择 “身份”。

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

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

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

   内置触发器和操作

   属性（设计器）	属性 (JSON)	Required	价值	Description
   Authentication	type	Yes	托管标识 或者 ManagedServiceIdentity	要使用的身份验证类型
   托管标识	identity	No	< 用户分配身份标识-ID>	由用户分配的要使用的托管标识。 注意：使用系统分配的托管标识时，请勿包含此属性。
   观众	audience	Yes	< 目标资源 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": {}
   }
   

   托管的连接器触发器和操作

   属性（设计器）	Required	价值	Description
   连接名称	Yes	< 连接名称>
   托管标识	Yes	系统分配的托管标识 或者 < 用户分配的托管标识名称>	要使用的身份验证类型

阻止由特定连接器创建的连接

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

逻辑应用隔离指南

• 标准逻辑应用工作流可以通过为入站流量设置的专用终结点和为出站流量设置的虚拟网络集成，与 Azure 虚拟网络进行私密且安全的通信。 有关详细信息，请参阅使用专用终结点保护虚拟网络和单租户 Azure 逻辑应用之间的流量。

• 若要运行自己的代码或执行 XML 转换，请创建并调用一个 Azure 函数，而不要使用内联代码功能或提供用作映射的程序集。 此外，为函数应用设置托管环境，以符合隔离要求。

  有关详细信息，请参见:

  • Azure 应用服务计划
  • Azure Functions 网络选项
  • 适用于虚拟机的 Azure 专用主机
  • Azure 中的虚拟机隔离
  • 将专用 Azure 服务部署到虚拟网络

有关隔离的更多信息，请参见：

• Azure 公有云中的隔离

相关内容

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