无数据泄露的权限感知全局搜索设计

为什么全局搜索会导致数据泄露

全局搜索通常意味着一个搜索框会扫描整个应用：客户、工单、发票、文档、用户，以及其他人日常处理的对象。它通常为自动完成和快速结果页提供支持，让用户能直接跳转到某条记录。

泄露发生在搜索返回了用户无权知道存在的项时。即使他们无法打开记录，一行结果标题、某人的姓名、标签或高亮片段也可能暴露敏感信息。

搜索看起来像“只读”，因此团队常常低估它。但它会通过结果标题和预览、自动完成建议、结果总数、诸如“Customers (5)”之类的分面，甚至时间差异（某些词条很快、其他词条更慢）泄露数据。

这种问题通常不是在第一天出现的。早期团队在只有一种角色，或所有人在测试数据库中都能看到一切时就上线搜索。随着产品成长，你会添加角色（支持 vs 销售、经理 vs 客服）和功能（共享收件箱、私密备注、受限客户、“仅我的账户”）。如果搜索仍然依赖旧假设，就会开始返回跨团队或跨客户的线索。

一种常见的失败模式是为了速度把“所有内容”都索引进来，然后在应用层对结果进行过滤。那已经太晚了。搜索引擎已经决定了哪些匹配项，它可能通过建议、计数或部分字段暴露受限记录。

想象一个只应该看到其分配客户工单的支持代理。当他们输入“Acme”时，自动完成却显示“Acme - Legal escalation”或“Acme breach notification”。即便点击后显示“访问被拒”，仅标题就构成了数据泄露。

权限感知的全局搜索目标说起来简单、实现却不易：在执行与打开记录时相同的访问规则的前提下，返回快速且相关的结果。每次查询都必须表现得像用户只能看到他们那一片数据一样，且 UI 必须避免在那片之外泄露额外线索（比如计数）。

你要索引的内容与必须保护的部分

全局搜索看起来很简单，因为用户输入词语并期待答案。底层上，你为数据暴露创造了新的表面。在选择索引或数据库特性之前，先明确两点：你要搜索哪些对象（实体），以及这些对象的哪些部分是敏感的。

实体是任何人可能想快速查找的记录。在多数业务应用中，这包括客户、支持工单、发票、订单和文件（或文件元数据）。还可能包括人员记录（用户、代理）、内部备注，以及像集成或 API 密钥这样的系统对象。如果它有名称、ID 或状态，且有人可能会输入，它通常会出现在全局搜索中。

每条记录规则 vs 每表规则

每表规则很粗糙：要么能访问整张表，要么不能。例如：只有财务可以打开发票页面。这易于理解，但在同一表中不同人应看到不同的行时会失效。

每条记录规则按行决定可见性。例如：支持代理可以看到分配给他们团队的工单，而经理可以看到其区域内的所有工单。另一个常见规则是租户归属：在多租户应用中，用户只能看到 customer_id = their_customer_id 的记录。

搜索常在这些每条记录规则上发生泄露。如果你的索引在检查行访问之前就返回了命中，你已经泄露了某些东西的存在。

实践中“被允许查看”意味着什么

“被允许”很少是单一的是/否开关。它通常结合了所有权（我创建的、分配给我的）、成员资格（我的团队、我的部门、我的角色）、范围（我的区域、业务单元、项目）、记录状态（已发布、未归档）以及特殊情况（VIP 客户、法律保全、受限标签）。

先用白话把这些规则写下来。之后再把它们转换为数据模型加上服务器端检查。

决定在结果预览中显示什么是安全的

搜索结果通常包含预览片段，而这些片段即使用户无法打开记录也会泄露敏感数据。

一个安全的默认做法是只在确认访问之前显示最少的、非敏感字段：显示名或标题（有时可做掩码）、短标识（如订单号）、高层状态（Open、Paid、Shipped）、日期（创建或更新）以及通用实体标签（Ticket、Invoice）。

具体例子：如果有人搜索“A cme merger”并且存在受限工单，返回“Ticket: Acme merger draft - Legal” 就已构成泄露。更安全的结果是显示“Ticket: Restricted”且没有片段，或根据策略直接不显示该结果。

提前把这些定义弄清楚会让后续决定更简单：你要索引什么、如何过滤、以及愿意揭示多少内容。

安全且快速的搜索的基本要求

人们在赶时间时使用全局搜索。如果它花费超过一秒，他们就会失去信任并回去手动筛选。但速度只是工作的一半。一个快速但泄露了哪怕一条记录标题、客户名或工单主题的搜索，比没有搜索更糟。

核心规则不可妥协：在查询时强制执行权限，而不仅仅在 UI 层面。获取记录后再隐藏它已经太晚，因为系统已经触碰到了不应返回的数据。

这同样适用于围绕搜索的所有子功能，而不仅仅是最终结果列表。建议、热门命中、计数，甚至“无结果”行为都可能泄露信息。给无法打开的人显示“Acme Renewal Contract”的自动完成就是泄露。显示“12 条匹配发票”的分面在用户只能看到 3 条时也是泄露。即使是时间差，如果受限匹配让查询变慢，也会造成泄露线索。

一个安全的全局搜索需要四点：

• 正确性：每个返回项在此时此刻对该用户、该租户都是允许的。
• 速度：结果、建议和计数在大规模下也保持稳定快速。
• 一致性：当访问发生变化（角色更新、工单重新分配）时，搜索行为迅速且可预测地改变。
• 可审计性：你能解释为什么返回某项，并能记录搜索活动以供调查。

有用的思维转换：把搜索当作另一个数据 API，而不是单纯的 UI 功能。这意味着你在列表页上应用的相同访问规则，也必须用于索引构建、查询执行和所有相关端点（自动完成、最近搜索、热门查询）。

三种常见设计模式（以及何时使用）

搭建一个搜索框很容易。做出一个权限感知的全局搜索更难，因为索引希望瞬时返回结果，而应用必须绝不泄露用户无权访问的记录，哪怕是间接地。

下面是团队最常用的三种模式。正确选择取决于你的访问规则有多复杂以及你能承受多少风险。

方法 A：只索引“安全”字段，点击后再做权限检查再拉取完整记录。 在索引中存最少的文档，比如 ID 加上对任何能看到搜索 UI 的人都安全的非敏感标签。当用户点击结果时，应用从主数据库加载完整记录并在那里应用真实的权限规则。

这能降低泄露风险，但会让搜索感觉信息不足，因为结果上下文有限。还需要谨慎的 UI 文案，以免“安全”标签反而泄露信息。

方法 B：在索引中存储权限属性并在那里过滤。 在每个索引文档中包含 tenant_id、team_id、owner_id、角色标志或 project_id 等字段。每次查询都加上匹配当前用户范围的过滤条件。

这能提供快速且丰富的结果和良好的自动完成功能，但仅在访问规则可以用过滤表达时有效。如果权限取决于复杂逻辑（例如“分配给 OR 本周值班 OR 参与某次事故”），就很难保证正确性。

方法 C：混合。先在索引做粗过滤，然后在数据库对候选 ID 做最终检查。 使用稳定且范围较粗的属性（租户、工作区、客户）在索引中过滤，然后在主数据库对少量候选 ID 重新校验权限，最后再返回结果。

对于真实应用来说，这通常是最安全的路径：索引保持快速，数据库仍然是事实来源。

如何选择模式

当你想要最简单的方案且能接受精简的片段时选 A。当你的范围清晰且相对静态（多租户、基于团队的访问），并且需要非常快的自动完成时选 B。当你有很多角色、例外或经常变化的记录级规则时选 C。对于高风险数据（人力资源、财务、医疗），优先选择 C，因为“几乎正确”是不可接受的。

逐步：设计一个尊重访问规则的索引

先把你的访问规则写成你会向新同事解释的方式。避免写“管理员可以看到一切”，除非这确实成立。把原因写清楚：例如“支持代理可以看到来自其租户的工单。团队负责人还可以看到其组织单元内的工单。只有工单所有者和被指派的代理可以看到私密备注。”如果你无法说明某人为什么能看到记录，就很难安全地把它编码进系统。

接着选择一个稳定标识符并定义最小的搜索文档。索引不应该是数据库行的完整副本。只保留查找和在结果列表中展示所需的内容，比如标题、状态和可能的短非敏感片段。把敏感字段放在第二次拉取并做权限检查的路径后面。

然后决定哪些权限信号可以被快速过滤。这些是门控访问并且可以存储在每个索引文档上的属性，如 tenant_id、org_unit_id、少量的 scope flags。目标是每次查询都能先应用过滤，包含自动完成。

一个实用工作流如下：

1. 为每种实体（工单、客户、发票）定义可见性规则（用白话）。
2. 创建包含 record_id 及仅安全可搜索字段的搜索文档模式。
3. 在每个文档中添加可过滤的权限字段（tenant_id、org_unit_id、visibility_level）。
4. 用显式授权处理例外：在索引中存储允许列表（用户 ID）或用于共享项的组 ID。

共享项和例外是设计容易出问题的地方。如果一条工单可以跨团队共享，不要“只加一个布尔值”。使用显式授权并通过过滤检查它。如果允许列表很大，优先使用基于组的授权而不是单个用户。

在不出惊喜的情况下保持索引同步

安全的搜索体验依赖一件枯燥但要做好：索引必须反映真实情况。记录被创建、修改、删除或其权限改变时，搜索结果必须迅速且可预测地跟随变化。

跟上创建、更新、删除的步伐

把索引视为数据生命周期的一部分。一个有用的心智模型是：每当事实来源改变，你就发出一个事件，索引器对其做出反应。

常见做法包括数据库触发器、应用事件或作业队列。最重要的是事件不能丢失。如果应用能保存记录但索引失败，你会遇到“我知道它存在但搜索找不到它”的令人困惑的行为。

权限变化也是索引变化

很多泄露发生在内容本身更新正确，但访问元数据没有更新的情况。权限变化来自角色更新、团队变动、所有权转移、客户重新分配或工单合并到另一个案例中。

把权限变化当作一等公民事件处理。如果你的权限感知搜索依赖租户或团队过滤，确保索引文档包含那些用于强制的字段（tenant_id、team_id、owner_id、allowed_role_ids）。这些字段变化时要重新索引。

棘手之处是影响范围。一条角色变更可能影响数千条记录。规划一个支持进度、重试并能暂停的大规模重建路径。

为最终一致性做计划

即使有良好的事件机制，也会有搜索滞后的窗口。决定用户在变更后的前几秒应该看到什么。

两条规则有帮助：

• 对延迟保持一致。如果索引通常在 2–5 秒内完成，重要时要设置该预期。
• 倾向于缺失而非泄露。新授权的记录稍晚出现比被撤销的记录继续显示要安全。

当索引过时时添加安全后备

搜索用于发现，但查看详情才是泄露发生的地方。在显示任何敏感字段之前，在读取时做第二次权限检查。如果某个结果因为索引滞后漏出，详情页仍应阻止访问。

一个好的模式是：在搜索中显示最少片段，然后当用户打开记录（或展开预览）时重新检查权限。如果检查失败，在界面上显示明确信息并在下次刷新时将该项从可见结果集中移除。

导致数据泄露的常见错误

即便你的“打开记录”页面已上锁，搜索也可能泄露数据。用户可能从未点击结果，却从名称、客户 ID 或隐藏项目的规模中获知信息。权限感知的全局搜索必须保护的不仅仅是文档本身，还有关于文档的线索。

自动完成是常见的泄露源。建议通常由快速的前缀查找提供，往往跳过完整的权限检查。界面看起来无害，但一个字母就能泄露客户名或员工邮箱。自动完成必须运行与完整搜索相同的访问过滤，或者基于预过滤的建议集合（例如按租户和角色分开构建）。

分面计数和“约 1,243 条结果”标语也是静默的泄露来源。计数可以确认某物存在，即使你隐藏了记录。如果无法在相同访问规则下安全计算计数，就显示更少信息或省略计数。

缓存是另一个常见罪魁祸首。跨用户、角色或租户共享的缓存会产生“结果幽灵”，某个用户会看到为其他人生成的结果。这可能发生在边缘缓存、应用层缓存或搜索服务内部的内存缓存中。

值得早期检查的泄露陷阱：

• 自动完成和最近搜索是否与完整搜索应用相同规则过滤。
• 分面计数和总数是否在权限后计算。
• 缓存键是否包含 tenant ID 和权限签名（角色、团队、用户 ID）。
• 日志和分析是否不会为受限数据存储原始查询或结果片段。

最后，注意过宽的过滤。“仅按租户过滤”是经典的多租户错误，但在单个租户内也会发生：按“部门”过滤时实际访问是按记录的。示例：支持代理搜索“refund”并得到整个租户的结果，包括仅该小团队可见的 VIP 账户。原则上修复很简单：在每个查询路径（搜索、自动完成、分面、导出）都强制行级规则，而不仅仅在查看记录时。

人们常忘记的隐私与安全细节

很多设计关注“谁能看到什么”，但泄露也会通过边缘发生：空状态、时间和 UI 中微小的提示。权限感知搜索必须即便在返回空结果时也安全。

一个容易的泄露是通过缺失确认。如果未授权用户搜索一个具体客户名、工单 ID 或邮箱并看到特殊信息如“无访问权限”或“你没有权限”，那就确认了该记录存在。把“无结果”作为“不存在”和“存在但无权访问”这两种情况的默认表现。保持响应时间和措辞一致，避免别人通过速度猜测。

敏感的部分匹配

自动完成和即时搜索是隐私易滑落的地方。对邮箱、电话号码以及政府或客户 ID 的部分匹配可能泄露比预期更多的信息。事先决定这些字段的行为。

一组实用规则：

• 对高风险字段（邮箱、电话、ID）要求精确匹配。
• 避免显示会暴露隐藏文本的高亮片段。
• 考虑完全禁用敏感字段的自动完成。

如果显示一个字符就能让人猜到数据，那就把它视为敏感。

不创造新风险的滥用控制

搜索端点很适合做枚举攻击：试很多查询来映射存在的条目。添加速率限制和异常检测，但注意你存储的内容。包含原始查询的日志可能成为第二重数据泄露来源。

保持简单：按用户、按 IP、按租户限制速率；记录计数、时长和粗略模式（不要完整查询文本）；对重复的“近似命中”查询（例如连续 ID）发出告警；在重复失败后阻断或要求更高验证。

让你的错误信息乏味。对“无结果”、“无权限”和“无效过滤器”使用相同消息和空状态。界面说得越少，就越不可能意外泄露。

示例：支持团队跨客户搜索工单

支持代理 Maya 在一个团队，负责三个客户账号。她在应用头部有一个搜索框。产品有一个覆盖工单、联系人和公司等的全局索引，但每个结果都必须遵守访问规则。

Maya 输入“Alic”，因为来电者说名字是 Alice。自动完成显示一些建议。她点击“Alice Nguyen - Ticket: Password reset”。在打开任何内容前，应用重新检查该记录的访问权限。如果工单仍分配给她的团队并且她的角色允许，她就能进入工单页面。

Maya 在每一步看到的内容：

• 搜索框：建议迅速出现，但仅限她当前能访问的记录。
• 结果列表：显示工单主题、客户名、最后更新时间。没有“你无权访问”之类的占位符。
• 工单详情：在二次服务器端权限检查后加载完整视图。如果访问已变更，应用显示“工单未找到”（而不是“禁止”）。

再对比受训的新代理 Leo。他的角色只能查看标记为“Public to Support”的工单且仅限一个客户。Leo 输入同样的查询“Alic”。他看到的建议更少，且缺失的项不会以任何方式提示存在。界面也不会显示“5 条结果”之类泄露其他匹配存在的计数。界面只是显示他能打开的那些。

后来，经理把“Alice Nguyen - Password reset”从 Maya 的团队调到一个专门的升级团队。通常在短时间内（取决于你的同步方式，常在几秒到几分钟内），Maya 的搜索不再返回该工单。如果她已打开详情页并刷新，应用会重新检查权限，工单会消失。

这就是你想要的行为：输入和返回都很快，但通过计数、片段或陈旧的索引条目不会泄露任何线索。

实施安全的清单与下一步

权限感知的全局搜索只有在那些枯燥的边缘也安全时才算“完成”。许多泄露发生在看起来无害的地方：自动完成、结果计数和导出。

快速安全检查

在上线前，用真实数据而不是样本走查以下项：

• 自动完成：绝不建议用户无法打开的标题、名字或 ID。
• 计数与分面：如果显示总数或分组计数，应在权限后计算（或省略计数）。
• 导出和批量操作：导出“当前搜索”时必须在导出时对每行再次检查访问权限。
• 排序与高亮：不要使用用户无权查看的字段来排序或高亮。
• “未找到”与“禁止”：对敏感实体考虑使用相同的响应形态，以便用户无法确认存在性。

可执行的测试计划

创建一个小的角色矩阵（角色 x 实体）和一个包含刻意棘手情况的数据集：共享记录、最近被撤销访问的记录以及跨租户相似项。

分三轮测试：(1) 角色矩阵测试，验证被拒绝的记录绝不出现在结果、建议、计数或导出中；(2) “试图破坏它”测试，粘贴 ID、按邮箱或电话搜索，并尝试应该不返回的部分匹配；(3) 时序与缓存测试，改变权限并确认结果能快速更新且无陈旧建议。

在运维上，为“某天搜索结果看起来不对”做好准备。记录查询上下文（用户、角色、租户）和所应用的权限过滤，但避免存储原始敏感查询字符串或片段。为安全调试，构建一个仅限管理员使用的工具，该工具能解释为何某条记录匹配及为何被允许。

如果你在 AppMaster (appmaster.io) 上构建，一个实用方法是把搜索保持为服务器端流程：在 Data Designer 中建模实体和关系，在 Business Processes 中强制访问规则，并复用相同的权限检查来支持自动完成、结果列表和导出，从而仅在一个地方保持正确性。