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

Поэтому прошу предложить и обсудить действенные решения.
Что имеем:
1. Информационная система дающая пользователям возможность принимать сложные решения в режиме онлайн, соответственно все действия применяемые оператором должны быть подписаны каким-то образом.
2. Архитектура клиент-сервер (клиент - Win32 приложение, сервер MS SQL 2008).
3. 99 % бизнес логики сосредоточено на стороне SQL, в виде Stored Procedures (все добавления, изменения, удаления и выборки только через процедуры).
4. Метод аутентификации средствами SQL Server. Пользователей > 50.

В процессе мозгового штурма родились следующие идеи:

Идея А): ЭЦП для каждой строки.
Добавление в каждую таблицу полей Old (bit) и Hash - ЭЦП всей строки, при этом любое изменение записи приводит к генерации новой записи с новой подписью и с полем Old = 0, а старая запись помечается как Old = 1.
В итоге после каждого изменения создается запись, подписанная заново. Вся работа с таблицами ведется с условием Old = 0.

Плюсы:
Реальное придание значимости системе.
ЭЦП может генериться на стороне клиента(у сервера нет закрытого ключа пользователя для подписывания).
Минусы:
Сложная реализация
Существенное увеличение данных
Проблемы с PK и FK


Идея Б): ЭЦП только в логах (после изменения).
В систему добавляется продвинутый журнал действий пользователя (он и так есть, просто начинает использоваться для ЭЦП).
Журнал содержит следующие сведения:
Пользователь, Хост, Сессия, Таблица, Поле, Старое значение, Новое значение, ЭЦП
Соответственно любое изменение любых данных должно генерировать записи в журнал, которые в свою очередь подписываются.

Плюсы:
Простота реализации (нужна только система триггеров на таблицы).
Минусы:
Непонятно будет ли это являться юридически правильным.
ЭЦП придется генерировать на стороне сервера, что совсем не ясно как организовать, ведь закрытый ключ есть только у клиента.


Идея В): ЭЦП только в логах (перед изменением).
В систему добавляется продвинутый журнал действий пользователя (он и так есть, просто начинает использоваться для ЭЦП).
Журнал содержит следующие сведения:
Пользователь, Хост, Сессия, Таблица, Поле, Старое значение, Новое значение, ЭЦП
Отличие от идеи Б состоит в том что сначала генерируется запись в таблицу лога, а только потом на основании этой записи выполняется действие. Т.е. по сути таблица логов становится таблицей заявок на изменение или очередью транзакций.
Соответственно любое изменение любых данных должно проходить сначала через эту таблицу, записи которой в свою очередь подписываются.

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

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

Модератор: Тема перенесена из форума "Microsoft SQL Server".

Я тоже склоняюсь к варианту В как к самому правильному, но он безумно сложен тем что придется переделывать очень много.

Модератор: Тема перенесена из форума "ERP и учетные системы".