Как защитить Web приложение?

Question

[3ton]

Каким образом можно предоставлять свои web приложения на сервера клиентов с исключением доступа к исходному коду.

Исходные данные: приложение на PHP с базой на MySQL, используется апач и стандартные PHP библиотеки для функционала.

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

Хотелось бы узнать какие еще существуют варианты защиты данных (в том числе и данные в базах чтоб не были доступны кроме как самому приложению).

PS: написал это как комментарий к одному из ответов, но позже решил что это достаточное уточнение чтоб отмести основные предлагаемые варианты.

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

Answer 1

[Павел Елизарьев]

Рекомендую Вам для начала задуматься над вопросом: "от кого вы собрались защищаться?".

Если Вы хотите чтобы Ваш клиент, не обладающий специальными навыками не уркал Ваше ПО, то Вам будет достаточно обфускаторов, о которых пишут коллеги выше (Zend, например).

Если Вы хотите защитить решения от угроз извне приложения, Вам следует нанять специалиста разработчика и провести аудит безопасности Вашего решения. Так же можете воспользоваться сканерами безопасности, типа XSpider или подобных.

Защитить же решение, которое размещается на внешнем сервере от хакеров / крякеров или иных специалистов, которые почему-то захотели именно Вашу программульку, Вам скорее всего самому не удастся. В таком случае стоит обратиться к профессионалам. Скорее всего Вам предстоит в таком случае пересмотреть архитектуру Вашего ПО, а так же каналы его распространения. Самый надежный сегодня вариант - это архитектура Software as a Service и собстенные защищенные сервера. Так поступают лидеры рынка, которые заполонили веб своими облачными решениями.

Comments

[3ton]

В нашем случае как раз и получается программа как сервис, но основной функционал находится именно на стороне заказчика, а доступ к нему будет согласно прохождению проверки лицензии включаться. Потому такие места должны быть скрыты от доступа заказчика. Так же думали над "облачными решениями" но хотелось бы побольше узнать о их архитектуре и реализации в разрезе PHP SaaS приложений, можете указать куда грести за большей информацией?

[Павел Елизарьев]

3ton: "Облачные решения" - это такой красивый термин для железонезависимой виртуализации. В вашем случае стоит сконцентрироваться на "функционале на стороне заказчика" и провести декомпозицию. Наверняка можно какую-то часть кода перевести на внешнее (от заказчика) местоположения с удаленным вызовом. Так Вы себя обезопасите.

Касательно SaaS - начните с википедии: en.wikipedia.org/wiki/Software_as_a_service и идите дальше по ссылкам. Рано или поздно Вы дайдете до архитектуры программных приложений. Тут я могу рекомендовать Фаулера www.ozon.ru/context/detail/id/1616782/.

Что касается PHP - то Вам, как разработчику, стоит придти к пониманию, что именно язык служит архитектуре, а не наоборот. Иначе выражаясь, - не важно на каком языке Вы пишите.

[3ton]

Павел Елизарьев: Спасибо за Вики, прочитал еще раз и убедился что именно таким путем и идем, но вопрос с переводом на сервер заказчика присутствует. Хотя возможно мы не правильно его интерпретировали. Когда заказчик желает воспользоваться CRM но его смущает необходимость работать в одном информационном пространстве с другими заказчиками, он предлагает получить изолированную от других заказчиков среду. Вот именно в этом моменте у нас и недоумевание - как ее обеспечить. Мой вопрос мне показался наиболее приемлемым при условии возможности сохранить приватность кода и данных, но есть вариант который мы пока не знаем как реализуется. Это вариант когда при клике на каком-либо SaaS сервисе разворачивается среда изолированная от основного сервиса и там лишь рабочее пространство конкретного заказчика. Для примера имеем сервис service.ru где логинимся и работаем в общем с другими клиентами информационном пространстве, но существует вариант создать изолированное пространство как вариант в поддомене customer.service.ru где будет база с данными лишь данного заказчика. Как пример если мы в первом варианте будем иметь в базе записи чередующиеся в порядке добавления их всему клиентами(к примеру нашему клиенту будут принадлежать записи с индексом 2,6,11, 35,56 ... ... ..), то во втором случае после первой записи у нас будет идти с индексом 2, а после нее с индексом 3, так как ни чьих посторонних записей там появиться не может.

Направьте пожалуйста где можно побольше узнать про такой вариант решения нашего вопроса.

[Павел Елизарьев]

3ton: CRM? Что же Вы раньше не сказали? Юридически мы делаем так: сдаем в аренду виртуальный сервер заказчику и размещаем на нем CRM. По документам и фактически все рычаги остаются у Вас. Клиент получает выделенное ПО исключительно под его нужды, а Вы получаете контроль. Читать тут особо нечего. Просто поставляйте свое решение по под эгидой SaaS: пока аренду платишь - все работает.

[3ton]

Павел Елизарьев: А каким образом идет поднятие виртуалки и накатывание продукта - вручную или есть автоматизм?

[Павел Елизарьев]

3ton: Вручную накатите на один образ, а затем копируйте его для каждой виртуалки.

Answer 2

[Сергей Наломенко]

Шифруйте PHP-код Zend'ом, ставьте на сервер ionCube Loader — и будет Вам счастье :)

Comments

[xmoonlight]

не особое счастье.... декомпиллеров - навалом. 1 раз декомпилят и код в паблике...

Answer 3

[Эргил Осин]

Гуглить по «обфускация php»

Answer 4

[Sergey Lerg]

Ещё можете модифицировать для работы под HipHop или KPHP и распространять в бинарном виде. И производительность за одно увеличите.

Answer 5

[xmoonlight]

Был бы вопрос)))
REST API - строго у Вас на серверах.
Тонкий клиент (html(5)/js/png/mp3/svg/etc.) - где угодно...

Для защиты АВТОРИЗАЦИИ: сертификаты и ключи.
Для защиты ДАННЫХ: используются алгоритмы шифрования канала передачи данных.
Для защиты REST API: защита авторизации + защита канала передачи данных.

И важно помнить!!!: всё что находится за пределами REST API - уже Вами не контролируется (как бы Вы не пытались криптовать или обфуцировать код/ключи и прочее).

Ваш кэп!)