Как хранить пароль в 1С: практическое руководство

Пароли в 1С встречаются в двух разных контекстах, и путать их нельзя. Первый — пароли пользователей информационной базы, которые платформа хранит сама и не даёт прочитать даже администратору. Второй — пароли к внешним сервисам (почта, обмены, FTP, веб-сервисы), которые разработчику или администратору приходится сохранять в самой конфигурации. Подход к хранению в этих случаях принципиально разный.

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

Как 1С хранит пароли пользователей информационной базы

При создании пользователя в конфигураторе (Администрирование → Пользователи) или в режиме предприятия пароль не записывается в базу в открытом виде. Платформа вычисляет от пароля криптографический хеш и сохраняет именно его. При входе пользователя хеш введённого пароля сравнивается с сохранённым — сам пароль при этом нигде не фигурирует.

Следствие из этого важно понимать: восстановить забытый пароль пользователя 1С невозможно, его можно только сбросить и задать новый. Это делает администратор с полными правами через список пользователей — открывает карточку пользователя и устанавливает новый пароль. Если утрачен пароль единственного администратора файловой базы, штатных средств восстановления нет, и это отдельная сложная ситуация.

Хранение через хеш означает также, что никакая обработка и никакой запрос к базе данных не покажут вам пароли пользователей — в таблицах лежат только необратимые значения. Если кто-то предлагает обработку «показать все пароли 1С», это либо обман, либо инструмент, работающий с уже скомпрометированной базой.

Настройка политики паролей пользователей

Чтобы пароли пользователей не были слабыми, в типовых конфигурациях на базе Библиотеки стандартных подсистем (БСП) есть настройки сложности паролей. Они находятся в разделе администрирования, в настройках пользователей и прав. Там можно задать требования к минимальной длине пароля, сложности и другие ограничения.

Дополнительно платформа позволяет для каждого пользователя включить признак «Показывать в списке выбора», запретить смену пароля пользователем или, наоборот, потребовать смену пароля при первом входе. Для учётных записей, под которыми работают внешние соединения и фоновые задания, рекомендуется отключать интерактивный вход, если он не нужен.

1. 1
   Откройте раздел Администрирование → Настройки прав и пользователей
2. 2
   Найдите блок настроек паролей (состав зависит от конфигурации)
3. 3
   Установите минимальную длину пароля и требования к сложности
4. 4
   Включите требование смены пароля при первом входе для новых учётных записей
5. 5
   Проверьте на тестовом пользователе, что слабый пароль отклоняется

Практическая рекомендация: пароли для служебных учётных записей (обмены, регламентные задания, публикация на веб-сервере) делайте длинными и случайными, храните их в корпоративном менеджере паролей, а не в личных заметках сотрудника. Увольнение сотрудника, единолично знавшего пароль, — классическая причина аварий.

Как безопасно хранить пароли к внешним сервисам

Здесь начинается зона ответственности разработчика и администратора. Пароли к почтовым ящикам, FTP-серверам, веб-сервисам, API обменов и другим внешним системам конфигурации приходится хранить самостоятельно, потому что эти пароли нужны в открытом виде в момент подключения.

В конфигурациях на базе БСП есть штатный механизм — безопасное хранилище данных. Он предназначен именно для секретов: паролей, токенов, ключей API. Данные записываются программно и хранятся в специальном регистре в защищённом виде, недоступном для обычного просмотра через формы и отчёты.

// Запись пароля в безопасное хранилище (БСП)
ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(НастройкаОбмена, "ПарольОтСервиса", "Пароль");

// Чтение пароля при подключении
Пароль = ОбщегоНазначения.ПрочитатьДанныеИзБезопасногоХранилища(НастройкаОбмена, "Пароль");

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

Куда пароли сохранять нельзя

Перечислим места, где пароль хранить недопустимо, даже если «так удобнее». Константа строкового типа — её значение видит любой пользователь с правами просмотра и попадает во все выгрузки. Регистр сведений с открытым строковым полем — то же самое, плюс значение легко вытащить универсальным отчётом. Код модуля — пароль в коде виден всем разработчикам с доступом к конфигуратору и навсегда оседает в хранилище конфигурации и в копиях баз у подрядчиков.

Отдельный риск — пароли в настройках внешних обработок, макетах, файлах настроек обмена и в комментариях. Пароль, однажды попавший в выгруженный dt-файл или в письмо с обработкой, считается скомпрометированным: его нужно менять, а не надеяться, что файл никто не откроет.

Что делать, если БСП нет или нужен более высокий уровень защиты

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

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

Как проверить, что пароли хранятся правильно

Проверка начинается с аудита текущего состояния. Откройте константы и регистры сведений конфигурации и найдите поля с названиями вроде «Пароль», «Password», «Токен», «Ключ». Если значения в них читаются открытым текстом — это нарушение, которое нужно устранять. Затем выполните поиск по модулям конфигурации: пароли и токены в коде часто остаются после отладки.

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

Частые вопросы о хранении паролей в 1С