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

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

Вы также должны настроить веб-сервер, который находится перед 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% веб-приложений, но вы также можете настроить их.