Контрольный список развертывания ¶
Интернет - враждебная среда. Перед развертыванием проекта Django рекомендуется потратить некоторое время на просмотр настроек с учетом безопасности, производительности и операций.
Django содержит множество функций, связанных с безопасностью . Некоторые из них интегрированы и все еще действуют. Другие необязательны, потому что они не всегда адекватны или не подходят во время разработки. Например, использование исключительно HTTPS подходит не для всех веб-сайтов, и это нереально при локальной разработке.
Еще одна категория компромиссов между эффективностью и удобством - это оптимизация производительности. Например, использование кеширования полезно в производственной среде, а не в локальной разработке. Потребности в сообщениях об ошибках также очень разные.
Следующий контрольный список содержит настройки, которые:
- должны быть правильно настроены, чтобы Django мог гарантировать ожидаемый уровень безопасности;
- обычно различаются в зависимости от среды;
- активировать дополнительные функции безопасности;
- активировать оптимизацию производительности;
- позаботьтесь об отчетах об ошибках.
Многие из этих настроек являются конфиденциальными, и с ними следует обращаться конфиденциально. Если вы выпускаете исходный код для своего проекта, обычно публикуют настройки, подходящие для разработки, но используют модуль частных настроек, предназначенный для производства.
Запуск ¶manage.py check --deploy
Некоторые из элементов управления, показанных ниже, можно автоматизировать с помощью этой опции --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 '' в рабочей среде.
Вы, безусловно, будете развивать свой проект с его помощью , поскольку он предлагает очень практичные возможности, такие как подробные трассировки вызовов в вашем браузере.DEBUG = True
Однако в производственной среде это очень плохая идея, потому что она раскрывает много информации о вашем проекте: фрагменты исходного кода, локальные переменные, настройки, используемые библиотеки и т. Д.
Настройки для конкретной среды ¶
ALLOWED_HOSTS ¶
Когда Django вообще не работает без правильного значения .DEBUG = False ALLOWED_HOSTS
Этот параметр необходим для защиты вашего сайта от определенных атак CSRF. Если вы указываете подстановочный знак, вы должны выполнить проверку заголовка HTTP Host самостоятельно или иным образом убедиться, что вы не уязвимы для этой категории атак.
Это также касается настройки веб-сервера перед Django для проверки хоста. Если есть запросы с неправильными именами хостов, веб-сервер должен ответить статической страницей с ошибкой или игнорировать эти запросы вместо того, чтобы перенаправлять их в Django. Таким образом, это позволит избежать загрязнения журналов Django ошибками (или электронной почты, если вы настроили для этого отчеты об ошибках). Например, с помощью nginx можно настроить сервер так, чтобы он по умолчанию возвращал ошибку «444 No Response», если обнаруживал неизвестный хост:
server {
listen 80 default_server;
return 444;
}
CACHES ¶
Если вы используете кеш, настройки подключения могут отличаться между разработкой и производством. По умолчанию Django использует кеш локальной памяти , что не всегда является наиболее подходящим.
Кэш-серверы часто имеют слабую аутентификацию. Убедитесь, что они принимают соединения только от ваших серверов приложений.
DATABASES ¶
Параметры подключения к базе данных, вероятно, будут различаться между разработкой и производством.
Пароли базы данных очень чувствительны. Вы должны защищать их не хуже SECRET_KEY .
Для максимальной безопасности убедитесь, что серверы баз данных принимают соединения только от серверов приложений.
Если вы еще не настроили резервное копирование для своей базы данных, сделайте это сейчас!
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
Сессии ¶
Рассмотрите возможность использования кэшированных сеансов для повышения производительности.
Если вы используете сеансы, хранящиеся в базе данных, ref: регулярно удаляйте старые сеансы <clearing-the-session-store>, чтобы избежать хранения ненужных данных.
CONN_MAX_AGE ¶
Включение постоянных подключений к базе данных может значительно повысить производительность, если подключение к базе данных составляет большую часть времени обработки запроса.
Это важный плюс для виртуализированных хостов с ограниченной производительностью сети.
TEMPLATES ¶
Включение кеша загрузчика шаблонов часто значительно повышает производительность, так как позволяет избежать повторной компиляции шаблонов при их визуализации. Дополнительную информацию см. В документации по загрузчикам шаблонов .
Отчет об ошибках ¶
Когда приходит время вводить код в производство, он должен быть надежным, но вы никогда не сможете исключить неожиданные ошибки. К счастью, Django может обнаруживать ошибки и уведомлять вас.
LOGGING ¶
Проанализируйте настройки ведения журнала перед запуском веб-сайта и убедитесь, что он работает должным образом, как только приложение начинает получать трафик.
См. « Ведение журнала» для получения дополнительных сведений о ведении журнала.
ADMINS и ¶MANAGERS
Они ADMINS получают уведомление по электронной почте об ошибках типа 500.
MANAGERS Оповещается 404 ошибок. IGNORABLE_404_URLS Может помочь фильтру из несвоевременных отчетов.
См. Отчет об ошибках для получения подробной информации об отправке отчетов об ошибках по электронной почте.
Отчеты об ошибках электронной почты не подходят для большого трафика
Прежде чем вы увидите, что ваш почтовый ящик переполнен сообщениями, подумайте об использовании системы мониторинга ошибок, такой как Sentry . Sentry также может собирать журналы.
Настройка представлений ошибок по умолчанию ¶
Django включает представления по умолчанию и шаблоны для нескольких кодов ошибок HTTP. Это может быть желательно заменить шаблоны по умолчанию, создав следующий шаблон в корневом каталоге шаблона: 404.html , 500.html , 403.html и 400.html . Представления ошибок по умолчанию , в которых используются эти шаблоны, должны подходить для 99% веб-приложений, но вы также можете точно настроить их .