可扩展逻辑应用（Logic Apps）身份认证方案选型咨询

两种方案核心能力对比 #

• 托管标识（Managed Identities）
  • 无需手动管理凭据，Azure 后台自动轮换密钥，无过期泄漏风险
  • 仅支持同租户内的 Azure 资源、以及支持 Azure AD 认证的第三方服务连接器使用
  • 零额外费用，开箱即用，可直接在 Logic Apps 身份配置面板开启
  • 分为两类：系统分配托管标识（和逻辑应用生命周期绑定，删除逻辑应用自动销毁）、用户分配托管标识（可独立于逻辑应用存在，多个逻辑应用可共享同一个）
• 服务账号（Service Account）
  • 分为 Azure AD 服务主体、本地域服务账号两类，适配跨租户、混合云、本地系统对接场景
  • 需手动管理凭据有效期、权限变更，存在密钥泄漏、过期导致业务中断的风险
  • 支持对接不支持 Azure AD 托管标识认证的 legacy 系统、第三方 SaaS 服务

选型决策参考 #

满足以下所有条件优先选托管标识：

• 对接的所有连接器都支持 Azure AD 认证
• 所有对接资源和逻辑应用在同一个 Azure AD 租户内，无跨租户/本地系统对接需求
• 希望最大化降低凭据运维成本，彻底避免 PAT 过期、泄漏同类问题

满足以下任意条件选服务账号：

• 需要对接不支持托管标识认证的连接器、本地系统、跨租户资源
• 需要统一管理多套环境（开发/测试/生产）的身份权限，有跨云、混合云部署需求
• 企业现有身份治理体系要求所有服务身份必须走现有服务主体管控流程

落地注意事项 #

• 采用托管标识时优先使用用户分配托管标识，避免系统分配标识随逻辑应用删除重建导致的权限重新配置问题
• 采用服务账号时建议搭配 Azure Key Vault 存储凭据，在 Logic Apps 中通过 Key Vault 连接器动态读取凭据，不要硬编码在连接器配置或者工作流定义中
• 两种方案都需要遵循最小权限原则，仅给身份分配连接器调用必须的权限，避免过度授权

内容的提问来源于stack exchange，提问作者Milgo