在 Azure 逻辑应用中保护访问和数据Secure access and data in Azure Logic Apps

Azure 逻辑应用依赖 Azure 存储来存储和自动加密静态数据Azure Logic Apps relies on Azure Storage to store and automatically encrypt data at rest. 此加密可保护数据,并帮助你履行组织的安全性和符合性承诺。This encryption protects your data and helps you meet your organizational security and compliance commitments. 默认情况下,Azure 存储使用 Azure 托管密钥来加密数据。By default, Azure Storage uses Azure-managed keys to encrypt your data. 有关详细信息,请参阅静态数据的 Azure 存储加密For more information, see Azure Storage encryption for data at rest.

若要在 Azure 逻辑应用中进一步控制访问并保护敏感数据,可以在以下方面设置额外的安全性:To further control access and protect sensitive data in Azure Logic Apps, you can set up additional security in these areas:

有关 Azure 中的安全性的详细信息,请参阅以下主题:For more information about security in Azure, see these topics:

对基于请求的触发器的访问Access to request-based triggers

如果逻辑应用使用接收传入调用或请求的基于请求的触发器(例如请求Webhook 触发器),则你可以限制访问权限,以便只有经过授权的客户端才能调用逻辑应用。If your logic app uses a request-based trigger, which receives incoming calls or requests, such as the Request or Webhook trigger, you can limit access so that only authorized clients can call your logic app. 逻辑应用接收到的所有请求都使用传输层安全性 (TLS) 协议(以前称为“安全套接字层 (SSL)”)进行加密和保护。All requests received by a logic app are encrypted and secured with Transport Layer Security (TLS) protocol, previously known as Secure Sockets Layer (SSL).

以下选项可帮助你保护对此触发器类型的访问:Here are options that can help you secure access to this trigger type:

生成共享访问签名 (SAS)Generate shared access signatures (SAS)

逻辑应用的每个请求终结点在终结点的 URL 中都包含一个共享访问签名 (SAS),该 URL 的格式如下:Every request endpoint on a logic app has a Shared Access Signature (SAS) in the endpoint's URL, which follows this format:

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

每个 URL 包含下表中所述的 spsvsig 查询参数:Each URL contains the sp, sv, and sig query parameter as described in this table:

查询参数Query parameter 说明Description
sp 指定允许的 HTTP 方法使用的权限。Specifies permissions for the permitted HTTP methods to use.
sv 指定用于生成签名的 SAS 版本。Specifies the SAS version to use for generating the signature.
sig 指定用于对触发器访问进行身份验证的签名。Specifies the signature to use for authenticating access to the trigger. 此签名是使用 SHA256 算法生成的,所有 URL 路径和属性中都包含机密访问密钥。This signature is generated by using the SHA256 algorithm with a secret access key on all the URL paths and properties. 该密钥永远不会公开或发布,而是一直处于加密状态并存储在逻辑应用中。Never exposed or published, this key is kept encrypted and stored with the logic app. 逻辑应用仅向那些包含有效签名(使用密钥创建)的触发器授权。Your logic app authorizes only those triggers that contain a valid signature created with the secret key.

有关使用 SAS 保护访问的详细信息,请参阅本主题中的以下部分:For more information about securing access with SAS, see these sections in this topic:

重新生成访问密钥Regenerate access keys

若要随时生成新的安全访问密钥,请使用 Azure REST API 或 Azure 门户。To generate a new security access key at any time, use the Azure REST API or Azure portal. 以前使用旧密钥生成的所有 URL 已失效,不再有权触发逻辑应用。All previously generated URLs that use the old key are invalidated and no longer have authorization to trigger the logic app. 重新生成后检索的 URL 将使用新访问密钥进行签名。The URLs that you retrieve after regeneration are signed with the new access key.

  1. Azure 门户中,打开包含要重新生成密钥的逻辑应用。In the Azure portal, open the logic app that has the key you want to regenerate.

  2. 在逻辑应用菜单的“设置”下,选择“访问密钥” 。On the logic app's menu, under Settings, select Access Keys.

  3. 选择要重新生成的密钥并完成生成过程。Select the key that you want to regenerate and finish the process.

创建具有到期日期的回调 URLCreate expiring callback URLs

如果与其他各方共享基于请求的触发器的终结点 URL,可以生成使用特定密钥并具有过期日期的回调 URL。If you share the endpoint URL for a request-based trigger with other parties, you can generate callback URLs that use specific keys and have expiration dates. 这样,便可以无缝地滚动密钥,或基于特定的时间范围限制对触发逻辑应用的访问。That way, you can seamlessly roll keys or restrict access to triggering your logic app based on a specific timespan. 若要为 URL 指定过期日期,请使用逻辑应用 REST API,例如:To specify an expiration date for a URL, use the Logic Apps REST API, for example:

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

在正文中,使用 JSON 日期字符串包含 NotAfter 属性。In the body, include the NotAfterproperty by using a JSON date string. 该属性返回仅在 NotAfter 日期和时间之前有效的回调 URL。This property returns a callback URL that's valid only until the NotAfter date and time.

创建附带主密钥或辅助密钥的 URLCreate URLs with primary or secondary secret key

生成或列出基于请求的触发器的回调 URL 时,可以指定用于对 URL 进行签名的密钥。When you generate or list callback URLs for a request-based trigger, you can specify the key to use for signing the URL. 若要生成由特定密钥签名的 URL,请使用逻辑应用 REST API,例如:To generate a URL that's signed by a specific key, use the Logic Apps REST API, for example:

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

在正文中,包含值为 PrimarySecondaryKeyType 属性。In the body, include the KeyType property as either Primary or Secondary. 此属性返回由指定的安全密钥签名的 URL。This property returns a URL that's signed by the specified security key.

启用 Azure Active Directory OAuthEnable Azure Active Directory OAuth

如果逻辑应用一开始使用“请求”触发器,则可为针对“请求”触发器的入站调用创建授权策略,通过这种方式来启用 Azure Active Directory 开放式身份验证 (Azure AD OAuth)。If your logic app starts with a Request trigger, you can enable Azure Active Directory Open Authentication (Azure AD OAuth) by creating an authorization policy for inbound calls to the Request trigger. 在启用此身份验证之前,请查看以下注意事项:Before you enable this authentication, review these considerations:

  • 对逻辑应用的入站调用只能使用一个授权方案,Azure AD OAuth 或共享访问签名 (SAS)An inbound call to your logic app can use only one authorization scheme, either Azure AD OAuth or Shared Access Signatures (SAS). “请求”触发器仅支持 OAuth 令牌,而该令牌仅支持 Bearer-type 授权方案。Only Bearer-type authorization schemes are supported for OAuth tokens, which are supported only for the Request trigger.

  • 逻辑应用限制为最大授权策略数。Your logic app is limited to a maximum number of authorization policies. 每个授权策略还具有最大声明数。Each authorization policy also has a maximum number of claims. 有关详细信息,请参阅 Azure 逻辑应用的限制和配置For more information, see Limits and configuration for Azure Logic Apps.

  • 授权策略必须至少包含颁发者声明,该声明具有作为 Azure AD 颁发者 ID 的以 https://sts.chinacloudapi.cn/https://login.chinacloudapi.cn/ (OAuth V2) 开头的值。An authorization policy must include at least the Issuer claim, which has a value that starts with https://sts.chinacloudapi.cn/ or https://login.chinacloudapi.cn/ (OAuth V2) as the Azure AD issuer ID. 有关访问令牌的详细信息,请参阅 Microsoft 标识平台访问令牌For more information about access tokens, see Microsoft identity platform access tokens.

若要启用 Azure AD OAuth,请按照以下步骤将一个或多个授权策略添加到逻辑应用。To enable Azure AD OAuth, follow these steps to add one or more authorization policies to your logic app.

  1. Azure 门户的逻辑应用设计器中查找并打开逻辑应用。In the Azure portal, find and open your logic app in the Logic App Designer.

  2. 在逻辑应用菜单的“设置”下,选择“授权” 。On the logic app menu, under Settings, select Authorization. 打开“授权”窗格后,选择“添加策略”。After the Authorization pane opens, select Add policy.

    选择“授权”>“添加策略”

  3. 在对请求触发器的每次入站调用提供的身份验证令牌中,逻辑应用需要一些声明类型和值,通过指定这些声明类型和值来提供有关授权策略的信息:Provide information about the authorization policy by specifying the claim types and values that your logic app expects in the authentication token presented by each inbound call to the Request trigger:

    提供授权策略的信息

    属性Property 必须Required 说明Description
    策略名称Policy name Yes 要用于授权策略的名称The name that you want to use for the authorization policy
    申请Claims Yes 逻辑应用从入站调用接受的声明类型和值。The claim types and values that your logic app accepts from inbound calls. 下面是可用的声明类型:Here are the available claim types:

    - 颁发者- Issuer
    - 受众- Audience
    - 主题- Subject
    - JWT ID(JSON Web 令牌 ID)- JWT ID (JSON Web Token ID)

    声明列表必须至少包含颁发者声明,该声明具有作为 Azure AD 颁发者 ID 的以 https://sts.chinacloudapi.cn/https://login.chinacloudapi.cn/ 开头的值。 At the minimum, the Claims list must include the Issuer claim, which has a value that starts with the https://sts.chinacloudapi.cn/ or https://login.chinacloudapi.cn/ as the Azure AD issuer ID. 有关这些声明类型的详细信息,请参阅 Azure AD 安全令牌中的声明For more information about these claim types, see Claims in Azure AD security tokens. 你还可以指定自己的声明类型和值。You can also specify your own claim type and value.

  4. 若要添加其他声明,请从以下选项中进行选择:To add another claim, select from these options:

    • 若要添加其他声明类型,请选择“添加标准声明”,选择声明类型,并指定声明值。To add another claim type, select Add standard claim, select the claim type, and specify the claim value.

    • 若要添加自己的声明,请选择“添加自定义声明”,并指定自定义声明值。To add your own claim, select Add custom claim, and specify the custom claim value.

  5. 若要添加其他授权策略,请选择“添加策略”。To add another authorization policy, select Add policy. 重复前面的步骤以设置策略。Repeat the previous steps to set up the policy.

  6. 完成后,选择“保存”。When you're done, select Save.

逻辑应用现已设置为使用 Azure AD OAuth 来授权入站请求。Your logic app is now set up to use Azure AD OAuth for authorizing inbound requests. 逻辑应用收到包含身份验证令牌的入站请求时,Azure 逻辑应用会将令牌的声明与每个授权策略中的声明进行比较。When your logic app receives an inbound request that includes an authentication token, Azure Logic Apps compares the token's claims against the claims in each authorization policy. 如果令牌的声明与至少一个策略中的所有声明之间存在匹配项,则入站请求的授权成功。If a match exists between the token's claims and all the claims in at least one policy, authorization succeeds for the inbound request. 令牌的声明数可以大于授权策略指定的声明数。The token can have more claims than the number specified by the authorization policy.

例如,假定逻辑应用有一个需要两个声明类型(颁发者和受众)的授权策略。For example, suppose that your logic app has an authorization policy that requires two claim types, Issuer and Audience. 此示例解码的访问令牌包括以下声明类型:This sample decoded access token includes both those claim types:

{
   "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": "72f988bf-86f1-41af-91ab-2d7cd011db47",
   "unique_name": "SophiaOwen@fabrikam.com",
   "upn": "SophiaOwen@fabrikam.com",
   "uti": "TPJ7nNNMMZkOSx6_uVczUAA",
   "ver": "1.0"
}

限制入站 IP 地址Restrict inbound IP addresses

除了共享访问签名 (SAS) 以外,还可以限制可调用逻辑应用的特定客户端。Along with Shared Access Signature (SAS), you might want to specifically limit the clients that can call your logic app. 例如,如果使用 Azure API 管理来管理请求终结点,则可将逻辑应用限制为仅接受来自你创建的 API 管理服务实例的 IP 地址的请求。For example, if you manage your request endpoint by using Azure API Management, you can restrict your logic app to accept requests only from the IP address for the API Management service instance that you create.

在 Azure 门户中限制入站 IP 范围Restrict inbound IP ranges in Azure portal

  1. Azure 门户的逻辑应用设计器中打开逻辑应用。In the Azure portal, open your logic app in the Logic App Designer.

  2. 在逻辑应用的菜单中,在“设置”下,选择“工作流设置”。On your logic app's menu, under Settings, select Workflow settings.

  3. 在“访问控制配置” > “允许的入站 IP 地址”下,选择“特定 IP 范围” 。Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. 在“触发器的 IP 范围”下,请指定触发器接受的 IP 地址范围。Under IP ranges for triggers, specify the IP address ranges that the trigger accepts.

    有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x A valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

如果想让逻辑应用仅作为嵌套逻辑应用触发,请从“允许的入站 IP 地址”列表中选择“仅限其他逻辑应用” 。If you want your logic app to trigger only as a nested logic app, from the Allowed inbound IP addresses list, select Only other Logic Apps. 此选项会将空数组写入逻辑应用资源。This option writes an empty array to your logic app resource. 这样,只有来自逻辑应用服务(父级逻辑应用)的调用才能触发嵌套的逻辑应用。That way, only calls from the Logic Apps service (parent logic apps) can trigger the nested logic app.

备注

无论 IP 地址如何,仍可通过逻辑应用 REST API: 工作流触发器 - 运行请求或 API 管理来运行具有基于请求的触发器的逻辑应用。Regardless of IP address, you can still run a logic app that has a request-based trigger by using the Logic Apps REST API: Workflow Triggers - Run request or by using API Management. 不过,这种情况下仍需要针对 Azure REST API 进行身份验证However, this scenario still requires authentication against the Azure REST API. 所有事件都会显示在 Azure 审核日志中。All events appear in the Azure Audit Log. 请确保相应地设置访问控制策略。Make sure that you set access control policies accordingly.

在 Azure 资源管理器模板中限制入站 IP 范围Restrict inbound IP ranges in Azure Resource Manager template

如果使用资源管理器模板自动执行逻辑应用部署,则可以通过使用 accessControl 部分并在逻辑应用的资源定义中包含 triggersactions 部分来指定采用 x.x.x.x/x 或 x.x.x.x-x.x.x.x 格式的 IP 范围,例如 :If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges in x.x.x.x/x or x.x.x.x-x.x.x.x format by using the accessControl section and by including the triggers and actions sections in your logic app's resource definition, for example:

{
   "$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:" : []
               }
            },
            "endpointsConfiguration": {}
         }
      }
   ],
   "outputs": {}
}

添加 Azure Active Directory 开放式身份验证或其他安全性Add Azure Active Directory Open Authentication or other security

若要向逻辑应用添加更多身份验证协议,请考虑使用 Azure API 管理服务。To add more authentication protocols to your logic app, consider using the Azure API Management service. 此服务可帮助你将逻辑应用公开为 API,并为所有终结点提供丰富的监视信息、安全性、策略和文档。This service helps you expose your logic app as an API and offers rich monitoring, security, policy, and documentation for any endpoint. API 管理可以公开逻辑应用的公共或专用终结点。API Management can expose a public or private endpoint for your logic app. 若要授予对此终结点的访问权限,可以使用 Azure Active Directory 开放式身份验证 (Azure AD OAuth)、客户端证书或其他安全标准来授权对该终结点的访问权限。To authorize access to this endpoint, you can use Azure Active Directory Open Authentication (Azure AD OAuth), client certificate, or other security standards for authorizing access to that endpoint. 当 API 管理收到请求时,此服务会将请求发送到逻辑应用,同时也会进行任何必要的转换或限制。When API Management receives a request, the service sends the request to your logic app, also making any necessary transformations or restrictions along the way. 要仅让 API 管理触发逻辑应用,可以使用逻辑应用的入站 IP 范围设置。To let only API Management trigger your logic app, you can use your logic app's inbound IP range settings.

对逻辑应用操作的访问Access to logic app operations

可以仅允许特定的用户或组运行特定的任务,例如管理、编辑和查看逻辑应用。You can permit only specific users or groups to run specific tasks, such as managing, editing, and viewing logic apps. 若要控制其权限,请使用 Azure 基于角色的访问控制 (RBAC),以便能够为 Azure 订阅中的成员分配自定义角色或内置角色:To control their permissions, use Azure Role-Based Access Control (RBAC) so that you can assign customized or built-in roles to the members in your Azure subscription:

要防止他人更改或删除逻辑应用,可以使用 Azure 资源锁To prevent others from changing or deleting your logic app, you can use Azure Resource Lock. 此功能可以防止他人更改或删除生产资源。This capability prevents others from changing or deleting production resources.

对运行历史记录数据的访问Access to run history data

在逻辑应用运行期间,所有数据都是使用传输层安全性 (TLS) 在传输过程中加密的以及静态加密的。During a logic app run, all the data is encrypted during transit by using Transport Layer Security (TLS) and at rest. 运行逻辑应用后,可以查看该运行的历史记录,包括已运行的步骤以及每个操作的状态、持续时间、输入和输出。When your logic app finishes running, you can view the history for that run, including the steps that ran along with the status, duration, inputs, and outputs for each action. 此丰富的详细信息可让你深入了解逻辑应用的运行方式,以及开始解决出现的任何问题的位置。This rich detail provides insight into how your logic app ran and where you might start troubleshooting any problems that arise.

查看逻辑应用的运行历史记录时,逻辑应用将对该访问进行身份验证,然后提供指向请求的输入和输出以及每个运行的响应的链接。When you view your logic app's run history, Logic Apps authenticates your access and then provides links to the inputs and outputs for the requests and responses for each run. 但是,对于处理任何密码、机密、密钥或其他敏感信息的操作,你希望防止他人查看和访问该数据。However, for actions that handle any passwords, secrets, keys, or other sensitive information, you want to prevent others from viewing and accessing that data. 例如,如果逻辑应用从 Azure Key Vault 获取机密,以便在对 HTTP 操作进行身份验证时使用,则你需要在视图中隐藏该机密。For example, if your logic app gets a secret from Azure Key Vault to use when authenticating an HTTP action, you want to hide that secret from view.

若要控制对逻辑应用运行历史记录中的输入和输出的访问,可使用以下选项:To control access to the inputs and outputs in your logic app's run history, you have these options:

按 IP 地址范围限制访问Restrict access by IP address range

可以限制对逻辑应用运行历史记录中的输入和输出的访问,以便只有来自特定 IP 地址范围的请求才能查看这些数据。You can limit access to the inputs and outputs in your logic app's run history so that only requests from specific IP address ranges can view that data. 例如,若要阻止任何人访问输入和输出,请指定类似于 0.0.0.0-0.0.0.0 的 IP 地址范围。For example, to block anyone from accessing inputs and outputs, specify an IP address range such as 0.0.0.0-0.0.0.0. 只有拥有管理员权限的人员才能去除此限制,使“实时”访问逻辑应用的数据成为可能。Only a person with administrator permissions can remove this restriction, which provides the possibility for "just-in-time" access to your logic app's data. 可以使用 Azure 门户或者在用于逻辑应用部署的 Azure 资源管理器模板中指定要限制的 IP 范围。You can specify the IP ranges to restrict either by using the Azure portal or in an Azure Resource Manager template that you use for logic app deployment.

在 Azure 门户中限制 IP 范围Restrict IP ranges in Azure portal

  1. 在 Azure 门户的逻辑应用设计器中打开逻辑应用。In the Azure portal, open your logic app in the Logic App Designer.

  2. 在逻辑应用的菜单中,在“设置”下,选择“工作流设置”。On your logic app's menu, under Settings, select Workflow settings.

  3. 在“访问控制配置” > “允许的入站 IP 地址”下,选择“特定 IP 范围” 。Under Access control configuration > Allowed inbound IP addresses, select Specific IP ranges.

  4. 在“内容的 IP 范围”下,指定可以访问输入和输出中内容的 IP 地址范围。Under IP ranges for contents, specify the IP address ranges that can access content from inputs and outputs.

    有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x A valid IP range uses these formats: x.x.x.x/x or x.x.x.x-x.x.x.x

在 Azure 资源管理器模板中限制 IP 范围Restrict IP ranges in Azure Resource Manager template

如果使用资源管理器模板自动执行逻辑应用部署,则可以通过在逻辑应用的资源定义中结合使用 accessControlcontents 部分来指定 IP 范围,例如:If you automate deployment for logic apps by using Resource Manager templates, you can specify the IP ranges by using the accessControl section with the contents section in your logic app's resource definition, for example:

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

使用模糊处理保护运行历史记录中的数据Secure data in run history by using obfuscation

许多触发器和操作具有用于保护逻辑应用的运行历史记录中的输入和/或输出的设置。Many triggers and actions have settings to secure inputs, outputs, or both from a logic app's run history. 在使用这些设置帮助你保护此数据之前,请查看以下注意事项Before using these settings to help you secure this data, review these considerations.

保护设计器中的输入和输出Secure inputs and outputs in the designer

  1. Azure 门户的逻辑应用设计器中打开逻辑应用。In the Azure portal, open your logic app in the Logic App Designer.

    在逻辑应用设计器中打开逻辑应用

  2. 在要保护敏感数据的触发器或操作中,选择省略号 ( ... ) 按钮,然后选择“设置”。On the trigger or action where you want to secure sensitive data, select the ellipses (...) button, and then select Settings.

    打开触发器或操作设置

  3. 打开“安全输入”和/或“安全输出” 。Turn on either Secure Inputs, Secure Outputs, or both. 完成后,选择“完成”。When you're finished, select Done.

    打开“安全输入”或“安全输出”

    操作或触发器现在显示标题栏中的锁图标。The action or trigger now shows a lock icon in the title bar.

    操作或触发器标题栏显示锁形图标

    表示以前操作的安全输出的令牌也显示锁图标。Tokens that represent secured outputs from previous actions also show lock icons. 例如,从动态内容列表中选择要在操作中使用的此类输出时,该令牌将显示锁图标。For example, when you select such an output from the dynamic content list to use in an action, that token shows a lock icon.

    为安全输出选择令牌

  4. 运行逻辑应用后,可以查看该运行的历史记录。After the logic app runs, you can view the history for that run.

    1. 在逻辑应用的”概述“窗格中,选择要查看的运行。On the logic app's Overview pane, select the run that you want to view.

    2. 在“逻辑应用运行”窗格中,展开要查看的操作。On the Logic app run pane, expand the actions that you want to review.

      如果选择同时遮盖输入和输出,这些值现在将处于隐藏状态。If you chose to obscure both inputs and outputs, those values now appear hidden.

      隐藏运行历史记录中的输入和输出

保护代码视图中的输入和输出Secure inputs and outputs in code view

在基础触发器或操作定义中,使用以下两个值中的一个或两个值添加或更新 runtimeConfiguration.secureData.properties 数组:In the underlying trigger or action definition, add or update the runtimeConfiguration.secureData.properties array with either or both of these values:

  • "inputs":在运行历史记录中保护输入。"inputs": Secures inputs in run history.
  • "outputs":保护运行历史记录中的输出。"outputs": Secures outputs in run history.

使用这些设置帮助你保护此数据时,请查看以下注意事项Here are some considerations to review when you use these settings to help you secure this data.

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

保护输入和输出时的注意事项Considerations when securing inputs and outputs

  • 遮盖触发器或操作的输入或输出时,逻辑应用不会将安全数据发送到 Azure Log Analytics。When you obscure the inputs or outputs on a trigger or action, Logic Apps doesn't send the secured data to Azure Log Analytics.

  • 用于处理工作流历史记录的逻辑应用 API 不会返回受保护的输出。The Logic Apps API for handling workflow history doesn't return secured outputs.

  • 若要保护可遮盖输入或显式遮盖输出的操作的输出,请在该操作中手动打开“安全输出”。To secure outputs from an action that obscures inputs or explicitly obscures outputs, manually turn on Secure Outputs in that action.

  • 请确保在你希望运行历史记录来遮盖该数据的下游操作中打开“安全输入”或“安全输出” 。Make sure that you turn on Secure Inputs or Secure Outputs in downstream actions where you expect the run history to obscure that data.

    安全输出设置Secure Outputs setting

    在触发器或操作中手动打开“安全输出”时,逻辑应用会隐藏运行历史记录中的这些输出。When you manually turn on Secure Outputs in a trigger or action, Logic Apps hides these outputs in the run history. 如果下游操作显式使用这些安全输出作为输入,则逻辑应用会隐藏运行历史记录中的此操作的输入,但不会启用操作的“安全输入”设置。If a downstream action explicitly uses these secured outputs as inputs, Logic Apps hides this action's inputs in the run history, but doesn't enable the action's Secure Inputs setting.

    用作输入的受保护输出,以及对大多数操作的下游影响

    “撰写”、“分析 JSON”和“响应”操作仅提供“保护输入”设置。The Compose, Parse JSON, and Response actions has only the Secure Inputs setting. 启用后,此设置也会隐藏这些操作的输出。When turned on, the setting also hides these actions' outputs. 如果这些操作显式使用上游的受保护输出作为输入,则逻辑应用会隐藏这些操作的输入和输出,但不会启用这些操作的“保护输入”设置。If these actions explicitly use the upstream secured outputs as inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these actions' Secure Inputs setting. 如果下游操作显式使用“撰写”、“分析 JSON”或“响应”操作中隐藏的输出作为输入,则逻辑应用不会隐藏此下游操作的输入或输出。If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    用作输入的受保护输出,以及对特定操作的下游影响

    安全输入设置Secure Inputs setting

    在触发器或操作中手动打开“安全输入”时,逻辑应用会隐藏运行历史记录中的这些输入。When you manually turn on Secure Inputs in a trigger or action, Logic Apps hides these inputs in the run history. 如果下游操作显式使用该触发器或操作中的可见输出作为输入,则逻辑应用会隐藏运行历史记录中的此下游操作的输入,但不会启用此操作中的“安全输入”,并且不会隐藏此操作的输出。If a downstream action explicitly uses the visible outputs from that trigger or action as inputs, Logic Apps hides this downstream action's inputs in the run history, but doesn't enable Secure Inputs in this action and doesn't hide this action's outputs.

    受保护的输入以及对大多数操作的下游影响

    如果“撰写”、“分析 JSON”和“响应”操作显式使用具有受保护输入的触发器或操作中的可见输出,则逻辑应用将隐藏这些操作的输入和输出,但不会启用这些操作的“保护输入”设置。If the Compose, Parse JSON, and Response actions explicitly use the visible outputs from the trigger or action that has the secured inputs, Logic Apps hides these actions' inputs and outputs, but doesn't enable these action's Secure Inputs setting. 如果下游操作显式使用“撰写”、“分析 JSON”或“响应”操作中隐藏的输出作为输入,则逻辑应用不会隐藏此下游操作的输入或输出。If a downstream action explicitly uses the hidden outputs from the Compose, Parse JSON, or Response actions as inputs, Logic Apps doesn't hide this downstream action's inputs or outputs.

    受保护的输入以及对特定操作的下游影响

对参数输入的访问Access to parameter inputs

如果跨不同的环境进行部署,请考虑参数化工作流定义中因这些环境而有所不同的值。If you deploy across different environments, consider parameterizing the values in your workflow definition that vary based on those environments. 这样,便可以通过使用 Azure 资源管理器模板部署逻辑应用来避免使用硬编码数据,通过定义安全的参数来保护敏感数据,并使用参数文件通过模板的参数将该数据作为单独输入传递。That way, you can avoid hard-coded data by using an Azure Resource Manager template to deploy your logic app, protect sensitive data by defining secured parameters, and pass that data as separate inputs through the template's parameters by using a parameter file.

例如,如果使用 Azure Active Directory 开放式身份验证 (Azure AD OAuth) 对 HTTP 操作进行身份验证,则可以定义并遮盖接受用于身份验证的客户端 ID 和客户端机密的参数。For example, if you authenticate HTTP actions with Azure Active Directory Open Authentication (Azure AD OAuth), you can define and obscure the parameters that accept the client ID and client secret that are used for authentication. 若要在逻辑应用中定义这些参数,请使用逻辑应用的工作流定义中的 parameters 部分,以及用于部署的资源管理器模板。To define these parameters in your logic app, use the parameters section in your logic app's workflow definition and Resource Manager template for deployment. 若要帮助保护在编辑逻辑应用或查看运行历史记录时不希望显示的参数值,请使用 securestringsecureobject 类型定义参数并根据需要使用编码。To help secure parameter values that you don't want shown when editing your logic app or viewing run history, define the parameters by using the securestring or secureobject type and use encoding as necessary. 具有此类型的参数不会随资源定义一起返回,并且在部署后无法通过查看资源来访问这些参数。Parameters that have this type aren't returned with the resource definition and aren't accessible when viewing the resource after deployment. 若要在运行时访问这些参数值,请在工作流定义中使用 @parameters('<parameter-name>') 表达式。To access these parameter values during runtime, use the @parameters('<parameter-name>') expression inside your workflow definition. 此表达式仅在运行时进行计算,由工作流定义语言描述。This expression is evaluated only at runtime and is described by the Workflow Definition Language.

备注

如果在请求标头或正文中使用参数,查看逻辑应用的运行历史记录和传出的 HTTP 请求时,该参数可能是可见的。If you use a parameter in a request header or body, that parameter might be visible when you view your logic app's run history and outgoing HTTP request. 请务必同时相应地设置内容访问策略。Make sure that you also set your content access policies accordingly. 还可以使用模糊处理在运行历史记录中隐藏输入和输出。You can also use obfuscation to hide inputs and outputs in your run history. 始终不能通过输入或输出看见授权标头。Authorization headers are never visible through inputs or outputs. 因此,如果在此处使用机密,则无法检索该机密。So if a secret is used there, that secret isn't retrievable.

有关详细信息,请参阅本主题中的以下部分:For more information, see these sections in this topic:

如果使用资源管理器模板自动执行逻辑应用部署,则可以使用 securestringsecureobject 类型定义在部署时计算的安全模板参数If you automate deployment for logic apps by using Resource Manager templates, you can define secured template parameters, which are evaluated at deployment, by using the securestring and secureobject types. 若要定义模板参数,请使用模板的顶级 parameters 节,该节不同于工作流定义的 parameters 节。To define template parameters, use your template's top level parameters section, which is separate and different from your workflow definition's parameters section. 若要提供模板参数的值,请使用单独的参数文件To provide the values for template parameters, use a separate parameter file.

例如,如果使用机密,则可以定义并使用可在部署时从 Azure Key Vault 检索这些机密的受保护模板参数。For example, if you use secrets, you can define and use secured template parameters that retrieve those secrets from Azure Key Vault at deployment. 然后,可以在参数文件中引用 Key Vault 和机密。You can then reference the key vault and secret in your parameter file. 有关详细信息,请参阅以下主题:For more information, see these topics:

保护工作流定义中的参数Secure parameters in workflow definitions

若要在逻辑应用工作流定义中保护敏感信息,请使用受保护的参数,以使该信息在保存逻辑应用后不可见。To protect sensitive information in your logic app's workflow definition, use secured parameters so this information isn't visible after you save your logic app. 例如,假设某个 HTTP 操作需要使用用户名和密码进行基本身份验证。For example, suppose you have an HTTP action requires basic authentication, which uses a username and password. 在工作流定义中,parameters 节使用 securestring 类型定义 basicAuthPasswordParambasicAuthUsernameParam 参数。In the workflow definition, the parameters section defines the basicAuthPasswordParam and basicAuthUsernameParam parameters by using the securestring type. 然后,操作定义将引用 authentication 节中的这些参数。The action definition then references these parameters in the authentication section.

"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 资源管理器模板中保护参数Secure parameters in Azure Resource Manager templates

逻辑应用的资源管理器模板包含多个 parameters 节。A Resource Manager template for a logic app has multiple parameters sections. 若要保护密码、密钥、机密和其他敏感信息,请使用 securestringsecureobject 类型在模板级别和工作流定义级别定义安全的参数。To protect passwords, keys, secrets, and other sensitive information, define secured parameters at the template level and workflow definition level by using the securestring or secureobject type. 然后,可将这些值存储在 Azure Key Vault 中,并使用参数文件来引用 Key Vault 和机密。You can then store these values in Azure Key Vault and use the parameter file to reference the key vault and secret. 模板便会在部署时检索该信息。Your template then retrieves that information at deployment. 有关详细信息,请参阅在部署时使用 Azure Key Vault 传递敏感值For more information, see Pass sensitive values at deployment by using Azure Key Vault.

下面详细介绍了这些 parameters 部分:Here is more information about these parameters sections:

  • 在模板的最高级别,parameters 节定义了模板在部署时使用的值的参数。At the template's top level, a parameters section defines the parameters for the values that the template uses at deployment. 例如,这些值可能包含特定部署环境的连接字符串。For example, these values can include connection strings for a specific deployment environment. 然后,你可将这些值存储在单独的参数文件中,以方便更改这些值。You can then store these values in a separate parameter file, which makes changing these values easier.

  • 在逻辑应用的资源定义内部、工作流定义外部,parameters 节指定了工作流定义参数的值。Inside your logic app's resource definition, but outside your workflow definition, a parameters section specifies the values for your workflow definition's parameters. 在此节中,可以使用引用模板参数的模板表达式来分配这些值。In this section, you can assign these values by using template expressions that reference your template's parameters. 这些表达式将在部署时计算。These expressions are evaluated at deployment.

  • 在工作流定义中,parameters 节定义了逻辑应用在运行时使用的参数。Inside your workflow definition, a parameters section defines the parameters that your logic app uses at runtime. 然后,你可以使用在运行时计算的工作流定义表达式,在逻辑应用工作流中引用这些参数。You can then reference these parameters inside your logic app's workflow by using workflow definition expressions, which are evaluated at runtime.

此示例模板包含使用 securestring 类型的多个受保护参数定义:This example template that has multiple secured parameter definitions that use the securestring type:

参数名称Parameter name 说明Description
TemplatePasswordParam 一个模板参数,它接受随后要传递到工作流定义的 basicAuthPasswordParam 参数的密码A template parameter that accepts a password that is then passed to the workflow definition's basicAuthPasswordParam parameter
TemplateUsernameParam 一个模板参数,它接受随后要传递到工作流定义的 basicAuthUserNameParam 参数的用户名A template parameter that accepts a username that is then passed to the workflow definition's basicAuthUserNameParam parameter
basicAuthPasswordParam 一个工作流定义参数,它接受 HTTP 操作中用于基本身份验证的密码A workflow definition parameter that accepts the password for basic authentication in an HTTP action
basicAuthUserNameParam 一个工作流定义参数,它接受 HTTP 操作中用于基本身份验证的用户名A workflow definition parameter that accepts the username for basic authentication in an HTTP action
{
   "$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",
         ],
         "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": {} 
}   

对从逻辑应用调用的服务和系统的访问Access to services and systems called from logic apps

下面是可帮助保护接收来自逻辑应用的调用或请求的终结点的一些方法:Here are some ways that you can help secure endpoints that receive calls or requests from your logic app:

  • 向出站请求添加身份验证。Add authentication to outbound requests.

    使用基于 HTTP 的触发器或发出出站调用的操作(如 HTTP、HTTP + Swagger 或 Webhook)时,可以向逻辑应用发送的请求添加身份验证。When you work with an HTTP-based trigger or action that makes outbound calls, such as HTTP, HTTP + Swagger, or Webhook, you can add authentication to the request that's sent by your logic app. 例如,可以选择以下身份验证类型:For example, you can select these authentication types:

    有关详细信息,请参阅本主题稍后的针对出站调用添加身份验证For more information, see Add authentication to outbound calls later in this topic.

  • 限制来自逻辑应用 IP 地址的访问。Restrict access from logic app IP addresses.

    从逻辑应用对终结点发出的所有调用都来源于基于逻辑应用区域的指定 IP 地址。All calls to endpoints from logic apps originate from specific designated IP addresses that are based on your logic apps' regions. 可以添加仅接受来自这些 IP 地址的请求的筛选规则。You can add filtering that accepts requests only from those IP addresses. 若要获取这些 IP 地址,请参阅 Azure 逻辑应用的限制和配置To get these IP addresses, see Limits and configuration for Azure Logic Apps.

  • 提高与本地系统的连接的安全性。Improve security for connections to on-premises systems.

    Azure 逻辑应用可与这些服务集成,来帮助提供更安全可靠的本地通信。Azure Logic Apps provides integration with these services to help provide more secure and reliable on-premises communication.

    • 本地数据网关On-premises data gateway

      Azure 逻辑应用中的许多托管连接器都可以安全连接到本地系统,例如,文件系统、SQL、SharePoint 和 DB2。Many managed connectors in Azure Logic Apps facilitate secured connections to on-premises systems, such as File System, SQL, SharePoint, and DB2. 网关通过 Azure 服务总线发送来自加密通道上的本地源的数据。The gateway sends data from on-premises sources on encrypted channels through the Azure Service Bus. 所有流量最初都是网关代理的安全出站流量。All traffic originates as secured outbound traffic from the gateway agent. 了解本地数据网关的工作原理Learn how the on-premises data gateway works.

    • 通过 Azure API 管理进行连接Connect through Azure API Management

      Azure API 管理提供本地连接选项,例如站点到站点虚拟专用网络和 ExpressRoute 集成,用于保护代理和与本地系统的通信。Azure API Management provides on-premises connection options, such as site-to-site virtual private network and ExpressRoute integration for secured proxy and communication to on-premises systems. 如果你有一个提供对你的本地系统的访问权限的 API,并且通过创建 API 管理服务实例公开了该 API,则可通过在逻辑应用设计器中选择内置的 API 管理触发器或操作在逻辑应用的工作流中调用该 API。If you have an API that provides access to your on-premises system, and you exposed that API by creating an API Management service instance, you can call that API in your logic app's workflow by selecting the built-in API Management trigger or action in the Logic App Designer.

      备注

      连接器仅显示那些你有权在其中进行查看和连接操作的 API 管理服务,但不显示基于消耗的 API 管理服务。The connector shows only those API Management services where you have permissions to view and connect, but doesn't show consumption-based API Management services.

      1. 在逻辑应用设计器的搜索框中输入 api managementIn the Logic App Designer, enter api management in the search box. 根据你是要添加触发器还是操作来选择步骤:Choose the step based on whether you're adding a trigger or an action:

        • 如果要添加始终是工作流中的第一个步骤的触发器,请选择“选择 Azure API 管理触发器”。If you're adding a trigger, which is always the first step in your workflow, select Choose an Azure API Management trigger.

        • 如果要添加操作,请选择“选择 Azure API 管理操作”。If you're adding an action, select Choose an Azure API Management action.

        此示例将添加一个触发器:This example adds a trigger:

        添加 Azure API 管理触发器

      2. 选择你之前创建的 API 管理服务实例。Select your previously created API Management service instance.

        选择 API 管理服务实例

      3. 选择要使用的 API 调用。Select the API call to use.

        选择现有 API

针对出站调用添加身份验证Add authentication to outbound calls

HTTP 和 HTTPS 终结点支持各种身份验证。HTTP and HTTPS endpoints support various kinds of authentication. 在用于向这些终结点发送出站调用或请求的某些触发器和操作上,可以指定身份验证类型。On some triggers and actions that you use for sending outbound calls or requests to these endpoints, you can specify an authentication type. 在逻辑应用设计器中,支持选择身份验证类型的触发器和操作具有“身份验证”属性。In the Logic App Designer, triggers and actions that support choosing an authentication type have an Authentication property. 但是,此属性可能并不总会默认显示。However, this property might not always appear by default. 在这种情况下,请在触发器或操作中打开“添加新参数”列表,然后选择“身份验证”。 In these cases, on the trigger or action, open the Add new parameter list, and select Authentication.

重要

若要保护你的逻辑应用处理的敏感信息,请使用受保护的参数,并根据需要对数据进行编码。To protect sensitive information that your logic app handles, use secured parameters and encode data as necessary. 有关使用和保护参数的详细信息,请参阅对参数输入的访问For more information about using and securing parameters, see Access to parameter inputs.

此表标识了可以在其中选择身份验证类型的触发器和操作上可用的身份验证类型:This table identifies the authentication types that are available on the triggers and actions where you can select an authentication type:

身份验证类型Authentication type 可用性Availability
基本Basic Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP WebhookAzure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
客户端证书Client Certificate Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP WebhookAzure API Management, Azure App Services, HTTP, HTTP + Swagger, HTTP Webhook
Active Directory OAuthActive Directory OAuth Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP WebhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
原始Raw Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP WebhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook
托管的标识Managed identity Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP WebhookAzure API Management, Azure App Services, Azure Functions, HTTP, HTTP + Swagger, HTTP Webhook

基本身份验证Basic authentication

如果基本选项可用,请指定以下属性值:If the Basic option is available, specify these property values:

属性(设计器)Property (designer) 属性 (JSON)Property (JSON) 必须Required ValueValue 说明Description
身份验证Authentication type Yes 基本Basic 要使用的身份验证类型The authentication type to use
用户名Username username Yes <user-name><user-name> 用于对目标服务终结点访问进行身份验证的用户名The user name for authenticating access to the target service endpoint
密码Password password Yes <password><password> 用于对目标服务终结点访问进行身份验证的密码The password for authenticating access to the target service endpoint

使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. 此示例 HTTP 操作定义将身份验证 type 指定为 Basic 并使用 parameters() function 获取参数值:This example HTTP action definition specifies the authentication type as Basic and uses the parameters() function to get the parameter values:

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

客户端证书身份验证Client Certificate authentication

如果客户端证书选项可用,请指定以下属性值:If the Client Certificate option is available, specify these property values:

属性(设计器)Property (designer) 属性 (JSON)Property (JSON) 必须Required ValueValue 说明Description
身份验证Authentication type Yes 客户端证书Client Certificate
or
ClientCertificate
可使用的身份验证类型。The authentication type to use. 可以使用 Azure API 管理来管理证书。You can manage certificates with Azure API Management.

注意:对于入站和出站调用,自定义连接器不支持基于证书的身份验证。Note: Custom connectors don't support certificate-based authentication for both inbound and outbound calls.
PfxPfx pfx Yes <encoded-pfx-file-content><encoded-pfx-file-content> 个人信息交换 (PFX) 文件中的 base64 编码内容The base64-encoded content from a Personal Information Exchange (PFX) file

若要将 PFX 文件转换为 base64 编码格式,可以使用 PowerShell 并执行以下步骤:To convert the PFX file into base64-encoded format, you can use PowerShell by following these steps:

1.将证书内容保存到某个变量中:1. Save the certificate content into a variable:

$pfx_cert = get-content 'c:\certificate.pfx' -Encoding Byte

2.使用 ToBase64String() 函数转换证书内容,并将该内容保存到某个文本文件中:2. Convert the certificate content by using the ToBase64String() function and save that content to a text file:

[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt'

密码Password password No <password-for-pfx-file> 用于访问 PFX 文件的密码The password for accessing the PFX file

使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. 此示例 HTTP 操作定义将身份验证 type 指定为 ClientCertificate 并使用 parameters() function 获取参数值:This example HTTP action definition specifies the authentication type as ClientCertificate and uses the parameters() function to get the parameter values:

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

有关使用客户端证书身份验证保护服务的详细信息,请参阅以下主题:For more information about securing services by using client certificate authentication, see these topics:

Azure Active Directory 开放式身份验证Azure Active Directory Open Authentication

在请求触发器上,可以使用 Azure Active Directory 开放式身份验证 (Azure AD OAuth),在为逻辑应用设置 Azure AD 授权策略后对传入调用进行身份验证。On Request triggers, you can use Azure Active Directory Open Authentication (Azure AD OAuth), for authenticating incoming calls after you set up Azure AD authorization policies for your logic app. 对于提供 Active Directory OAuth 身份验证类型供你选择的所有其他触发器和操作,请指定以下属性值:For all other triggers and actions that provide the Active Directory OAuth authentication type for you to select, specify these property values:

属性(设计器)Property (designer) 属性 (JSON)Property (JSON) 必须Required ValueValue 说明Description
身份验证Authentication type Yes Active Directory OAuthActive Directory OAuth
or
ActiveDirectoryOAuth
可使用的身份验证类型。The authentication type to use. 逻辑应用当前遵循 OAuth 2.0 协议Logic Apps currently follows the OAuth 2.0 protocol.
颁发机构Authority authority No <URL-for-authority-token-issuer><URL-for-authority-token-issuer> 提供身份验证令牌的颁发机构的 URL。The URL for the authority that provides the authentication token. 此值默认为 https://login.chinacloudapi.cnBy default, this value is https://login.chinacloudapi.cn.
租户Tenant tenant Yes <tenant-ID><tenant-ID> Azure AD 租户的租户 IDThe tenant ID for the Azure AD tenant
受众Audience audience Yes <resource-to-authorize><resource-to-authorize> 要用于授权的资源,例如 https://management.core.chinacloudapi.cn/The resource that you want to use for authorization, for example, https://management.core.chinacloudapi.cn/
客户端 IDClient ID clientId Yes <client-ID><client-ID> 请求授权的应用的客户端 IDThe client ID for the app requesting authorization
凭据类型Credential Type credentialType Yes 证书Certificate
or
SecretSecret
客户端用来请求授权的凭据类型。The credential type that the client uses for requesting authorization. 此属性和值不会显示在逻辑应用的基础定义中,但确定了为选定凭据类型显示的属性。This property and value don't appear in your logic app's underlying definition, but determines the properties that appear for the selected credential type.
机密Secret secret 是,但仅适用于“机密”凭据类型Yes, but only for the "Secret" credential type <client-secret><client-secret> 用于请求授权的客户端密码The client secret for requesting authorization
PfxPfx pfx 是,但仅适用于“证书”凭据类型Yes, but only for the "Certificate" credential type <encoded-pfx-file-content><encoded-pfx-file-content> 个人信息交换 (PFX) 文件中的 base64 编码内容The base64-encoded content from a Personal Information Exchange (PFX) file
密码Password password 是,但仅适用于“证书”凭据类型Yes, but only for the "Certificate" credential type <password-for-pfx-file><password-for-pfx-file> 用于访问 PFX 文件的密码The password for accessing the PFX file

使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. 此示例 HTTP 操作定义将身份验证 type 指定为 ActiveDirectoryOAuth,将凭据类型指定为 Secret,并使用 parameters() function 获取参数值:This example HTTP action definition specifies the authentication type as ActiveDirectoryOAuth, the credential type as Secret, and uses the parameters() function to get the parameter values:

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

如果原始选项可用,在必须使用不遵循 OAuth 2.0 协议身份验证方案时,可以使用此身份验证类型。If the Raw option is available, you can use this authentication type when you have to use authentication schemes that don't follow the OAuth 2.0 protocol. 使用此类型可以手动创建要与传出请求一起发送的授权标头值,并指定触发器或操作中的标头值。With this type, you manually create the authorization header value that you send with the outgoing request, and specify that header value in your trigger or action.

例如,下面是遵循 OAuth 1.0 协议的 HTTPS 请求的示例标头:For example, here is a sample header for an HTTPS request that follows the OAuth 1.0 protocol:

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"

在支持原始身份验证的触发器或操作中指定以下属性值:In the trigger or action that supports raw authentication, specify these property values:

属性(设计器)Property (designer) 属性 (JSON)Property (JSON) 必须Required ValueValue 说明Description
身份验证Authentication type Yes 原始Raw 要使用的身份验证类型The authentication type to use
Value value Yes <authorization-header-value><authorization-header-value> 要用于身份验证的授权标头值The authorization header value to use for authentication

使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. 此示例 HTTP 操作定义将身份验证 type 指定为 Raw 并使用 parameters() function 获取参数值:This example HTTP action definition specifies the authentication type as Raw, and uses the parameters() function to get the parameter values:

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

托管标识身份验证Managed identity authentication

如果托管标识选项可用,则无需登录,逻辑应用即可使用系统分配的标识或单个手动创建的用户分配的标识对受 Azure Active Directory (Azure AD) 保护的其他资源的访问进行身份验证。If the Managed Identity option is available, your logic app can use the system-assigned identity or a single manually created user-assigned identity for authenticating access to other resources that are protected by Azure Active Directory (Azure AD) without signing in. 由于无需提供或轮换机密,因此 Azure 会为你管理此标识,并且会帮助保护凭据。Azure manages this identity for you and helps you secure your credentials because you don't have to provide or rotate secrets. 详细了解支持 Azure AD 身份验证的托管标识的 Azure 服务Learn more about Azure services that support managed identities for Azure AD authentication.

  1. 在逻辑应用可以使用托管标识之前,请按照使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问进行身份验证中的步骤进行操作。Before your logic app can use a managed identity, follow the steps in Authenticate access to Azure resources by using managed identities in Azure Logic Apps. 这些步骤将在逻辑应用上启用托管标识,并设置该标识对目标 Azure 资源的访问权限。These steps enable the managed identity on your logic app and set up that identity's access to the target Azure resource.

  2. 在 Azure 函数可以使用托管标识之前,请先为 Azure 函数启用身份验证Before an Azure function can use a managed identity, first enable authentication for Azure functions.

  3. 在要使用托管标识的触发器或操作中,指定以下属性值:In the trigger or action where you want to use the managed identity, specify these property values:

    属性(设计器)Property (designer) 属性 (JSON)Property (JSON) 必须Required ValueValue 说明Description
    身份验证Authentication type Yes 托管标识Managed Identity
    or
    ManagedServiceIdentity
    要使用的身份验证类型The authentication type to use
    托管标识Managed Identity identity Yes * 系统分配的托管标识* System Assigned Managed Identity
    or
    SystemAssigned

    * * <user-assigned-identity-name>

    要使用的托管标识The managed identity to use
    受众Audience audience Yes <target-resource-ID><target-resource-ID> 要访问的目标资源的资源 ID。The resource ID for the target resource that you want to access.

    例如,https://storage.azure.com/ 使用于身份验证的访问令牌对所有存储帐户都有效。For example, https://storage.azure.com/ makes the access tokens for authentication valid for all storage accounts. 但是,还可以为特定存储帐户指定根服务 URL,如 https://fabrikamstorageaccount.blob.core.chinacloudapi.cnHowever, you can also specify a root service URL, such as https://fabrikamstorageaccount.blob.core.chinacloudapi.cn for a specific storage account.

    注意:“受众”属性可能已在某些触发器或操作中隐藏。Note: The Audience property might be hidden in some triggers or actions. 若要显示此属性,请在触发器或操作中打开“添加新参数”列表,然后选择“受众” 。To make this property visible, in the trigger or action, open the Add new parameter list, and select Audience.

    重要说明:请确保此目标资源 ID 完全匹配 Azure AD 所需的值,包括任何必需的尾部反斜杠。Important: Make sure that this target resource ID exactly matches the value that Azure AD expects, including any required trailing slashes. 因此,所有 Azure Blob 存储帐户的 https://storage.azure.com/ 资源 ID 都需要尾部反斜杠。So, the https://storage.azure.com/ resource ID for all Azure Blob Storage accounts requires a trailing slash. 但是,特定存储帐户的资源 ID 不需要尾部斜杠。However, the resource ID for a specific storage account doesn't require a trailing slash. 若要查找这些资源 ID,请参阅支持 Azure AD 的 Azure 服务To find these resource IDs, see Azure services that support Azure AD.

    使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。When you use secured parameters to handle and secure sensitive information, for example, in an Azure Resource Manager template for automating deployment, you can use expressions to access these parameter values at runtime. 此示例 HTTP 操作定义将身份验证 type 指定为 ManagedServiceIdentity,并使用 parameters() 函数获取参数值:This example HTTP action definition specifies the authentication type as ManagedServiceIdentity and uses the parameters() function to get the parameter values:

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

阻止创建连接Block creating connections

如果组织不允许使用 Azure 逻辑应用中的连接器连接到特定资源,则可以在逻辑应用工作流中使用 Azure Policy 阻止为特定连接器创建这些连接的功能If your organization doesn't permit connecting to specific resources by using their connectors in Azure Logic Apps, you can block the capability to create those connections for specific connectors in logic app workflows by using Azure Policy. 有关详细信息,请参阅在 Azure 逻辑应用中阻止特定连接器创建的连接For more information, see Block connections created by specific connectors in Azure Logic Apps.

后续步骤Next steps