План развертывания

Интернет — враждебная среда. Перед развертыванием вашего проекта 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()

Если требуется обновление ключей секретности, вы можете использовать SECRET_KEY_FALLBACKS:

import os
SECRET_KEY = os.environ['CURRENT_SECRET_KEY']
SECRET_KEY_FALLBACKS = [
    os.environ['OLD_SECRET_KEY'],
]

Обеспечьте своевременное удаление старых ключей секретности из SECRET_KEY_FALLBACKS.

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

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

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

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 токены доступа включают логин/пароль, куки сессии и токены сброса пароля. (Вы не сможете много сделать для защиты токенов сброса пароля, если вы отправляете их по электронной почте.)

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

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

CSRF_COOKIE_SECURE

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

SESSION_COOKIE_SECURE

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

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

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

Сессии

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

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

CONN_MAX_AGE

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

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

TEMPLATES

Включение кэшированного загрузчика шаблонов часто значительно улучшает производительность, так как позволяет избежать компиляции каждого шаблона каждый раз, когда он должен быть рендерирован. Когда DEBUG = False, кэшированный загрузчик шаблонов включается автоматически. См. django.template.loaders.cached.Loader для получения дополнительной информации.

Отчеты об ошибках

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

LOGGING

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

Подробные сведения о ведении журнала см. в разделе Ведение журнала.

ADMINS и MANAGERS

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

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

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

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

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