В процессе сопровождения и разработки систем на платформе 1С:Предприятие часто возникает задача защиты коммерческой тайны. Особую сложность представляет сокрытие конфиденциальных финансовых показателей (например, сумм проводок, окладов в зарплатных документах или цен номенклатуры) от сотрудников с повышенными привилегиями — системных администраторов, разработчиков или аутсорсеров. Стандартный механизм ограничения доступа на уровне записей (RLS) здесь не помогает, поскольку администратор СУБД или разработчик с полными правами в коде может обойти любые экранные ограничения.
В этой статье мы подробно разберем технические сложности, возникающие при попытке зашифровать числовые показатели в СУБД, проанализируем реальные варианты решения этой задачи и рассмотрим готовый алгоритм транзакционного декодирования данных «на лету».
При попытке зашифровать числовое поле (например, сумму документа или проводки) мы неизбежно сталкиваемся со следующими архитектурными ограничениями:
Число(15,2). Приходится либо менять тип поля на строку/хранилище значения, либо добавлять дублирующие реквизиты.Ниже мы проанализируем три основных подхода к решению этой проблемы: транзакционный метод, шифрование на уровне СУБД и организационное разделение сред разработки.
Рассмотрим оригинальное техническое решение, которое позволяет обойти ограничение СУБД на расчет итогов при использовании шифрования. Суть метода заключается в том, что в базе данных суммы физически хранятся в зашифрованном строковом виде, а оригинальные числовые поля обнуляются (или заполняются единичным значением для исключения пустых ссылок и сохранения работы базовых алгоритмов платформы).
Для вывода отчета (например, оборотно-сальдовой ведомости) система временно расшифровывает данные внутри транзакции, строит отчет стандартным запросом СУБД, а затем откатывает транзакцию назад, не записывая расшифрованные данные на диск физически.
Разберем по шагам реализацию этого алгоритма:
Шаг 1. Модернизация структуры метаданных.
В документы и регистры бухгалтерии (или регистры накопления) добавляются строковые реквизиты (например, СуммаЗашифровано с типом Строка), куда записывается результат шифрования. Штатные числовые поля Сумма при проведении документов очищаются или заполняются фиктивными значениями.
Шаг 2. Использование компоненты шифрования.
Для криптографических операций можно использовать встроенный в платформу менеджер криптографии или внешние компоненты. Рассмотрим пример схемы работы механизма отчетов с транзакционным декодированием:
// Процедура инициализации отчета с временным декодированием
Процедура СформироватьОтчетНаСервере()
// Проверяем наличие прав и ключа шифрования у текущего пользователя
Если Не КлючШифрованияДоступен() Тогда
ВызватьИсключение "Доступ к конфиденциальным данным запрещен. Ключ не найден.";
КонецЕсли;
// Открываем транзакцию, чтобы изменения не зафиксировались на диске
НачатьТранзакцию();
Попытка
// Шаг 1: Временно расшифровываем нужный период в регистре
РасшифроватьДанныеРегистраЗаПериод(НачалоПериода, КонецПериода);
// Шаг 2: Выполняем стандартный запрос СКД / построение отчета
ПостроитьОтчетПоРасшифрованнымДанным();
// Шаг 3: Принудительно отменяем транзакцию, возвращая базу в зашифрованное состояние
ОтменитьТранзакцию();
Исключение
// В случае любой ошибки гарантированно откатываем транзакцию
Если ТранзакцияАктивна() Тогда
ОтменитьТранзакцию();
КонецЕсли;
ЗаписатьЛогОшибки(ОписаниеОшибки());
ВызватьИсключение "Ошибка построения отчета. Данные защищены.";
КонецПопытки;
КонецПроцедуры
Шаг 3. Алгоритм временной расшифровки данных.
Внутри транзакции мы программно считываем зашифрованные строки, дешифруем их с помощью секретного ключа (который может передаваться пользователем при входе с USB-токена или вводиться вручную) и записываем обратно в числовые поля документов и регистров:
Процедура РасшифроватьДанныеРегистраЗаПериод(ДатаНачала, ДатаКонца)
// Выбираем записи регистра за период, требующие расшифровки
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Хозрасчетный.Регистратор КАК Регистратор,
| Хозрасчетный.НомерСтроки КАК НомерСтроки,
| Хозрасчетный.СуммаЗашифровано КАК СуммаЗашифровано
|ИЗ
| РегистрБухгалтерии.Хозрасчетный КАК Хозрасчетный
|ГДЕ
| Хозрасчетный.Период МЕЖДУ &ДатаНачала И &ДатаКонца";
Запрос.УстановитьПараметр("ДатаНачала", ДатаНачала);
Запрос.УстановитьПараметр("ДатаКонца", ДатаКонца);
Выборка = Запрос.Выполнить().Выбрать();
Пока Выборка.Следующий() Цикл
// Расшифровываем строку обратно в число
ЧисловаяСумма = ДешифроватьСтроку(Выборка.СуммаЗашифровано);
// Записываем расшифрованное значение в числовое поле внутри транзакции
НаборЗаписей = РегистрыБухгалтерии.Хозрасчетный.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Регистратор.Установить(Выборка.Регистратор);
НаборЗаписей.Прочитать();
Для Каждого Запись Из НаборЗаписей Цикл
Если Запись.НомерСтроки = Выборка.НомерСтроки Тогда
Запись.Сумма = ЧисловаяСумма;
КонецЕсли;
КонецЦикла;
// Запись происходит только в оперативную память транзакции СУБД
НаборЗаписей.Записать();
КонецЦикла;
КонецПроцедуры
Важное предупреждение о безопасности этого метода: Как только транзакция временно расшифровывает данные в оперативной памяти СУБД, эти данные технически становятся доступны для чтения из других сессий SQL Server (уровни изоляции транзакций Read Uncommitted) или через анализ дампов оперативной памяти. Метод защищает информацию «на диске», но не гарантирует абсолютной защиты от высококвалифицированного взлома администратором сервера.
Проанализируем встроенные механизмы СУБД, такие как Transparent Data Encryption (TDE), доступные в MS SQL Server Enterprise Edition, а также в некоторых отечественных сборках СУБД (например, Postgres Pro Enterprise).
Технология TDE работает следующим образом:
Преимущества TDE:
Главный недостаток: TDE защищает данные только «в покое» (at rest). Поскольку сервер 1С:Предприятия подключается к СУБД под учетной записью с правами чтения, СУБД отдает серверу 1С уже расшифрованные данные. Администратор СУБД или разработчик с правами на сервере 1С все равно увидит открытые числовые значения сумм.
Если перед компанией стоит задача не допустить утечки реальных финансовых показателей к разработчикам, то самым надежным, дешевым и общепринятым в мировой практике решением является разделение контуров разработки и эксплуатации.
Вместо усложнения архитектуры рабочей базы тяжелыми алгоритмами криптографии, мы рекомендуем организовать работу по следующему регламенту:
Выбор конкретного метода зависит от требований регуляторов (например, соответствие ФЗ-152 о персональных данных требует применения сертифицированных средств шифрования на дисках) и реального бюджета проекта. Для большинства практических задач маскирование тестовых данных в сочетании с жестким разграничением прав доступа пользователей в рабочей базе является наиболее стабильным и безопасным решением.