インターネットは敵意ある環境です。あなたの Django プロジェクトをデプロイする前に、セキュリティ、パフォーマンスおよびオペレーションに関する設定を一通り見直す時間を取ってください。
\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 のバリデーションを自分自身で行う必要があります。さもなければ、この種の攻撃に脆弱なサイトとなってしまいます。
加えて、Django の手前にいるウェブサーバーにも、ホストを検証するよう設定をする必要があります。これにより、不適切なホストに対して、Django にリクエストを転送する代わりに、エラーページを表示したりリクエストを無視するようにできます。そして、Django のログ内で誤ったエラーが起きる (もしくは設定しだいでは E メールが送信される) のを防ぎます。たとえば、nginx では認識されないホストに対してデフォルトサーバーが "444 No Response" を返します:
\nserver {\n listen 80 default_server;\n return 444;\n}\nCACHESLink to this heading#もしキャッシュを使うなら、開発環境と本番環境とでコネクションパラメータは異なるでしょう。そうでない場合、デフォルトはref:`local-memory-caching`のper-processに設定されています。
\nキャッシュサーバーは認証に弱点を持っています。あなたのアプリケーションからのコネクションだけを受け入れるようにしてください。
\nもしあなたがMemcachedを使うなら、より性能を向上させるために cached sessions を使うことも検討してください。
\nDATABASESLink to this heading#データベースの接続パラメータは、開発環境と本番環境でおそらく異なります。
\nデータベースパスワードは非常に機密的なものです。SECRET_KEY と同様の方法で保護してください。
セキュリティを最大化するために、データベースサーバーがあなたのアプリからの未接続を受け入れるようにしてください。
\nもしデータベースのバックアップの設定をしていなければ、今すぐに行ってください!
\nSTATIC_ROOT と STATIC_URLLink to this heading#静的ファイルは、開発用サーバーでは自動的に提供されます。本番環境では、collectstatic が静的ファイルをコピーする STATIC_ROOT ディレクトリを設定する必要があります。
より詳しくは 静的ファイル (画像、JavaScript、CSS など) を管理する を参照してください。
\nMEDIA_ROOT と MEDIA_URLLink to this heading#メディアファイルは、あなたのユーザーによってアップロードされます。彼らは信用なりません! ウェブサーバーが決してこれらを解読しようとしないようにしてください。たとえば、ユーザーが .php ファイルをアップロードしたとき、ウェブサーバーはその内容を実行するべきではありません。
この機会に、こうしたファイルに対するバックアップ戦略をチェックしておきましょう。
\nFILE_UPLOAD_PERMISSIONSLink to this heading#With the default file upload settings, files smaller than\nFILE_UPLOAD_MAX_MEMORY_SIZE may be stored with a different mode\nthan larger files as described in FILE_UPLOAD_PERMISSIONS.
Setting FILE_UPLOAD_PERMISSIONS ensures all files are uploaded with\nthe same permissions.
ユーザーにログインさせるあらゆるウェブサイトは、アクセストークンを平文で送信するのを防ぐため、サイト全体の HTTPS を強制するべきです。Django では、アクセストークンはログインとパスワード、セッションクッキー、パスワードリセットトークンを含みます。(パスワードリセットトークンを E メール送信する場合、それほど保護されてはいません。)
\nユーザーアカウントやアドミンといった機密領域を保護するだけでは十分ではありません。同じセッションクッキーが HTTP や HTTPS に使われるからです。ウェブサーバーはすべての HTTP トラフィックを HTTPS にリダイレクトし、Django には HTTPS リクエストのみが送信されなければなりません。
\n一度 HTTPS をセットアップしたら、以下の設定項目が有効になります。
\n\n\nDEBUG = False をセットすることで、開発向けの複数の機能が無効化されます。加えて、以下の設定をチューンすることもできます。
CONN_MAX_AGELink to this heading#永続的なデータベース接続 を有効化すると、リクエストのプロセス時間の多くの部分に対するデータベースアカウントへの接続において、高速になります。
\n限られたネットワーク性能の仮想化ホストにおいて、とても効果的です。
\nTEMPLATESLink to this heading#キャッシュされたテンプレートローダーを有効化すると、描画のたびにテンプレートを変換しなくなるので、しばしばパフォーマンスを劇的に改善します。詳しくは テンプレートローダーのドキュメント を参照してください。
\nあなたの書いたコードを本番環境に送信するまでは、頑強であることが望まれますが、予期しないエラーを除外することはできません。ありがたいことに、Django はエラーをキャッチして適切にお知らせします。
\nLOGGINGLink to this heading#本番環境に置く前に、ロギング設定を見直しましょう。また、トラフィックを受け取ったらすぐにそれらが想定通り動作していることを確認してください。
\nロギングに関する詳細は ロギング を参照してください。
\nADMINS と MANAGERSLink to this heading#ADMINS は、500 エラーの通知を E メールで受け取ります。
MANAGERS は、404 エラーの通知を受け取ります。IGNORABLE_404_URLS により不要なレポートをフィルタリングできます。
E メールによるエラーレポートの詳細は、エラーのレポート を参照してください。
\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.