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

Интернет — враждебная среда. Перед развертыванием вашего проекта 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 (HTTP Запрещено)
• Представление 400 (ошибка запроса)