Oracle - Защита исходного кода

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

Обфускация (WRAP), хотя поначалу была многообещающей, оказалась бесполезной, поскольку очень легко ОТМЕНИТЬ обфускацию и вернуть исходный (читаемый) код.

Итак, прежде чем я сдаюсь, есть ли какой-либо способ, поддерживаемый Oracle, который позволяет по-настоящему скрыть код? (Я имею в виду, помимо блокировки доступа по учетным данным).


oracle source-code-protection
person FDavidov    schedule 28.06.2015    source источник
comment
Почему вы не рассматриваете возможность использования привилегий для блокировки доступа? Если вас беспокоит, что администраторы баз данных имеют доступ, есть даже способы ограничить их с помощью Oracle Database Vault. Но, имея дело с этим продуктом как администратор базы данных, я могу сказать вам, что очень больно ограничивать таких администраторов.   -  person Jon Heller    schedule 28.06.2015
comment
Спасибо за комментарии, Джон. Я знаю о последствиях, связанных с блокировкой доступа администратора баз данных к коду, но (как вы можете себе представить) есть среды / приложения, в которых это условие почти обязательно.   -  person FDavidov    schedule 29.06.2015

Ответы (2)


arrow_upward
0
arrow_downward

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

В то время как для упаковки пакетов просто заменяются байты. Для процедур Oracle хранит p-код виртуальной машины ADA. Что гораздо сложнее изменить инженеру.

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

person ibre5041    schedule 28.06.2015
comment
Спасибо за ваш быстрый ответ. Я только что проверил распаковку функции, процедуры и всего пакета с помощью предлагаемого здесь обслуживания: codecrete.net/UnwrapIt. Все три были ИДЕАЛЬНО возвращены к исходному коду. Следовательно, обфускация не подходит (не из-за ее недостатков, как вы упомянули, а потому, что она бесполезна). - person FDavidov; 28.06.2015
comment
Удивительно. Я думал, что никто еще не приложил достаточно усилий для реверсирования инженерного байт-кода ADA (или того, во что он вовлечен на протяжении многих лет). В любом случае из-за некоторой ошибки администраторам баз данных может потребоваться перекомпилировать PL / SQL с оптимизацией или без нее, поэтому должен быть какой-то способ вернуть исходный исходный код. Возможно, вам удастся скрыть какую-то действительно важную часть кода в хранимой процедуре Java. Но даже байт-код java можно декомпилировать. Это просто вопрос вложенных усилий. PS: Хранимые процедуры Java намного проще поддерживать, чем процедуры C. - person ibre5041; 28.06.2015

arrow_upward
0
arrow_downward

Это, пожалуй, одно из оставшихся преимуществ языков предварительного компилятора, таких как Pro-C, Pro-COBOL. Конечно, запросы всегда можно выявить с помощью трассировки / мониторинга, но логика, не связанная с SQL, в языках будет скрыта, поскольку то, что вы доставляете, будет скомпилированными объектами. У вас есть возможность обратиться к библиотекам C (см. CREATE LIBRARY) из PLSQL для выполнения ваших вычислений, но окунуться в это просто для разделения между SQL и логическим потоком, я думаю, будет громоздко. Этот метод имеет тенденцию использовать преимущества внешних утилит (например, библиотеки Bank Wizard для проверки банковских счетов, проверки PAF и т. Д.).

person TenG    schedule 28.06.2015
comment
Что ж ... Реализация бизнес-логики, которая требует интенсивного взаимодействия с данными, вернется в прошлое столетие. Вы не согласны? НАСТОЯЩИМ решением было бы, чтобы ORACLE представил НАДЕЖНУЮ защиту исходного кода ... - person FDavidov; 28.06.2015
comment
Это в значительной степени то, что Oracle делает для многих своих программ. - person hdost; 28.06.2015