保护 Azure 逻辑应用中工作流的访问和数据
Azure 逻辑应用依赖 Azure 存储来存储和自动加密静态数据。 此加密可保护数据,并帮助你履行组织的安全性和符合性承诺。 默认情况下,Azure 存储使用 Microsoft 托管密钥来加密数据。 有关详细信息,请查看静态数据的 Azure 存储加密。
若要在 Azure 逻辑应用中进一步控制访问并保护敏感数据,可以在以下方面设置更多安全性:
- 对逻辑应用操作的访问
- 对运行历史记录输入和输出的访问
- 对参数输入的访问
- 支持身份验证的触发器和操作的身份验证类型
- 对基于请求的触发器的入站调用的访问
- 对其他服务和系统的出站调用的访问
- 阻止为特定连接器创建连接
- Azure 逻辑应用的 Azure 安全基线
有关 Azure 中的安全性的详细信息,请查看以下主题:
对逻辑应用操作的访问
对于消耗型逻辑应用,要创建或管理逻辑应用及其连接,你需要具有特定的权限,这些权限是使用 Azure 基于角色的访问控制 (Azure RBAC) 通过角色提供的。 你还可以设置权限,以便仅允许特定用户或组运行特定任务,例如管理、编辑和查看逻辑应用。 要控制其权限,你可以将内置或自定义角色分配给有权访问 Azure 订阅的成员。 Azure 逻辑应用具有以下特定角色,具体取决于你使用的是消耗型还是标准型逻辑应用工作流:
消耗型工作流
角色 | 说明 |
---|---|
逻辑应用参与者 | 可以管理逻辑应用工作流,但不能更改对它们的访问权限。 |
逻辑应用操作员 | 可以读取、启用和禁用逻辑应用工作流,但不能对其进行编辑或更新。 |
参与者 | 具有管理所有资源的完全访问权限,但不能在 Azure RBAC 中分配角色或在 Azure 蓝图中管理分配,也不能共享映像库。 |
例如,假设你必须使用并非你创建的逻辑应用工作流,并对该逻辑应用的工作流使用的连接进行身份验证。 Azure 订阅需要具备包含该逻辑应用资源的资源组的参与者权限。 如果创建逻辑应用资源,则会自动具有参与者访问权限。
要防止他人更改或删除逻辑应用工作流,可以使用 Azure 资源锁。 此功能可以防止他人更改或删除生产资源。 有关连接安全性的详细信息,请参阅 Azure 逻辑应用中的连接配置和连接安全性和加密。
标准型工作流
注意
此功能为预览版,受 Azure 预览版补充使用条款约束。
角色 | 说明 |
---|---|
标准型逻辑应用读取者(预览版) | 对标准型逻辑应用和工作流中的所有资源(包括工作流运行及其历史记录)具有只读访问权限。 |
标准型逻辑应用操作者(预览版) | 具有启用、重新提交和禁用工作流,以及为标准型逻辑应用创建与服务、系统和网络的连接的权限。 操作者角色可以在 Azure 逻辑应用平台上执行管理和支持任务,但无权编辑工作流或设置。 |
标准型逻辑应用开发者(预览版) | 具有为标准型逻辑应用创建和编辑工作流、连接和设置的权限。 开发者角色无权在工作流范围之外进行更改,例如配置虚拟网络集成等应用程序范围的更改。 不支持应用服务计划。 |
标准型逻辑应用参与者(预览版) | 具有管理标准型逻辑应用各个方面的权限,但不能更改访问权限或所有权。 |
对运行历史记录数据的访问
在逻辑应用运行期间,所有数据都是使用传输层安全性 (TLS) 在传输过程中加密的以及静态加密的。 运行逻辑应用后,可以查看该运行的历史记录,包括已运行的步骤以及每个操作的状态、持续时间、输入和输出。 此丰富的详细信息可让你深入了解逻辑应用的运行方式,以及开始解决出现的任何问题的位置。
查看逻辑应用的运行历史记录时,Azure 逻辑应用对该访问进行身份验证,然后提供指向每次运行的请求和响应的输入和输出的链接。 但是,对于处理任何密码、机密、密钥或其他敏感信息的操作,你需要阻止他人查看和访问该数据。 例如,如果逻辑应用从 Azure Key Vault 获取机密,以便在对 HTTP 操作进行身份验证时使用,则你需要在视图中隐藏该机密。
若要控制对逻辑应用运行历史记录中的输入和输出的访问,可使用以下选项:
-
此选项可帮助你基于来自特定 IP 地址范围的请求保护对运行历史记录的访问。
-
在许多触发器和操作中,可以保护逻辑应用的运行历史记录中的输入和/或输出。
按 IP 地址范围限制访问
可以限制对逻辑应用工作流的运行历史记录中的输入和输出的访问,以便只有来自特定 IP 地址范围的请求才能查看该数据。
例如,若要阻止任何人访问输入和输出,请指定类似于 0.0.0.0-0.0.0.0
的 IP 地址范围。 只有拥有管理员权限的人员才能移除此限制,使“实时”访问逻辑应用工作流中的数据成为可能。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
若要指定允许的 IP 范围,请执行以下针对 Azure 门户或 Azure 资源管理器模板中的消费型或标准逻辑应用的步骤:
消耗型工作流
在 Azure 门户中,打开设计器中的消耗逻辑应用工作流。
在逻辑应用菜单的“设置”下,选择“工作流设置”。
在“访问控制配置”部分中,在“允许的入站 IP 地址”下,从“触发器访问选项”列表中选择“特定 IP 范围”。
在“内容的 IP 范围”下,指定可以访问输入和输出内容的 IP 地址范围。
标准型工作流
在 Azure 门户中,打开你的标准逻辑应用资源。
在逻辑应用菜单的“设置”下,选择“网络”。
在“入站流量配置”部分,选择“公用网络访问”旁边的“启用且没有访问限制”。
在“访问限制”页上,在“应用访问”下,选择“从选择虚拟网络和 IP 地址启用”。
在“站点访问和规则”下,在“主站点”选项卡上,添加一个或多个规则以“允许”或“拒绝”来自特定 IP 范围的请求。 还可以使用 HTTP 标头筛选器设置和转发设置。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
有关详细信息,请参阅在 Azure 逻辑应用(标准型)中阻止入站 IP 地址。
使用模糊处理保护运行历史记录中的数据
许多触发器和操作具有用于保护逻辑应用的运行历史记录中的输入和/或输出的设置。 所有托管连接器和自定义连接器都支持这些选项。 但是,以下内置操作不支持这些选项:
安全输入 - 不受支持 | 安全输出 - 不受支持 |
---|---|
追加到数组变量 追加到字符串变量 递减变量 对每一个 如果 递增变量 初始化变量 定期 作用域 设置变量 Switch 终止 截止 |
追加到数组变量 追加到字符串变量 撰写 递减变量 对每一个 如果 递增变量 初始化变量 分析 JSON 定期 响应 作用域 设置变量 Switch 终止 截止 Wait |
保护输入和输出时的注意事项
在使用这些设置帮助保护此数据之前,请查看以下注意事项:
遮盖触发器或操作的输入或输出时,Azure 逻辑应用不会将安全数据发送到 Azure Log Analytics。 此外,不能将跟踪的属性添加到该触发器或操作进行监视。
用于处理工作流历史记录的 Azure 逻辑应用 API 不返回安全输出。
若要保护可遮盖输入或显式遮盖输出的操作的输出,请在该操作中手动打开“安全输出”。
请确保在你希望运行历史记录来遮盖该数据的下游操作中打开“安全输入”或“安全输出” 。
安全输出设置
在触发器或操作中手动启用“安全输出”时,Azure 逻辑应用会隐藏运行历史记录中的这些输出。 如果下游操作显式使用这些安全输出作为输入,则 Azure 逻辑应用会隐藏运行历史记录中的此操作的输入,但不会启用操作的“安全输入”设置。
“撰写”、“分析 JSON”和“响应”操作仅提供“保护输入”设置。 启用后,此设置也会隐藏这些操作的输出。 如果这些操作显式使用上游安全输出作为输入,则 Azure 逻辑应用会隐藏这些操作的输入和输出,但不会启用这些操作的“安全输入”设置。 如果下游操作显式使用来自撰写、分析 JSON 或响应操作的隐藏输出作为输入,则 Azure 逻辑应用不会隐藏此下游操作的输入或输出。
安全输入设置
在触发器或操作中手动打开“安全输入”时,Azure 逻辑应用会隐藏运行历史记录中的这些输入。 如果下游操作显式使用来自该触发器或操作的可见输出作为输入,则 Azure 逻辑应用将在运行历史记录中隐藏此下游操作的输入,但不会在此操作中启用“保护输入”,并且不会隐藏此操作的输出。
如果撰写、分析 JSON 和响应操作显式使用具有安全输入的触发器或操作的可见输出,则 Azure 逻辑应用会隐藏这些操作的输入和输出,但不会启用这些操作的“安全输入”设置。 如果下游操作显式使用来自撰写、分析 JSON 或响应操作的隐藏输出作为输入,则 Azure 逻辑应用不会隐藏此下游操作的输入或输出。
保护设计器中的输入和输出
在 Azure 门户中,打开设计器的逻辑应用工作流。
在设计器上,选择要在其中保护敏感数据的触发器或操作。
在打开的信息窗格中,选择“设置”,然后展开“安全性”。
打开“安全输入”和/或“安全输出” 。
触发器或操作现在显示标题栏中的锁图标。 表示以前操作的安全输出的令牌也显示锁图标。 例如,在后续操作中,为动态内容列表中的安全输出选择令牌后,该令牌将显示一个锁图标。
运行工作流后,可以查看该运行的历史记录。
保护代码视图中的输入和输出
在基础触发器或操作定义中,使用以下两个值中的一个或两个值添加或更新 runtimeConfiguration.secureData.properties
数组:
"inputs"
:在运行历史记录中保护输入。"outputs"
:保护运行历史记录中的输出。
"<trigger-or-action-name>": {
"type": "<trigger-or-action-type>",
"inputs": {
<trigger-or-action-inputs>
},
"runtimeConfiguration": {
"secureData": {
"properties": [
"inputs",
"outputs"
]
}
},
<other-attributes>
}
对参数输入的访问
如果跨不同的环境进行部署,请考虑参数化工作流定义中因这些环境而有所不同的值。 这样,便可以通过使用 Azure 资源管理器模板部署逻辑应用来避免使用硬编码数据,通过定义安全的参数来保护敏感数据,并使用参数文件通过模板的参数将该数据作为单独输入传递。
例如,如果使用 Microsoft Entra ID OAuth 对 HTTP 操作进行身份验证,则可以定义并保护接受用于身份验证的客户端 ID 和客户端机密的参数。 若要在逻辑应用工作流中定义这些参数,请使用逻辑应用的工作流定义中的 parameters
部分,以及用于部署的资源管理器模板。 若要帮助保护在编辑逻辑应用或查看运行历史记录时不希望显示的参数值,请使用 securestring
或 secureobject
类型定义参数并根据需要使用编码。 具有此类型的参数不会随资源定义一起返回,并且在部署后无法通过查看资源来访问这些参数。 若要在运行时访问这些参数值,请在工作流定义中使用 @parameters('<parameter-name>')
表达式。 此表达式仅在运行时进行计算,由工作流定义语言描述。
注意
如果在请求头或正文中使用参数,当查看工作流的运行历史记录和传出的 HTTP 请求时,该参数可能是可见的。 请务必同时相应地设置内容访问策略。 还可以使用模糊处理在运行历史记录中隐藏输入和输出。
默认情况下,Authorization
标头在输入或输出中是不可见的。
因此,如果在此处使用机密,则无法检索该机密。
有关详细信息,请查看本主题中的以下部分:
如果使用资源管理器模板自动执行逻辑应用部署,则可以使用 securestring
和 secureobject
类型定义在部署时计算的安全模板参数。 若要定义模板参数,请使用模板的顶级 parameters
节,该节不同于工作流定义的 parameters
节。 若要提供模板参数的值,请使用单独的参数文件。
例如,如果使用机密,则可以定义并使用可在部署时从 Azure Key Vault 检索这些机密的受保护模板参数。 然后,可以在参数文件中引用 Key Vault 和机密。 有关详细信息,请查看以下主题:
在工作流定义中保护参数(消耗型工作流)
若要在逻辑应用的工作流定义中保护敏感信息,请使用安全的参数,使该信息在保存逻辑应用工作流后不可见。 例如,假设某个 HTTP 操作需要使用用户名和密码进行基本身份验证。 在工作流定义中,parameters
节使用 securestring
类型定义 basicAuthPasswordParam
和 basicAuthUsernameParam
参数。 然后,操作定义将引用 authentication
节中的这些参数。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
}
在 Azure 资源管理器模板中保护参数(消耗型工作流)
逻辑应用资源和工作流的资源管理器模板包含多个 parameters
部分。 若要保护密码、密钥、机密和其他敏感信息,请使用 securestring
或 secureobject
类型在模板级别和工作流定义级别定义安全的参数。 然后,可将这些值存储在 Azure Key Vault 中,并使用参数文件来引用 Key Vault 和机密。 模板便会在部署时检索该信息。 有关详细信息,请查看使用 Azure Key Vault 在部署时传递敏感值。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
此列表包含有关这些 parameters
部分的更多信息:
在模板的最高级别,
parameters
节定义了模板在部署时使用的值的参数。 例如,这些值可能包含特定部署环境的连接字符串。 然后,你可将这些值存储在单独的参数文件中,以方便更改这些值。在逻辑应用的资源定义内部、工作流定义外部,
parameters
节指定了工作流定义参数的值。 在此节中,可以使用引用模板参数的模板表达式来分配这些值。 这些表达式将在部署时计算。在工作流定义中,
parameters
部分定义了逻辑应用工作流在运行时使用的参数。 然后,你可以使用在运行时计算的工作流定义表达式,在逻辑应用工作流中引用这些参数。
此示例模板包含使用 securestring
类型的多个受保护参数定义:
参数名称 | 说明 |
---|---|
TemplatePasswordParam |
一个模板参数,它接受随后要传递到工作流定义的 basicAuthPasswordParam 参数的密码 |
TemplateUsernameParam |
一个模板参数,它接受随后要传递到工作流定义的 basicAuthUserNameParam 参数的用户名 |
basicAuthPasswordParam |
一个工作流定义参数,它接受 HTTP 操作中用于基本身份验证的密码 |
basicAuthUserNameParam |
一个工作流定义参数,它接受 HTTP 操作中用于基本身份验证的用户名 |
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"LogicAppName": {
"type": "string",
"minLength": 1,
"maxLength": 80,
"metadata": {
"description": "Name of the Logic App."
}
},
"TemplatePasswordParam": {
"type": "securestring"
},
"TemplateUsernameParam": {
"type": "securestring"
},
"LogicAppLocation": {
"type": "string",
"defaultValue": "[resourceGroup().location]",
"allowedValues": [
"[resourceGroup().location]",
"chinaeast",
"chinanorth",
"chinaeast2",
"chinanorth2",
"chinanorth3"
],
"metadata": {
"description": "Location of the Logic App."
}
}
},
"variables": {},
"resources": [
{
"name": "[parameters('LogicAppName')]",
"type": "Microsoft.Logic/workflows",
"location": "[parameters('LogicAppLocation')]",
"tags": {
"displayName": "LogicApp"
},
"apiVersion": "2016-06-01",
"properties": {
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "https://www.microsoft.com",
"authentication": {
"type": "Basic",
"username": "@parameters('basicAuthUsernameParam')",
"password": "@parameters('basicAuthPasswordParam')"
}
},
"runAfter": {}
}
},
"parameters": {
"basicAuthPasswordParam": {
"type": "securestring"
},
"basicAuthUsernameParam": {
"type": "securestring"
}
},
"triggers": {
"manual": {
"type": "Request",
"kind": "Http",
"inputs": {
"schema": {}
}
}
},
"contentVersion": "1.0.0.0",
"outputs": {}
},
"parameters": {
"basicAuthPasswordParam": {
"value": "[parameters('TemplatePasswordParam')]"
},
"basicAuthUsernameParam": {
"value": "[parameters('TemplateUsernameParam')]"
}
}
}
}
],
"outputs": {}
}
支持身份验证的连接器的身份验证类型
下表列出了连接器操作中可用的身份验证类型,你可以在其中选择身份验证类型:
身份验证类型 | 逻辑应用和支持的连接器 |
---|---|
基本 | Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP Webhook |
客户端证书 | Azure API 管理、Azure 应用服务、HTTP、HTTP + Swagger、HTTP Webhook |
Active Directory OAuth(使用 Microsoft Entra ID 的 OAuth 2.0) | - 消耗:Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook - 标准:Azure 自动化、Azure Blob 存储、Azure 事件中心、Azure 队列、Azure 服务总线、Azure 表、HTTP、HTTP Webhook、SQL Server |
Raw | Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP + Swagger、HTTP Webhook |
托管的标识 | 内置连接器: - 消耗:Azure API 管理、Azure 应用服务、Azure Functions、HTTP、HTTP Webhook - 标准:Azure 自动化、Azure Blob 存储、Azure 事件中心、Azure 队列、Azure 服务总线、Azure 表、HTTP、HTTP Webhook、SQL Server 注意:目前,大多数基于服务提供商的内置连接器不支持选择用户分配的托管标识进行身份验证。 托管连接器:Azure 应用服务、Azure 自动化、Azure Blob 存储、Azure 容器实例、Azure Cosmos DB、Azure 数据资源管理器、Azure 数据工厂、Azure Data Lake、Azure 事件网格、Azure 事件中心、Azure IoT Central V2、Azure IoT Central V3、Azure 密钥保管库、Azure Log Analytics、Azure 队列、Azure 资源管理器、Azure 服务总线、Azure Sentinel、Azure 表存储、使用 Microsoft Entra ID 的 HTTP、SQL Server |
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
对基于请求的触发器的入站调用的访问
逻辑应用通过基于请求的触发器(例如请求触发器或 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
重要
对于向后兼容性,Azure 逻辑应用当前支持一些较旧的密码套件。 但是,请勿在开发新应用时使用较旧的密码套件,因为此类套件可能在未来不受支持 。
例如,如果你在 Azure 逻辑应用中检查 TLS 握手消息,或者使用逻辑应用 URL 上的安全工具,则可能会找到以下密码套件。 再次声明,请勿使用以下较旧的套件:
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_AES_256_GCM_SHA384
- TLS_RSA_WITH_AES_128_GCM_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA256
- TLS_RSA_WITH_AES_128_CBC_SHA256
- TLS_RSA_WITH_AES_256_CBC_SHA
- TLS_RSA_WITH_AES_128_CBC_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
你可以使用以下列表包括的方法限制对触发器(这些触发器接收对逻辑应用工作流的入站调用)的访问,以便只有经过授权的客户端才能调用工作流:
- 启用使用 Microsoft Entra ID 的 OAuth
- 生成共享访问签名 (SAS) 密钥或令牌
- 禁用共享访问签名 (SAS) 身份验证
- 限制入站 IP 地址
- 通过 Azure API 管理公开逻辑应用
启用使用 Microsoft Entra ID 的 OAuth 2.0
在以基于请求的触发器开头的消耗工作流中,可以通过启用使用 Microsoft Entra ID 的 OAuth 2.0,对发送到该触发器创建的终结点的入站调用进行身份验证和授权。 若要设置此身份验证,请在逻辑应用资源级别定义或添加授权策略。 这样,入站调用将使用 OAuth 访问令牌进行授权。
当你的逻辑应用工作流收到包含 OAuth 访问令牌的入站请求时,Azure 逻辑应用会将令牌的声明与每个授权策略指定的声明进行比较。 如果令牌的声明与至少一个策略中的所有声明之间存在匹配项,则入站请求的授权成功。 令牌的声明数可以大于授权策略指定的声明数。
在以请求触发器(但不是 Webhook 触发器)开始的标准工作流中,可使用 Azure Functions 预配,通过托管标识对发送到由该请求触发器创建的终结点的入站调用进行身份验证。 此预配也称为“简易身份验证”。 有关详细信息,请查看使用简易身份验证在标准逻辑应用中触发工作流。
启用 使用 Microsoft Entra ID 的 OAuth 2.0 之前的注意事项
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
在消耗工作流中,对基于请求的触发器的终结点 URL 的入站调用只能使用一个授权方案,即使用 Microsoft Entra ID 的 OAuth 2.0 或 共享访问签名 (SAS) 二者之一。 尽管使用一个方案不会禁用另一个方案,但如果同时使用这两种方案,Azure 逻辑应用会生成错误,因为服务不知道要选择哪个方案。 如果消耗工作流以请求触发器开头,则可以禁用 SAS 身份验证,并限制授权以仅使用 使用 Microsoft Entra ID 的 OAuth 2.0。 对于标准工作流,无需禁用 SAS 即可使用其他身份验证类型。
Azure 逻辑应用支持 Microsoft Entra ID OAuth 访问令牌的授权方案持有者类型或所有权证明类型(仅消耗型逻辑应用)。 但是,
Authorization
访问令牌的标头必须指定Bearer
类型或PoP
类型。 有关如何获取和使用 PoP 令牌的详细信息,请参阅获取所有权证明 (PoP) 令牌。消耗逻辑应用资源限制为最大授权策略数。 每个授权策略还具有最大声明数。 有关详细信息,请参阅 Azure 逻辑应用的限制和配置。
授权策略必须至少包含“颁发者”声明,该声明作为 Microsoft Entra ID 的颁发者,以
https://sts.chinacloudapi.cn/
或https://login.chinacloudapi.cn/
(OAuth V2) 开头。例如,假定逻辑应用资源有一个需要两个声明类型(“受众”和“颁发者”)的授权策略。 解码的访问令牌的此示例有效负载部分包括两种声明类型,其中
aud
是受众值,iss
是颁发者值:{ "aud": "https://management.core.chinacloudapi.cn/", "iss": "https://sts.chinacloudapi.cn/<Azure-AD-issuer-ID>/", "iat": 1582056988, "nbf": 1582056988, "exp": 1582060888, "_claim_names": { "groups": "src1" }, "_claim_sources": { "src1": { "endpoint": "https://graph.chinacloudapi.cn/7200000-86f1-41af-91ab-2d7cd011db47/users/00000-f433-403e-b3aa-7d8406464625d7/getMemberObjects" } }, "acr": "1", "aio": "AVQAq/8OAAAA7k1O1C2fRfeG604U9e6EzYcy52wb65Cx2OkaHIqDOkuyyr0IBa/YuaImaydaf/twVaeW/etbzzlKFNI4Q=", "amr": [ "rsa", "mfa" ], "appid": "c44b4083-3bb0-00001-b47d-97400853cbdf3c", "appidacr": "2", "deviceid": "bfk817a1-3d981-4dddf82-8ade-2bddd2f5f8172ab", "family_name": "Sophia Owen", "given_name": "Sophia Owen (Fabrikam)", "ipaddr": "167.220.2.46", "name": "sophiaowen", "oid": "3d5053d9-f433-00000e-b3aa-7d84041625d7", "onprem_sid": "S-1-5-21-2497521184-1604012920-1887927527-21913475", "puid": "1003000000098FE48CE", "scp": "user_impersonation", "sub": "KGlhIodTx3XCVIWjJarRfJbsLX9JcdYYWDPkufGVij7_7k", "tid": "72f988bf-86f1-41af-91ab-2d7cd011db47", "unique_name": "SophiaOwen@fabrikam.com", "upn": "SophiaOwen@fabrikam.com", "uti": "TPJ7nNNMMZkOSx6_uVczUAA", "ver": "1.0" }
启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用请求终结点的唯一选项(仅消耗)
对于基于请求的终结点,可以将授权限制为仅使用使用 Microsoft Entra ID 的 OAuth 2.0。 即使禁用共享访问签名 (SAS) 身份验证,此选项也能正常工作。
对于消耗工作流,请按照在请求触发器或 HTTP Webhook 触发器输出中包含“Authorization”标头的步骤,设置请求或 HTTP Webhook 触发器,以检查 OAuth 访问令牌的功能。
注意
此步骤使
Authorization
标头在工作流的运行历史记录和触发器的输出中可见。在 Azure 门户中,打开设计器中的消耗工作流。
在设计器上,选择触发器。 在打开的信息窗格中,选择“设置”。
在“常规”>“触发条件”下,选择“添加”。 在“触发条件”框中,根据要使用的令牌类型输入以下表达式之一:
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'Bearer')
-或-
@startsWith(triggerOutputs()?['headers']?['Authorization'], 'PoP')
如果在没有正确授权的情况下调用触发器终结点,则运行历史记录只将触发器显示为 Skipped
,而不会显示有关触发器条件失败的任何消息。
获取所有权证明 (PoP) 令牌
Microsoft 身份验证库 (MSAL) 库提供 PoP 令牌供你使用。 如果要调用的消耗逻辑应用工作流需要 PoP 令牌,可以使用 MSAL 库获取此令牌。 以下示例演示如何获取 PoP 令牌:
若要将 PoP 令牌用于消耗逻辑应用工作流,请按照以下步骤设置使用 Microsoft Entra ID 的 OAuth。
为消耗逻辑应用资源启用使用 Microsoft Entra ID 的 OAuth
若要将授权策略添加到消耗逻辑应用,请遵循 Azure 门户或 Azure 资源管理器模板的步骤:
在 Azure 门户中,打开设计器中的消耗型逻辑应用和工作流。
在逻辑应用菜单的“设置”下,选择“授权” 。
在“授权”页上,选择“添加策略”。
在每次对请求触发器进行入站调用时提供的访问令牌中,逻辑应用需要一些声明类型和值,通过指定这些声明类型和值来提供有关授权策略的信息:
properties 必须 类型 说明 策略名称 是 String 要用于授权策略的名称 策略类型 是 字符串 表示持有者类型令牌的 AAD 或表示所有权证明类型令牌的 AADPOP。 申请 是 字符串 一个键值对,指定工作流的请求触发器在每次对触发器的入站调用所提供的访问令牌中所需的声明类型和值。 可以通过选择“添加标准声明”来添加所需的任何标准声明。 若要添加特定于 PoP 令牌的声明,请选择“添加自定义声明”。
可用的标准声明类型:
- 颁发者
- 受众
- 主题
- JWT ID(JSON Web 令牌标识符)
要求:
-“声明”列表必须至少包含“颁发者”声明,该声明的值(作为 Microsoft Entra 颁发者 ID)以https://sts.chinacloudapi.cn/
或https://login.chinacloudapi.cn/
开头。
- 每个声明必须是单个字符串值,而不是值的数组。 例如,可以有“Role”作为类型,“Developer”作为值的声明。 不能有将“Role”作为类型并将值设置为“Developer”和“Program Manager”的声明。
- 声明值将限制为最大字符数。
有关这些声明类型的详细信息,请参阅 Microsoft Entra 安全令牌中的声明。 你还可以指定自己的声明类型和值。以下示例显示了 PoP 令牌的信息:
若要添加其他声明,请从以下选项中进行选择:
若要添加其他声明类型,请选择“添加标准声明”,选择声明类型,并指定声明值。
若要添加你自己的声明,请选择“添加自定义声明”。 有关详细信息,请查看如何向应用提供可选声明。 然后,自定义声明将存储为 JWT ID 的一部分;例如
"tid": "72f988bf-86f1-41af-91ab-2d7cd011db47"
。
若要添加其他授权策略,请选择“添加策略”。 重复前面的步骤以设置策略。
完成后,选择“保存”。
若要在基于请求的触发器输出中包含访问令牌的
Authorization
标头,请查看在请求和 HTTP Webhook 触发器输出中包含“Authorization”标头。
工作流属性(例如策略)不会显示在 Azure 门户上工作流的代码视图中。 若要以编程方式访问策略,请通过 Azure 资源管理器调用以下 API:https://management.chinacloudapi.cn/subscriptions/{Azure-subscription-ID}/resourceGroups/{Azure-resource-group-name}/providers/Microsoft.Logic/workflows/{your-workflow-name}?api-version=2016-10-01&_=1612212851820
。 请务必替换 Azure 订阅 ID、资源组名称和工作流名称的占位符值。
在请求或 HTTP Webhook 触发器输出中包括“Authorization”标头
如果逻辑应用启用 Microsoft Entra ID OAuth 来授权入站调用访问基于请求的触发器,则你可以使请求触发器或 HTTP Webhook 触发器输出包含 OAuth 访问令牌的 Authorization
标头。 在触发器的基础 JSON 定义中,添加 operationOptions
属性并将其设置为 IncludeAuthorizationHeadersInOutputs
。 下面是请求触发器的示例:
"triggers": {
"manual": {
"inputs": {
"schema": {}
},
"kind": "Http",
"type": "Request",
"operationOptions": "IncludeAuthorizationHeadersInOutputs"
}
}
有关详细信息,请查看以下主题:
生成共享访问签名 (SAS) 密钥或令牌
当工作流以基于请求的触发器开头,并且首次保存该工作流时,Azure 逻辑应用在该触发器上创建可调用的终结点。 此终结点具有可以接收入站调用或启动工作流的请求的 URL。 URL 包括共享访问签名 (SAS),这是授予存储服务权限的密钥或令牌。 此终结点 URL 使用以下格式:
https://<request-endpoint-URI>sp=<permissions>sv=<SAS-version>sig=<signature>
例如,若要在"请求"触发器中查看此 URL,请查找触发器的 HTTP URL 属性:
完整的 URL 如以下示例所示:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
URL 中的 SAS 具有查询参数,下表描述了这些参数:
查询参数 | 说明 |
---|---|
sp |
指定允许使用的 HTTP 方法的权限。 |
sv |
指定用于生成签名的 SAS 版本。 |
sig |
指定用于对触发器访问进行身份验证的签名。 此签名是使用 SHA256 算法生成的,所有 URL 路径和属性中都包含机密访问密钥。 此密钥保持机密和加密状态,使用逻辑应用进行存储,并且永远不会公开或发布。 逻辑应用仅向那些包含有效签名(使用密钥创建)的触发器授权。 |
注意
请确保保护 SAS,就像保护帐户密钥免受未经授权的使用一样。 设置或制定计划以撤销已泄露的 SAS 密钥。 在分发 SAS URI 时采用自由裁量权,仅通过安全连接(如 HTTPS)分发 SAS URI。 请确保仅执行通过 HTTPS 连接使用 SAS 的操作。
如果使用 SAS 访问存储服务,Microsoft 建议创建用户委派 SAS,该 SAS 使用Microsoft Entra ID 受到保护,而不是帐户密钥。
基于请求的触发器对终结点的入站调用只能使用一个授权方案,即 SAS 或使用 Microsoft Entra ID 的 OAuth 2.0 二者之一。 尽管使用一个方案不会禁用另一个方案,但同时使用这两个方案会导致错误,因为逻辑应用服务不知道要选择哪个方案。
如果消耗工作流以“请求”触发器开头,则可以禁用 SAS 身份验证。 即使将授权限制为仅使用 Microsoft Entra ID 的 OAuth 2.0,此选项也可正常工作。 对于标准工作流,无需禁用 SAS 即可使用其他身份验证类型。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
有关使用 SAS 的详细信息,请参阅本指南中的以下部分:
禁用共享访问签名 (SAS) 身份验证(仅消耗)
默认情况下,基于请求的触发器已启用 SAS 身份验证。 触发器的终结点 URL 包括一个 SAS,从查询参数 sp-<permissions>sv-<SAS-version>sig=<signature>
开始,例如:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
如果消耗工作流以“请求”触发器开头,并且想要使用使用 Microsoft Entra ID 的 OAuth,则可以禁用 SAS 身份验证以避免运行工作流时出现错误和问题。 还可以通过删除对机密的依赖项来添加安全层,从而降低记录或泄露机密的风险。
即使还启用使用 Microsoft Entra ID 的 OAuth 2.0 作为调用基于请求的终结点的唯一选项,此选项也可正常工作。 对于标准工作流,无需禁用 SAS 即可使用其他身份验证类型。
注意
此操作将禁用传入请求的 SAS 身份验证,并阻止现有 SAS 令牌或签名正常工作。 但是,如果再次启用 SAS 身份验证,SAS 令牌或签名仍然有效,仍会工作。 若要禁用 SAS 令牌和签名,请参阅“重新生成访问密钥”。
禁用 SAS 身份验证后,"请求"触发器的终结点 URL 不再包含 SAS 密钥,例如:
https://{domain}:443/workflows/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX/triggers/When_a_HTTP_request_is_received/paths/invoke?api-version=2016-10-01
先决条件
对于此任务,需要一个发送 REST API 调用的工具,例如:
注意
对于具有敏感数据(例如凭据、机密、访问令牌、API 密钥和其他类似信息)的情况,请务必使用具有必要安全功能可保护数据的工具,该工具可脱机或本地工作,不会将数据同步到云,并且不需要登录联机帐户。 这样可以降低向公众公开敏感数据的风险。
检查是否启用或禁用 SAS 的触发器
禁用 SAS 身份验证后,触发器的终结点 URL 不再包含 SAS 密钥。 此外,消耗工作流定义包括 sasAuthenticationPolicy JSON 对象。 此对象具有设置为 Disabled 的状态属性,例如:
"properties": {
"accessControl": {
"triggers": {
"sasAuthenticationPolicy": {
"state": "Disabled"
}
}
}
}
若要查找已启用或禁用 SAS 的消耗工作流,请检查工作流定义是否包括 sasAuthenticationPolicy 对象,其中状态属性设置为“已禁用” 。
使用发送 REST API 调用的工具,通过运行 工作流 - 获取操作来获取有关您的工作流程的信息,例如使用以下 GET 请求:
GET https://management.chinacloudapi.cn/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
获取工作流 - 获取操作的输出,并检查 sasAuthenticationPolicy 对象是否存在,其中状态 属性设置为 Disabled。
将 sasAuthenticationPolicy 属性添加到工作流定义
对于想要禁用 SAS 身份验证的消耗工作流,请执行以下步骤:
如果尚未执行此操作,请通过运行 工作流 - 获取操作来获取有关您的工作流程的信息,例如使用以下 GET 请求:
GET https://management.chinacloudapi.cn/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
获取工作流 - 获取操作的输出,并手动添加以下元素:
在
properties
对象中,添加包含triggers
对象的accessControl
对象(如果不存在)。在
triggers
对象中,添加一个sasAuthenticationPolicy
对象,该对象包含设置为Disabled
的state
属性。
完成后,编辑的部件如以下示例所示:
"properties": { "accessControl": { "triggers": { "sasAuthenticationPolicy": { "state": "Disabled" } } } }
通过使用以下 PATCH 请求,运行 工作流 - 更新操作,以使用编辑的输出(用作请求正文中的输入)发送另一个请求,例如:
PATCH https://management.chinacloudapi.cn/subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}?api-version=2016-06-01
在 Azure 门户中,转到设计器中的消耗工作流,并确认“请求”触发器的 URL 不再包含 SAS。
若要在逻辑应用资源级别启用使用 Microsoft Entra ID 的 Oauth 2.0,请为使用 Microsoft Entra ID 的 OAuth 2.0 添加授权策略。
有关详细信息,请参阅启用使用 Microsoft Entra ID 的 OAuth 2.0。
重新生成访问密钥
若要随时生成新的安全访问密钥,请使用 Azure REST API 或 Azure 门户。 以前使用旧密钥生成的所有 URL 已失效,不再有权触发逻辑应用。 重新生成后检索的 URL 将使用新访问密钥进行签名。
在 Azure 门户中,打开包含要重新生成密钥的逻辑应用。
在逻辑应用资源菜单中的“设置”下,选择“访问密钥”。
选择要重新生成的密钥并完成生成过程。
创建具有到期日期的回调 URL
如果与其他各方共享基于请求的触发器的终结点 URL,可以生成使用特定密钥并具有过期日期的回调 URL。 这样,就可以无缝滚动更新密钥,或者根据特定的时间跨度将触发逻辑应用的访问限制。 若要为 URL 指定到期日期,请使用 Azure 逻辑应用 REST API,例如:
POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01
在正文中,使用 JSON 日期字符串包含 NotAfter
属性。 该属性返回仅在 NotAfter
日期和时间之前有效的回调 URL。
创建附带主密钥或辅助密钥的 URL
生成或列出基于请求的触发器的回调 URL 时,可以指定用于对 URL 进行签名的密钥。 若要生成由特定密钥签名的 URL,请使用 Azure 逻辑应用 REST API,例如:
POST /subscriptions/{subscription-ID}/resourceGroups/{resource-group-name}/providers/Microsoft.Logic/workflows/{workflow-name}/triggers/{trigger-name}/listCallbackUrl?api-version=2016-06-01
在正文中,包含值为 Primary
或 Secondary
的 KeyType
属性。 此属性返回由指定的安全密钥签名的 URL。
通过 Azure API 管理公开逻辑应用工作流
有关更多身份验证协议和选项,请考虑使用 Azure API 管理将逻辑应用工作流公开为 API。 此服务可为任何终结点提供丰富的监视、安全性、策略和文档功能。 API 管理可以公开逻辑应用的公共或专用终结点。 若要授予对此终结点的访问权限,可以使用 Microsoft Entra ID OAuth、客户端证书或其他安全标准来实现授权。 当 API Management 收到请求时,此服务会将请求发送到逻辑应用,并会进行任何必要的转换或限制。 若要仅让 API 管理调用你的逻辑应用工作流,可以限制逻辑应用的入站 IP 地址。
有关详细信息,请参阅以下文档:
- 关于 API 管理
- 在 Azure API 管理中使用 OAuth 2.0 授权和 Microsoft Entra ID 保护 Web API 后端
- 使用 API 管理中的客户端证书身份验证确保 API 安全
- API 管理身份验证策略
限制入站 IP 地址
除了共享访问签名 (SAS) 外,你还需要特别限制可调用逻辑应用工作流的客户端。 例如,如果使用 Azure API 管理来管理请求终结点,则可将逻辑应用工作流限制为仅接受来自你创建的 API 管理服务实例的 IP 地址的请求。
无论指定的 IP 地址如何,都仍可通过工作流触发器 - 运行操作请求或 API 管理来运行具有基于请求的触发器的逻辑应用工作流。 不过,这种情况下仍需要针对 Azure REST API 进行身份验证。 所有事件都会显示在 Azure 审核日志中。 请确保相应地设置访问控制策略。
若要限制逻辑应用工作流的入站 IP 地址,请针对 Azure 门户或 Azure 资源管理器模板执行相应步骤。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
在 Azure 门户中,IP 地址限制会影响触发器和操作,这与门户中“允许的入站 IP 地址”下的说明相反。 若要为触发器和操作单独设置此筛选器,请在 Azure 资源管理器模板中为逻辑应用资源使用 accessControl
对象,或使用 Azure 逻辑应用 REST API 中的 工作流 - 创建或更新 操作。
消耗型工作流
在 Azure 门户中,在工作流设计器中打开消耗逻辑应用。
在逻辑应用菜单的“设置”下,选择“工作流设置”。
在“访问控制配置”部分的“允许的入站 IP 地址”下,选择方案的路径:
若要通过 Azure 逻辑应用内置操作使工作流可供调用(但仅作为嵌套工作流进行调用),请选择“仅其他逻辑应用”。 仅当使用 Azure 逻辑应用操作调用嵌套工作流时,此选项才有效。
此选项会将一个空数组写入逻辑应用资源,并要求只有使用内置 Azure 逻辑应用操作的父工作流发出的调用才能触发嵌套工作流。
若要通过 HTTP 操作使工作流可供调用(但仅作为嵌套工作流进行调用),请选择“特定 IP 范围”。 出现“触发器的 IP 范围”框时,请输入父工作流的出站 IP 地址。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
备注
如果使用“仅限其他逻辑应用”选项和 HTTP 操作来调用嵌套工作流,调用将被阻止,并出现“401 未授权”错误。
如果你想要限制来自其他 IP 的入站调用,当“触发器的 IP 范围”框出现时,请指定触发器接受的 IP 地址范围。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
(可选)在“仅限提供的 IP 地址发出从运行历史记录中获取输入和输出消息的调用”下,可以指定能够访问运行历史记录中输入和输出消息的入站调用的 IP 地址范围。
标准型工作流
在 Azure 门户中,打开你的标准逻辑应用资源。
在逻辑应用菜单的“设置”下,选择“网络”。
在“入站流量配置”部分,选择“公用网络访问”旁边的“启用且没有访问限制”。
在“访问限制”页上,在“应用访问”下,选择“从选择虚拟网络和 IP 地址启用”。
在“站点访问和规则”下,在“主站点”选项卡上,添加一个或多个规则以“允许”或“拒绝”来自特定 IP 范围的请求。 有效的 IP 范围使用这些格式:x.x.x.x/x 或 x.x.x.x-x.x.x.x
有关详细信息,请参阅在 Azure 逻辑应用(标准型)中阻止入站 IP 地址。
对其他服务和系统的出站调用的访问
根据目标终结点的功能,HTTP 触发器或 HTTP 操作发送的出站调用支持加密,并使用传输层安全性 (TLS) 1.0、1.1 或 1.2(以前称为安全套接字层 (SSL))进行保护。 Azure 逻辑应用会就是否使用受支持的最高可能版本一事与目标终结点进行协商。 例如,如果目标终结点支持 1.2 版,则 HTTP 触发器或操作会首先使用 1.2 版。 否则,连接器将使用下一个受支持的最高版本。
此列表包括有关 TLS/SSL 自签名证书的信息:
对于多租户 Azure 逻辑应用环境中的消耗型逻辑应用工作流,HTTP 操作不允许自签名的 TLS/SSL 证书。 如果你的逻辑应用向服务器发出 HTTP 调用并提供了 TLS/SSL 自签名证书,则 HTTP 调用将失败并出现
TrustFailure
错误。对于单租户 Azure 逻辑应用环境中的标准逻辑应用工作流,HTTP 操作支持自签名的 TLS/SSL 证书。 但是,必须为此身份验证类型完成一些额外的步骤。 否则,调用会失败。 有关详细信息,请参阅单租户 Azure 逻辑应用的 TLS/SSL 证书身份验证。
如果要将客户端证书或 Microsoft Entra ID OAuth 与“证书”凭据类型一起使用,则仍必须为此身份验证类型完成一些额外的步骤。 否则,调用会失败。 有关详细信息,请参阅单租户 Azure 逻辑应用的客户端证书或凭据类型为“证书”的 Microsoft Entra ID OAuth。
下面提供了更多方法,它们有助于保护对逻辑应用工作流发送的调用进行处理的终结点:
-
当使用 HTTP 触发器或操作来发送出站调用时,可以针对逻辑应用发送的请求添加身份验证。 例如,可以选择以下身份验证类型:
限制来自逻辑应用工作流 IP 地址的访问。
从逻辑应用工作流对终结点进行的所有调用都源自基于逻辑应用所在区域的具体指定 IP 地址。 可以添加仅接受来自这些 IP 地址的请求的筛选规则。 若要获取这些 IP 地址,请查看 Azure 逻辑应用的限制和配置。
提高与本地系统的连接的安全性。
Azure 逻辑应用可与这些服务集成,来帮助提供更安全可靠的本地通信。
本地数据网关
Azure 逻辑应用中的许多托管连接器都可以安全连接到本地系统,例如,文件系统、SQL、SharePoint 和 DB2。 网关通过 Azure 服务总线发送来自加密通道上的本地源的数据。 所有流量最初都是网关代理的安全出站流量。 了解本地数据网关的工作原理。
通过 Azure API 管理进行连接
Azure API 管理提供本地连接选项,例如站点到站点虚拟专用网络和 ExpressRoute 集成,用于保护代理和与本地系统的通信。 如果你有一个可访问本地系统的 API,并通过创建 API 管理服务实例公开了该 API,那么可以在工作流设计器中选择相应的 API 管理操作,从逻辑应用的工作流中调用该 API。
注意
连接器仅显示那些你有权在其中进行查看和连接操作的 API 管理服务,但不显示基于消耗的 API 管理服务。
根据逻辑应用资源类型,执行相应的步骤:
消耗型工作流
根据要添加的是 API 管理触发器还是操作,请按照以下步骤操作:
触发器:
在工作流设计器上,选择“添加触发器”。
“添加触发器”窗格打开后,在搜索框中输入“API 管理”。
从触发器结果列表中选择”选择 Azure API 管理触发器”。
操作:
在工作流设计器上,选择要在其中添加操作的加号 (+)。
“添加操作”窗格打开后,在搜索框中输入“API 管理”。
从操作结果列表中选择”选择 Azure API 管理操作”。
以下示例演示如何查找 Azure API 管理触发器:
从 API 管理服务实例列表中,选择之前创建的 API 管理服务实例。
从 API 操作列表中选择要调用的 API 操作,然后选择“添加操作”。
标准型工作流
对于标准工作流,只能添加“API 管理”操作,而不能添加触发器。
针对出站调用添加身份验证
HTTP 和 HTTPS 终结点支持各种身份验证。 在用于向这些终结点发送出站调用或请求的某些触发器和操作上,可以指定身份验证类型。 在工作流设计器中,支持选择身份验证类型的触发器和操作具有“身份验证”属性。 但是,此属性可能并不总会默认显示。 在这种情况下,请在触发器或操作中打开“高级参数”列表,然后选择“身份验证”。
重要
若要保护你的逻辑应用工作流处理的敏感信息,请使用受保护的参数,并根据需要对数据进行编码。 有关使用和保护参数的详细信息,请查看对参数输入的访问。
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
基本身份验证
对于 HTTP 调用,基本身份验证使用 base64 编码的字符串,其中包含用户名和密码发出请求。 除非将此选项用于 HTTPS/SSL 协议,否则此方法传输不加密的凭据,并带来更高的安全风险。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
如果基本选项可用并选中,请指定以下属性值:
属性(设计器) | 属性 (JSON) | 必须 | 值 | 说明 |
---|---|---|---|---|
身份验证 | type |
是 | 基本 | 要使用的身份验证类型 |
用户名 | username |
是 | <user-name> | 用于对目标服务终结点访问进行身份验证的用户名 |
密码 | password |
是 | <password> | 用于对目标服务终结点访问进行身份验证的密码 |
使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。 此示例 HTTP 操作定义将身份验证 type
指定为 Basic
,并使用 parameters() 函数获取参数值:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Basic",
"username": "@parameters('userNameParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
客户端证书身份验证
客户端证书身份验证允许或要求用户使用 X.509 证书直接向其 Microsoft Entra ID 进行身份验证,以便应用程序和浏览器登录。 此功能可帮助你采用防钓鱼身份验证,并使用针对公钥基础结构 (PKI) 的 X.509 证书进行身份验证。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
如果客户端证书选项可用并选择,请指定以下属性值:
属性(设计器) | 属性 (JSON) | 必须 | 值 | 说明 |
---|---|---|---|---|
身份验证 | type |
是 | 客户端证书 或 ClientCertificate |
可使用的身份验证类型。 可以使用 Azure API 管理来管理证书。 注意:对于入站和出站调用,自定义连接器不支持基于证书的身份验证。 |
Pfx | pfx |
是 | <encoded-pfx-file-content> | 个人信息交换 (PFX) 文件中的 base64 编码内容 若要将 PFX 文件转换为 base64 编码格式,可以使用 PowerShell 7 并执行以下步骤: 1.将证书内容保存到某个变量中: $pfx_cert = [System.IO.File]::ReadAllBytes('c:\certificate.pfx') 2.使用 ToBase64String() 函数转换证书内容,并将该内容保存到某个文本文件中:[System.Convert]::ToBase64String($pfx_cert) | Out-File 'pfx-encoded-bytes.txt' 故障排除:如果使用 cert mmc/PowerShell 命令,可能会出现以下错误:Could not load the certificate private key. Please check the authentication certificate password is correct and try again. 若要解决此错误,请尝试使用 openssl 命令将 PFX 文件转换为 PEM 文件,再转换回来:openssl pkcs12 -in certificate.pfx -out certificate.pem openssl pkcs12 -in certificate.pem -export -out certificate2.pfx 然后,在获得证书的新转换 PFX 文件的 base64 编码字符串后,便可以在 Azure 逻辑应用中使用该字符串。 |
密码 | password |
否 | <password-for-pfx-file> | 用于访问 PFX 文件的密码 |
注意
如果尝试使用 OpenSSL 通过客户端证书进行身份验证,可能会收到以下错误:
BadRequest: Could not load private key
若要解决此错误,请执行以下步骤:
- 卸载所有 OpenSSL 实例。
- 安装 OpenSSL 版本 1.1.1t。
- 使用新的更新重新为证书签名。
- 使用客户端证书身份验证时,将新证书添加到 HTTP 操作。
使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。 此示例 HTTP 操作定义将身份验证 type
指定为 ClientCertificate
,并使用 parameters() 函数获取参数值:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ClientCertificate",
"pfx": "@parameters('pfxParam')",
"password": "@parameters('passwordParam')"
}
},
"runAfter": {}
}
重要
如果你在单租户 Azure 逻辑应用中具有标准逻辑应用资源,并且想要使用带有 TSL/SSL 证书、客户端证书或凭据类型为 Certificate
的 Microsoft Entra ID Open Authorization (Microsoft Entra ID OAuth),请确保为此身份验证类型完成额外的设置步骤。 否则,调用会失败。 有关详细信息,请参阅单租户环境中的身份验证。
有关使用客户端证书身份验证保护服务的详细信息,请查看以下主题:
- 使用 Azure API 管理中的客户端证书身份验证提高 API 的安全性
- 使用 Azure API 管理中的客户端证书身份验证提高后端服务的安全性
- 应用程序身份验证的证书凭据
- 在 Azure 应用服务中通过代码使用 TLS/SSL 证书
Microsoft Entra 平台
在 请求 触发器上,可以在为逻辑应用设置 Microsoft Entra 授权策略 后,使用 Microsoft Entra 平台 对传入调用进行身份验证。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
对于支持 Active Directory OAuth(使用 Microsoft Entra ID 的 OAuth 2.0)身份验证类型的所有其他触发器和操作,请指定以下属性值:
属性(设计器) | 属性 (JSON) | 必须 | 值 | 说明 |
---|---|---|---|---|
身份验证 | type |
是 | Active Directory OAuth(使用 Microsoft Entra ID 的 OAuth 2.0) 或 ActiveDirectoryOAuth |
可使用的身份验证类型。 Azure 逻辑应用当前遵循 OAuth 2.0 协议。 |
颁发机构 | authority |
否 | <URL-for-authority-token-issuer> | 提供访问令牌的颁发机构的 URL,例如 Azure 全球服务区域的 https://login.chinacloudapi.cn/ 。 对于其他国家云,请查看 Microsoft Entra 身份验证终结点 - 选择标识颁发机构。 |
租户 | tenant |
是 | <tenant-ID> | Microsoft Entra 租户的租户 ID。 |
受众 | audience |
是 | <resource-to-authorize> | 要用于授权的资源,例如 https://management.core.chinacloudapi.cn/ |
客户端 ID | clientId |
是 | <client-ID> | 请求授权的应用的客户端 ID |
凭据类型 | credentialType |
是 | 证书 或 机密 |
客户端用来请求授权的凭据类型。 此属性和值不会显示在逻辑应用的基础定义中,但确定了为选定凭据类型显示的属性。 |
机密 | secret |
是,但仅适用于“机密”凭据类型 | <client-secret> | 用于请求授权的客户端密码 |
Pfx | pfx |
是,但仅适用于“证书”凭据类型 | <encoded-pfx-file-content> | 个人信息交换 (PFX) 文件中的 base64 编码内容 |
密码 | password |
是,但仅适用于“证书”凭据类型 | <password-for-pfx-file> | 用于访问 PFX 文件的密码 |
使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。 此示例 HTTP 操作定义将身份验证 type
指定为 ActiveDirectoryOAuth
,将凭据类型指定为 Secret
,并使用 parameters() function 获取参数值:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "ActiveDirectoryOAuth",
"tenant": "@parameters('tenantIdParam')",
"audience": "https://management.core.chinacloudapi.cn/",
"clientId": "@parameters('clientIdParam')",
"credentialType": "Secret",
"secret": "@parameters('secretParam')"
}
},
"runAfter": {}
}
重要
如果在单租户 Azure 逻辑应用中有标准逻辑应用资源,并且想要使用带有 TSL/SSL 证书、客户端证书或凭据类型为 Certificate
的 Microsoft Entra ID OAuth,请确保为此身份验证类型完成额外的设置步骤。 否则,调用会失败。 有关详细信息,请参阅单租户环境中的身份验证。
原始身份验证
如果原始选项可用,在必须使用不遵循 OAuth 2.0 协议的身份验证方案时,可以使用此身份验证类型。 使用此类型可以手动创建要与传出请求一起发送的授权标头值,并指定触发器或操作中的标头值。
重要
为了获得最佳安全性,Microsoft 建议尽可能使用具有托管标识的 Microsoft Entra ID 进行身份验证。 此选项提供卓越的安全性,无需提供凭据。 Azure 负责管理此标识并帮助保护身份验证信息的安全,这样你就无需管理这种敏感信息了。 若要为 Azure 逻辑应用设置托管标识,请参阅“使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问和连接进行身份验证”。
以下示例显示了遵循 OAuth 1.0 协议的 HTTPS 请求的示例标头:
Authorization: OAuth realm="Photos",
oauth_consumer_key="dpf43f3p2l4k3l03",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="137131200",
oauth_nonce="wIjqoS",
oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",
oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
在支持原始身份验证的触发器或操作中指定以下属性值:
属性(设计器) | 属性 (JSON) | 必须 | 值 | 说明 |
---|---|---|---|---|
身份验证 | type |
是 | 原始 | 要使用的身份验证类型 |
值 | value |
是 | <authorization-header-value> | 要用于身份验证的授权标头值 |
使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。 此示例 HTTP 操作定义将身份验证 type
指定为 Raw
并使用 parameters() function 获取参数值:
"HTTP": {
"type": "Http",
"inputs": {
"method": "GET",
"uri": "@parameters('endpointUrlParam')",
"authentication": {
"type": "Raw",
"value": "@parameters('authHeaderParam')"
}
},
"runAfter": {}
}
托管标识身份验证
当托管标识选项可用于支持托管标识身份验证的触发器或操作时,逻辑应用可以使用此标识,对访问受 Microsoft Entra ID 保护的 Azure 资源的操作进行身份验证,而无需使用凭据、机密或 Microsoft Entra 令牌。 你无需管理机密或直接使用 Microsoft Entra 令牌,Azure 会为你管理此标识,并且会帮助你保护凭据。 详细了解支持使用托管标识进行 Microsoft Entra 身份验证的 Azure 服务。
“消耗”逻辑应用资源可以使用系统分配的标识或单个手动创建的用户分配标识。
“标准”逻辑应用资源支持具有系统分配的托管标识并同时启用多个用户分配的托管标识,不过,你任何时候都还是只能选择一个标识。
注意
在默认情况下,已启用系统分配的标识,以便在运行时对连接进行身份验证。 该标识与你在创建连接时使用的身份验证凭据或连接字符串不同。 如果禁用该标识,则运行时连接无效。 若要查看此设置,请在逻辑应用菜单的“设置”下,选择“标识”。
在逻辑应用可以使用托管标识之前,请按照使用 Azure 逻辑应用中的托管标识对 Azure 资源的访问进行身份验证中的步骤进行操作。 这些步骤将在逻辑应用上启用托管标识,并设置该标识对目标 Azure 资源的访问权限。
在 Azure 函数可以使用托管标识之前,请先为 Azure 函数启用身份验证。
在支持使用托管标识的触发器或操作中提供以下信息:
内置触发器和操作
属性(设计器) 属性 (JSON) 必须 值 说明 身份验证 type
是 托管标识
或ManagedServiceIdentity
要使用的身份验证类型 托管标识 identity
否 <user-assigned-identity-ID> 要使用的用户分配的托管标识。 注意:使用系统分配的托管标识时,请勿包含此属性。 受众 audience
是 <target-resource-ID> 要访问的目标资源的资源 ID。
例如,https://storage.azure.com/
使用于身份验证的访问令牌对所有存储帐户都有效。 但是,还可以为特定存储帐户指定根服务 URL,如https://fabrikamstorageaccount.blob.core.chinacloudapi.cn
。
注意:“受众”属性可能已在某些触发器或操作中隐藏。 若要显示此属性,请在触发器或操作中打开“高级参数”列表,然后选择“受众”。
重要提示:请确保此目标资源 ID 与 Microsoft Entra ID 所需的值完全匹配,包括所有必要的尾部斜杠。 因此,所有 Azure Blob 存储帐户的https://storage.azure.com/
资源 ID 都需要尾部反斜杠。 但是,特定存储帐户的资源 ID 不需要尾部反斜杠。 若要查找这些资源 ID,请查看支持 Microsoft Entra ID 的 Azure 服务。使用安全参数处理和保护敏感信息时,例如,在用于自动执行部署的 Azure 资源管理器模板中,可以使用表达式在运行时访问这些参数值。 例如,此 HTTP 操作定义将身份验证
type
指定为ManagedServiceIdentity
,并使用 parameters() 函数获取参数值:"HTTP": { "type": "Http", "inputs": { "method": "GET", "uri": "@parameters('endpointUrlParam')", "authentication": { "type": "ManagedServiceIdentity", "audience": "https://management.chinacloudapi.cn/" }, }, "runAfter": {} }
托管连接器触发器和操作
属性(设计器) 必须 值 说明 连接名称 是 <connection-name> 托管的标识 是 系统分配的托管标识
或
<用户分配的托管标识名称>要使用的身份验证类型
阻止创建连接
如果组织不允许使用 Azure 逻辑应用中的连接器连接到特定资源,则可以在逻辑应用工作流中使用 Azure Policy阻止为特定连接器创建这些连接的功能。 有关详细信息,请查看在 Azure 逻辑应用中阻止特定连接器创建的连接。