Spec-Zone.ru › Django 1.9

Список проверок перед развертыванием

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

Django включает много функций безопасности. Некоторые из них встроенные и всегда включены. Другие — опциональные, потому что не всегда уместны или неудобны для разработки. Например, принудительное использование HTTPS может быть неприменимо для всех веб-сайтов и неудобно для локальной разработки.

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

Следующий список проверок включает настройки, которые:

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

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

Запуск manage.py check --deploy

Некоторые из проверок, описанных ниже, можно автоматизировать, используя опцию check --deploy. Не забудьте выполнить её на файле настроек рабочей среды, как описано в документации к этой опции.

Критические настройки

SECRET_KEY

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

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

Вместо того, чтобы жёстко кодировать ключ секретности в модуле настроек, рассмотрите возможность его загрузки из переменной среды:

import os
SECRET_KEY = os.environ['SECRET_KEY']

или из файла:

with open('/etc/secret_key.txt') as f:
    SECRET_KEY = f.read().strip()

DEBUG

В рабочей среде необходимо отключить режим отладки.

Вы, безусловно, разрабатываете свой проект с DEBUG = True, так как это включает удобные функции, такие как полные трассировки в вашем браузере.

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

Настройки, специфичные для среды

ALLOWED_HOSTS

Когда DEBUG = False, Django вообще не работает без подходящего значения для ALLOWED_HOSTS.

Эта настройка необходима для защиты вашего сайта от некоторых атак CSRF. Если вы используете подстановочный символ, вам необходимо выполнить собственную проверку заголовка Host HTTP, или каким-либо другим способом обеспечить, что ваш сайт не уязвим для этого типа атак.

Вы также должны настроить веб-сервер, который находится перед Django, для проверки хоста. Он должен отвечать статической страницей ошибки или игнорировать запросы на неправильные хосты, вместо того, чтобы пересылать запрос Django. Таким образом, вы избежите ложных ошибок в ваших журналах Django (или электронных письмах, если у вас настроена обработка ошибок таким образом). Например, в nginx вы можете настроить сервер по умолчанию для возвращения «444 Нет ответа» при неизвестном хосте:

server {
    listen 80 default_server;
    return 444;
}

CACHES

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

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

Если вы используете Memcached, рассмотрите возможность использования кэшированных сессий для повышения производительности.

DATABASES

Параметры подключения к базе данных, вероятно, отличаются в среде разработки и в рабочей среде.

Пароли баз данных очень чувствительны. Вы должны защищать их точно так же, как SECRET_KEY.

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

Если вы ещё не настроили резервное копирование базы данных, сделайте это прямо сейчас!

EMAIL_BACKEND и связанные настройки

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

По умолчанию Django отправляет электронные письма с адресов webmaster@localhost и root@localhost. Однако некоторые поставщики почты отклоняют электронные письма с этих адресов. Чтобы использовать другие адреса отправителя, измените настройки DEFAULT_FROM_EMAIL и SERVER_EMAIL.

STATIC_ROOT и STATIC_URL

Статические файлы автоматически обслуживаются сервером разработки. В рабочей среде вы должны определить директорию STATIC_ROOT, куда collectstatic скопирует их.

См. Управление статическими файлами (например, изображениями, JavaScript, CSS) для получения дополнительной информации.

MEDIA_ROOT и MEDIA_URL

Файлы медиа загружаются пользователями. Они ненадёжные! Убедитесь, что ваш веб-сервер никогда не пытается их интерпретировать. Например, если пользователь загрузит .php файл, веб-сервер не должен его выполнять.

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

HTTPS

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

Защита таких чувствительных областей, как учётная запись пользователя или админ-панель, недостаточно, потому что cookie сессии используются для HTTP и HTTPS. Ваш веб-сервер должен перенаправлять весь HTTP-трафик на HTTPS и только передавать HTTPS-запросы Django.

После настройки HTTPS включите следующие настройки.

CSRF_COOKIE_SECURE

Установите это значение в True, чтобы случайно не передать cookie CSRF по HTTP.

SESSION_COOKIE_SECURE

Установите это значение в True, чтобы случайно не передать cookie сессии по HTTP.

Оптимизация производительности

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

CONN_MAX_AGE

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

Это очень полезно на виртуализированных хостах с ограниченной производительностью сети.

TEMPLATES

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

Обработка ошибок

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

LOGGING

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

См. Логгирование для получения подробной информации о логгировании.

ADMINS и MANAGERS

ADMINS будут получать уведомления об ошибках 500 по электронной почте.

MANAGERS будут получать уведомления об ошибках 404. IGNORABLE_404_URLS может помочь отфильтровать ложные сообщения.

См. Обработка ошибок для получения подробной информации об отправке сообщений об ошибках по электронной почте.

Отчёт об ошибках по электронной почте не масштабируется

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

Настройка стандартных представлений об ошибках

Django включает стандартные представления и шаблоны для нескольких кодов HTTP-ошибок. Вы можете переопределить стандартные шаблоны, создав следующие шаблоны в вашем корневом каталоге шаблонов: 404.html, 500.html, 403.html, и 400.html. Стандартные представления подойдут для 99% веб-приложений, но если вы хотите их настроить, см. эти инструкции, в которых также содержатся подробности о стандартных шаблонах:

  • Представление 404 (страница не найдена)
  • Представление 500 (ошибка сервера)
  • Представление 403 (запрещено)
  • Представление 400 (неверный запрос)

Параметры Python

Сильно рекомендуется запускать процесс Python, выполняющий ваше Django-приложение, с параметром -R или с переменной окружения PYTHONHASHSEED, установленной в значение random. Этот параметр включён по умолчанию начиная с Python 3.3.

Эти параметры помогают защитить ваш сайт от атак типа «отказ в обслуживании» (DoS), вызванных тщательно разработанными входными данными. Такая атака может значительно увеличить использование ЦП, вызывая худшие показатели производительности при создании dict экземпляров. См. консультацию oCERT #2011-003 для получения дополнительной информации.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.9/howto/deployment/checklist/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API