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

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

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

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

• Представление 404 (страница не найдена)
• Представление 500 (ошибка сервера)
• Представление 403 (Запрещено)
• Представление 400 (ошибка запроса)

Параметры Python

Сильно рекомендуется запускать процесс Python, выполняющий ваше Django-приложение, с параметром -R или с переменной окружения PYTHONHASHSEED, установленной в значение random. Этот параметр включен по умолчанию, начиная с Python 3.3.

Эти параметры помогают защитить ваш сайт от атак типа «отказ в обслуживании» (DoS), которые вызваны тщательно составленными входными данными. Такая атака может значительно увеличить использование ЦП, вызывая худшую производительность при создании dict экземпляров. Дополнительную информацию см. в консультации oCERT #2011-003.