Поделитесь опытом или подкиньте идейку как наиболее беспроблемным образом организовать прозрачное шифрование данных в 1С. Соответственно документ, делает проводки по РБ. Надо шифровать этот документ и проводки, а потом соответственно расшифровывать... и всё бы ничего только есть ещё всякие ОСВ и бух операции. Которым любые решения не очень понравятся... Может на уровне MS SQL, может ВК использовать, может вообще весь регистр шифровать и быстренько извлекать...
---
алгоритмов шифрования много , выберите его создайте процедуру
Например

```1c
    Процедура Шифровка(ЧтоШифруем, КЛЮЧ)
    Зашифрованное=АлгоритмШифрования(чтоШифруем,КЛюч)
    Возврат(Зашифрованное)
    //Ключ это пароль пользователя который он вводит
```

Соответственно везде в проводках/доках хранить зашифрованные значения.
Для того чтобы расшифровать необходим ключ(который создаст пользователь и который тоже будет храниться в зашифрованном виде)
в итоге не узнав ключ пользователя программист увидит только зашифрованные данные, очень много алгоритмов шифрования при которых зная алгоритм но не зная ключ НЕВОЗМОЖНО(или нужно много лет) расшифровать данные.
---
comol, Соответственно документ, делает проводки по РБ. Надо шифровать этот документ и проводки, а потом соответственно расшифровывать... и всё бы ничего только есть ещё всякие ОСВ и бух операции. Которым любые решения не очень понравятся...

возможно не очень понял цель. если я разработчик с полными правами - от меня хоть как прячь - я вытащу любую инфу.
а вот если в пользовательском интерфейсе частично ограничить вывод данных, несмотря на роли - это можно. мы делали нечто подобное для данных по зарплате. завязка идет на настройки пользователя (что-то типа "Есть доступ к зарплате") - если нет, то в документах и отчетах пользователь увидит пустые суммы. может и коряво написал - но направление мысли такое.
---
nihfalck, от меня хоть как прячь - я вытащу любую инфу. Вытаскивай, зашифрованную по RSA к примеру и радуйся жизни :)))
---
comol, видишь ли - для шифрования/дешифрования ты будешь использовать алгоритмы и ключи, прописанные внутри конфигурации, к которым разработчик (то есть я) - однофигственно имеет доступ. смысл шифрования = 0 в этом контексте.
может правда - нет доверия к разработчику - нафик такого разработчика?
---
nihfalck, зачем иметь ключи в базе? Тогда никакого смысла в шифровании в 1с нет (если не использовать внешние компоненты).
---
PetroP, ну я про то и говорю. даже если ключ в базе не хранить - будет совершенно точно понятно откуда он берется) разработчик будет иметь доступ к процедурам получения ключа. что ему помешает встроить сохранение ключа куда-нить и потом его использовать?
только если написать свою ВК с двумя доступными методами. а всю логику внутри реализовать. на вход сумма - на выходе абракадабра. и везде где суммы нужно показать - на каждую сумму - вызов, вызов, вызов. сдается мне что не хорошо это скажется на скорости вывода отчетов.
---
nihfalck, с суммами все гораздо хуже: придется отказаться от стандартных способов накопления данных (РН) и построения отчетов (запросы, СКД...). Все это работать уже не будет.
---
PetroP, придется отказаться от стандартных способов накопления данных (РН) и построения отчетов (запросы, СКД...). Все это работать уже не будет.

кстати да, упустил из виду.

на уровне SQL можно посмотреть в сторону MS SQL Server Enterprise Edition. там есть в частности:
Прозрачное шифрование данных позволяет шифровать информацию без внесения каких-либо изменений в приложения.
http://www.microsoft.com/sqlserver/2008/ru/ru/enterprise.aspx

но зашифровано будет только в sql - 1Ска увидит все равно нормальные суммы.
---
PetroP, (26) nihfalck, Всё будет. "ВК" в 1с соответствующая уже давно есть. Пока буду шифровать таблицу с фильтром только по периоду... ну и соответственно во всех отчетах
НачатьТранзакцию(); Расшифровать(ДатаНач, ДатаКон); ВывестиОтчет(); ОтменитьТранзакцию(). Надеялся конечно что может кто-то придумает более адекватное решение...
---
comol, НачатьТранзакцию(); Расшифровать(ДатаНач, ДатаКон); ВывестиОтчет(); ОтменитьТранзакцию(). Надеялся конечно что может кто-то придумает более адекватное решение...Данные можно будет считать из оперативной памяти. При желании ))
---
MaxDavid, Данные можно будет считать из оперативной памяти. При желании )) Можно ещё из мозга телепатически :)
---
PetroP, Ключ на флешке или вводится...
---
comol, только так.
(32) comol, что за ВК? Как она работает (схематически)? Как будут рассчитываться итоги, агрегаты, если фактически сумм не будет в регистрах? Не совсем представляю...
---
nihfalck, (23) MaxDavid, Коллеги, рассуждайте как взрослые люди... Во всём цивилизованном мире уже давно принято что разработчик занимается разработкой, системный администратор - администрированием, финансист - финансами. И доступ разработчика ко всей финансовой информации совсем не лучшая практика. Все развитые платформы (СУБД) имеют для этого соответствующую технологию ещё готов с 90-х... в 1С она тоже есть, но, к сожалению, не прозрачная...
---
comol, ну-ну. а для финансиста его любимые отчётики, которые сами всю информацию собирают по базе анализируют и выводят в виде диаграмм финансист сам будет писать?
а как писать отчёт, если не представлять что там за данные хранятся и есть ли они вообще.
---
platon_, Что за данные все представляют... разница только в том что не представляют какие по факту данные....
---
comol, Коллеги, рассуждайте как взрослые люди... Во всём цивилизованном мире уже давно принято что разработчик занимается разработкой, системный администратор - администрированием, финансист - финансами.Так вот и используйте те инструменты, которыми пользуются во всем цивилизованном мире, а не натягивайте 1С на глобус ))
---
comol, Во всём цивилизованном мире уже давно принято что разработчик занимается разработкой, системный администратор - администрированием, финансист - финансами. И доступ разработчика ко всей финансовой информации совсем не лучшая практика.Вольготно, наверное, живется разработчикам во всем цивилизованном мире... ))
Финансист: У меня база неправильно считает!
Разработчик: Где? Покажите.
Финансист: Я не могу показать цифры, это финансовая информация.
Разработчик: А! Ну тогда подготовьте мне набор тестовых данных, на которых ошибка воспроизводится, а я пока дальше в контру поиграю )))
---
comol, ну так заберите доступ у разработчиков к базе(SQL серверу)...создайте отдельную базу, при КД цены всех товаров проставляйте 1.00 - на этом шифрование закончено, без реальных цен - уже не интересно. Вроде все работает, но данных по ценам нет.
в реальную базу пускать по USB-ключу.
---
minimajack, ну так заберите доступ у разработчиков к базе(SQL серверу) у меня, к сожалению, не столько человек, чтобы на обслуживание рабочей базы выделить отдельную группу... иначе конечно речь о шифровании не шла бы...
---
Надо шифровать этот документ и проводки Что означает в вашем представлении "зашифровать документ"? Зашифровать дату? Сумму? Ссылки на реквизиты справочников? Типа, открываешь форму - а там одни каракули?
потом соответственно расшифровывать... Когда наступит "потом"? Чем это определяется?

А вообще, неплохо было бы узнать - зачем нужна сама затея с шифрованием? Гладишь, и советовать было бы проще.
---
Cooler, Сумму в принципе.... главным образом сумму. зачем нужна сама затея с шифрованием Даже пользователям с полными правами не всё нужно видеть....
---
comol, Сумму в принципе.... главным образом сумму Тогда шифрование - это последнее, что нужно. Гораздо проще выводить на экран пустой реквизит документа или заполненный звездочками или прочерками.

что-то мне подсказывает что это затея близкая к нереальной... Да нет, почему же? Всего лишь переделать экранные формы документов и журналов, запретить все отчеты, компрометирующие эти "секретные" данные.

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

Вывод: "Брось этих глупостей, Беня!" (с)
---
Cooler, выводить на экран пустой реквизит документа или заполненный звездочками или прочерками с полными правами? :))))
---
comol, Даже пользователям с полными правами не всё нужно видеть....
Убрать полные права и настроить ограничение по РЛС - это единственное что можно тут придумать.
Какой смысл шифровать, если во всех отчетах все равно будет выполняться расшифровка?!
---
Несколько заметок на тему:

1. Если БД файловая - то тут единственный вариант: создать какой-нибудь файл-контейнер (или диск-контейнер) с шифрованием данных и в нём хранить БД. Таких програмулек валом, и платных и бесплатных.

2. Если БД серверная, то тут могут быть варианты:

2.1. Зашифровать диск, на котором лежит БД (в терминах СУБД - табличное пространство). Как сделать: см. пункт 1.

2.2. Написать какой-нибудь драйвер, который будет перехватывать обращения от 1С-Сервера к СУБД и шифровать/дешифровывать им данные. Таких нигде не видел, поэтому, скорей всего, придётся писать. Это сложно, т.к. шифровать надо будет не всё подряд, а только данные в переданных запросах с учётом типов данных (строку, число и дату совершенно точно надо будет шифровать разными алгоритмами, т.к. хранилище данных накладывает ограничения на содержимое типизированных полей).
---
FractonKireyev, который будет перехватывать обращения от 1С-Сервера к СУБД и шифровать/дешифровывать им данные что-то мне подсказывает что это затея близкая к нереальной... шифровать сам диск конечно смысла нет...
---
Я не очень понимаю задачу. В момент формирования ОСВ разве нельзя задать условие "Все Разрешенные"? Соответственно, рулить правами юзера. Или вам нужно именно записывать в базу зашифрованное значение?
---
MaxDavid, Как рулить правами юзера с полными правами? Даже если в рабочей базе получится разрулить никто не отменял тестовую среду и среду разработки....
---
comol, Как рулить правами юзера с полными правами?Если юзеру с полными правами чего-то нельзя видеть - значит, это не такие уж и полные права... ))
---
MaxDavid, соответственно пользователь с полными правами должен всё видеть, только зашифрованное...
---
От пользователя с правами открывать обработку/отчет сложно скрыть, он же открое консоль отчетов и сформирует оборотку по регистру бухгалтерии.
---
Соглашусь с максдавидом - может проще подрезать интер фейс юзеру ?
---
KontoraB, может проще подрезать интер фейс юзеру полные права. Представьте что от себя хотите данные в конфе собственной разработки скрыть.
---
Подойдем к проблеме с другой стороны. Каким образом посторонний сможет прочитать данные из базы? Может, проще ограничить доступ к файлу базы?
---
MaxDavid, Клиент-сервер конечно. Никто не говорит о постороннем
---
comol, Никто не говорит о постороннемТогда какова цель шифрования, если посторонний и так не имеет возможности заглянуть в базу?
---
MaxDavid, :)))) Никогда не встречался с задачей скрыть информацию от админа/разработчика базы?
---
comol, это не задача, это блажь. И, как всякая блажь, обойдется очень дорого. Желаю удачи!
---
comol, кое как шифровать можно строковые данные. Шифровать суммы - это нереальная переделка.
---
comol, Никогда не встречался с задачей скрыть информацию от админа/разработчика базы?Если вы не доверяете людям, работающим с базой, тогда 1С вам, очевидно, не подойдет. Используйте другую платформу или других людей ))
---
алгоритмов шифрования много , выберите его создайте процедуру
Например

```1c
    Процедура Шифровка(ЧтоШифруем, КЛЮЧ)
    Зашифрованное=АлгоритмШифрования(чтоШифруем,КЛюч)
    Возврат(Зашифрованное)
    //Ключ это пароль пользователя который он вводит
```

Соответственно везде в проводках/доках хранить зашифрованные значения.
Для того чтобы расшифровать необходим ключ(который создаст пользователь и который тоже будет храниться в зашифрованном виде)
в итоге не узнав ключ пользователя программист увидит только зашифрованные данные, очень много алгоритмов шифрования при которых зная алгоритм но не зная ключ НЕВОЗМОЖНО(или нужно много лет) расшифровать данные.
---
Cool_vsi, Вообщем только так... видимо, на этом закроем вопрос.
---
Cool_vsi, (47) comol, хотел бы я посмотреть описание того как Вы это собираетесь реализовывать. Хранить в реквизитах типа ЧИСЛО зашифрованную сумму )))). Детский лепет вообщем.
---
Хотелки ваши вполне понятны. Вот только реализация их может стать вам в суммы соизмеримые с теми, которые вы пытаетесь скрыть от пользователей с полными правами :-)
Это целый комплекс мероприятий по безопасности, которые очевидно начнутся с разделения прав в 1С, но этим не закончатся. Очевидно, что архитектура 1С такова, что пользователь с полными правами должен быть. Его невозможно ни в чём ограничить. Пусть это будет владелец бизнеса или гендир. Надеюсь им разрешено видеть любые суммы? Разработка конфигурации может вестись в базе заполненной тестовыми данными, без доступа к реальной базе. Что бы контролировать доступ к рабочей базе данных нужна служба безопасности...
Мне приходилось разговаривать с множеством клиентов выражающих подобные хотелки. Когда начинаешь просто перечислять комплекс мероприятий для их достижения и описывать работу в базе с подобными ограничениями - физиономия клиента начинает скисать прямо на глазах. Хотелки после этого ограничиваются стандартным разграничением прав по контрагентам, организациям, ролям, закрытием прошлых периодов.
---
AndreyMTV, пользователь с полными правами должен быть... Пусть это будет владелец бизнеса или гендир От души повеселился... "Николай Иванович, можно? Не могли бы вы обновить базу 1С :)))))". По-моему после этой фразы я был бы уволен )))
---
AndreyMTV, Вы не правы. Нет абсолютно никакой необходимости в "Очевидно, что архитектура 1С такова, что пользователь с полными правами должен быть." Вполне возможно создать несколько пересекающихся профилей для реализации "полных прав".
---
Заинтересовала дискуссия.
Тот вариант, который хочет реализовать ТС прямиком приведет к эпическому падению производительности. Т.к. каждый отчет, в который входит шифрованная сумма, придется формировать не запросом, а циклом. Т.е. назад в 7.7 со всеми ее плюшками.

Рискну предложить вариант, в котором есть 2 идентичные базы:
1. Рабочая
2. Для разработчика

В базе 1 права настроены так, что полный доступ в нее имеют только допущенные к секретам лица. Разработчик в этот круг не входит.
В базе 2 секретные суммы искажены и разработка ведется только в ней.
Когда есть необходимость внести изменения в рабочую базу, 3 кнопки в конфигураторе давит доверенное лицо.
Можно сделать обработку, которая в копии рабочей базы искажает секретные суммы и позволяет относительно быстро передать эту базу разработчику с обезвреженной секретной информацией.
Ну а шифрование, криптография - это для внешних дисков, на которых хранится рабочая база.
---
andreysmirnoff, База MS SQL > 100 ГБ, и у разработчиков есть админские права на MS SQL
---
Кому интересно... Решение кривое, но следующее:
1) Шифрование ведётся компонентой CAPICOM - как тут (http://infostart.ru/public/16791/)... которая немного устарела, но наиболее быстра, проста для 1С. Для неё надо только создать COM+ обёрку - как тут http://infostart.ru/public/195820/
2) В документы и РБ добавляются строковые реквизиты для сумм, в которые они шифруются, и в процессе шифрования обнуляются (вернее объединичиваются - чтобы работали итоги)
3) Поскольку архитектура системы (не бухгалтерия) позволяет ограничить объём шифрованных данных (флаг "зашифрован") в каждом отчет перен "Запрос.Выполнить()" располагается код вида
```1c
    Если ШифрованиеИнициализировано() Тогда
    НачатьТранзакцию();
    РисшифроватьВесьРегистр();
    Запрос.Выполнить();
    ОтменитьТранзакцию();
    КОнецЕсли;
```

К сожалению, ничего более умного не придумал пока и никто ничего не подсказал :(.
---
Шифрование баз данных средствами MS SQL Server

В Microsoft SQL Server 2008 впервые реализовано прозрачное шифрование баз данных (Transparent Data Encryption). Прозрачное шифрование кодирует базы данных целиком. Когда страница данных записывается из оперативной памяти на диск, она шифруется. Когда страница загружается обратно в оперативную память, она расшифровывается. Таким образом, база данных на диске оказывается полностью зашифрованной, а в оперативной памяти – нет. Основным преимуществом TDE является то, что шифрование и дешифрование выполняются абсолютно прозрачно для приложений. Использовать преимущества шифрования может любое приложение, использующее для хранения своих данных Microsoft SQL Server. При этом модификации или доработки приложения не потребуется.

В Microsoft SQL Server 2012 функции шифрования были улучшены и расширены. Для увеличения надежности криптозащиты и уменьшения нагрузки на систему применяется специальная иерархия ключей.

1. Каждой базы данных шифруется при помощи специального ключа – Database Encryption Key.
2. Database Encryption Key шифруется сертификатом, который создан в базе данных Master.
3. Сертификат базы данных Master шифруется ее главным ключом.
4. Главный ключ БД Master шифруется главным ключом службы Service Master Key.
5. Главный ключ службы SMK шифруется службой защиты данных операционной системы.

Наглядно схема работы с зашифрованной базой данных выглядит следующим образом:

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

Так, база данных защищается более быстрым симметричным шифрованием, которое, при учете больших объемов информации, предпочтительнее. В свою очередь, ассиметричному шифрованию подвергаются ключи шифрования базы, размер которых несоизмеримо мал, но критичность их защиты выше. Использование такого подхода, на серверах с низким уровнем ввода/вывода, низким потреблением процессорного времени и оперативной памятью, достаточной для хранения больших массивов информации, влияет на производительность на 3-5% при включении TDE. Серверы с меньшим объемом ОЗУ, чьи приложения нагружают ЦПУ и систему ввода/вывода, будут страдать на 28%, что достигается асинхронным выполнением процедур SQL (распараллеливание процессов).