Я использую SQL Server 2008 Enterprise на Windows Server 2003 Enterprise. Я разработал некоторые хранимые процедуры для SQL Server, и машина, на которой установлен SQL Server, не может полностью находиться под моим контролем (может использоваться ненадежной третьей стороной).
Я хочу защитить исходный код T-SQL моих хранимых процедур (т.е. недоступный для просмотра какой-либо другой стороной) с помощью функции шифрования хранимых процедур, предоставляемой SQL Server. Я не уверен, безопасна ли зашифрованная хранимая процедура и будет ли у администратора машины (установленного с SQL Server) способы просмотра исходного кода хранимой процедуры?
Можно расшифровать и просмотреть источник зашифрованных хранимых процедур SQL, быстрый поиск по запросу «Расшифровать хранимую процедуру sql» покажет вам изрядное количество совпадений, например:
Однако шифрование вашей хранимой процедуры, по крайней мере, затрудняет просмотр источника - я также не уверен, действительно ли какие-либо из текущих методов дешифрования хранимых процедур действительно жизнеспособны при установке живого SQL-сервера - в прошлый раз я просмотрел много необходимых методов монопольный доступ к экземпляру SQL-сервера и предотвращение доступа других пользователей к серверу (хотя это все еще может быть неверным).
Также стоит отметить, что шифрование вашей хранимой процедуры может вызвать головную боль поддержки - поскольку вы больше не можете видеть планы выполнения для своих зашифрованных хранимых процедур, у вас могут возникнуть проблемы при попытке диагностировать какие-либо проблемы с производительностью.
Мне неизвестны другие методы защиты вашего источника.
Чтобы уточнить ответ marc_s (сейчас удален)
Для SQL Server 2005 и более поздних версий порог для получения «простого текста» выше, чем раньше. В основном, сисадмин поверх DAC. К этому моменту вы все равно уже выиграли.
Для SQL Server 2000 и ранее это было намного проще. Честно говоря, суровый взгляд сработал.
Таким образом, это достаточно безопасно для конечных пользователей и разработчиков (без системного администратора), но не в том случае, если вы хотите использовать его для защиты IP на сайте клиента.
«Я хотел бы упаковать свое приложение базы данных в форме, которая позволила бы клиенту использовать его, но без возможности доступа к реальным данным, хранящимся в нем. Я думаю, что шифрование базы данных должно помочь».
ответ всегда один: то, что вы просите, называется управлением цифровыми правами, а SQL Server не поддерживает DRM. Этот ответ применим независимо от того, обращаетесь ли вы к данным, к дизайну схемы или к логике хранимых процедур. Видеть Кому нужно шифрование? для более подробного обсуждения.