# Как защитить Manticore Search с помощью встроенной аутентификации и авторизации

Узнайте, как включить аутентификацию в Manticore, создать первого администратора, завести пользователей с минимальными правами, использовать учётные данные в SQL и HTTP, а также проверить разрешённый и запрещённый доступ.

Поиск нередко считают просто инфраструктурой. Но в продакшене он фактически работает как API приложения: принимает пользовательский трафик, отдаёт бизнес-данные, обслуживает дашборды и нередко стоит рядом с записями, которые не должны быть доступны каждому клиенту в сети.

В Manticore Search теперь (с релиза [27.1.5](http://localhost:1313/blog/manticore-search-27-1-5/)) есть встроенная аутентификация и авторизация — для SQL по протоколу MySQL, для HTTP/HTTPS-эндпоинтов и для операций, связанных с репликацией.

Аутентификация отвечает на вопрос «кто делает запрос?». Авторизация — «что этому пользователю разрешено делать?».

Пользователи, которые уже используют Manticore могут подключить новую функциональность, сохранив привычные способы работы с Manticore. Существующие SQL и HTTP-клиенты сохраняют свои обычные паттерны подключения. В приложениях требуются минимальные изменения.

## Что добавилось в Manticore

- Аутентификация SQL/MySQL по паролю с `mysql_native_password`.
- HTTP Basic-аутентификация с тем же именем пользователя и паролем.
- HTTP Bearer-токены для случаев, когда нельзя отправлять пароль в каждом запросе.
- Пермиссии на пять понятных действий: `read`, `write`, `schema`, `replication` и `admin`.
- Цели вроде `products`, `logs_*`, `posts` и `*`.
- SQL-команды для управления пользователями, токенами и правами.
- Лог аутентификации с уровнями `disabled`, `error`, `warning`, `info`, `all` и `trace`. По умолчанию — `info`.

Модель доступа специально задумана компактной. Просто создайте пользователей, назначьте им соответствующие права, обновите приложение, чтобы оно отправляли учётные данные, и убедитесь, что запрещённые операции действительно запрещены.

## Включение аутентификации

Аутентификация включаемся параметром `auth` в секции `searchd` в конфиге.

Для [режима RT](https://manual.manticoresearch.com/Read_this_first#Real-time-mode-vs-plain-mode) задайте `auth = 1`. В этом случае Manticore будет хранить данные аутентификации в файле `auth.json` в каталоге `data_dir`.

```ini
searchd {
    data_dir = /var/lib/manticore
    auth = 1
    auth_log_level = info
}
```

Чтобы отключить аутентификацию в режиме RT, установите `auth = 0` либо удалите директиву.

В режиме plain задайте в `auth` путь к файлу аутентификации:

```ini
searchd {
    auth = /var/lib/manticore/auth.json
    auth_log_level = info
}
```

При передаче паролей или bearer-токенов по сети обязательно используйте SSL для SQL-соединений и HTTPS для HTTP-клиентов.

Обеспечьте ограниченный доступ к файлу аутентификации: он должен быть недоступен посторонним. До первой инициализации Manticore может создать пустой файл аутентификации. После инициализации в нём хранятся данные аутентификации и хеши учётных данных.

## Инициализация первого администратора

После включения `auth` запустите `searchd`. Затем создайте первого администратора, используя тот же конфигурационный файл:

```bash
searchd --config /etc/manticoresearch/manticore.conf --auth
```

Для автоматизированной инициализации используйте неинтерактивный режим:

```bash
printf 'admin\nStrongPass#2026\nStrongPass#2026\n' | \
  searchd --config /etc/manticoresearch/manticore.conf --auth-non-interactive
```

Для инициализации обязательно требуется запущенный демон. Эта команда создаёт первого администратора и выдаёт ему права на все действия.

bearer-токен при этом не выдаётся автоматически. Если администратору нужен доступ через HTTP Bearer, подключитесь под этим администратором и выполните `TOKEN`, либо вызовите HTTP-эндпоинт `POST /token`.

## Создание пользователей

После инициализации администратора вы можете через его учётную запись управлять пользователями и правами через SQL-команды. Не используйте его учётную запись в приложении. Вместо этого создавайте отдельных пользователей под конкретные задачи.

Например, поисковому фронтенду, который только читает из `products`, нужны права `read`, а не `write`, `schema`, `replication` или `admin`:

```sql
CREATE USER 'app_read' IDENTIFIED BY 'ReadPass#2026';
GRANT read ON 'products' TO 'app_read';
```

Команда `CREATE USER` выводит bearer-токен нового пользователя в открытом виде. Сохраните его сразу — повторно Manticore его не покажет.

Чтобы позже создать или перевыпустить bearer-токен:

```sql
TOKEN 'app_read';
```

Команда `TOKEN 'app_read'` возвращает новый готовый к использованию токен в открытом виде. Имейте в виду, что `SHOW TOKEN` показывает сохранённый хеш токена, а не сам токен, который нужно отправлять в HTTP-запросе. Это полезно для проверки и аудита: можно убедиться, что токен существует или изменился после перевыпуска, не раскрывая сам секрет:

```sql
SHOW TOKEN FOR 'app_read';
```

`SET PASSWORD` меняет пароль, используемый SQL/MySQL и HTTP Basic-аутентификацией:

```sql
SET PASSWORD 'NewReadPass#2026' FOR 'app_read';
```

Существующие bearer-токены при этом не отзываются. Чтобы перевыпустить токен для Bearer-доступа, создайте новый через `TOKEN` или `POST /token`:

```sql
TOKEN 'app_read';
```

ETL-пайплайну, который загружает данные, достаточно `write` — более широкие права не нужны:

```sql
CREATE USER 'app_ingest' IDENTIFIED BY 'IngestPass#2026';
GRANT write ON 'products' TO 'app_ingest';
```

Задаче миграции схемы таблиц можно выдать `schema`:

```sql
CREATE USER 'schema_job' IDENTIFIED BY 'SchemaPass#2026';
GRANT schema ON 'products' TO 'schema_job';
```

Администратор аутентификации может получить права `admin`:

```sql
CREATE USER 'security_admin' IDENTIFIED BY 'AdminPass#2026';
GRANT admin ON * TO 'security_admin';
```

Права `admin` управляет только состоянием аутентификации и авторизации. Это не подразумевает `read`, `write`, `schema` или `replication`. Если этому же пользователю такие права действительно нужны, выдайте их отдельно.

## Подключение через SQL и HTTP

mysql-клиенты проходят аутентификацию по имени пользователя и паролю Manticore:

```bash
MYSQL_PWD=ReadPass#2026 \
  mysql -h127.0.0.1 -P9306 -uapp_read \
  -e "SELECT * FROM products LIMIT 10"
```

HTTP/HTTPS-клиенты могут использовать Basic-аутентификацию:

```bash
curl -u app_read:ReadPass#2026 \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"
```

Также можно использовать bearer-токен, возвращённый командами `CREATE USER`, `TOKEN` или `POST /token`:

```bash
curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"
```

Схемы аутентификации `Basic` и `Bearer` нечувствительны к регистру, а имена пользователей чувствительны.

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

## Тестирование после включения аутентификации

Совет: при включении доступа к Manticore не стоит останавливаться на проверке того факта, что клиент может подключиться после включения аутентификации. Неплохо бы ещё проверить и запрещённый доступ и то, как ваше приложение на это отреагирует.

Пользователь `app_read` должен успешно читать из `products`:

```bash
curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "SELECT * FROM products LIMIT 10"
```

А вот запись в `products` у того же пользователя проходить не должна:

```bash
curl -H "Authorization: Bearer <app_read_token>" \
  http://127.0.0.1:9308/sql?mode=raw \
  -d "INSERT INTO products(id,title) VALUES(1,'test')"
```

Ошибка в данном случае — ожидаемое поведение. Если у пользователя нет необходимых пермиссий, HTTP-запрос завершится ошибкой `403 Forbidden`. По SQL/MySQL Manticore возвращает `ERROR 1045` с сообщением о запрете доступа.

## Как проверяется, что можно, а что нельзя

Права в Manticore — это правила вида «действие + цель». Если ни одно правило не разрешает запрошенное действие над запрошенной целью, доступ запрещается.

Коротко:

- Правила сопоставляются только для запрошенного действия. `admin` не покрывает `read`, `write`, `schema` или `replication`.
- `WITH ALLOW 0` создаёт явный запрет.
- Любой совпавший явный запрет побеждает, даже если есть более специфичное разрешающее правило.
- Если совпавшего разрешения нет, доступ запрещается.

Пример:

```sql
CREATE USER 'analyst' IDENTIFIED BY 'AnalystPass#2026';
GRANT read ON * TO 'analyst';
GRANT read ON 'private_logs' TO 'analyst' WITH ALLOW 0;
```

Пользователь `analyst` может читать остальные таблицы, но не может читать `private_logs`.

Запрет по маске в сочетании с точным разрешением нельзя использовать, как способ сделать исключение. Если запрет совпадает с запросом, он всё равно побеждает.

## Внедрение доступа в уже работающей системе

Аутентификацию на уже работающих инстансах Manticore рекомендуется внедрять поэтапно, а не переключать всё за раз:

1. Составьте список SQL и HTTP-клиентов, которые подключаются к Manticore.
2. Выберите путь к файлу аутентификации: `auth.json` в `data_dir` в режиме RT, либо явный путь в режиме plain.
3. Включите аутентификацию на стейджинге.
4. Инициализируйте первого администратора.
5. Создайте пользователей с минимальными правами для поиска, записи, изменения схемы, репликации и администрирования аутентификации.
6. Обновите код подключения через SQL в вашем приложении, чтобы он отправлял имя пользователя и пароль.
7. Обновите код подключения через HTTP/HTTPS, чтобы он использовал Basic-аутентификацию или Bearer-токены.
8. Для каждого пользователя приложения проверьте ожидаемый успех и ожидаемый отказ.
9. Настройте подходящий уровень логирования аутентификации и убедитесь, что лог хранится безопасно вместе с остальными операционными логами.
10. Выкатывайте изменения постепенно, а после переключения перевыпустите учётные данные для большей безопасности и дополнительного теста и самообучения.

Для распределённых таблиц нужна ещё одна проверка. Запросы к удалённым агентам проходят аутентификацию от имени текущего пользователя сессии, поэтому на удалённом демоне должны быть совпадающие данные аутентификации для этого пользователя, а у самого пользователя — нужное право на удалённую целевую таблицу.

Кластеры репликации используют действие `replication`. Когда аутентификация включена, присоединение к кластеру может заменить локальные данные аутентификации данными из донорского кластера, поэтому до присоединения согласуйте данные аутентификации между узлами. Во время работы с кластером обращайтесь с логом аутентификации (по умолчанию файл `searchd.log.auth`) с бережностью, так как в нём могут содержаться соли и хеши учётных данных.

## Полный справочник

Полный набор команд и детали эксплуатации новой фукнциональности приведены в разделе руководства — включая политику паролей, уровни лога аутентификации, `SHOW USERS`, `SHOW PERMISSIONS`, `RELOAD AUTH`, а также работу удалённых агентов в распределённых таблицах и кластеры репликации:

[Руководство по аутентификации и авторизации](https://manual.manticoresearch.com/Security/Authentication_and_authorization)

Но для большинства приложений рецепт простой: включить аутентификацию, инициализировать администратора, создать пользователей с минимальными правами, обновить клиентов и убедиться, что правильные запросы проходят, а неправильные — отклоняются.