Недостатки в объектном шифровании SQL Server 2005+?

Question

Для базы данных, которая поставляется с удаленно развернутым продуктом, есть ли какие-либо недостатки в шифровании всех объектов кода (процедур, функций, представлений) с помощью предложения WITH ENCRYPTION в MS SQL Server 2005 и 2008?

Преимущества являются сдерживающим фактором для «пользовательских» изменений в области, которые решают одну потребность, создавая еще больше. Цель состоит не в том, чтобы защитить IP или данные, а в том, чтобы помочь предотвратить несанкционированные изменения кода, когда невозможно управлять правами на изменение объектов (безопасность находится вне рук разработчиков, но ответственность за исправление проблем, вызванных другими пользователями).

Какие новые проблемы могут быть вызваны таким подходом?

Answer 1

Microsoft создала эту функцию специально для этой цели. Единственный недостаток, который я вижу, - слабая защита; его можно обойти общедоступными скриптами, а SQL Profiler можно использовать для просмотра открытого текста дешифрованных процедур Но это все равно должно действовать как эффективное сдерживающее средство.

Answer 2

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

Answer 3

Вы не на том пути. WITH ENCRYPTION - это устаревший вариант из SQL 2000 дней. Способы обхода хорошо известны и могут быть обнаружены любым, кто обладает минимальными навыками поиска в Google . Правильным способом является использование подписи кода . Лучший способ - создать сертификат, подписать процедуры, а затем сбросить закрытый ключ. Таким образом, никто, даже вы, не может изменить код, не разрушая подписи. Это не мешает никому изменять процедуры, но после изменения они разрушают печать подписи, и подделка становится очевидной. Вы можете сделать еще один шаг вперед и убедиться, что сами по себе процедуры не имеют полномочий для выполнения своей цели (т.е. не могут читать таблицы, к которым пытаются получить доступ), но полномочия основаны на их сигнатурах (сертификат, используемый для их подписания, предоставляется необходимые права). Таким образом, если они вмешиваются в код, они не только разрушают печать, но и приводят к остановке системы. Объяснение последствий этих действий обычно является достаточно сильным сдерживающим фактором.

Answer 4

Мы внедрили шифрование в корпоративный продукт, который мы развернули на более чем 200 сайтах по указанным вами причинам и для предотвращения обратного инжиниринга.

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

Кроме того, усложняется изменение схемы в соответствии с ожидаемой версией. Большинство разностных инструментов не могут различать зашифрованные объекты.