Журнал аудита использования лицензий на программное обеспечение - PullRequest
3 голосов
/ 25 января 2010

Люди,

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

В частности, TickZoom продает торговую платформу альфа-поколения для хедж-фондов, которая в настоящее время обходится в 2000 долларов США в месяц за лицензию, включая поддержку (скоро увеличится более чем вдвое). Это хорошо для учреждений, но слишком дорого для частных лиц. Люди часто просят более низкую цену в обмен на процент от прибыли, полученной с использованием программного обеспечения, до тех пор, пока они не смогут позволить себе платить фиксированные сборы.

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

Это приложение написано на C #, и эта часть системы запутана, по крайней мере, затрудняя расшифровку кода.

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

Конечно, предполагается, что файл будет зашифрован.

Но есть ли идеи, как сделать его "защищенным от взлома"? Особенно против простой попытки удаления?

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

Затем, когда мы поставляем программное обеспечение, оно упаковывается с «пустым» файлом аудита, который, на самом деле, имеет своего рода проверочную проверку.

Следующий очевидный способ, которым пользователи могут попытаться «подделать» файл, - это просто сделать резервную копию этого оригинального «пустого» файла, а затем использовать его для последующей перезаписи файла аудита, тем самым обманывая систему, думая, что это новый старт.

Возможно, это можно решить, добавив какую-то "метку времени последнего обновления" и время истечения.

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

С уважением, Waynek

Ответы [ 3 ]

5 голосов
/ 28 января 2010

Формулировка вашей проблемы:

  • мы не доверяем клиенту; клиент может быть враждебным.
  • мы хотим, чтобы клиент отправил нам данные, которым мы можем доверять.

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

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

2 голосов
/ 25 января 2010

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

- Изменить:

На мой взгляд, у вас есть только следующие варианты:

  • Преобразование системы в веб-интерфейс (или, по крайней мере, в тонкий клиент), тем самым осуществляя все транзакции на сервере

Очевидно, это, вероятно, довольно непрактично, если вы уже разработали целую локальную систему

  • Придумайте какую-нибудь сложную схему, которую «сложно» сломать, и надейтесь, что люди не сломают ее

И объедините в этом методе какое-то профилирование, показывающее, зарабатывают ли магазины X, и вдруг X-sigificantAmount, вы можете определить, что они больше не приносят прибыли, таким образом, вероятно, обманывая систему (или выходя из системы) бизнеса :) Но это граничит с вторжением в частную жизнь и, возможно, не совсем уместно.

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

1 голос
/ 25 января 2010

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

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

Не совсем дурак, но был бы довольно надежным.

Также, проверить этот вопрос

...