Контрольный список развертывания

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. Если вы используете подстановочный знак, необходимо самостоятельно проверять HTTP-заголовок Host или иным способом убедиться, что вы не уязвимы к этому типу атак.

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

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, веб-сервер не должен его выполнять.

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

CSRF_COOKIE_SECURE

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

SESSION_COOKIE_SECURE

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

Сеансы

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

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

CONN_MAX_AGE

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

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

TEMPLATES

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

LOGGING

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

Подробную информацию о журналировании см. в разделе Журналирование.

ADMINS и MANAGERS

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

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

Подробную информацию об отправке отчетов об ошибках по электронной почте см. в разделе Управление отчетами об ошибках.

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

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