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

The internet is a hostile environment. Before deploying your Django project, you should take some time to review your settings, with security, performance, and operations in mind.

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 Development version:

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

DEBUG

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

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

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

Настройки для конкретной среды

ALLOWED_HOSTS

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

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

You should also configure the web server that sits in front of Django to validate the host. It should respond with a static error page or ignore requests for incorrect hosts instead of forwarding the request to Django. This way you’ll avoid spurious errors in your Django logs (or emails if you have error reporting configured that way). For example, on nginx you might set up a default server to return «444 No Response» on an unrecognized host:

server {
    listen 80 default_server;
    return 444;
}

CACHES

Если вы используете кэш, параметры подключения могут быть разными в разработке и в продакшене. Django по умолчанию устанавливает per-process local-memory caching, что может быть нежелательно.

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

DATABASES

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

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

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

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

STATIC_ROOT и STATIC_URL.

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

Дополнительную информацию см. в разделе How to manage static files (e.g. images, 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

Enabling the cached template loader often improves performance drastically, as it avoids compiling each template every time it needs to be rendered. When DEBUG = False, the cached template loader is enabled automatically. See django.template.loaders.cached.Loader for more information.

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

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

LOGGING

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

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

ADMINS и MANAGERS.

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

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

Подробную информацию о сообщении об ошибках по электронной почте см. в разделе How to manage error reporting.

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

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

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

Django includes default views and templates for several HTTP error codes. You may want to override the default templates by creating the following templates in your root template directory: 404.html, 500.html, 403.html, and 400.html. The default error views that use these templates should suffice for 99% of web applications, but you can customize them as well.

Как использовать Django с Uvicorn
How to upgrade Django to a newer version
Вернуться на верх