Spec-Zone.ru › Django 1.10

План развертывания

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

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

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 может помочь отфильтровать ненужные сообщения.

См. Отчеты об ошибках для получения подробностей об отправке отчетов об ошибках по электронной почте.

Отчеты об ошибках по электронной почте не масштабируются хорошо

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

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

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

  • Представление 404 (страница не найдена)
  • Представление 500 (ошибка сервера)
  • Представление 403 (HTTP Запрещено)
  • Представление 400 (неправильный запрос)

Параметры Python

Сильно рекомендуется вызывать процесс Python, выполняющий ваше приложение Django, с параметром -R или с переменной окружения PYTHONHASHSEED, установленной в значение random. Этот параметр включён по умолчанию начиная с Python 3.3.

Эти параметры помогают защитить ваш сайт от атак типа «отказ в обслуживании» (DoS), вызванных тщательно продуманными входными данными. Такая атака может значительно увеличить использование ЦП, вызывая наихудшие показатели производительности при создании dict экземпляров. См. консультацию oCERT #2011-003 для получения дополнительной информации.

© Django Software Foundation and individual contributors
Licensed under the BSD License.
https://docs.djangoproject.com/en/1.10/howto/deployment/checklist/

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API