デプロイチェックリスト¶
The internet is a hostile environment. Before deploying your Django project, you should take some time to review your settings, with security, performance, and operations in mind.
Django には多くの セキュリティ機能 があります。いくつかはビルトインで、常に有効です。その他は任意となっており、これは常に適切とは限らなかったり、開発に対しては不便だったりするためです。たとえば、HTTPS を強制することは、すべてのウェブサイトに対して適切とは言えず、またローカル開発では実践的ではありません。
パフォーマンスの最適化は、利便性とのトレードオフとなるもう 1 つの要素です。たとえば、キャッシングは本番環境では役立ちますが、ローカル開発では役立ちません。同様に、エラーレポートの必要性にも大きな違いがあります。
以下のチェックリストは、次の設定項目を含みます:
- 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()
If rotating secret keys, you may use SECRET_KEY_FALLBACKS:
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
Ensure that old secret keys are removed from SECRET_KEY_FALLBACKS in a
timely manner.
The SECRET_KEY_FALLBACKS setting was added to support rotating secret
keys.
DEBUG¶
デバッグは、本番環境では決して有効化してはいけません。
プロジェクトの開発中は DEBUG = True だったはずですが、これはブラウザ内の全トレースバックといった便利な機能を使えるようにするためです。
しかし、本番環境に対してはこれはまったく不適切です。なぜなら、プロジェクトに関する多くの情報を公にしてしまうからです: ソースコードからの引用、ローカル変数、設定、使われているライブラリ、等。
環境に合わせた設定¶
ALLOWED_HOSTS¶
DEBUG = False のとき、ALLOWED_HOSTS が適切に設定されない限り Django は一切動作しません。
この設定は、いくつかの CSRF 攻撃からあなたのサイトを保護するために必要です。もしワイルドカードを使用した場合、Host HTTP のバリデーションを自分自身で行う必要があります。さもなければ、この種の攻撃に脆弱なサイトとなってしまいます。
加えて、Django の手前にいるウェブサーバーにも、ホストを検証するよう設定をする必要があります。これにより、不適切なホストに対して、Django にリクエストを転送する代わりに、エラーページを表示したりリクエストを無視するようにできます。そして、Django のログ内で誤ったエラーが起きる (もしくは設定しだいでは E メールが送信される) のを防ぎます。たとえば、nginx では認識されないホストに対してデフォルトサーバーが "444 No Response" を返します:
server {
listen 80 default_server;
return 444;
}
CACHES¶
もしキャッシュを使うなら、開発環境と本番環境とでコネクションパラメータは異なるでしょう。そうでない場合、デフォルトはref:local-memory-caching`のper-process に設定されています。
キャッシュサーバーは認証に弱点を持っています。あなたのアプリケーションからのコネクションだけを受け入れるようにしてください。
DATABASES¶
データベースの接続パラメータは、開発環境と本番環境でおそらく異なります。
データベースパスワードは非常に機密的なものです。SECRET_KEY と同様の方法で保護してください。
セキュリティを最大化するために、データベースサーバーがあなたのアプリからの未接続を受け入れるようにしてください。
もしデータベースのバックアップの設定をしていなければ、今すぐに行ってください!
STATIC_ROOT と STATIC_URL¶
静的ファイルは、開発用サーバーでは自動的に提供されます。本番環境では、collectstatic が静的ファイルをコピーする STATIC_ROOT ディレクトリを設定する必要があります。
より詳しくは 静的ファイル (画像、JavaScript、CSS など) を管理する を参照してください。
MEDIA_ROOT と MEDIA_URL¶
メディアファイルは、あなたのユーザーによってアップロードされます。彼らは信用なりません! ウェブサーバーが決してこれらを解読しようとしないようにしてください。たとえば、ユーザーが .php ファイルをアップロードしたとき、ウェブサーバーはその内容を実行するべきではありません。
この機会に、こうしたファイルに対するバックアップ戦略をチェックしておきましょう。
HTTPS¶
ユーザーにログインさせるあらゆるウェブサイトは、アクセストークンを平文で送信するのを防ぐため、サイト全体の HTTPS を強制するべきです。Django では、アクセストークンはログインとパスワード、セッションクッキー、パスワードリセットトークンを含みます。(パスワードリセットトークンを E メール送信する場合、それほど保護されてはいません。)
ユーザーアカウントやアドミンといった機密領域を保護するだけでは十分ではありません。同じセッションクッキーが HTTP や HTTPS に使われるからです。ウェブサーバーはすべての HTTP トラフィックを HTTPS にリダイレクトし、Django には HTTPS リクエストのみが送信されなければなりません。
一度 HTTPS をセットアップしたら、以下の設定項目が有効になります。
CSRF_COOKIE_SECURE¶
誤って HTTP によって CSRF クッキーを送信してしまうのを防ぐには、True をセットしてください。
SESSION_COOKIE_SECURE¶
誤って HTTP によってセッションクッキーを送信してしまうのを防ぐには、True をセットしてください。
パフォーマンスの最適化¶
DEBUG = False をセットすることで、開発向けの複数の機能が無効化されます。加えて、以下の設定をチューンすることもできます。
セッション¶
Consider using cached sessions to improve performance.
If using database-backed sessions, regularly clear old sessions to avoid storing unnecessary data.
CONN_MAX_AGE¶
永続的なデータベース接続 を有効化すると、リクエストのプロセス時間の多くの部分に対するデータベースアカウントへの接続において、高速になります。
限られたネットワーク性能の仮想化ホストにおいて、とても効果的です。
TEMPLATES¶
Enabling the cached template loader often improves performance drastically, as
it avoids compiling each template every time it needs to be rendered. When
DEBUG = False, the cached template loader is enabled
automatically. See django.template.loaders.cached.Loader for more
information.
エラーのレポート¶
あなたの書いたコードを本番環境に送信するまでは、頑強であることが望まれますが、予期しないエラーを除外することはできません。ありがたいことに、Django はエラーをキャッチして適切にお知らせします。
LOGGING¶
本番環境に置く前に、ロギング設定を見直しましょう。また、トラフィックを受け取ったらすぐにそれらが想定通り動作していることを確認してください。
ロギングに関する詳細は ロギング を参照してください。
ADMINS と MANAGERS¶
ADMINS は、500 エラーの通知を E メールで受け取ります。
MANAGERS は、404 エラーの通知を受け取ります。IGNORABLE_404_URLS により不要なレポートをフィルタリングできます。
E メールによるエラーレポートの詳細は、エラーレポートの管理 を参照してください。
E メールによるエラーレポートはスケールしない
あなたの受信箱がレポートであふれかえる前に、Sentry などのエラーモニタリングツールの導入を検討してください。Sentry もログを集計することができます。
デフォルトのエラービューをカスタムする¶
Django には、いくつかの HTTP に対して、デフォルトのビューとテンプレートが用意してあります。ルートのテンプレートディレクトリに以下のテンプレートを作成することで、独自のテンプレートに置き換えることができます: 404.html, 500.html, 403.html, and 400.html 。99％のWebアプリケーションは、これらのテンプレートを使用した デフォルトのエラービュー で事足りるはずですが、 これらをカスタマイズする こともできます。
