Как Google эффективно проверяет права доступа к защищенным документам во время поиска

Термины и определения

ACL (Access Control List)

Список контроля доступа. Структура данных, ассоциированная с документом, которая определяет, какие пользователи или группы (Aliases) имеют права доступа к этому документу. В патенте ACL рассматривается как специфический тип Alias.

Alias (Псевдоним/Группа)

Идентификатор, представляющий группу участников. Участниками могут быть пользователи и/или другие группы (вложенные Aliases).

Membership List (Список членства)

Ключевой компонент изобретения. Заранее вычисленный список всех Aliases (групп), в которые пользователь входит прямо (Direct Member) или косвенно (Indirect Member), т.е. через членство во вложенных группах.

Intersection (Пересечение)

Операция сравнения Membership List пользователя и ACL документа для нахождения общих элементов (Alias). Ненулевое пересечение означает наличие прав доступа.

Direct Member (Прямой участник)

Пользователь или Alias, который непосредственно указан в составе другого Alias или ACL.

Indirect Member (Косвенный участник)

Пользователь, который является членом Alias, который, в свою очередь, является членом другого Alias или ACL.

ACL Map (Карта ACL)

Структура данных, отображающая соответствие между документами и их ACLs.

Ключевые утверждения (Анализ Claims)

Патент описывает внутренние процессы Google без прямых рекомендаций для SEO.

Claim 1 (Независимый пункт): Описывает основной метод контроля доступа.

1. Система ассоциирует пользователя с первым набором псевдонимов (Membership List). Важное условие: эта ассоциация происходит до получения запроса от пользователя.
2. Система ассоциирует документ со вторым набором псевдонимов (ACL).
3. При получении запроса система определяет, имеют ли первый и второй наборы общий псевдоним.
4. Ключевой механизм: определение происходит путем пересечения (intersecting) наборов без рекурсивного анализа (without recursively analyzing) этих наборов в реальном времени.
5. Доступ предоставляется, если общий псевдоним найден, и запрещается, если нет.
6. Описан механизм обновления: если членство пользователя в группе меняется или меняется структура групп, первый набор (Membership List) подвергается действию (инвалидация, пересчет или модификация).

Ядро изобретения — замена медленного рекурсивного анализа в реальном времени на быстрое пересечение предварительно рассчитанных списков.

Claim 3 (Независимый пункт): Альтернативное описание метода, сфокусированное на процессе генерации.

1. Генерация Membership List для пользователя (включая прямое и косвенное членство) до запроса пользователя.
2. Назначение документу ACL.
3. В ответ на запрос: пересечение Membership List и ACL для определения наличия общего псевдонима без рекурсивного анализа.
4. Предоставление или запрет доступа на основе результата пересечения.
5. Обновление (инвалидация, пересчет) Membership List при изменении структуры членства.

Где и как применяется

Изобретение применяется в инфраструктуре поиска для управления доступом к непубличному контенту (например, Google Workspace, Enterprise Search, персонализированный поиск).

INDEXING – Индексирование и извлечение признаков
На этом этапе система индексирует защищенные документы и ассоциирует с ними соответствующие ACL. Эта информация сохраняется в индексе (например, в ACL Map).

(Офлайн-процессы / Обслуживание данных)
Система заранее рассчитывает и кэширует Membership Lists для всех пользователей. Эти списки обновляются при любых изменениях в структуре групп (Aliases). Этот процесс может быть рекурсивным, но он выполняется заранее, а не в момент запроса.

RANKING / RERANKING (Фильтрация результатов)
Основное применение патента в контексте поиска. Система должна гарантировать, что пользователь увидит только доступные ему результаты. Патент предлагает два варианта реализации:

1. Вариант 1: Фильтрация после поиска (Post-filtering, FIG. 6).
   1. Система выполняет стандартный поиск (RANKING) по всему корпусу и получает набор результатов.
   2. На этапе RERANKING для каждого документа выполняется проверка доступа: пересечение ACL документа и Membership List пользователя.
   3. Если пересечение пустое, документ удаляется из выдачи.
2. Вариант 2: Фильтрация до поиска (Pre-filtering, FIG. 7).
   1. Система анализирует Membership List пользователя, чтобы определить все доступные ему ACL.
   2. Система определяет множество документов, ассоциированных с этими доступными ACL.
   3. Поиск (RANKING) выполняется только по этому подмножеству доступных документов.

Входные данные:

• Идентификатор пользователя и его запрос.
• Предварительно вычисленный Membership List пользователя.
• Корпус документов с ассоциированными ACL.

Выходные данные:

• Отфильтрованный список результатов поиска, содержащий только те документы, к которым у пользователя есть доступ.

На что влияет

• Типы контента и Среды: Влияет исключительно на системы поиска по защищенным (приватным) данным, где требуется контроль доступа. Примеры: корпоративный поиск, поиск в Google Drive, поиск по Gmail.
• Публичный веб-поиск: Не оказывает никакого влияния на ранжирование или отображение общедоступных веб-страниц на Google.com.

Когда применяется

• Условия работы: Применяется при каждом поисковом запросе в системе, которая управляет доступом к документам с помощью ACL и Aliases, и когда пользователь идентифицирован (залогинен).

Пошаговый алгоритм

Процесс проверки доступа к документу (Real-time)

1. Получение запроса: Система получает запрос на доступ к документу (например, как часть поискового запроса).
2. Идентификация субъектов: Идентифицируется запрашивающий пользователь и запрашиваемый документ.
3. Получение данных доступа: Система извлекает ACL документа и заранее вычисленный Membership List пользователя (например, из кэша).
4. Пересечение (Intersection): Выполняется операция пересечения множеств Membership List и ACL.
5. Принятие решения:
   1. Если результат пересечения не пустой (Intersection != Null), это означает наличие общего Alias. Доступ разрешается.
   2. Если результат пересечения пустой (Intersection = Null), общих Alias нет. Доступ запрещается (документ фильтруется из выдачи).

Какие данные и как использует

Данные на входе

Патент фокусируется исключительно на инфраструктурных данных для управления доступом. Он не упоминает никаких факторов, используемых в публичном SEO (контентных, ссылочных, поведенческих и т.д.).

• Инфраструктурные данные:
  • Идентификаторы пользователей и групп (Aliases).
  • Access Control Lists (ACLs): Права доступа, назначенные документам.
  • Membership Lists: Предварительно вычисленные списки членства пользователей.
  • Структуры данных, описывающие иерархию групп (используются в офлайн-процессе).

Какие метрики используются и как они считаются

В патенте не используются метрики ранжирования или оценки качества. Используется одна ключевая операция над множествами.

• Проверка пересечения: Основная операция — это булева проверка пересечения множеств. Доступ разрешен, если: $(Membership List \cap ACL) \neq \emptyset$
• Условие срабатывания: Результат пересечения не равен нулю (Non-Null), что означает наличие хотя бы одного общего элемента.

Патент описывает внутренние инфраструктурные процессы Google и не дает практических выводов для публичного SEO.

1. Фокус на производительности и масштабируемости: Основная цель изобретения — обеспечить быструю проверку прав доступа в крупных системах, не замедляя при этом поиск.
2. Предварительные вычисления вместо реального времени: Ключевая инновация заключается в отказе от ресурсоемкой рекурсивной проверки прав доступа в момент запроса. Вместо этого используется предварительный расчет полных списков членства (Membership Lists).
3. Проверка через пересечение: Проверка доступа сводится к быстрой математической операции пересечения двух множеств (Membership List и ACL).
4. Применимость к приватному поиску: Этот механизм является ключевым для работы сервисов с ограниченным доступом, таких как Google Workspace или корпоративный поиск, позволяя быстро фильтровать результаты.
5. Отсутствие связи с ранжированием: Описанный механизм является бинарным фильтром (доступен/недоступен). Он не влияет на то, как ранжируются доступные документы между собой в публичном вебе.

ВАЖНО: Патент является инфраструктурным и не дает практических выводов для SEO-специалистов, работающих с публичным веб-поиском (Google.com).

Best practices (это мы делаем)

Практических рекомендаций для стандартного SEO, основанных на механизмах этого патента, нет.

Worst practices (это делать не надо)

Практических рекомендаций для стандартного SEO, основанных на механизмах этого патента, нет. Патент не направлен против каких-либо SEO-тактик.

Стратегическое значение

Для публичного SEO стратегическое значение нулевое. Патент важен для понимания того, как Google решает инженерные задачи масштабирования при обработке персонализированных и приватных данных, но он не дает никаких инсайтов о работе алгоритмов ранжирования Google.com.

Практические примеры

Практических примеров для публичного SEO нет. Ниже приведен пример работы механизма в контексте приватного поиска (например, Google Workspace) для иллюстрации.

Сценарий: Поиск по корпоративным документам

1. Структура групп: Пользователь User_A входит в группу "Инженеры". Группа "Инженеры" входит в группу "Технический департамент".
2. Предварительное вычисление (Офлайн): Система заранее рассчитала Membership List для User_A: ["Инженеры", "Технический департамент"].
3. Документ: Документ "Стратегия развития" имеет ACL: ["Менеджмент", "Технический департамент"].
4. Поиск (Онлайн): User_A ищет "Стратегия развития". Система находит документ.
5. Проверка доступа (Онлайн): Система выполняет пересечение: Membership List ["Инженеры", "Технический департамент"] ∩ ACL ["Менеджмент", "Технический департамент"].
6. Результат: Пересечение = ["Технический департамент"]. Оно не пустое. Доступ разрешен. Документ показывается в выдаче. Этот процесс занимает миллисекунды.