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

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

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

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

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

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