Эксперты в подборе IT-оборудования
Чаще всего в сервере 1С ломается вот что: учётная запись, под которой работает служба, и права, которые ей выдали «чтобы заработало». Через неё пользователь базы дотягивается до файлов сервера, а иногда и до домена целиком. Ошибки платформы и пропущенные обновления в этом списке идут далеко позади.
Разберём четыре места, где это происходит: учётка службы, подключение к СУБД, права внутри базы и администратор кластера. Плюс профили безопасности - штатный механизм платформы, которым всё перечисленное закрывается, и про который вспоминают в последнюю очередь.
При установке сервера платформа заводит отдельного пользователя операционной системы - USR1CV8 на Windows, usr1cv8 на Linux. Прав у него немного, и это правильно: серверные процессы должны работать с минимумом полномочий.
Проблемы начинаются, когда серверу нужен сетевой ресурс. Выгрузить файл обмена в общую папку, положить туда печатные формы, забрать данные из соседней системы. Локальная учётка в домен не ходит, обмен не работает, и дальше сценарий предсказуем: службу перевешивают на доменную учётную запись. Обычно на ту, которая точно всё откроет.
Правильный вариант звучит скучнее. Заводится отдельная доменная учётка под службу сервера 1С, ей запрещается интерактивный вход, и права выдаются точечно - на конкретные папки и конкретные серверы. В Domain Admins её быть не должно. Ни постоянно, ни «временно, до понедельника».
В 1С код исполняется в двух контекстах - на клиенте и на сервере. Процедура, помеченная как серверная, выполняется процессом rphost, то есть с правами той самой учётной записи службы.
Дальше арифметика простая. Кто может выполнить свой код на сервере - разработчик, пользователь с правом запускать внешние обработки, человек, подключившийся к кластеру снаружи, - тот получает права учётки службы на уровне операционной системы. Права в самой базе тут уже ни при чём.
Сервер 1С, работающий под администратором домена, отдаёт весь домен любому, кто сможет запустить в базе внешнюю обработку. Платформа тут ни при чём, и чинится это за пять минут. Проверяйте этот пункт раньше всех остальных.
Сисадмины про двухконтекстное исполнение часто не знают - это территория 1С-ников. А 1С-ники редко смотрят, под кем крутится служба. Дыра живёт ровно в этом зазоре между двумя зонами ответственности.
Про этот механизм вспоминают реже всего, хотя он в платформе есть и делает именно то, что нужно.
Профиль безопасности - набор разрешений, который администратор кластера назначает информационной базе. Только что созданный профиль запрещает всё потенциально опасное сразу:
| Что блокирует новый профиль | Зачем это нужно |
|---|---|
| Доступ к файловой системе сервера | код из базы не читает и не пишет файлы вне разрешённых каталогов |
| Запуск COM-объектов (Windows) | нельзя дёрнуть внешнее приложение на сервере |
| Использование внешних компонент | сторонняя библиотека не подгрузится |
| Внешние отчёты и обработки | главный канал запуска чужого кода закрыт |
| Запуск приложений на сервере | никаких вызовов оболочки |
| Обращение к интернет-ресурсам | база не ходит наружу самостоятельно |
Дальше разрешения добавляются по одному - белым списком, под конкретные задачи. Отдельно можно разрешить конкретную внешнюю обработку по её хеш-сумме: файл изменили, хеш не совпал, запуск не состоялся. Начиная с версии 8.3.28 профиль можно назначить не отдельной базе, а сразу всему кластеру.
Оговорка, без которой совет будет вредным: типовые конфигурации активно пользуются и внешними обработками, и обменом по сети, и обращением к внешним сервисам. Если включить профиль на боевой базе в пятницу вечером, в понедельник встанут печатные формы, обмен и отправка отчётности. Включать нужно на копии, вместе с 1С-ником, и составлять список разрешений по факту - что реально понадобилось.
База регистрируется в кластере вместе с параметрами подключения к СУБД. Эти параметры хранятся в кластере, и кто получил доступ к консоли администрирования, тот их и увидит.
Отсюда первое правило: в строке подключения не должно быть суперпользователя. На MS SQL это sa, на PostgreSQL - postgres. Под суперпользователем база подключается «чтобы наверняка», а по факту вы отдаёте вместе с ней все остальные базы на этом экземпляре.
MS SQL. Заводится отдельный логин под 1С, права - только на свои базы. У sa должен стоять длинный пароль, а лучше эта учётная запись отключается совсем. Где инфраструктура позволяет, аутентификация переводится на доменную: тогда доступ к СУБД управляется там же, где остальные права, и его видно в общем аудите.
PostgreSQL. Для российских внедрений это уже основной вариант, и логика та же. Постоянно работать под postgres не нужно - под 1С заводится отдельная роль, которой хватает прав на свои базы. Отдельно проверьте pg_hba.conf: подключения к СУБД должны приниматься с адреса сервера 1С, а не откуда угодно, и метод аутентификации должен быть scram-sha-256. Строка с trust в этом файле означает, что пароль не спрашивают вообще - её там быть не должно.
Полезная привычка: включить журнал подключений к СУБД и раз в месяц смотреть, кто и откуда ходит. Одно это ловит и забытые тестовые подключения, и те, которых там быть не должно.
Недооценённый пункт, на котором спотыкаются чаще всего. В кластере 1С есть два списка администраторов - администраторы центрального сервера и администраторы кластера. Оба после установки пустые.
Пока список пуст, консоль администрирования подключается без пароля. То есть любой, кто дотянулся до порта агента сервера, становится администратором кластера со всеми вытекающими:
Лечится это за две минуты: в консоли управления создаются администратор кластера и администратор центрального сервера, каждому - свой пароль. Пароли не должны совпадать с доменными и тем более с паролем sa.
Второй половиной вопроса занимается сеть: порты кластера не должны быть открыты всему офису и тем более наружу. Что именно открывать и кому - разобрано отдельно, в статье про настройку firewall для сервера 1С.
Администратор кластера и администратор информационной базы - разные вещи. Полные права внутри базы не дают доступа к кластеру, а администратор кластера не становится автоматически администратором базы. Заводить нужно и то и другое, и это разные учётные записи.
Про забытый пароль администратора кластера спрашивают часто. Восстанавливается он на самом сервере, через служебный каталог кластера при остановленной службе. Отсюда следствие, которое важнее самой процедуры: доступ к файловой системе сервера 1С равен доступу к кластеру. Кто может зайти на машину и остановить службу, тот перенастроит что угодно. Разграничение прав на сам сервер - часть той же задачи.
Тут всё упирается в один вопрос: кому доступен Конфигуратор. Пользователь с административными полномочиями выгружает базу в файл .dt и уносит её целиком - вместе с зарплатами, контрагентами и всей историей. Никакого взлома для этого не требуется, штатная функция.
Список таких пользователей стоит пересмотреть вместе с 1С-ником и свести к тем, кому Конфигуратор реально нужен в работе. Полезно один раз составить таблицу: сотрудник, роли, что эти роли позволяют, до какого уровня права можно понизить без остановки процессов. Занимает полдня, а результат живёт годами.
Вторая половина - запуск внешних отчётов и обработок. На уровне ролей это закрывается в конфигурации, на уровне платформы - профилем безопасности, о котором выше. Работают эти два механизма независимо, так что закрывать лучше оба: роль ограничивает пользователя, профиль - саму базу, включая код, запущенный в обход интерфейса.
И отдельно про журнал регистрации. Он у всех включён и почти ни у кого не просматривается. Настройте выгрузку событий входа и изменения прав туда, где на них кто-то смотрит, - в общий сбор логов или хотя бы в почту ответственному.
Короткий проход по своему серверу.
| Что смотрим | Плохой ответ |
|---|---|
| Под какой учётной записью работает служба сервера 1С | доменный администратор или личная учётка сотрудника |
| Есть ли у этой учётки интерактивный вход и лишние права | вход разрешён, права выданы «на всякий случай» |
| Под кем базы подключены к СУБД | sa или postgres |
| Пароль суперпользователя СУБД | короткий, известный половине отдела, одинаковый с доменным |
pg_hba.conf (для PostgreSQL) | строка с trust или подключения с любого адреса |
| Список администраторов кластера и центрального сервера | пустой |
| Откуда доступны порты кластера | из всей офисной сети или из интернета |
| Назначены ли базам профили безопасности | ни одного профиля не создано |
| Кому доступен Конфигуратор | всем, кто когда-то просил |
| Кто смотрит журнал регистрации | никто |
Ни один из пунктов не требует ни денег, ни простоя - кроме профилей безопасности, которые стоит обкатать на копии. Зато вместе они закрывают тот самый зазор, из-за которого история про «дыру в 1С» обычно заканчивается разговором с директором.
Никакого. Список администраторов после установки пуст, и консоль администрирования подключается вообще без пароля. Учётную запись администратора кластера создаёт человек, а платформа за него этого не делает.
Ни то ни другое. sa - суперпользователь СУБД, USR1CV8 - учётная запись операционной системы, под которой работает служба сервера. Администратор кластера живёт внутри самого кластера 1С и заводится в консоли администрирования отдельно.
Значит, администратор в кластере заведён, а вы подключаетесь без его логина и пароля. Укажите их в свойствах подключения. Если пароль утерян, сбрасывать придётся на самом сервере, через служебный каталог кластера при остановленной службе.
Прямо - никак: учётная запись локальная и в домене её не существует. Заводится отдельная доменная учётная запись под службу сервера 1С, права на нужную папку выдаются ей, а служба перенастраивается на эту учётку. Брать для этого готовую учётку администратора не нужно.
Это про разное. Профиль ограничивает то, что код в базе может сделать на сервере: файлы, COM, внешние обработки, интернет. Запросы к СУБД он не фильтрует. Уязвимость возникает там, где текст запроса склеивают из строк с пользовательским вводом вместо того, чтобы передавать значение параметром. Это зона 1С-ника при код-ревью. Со стороны инфраструктуры остаётся второй рубеж - права учётной записи, под которой база подключена к СУБД: если у неё доступ только к своим базам, цена ошибки в коде резко падает.
По теме: как устроен кластер серверов 1С · резервное копирование 1С · какую ОС выбрать для сервера 1С
Собираете или переносите сервер под 1С?
Инженеры ITTELO подберут конфигурацию под число пользователей и режим работы, соберут и протестируют машину перед отгрузкой, с гарантией и поддержкой после продажи. На рынке серверов 11+ лет.
