Продукт держит в себе ключи от поставщиков, пароли каналов связи и журнал обращений, поэтому к безопасности стоит отнестись внимательно. Здесь собрано, что уже сделано в самом продукте, а что нужно сделать на стороне сервера и в привычках команды.
Учётная запись администратора
Администратор один, и он задаётся переменными окружения — так что завести «лишнего» пользователя нельзя, даже случайно. Пароль хранится не как текст, а его необратимой суммой (SHA-256, записанной строчными буквами). Вход держится 90 дней — до тех пор пароль повторно вводить не придётся.
Выход закрывает сессию только в том браузере, из которого вы вышли. Чтобы завершить сессии во всех местах, нужно сменить ключ подписи сессий (переменная окружения) или пересоздать контейнер без постоянного ключа: после этого все выданные входы перестают работать.
Где хранятся секреты
- Ключи поставщиков и пароли каналов связи лежат не в базе, а в файлах папки конфигурации (по умолчанию
/project/apps/proxy) —models.ymlиhttp-providers.yml; там же лежит ссылка на подписку Happ. В интерфейсе и при управлении по API эти секреты показываются заглушкой: сохранить можно, прочитать обратно — нет. - Вместо самого секрета в файле можно записать ссылку на переменную окружения вида
$ИМЯ_ПЕРЕМЕННОЙ. Тогда секрет подставляется в момент использования и в файле не лежит вовсе. - Секреты можно держать в одном файле
.envрядом с проектом (по умолчанию/project/.env, путь меняетсяPROXY_APP_ENV_FILE). Настоящие переменные окружения важнее файла; сам файл стоит добавить в.gitignore. - Права на папку конфигурации важны не меньше прав на базу: в ней теперь лежит вся настройка вместе с секретами. Папку стоит защитить и включить в резервные копии.
- Ключи доступа хранятся только отпечатком и последними 8 знаками. Готовый ключ показывается один раз, и восстановить его из базы невозможно.
- Секреты скрытия секретов в отчётах об утечках замаскированы и хранятся ограниченное время.
Чего нет в журнале
Тексты запросов и ответов не сохраняются никогда — это принципиально. Поэтому даже полный доступ к базе не покажет, о чём вы переписывались с моделями: там только время, модель, ключ, объём, стоимость и ошибки.
Кто может обратиться из браузера
Внешние обращения к интерфейсу разрешены только с того же адреса, где открыт продукт. Это значит, что посторонний сайт не сможет из браузера вашего сотрудника незаметно обратиться к вашему прокси: браузер сам заблокирует такой запрос. Отдельно от этого адреса /api/* открыт для программ — он защищён ключами доступа и пропускает запросы только при действительной лицензии.
Управление по API
Всё, что администратор делает в браузере, можно делать и программой — по адресу /api/agent/*. Это удобно, если продуктом управляет другой агент или ваш скрипт: заводить модели и каналы связи, вести ключи доступа, читать журналы и аналитику, менять настройки и правила скрытия секретов.
Доступ закрыт ключом управления. Ключ задаётся переменной окружения PROXY_APP_HASH и передаётся в заголовке X-API-Key. В переменной хранится не сам ключ, а его необратимая сумма (SHA-256, записанная строчными буквами), — поэтому по файлу с переменными восстановить ключ нельзя. Если переменная не задана, поверхность отвечает «выключено» (503). Список всего, что доступно, продукт отдаёт сам по запросу GET /api/agent: это её единственная документация.
Ключ управления стоит держать в секрете — он открывает всё то же, что и вход администратора. При этом пароль администратора он не заменяет: обычный вход в браузер по нему не открыть, только разовый код для входа. Лицензией эта поверхность не закрыта — управление работает и без ключа лицензии, а секреты остаются закрытыми: модели, каналы и ключи доступа показываются теми же заглушками, что и в интерфейсе.
Подробнее — в разделе Управление агентом по API.
Что стоит сделать при выходе в интернет
- Настроить HTTPS — чтобы пароль и ключи не ходили открытым текстом.
- Завести отдельную базу со своим паролем — не использовать общую с другими программами.
- Защищать и копировать папку конфигурации — в ней лежит вся настройка и секреты. Права на неё важны не меньше прав на базу. Если секреты лежат в файле
.env, защищайте и его и не коммитьте: в нём ключи поставщиков, лицензия и ключ управления. - Разобраться с портами прокси-службы. Порт теперь у каждого канала свой — их столько, сколько каналов вы предоставили. Публикуйте только нужные, остальные закрывайте файрволом, а у опубликованных включайте проверку входа. Если проверка выключена, любой, кто дотянется до порта, сможет передавать трафик через ваш сервер — продукт предупреждает об этом в редакторе канала.
- Задать ключ лицензии. Без действительного ключа трафик через прокси не идёт: интерфейс, чат и проверка состояния работают, а запросы к моделям и обычный трафик — нет. Это ожидаемое поведение, а не поломка.
- Выдавать отдельный ключ доступа каждому человеку и подрядчику — с пределом расхода и списком моделей. Тогда отзыв доступа не задевает остальных.
- Регулярно делать дамп базы — это и защита от потери истории, и способ разобраться в происходящем.
Что честно не защищено
- Украденный ключ доступа работает до отзыва. Продукт не знает, кто держит ключ, — он проверяет только сам ключ. Поэтому отзывать ключи нужно сразу, как только человек или подрядчик уходит.
- Администратор видит всё. Настройки, ключи заглушками, журналы и расходы доступны ему целиком. Учёная запись одна — разделить права между людьми нельзя.
- Сервер — вне продукта. Защита самого сервера, базы, папки конфигурации и файрвола остаётся на вас: продукт не заменяет её и не настраивает.
Это последняя страница документации. Вернуться к списку разделов можно в оглавлении документации, а за общей картиной продукта — на страницу «Прокси-агент».