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

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

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

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

В следующем списке проверок содержатся настройки, которые:

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

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

Выполнить manage.py check --deploy

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

Перейти от manage.py runserver

Команда runserver не предназначена для рабочей среды. Обязательно переключитесь на сервер WSGI или ASGI, предназначенный для рабочей среды. Примеры таких серверов можно найти в документации по серверам WSGI или документации по серверам ASGI.

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

SECRET_KEY

Ключ секретности должен быть большим случайным значением и храниться в секрете.

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

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

import os

SECRET_KEY = os.environ["SECRET_KEY"]

или из файла:

with open("/etc/secret_key.txt") as f:
    SECRET_KEY = f.read().strip()

При вращении ключей секретности вы можете использовать SECRET_KEY_FALLBACKS:

import os

SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
    os.environ["OLD_SECRET_KEY"],
]

Убедитесь, что старые ключи секретности удаляются из SECRET_KEY_FALLBACKS своевременно.

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

Включение кэшированного загрузчика шаблонов часто значительно улучшает производительность, так как он предотвращает компиляцию каждого шаблона каждый раз, когда он должен быть отрисован. Когда DEBUG = False включен, кэшированный загрузчик шаблонов включается автоматически. Дополнительную информацию см. в django.template.loaders.cached.Loader.

Обработка ошибок

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

LOGGING

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

См. Ведение журнала для получения подробной информации о ведении журнала.

ADMINS и MANAGERS

ADMINS будут уведомлены об ошибках 500 по электронной почте.

MANAGERS будут уведомлены об ошибках 404. IGNORABLE_404_URLS может помочь отфильтровать ложные сообщения.

См. Как управлять обработкой ошибок для получения подробной информации о обработке ошибок по электронной почте.

Настроить стандартные представления ошибок

Django включает стандартные представления и шаблоны для нескольких кодов ошибок HTTP. Вы можете переопределить стандартные шаблоны, создав следующие шаблоны в корневом каталоге шаблонов: 404.html, 500.html, 403.html, и 400.html. Стандартные представления ошибок, которые используют эти шаблоны, должны быть достаточными для 99% веб-приложений, но вы также можете настроить их.