安全过滤(Security filter)

适用于:搜索方案无法使用内置访问控制列表(ACL)支持时,用一个存有用户或组标识的字段,在查询时过滤掉调用方无权看到的文档。

前提

  • 能从可信的服务端获得调用方的用户或组标识(页面示例为 Microsoft Entra 对象 ID)。
  • 索引中每个文档都有一个存放标识的字段,并随文档一起写入。
  • 理解本模式的性质:页面明确说明,它只是用字符串做过滤,本身不做认证或授权。

步骤

步骤
操作
要点
1
在索引中新增安全字段
Collection(Edm.String),filterable 为 true,retrievable 为 false,且不作为 key
2
推送文档时写入标识
用 upload 写入;需要更新授权时用 mergeOrUpload 只更新该字段
3
查询时加入过滤
形如 group_ids/any(g:search.in(g, 'group_id1, group_id2')),每次查询都必须带上
4
验证
用不同身份的组标识分别查询,确认结果集不同

参数表(示例字段)

字段
类型
属性
说明
file_id
Edm.String
key
文档键
file_name
Edm.String
searchable,retrievable
可检索、可返回
file_description
Edm.String
searchable,retrievable
可检索、可返回
group_ids
Collection(Edm.String)
filterable,retrievable 为 false
安全过滤字段

示例数据与结果(页面示例)

file_id
file_name
group_ids
组 group_id1 或 group_id2 的查询是否返回
1
secured_file_a
group_id1
是
2
secured_file_b
group_id1,group_id2
是
3
secured_file_c
group_id5,group_id6
否

验证

  • 以只属于 group_id5 的身份查询,应只返回 file_id 为 3 的文档。
  • 确认查询请求中确实带有过滤条件(漏加过滤是最常见的越权原因)。
  • 用 mergeOrUpload 修改某文档的 group_ids 后,再次查询,结果应随之变化。

排错表

现象
可能原因
处理
结果为空
标识大小写或格式与索引中的值不一致
统一由同一来源生成标识
看到了不该看的文档
某条查询未加过滤,或安全字段未设为 filterable
在服务端统一封装查询,并检查索引属性
无法返回安全字段
retrievable 为 false,属于预期行为
该字段仅用于过滤,不用于展示
组很多时查询变慢
用多个 eq 串联过滤
页面建议改用 search.in;见“性能调优要点”

注意事项

  • retrievable 为 false 不是字段级安全机制。页面明确说明:不要仅依赖它来保护敏感信息,过滤必须应用于每一次查询。
  • 本模式不做认证。调用方身份如何可信地获取,页面未展开:待核实,需结合具体身份方案设计。
  • 权限变化时需要同步更新索引中的标识字段。页面只给出 merge 示例,同步的频率与机制:待核实。
  • 页面称 search.in 的过滤可达亚秒级响应,相较多个等值比较更快;具体延迟数值:待核实(2026-11-05 获取)。

来源与核对

  • 来源:https://learn.microsoft.com/en-us/azure/search/search-security-trimming-for-azure-search
  • read_scope:正文已读(安全过滤模式页面,2026-11-05 抓取)。
  • 待核实:身份的可信获取方式、权限同步机制、延迟数值。
上一篇
网络与身份
下一篇
索引字段设计
Loading...
文章列表
分享AI实践与思考
入门
Microsoft Foundry
开发工具
治理与网络
观测与评测
工具与知识
模型与部署
Azure OpenAI
Azure AI Search
性能与基准
索引与分块
概念解释
快速上手
Foundry Tools
RAG 与知识工程
检索质量与评测
数据准备
智能体与工具
评测、观测与安全
企业架构与成本
成本与容量
架构
解决方案场景
文档与服务
知识与分析
样例与学习资源
附录