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

Самое простое решение — создать справочник учётных записей с реквизитами «Логин» и «Пароль», включить для поля «Пароль» режим пароля (маскировку ввода). Однако этого недостаточно.

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

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

Оценка риска зависит от типа базы. Для файловых баз угроза выше: файл с данными может скопировать кто угодно из числа пользователей. В клиент-серверной архитектуре база данных, как правило, доступна только администраторам СУБД. Однако сам факт, что пароль хранится в реквизите, делает его уязвимым в обеих схемах.

Дополнительный фактор — планы обмена. Если справочник с паролем участвует в обмене данными между узлами распределённой базы, пароль уйдёт во все узлы-приёмники без какого-либо шифрования внутри обмена.

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

Стандарт 1С (std740) требует не размещать конфиденциальные данные, включая пароли, в объектах информационной базы. Если такое хранение необходимо, пароль следует помещать в отдельный объект метаданных с ограниченными правами доступа.

Архитектура «Безопасного хранилища» БСП

Библиотека стандартных подсистем (БСП) включает готовую подсистему — Безопасное хранилище данных. В её основе лежит регистр сведений БезопасноеХранилищеДанных, спроектированный так, что:

• Пользователь не может напрямую прочитать его содержимое — данные можно получить только программно с использованием привилегированного режима.
• Регистр исключён из планов обмена — конфиденциальная информация не уходит в другие узлы.
• Хранимые значения защищены на уровне СУБД, платформа отвечает за их шифрование.

Программный интерфейс

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

Для массовых операций предусмотрена ПрочитатьДанныеВладельцевИзБезопасногоХранилища(Владельцы, Ключи) — она за один вызов возвращает Соответствие, где каждому владельцу сопоставлены его данные.

Параметр «Владелец». В качестве владельца можно передать ссылку на элемент справочника или плана обмена, либо строку (до 128 символов).

Параметр «Данные». Тип произвольный. Если передать Неопределено, все записи выбранного владельца будут стёрты — для точечного удаления по ключу предусмотрена УдалитьДанныеИзБезопасногоХранилища. Когда данные имеют тип Структура, параметр Ключ обязан быть Неопределено, а имена полей структуры становятся ключами сохраняемых значений.

Параметр «Ключ». По умолчанию равен «Пароль». Ключ подчиняется правилам 1С-идентификаторов: начинается с буквы или подчёркивания, остальные символы — буквы, цифры, подчёркивание.

Доступность всех трёх функций: Сервер, Толстый клиент, Внешнее соединение. Вызвать их с тонкого или веб-клиента не получится.

Привилегированный режим (УстановитьПривилегированныйРежим(Истина)) обязан включать тот код, который непосредственно вызывает чтение или запись, процедуры общего модуля ОбщегоНазначения привелигированный режим не устанавливают. Отключать режим нужно сразу после обращения.

Пример использования

Рассмотрим реальный кейс использования безопасного хранения данных: две базы 1С обмениваются данными через COM-соединение с использованием типовой обработки «Универсальный обмен данными в формате XML». Для обмена через COM-соединение нужны данные базы приемника: сервер, имя базы, пользователь, пароль.

Первоначально была создана обработка для записи необходимых данных в безопасное хранилище. Запись выполнялась с формы обработки с использованием процедуры ЗаписатьДанныеВБезопасноеХранилище.

Запись данных в безопасное хранилище

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

Когда настройки сохранены, регламентное задание или фоновая обработка использует их для COM-соединения. Пароль читается непосредственно перед подключением, а после — немедленно затирается.

Чтение данных из безопасного хранилища

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

P.S.: V83.ComConnector работает только на Windows. Под Linux он недоступен.

При удалении объекта-владельца нужно очистить связанные с ним данные из хранилища:

Удаление данных из безопасного хранилища

Если требуется записать несколько полей за раз (например, логин и пароль, как в нашем примере), передаём структуру с Ключ = Неопределено:

Запись структуры данных в безопасное хранилище

В таком варианте имена ключей берутся из структуры, а явный Ключ не указывается.

Когда безопасное хранилище необходимо

«Безопасное хранилище» БСП оправдано в сценариях, где пароль должен храниться в информационной базе и использоваться автоматически:

Во всех этих случаях пароль нельзя запрашивать у пользователя каждый раз — серверный код должен работать самостоятельно. «Безопасное хранилище» даёт единственный штатный способ хранить такие пароли без риска перехвата.

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

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

Типовые случаи, когда можно обойтись без хранения:

Чего не даёт режим пароля на форме

Распространённое заблуждение — включить для реквизита справочника режим пароля (маскировку *) и считать данные защищёнными. Это не так:

Режим пароля — это элемент интерфейса, а не защиты. Реквизит Пароль должен существовать только на форме, а реальное значение — лежать в БезопасноеХранилищеДанных.

Отдельная проблема — хранение пароля прямо в коде модуля (например, Пароль = «admin123»; или строка подключения с Pwd). Пароль в коде не меняется без перекомпиляции, виден всем, у кого есть доступ к конфигурации, и не может быть изолирован правами доступа.

Выводы

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

• создать отдельный регистр сведений (независимый, периодичность — не требуется);
• исключить его из планов обмена;
• настроить права: чтение и запись — только через привилегированный режим;
• написать свои обёртки ЗаписатьДанныеВБезопасноеХранилище / ПрочитатьДанныеИзБезопасногоХранилища с включением привилегированного режима.

Это даст изоляцию доступа, но без встроенного шифрования на уровне СУБД, которое обеспечивает БСП.