多租户 on 姚玉亮的网络日志

腾讯云 SMS/SES/Captcha 多租户通道按需切换实践

Sat, 29 Jun 2024 10:30:00 +0800

每家的通道配置都不一样

统一认证中心服务着多家客户和内部业务线：有的客户用自己报备的腾讯云账号，签名和模板都得单独申请；有的直接用平台统一账号。国内走短信，海外走 SES 邮件，不同应用的验证码模板也不一样。

所有租户挤在同一套腾讯云配置上，签名和模板就没法隔离，客户自己报备的签名也用不上。所以要在 Provider 抽象之上再加一层多租户通道，这件事没有绕开的余地。

一份配置对应一条通道

核心是一张 ChannelConfig 表：team_id + app_id + channel 三元组对应一份通道配置，存供应商类型、加密后的凭证、模板 ID、签名这些。发送时按请求上下文查到配置，从缓存里拿对应的 Provider 实例，没有就创建一个再缓存住，之后一直复用。

凭证安全是底线：AES-GCM 加密落库，主密钥从 KMS 或环境变量读取，明文不落盘。腾讯云 SDK 的 client 是并发安全的，按配置维度缓存复用就行，不必每个请求都新建。

发一次短信背后的查找

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


type ChannelConfig struct {
 ID int64 `gorm:"primaryKey"`
 TeamID int64 `gorm:"uniqueIndex:idx_ch"`
 AppID string `gorm:"uniqueIndex:idx_ch"`
 Channel string `gorm:"uniqueIndex:idx_ch"` // sms/email/captcha
 Provider string `gorm:"size:32"` // tencent_sms / tencent_ses
 ConfigEnc []byte // AES-GCM 加密的 JSON
 Status int8
}

type TencentSMSProvider struct {
 client *sms.Client
 appID string
 sign string
}

func strPtr(s string) *string { return &s }

func (p *TencentSMSProvider) Send(ctx context.Context,
 phone, tplID string, params map[string]string) error {

 req := sms.NewSendSmsRequest()
 req.SmsSdkAppId = strPtr(p.appID)
 req.SignName = strPtr(p.sign)
 req.TemplateId = strPtr(tplID)
 req.PhoneNumberSet = []*string{strPtr(phone)}
 // 腾讯云模板参数为有序数组，需按模板顺序传
 arr := make([]*string, 0, len(params))
 for _, v := range params {
 arr = append(arr, strPtr(v))
 }
 req.TemplateParamSet = arr
 _, err := p.client.SendSms(ctx, req)
 return err
}

Provider 缓存用 sync.Map，key 取配置内容的 hash。配置变更时更新数据库、删掉对应缓存 key，下一个请求自动重建。没有自定义配置的租户，回退到平台默认配置。

验证码这条链路前面还加了一道人机校验：接了腾讯云验证码，前端先拿到 ticket，后端调用腾讯云接口校验通过，才允许发验证码。人机验证之外，还配了频率限制。

三个教训

第一个是凭证加密，这条没得商量。最初 SecretKey 明文存数据库，安全评审直接打回来。改成 AES-GCM 加密之后，主密钥通过环境变量注入 Secret，代码里不出现任何硬编码。

第二个坑藏在腾讯云 SMS 的模板参数里：它是有序数组，不是 map。我们按 map 遍历传参，顺序不稳定，结果验证码和过期时间填反了。后来改成按模板定义的参数顺序显式构造数组，才算踏实。

第三个是频率限制。多租户共用默认账号时容易触发腾讯云限流，我们给默认通道加了令牌桶限流和告警，量大的客户引导他们换用自有账号。

后来

多租户通道切换做完，认证中心两头都照顾到了：想快速接入的用平台统一配置；要隔离的客户自带腾讯云账号，签名、凭证完全独立。加密存储、Provider 缓存、默认回退、人机校验，几个机制组合在一起，安全性和易用性都站住了，支撑住了多业务线和外部客户的验证码与通知需求。

封面图：Matthew Summerton / Wikimedia Commons · CC BY-SA 3.0

AppRole 与应用团队隔离：多业务线权限自治的实现

Mon, 13 May 2024 10:30:00 +0800

角色表快撑不住了

统一认证中心接入的应用越来越多，权限模型先扛不住了。支付平台有运营、财务、商户管理员这些角色；数据治理服务有数据管理员、分析师；数据集管理服务又有自己的文档管理员。要是所有角色都放到认证中心全局定义，角色表迟早撑爆，而且业务线想调整自己的角色，还得来找认证中心团队，自治无从谈起。

我们需要一层「应用角色（AppRole）」：每个应用自己定义、自己管理角色，认证中心只负责团队隔离。

认证中心管边界，应用管角色

做法是把权限拆成两层。认证中心全局层只管团队（Team）和成员关系，应用层管 AppRole。一个用户在同一个团队里，对不同应用可以有不同角色：张三在数据中台团队里，对数据治理服务是 admin，对知识库问答就只是 viewer。

团队是隔离边界，数据、配置、成员都按 team_id 隔离，跨团队访问必须显式授权。AppRole 的角色编码（admin/editor/viewer 这类）和对应权限点由应用自己定义，认证中心只存绑定关系，不关心权限点具体是什么意思。

查权限就是查一次绑定

绑定关系就一张表，team_id、user_id、app_id 联合唯一，AppRole 字段存的是应用自己定义的角色编码：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


type TeamMember struct {
 ID int64 `gorm:"primaryKey"`
 TeamID int64 `gorm:"uniqueIndex:idx_team_user_app"`
 UserID int64 `gorm:"uniqueIndex:idx_team_user_app"`
 AppID string `gorm:"uniqueIndex:idx_team_user_app"`
 AppRole string `gorm:"size:32"` // 应用自定义角色编码
}

func (s *Service) CheckPermission(ctx context.Context,
 userID, teamID int64, appID, perm string) bool {

 member, err := s.memberDAO.Get(ctx, teamID, userID, appID)
 if err != nil {
 return false
 }
 // 应用通过接口返回角色 -> 权限点映射
 perms, err := s.appProvider.GetPermissions(ctx, appID, member.AppRole)
 if err != nil {
 return false
 }
 for _, p := range perms {
 if p == perm || p == "*" {
 return true
 }
 }
 return false
}

CheckPermission 的逻辑很直白：查出用户在这个团队、这个应用上的角色，再向应用要这个角色对应的权限点列表，匹配上就放行。角色到权限点的映射由应用自己实现，认证中心不做解释。

JWT 里带了当前 team_id 和各应用的 role 映射，业务系统在本地就能做粗粒度鉴权，细粒度权限点再查认证中心或读缓存。团队隔离则下沉到 DAO 层强制：所有查询都带 team_id 条件，我们用 Gorm 的 Scopes 封了个 WithTeam，免得哪次手写漏了。

两个坑

第一个是切换团队。用户可能同时属于多个团队，但 Token 里只能放一个当前 team_id。最初想把所有团队都塞进 Token，团队一多就超过 HTTP 头大小限制了。后来改成 Token 只放当前团队，加了个 switch-team 接口重新签发，前端切团队时调一下。

第二个是自治带出来的小代价：AppRole 让应用自己定义之后，认证中心管理后台没法统一展示权限点了。解决办法是让应用注册一个权限元数据接口，认证中心拉取后展示。多了一次对接，换来自治，这笔账算得过来。

后来

AppRole 加 Team 的两层模型，说白了就是在全局管控和应用自治之间找平衡：认证中心管身份和团队边界，应用管自己的角色和权限点。后来支付平台、数据治理、知识库问答几条业务线先后接入，新应用进来定义好自己的角色就能用，认证中心的表结构不用动。

封面图：bfi Office Furniture / Flickr · CC BY-SA 2.0