Недавно появилась задача, необходимо шифровать некоторые поля в объектах бд, таким образом чтобы пароль для расшифровки не вводился с клавиатуры а выбирался с аппаратного ключа, например с рутокена S, лайт или другого. Для каждого объекта должен быть свой зашифрованный контейнер, ключ для расшифровки может быть один. На рутокенах можно хранить таблицы с ключами, для доступа к таблице нужно ввести пин-код пользователя.
Может кто сталкивался с аналогичной задачей, есть какие-то решения для этого. Запароленные архивы и другие варианты с вводом ключа с клавиатуры не интересуют.

ты в чат гпт писал и промахнулся?

(1) Нейронки уже все сделали, мне интересно что сообщество может предложить :)

(2) вот и поделился бы решением, если оно рабочее

(0) А где будет аппаратный ключ стоять?

это юсб ключ он может быть передан по сети, главное чтобы висел на ком порту клиентской тачки где запущен сеанс 1с.

(5) Вас не смущает, что в отчеты вы зашифрованные поля не вытащите просто так? Точнее вытащите в зашифрованном виде. Знать бы цели задачи. Явно же шифрование не является целью.

(3) Решение рабочее но выглядит ненадежно, ии собрал мне приложение обертку для вызова из командной строки, с интерфейсом управления для вызова из 1С. Это приложение создает заполняет и читает базы данных keepass зашифрованные аппаратным рутокеном, базы хранятся в РСВ в связке со своими объектами. юзер один раз вводит пин-код ключа, дальше 1с читает, заполняет шифрует и расшифровывает данные объектов. В СКД даже работает.
Поделиться готовым решением не могу, заказчик возражает.

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

(6) Там шифруются какие-то финансовые данные, строки, это не ресурсы регистров а в крайнем случае какие-то реквизиты объектов, в скд кстати довольно шустро все расшифровывается при выводе.

(7) [ии собрал мне приложение]
задай ИИ промт-описать решение языком понятным мисте на уровне исключающем раскрытие коммерческой тайны

[Архитектура] Безопасное хранение конфиденциальных данных в 1С: интеграция с KeePass и аппаратными токенами RuToken (PKCS#11)
Проблема:
Стандартные механизмы шифрования 1С (ХранилищеЗначения) не всегда удовлетворяют строгим политикам ИБ. Возникает потребность хранить отдельные реквизиты справочников и документов (пароли, ключи, персональные данные) в криптографически стойких контейнерах сторонних менеджеров паролей (KeePass), при этом доступ к базам должен аппаратно ограничиваться токенами RuToken.

Требовалось сделать механизм «прозрачным» для разработчика конфигурации: чтобы вынос данных за периметр 1С не требовал написания уникального кода для каждой формы.

Стек технологий:

Платформа: 1С:Предприятие 8.3.27
Менеджер паролей: KeePass 2.x (формат KDBX 4)
Аппаратный ключ: RuToken (интерфейс PKCS#11)
Middleware (Прокси): C# (.NET Framework 4.8)
Библиотеки C#: KeePassLib (официальный NuGet), Pkcs11Interop (v4.x), System.Text.Json
Архитектура решения
Прямое использование COM-объектов или встроенных средств 1С для работы с PKCS#11 и форматом KDBX невозможно или крайне нестабильно (проблемы с разрядностью, утечки памяти).

Было принято решение реализовать изолированный C# CLI-прокси, который запускается как дочерний процесс и общается с 1С через стандартные потоки ввода/вывода (StdIn / StdOut), обмениваясь JSON-сообщениями.

Почему не HTTP API (микросервис)?
Даже на localhost HTTP-трафик может быть перехвачен локальными снифферами. StdIn/StdOut (pipes) работает в рамках памяти процесса-родителя, что исключает сетевой перехват конфиденциальных данных при передаче.

Жизненный цикл сессии (Stateful Proxy):

1С запускает прокси через WScript.Shell.Exec().
Отправляет команду init_token с ПИН-кодом от Рутокен.
Прокси открывает сессию с токеном (держит её в памяти) и ждет команд.
1С отправляет команды на создание/чтение/запись баз.
При закрытии формы 1С отправляет команду exit, прокси очищает память и завершает процесс.
Ключевые технические узлы и интересные находки
1. Изоляция мастер-пароля
Критически важное требование ИБ: мастер-пароль от базы KDBX никогда не должен попадать в память процесса 1С.
В прокси реализована логика: 1С передает только метку ключа на токене (например, "wish"). C#-прокси сам обращается к PKCS#11, считывает значение объекта CKO_DATA по метке, формирует CompositeKey и открывает базу. В 1С возвращаются только сами данные записей.

2. Хранение файлов баз (KDBX) внутри 1С
Базы KeePass не должны валяться на диске сервера в виде файлов. Файл .kdbx хранится в регистре сведений 1С в реквизите типа ХранилищеЗначения.
Алгоритм работы:

1С выгружает базу из ХранилищеЗначения во временный файл на диске.
Передает путь к файлу в C# прокси.
Прокси модифицирует базу и сохраняет её на диск.
1С считывает измененный файл и кладет обратно в ХранилищеЗначения.
Таким образом, база существует на диске сервера лишь доли секунды во время транзакции.
3. Метаданные и универсальный драйвер форм (1С)
Чтобы не писать код для каждой формы, реализован паттерн поиска по метаданным.
Разработчик конфигурации добавляет реквизиту или табличной части префикс хд_ (например, хд_СекретныйКлюч, хд_ИсторияДоступа).
Универсальная общая команда на сервере:

Рефлексивно обходит метаданные переданного объекта.
Извлекает все свойства с префиксом хд_.
Сериализует их (скалярные типы — в строку, табличные части и ссылки — через ЗначениеВСтрокуВнутр()).
Формирует массив JSON и отправляет прокси одной транзакцией.
4. Подводные камни Pkcs11Interop и KeePassLib
В процессе разработки столкнулись с несколькими неочевидными проблемами:

Смена API Pkcs11Interop: Библиотека версии 5.x перешла на фабрики (Factories), что ломает обратную совместимость. Для простоты CLI-утилит было решено зафиксировать версию на 4.1.2, где API проще (new Pkcs11(), new Session()). Кроме того, поиск объектов на токене в 4.x строго требует трех шагов: FindObjectsInit -> FindObjects -> FindObjectsFinal. Пропуск Final блокирует сессию токена.
Нативная криптография KeePass (Argon2): Начиная с KeePass 2.54, по умолчанию используется алгоритм хеширования Argon2, требующий нативных (C/C++) библиотек KeePassLibN.x64.dll. Чистый управляемый KeePassLib из NuGet не сможет открыть новые базы без этих DLL. Решение: собирать прокси под .NET Framework (для 100% совместимости с KeePassLib), компилировать под x64 и класть нативные DLL от самого KeePass рядом с exe-файлом прокси.
Разрядность драйверов Рутокен: Драйверы Рутокен ставятся раздельно для x86 и x64. Папка Program Files (x86) и SysWOW64 содержит 32-битные DLL (rtPKCS11ECP.dll). 64-битная версия лежит в System32 и Program Files. Чтобы не зависеть от установленных драйверов на сервере, мы применяем Local Deployment: нужная разрядность rtPKCS11ECP.dll просто лежит в папке с приложением прокси. Функция LoadLibrary Windows сначала ищет DLL в каталоге запуска EXE.
5. Случайное распределение ключей
При создании новой защищенной базы для объекта, система рандомно выбирает один из 24 предзагруженных ключей на токене (передается массив меток). Это позволяет распределить нагрузку и соблюсти принцип "не хранить все яйца в одной корзине" на уровне аппаратного ключа.

Итог
Получился надежный механизм, удовлетворяющий параноидальным требованиям ИБ:

Данные не хранятся в 1С в открытом виде.
Мастер-пароли не пересекают границы доверенной зоны (C#).
Доступ невозможен без физического токена.
Для внедрения в новые объекты 1С разработчику достаточно добавить префикс к реквизиту — код форм не меняется.

(0)[Прокси модифицирует базу и сохраняет её на диск.
1С считывает измененный файл и кладет обратно в ХранилищеЗначения.
Таким образом, база существует на диске сервера лишь доли секунды во время транзакции.]
где процедура гарантированного затирания данных в удаленном файле ?

(12) Зачем, там ключи 512бит, эти базы вообще можно не стирать с диска.

(13) т.е. это не расшифрованная база, из которой потом СКД тащит данные ?

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

"Решение рабочее но выглядит ненадежно"
"Получилось довольно безопасно"

(16) есть вероятность что процесс 1с завершится, а запись в базу и ее сохранение нет, поэтому ненадежно.

Лисапед, причем дикий и бесполезный
Безопасности по сути нет ибо только ключ хранится аппаратно, не само шифрование
Но тормоза есть

Применять такое разумно только когда есть прямой доступ к базе левыми людьми (например база в облаке, а шифрование/дешифрование идет локально на клиенте)
Но нафига давать такой доступ?

Просто храните базу в защищенном месте без доступа левых напрямую
И доступ разруливайте на уровне прав, не связывайтесь с шифрованием

(18) [Но нафига давать такой доступ?]
это твой, т.е. 1С-ника доступ с полными правами + админов права на сиквеле/его бэкапы

слышал в налоговой использовалась какая то штука под названием ДИОНИС. единственная сетифицированная фсб и ФАПСИ и по рассказам товарища который с ней работал в ней было что-то подобное. но жутко тормозная опять же с чужих слов.

(18) Алгоритмы шифрования давно всем известны keepass работает с популярными алгоритмами, база биткоина и других криптовалют публично лежит в открытом доступе и никто ее не пытается стереть или спрятать алгоритмы шифрования тоже всем известны, пожалуйста открывайте и забирайте "если есть ключ". При этом биткоин использует 256бит ключи. В наше время многие держат базы 1С на облачных серверах, а кто ее там может скопировать вообще неизвестно, а в 1С ничего не зашифровано все в открытом доступе.

Если аппаратный ключ накроется, то теряем колонки в базе?

(22) Кто ж его не экспортируемым будет делать? Можно конечно и проверку на срок действия сертификата спросить...

Тут другой вопрос, если ключ доступен, то и все данные доступны всем на основании прав 1С?

"StdIn/StdOut (pipes) работает в рамках памяти процесса-родителя, что исключает сетевой перехват конфиденциальных данных при передаче. "

Счастье - в неведении.

Простейший createremotethread() и сплайсинг winapi функций работы с pipes будут читать ваши трубы, не привлекая внимание.

(25) Примерно про это и пытался намекнуть
И можно сам ключик перехватить, и далее не привлекая внимание фигачить что угодно

А еще точно зная данные внутри - расшифровать нет особых проблем
Хоть какой ключ/шифрование ставь, если есть образцы (причем куча будет любая таблица на выбор) незашифрованных строк и зашифрованных - это легко
Все способы шифрования держатся на неведении незашифрованных данных