デプロイチェックリスト

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()

DEBUG

デバッグは、本番環境では決して有効化してはいけません。

プロジェクトの開発中は DEBUG = True だったはずですが、これはブラウザ内の全トレースバックといった便利な機能を使えるようにするためです。

しかし、本番環境に対してはこれはまったく不適切です。なぜなら、プロジェクトに関する多くの情報を公にしてしまうからです: ソースコードからの引用、ローカル変数、設定、使われているライブラリ、等。

環境に合わせた設定

ALLOWED_HOSTS

DEBUG = False のとき、ALLOWED_HOSTS が適切に設定されない限り Django は一切動作しません。

この設定は、いくつかの CSRF 攻撃からあなたのサイトを保護するために必要です。もしワイルドカードを使用した場合、Host HTTP のバリデーションを自分自身で行う必要があります。さもなければ、この種の攻撃に脆弱なサイトとなってしまいます。

You should also configure the web server that sits in front of Django to validate the host. It should respond with a static error page or ignore requests for incorrect hosts instead of forwarding the request to Django. This way you'll avoid spurious errors in your Django logs (or emails if you have error reporting configured that way). For example, on nginx you might set up a default server to return "444 No Response" on an unrecognized host:

server {
    listen 80 default_server;
    return 444;
}

CACHES

もしキャッシュを使うなら、開発環境と本番環境とでコネクションパラメータは異なるでしょう。そうでない場合、デフォルトはref:local-memory-caching`のper-process に設定されています。

キャッシュサーバーは認証に弱点を持っています。あなたのアプリケーションからのコネクションだけを受け入れるようにしてください。

DATABASES

データベースの接続パラメータは、開発環境と本番環境でおそらく異なります。

データベースパスワードは非常に機密的なものです。SECRET_KEY と同様の方法で保護してください。

セキュリティを最大化するために、データベースサーバーがあなたのアプリからの未接続を受け入れるようにしてください。

もしデータベースのバックアップの設定をしていなければ、今すぐに行ってください!

STATIC_ROOT と STATIC_URL

静的ファイルは、開発用サーバーでは自動的に提供されます。本番環境では、collectstatic が静的ファイルをコピーする STATIC_ROOT ディレクトリを設定する必要があります。

より詳しくは How to manage static files (e.g. images, JavaScript, CSS) を参照してください。

MEDIA_ROOT と MEDIA_URL

メディアファイルは、あなたのユーザーによってアップロードされます。彼らは信用なりません! ウェブサーバーが決してこれらを解読しようとしないようにしてください。たとえば、ユーザーが .php ファイルをアップロードしたとき、ウェブサーバーはその内容を実行するべきではありません。

この機会に、こうしたファイルに対するバックアップ戦略をチェックしておきましょう。

HTTPS

ユーザーにログインさせるあらゆるウェブサイトは、アクセストークンを平文で送信するのを防ぐため、サイト全体の HTTPS を強制するべきです。Django では、アクセストークンはログインとパスワード、セッションクッキー、パスワードリセットトークンを含みます。(パスワードリセットトークンを E メール送信する場合、それほど保護されてはいません。)

ユーザーアカウントやアドミンといった機密領域を保護するだけでは十分ではありません。同じセッションクッキーが HTTP や HTTPS に使われるからです。ウェブサーバーはすべての HTTP トラフィックを HTTPS にリダイレクトし、Django には HTTPS リクエストのみが送信されなければなりません。

一度 HTTPS をセットアップしたら、以下の設定項目が有効になります。

パフォーマンスの最適化

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 メールによるエラーレポートの詳細は、How to manage error reporting を参照してください。

E メールによるエラーレポートはスケールしない

あなたの受信箱がレポートであふれかえる前に、Sentry などのエラーモニタリングツールの導入を検討してください。Sentry もログを集計することができます。

デフォルトのエラービューをカスタムする

Django includes default views and templates for several HTTP error codes. You may want to override the default templates by creating the following templates in your root template directory: 404.html, 500.html, 403.html, and 400.html. The default error views that use these templates should suffice for 99% of web applications, but you can customize them as well.

« previous | up | next »