Azure Blob Storage搜索资源管理器索引标签权限配置方法

索引层配置 #

• 先在认知搜索索引中新增专门的权限字段，字段名建议设为allowedUid，字段配置只开启filterable、retrievable两个属性，不要开启searchable属性，避免UID本身被搜索关键词命中，也不需要给这个字段配置分词器。如果是单用户独占文档的场景字段类型用Edm.String就行，后续如果要支持多用户/用户组共享文档，换成Edm.String类型的数组也能兼容。
• 给Azure Blob中的每个文档提前写入自定义元数据，键名就叫allowedUid，值对应该文档所属用户的UID。配置Blob索引器的时候，添加元数据字段映射，把Blob元数据里的allowedUid直接同步到索引的allowedUid字段，9TB的全量文档可以靠索引器自动完成字段填充，不需要手动写批量处理代码。

检索层权限控制 #

• 所有搜索请求的过滤逻辑必须在后端服务侧实现，绝对不能把过滤参数拼接的逻辑放到前端，也不能信任前端传入的UID值，要从服务端保存的登录态（比如JWT令牌、Session）里取当前用户的可信UID，防止用户伪造请求越权访问。
• 每次发起认知搜索请求时，固定在请求参数里加上过滤条件，单用户权限场景下过滤表达式写法为：

  filter=allowedUid eq '{服务端校验过的当前用户UID}'
  

• 对应你举的场景：当UID1发起搜索时，后端自动给请求加上filter=allowedUid eq 'UID1'的规则，认知搜索会在执行全文检索前先完成过滤，把所有allowedUid不等于UID1的文档（也就是doc3.txt、doc4.pdf）全部排除出检索候选集，不管搜索关键词是什么，这两个文档都不会出现在匹配结果中，也不会泄露内容摘要。

扩展优化 #

• 如果后续需要支持多用户共享、部门权限等复杂场景，不需要重构索引，只需要把allowedUid字段替换为存储所有有权限访问的ID列表，过滤表达式改用search.in函数即可，示例写法：

  filter=search.in(allowedIds, 'UID1,dept_sales,share_789', ',')
  

• 权限字段不需要开启suggestable、facetable、sortable等非必要属性，能降低9TB文档量对应的索引存储开销。配置完成后可以做越权校验：用UID1的身份搜索doc3里的专属内容，确认返回结果为空即规则生效。

内容的提问来源于stack exchange，提问作者Raja Gc