Администрирование · 12 мин
Как настроить системную учетную запись в 1С
Как создать и настроить системную учетную запись в 1С: роли, пароли, разделение прав, работа с фоновыми заданиями и типичные ошибки администратора.
Системная (служебная) учетная запись в 1С — это пользователь, под которым работают не люди, а сама программа: фоновые задания, обмены данных, регламентные операции, внешние подключения через COM или веб-сервисы. От обычного пользователя такая запись отличается тем, что у неё нет сотрудника за компьютером, поэтому к ней предъявляются особые требования по паролю, правам и блокировкам.
Неправильно настроенная служебная учетная запись — одна из самых частых причин сбоев обменов и утечек доступа. Если выдать ей роль «Полные права», любой, кто узнает пароль, получит полный контроль над базой. Если, наоборот, прав не хватит, регламентные задания будут тихо падать с ошибками, а вы узнаете об этом через неделю, когда обнаружатся неактуальные данные.
Материал подходит для файловых и клиент-серверных баз 1С:Предприятие 8.3 — как для типовых конфигураций (Бухгалтерия, Управление торговлей, ЗУП, ERP), так и для самописных. Конкретные названия ролей зависят от конфигурации, но общая логика настройки одинакова.
Когда нужна отдельная системная учетная запись
Не каждой базе нужна служебная учетная запись. В небольшой файловой базе, где обмены запускаются вручную бухгалтером, отдельный системный пользователь избыточен. Но как только появляются автоматические процессы, работающие без участия человека, заводить отдельную запись становится обязательным.
Типичные сценарии, где нужна системная учетная запись: автоматический обмен с сайтом или другой базой 1С, синхронизация с банком и ЭДО, фоновая отправка отчетности, регламентные задания в клиент-серверном режиме, подключение внешних систем через веб-сервисы или OData. Во всех этих случаях процесс должен работать даже тогда, когда ни один сотрудник не вошел в программу.
Ключевой принцип — разделение ответственности. Учетная запись обмена с сайтом не должна иметь доступ к зарплате, а запись для регламентных заданий не должна использоваться для ручного входа. Это упрощает аудит: по журналу регистрации сразу видно, что действие выполнил робот, а не человек.
Создание пользователя в конфигураторе и в режиме предприятия
В типовых конфигурациях на БСП (Библиотека стандартных подсистем) пользователей создают в режиме «Предприятие»: раздел «Администрирование» → «Настройки пользователей и прав» → «Пользователи». Нажмите «Создать», укажите имя, например «RobotObmen» или «СлужебныйОбмен», и задайте пароль. Имя должно сразу говорить о назначении записи — это сильно упрощает разбор журнала регистрации через полгода.
Если конфигурация самописная или без БСП, пользователя создают в конфигураторе: меню «Администрирование» → «Пользователи» → «Добавить». На закладке «Основные» укажите имя, полное имя, пароль и подтверждение. Флажок «Аутентификация стандартная» должен быть включен, «Аутентификация операционной системы» для служебной записи обычно не нужна.
Обратите внимание на поле «Язык» и «Роль по умолчанию» в конфигураторе — их лучше оставить в значениях по умолчанию и управлять доступом только через явно назначенные роли. Галочка «Показывать в списке выбора» для системной записи обычно снимается, чтобы пользователь не маячил в окне входа и его не выбирали по ошибке.
- 1Откройте список пользователей в режиме «Предприятие» или конфигураторе
- 2Создайте пользователя с говорящим именем, например RobotObmen
- 3Задайте сложный пароль и сохраните его в защищенном хранилище
- 4Снимите флажок показа в списке выбора при входе
- 5Назначьте минимально необходимые роли
- 6Проверьте вход и запуск целевого задания
Назначение ролей: минимум необходимого
Главная ошибка при настройке — выдать системной записи полные права «чтобы наверняка работало». Это работает, но превращает запись в скрытого администратора. Правильный подход — метод исключения: создать запись без ролей, попробовать выполнить целевую операцию, посмотреть в журнале регистрации, каких прав не хватило, и добавить только их.
В типовых конфигурациях для обменов часто есть готовые профили: «Выполнение обменов данными», «Выполнение синхронизации данных» и подобные. Для регламентных заданий обычно достаточно роли, дающей право на запуск фоновых заданий, плюс роли на чтение и изменение тех объектов, которые задание обрабатывает. Например, для фоновой отправки отчетности нужны права на документы и регистры отчетности, но не на кассу и банк.
Если конфигурация поддерживает профили групп доступа, создайте отдельный профиль «Системные операции» и включите в него только нужные роли. Так проще контролировать состав прав: при обновлении конфигурации вы смотрите один профиль, а не разбросанные галочки у нескольких пользователей.
Настройка для фоновых и регламентных заданий
В клиент-серверном режиме регламентные задания выполняются на сервере 1С от имени пользователя, указанного в свойствах задания. Откройте консоль заданий (или «Регламентные и фоновые задания» в разделе «Администрирование»), найдите нужное задание и проверьте поле «Пользователь» — там должна стоять ваша системная запись, а не пустое значение и не конкретный сотрудник.
Если поле пользователя пустое, задание выполняется от имени служебного пользователя сеанса сервера, и права определяются иначе — это частый источник путаницы при диагностике ошибок «Нарушение прав доступа». Явное указание системной учетной записи делает поведение предсказуемым.
В файловом режиме регламентные задания выполняются из сеанса пользователя, запустившего обработчик ожидания. Здесь системная запись помогает иначе: можно настроить отдельный сеанс 1С на сервере или выделенной машине, который постоянно запущен под служебной записью и выполняет фоновые задачи. Это стандартная практика для файловых баз с автоматическими обменами.
Где выполнять задания
Задания выполняет сервер 1С от имени указанного пользователя. Надежно, не зависит от открытых сеансов, но требует явного указания пользователя в задании.
Отдельный постоянно запущенный сеанс под служебной записью выполняет фоновые задачи. Просто, но сеанс может завершиться — нужен контроль его работоспособности.
Запуск 1С по расписанию через планировщик Windows с параметрами входа. Гибко, но пароль хранится в командной строке — требуется защита файла задания.
Пароль и безопасность учетной записи
Пароль системной записи должен быть длинным и случайным — его не нужно запоминать и вводить ежедневно, поэтому удобство здесь не аргумент. Сгенерируйте пароль из 16 и более символов и сохраните в корпоративном менеджере паролей или в защищенной записи у администратора. Пароль в текстовом файле на общем диске — это то же самое, что отсутствие пароля.
Если пароль используется в строке подключения внешней системы или в параметрах запуска из планировщика, ограничьте доступ к этим файлам на уровне прав файловой системы. Проверьте, не попадает ли пароль в логи внешних приложений — веб-серверы и интеграционные шлюзы нередко пишут строки подключения в журнал.
Установите политику смены пароля, если она используется в компании, либо зафиксируйте дату последней смены пароля в документации. При увольнении администратора, который знал пароль, его нужно сменить — это часто забывают, потому что «запись же служебная».
Проверка работы и диагностика проблем
После настройки выполните контрольный запуск: войдите под системной записью вручную (если это не запрещено настройками) и выполните целевую операцию — запустите обмен или задание. Затем откройте журнал регистрации с отбором по этому пользователю и убедитесь, что операция завершилась без ошибок доступа.
Для регламентных заданий проверьте вкладку «Фоновые задания» в консоли: состояние должно быть «Выполнено», а не «Ошибка». Типичные признаки проблем — ошибки «Нарушение прав доступа» (не хватает роли), «Пользователь не найден» (запись удалена или переименована), «Неверный пароль» (пароль сменили, а в настройках обмена забыли обновить).
Настройте регулярный контроль: хотя бы раз в неделю просматривайте журнал регистрации по системным записям. Автоматические процессы не жалуются — о том, что обмен не работает две недели, обычно сообщает контрагент или расхождение остатков.
Как проверить результат
Вход выполняется, открывается только нужный интерфейс
Ошибка аутентификации или доступ ко всем разделам
Состояние «Выполнено», данные обновились
Состояние «Ошибка», в журнале нарушение прав доступа
Действия записаны от имени служебного пользователя
Действия выполняются от имени сотрудника или пустого пользователя
Синхронизация проходит по расписанию
Обмен работает только при ручном запуске администратором
Ограничения и частые сценарии
Запрет интерактивного входа
В типовых конфигурациях можно ограничить интерактивную работу служебной записи через настройки входа пользователей («Администрирование» → «Настройки пользователей и прав» → «Настройки входа пользователей»). Это снижает риск того, что кто-то будет работать под роботом вручную, «заметая следы» в журнале. Учтите: после такого запрета проверять настройки придется под администратором, а не под служебной записью.
Одна запись или несколько
Для разных направлений автоматизации лучше заводить отдельные записи: одна для обмена с сайтом, другая для регламентных заданий, третья для ЭДО. Это удорожает сопровождение (больше паролей), но резко упрощает аудит и позволяет точечно отзывать доступ. Компромиссный вариант для небольшой компании — одна запись на все внутренние задания и отдельные записи для всего, что торчит наружу (сайт, веб-сервисы).
Обновление конфигурации
После обновления типовой конфигурации состав ролей может измениться: появляются новые роли, старые разделяются. Если после обновления фоновые задания начали падать с ошибками прав, первым делом проверьте состав профиля системной записи — вероятно, нужные роли переименованы или разделены.
Заведите в учетных документах простую таблицу: имя служебной записи, назначение, где хранится пароль, какие задания и обмены её используют. Когда через год обмен перестанет работать, эта таблица сэкономит часы поиска.
Частые вопросы
Можно ли использовать учетную запись администратора для фоновых заданий?
Технически можно, но делать так не стоит. Задания будут работать, однако в журнале регистрации действия робота смешаются с действиями администратора, а пароль администратора придется прописывать в настройках обменов и внешних систем, что многократно увеличивает риск его компрометации.
Фоновое задание падает с ошибкой «Нарушение прав доступа». Что делать?
Откройте журнал регистрации, найдите событие ошибки и посмотрите, к какому объекту метаданных не хватило доступа. Затем добавьте системной записи роль, дающую нужное право именно на этот объект. Не выдавайте полные права — это устранит ошибку, но создаст дыру в безопасности.
Нужно ли менять пароль системной записи по расписанию?
Если пароль длинный, случайный и хранится в защищенном месте, частая смена не обязательна. Обязательно меняйте пароль при увольнении сотрудников, которые его знали, при подозрении на утечку и при переносе настроек на новый сервер.
Как запустить обмен в файловой базе, если никто не вошел в 1С?
Настройте запуск 1С через планировщик заданий Windows с параметрами командной строки: путь к базе, имя и пароль служебной записи, параметр запуска обработки или выполнения фоновых заданий. Файл задания планировщика защитите правами доступа, так как пароль в нем хранится открыто.
Пользователь удален, а задания на него ссылаются. Что будет?
Регламентные задания начнут завершаться с ошибкой. Перед удалением служебной записи проверьте консоль заданий и настройки всех обменов, переназначьте их на новую запись, и только потом удаляйте старую. Если записей много, удобнее не удалять, а блокировать запись снятием всех ролей и сменой пароля.
Отличается ли настройка в 1С:Фреше (облачной 1С)?
Да. В сервисе нет доступа к конфигуратору и кластеру серверов, пользователи создаются только в режиме «Предприятие», а часть регламентных заданий управляется самим сервисом. Служебные записи там нужны в основном для обменов и внешних подключений, и права им назначаются через профили групп доступа.
Что важно запомнить
Системная учетная запись — отдельный пользователь с говорящим именем, сложным паролем и минимально необходимыми ролями. Укажите её явно в регламентных заданиях, проверьте выполнение по журналу регистрации и зафиксируйте настройки в документации. Полные права служебной записи не выдавайте никогда.