Аутентификация как механизм лицензирования

в 7:08, , рубрики: SaaS, SaaS / S+S, защита от копирования, информационная безопасность, метки: , ,

Все разработчики ПО хотят кушать и бывает очень обидно, когда программа, на которую было потрачено множество времени и сил, доступна для пользования любому без законных отчислений в пользу автора. Разработчик, не получив свое кровное, начинает волноваться, плохо спать, а то и совсем перестает создавать свои продукты. Защищать ПО от несанкционированного использования стали практически тогда же, когда начали продавать программные продукты. В разное время использовались разные механизмы – серийные номера, привязка к компакт-дискам и параметрам компьютера, использование электронных ключей. Все эти механизмы достаточно подробно освещены на просторах интернета. А том, как защитить интересы разработчиков SaaS решений информации меньше. Я попытаюсь рассказать об одном из механизмов «лицензирования» онлайн ПО, который всплыл как-то неожиданно для меня самого.

Аутентификация как механизм лицензирования


Для начала стоит перечислить, о чем все же мы говорим. Условно проблему можно поделить на две части:
• Незаконное копирование ПО;
• Незаконное использование ПО.

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

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

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

За последнее время, мне пришлось посотрудничать с несколькими компаниями, решившими ограничить доступ к своим сервисам более строгим методом. Для обеспечения надежного «лицензирования» были использованы токены с неизвлекаемыми ключами, по сути являющиеся аналогами аппаратных ключей защиты ПО. Выпускаемое компанией Актив устройство Рутокен Web позволяет построить схему аутентификации таким образом, что без физического владения ключом сервисом пользоваться будет нельзя. То есть один ключ — один пользователь. Такой подход позволяет решить проблему запрета использования сервиса множеством людей под одной лицензией. Вот так строгая аутентификация приобрела для меня дополнительное свойство лицензирования ПО.

Более подробно о самом механизме аутентификации Рутокен Web я писал тут.

Автор: EugeneSukhov

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js