主题
生产级安全与多租户隔离
场景 多租户数据平台最怕的事故,往往不发生在正常流程里,而发生在边角:解析失败的降级路径悄悄跳过了鉴权、密钥明文躺在进程命令行里、一个空间把整个集群的算力吃满。所以安全这件事,不能只看「有没有权限模型」,要看异常和降级时守不守得住。
有哪些防线
| 防的是什么 | 平台怎么做 |
|---|---|
| 越权读数 | 每条查询提交即做逐表权限检查,无权的表当场拒绝;AI 生成的 SQL 也走同一道闸 |
| 降级变后门 | 安全默认拒绝:解析失败、组件降级时宁可拒绝也不放行未鉴权的访问 |
| 带弱口令上线 | 生产姿态下任一敏感凭据还是弱默认值,平台直接拒绝启动 |
| 密钥泄漏 | 数据源/存储密钥加密落库,运行时才解密送进引擎内存,不进命令行、不进配置快照 |
| 一个空间吃满集群 | 资源双层闸:提交前按空间配额准入(超容排队),运行中按空间的资源上限硬隔离 |
| 各模块口径打架 | 权限、可查询性、删除保护等横切规则各有单一权威组件,所有模块引用同一口径 |
亮点
- fail-closed 是默认姿态——功能可以降级,安全不降级;要么保住边界,要么保守拒绝
- 数据与算力是两条正交防线——数据面每空间独立存储账号,算力面每空间独立资源边界,谁也替代不了谁
- AI 路径无特权——自然语言查数、智能助手生成的查询,和手写 SQL 走完全相同的鉴权闸
- 密钥全生命周期不见明文——落库加密、展示脱敏、运行时只进引擎内存
实景一:越权,当场拒
bob 在自己的空间里查询另一个空间的表——提交那一刻就被逐表权限检查拦下,不会等跑到引擎才发现,更不会「解析不了就放过去」。报错同时给出正路:向建表空间申请读权限:
值得强调的是「表不存在」和「无权限」在报错里故意不区分——不给探测者「这张表存在但你无权」的情报。
实景二:空间是最小授权单元
成员与角色(属主/管理员/开发/访客)、OpenAPI 访问令牌、底层系统账号的凭据托管,都收在空间管理里。令牌对他人默认脱敏;数据库口令、对象存储密钥加密存储、密文展示,仅管理员可揭示。给别的空间授权湖表时,平台会联动把对象存储侧的访问策略一起下发——上层权限和底层存储权限永远一致:
实景三:算力配额,软准入 + 硬隔离
每个空间的批/流作业资源、查询引擎规格独立申报与配给。提交作业时先按空间配额做准入判定——超容不是失败而是排队,等资源释放再跑;真正运行时,空间的资源上限在集群层面硬性生效,即便有什么绕过了软准入,也吃不到超出配额的算力。查询引擎按空间独立部署,空间之间互不干扰:
申报、配给、实测三个口径分开呈现,资源是真占着还是虚占着一眼可判——配额治理不靠拍脑袋。
那些看不见的部分
- 启动自检:生产姿态下,任何一个敏感凭据(数据库口令、对象存储密钥、签名密钥等)还是出厂默认值,平台拒绝启动——「先跑起来再说」在安全上不成立
- 单一权威源:哪些表可被直查、删除某对象会不会破坏引用、令牌具备哪些能力,每条规则只有一个权威判定组件,前端、网关、各引擎全部引用它,不存在「两处判断打架」的缝隙
- 作业身份最小化:每个作业运行时拿到的是本空间的受限身份,能力集在签发时就被冻结,运行中的 pod 无法给自己加权
- 副作用最终一致:授权变更、表结构变更这类跨系统副作用走事务性 outbox 事件——与业务写同事务落库、可靠投递、消费幂等,还有定时对账兜底