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

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