40.1 导言 第34至39章建立了ACAI平台的数据库、认证、授权和API基础。
下一个主要子系统是文件存储.
AI平台可以处理许多类型的用户拥有的数据: 这些物体通常不应直接储存在PostgreSQL内.
相反,该系统应分别: 由此产生的结构是: 这种分离提高了可伸缩性、性能、生命周期管理和安全性。 40.2 数据库 vs 对象存储 PostgreSQL 适合结构化信息,如: 对象存储适合: 因此,数据库充当权威元数据层. 40.3 文件结构 基本流程是: 对于更大的文件,架构可以使用直接或多段上传模式: 客户不应收到不受限制的存储凭证. 40.4 存储密钥设计 文件应该有一个内部存储密钥,而不是只依赖其原始文件名.
例如: 生成的资产可以使用: 准确的格式可以不同,但关键应该是:独特; 只有在必要的情况下才能预测; 独立于用户提供的文件名; 不存在秘密; 与生命周期政策相兼容. 40.5 原始文件名 vs 存储密钥 假设用户上传: 应用程序可以存储: 同时使用内部密钥, 如: 这种分离会阻止用户提供的文件名成为存储对象的主要身份 。 40.6 文件元数据 早期引入的模型可以被扩展.
示例:潜在的元数据包括:只应储存适当的元数据. 40.7 文件生命周期A应有一个明确的生命周期。
示例: 失败路径: 删除: 这使得应用程序可以区分:和: 40.8 上传验证 安全上传系统至少应验证:不应自动将客户端提供的文件名或MIME类型视为权威. 40.9 文件尺寸限制 不同的资源可以有不同的限制.
例如:确切的限度应当由产品要求、基础设施能力和滥用测试来界定。
服务器必须执行限制,而不是只依赖UI. 40.10 MIME 类型验证 浏览器可能报告:但服务器不应盲目相信该声明.
适当时,加工管线应当检查实际档案特征.
原理是: 40.11 扩展处理用户控制的文件名可以包含异常或有误导性的扩展.
应用程序不应直接从不可信文件名中构建敏感的存储行为 。
相反:存储密钥应该由应用程序生成. 40.12 文件所有权 每个私人文件必须有一个所有权边界.
概念上:访问前:只有在成功授权后,申请才能提供访问. 40.13 私人存储私人用户文件一般仍应通过匿名公共URL访问。
首选模式是:这防止了拥有任意的URL自动成为永久访问. 40.14 临时出入 对于私人对象,当存储平台支持时,应用程序可以发布短寿命的授权访问机制.
概念上:寿命应限于实际使用情况。 40.15 上传工作流程 一个强大的上传序列是:这创造了可追踪的生命周期. 40.16 上传后处理管道:对于一个文档:对于一个图像:40.17 恶意和不安全文件处理文件处理基础设施应该假设上传文件是不可信的.
因此,加工环境应与特权基础设施隔离开来。
重要原则包括: 准确的安全控制取决于部署架构. 40.18 处理隔离 档案处理工作人员不应自动获得: 工作人员只应获得执行任务所需的许可。
这遵循了最低特权的设计. 40.19 临时文件处理可能需要在当地临时储存。 e 类