来自 Elastic Search、Solr 或答案

【问题标题】：Data security in result sets from Elastic Search, Solr or来自 Elastic Search、Solr 或
【发布时间】：2012-02-07 20:42:06
【问题描述】：

我需要将全文搜索功能添加到我现有的数据库中。当然，首先转向 Solr 或 Elastic Search 之类的东西。我必须解决的问题是——如何安全地显示从底层搜索引擎返回的结果（我们现在考虑一下 Solr 或 Elastic Search，但是任何其他解决方案或引擎也能达到这一点）。

棘手的上下文是，例如，我的系统中的个人资料记录要被索引。个人资料中的字段之一是 - 经理的反馈。通常在系统中，该字段仅对员工的直接经理和更高层级可见，即来自另一个分支机构的“经理”将无法看到该字段。但是，我希望该字段可以通过全文搜索进行搜索，但仅限于实际可以看到它的人。

现在我向 Solr 查询“stupid”（即查询字符串），它返回 N 个文档。将其返回给最终用户时，我将删除“经理的反馈”字段，因为最终用户不是特定人员的经理——但结果集中的文档已经是“愚蠢”家伙的证据……

问题是——处理该用例的可行方法是什么？是否可以使用本地安全过滤器插入 Solr/ES 以进行输出？

注意事项：

由于上述情况，仅过滤掉字段不起作用
过滤掉完整的文档将不起作用，因为
1. 搜索引擎不知道哪些字段匹配 - 因此无法按字段手动过滤结果集http://elasticsearch-users.115913.n3.nabble.com/Best-way-to-return-which-field-matched-td2713071.html
2. 即使这确实有效，从结果集中删除文档也会破坏引擎返回的方面（例如，按部门匹配的数量）——我必须手动重新计算方面，否则它们将与手动过滤的记录不匹配，并且会揭示我实际上不想向最终用户展示的内容

【问题讨论】：

标签： solr elasticsearch

【解决方案1】：

在 Solr 中，您可以创建 multiValued 字段。在您的情况下，您可以使用它来存储组织结构的非规范化值。

在所描述的场景中，您将创建多值字段ouId（组织单位 ID）并存储员工的 ouId 和所有父 ouId。换句话说，您将 allowed ouIds 保存到此字段中。

在搜索场景中，您将使用FilterQuery - fq 参数过滤按经理的ouId。

例子：

..&fq=ouId:12

其中 12 是所选经理的组织单位 ID。

【讨论】：

我没有提到，但这种方法已经过评估并被拒绝，因为 - ouID 的数量可能非常大（在超过 5000 名员工的组织中）。这必须为每个可限制字段完成（例如乘以 10-20） - 这会产生大约 50000 个项目的开销，并使对 solr 的查询过于复杂。最后 - 当组织结构发生变化时，这将完全被破坏:( - 所有 ACL 都必须重新计算。
反规范化有利有弊。开销是* avg。组织结构深度。你的 20 意味着有些员工对 CEO 有 20 个级别。即使这是真的，solr 响应时间也将低于 100 毫秒（在我们的案例中，超过 800000 条记录的平均响应时间约为 50 毫秒）。如果组织发生巨大变化 - 您只需重新索引整个数据库（对于 5000 名员工，这大约需要 10-30 秒）。
我觉得我在你的 cmets 中遗漏了一些东西。在我的例子中，“20”意味着每条记录（要被索引）有 20 个不同的字段，每个字段都有自己的权限规则——因此 ACL 必须单独分配给这些字段中的每一个。我认为我对需要存储在 ouId 中的内容有不同的理解——一般来说，这可以是任何动态规则，最终导致公司中每个用户的“允许”/“拒绝”，因此如果以这种方式指定 ACL 将非常长.您的解决方案仅解决了 ACL 分配的一个用例（对组织单位的粒度），我们不能将其限制为:(。
根据我在人力资源管理部门的经验，您的要求不会有效，很难维护，只有少数人会真正使用它们。另一方面，反规范化是所有搜索解决方案中的常规过程，Solr 就是针对这种情况而设计的。

【解决方案2】：

也许这对你有帮助 https://github.com/salyh/elasticsearch-security-plugin 它为 elasticsearch 添加了文档级别的安全性。

“目前，对于基于用户的身份验证和授权，Kerberos/SPNEGO 和 NTLM 通过 3rd 方库 waffle 支持（仅在 Windows 服务器上）。对于 UNIX 服务器，通过 SPNEGO Valve 中的 tomcat 构建支持 Kerberos/SPNEGO（适用于任何 Kerberos 实现。对于授权，支持 Active Directory 和通用 LDAP）。还支持 PKI/SSL 客户端证书身份验证（CLIENT-CERT 方法）。无需客户端身份验证也支持 SSL/TLS。

您也可以在没有 Kerberos/NTLM/PKI 的情况下使用此插件，但只有基于主机的身份验证可用。

目前已实现两个安全模块：

Actionpathfilter：在粗粒度级别上限制针对 Elasticsearch 的操作，例如允许谁进行 READ、WRITE 甚至 ADMIN rest api 调用文档级别安全性 (dls)：限制文档级别的操作，例如允许谁查询文档中的哪些字段”

【讨论】：