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

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

Django включает в себя множество security features. Некоторые из них встроены и всегда включены. Другие являются необязательными, потому что они не всегда уместны или неудобны для разработки. Например, принудительное использование 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.

Changed in Django 4.1:

Настройка SECRET_KEY_FALLBACKS была добавлена для поддержки вращающихся секретных ключей.

DEBUG

Вы никогда не должны включать отладку в production.

Вы наверняка разрабатываете свой проект с 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 по умолчанию устанавливает per-process local-memory caching, что может быть нежелательно.

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

DATABASES

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

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

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

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

STATIC_ROOT и STATIC_URL

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

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

MEDIA_ROOT и MEDIA_URL

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

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

HTTPS

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

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

После того как вы настроите HTTPS, включите следующие параметры.

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

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

Сессии

Рассмотрите возможность использования cached sessions для повышения производительности.

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

CONN_MAX_AGE

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

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

TEMPLATES

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

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

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

LOGGING

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

Подробнее о протоколировании см. в разделе Ведение журнала.

ADMINS и MANAGERS

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

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

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

Сообщения об ошибках по электронной почте не очень хорошо масштабируются

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

Настройка представлений ошибок по умолчанию

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

Как использовать Django с Uvicorn
Как обновить Django до более новой версии
Вернуться на верх