Процедура хранилища SQL Server шифрует, безопасно?
В то время как katriel уже ответил, что это с абсолютным минимумом должно было создать init сценарий, я думаю, что Вы были бы также хорошо обслужены со взглядом на /etc/init.d/skeleton и использование, что как шаблон, на котором можно основывать Ваш init сценарий. Вы закончите с намного более последовательным и читаемым сценарием.
Уверьте, что даже при использовании шифрования для Хранимых процедур в SQL Server 2008 это могло бы быть очень легко дешифровано с помощью сторонних инструментов. Существуют многие из них, и одним из них является http://www.elitude.net/.
Если Вы используете собственное программное обеспечение, затем добавляющее, что другой слой с помощью шифрования НЕ будет достаточно, если существует решительный пользователь. Все, что можно сделать, просят, чтобы они подписали соглашение о неразглашении (NDA) и поддержали эти правила.
Это 'безопасно' в том SQL Server, сохранил и зашифрованный текст процедуры и ключ, требуемый дешифровать его в Вашей базе данных, поэтому когда этому нужен текст процедуры - для компиляции плана запросов для выполнения его - это может дешифровать его.
Большая часть SQL Server может когда-либо делать, запутывают ключ, пытаясь скрыть его так он легко не украден.
Исторически была атака с повторением пакетов, где при использовании ALTER PROCEDURE, он снова использовал бы тот же ключ. Путем использования ALTER PROCEDURE с известным простым текстом Вы могли сравнить получающийся зашифрованный вывод и восстановить keystream, затем использовать это для дешифрования исходного зашифрованного текста. (Это использует поточный шифр RC4, который производит псевдослучайную строку битов, названных keystream, который является затем XORed с простым текстом для шифрования, или XORed с зашифрованным текстом для дешифрования.) Я не знаю, имеет ли это все еще место в SQL Server 2008.
DBA SQL-сервера будет всегда иметь способ просмотреть содержание хранимой процедуры, если они будут достаточно стараться. Единственный способ приложить это более трудное усилие состоит в том, чтобы использовать сторонний продукт, любят sql-щит, который будет использовать другую схему шифрования для preven "обычные' нападения дешифрования от того, чтобы быть успешным. Каждый раз, когда Вы даете кому-то зашифрованные данные и доступ к ключу расшифровки, Вы никогда не можете предотвращать дешифрование данных (неважно, насколько запутываемый процесс мог бы быть). Шифрование только действительно "хорошо" когда ключ шифрования и данные, не доступные вместе. Можно также считать запутывание кода при помощи хранимой процедуры CLR и любого многого .NET obfuscators доступным. См. Хранимые процедуры CLR для примера.