113.AI多租户隔离架构
你的SaaS客户，真的安全隔离了吗？AI多租户架构真相
先说一个扎心的问题
昨晚, 有个从事SaaS业务的朋友, 在半夜的时候给我打来电话。电话那头, 他特别着急, 跟我说他们的平台出了个比较严重的问题。在他们的平台里面, A租户用来做AI模型训练的数据, 居然能被B租户的管理员看到。
这种情形无疑是极为危险的, 不但涉及租户数据的隐私与安全层面的问题, 而且对整个平台的稳定性以及信誉都会造成极大的冲击。朋友担忧这一漏洞有可能引发一系列无法预估的后果, 像是数据泄露致使商业机密被窃取, 或者因数据混乱影响到AI模型训练的准确性, 进而妨害到各个租户的业务正常开展。
他说那一刻，冷汗直接湿透了衬衫领子。
这并非是那种科幻性质的剧本, 而是AI多租户隔离架构存在欠缺的日常情形。你觉得你购置了SaaS服务, 难道你的数据就实实在在仅归属于你? 别这般天真啦。
到底什么是AI多租户隔离？
确切来讲, 存在这样一种情况, 即有一个AI系统, 它要同时为多家客户服务, 对于每一家客户而言, 其数据、模型以及计算资源, 都必须如同一个个独立的公寓那般, 相互之间不能有交互。
然而实际情况是, 好多被称作“隔离”的东西, 事实上只是涂抹了一层漆的隔断墙体, 看上去好像是实心的模样, 可是一锤子砸下去便会被打通了。
AI多租户隔离可不是仅仅像数据库分离那么简易, 它实际上涵盖着三个层面的事项, 分别是数据层隔离, 模型层隔离, 还有计算资源隔离。这三个层面的隔离一个都不能缺, 每一项都得严格把控住, 要是少了其中任何一项, 那就如同埋下了一颗定时炸弹, 随时都有可能引发严重后果。
为什么99%的团队都做错了？
我见识过好多团队的行事方式, 那就是搞出一个命名空间, 而后配置一番RBAC权限控制, 便自以为一切都妥当无误了。
哥们儿，那是2018年的玩法了。
眼下处于怎样的时代时期阶段呢, 大模型实现共享, 向量数据库开展交叉检索, GPU显存进行复用, 每一项特性均在对那简陋的隔离方案发起挑战。
在你看来, 当租户A着手开展向量查询这一行为之际, 难道就只会于其自身所限定的索引范畴之内展开搜寻工作吗? 答案并非如此。事实上, 要是在数据隔离这个关键环节没能进行妥善的处置, 那么租户A所执行的向量查询举动极有可能会不知不觉地闯入租户B的语义空间范围之中, 进而会把本应属于他人的商业机密错误地当成是自身的知识库当中所包含的内容。
数据隔离：最基础也最容易翻车
到底怎么分？
分库？分表？还是加个租户ID过滤？
好多人会挑选运用最为简易的那般方式, 把所有数据都安放在同一个表里头, 并且增添一个字段。每回开展查询行动的时候，都会借着where =xxx的条件去筛选数据。
听起来没毛病对吧？
可你仔细琢磨琢磨, 要是程序员所写的SQL忘掉或少写入这个特定条件, 要是某一个JOIN操作缺失了过滤环节, 那数据就毫无遮拦地暴露在外跑去。
实际意义上的多租户数据隔离, 应当如同银行金库那般, 每个租户都具备属于自身的保险柜, 钥匙握于自己手中, 甚至于银行员工都不存在打开的权限。
模型隔离：最容易被忽视的角落
模型会泄密吗？
会的，而且泄得悄无声息。
瞧那些大型企业的人工智能平台, 租客A能够上传自身的数据去微调模型。微调之后的模型权重当中, 是不是夹杂着其他租客的信息呢?
有。概率还不低。
由于GPU显存属于共享性质的存在, 在进行批次训练这个行为的期间, 要是内存管理处于并未到位的状况, 那么在前面的那个租户所拥有的数据残留, 就具备了污染处于后续的下一个租户的模型的可能性。
这就像合租房的冰箱里，你的剩菜被人吃了，还往里面吐了口痰。
计算资源隔离：性能与安全的博弈
能不能又隔离又省钱？
这是个灵魂拷问。
完全进行隔离, 每一个租户单独享有一套 GPU 集群, 安全方面确实是安全了, 然而成本高昂到会使得 CEO 直接拍桌子。
完全共享, 即所有租户都挤在同一个集群当中, 虽说这样做确实能省下钱, 然而, 要是哪天隔壁租户运行了一个耗费显存的训练任务, 那么你的推理速度便会一下子降至龟速。
中间路线是什么？
搞的是资源配额吗? 还是搞优先级调度呢? 又或者是更狠的那种, 每个租户的推理请求都要走独立的容器化部署?
不存在所谓的标准答案 , 然而却存在着这样一条红线 , 即绝不能够使得一个租户的算力出现暴走的情况 , 进而导致饿死其他所有的租户。
聊聊那些血淋淋的案例
不久之前, 有个平台致力于提供AI客服服务, 它对外很高调地宣称具备“银行级数据隔离”能力。可是实际状况到底是怎样呢? 安全团队针对这个平台开展渗透测试工作的时候, 居然发现借助一个API的边界漏洞, 就能够轻松地把全平台20多家租户的对话数据都拉取下来。
这般情形之下, 那所谓的“银行级数据隔离”宣称, 瞬间化作泡影。此一事件突显, 于数据安全防护范畴内, 哪怕是看上去有着一定保障举措的平台, 依旧可能存有被忽略的安全隐患, API的边界漏洞便是一个典型例证, 它轻易地冲破了原本应有的数据隔离防线, 致使租户对话数据面临着泄露风险。
客户询问那究竟是怎么一回事, 技术总监含含糊糊、吞吞吐吐地讲了这样一句话: “我们所构建的隔离架构……兴许是对网络层过度信赖了。”。
太相信网络层。这句话现在成了业内的笑话。
又存在一个能提供AI绘画服务的SaaS平台, 租户A生成的图片, 居然出现在了租户B的“最近生成”展示区域当中。探寻其原因, 是他们用来存储图片的图床采用了连续ID的存储路径设置, 如此便致使B租户只要借助暴力遍历ID的方式, 就能够看到A租户的作品。
架构师的终极三问
当你要设计一个AI多租户隔离架构时，先问自己三个问题：
你的隔离方案，能扛住一个恶意的内部人员吗？
你的隔离方案，在系统故障时还能保持吗？
你的隔离方案，有没有考虑到模型推理时的隐性泄露？
如果这三个问题你回答得犹豫，那你的架构就有漏洞。
写在最后
AI多租户隔离不是一道技术题，是一道商业题。
你所面对的客户, 将数据交付于你, 乃是源于信任。然而, 信任此般事物, 倘若要构建起来, 需历经一百回无误的操作, 可一旦要遭破坏, 仅需一回细小的漏洞就足够了。
别拿“别人也这样”当借口。
也别拿“等出了事再补”当理由。
哪一些切实能够存活下来的SaaS平台, 并非凭借功能繁杂多样, 而是依靠具备安全性能从而经得起打击。
你问我怎么做？
话只能由我来讲, 去瞧瞧那些已然出现事故的实例, 将它们的漏洞一处处封堵好。而后, 千万别认为自身达成了尽善尽美。
因为漏洞这种东西，永远比你聪明。
最新评论