The internet is a hostile environment. Before deploying your Django project,\nyou should take some time to review your settings, with security, performance,\nand operations in mind.
\nDjango には多くの セキュリティ機能 があります。いくつかはビルトインで、常に有効です。その他は任意となっており、これは常に適切とは限らなかったり、開発に対しては不便だったりするためです。たとえば、HTTPS を強制することは、すべてのウェブサイトに対して適切とは言えず、またローカル開発では実践的ではありません。
\nパフォーマンスの最適化は、利便性とのトレードオフとなるもう 1 つの要素です。たとえば、キャッシングは本番環境では役立ちますが、ローカル開発では役立ちません。同様に、エラーレポートの必要性にも大きな違いがあります。
\n以下のチェックリストは、次の設定項目を含みます:
\nDjango が想定したレベルのセキュリティを提供するために適切にセットされる必要があるもの;
各環境で異なると予期されるもの;
オプションのセキュリティ機能を有効にするもの;
パフォーマンスの最適化を有効にするもの;
エラーレポートを提供するもの;
これらの設定の多くは秘匿的で、機密的に扱う必要があります。プロジェクトに対してソースコードをリリースする場合、一般的な方法は、開発に適した設定を公開し、本番用のプライベートな設定モジュールを使うことです。
\nmanage.py check --deploy を実施しようLink to this heading#以下で説明しているチェックのいくつかは、check --deploy オプションを使用して自動化できます。オプションのドキュメントで説明しているとおり、本番環境の設定に対してこのチェックを実施してください。
SECRET_KEYLink to this heading#シークレットキーは、長いランダム文字列で、秘匿される必要があります。
\n本番環境で使われるキーは、他の場所で使われておらず、ソースコントロール中に記述してしまわないよう十分注意してください。これにより、攻撃者がキーを取得してしまう恐れを軽減できます。
\n設定モジュールにシークレットキーを直接書き込む代わりに、環境変数から読み込む方法を検討してください:
\nimport os\nSECRET_KEY = os.environ['SECRET_KEY']\nもしくはファイルから読み込みます:
\nwith open('/etc/secret_key.txt') as f:\n SECRET_KEY = f.read().strip()\nDEBUGLink to this heading#デバッグは、本番環境では決して有効化してはいけません。
\nプロジェクトの開発中は DEBUG = True だったはずですが、これはブラウザ内の全トレースバックといった便利な機能を使えるようにするためです。
しかし、本番環境に対してはこれはまったく不適切です。なぜなら、プロジェクトに関する多くの情報を公にしてしまうからです: ソースコードからの引用、ローカル変数、設定、使われているライブラリ、等。
\nALLOWED_HOSTSLink to this heading#DEBUG = False のとき、ALLOWED_HOSTS が適切に設定されない限り Django は一切動作しません。
この設定は、いくつかの CSRF 攻撃からあなたのサイトを保護するために必要です。もしワイルドカードを使用した場合、Host HTTP のバリデーションを自分自身で行う必要があります。さもなければ、この種の攻撃に脆弱なサイトとなってしまいます。
You should also configure the web server that sits in front of Django to\nvalidate the host. It should respond with a static error page or ignore\nrequests for incorrect hosts instead of forwarding the request to Django. This\nway you'll avoid spurious errors in your Django logs (or emails if you have\nerror reporting configured that way). For example, on nginx you might set up a\ndefault server to return "444 No Response" on an unrecognized host:
\nserver {\n listen 80 default_server;\n return 444;\n}\nCACHESLink to this heading#もしキャッシュを使うなら、開発環境と本番環境とでコネクションパラメータは異なるでしょう。そうでない場合、デフォルトはref:local-memory-caching`のper-process に設定されています。
\nキャッシュサーバーは認証に弱点を持っています。あなたのアプリケーションからのコネクションだけを受け入れるようにしてください。
\nDATABASESLink to this heading#データベースの接続パラメータは、開発環境と本番環境でおそらく異なります。
\nデータベースパスワードは非常に機密的なものです。SECRET_KEY と同様の方法で保護してください。
セキュリティを最大化するために、データベースサーバーがあなたのアプリからの未接続を受け入れるようにしてください。
\nもしデータベースのバックアップの設定をしていなければ、今すぐに行ってください!
\nSTATIC_ROOT と STATIC_URLLink to this heading#静的ファイルは、開発用サーバーでは自動的に提供されます。本番環境では、collectstatic が静的ファイルをコピーする STATIC_ROOT ディレクトリを設定する必要があります。
より詳しくは How to manage static files (e.g. images, JavaScript, CSS) を参照してください。
\nMEDIA_ROOT と MEDIA_URLLink to this heading#メディアファイルは、あなたのユーザーによってアップロードされます。彼らは信用なりません! ウェブサーバーが決してこれらを解読しようとしないようにしてください。たとえば、ユーザーが .php ファイルをアップロードしたとき、ウェブサーバーはその内容を実行するべきではありません。
この機会に、こうしたファイルに対するバックアップ戦略をチェックしておきましょう。
\nユーザーにログインさせるあらゆるウェブサイトは、アクセストークンを平文で送信するのを防ぐため、サイト全体の HTTPS を強制するべきです。Django では、アクセストークンはログインとパスワード、セッションクッキー、パスワードリセットトークンを含みます。(パスワードリセットトークンを E メール送信する場合、それほど保護されてはいません。)
\nユーザーアカウントやアドミンといった機密領域を保護するだけでは十分ではありません。同じセッションクッキーが HTTP や HTTPS に使われるからです。ウェブサーバーはすべての HTTP トラフィックを HTTPS にリダイレクトし、Django には HTTPS リクエストのみが送信されなければなりません。
\n一度 HTTPS をセットアップしたら、以下の設定項目が有効になります。
\n\n\nDEBUG = False をセットすることで、開発向けの複数の機能が無効化されます。加えて、以下の設定をチューンすることもできます。
Consider using cached sessions to improve\nperformance.
\nIf using database-backed sessions, regularly clear old sessions to avoid storing unnecessary data.
\nCONN_MAX_AGELink to this heading#永続的なデータベース接続 を有効化すると、リクエストのプロセス時間の多くの部分に対するデータベースアカウントへの接続において、高速になります。
\n限られたネットワーク性能の仮想化ホストにおいて、とても効果的です。
\nTEMPLATESLink to this heading#Enabling the cached template loader often improves performance drastically, as\nit avoids compiling each template every time it needs to be rendered. When\nDEBUG = False, the cached template loader is enabled\nautomatically. See django.template.loaders.cached.Loader for more\ninformation.
あなたの書いたコードを本番環境に送信するまでは、頑強であることが望まれますが、予期しないエラーを除外することはできません。ありがたいことに、Django はエラーをキャッチして適切にお知らせします。
\nLOGGINGLink to this heading#本番環境に置く前に、ロギング設定を見直しましょう。また、トラフィックを受け取ったらすぐにそれらが想定通り動作していることを確認してください。
\nロギングに関する詳細は ロギング を参照してください。
\nADMINS と MANAGERSLink to this heading#ADMINS は、500 エラーの通知を E メールで受け取ります。
MANAGERS は、404 エラーの通知を受け取ります。IGNORABLE_404_URLS により不要なレポートをフィルタリングできます。
E メールによるエラーレポートの詳細は、How to manage error reporting を参照してください。
\n\nDjango includes default views and templates for several HTTP error codes. You\nmay want to override the default templates by creating the following templates\nin your root template directory: 404.html, 500.html, 403.html, and\n400.html. The default error views that use these\ntemplates should suffice for 99% of web applications, but you can\ncustomize them as well.