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

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

При смене ключей секретности вы можете использовать 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 чтобы случайно не передавать куки CSRF по HTTP.

SESSION_COOKIE_SECURE

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