При создании интеграций через HTTP-сервисы в 1С:Предприятии 8 одним из самых острых вопросов становится обеспечение безопасности. Мы часто сталкиваемся с необходимостью опубликовать базу «наружу», и вполне логично желание минимизировать права пользователя, под которым внешняя система будет авторизоваться. В этой статье мы подробно разберем, какие именно права требуются для стабильной работы HTTP-сервиса, что представляет собой этот тип сеанса и как правильно спроектировать систему прав, чтобы не оставить «дыр» в защите.
Прежде чем переходить к галочкам в конфигураторе, проанализируем, что происходит в кластере серверов 1С при поступлении HTTP-запроса. Многие ошибочно полагают, что это аналог Внешнего соединения или Веб-клиента. На самом деле, сеанс HTTP-сервиса — это отдельный, специфический тип сеанса.
В консоли администрирования он так и отображается: «HTTP-сервис». Его ключевые особенности:
ПриНачалеРаботыСистемы в модуле управляемого приложения.УстановкаПараметровСеанса) выполняются всегда. Это критически важно, если ваша система прав (RLS) опирается на параметры сеанса.Рассмотрим права, которые задаются в корне дерева конфигурации для роли. Выясним, какие из них действительно важны для работы нашего сервиса:
Таким образом, на верхнем уровне («Конфигурация») для работы HTTP-сервиса не требуется включать никаких специальных прав.
Теперь разберем, какие права нужно дать роли на конкретные объекты. Чтобы сервис заработал, мы должны выполнить следующие шаги:
Использование. Без этого вызова метода просто не произойдет — сервер вернет ошибку авторизации 401 или 403.Чтение, Добавление, Изменение).Просмотр относится к интерфейсу (видимость полей на формах). Поскольку у HTTP-сервиса нет интерфейса, Просмотр обычно не требуется. Однако, если вы используете механизм СКД (Система компоновки данных) внутри кода сервиса для получения данных, помните: СКД проверяет право Просмотр. Если его нет — результат запроса будет пустым.На практике предоставление прав на каждый чих (справочники, регистры сведений, константы) может превратиться в кошмар администратора, особенно если типовые подписки на события при записи объекта обращаются к множеству других объектов конфигурации. Рассмотрим наиболее эффективную архитектуру:
Создайте общий модуль, в котором установите свойство Привилегированный. Всю бизнес-логику обработки запроса вынесите в этот модуль. В самом модуле HTTP-сервиса оставьте только минимальный код приема и передачи управления:
// В модуле HTTP-сервиса
Функция ДанныеПринять(Запрос)
Возврат ИнтеграцияСВнешнейСистемойСервер.ОбработатьВходящийЗапрос(Запрос);
КонецФункции
В этом случае пользователю достаточно иметь права только на сам HTTP-сервис. Весь код внутри привилегированного модуля будет выполняться без проверки прав доступа текущего пользователя. Это не только упрощает настройку, но и существенно ускоряет работу, так как серверу не нужно проверять правила RLS (ограничение доступа на уровне записей) для каждого запроса.
Проанализируем вопрос ресурсов. Каждый активный вызов HTTP-сервиса в момент исполнения занимает одну клиентскую лицензию. Лицензия берется из доступного пула на сервере или из аппаратного ключа и освобождается сразу после того, как метод Возврат Ответ отработал.
Если ваша внешняя система шлет сотни запросов в секунду, вы можете столкнуться с нехваткой лицензий. В таких случаях лучше проектировать методы так, чтобы они принимали массив данных (пакетную обработку) за один вызов.
Часто в файле публикации default.vrd прописывают логин и пароль пользователя для автоматической авторизации:
ib="Srvr="ServerName";Ref="BaseName";" usr="IntegrationUser" pwd="Password"
Рассмотрим риски: если файл .vrd попадет в чужие руки, пароль будет скомпрометирован. Более безопасный подход — использование заголовка Authorization: Basic [base64_login_pass]. В этом случае в .vrd данные пользователя не указываются, а внешняя система сама передает учетные данные при каждом запросе. 1С прозрачно авторизует сеанс под этими данными.
Выясним, как сделать работу сервиса профессиональной. Если в коде 1С произойдет критическая ошибка (исключение), HTTP-сервер вернет код 500. Для внешней системы это малоинформативно. Рекомендуется всегда использовать конструкцию Попытка...Исключение:
Попытка
// Основная логика обработки
Ответ = Новый HTTPСервисОтвет(200); // OK
Исключение
Ответ = Новый HTTPСервисОтвет(500); // Ошибка сервера
Ответ.УстановитьТелоИзСтроки(ОписаниеОшибки());
КонецПопытки;
Возврат Ответ;
Это позволит вам не только корректно завершить сеанс, но и передать вызывающей стороне внятное описание проблемы.
Для настройки прав пользователя HTTP-сервиса придерживайтесь следующего алгоритма:
Роль_ИнтеграцияHTTP).Использование только для конкретных HTTP-сервисов.Такой подход обеспечивает максимальную безопасность системы при сохранении полной функциональности интеграции.