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

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

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

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