必须在gridfs元数据中显式写入业务线标识（如"biz_line":"payment"），并基于该字段建索引、配置带filter的mongodb角色权限，应用层须先校验文件存在性再下载，严禁绕过权限检查直接操作fs.chunks。
GridFS 文件元数据里存业务线标识是前提
不往 metadata 字段写业务线信息，后续所有权限控制都无从谈起。MongoDB 本身不识别“业务线”概念，它只认你塞进去的字段值。
实操建议：
- 上传文件时必须显式设置
metadata，比如：{ "biz_line": "payment", "env": "prod" } - 避免用文件名或
_id推断业务线——不可靠、难审计、查询慢 - 统一约定键名（如固定用
biz_line），别一会儿business一会儿line
MongoDB 角色定义要基于 find 查询过滤器
GridFS 实际是两个集合（fs.files 和 fs.chunks），权限得落在 fs.files 上，因为它是元数据入口；fs.chunks 不做细粒度控制——查不到文件就拿不到 chunk ID，自然读不了内容。
常见错误现象：角色只给了 find 权限但没限制条件，结果用户能列全库所有 GridFS 文件。
实操建议：
- 用
db.createRole()定义角色时，在privileges里指定resource: { "collection": "fs.files", "db": "your_db" } -
actions至少包含"find"，不能只给"read"（太宽泛） - 关键一步：在
resource下加"filter": { "metadata.biz_line": "payment" }，这才是隔离核心
应用层必须用 find + openDownloadStream 组合查文件
很多开发者直接调 bucket.find({}) 拿游标，再逐个 openDownloadStream——这会绕过 MongoDB 层的 filter 权限检查，因为 bucket.find 是驱动封装逻辑，不走原生权限引擎。
使用场景：用户请求下载 ID 为 abc123 的文件，且已知属于 logistics 线。
实操建议：
- 先用带权限的角色连接 DB，执行
db.fs.files.find({ "_id": ObjectId("abc123"), "metadata.biz_line": "logistics" }) - 确认返回非空再调
bucket.openDownloadStream(new ObjectId("abc123")) - 别省掉第一步校验——否则攻击者可伪造 ID 直接读 chunk
注意 fs.chunks 的隐式依赖和索引影响
即使你在 fs.files 上做了完美过滤，如果应用代码没校验文件存在性就直接拼 fs.chunks 的 files_id 去查，可能触发未授权访问。MongoDB 不会对 chunks 集合自动关联 files 的权限规则。
性能影响：每个业务线数据量差异大时，fs.files 上的 metadata.biz_line 字段必须建索引，否则 filter 权限对应的查询会全表扫。
实操建议：
- 在
fs.files上建支撑索引：db.fs.files.createIndex({ "metadata.biz_line": 1 }) - 禁止应用层直接操作
fs.chunks——所有读写必须经由GridFSBucketAPI - 测试时用低权限账号连，故意传错
biz_line值，看是否真被拒而不是静默返回空
真正卡住人的地方往往不是语法，而是 metadata 写没写对、索引建没建、以及有没有在应用层多补那一行存在性校验。
