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 つの要素です。たとえば、キャッシングは本番環境では役立ちますが、ローカル開発では役立ちません。同様に、エラーレポートの必要性にも大きな違いがあります。
以下のチェックリストは、次の設定項目を含みます:
これらの設定の多くは秘匿的で、機密的に扱う必要があります。プロジェクトに対してソースコードをリリースする場合、一般的な方法は、開発に適した設定を公開し、本番用のプライベートな設定モジュールを使うことです。
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 を強制するべきです。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 メールによるエラーレポートの詳細は、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.
2022年6月01日