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

Question

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

Answer 4

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