Как поисковая система предприятия отображает результаты для пользователя и скрывает неавторизованные результаты?

Я хочу понять, как решения корпоративного поиска решают проблему разрешений пользователей.

Мой вопрос касается отображения результатов поиска для пользователей. Наивный подход будет отображать результаты поиска пользователю, а затем, если пользователь щелкнет документ, на просмотр которого он не имеет права, он не сможет его открыть. Однако запрещается даже отображать заголовок документа или отрывок, если у пользователя нет разрешения на его чтение. То же самое можно сказать и о различных корпоративных поисковых системах:

  1. индексировать каждый документ вместе с его ACL?
  2. индексировать все документы без информации о разрешении, но проверять каждую ссылку в каждом результате поиска, чтобы узнать, есть ли у запрашивающего пользователя разрешение на просмотр этой ссылки?

Вариант № 2 кажется мне более разумным, но он также кажется намного медленнее, чем вариант № 1.
Вариант № 1 страдает от необходимости постоянно обновлять изменения в разрешениях для проиндексированных документов.

Я хочу понять, каков общий подход в существующих решениях на рынке сегодня. Есть ли третий вариант?


enterprise permissions search-engine attivio
person Eye of the Storm    schedule 12.09.2010    source источник
comment
Я выбрал вариант 1. Это было довольно просто в SQL с полнотекстовым каталогом, присоединенным к ACL.   -  person ccook    schedule 12.09.2010
comment
ОК - прошло некоторое время с тех пор, как я задал этот вопрос, на который не получил ответов. Я могу поделиться опытом, который мы получили до сих пор: лучше всего индексировать вместе с ресурсом некоторую информацию, которая может помочь отфильтровать ее во время поиска. Это может быть полная информация ACL, которая обеспечит наилучшую фильтрацию, но может быть сложной в обслуживании. Это также может быть любой другой набор атрибутов, который может помочь вам отфильтровать достаточно близкий набор ресурсов и только во время фактического поиска подтвердить, к каким ресурсам действительно можно получить доступ в режиме реального времени (проверка ACL).   -  person Eye of the Storm    schedule 06.03.2011

Ответы (1)


arrow_upward
1
arrow_downward

Я удивлен, увидев, что на этот вопрос пятилетней давности нет ответов, поскольку я думаю, что это довольно распространенная и важная проблема в корпоративном поиске.

Как указано в вопросе, существует два распространенных подхода к обеспечению безопасности на уровне документов:

  • раннее связывание-безопасность: индексирование ACL вместе с содержимым и
  • поздняя привязка-security: обеспечение безопасности во время запроса путем фильтрации защищенных результатов.

Ни в коем случае не рекомендуется обеспечивать безопасность только на стороне контента, так как в этот момент конфиденциальная информация уже может быть раскрыта (например, заголовок или предварительный просмотр документа в результатах поиска).

Преимущество реализации безопасности с помощью подхода с поздним связыванием заключается в том, что он очень гибкий, поскольку нет необходимости повторно индексировать контент при изменении ACL. Однако самым большим недостатком является то, что при этом может произойти утечка конфиденциальной информации через значения фасетов, и невозможно получить и отобразить правильное количество фасетов. Кроме того, сложнее правильно заполнить список результатов и обрабатывать разбиение на страницы. И последнее, но не менее важное: этот подход может значительно снизить производительность.

Преимущество реализации безопасности с помощью подхода с ранним связыванием заключается в том, что он устраняет все вышеперечисленные недостатки за счет переиндексации содержимого сразу после изменения ACL. Однако утечки все еще возможны, например. когда членство в группе или ACL только что изменились и еще не отражены в поисковом индексе. Чтобы устранить этот пробел, два подхода раннее связывание и позднее связывание часто комбинируются.

И последнее, но не менее важное: в зависимости от используемой корпоративной поисковой платформы может быть и третий вариант: Active Security от Attivio основан на соединениях во время запроса, что позволяет индексировать безопасность. информация, независимая от самого документа, но во время запроса объединяет два документа, чтобы обеспечить попадание в результаты поиска только авторизованного контента.

person Daniel Schneiter    schedule 17.01.2016