Поиск — уже не просто поле на веб‑сайте. Во многих случаях Manticore Search работает как внутренняя служба обработки данных: приложения направляют к нему запросы, процессы загрузки данных обновляют таблицы в нём, панели мониторинга получают из него данные, а операторы изменяют схемы таблиц. Когда всё это опирается лишь на сетевое доверие, контроль доступа быстро становится уязвимым.
Именно поэтому в Manticore Search теперь встроены аутентификация и авторизация. Функциональность добавлена в версиях 27.x и описана в посте о релизе 27.1.5 : она позволяет Manticore проверять, кто подключается и что этому пользователю разрешено делать.
Новая функциональность работает через SQL, HTTP/HTTPS-клиентов, распределённых и удалённых агентов и поддерживает репликацию.
Что добавилось
Теперь Manticore Search поддерживает аутентификацию и авторизацию для основных способов доступа:
- Клиенты работающие через протокол MySQL проходят аутентификацию по имени пользователя и паролю.
- Клиенты HTTP могут использовать Basic-аутентификацию или Bearer-токены.
- Права назначаются по действию и цели.
- События аутентификации можно логировать, поддерживается несколько уровней детализации.
- Пользователями и правами можно управлять с помощью отдельных SQL-команд.
Модель авторизации использует пять действий:
read— для поиска и доступа только на чтение.write— для изменения данных.schema— для управления таблицами и схемой.replication— для операций с кластером.admin— для управления аутентификацией и авторизацией.
Цели — это обычные имена или подстановочные шаблоны, например products, logs_* или *. Благодаря этому модель остаётся близкой к тому, как люди уже привыкли думать о таблицах и кластерах Manticore Search.
Что меняется для операторов
Часто бывает, что клиентское приложение может искать в таблице, не имея возможности туда писать. Процесс загрузки данных может обновлять документы, не меняя схемы. Задача миграции схемы может выполняться без предоставления прав администратора безопасности. Пользователь-оператор может управлять аутентификацией и авторизацией, не получая автоматически доступ на чтение бизнес-данных.
Эти границы прав становятся важны, когда поиск превращается частью общей инфраструктуры. Смысл не только в том, чтобы не пускать посторонних, но и в том, чтобы ограничить каждого доверенного юзера только тем, что ему действительно нужно.
Теперь Manticore делает подобные вещи легко настраиваемыми. Пользователи проходят аутентификацию через уже привычные протоколы. Manticore проверяет права по действиям и целям. Операторы управляют доступом с помощью SQL-команд, а приложения продолжают использовать обычный способ доступа через SQL или HTTP.
Почему это важно для SaaS и общих поисковых систем
Командам SaaS и общих сервисов часто нужен один поисковый слой для нескольких продуктов, команд или тенантов. Одни интеграции нацелены на работу с клиентами, другие используются внутренними инструментами, а третьи работают в фоне. У них не должен быть одинаковый уровень доверия.
До появления встроенной аутентификации командам приходилось решать большую часть этого вне Manticore. Распространённое решение было использовать nginx перед Manticore и опираться там на HTTP Basic authentication. Так можно было защитить одну точку входа, но у Manticore при этом не было собственной модели пользователей и прав. Теперь команды могут реализовывать разграничение прав непосредственно в Manticore, где обрабатываются данные.
Это делает Manticore Search удобнее для клиентского поиска по чувствительным данным, внутренних инструментов с разными уровнями прав и общих поисковых кластеров, которые используют сразу несколько сервисов.
Аутентификация и авторизация сами по себе ещё не являются полноценной программой соответствия требованиям. Однако проверяющие органы обычно ожидают увидеть такие меры контроля. При проверках на соответствие GDPR, SOC 2 и внутренним требованиям безопасности гораздо убедительнее выглядят именные учётные записи, ограниченные права доступа и журналы аутентификации, а не один общий логин с полным доступом ко всему.
Примечания по развёртыванию
Администратор Manticore может активировать аутентификацию и создать учётную запись первого администратора, а затем управлять пользователями и правами с помощью привычных SQL-команд. Приложениям не требуется отдельный шлюз для Manticore только ради передачи учётных данных. SQL-клиенты используют имена пользователей и пароли. HTTP-клиенты используют Basic authentication или Bearer tokens.
Для уже действующих инсталляций переход на аутентификацию рекомендуется выполнять поэтапно, не ограничиваясь простой сменой конфигурации. По умолчанию аутентификация отключена, пока её не настроят. После включения клиенты, которые не отправляют учётные данные, должны получать ошибку, поэтому первым делом обновите ваше приложение и протестируйте ожидаемые отказы до переключения боевого трафика.
Для распределённых или реплицируемых топологий планируйте развёртывание особенно внимательно. Сначала обновите удалённых агентов и реплики, затем обновите мастера, которые к ним обращаются или ими управляют, и включайте аутентификацию только после того, как вся топология будет работать на одной или совместимых версиях.
Подробнее
Практическое пошаговое руководство — в статье к запуску:
Как защитить Manticore Search с помощью встроенной аутентификации и авторизации
Для уже работающих развёртываний см. контрольный список по поэтапному запуску:
Полную справку смотрите на странице документации: