2012-04-24 1 views
2

Я подобрал python/django всего лишь год. Развертывание сайта django по-прежнему является предметом, о котором у меня есть много вопросов, хотя я успешно вручную развернул мой сайт. Один из моих самых больших вопросов, связанных с развертыванием, - это , какие меры я могу предпринять, чтобы защитить исходный код моих приложений, включая пароли в настройке django.py, от других, особенно, когда мой сайт работает на виртуальном хостинге, предоставляемом некоторым третьим лицом. Назовите меня параноидальным, но тот факт, что мой исходный код работает на стороннем сервере, у которого есть привилегии доступа к чему-либо/на сервере, вызывает у меня чувство беспокойства.Какие меры я могу предпринять, чтобы защитить исходный код моего сайта django от других?

+1

«Назовите меня параноидальным» - да, вы параноик. –

+1

@ahmoo Лучший вариант - найти поставщика, которому вы можете доверять. –

+1

Я второй Даниэль и Майкл. Там действительно мало что можно сделать. Даже если вы только развернули файлы .pyc, их можно скомпилировать. – Brandon

ответ

1

Если someone has the privileges to access anything/anywhere on the server вы не можете сделать много, потому что то, что вы можете делать другим, может также сделать, вы можете попробовать какой-то способ обфускации, но это не сработает. Единственное решение - НЕ использовать такой общий репозиторий.

Edit: варианты

  1. Продолжайте работать с общим хранилищем, если ваши данные не очень чувствительны
  2. Использования выделенным хостингом от таких компаний, как стоечное пространство и т.д.
  3. Использование AWS запустить свой собственный экземпляр
  4. Используйте сервер google-app-engine, но для этого может потребоваться изменение БД
  5. Запустить свой собственный сервер (наиболее безопасный)
+0

Каковы некоторые другие варианты?(Я не хочу запускать свой собственный сервер) – tamakisquare

+1

@ahmoo, см. Редактирование, все зависит от вашего уровня паранойи :) –

+0

Спасибо за дополнительную информацию. Последний последний вопрос. Как насчет простых строковых паролей в settings.py? Должен ли я что-то делать? – tamakisquare

1

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

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

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

+0

Хорошо. Как насчет паролей в моих settings.py? Должен ли я чувствовать себя комфортно, оставляя их в простых строках? – tamakisquare

+0

pyc ничего не сделал: если django может импортировать settings.py или pyc и получить пароль, так может человек –

+0

Да, .pyc не защитит ваши пароли. Однако и ничего другого. Это просто факт - вашему серверу нужно доверять, чтобы получить доступ ко всем данным, которые ему нужны для доступа, и тот, у кого есть root-доступ к вашему серверу, также сможет получить доступ к этим данным. Создайте план безопасности вокруг этой правды. –

1

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

С другой стороны, я мог бы просто говорить о своем заднем конце, так как я еще не суетился с Django.

+2

Это для хранения паролей пользователей, где все, что вам нужно сделать, это подтвердить, что любой пароль, предоставленный пользователем, является правильным. Я думаю, что OP говорит о паролях базы данных, которые приложение должно иметь возможность отправлять на сервер базы данных. – octern

+0

О, право. Увидеть это с этой точки зрения имеет гораздо больший смысл. В этом случае, ... просто chmod это консервативно - только достаточно, чтобы ваши скрипты могли ссылаться на него и выполнять. –

0

Защита исходного кода не так важна ИМХО. Я бы просто разложил скомпилированные файлы и не слишком беспокоился об этом.

Защита вашей конфигурации (особенно паролей) действительно важна. Тема Темя хорошая.

Смежные вопросы