使用B2C的公网WebApp经Azure Service Bus调用AAD下游API的安全配置咨询

1. 公众门户推送数据至队列/端点的配置 #

所有消息队列的访问入口不直接暴露到公网，通过集群内的门户后端服务作为唯一消息生产者对接：

• 门户后端先完成用户身份校验，确认请求来自合法B2C登录用户后，再将业务数据封装为标准化消息投递到消息代理，消息可选择Azure Service Bus、AKS内部署的Kafka/RabbitMQ等组件
• 通过Kubernetes Network Policy限制仅门户后端的服务Pod可以访问消息代理的服务端口，禁止其他未授权服务连接
• 若使用Azure托管的消息服务，给门户后端分配Azure托管身份，通过RBAC授予对应消息发送权限，无需在配置文件中存储连接密钥，降低泄露风险

2. 公网前端到WebApp的API与微服务调用安全防护 #

采用多层防护逻辑，避免内部服务直接暴露在公网：

• 公网入口统一接入带WAF功能的Azure Application Gateway或Ingress控制器，开启通用攻击防护规则，仅对外开放需要被前端调用的WebApp路径与端口，其余所有未声明路径默认拦截
• 所有公网发起的API请求必须携带B2C签发的有效访问令牌，统一在API网关层完成令牌有效性校验，校验不通过直接返回401，请求不转发到后端服务
• 集群内部通过Network Policy做东西向流量管控，所有微服务仅允许约定的调用方访问，禁止微服务直接接收公网请求，所有外部调用必须经过统一网关
• 针对敏感API端点额外配置访问频率限制规则，同时开启全链路请求审计，所有调用日志同步到Azure Monitor留痕，方便后续溯源排查

3. 身份认证与应用注册配置 #

区分用户身份与应用身份两类场景分别配置：

• 用户身份层：面向公众的前端用户统一通过Azure AD B2C完成登录认证，登录后获取B2C签发的访问令牌，所有向WebApp发起的请求必须携带该令牌
• 应用身份层：AKS内部运行的所有微服务、消息生产者、消费者，统一在Azure AD中注册应用，或者分配Azure托管身份，全程不用硬编码密钥
• 权限配置逻辑：
  • 门户后端的应用身份仅授予消息代理的消息发送权限，消息消费服务的应用身份仅授予消息读取、处理权限，遵循最小权限原则
  • 微服务之间的内部调用采用OAuth2客户端凭据流，调用方的应用身份需要提前申请被调用方暴露的应用权限，被调用方收到请求后先校验令牌中的权限声明，确认权限匹配后再处理业务
  • 配置B2C租户与内部Azure AD租户的信任关系，WebApp收到B2C用户令牌后，如需调用受Azure AD保护的内部微服务，通过OBO（代理流）将B2C令牌交换为Azure AD签发的内部访问令牌，保证用户身份上下文可以传递到下游服务
• 令牌有效期按需设置，敏感场景配置较短的访问令牌有效期，同时启用刷新令牌机制，降低令牌盗用后的风险

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