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

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

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

Оптимизация производительности — это еще одна категория компромиссов с удобством. Например, кэширование полезно в производственной среде, но менее полезно для локальной разработки. Требования к отчетности об ошибках также сильно различаются.

Следующий список проверок включает настройки, которые:

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

Многие из этих настроек являются конфиденциальными и должны рассматриваться как секретные. Если вы публикуете исходный код своего проекта, распространённая практика — опубликовать подходящие настройки для разработки и использовать отдельный модуль настроек для производственной среды.

Запуск manage.py check --deploy

Некоторые из проверок, описанных ниже, можно автоматизировать, используя опцию --deploy команды check. Не забудьте запустить его с файлом настроек вашей производственной среды, как описано в документации к этой опции.

Критические настройки

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

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

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

Если вы используете 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 (HTTP Запрещено)
• Представление 400 (неверный запрос)

Параметры Python

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

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