Почему в базе данных с открытым исходным кодом, такой как Postgresql и Mysql, нет зашифрованных хранимых процедур?

Question

Почему в базе данных с открытым исходным кодом, такой как Postgresql и Mysql, нет зашифрованных хранимых процедур?

Это из-за их врожденной философии открытого кода?

Каковы веские причины для шифрования хранимых процедур?

Answer 1

Хотя я уверен, что зашифрованные хранимые процессы - это, по крайней мере, простой вопрос программирования на PostgreSQL (MySQL и хранимые процессы не имеют большой истории вместе), но с поддержкой пользовательских языков PgSQL я не понимаю, почему это так полезно. В какой-то момент их нужно будет расшифровать, чтобы выполнить, чтобы любой, кто управляет сервером базы данных / базы данных, мог с достаточным навыком получить незашифрованный sp. Администратор базы данных уже может видеть все данные, все связи, что делает обфусцирование кода SP бессмысленным.

Answer 2

Поскольку зашифрованные хранимые процедуры являются явно плохой идеей.

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

Answer 3

Правильно, потому что никто не нуждался в этом.

Answer 4

Если это действительно классная функция (я никогда не использовал ее и не нуждался в ней), я предлагаю вам зарегистрировать запрос новой функции в соответствующих списках рассылки.

Postgresql: http://www.postgresql.org/community/lists/

MySQL: http://lists.mysql.com/

Answer 5

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

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

В основном - если вы хотите защитить свои данные от «кражи диска» - вы можете использовать шифрование жесткого диска. Если вы хотите защитить резервные копии - зашифруйте резервные копии. Но если вы хотите защитить базу данных от «слишком любопытных» администраторов - нанимайте адвокатов и не пытайтесь придумать (более или менее) невозможные способы сокрытия данных.

Answer 6

(RE: жирный текст) Я не думаю, что это совершенно правильно. Если вы когда-либо смотрели на ACT! для управления контактами они устанавливают MSSQL Express в качестве отдельного экземпляра и используют личное имя пользователя и пароль для SQL, а затем базу данных. Так что есть способы не делиться базой данных со своими клиентами.

Не для того, чтобы начать религиозную войну, но серверы БД, такие как MSSQL, имеют возможности шифрования proc. Идея в том, что если вы являетесь независимым разработчиком ПО, вы можете развернуть свое решение с зашифрованными процессами для защиты своего IP. Как администратор БД, вы не можете расшифровать эти процессы.

Мои 2 цента

Answer 7

Вот, imho, хороший сценарий для шифрования хранимых процедур / представлений. Компания, в которой я работаю, пишет приложение на основе базы данных. Мы размещаем базу данных в клиентской сети на сервере sql или рабочей станции, на которой работает SQL Express (для небольших клиентов с меньшим количеством пользователей). Хранимые процедуры и представления используются для аудита данных, предоставленных нам клиентом. Чтобы не допустить, чтобы клиентские администраторы или ИТ-специалисты просто нас обманули или украли запатентованные алгоритмы, мы шифруем хранимые процедуры и представления. Мы поддерживаем исходные текстовые сценарии в нашем программном обеспечении для контроля версий (т.е. Visual Source Safe), чтобы у нашей группы поддержки был доступ, чтобы увидеть, как кодируется процедура или представление. Мне бы хотелось, чтобы некоторые движки с открытым исходным кодом поддерживали его, чтобы мы могли отойти от ограничений SQL Express.

Answer 8

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

Конечно, вы можете ограничить доступ к исходному коду скомпилированного языка, такого как C ++, Java или Delphi. Клиент может перепроектировать скомпилированный код и изучить что-то из ваших алгоритмов, но это не то же самое, что иметь доступ к исходному коду. Существует много информации, которую они не получают при декомпиляции.

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

InterBase сохранил копию источника триггера / процесса в поле BLOB и скомпилированную версию той же процедуры в другом BLOB. Таким образом, вы можете обнулить поле BLOB, содержащее исходный код, и оставить скомпилированный код. Но это так же эффективно, как отправка скомпилированного кода приложения; он все еще может быть реконструирован пиратом с достаточным умением и мотивацией.

Я не знаю, возможен ли трюк NULL-out-the-source-BLOB в MySQL или PostgreSQL.

Нижняя строка:

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

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

Answer 9

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

Мне известно, что это не идеальное решение, но оно останавливает тривиальные попытки срывать код или не позволяет администраторам баз данных изменять то, к чему они не должны прикасаться.