Новые возможности защиты приложений - имеющимися средствами



Posted by Анатолий Анимица (213.24.65.254) on March 28, 2001 at 13:47:30:

In Reply to: Ой-йой-йой. Вопль заEnigmированных!!! posted by Valery Krumeng on March 28, 2001 at 09:51:24:

Valery Krumeng в своем сообщении 3427 сформулировал очень интересную задачу: как защитить от умышленного или случайного изменения приложение "Финансов без проблем" (ФБП) и, отчасти, базу данных. Одного единственного рецепта на все случаи жизни дать не могу - довольно много вещей надо строить по-разному в зависимости от целей приложения, окружения, прав доступа пользователей .., но некоторые методы решения задачи - причем средствами, имеющимися в арсенале ФБП прямо сейчас - попробую изложить. В виде ответов на вопросы, а затем, если позволите, и некоторого резюме.
Итак:

3. Выполняем инженерное/аудиторское/бухгалтерское сопровождение этих процедур и разработок. ... про аудиторские/бухгалтерские услуги, сопутствующие ФБП - чуть подробнее.
Разрабатывая бухгалтерскую; налоговую и иные системы (абсолютно законные) для предприятия клиента - мы (на основании договора), гарантируем, что при условии выполнения клиентом определенных последовательных действий, будет возникать совершенно определенный результат.
И при этом мы принимаем на себя полную материальную ответственность за этот результат (вплоть до обжалования несогласия с этим результатом - мытарей).


Здесь первая проблема, которую лучше определить, чем замолчать. Я занимаюсь вычислительными машинами, наверное, лет 35 (еще не 40 - с 1966 года), из них лет 25 - вычислительными системами для управления процессами и, может быть, поэтому с недоверием отношусь к программам, правильность которых не доказана.
К программному обеспечению (ПО) для бухгалтерского учета требования правильности не намного слабее, чем к ПО управляющих систем реального времени. И никакие гарантии: ни разработчика, ни тестера, ни страховой компании не покроют убытков от неверной работы ПО в случае его отказа. Защититься от отказа можно только доказательством правильности. В то же время сроки разработки никогда не позволяют заниматься доказательством дольше, чем срок жизни ПО. В реальности единственным надежным путем такого доказательства является детальное раскрытие - алгоритмов, программ, методов и других атрибутов ПО. Под детальным раскрытием мы понимаем далеко не всегда полное раскрытие - таковое чаще всего просто не существует или является профанацией, но детальное - метод описания ПО, представляющий его в деталях с исчерпывающей полнотой - и точным описанием границ раскрытых деталей. Детальное раскрытие является также важным контрактным атрибутом коммерческого ПО. Разработчик - допустим, просто человек, частное лицо, не имеет активов, гарантирующих от ошибок бизнес с оборотом в миллион долларов в месяц - да пусть даже в миллион рублей и пусть разработчик богат, как Крез - все равно. Риски надо ограничивать, а детальное раскрытие - единственный эффективный ограничитель рисков.

Следовательно, уместен более сдержанный энтузиазм, чем

Да еще отдельное спасибо ... за изготовление утилиты Enigma, которая позволила нам защитить от несанкционированного (даже неумышленного) изменения файлы *.rpt.

Я до сих пор не рискую применять шифрование *.rpt файлов в своих приложениях больше, чем это абсолютно необходимо - так как надежность ПО понимаю в изложенном выше смысле.
"Финансы без проблем" - без преувеличения уникальный инструмент, отвечающий моим представлениям о надежности ПО. Не один я так считаю, и многие аспекты этой стороны дела мы не раз обсуждали на доске WWWBOARD. Надежный алгоритмический фундамент архитектуры ФБП и встроенного в ФБП языка F позволяют разделить ответственность за правильность работы приложения в целом между хорошо структурированными компонентами, доказательство правильности каждого из которых провести гораздо легче, чем комплексное доказательство правильности системы как целого. Оставляя последний вывод правильности конечному пользователю, между прочим!

Очень много написал - хочу надеяться, что не переусердствовал. Изложенные выше соображения оставляют меня в лагере сторонников открытого исходного кода - а ФБП с ее (его, их?) открытым кодом приложений исторически на первом месте - среди действующих сегодня примеров открытого кода (Linux, Java etc) - и, значит, в лагере ФБП. Не в последнюю очередь по этой причине.
По этой же причине я не сторонник лозунга "Enigma защитит все".

Мой вывод: систему "Enigma" вообще не стоит рассматривать как панацею от несанкционированного изменения ПО, ее роль скорее - предложить механизм защиты от несанкционированного использования приложения ФБП, и эту роль специально подчеркивал А.Г.Водяник в первой публикации на эту тему.
Продолжим по вопросам Валерия:

Теперь короткое изложение проблемы: На одном из предприятий-клиентов .. системный администратор .. решил усовершенствовать правила. Что и сделал с помощью локальной версии ФБП. Это усовершенствование повлекло катастрофическое изменение результата.
Резюме:
1. Несмотря на попытку свернуть
(свалить? ААА) "неудачу" на систему ФБП, нерадивый сотрудник был наказан, а с проблемой мы справились.
...
3. И вопрос к господину Водянику: нельзя ли приобрести утилиту Enigmafora3p&rul, которая бы делала приятные изменения с файлами *.a3p & *.rul, подобные тем, которые делает Enigma с файлами *.rpt.

Первый рецепт. Сдавая систему заказчику в эксплуатацию, создайте ACNT+RPT+RUL архив (например, zip или arj - мне последний архиватор больше нравится, так как pkunzip при извлечении одного файла из вложенной директории с переименованием создает каталог (папку), а не файл с заданным именем. И заактируйте его - размер, длина, листинг, дата создания и т.п. Хотите, зашифруйте его, не хотите - не надо, это не важно. В ответственном случае такой архив можно положить в конверт и запечатать его печатью нотариуса. Дальнейшие процедуры известны. Стартуйте сервер из этого архива


arj x dir1\arcfile.arj dir2\*.rpt dir2\cas.rul
start fnt10318.exe -cXXXXX dir2 box ....
где dir1 - каталог с архивом, dir2 - рабочий каталог сервера, box - каталог обмена.

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

Второй рецепт. Сергей Холево о нем недавно писал (не факт, что воспроизвожу в точности, или что это то же самое, важна идея). Сергей привязывал приложение к компьютеру, препятствуя незаконному исполнению приложения на незарегистрированном компьютере. Но ведь точно так же можно вставить в код приложения метки, распознающие неизменность файлов-коэффициентов! И автоматически выполнять действия, пресекающие художественную самодеятельность пользователя. Выбор меток и инструментов - нетривиальная задача, поэтому я не хотел бы на них сейчас останавливаться.

Третий рецепт. Существует уже несколько часов - сервер 3.20 позволяет в полной мере реализовать рецепт 2 - просто однажды прочитайте и запишите cas.rul в extrd.dat известным вам способом. Никакого воздействия на результаты расчетов, вырабатываемые приложением ФБП, это заведомо не даст - а контроль целостности дерева видов операций достигается 100%.


И, наконец, четвертый рецепт:

P.S. да еще, исходя из того, что обслуживание у нас абонентское, неплохо бы было, если бы эти изменения действовали какое-то время, после которого (в случае неоплаты обслуживания), файлы не работали вовсе. При этом, хотим заметить, у клиентов остается ключ ФБП и право самим построить свою личную систему ресурсного учета.

Рецепт 3 как нельзя лучше подходит для решения и этой задачи! Только вот здесь закройте Enigm'ой один файл-коэффициент - тот, который и контролирует нужный параметр (скажем, срок абонентского обслуживания). А попытку откусить этот файл пресеките на корню - не дерева операций, разумеется, а тем же способом. Ведь его наличие и правильность можно проверить так же, как и неизменность дерева операций.

Контроль деструктивного воздействия на acnt.a3p не может быть предложен в общем виде. Могу лишь посоветовать не применять нигде явных указателей счетов, а работать с *обращениями, предварительно проверяя существование счета (субсчета). Постоянно имея в виду, что некоторое количество ресурсов сервера эта штука заберет. То есть разумно пользоваться таким контролем.

С уважением.
ААА




Пpишедшие ответы: