SQL Server: защита базы данных от непосредственного изменения

Question

Наша программа поставляется с базой данных SQL Server 2005 и SQL Server 2005 Express. Обычно он устанавливает свой собственный экземпляр SQL Server 2005 на компьютер клиента.

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

Как мне этого добиться? Должен ли я установить права пользователя? Могу ли я использовать шифрование? Я думал о том, чтобы установить собственный пароль «sa» для доступа к экземпляру SQL Server и использовать его только из программы, но это не лишит его доступа через проверку подлинности Windows.

[Редактировать] Некоторые разъяснения того, что я пытаюсь сделать. Программа является программой времени и посещаемости. Часы сотрудников собираются из часов и сохраняются в базе данных; собранные данные не могут быть удалены, а их значения даты и времени не могут быть изменены. Поэтому мне нужен способ, чтобы пользователи не могли связываться с этими значениями непосредственно в базе данных.

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

[Изменить 2] Спасибо за ваши ответы, я хотел бы задать еще два вопроса по этой теме:

1 - Могу ли я предоставить разрешения SELECT только тем, кто обращается к БД через проверку подлинности Windows?

2 - Можно ли / целесообразно защитить таблицу от изменений через хэш-систему? Как добавить столбец хеша и вычислить хеш для каждой строки, а затем сравнить данные строки с хешем для проверки изменений?

Answer 1

Если у кого-либо есть доступ на уровне sa, вы не можете предотвратить это.Тем не менее, обычные пользователи не должны иметь доступ к sa.

Вы можете помочь изолировать его от обычных пользователей с помощью грантов, например, только предоставляя пользователю своего приложения доступ к INSERT, UPDATE, DELETE (или EXECUTE, если вы вместо этого используете хранимые процедурыпрямой SQL) и только предоставляя другим пользователям доступ SELECT (или нет).

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

Answer 2

Вы не можете запретить членам локальной группы администраторов делать все, что им нравится с вашей базой данных. Любое утверждение об обратном - змеиное масло. В наше время все, что нужно, - это один бесстрашный пользователь, чтобы найти способ изменить данные (например, добавив себе время), и с этого момента Google обеспечит каждого пользователя. заинтересованные найдут взломать.

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

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

Answer 3

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

Answer 4

Можете ли вы использовать SQL Server Compact Edition вместо Express?Он встроен в приложение и предназначен для такого сценария.