Как запутать SQL Sprocs?

Question

Есть ли способ скрыть / защитить / запутать хранимые процедуры MS SQL?

Answer 1

Если вы хотите скрыть это, как насчет предложения "WITH ENCRYPTION"?

http://blog.sqlauthority.com/2007/07/01/sql-server-explanation-of-with-encryption-clause-for-stored-procedure-and-user-defined-functions/

Answer 2

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

Во всяком случае, многие из SQL, которые я видел здесь, в качестве стандартного замаскированы.

Answer 3

См. Параметр ENCRYPTION для оператора CREATE PROCEDURE.

http://msdn.microsoft.com/en-us/library/ms187926.aspx

Answer 4

Нет. По крайней мере, не таким необратимым образом. «С ШИФРОВАНИЕМ» в SQL Server 2000 можно изменить, чтобы получить исходный открытый текст. Псевдокод и скрипт T-SQL, иллюстрирующие это, находятся здесь: http://education.sqlfarms.com/education/ShowPost.aspx?PostID=783

Примечание: я не пробовал его с SQL 2005 или выше, но я думаю, что он так же уязвим .. Как указано в документе MSDN:

ENCRYPTION Указывает, что SQL Server преобразует исходный текст инструкции CREATE PROCEDURE в формат обфусцированный .

Акцент мой.

Answer 5

Старый пост, я знаю. Но я пришел сюда из поиска «Почему я должен запутывать SQL?» Я только что установил бесплатный продукт под названием ApexSQL Refactor (без присоединения), который предлагает компонент запутывания.

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

CrEAtE Procedure spInsertOrUpdateProduct @ProductNumber nVarChar(25),
@ListPrice Money aS IF exIsTS(selECt * FROm Production.Product WHere
ProductNumber=@ProductNumber AnD ListPrice>1000) uPdatE Production.
Product sET ListPrice=(ListPrice-100) where ProductNumber=
@ProductNumber elsE INSerT intO Production.Product(ProductNumber,
ListPrice) SelECT @ProductNumber,@ListPrice GO SElEct * fRoM
Production.Product gO iNsERT iNTo Production.UnitMeasure(
UnitMeasureCode,Name,ModifiedDate) vAlUeS(N'FT2',N'Square Feet',
'20080923'); Go

Answer 6

Легко обратимо, если вы знаете, но запугивает большинство людей, ковыряющихся в коде. hex кодирует вашу логику, а затем выполняет с EXEC (@hexEncodedString).
см. сообщение .

Answer 7

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

http://msdn.microsoft.com/en-us/library/ms131094.aspx

Answer 8

Вы можете использовать предложение ENCRYPTION при создании хранимой процедуры.

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

Смотрите здесь для получения дополнительной информации:

http://msdn.microsoft.com/en-us/library/ms187926(SQL.90).aspx

Answer 9

Если вы действительно беспокоитесь о том, что кто-то попадет в БД и увидит источник процедуры, то, как сказал С. Лотт, вы можете перенести процедуру на C #. Я бы порекомендовал LINQ.

Однако сама база данных, вероятно, должна быть защищена от доступа людей к коду для процедур, которых не должно быть. Вы можете ограничить права пользователя или группы, чтобы иметь ИСПОЛНИТЕЛЬНЫЙ доступ к процессу только в случае необходимости.

Answer 10

Вы всегда можете написать обычный код на C # (или VB) и сохранить его вне базы данных в DLL.

Тогда вам не нужно беспокоиться о запутывании вашего SQL.