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

В 7й платформе 1С добраться до конфигуратора без знания пароля было очень просто. Достаточно было удалить файлик users.usr. В 8й версии это стало сложнее, но не намного. Теперь это делается правкой 1 байта в файле базы с помощью hex-редактора. Это, в принципе практически, так же легко как и удалить файл. После этого спокойно заходим в базу и вуаля – вот они конфиденциальные данные.

А раз вход в базу данных не представляет особой проблемы, то выходом может стать введение повторной авторизации уже после входа в базу данных. Компании 1С-франчайзи время от времени любят вводить клиентов в заблуждение, делая им обычный запрос пароля при входе в систему без каких-либо заморочек, тем самым обеспечивая и поддерживая иллюзию безопасности и сохранности данных клиента. Однако, при всей своей очевидности это решение гораздо сложнее, поскольку нужно добавить какой-нибудь алгоритм хеширования пароля, дабы не хранить пароль в базе в чистом виде – его ведь можно будет просто увидеть в отладчике. Свой выбор я остановил на одном из самых популярных алгоритмов MD5.

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

Изначально платформа 1C предоставляет разработчикам всего 2 варианта защиты кода программы – пароль на чтение текста модулей и поставка конфигурации без исходных кодов. Первый вариант нам не особо подходит. Это обусловлено тем, что проверку пароля нужно ставить в главный модуль конфигурации, а платформа не дает ставить на него пароль.

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

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

Именно эту фичу я и использовал для защиты кода от изменений. Для это нужно добавить в конфигурацию объект метаданных План обмена. После этого с помощью системной процедуры

ПланыОбмена.УстановитьГлавныйУзел(<СсылкаНаПланОбмена>);

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

Если же в качесте параметра процедуры передать значение Неопределено (а у центральной базы значение Главного узла именно такое), то редактирование кода вновь станет возможным.

Вопросы и дополнения пишите в камменты или на мыло.