Где и как держать пароли и токены в базе 1С, чтобы они не утекли

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

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

Чем опасно хранить пароли в открытом виде

Типичная картина в чужой базе: в константе «ПарольFTP» строка, в модуле обработки Пароль = "12345", в регистре сведений логины и пароли обмена с сайтом. Каждый вариант — отдельная дыра.

• 🔓 Константа или реквизит справочника. Значение видно в пользовательском режиме любому, у кого есть право чтения. Оно же уходит в выгрузку информационной базы.
• 📄 Текст в модуле. Пароль читается из конфигурации, из хранилища конфигурации и из резервной копии разработчика. После увольнения программиста он остаётся у него в рабочей копии.
• 🧾 Пароль в строке запуска или в параметрах подключения. Попадает в журнал, в диспетчер задач и в историю команд.
• 📤 Пароль в справочнике «Пользователи» внешнего обмена. Уходит вместе с обменом в узел-приёмник.

Дополнительный риск — копии базы. Файл 1Cv8.1CD часто лежит на сетевой папке, ночной .dt уходит на внешний диск. Открытый пароль утечёт вместе с копией, даже если права в самой базе настроены безупречно.

Правило простое: прикладной объект хранит ссылку на секрет, а сам секрет живёт в отдельном защищённом месте.

Безопасное хранилище данных: встроенный способ

В платформе 8.3 есть безопасное хранилище — отдельная область базы, куда записывают пары «владелец — ключ — значение». Значение не лежит в реквизитах объекта, а прочитать его можно только программно и только на сервере.

В типовых конфигурациях на библиотеке стандартных подсистем (БСП) для этого есть готовые процедуры общего модуля ОбщегоНазначения:

В качестве владельца обычно берут ссылку на элемент справочника — например, на настройку подключения. Ключ — строка вроде "Пароль" или "Токен". Так для одного владельца можно хранить несколько секретов.

Как это выглядит на форме

Поле пароля на форме не должно быть связано с реквизитом объекта. Делают так:

1. На форме создаётся реквизит типа Строка не из объекта, а «форменный».
2. У поля ввода включается режим пароля (свойство РежимПароля), чтобы символы отображались точками.
3. При записи объекта значение уходит в хранилище, а форменный реквизит очищается.
4. При открытии формы пароль не читается. Показывают заглушку «пароль задан» и кнопку «Изменить».

Так пароль не оказывается ни в данных формы, ни в клиентском контексте — по сети он уходит один раз, при вводе.

Пример записи и чтения

Запись при сохранении настроек подключения:

&НаСервере
Процедура СохранитьПарольНаСервере(Настройка, Пароль)
	УстановитьПривилегированныйРежим(Истина);
	ОбщегоНазначения.ЗаписатьДанныеВБезопасноеХранилище(Настройка, Пароль, "Пароль");
КонецПроцедуры

Чтение в момент обращения к внешнему сервису:

&НаСервере
Функция ПолучитьПароль(Настройка)
	УстановитьПривилегированныйРежим(Истина);
	Возврат ОбщегоНазначения.ПрочитатьДанныеИзБезопасногоХранилища(Настройка, "Пароль");
КонецФункции

Пароль читают в серверной функции, прямо перед отправкой запроса, и не возвращают на клиент. Функцию не помечают Экспорт без необходимости и не выносят в клиентский общий модуль.

Что хранилище не решает

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

Внешние менеджеры паролей и связка с 1С

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

Схема подходит для корпоративных хранилищ секретов (серверные менеджеры паролей, сервисы управления секретами). Общий порядок:

1. Секрет создаётся в менеджере паролей, для 1С заводится отдельная учётная запись с правом только на чтение нужных записей.
2. В базе хранится адрес сервиса и идентификатор записи — они не секретны.
3. Серверный код 1С обращается к сервису по HTTPS (объект HTTPСоединение), получает значение и использует его в памяти, не записывая в базу.
4. Для самого обращения к менеджеру нужен токен. Его, в свою очередь, держат в безопасном хранилище или в защищённой среде процесса.

Обратите внимание на последний пункт: цепочка всё равно упирается в один «первый секрет». Задача внешнего менеджера — не убрать его совсем, а сократить число мест, где секреты живут, и дать единую точку смены и аудита.

Переменные среды и реестр: когда это оправдано

Переменные среды на сервере 1С — компромисс для серверных обработок и регламентных заданий. Секрет задаётся в окружении службы агента сервера, а код читает его при выполнении.

Что важно знать:

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

Хранение паролей в реестре Windows (ветки HKCU/HKLM) оправдано ещё реже. Права на ветки приходится настраивать вручную, а резервная копия базы реестр не захватывает, поэтому при переносе на другой сервер вы легко потеряете подключение и будете искать, где оно было задано. Если выбираете между реестром и безопасным хранилищем, берите хранилище.

Практика: перенос паролей из открытых мест

Если паролей в базе уже накопилось, переводить их надо поэтапно, а не одним скриптом на боевой базе. Перед массовой правкой сделайте копию базы и проверьте шаги на тестовой.

1. Найдите, где лежат пароли. Поиск по конфигурации в конфигураторе по словам Пароль, Password, Token, Secret. Отдельно посмотрите константы, регистры сведений обмена и настройки учётных записей.
2. Сгруппируйте по владельцам. Для каждого подключения определите объект, к которому секрет относится: настройка обмена, учётная запись, интеграция.
3. Добавьте запись и чтение через безопасное хранилище. Код чтения оберните в одну функцию, чтобы потом можно было заменить источник.
4. Перенесите значения. Разовая обработка читает старый реквизит, записывает значение в хранилище и очищает исходное поле.
5. Удалите старый реквизит из объекта. Пока он остаётся в метаданных, пароль может вернуться через загрузку данных или выгрузку.
6. Смените пароли. Всё, что хоть раз лежало открытым, считайте скомпрометированным и перевыпустите у источника.

Шаг 6 пропускают чаще всего, а он самый важный. Перенести пароль в хранилище и оставить прежний — значит закрыть дверь, ключ от которой давно у посторонних.

Права доступа и отдельные учётные записи

Хранилище защищает значение от просмотра, но если пользователь может выполнить действие, которое использует пароль, он получит доступ к сервису косвенно. Поэтому настройте права так:

• Обработку, запускающую обмен с внешним сервисом, давайте отдельной роли, а не группе «Полные права».
• Вызовы, читающие секрет, выполняйте от имени отдельной служебной учётной записи в регламентных заданиях.
• Для внешнего сервиса заведите отдельного пользователя с минимальными правами: только нужные методы API, только нужные склады или организации. Если учётка с общими правами и утечёт, ущерб будет ограничен.
• Не используйте один и тот же пароль в разных системах. Утечка из одной не должна открывать остальные.

Для самих пользователей 1С действует отдельное правило: не передавайте пароль входа в программу в сообщениях и не записывайте его на стикеры. В свойствах пользователя в конфигураторе и в Администрирование → Настройки пользователей и прав можно включить требования к сложности и срок действия пароля. Точные названия пунктов зависят от конфигурации, поэтому ищите их в разделе настроек пользователей и прав.

Аудит: как понять, что секрет читали

Контролировать нужно две вещи: кто менял настройки подключений и откуда шли обращения к внешним сервисам.

В журнале регистрации (Администрирование → Журнал регистрации в типовых конфигурациях) отбор по пользователю, событию и дате покажет, кто открывал и записывал настройки. Чтобы изменения секретов были видны, пишите свои события через ЗаписьЖурналаРегистрации: «Пароль подключения изменён», «Токен перевыпущен». В текст события пароль, разумеется, не включайте — только имя настройки и пользователя.

Что стоит проверять регулярно:

• ✅ Кто за последний квартал менял настройки подключений и интеграций.
• ✅ Остались ли в метаданных реквизиты с открытыми паролями.
• ✅ Не уходят ли пароли в журнал, в сообщения об ошибках, в строки исключений.
• ✅ Не лежат ли в выгрузках и копиях базы файлы с настройками подключений.

Отдельно проверьте тексты ошибок. Распространённая ошибка — вывести в журнал строку подключения целиком, вместе с паролем. Формируйте сообщение так, чтобы в нём были адрес и логин, но не пароль.

Частые ошибки

• Пароль в параметрах сеанса или в клиентском общем модуле. Значение оказывается на клиенте. Всё, что связано с секретом, делайте в серверном контексте.
• Хранение в Хранилище значения реквизита. Это не шифрование: значение сериализуется и читается обычным кодом, доступ к нему определяют права на объект.
• Самодельное «шифрование» с ключом в том же модуле. Ключ рядом с данными защиты не даёт. Используйте встроенное хранилище.
• Один технический пароль на все интеграции. При утечке придётся перевыпускать всё и останавливать обмены.
• Пароль остался в старой копии базы. После переноса секретов в хранилище старые копии продолжают его содержать. Удалите их или смените пароли.

Частые вопросы