План развертывания

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

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

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

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

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

FILE_UPLOAD_PERMISSIONS

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

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

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