展開チェックリスト
インターネットは敵対的な環境です。 Djangoプロジェクトをデプロイする前に、セキュリティ、パフォーマンス、操作を念頭に置いて、設定を確認する必要があります。
Djangoには多くのセキュリティ機能が含まれています。 一部は組み込みで、常に有効になっています。 その他は、常に適切であるとは限らないため、または開発に不便であるため、オプションです。 たとえば、HTTPSを強制することは、すべてのWebサイトに適しているとは限らず、ローカル開発には実用的ではありません。
パフォーマンスの最適化は、利便性とのトレードオフのもう1つのカテゴリです。 たとえば、キャッシングは本番環境では役立ちますが、ローカル開発ではあまり役立ちません。 エラー報告のニーズも大きく異なります。
次のチェックリストには、次の設定が含まれています。
- 期待されるレベルのセキュリティを提供するには、Djangoを適切に設定する必要があります。
- 環境ごとに異なることが予想されます。
- オプションのセキュリティ機能を有効にします。
- パフォーマンスの最適化を有効にします。
- エラー報告を提供します。
これらの設定の多くは機密性が高く、機密情報として扱う必要があります。 プロジェクトのソースコードをリリースする場合、一般的な方法は、開発に適した設定を公開し、本番環境にプライベート設定モジュールを使用することです。
manage.py check --deployを実行します
以下で説明するチェックの一部は、check --deployオプションを使用して自動化できます。 オプションのドキュメントに記載されているように、必ず本番設定ファイルに対して実行してください。
重要な設定
：setting： `SECRET_KEY`
秘密鍵は大きなランダムな値である必要があり、秘密にしておく必要があります。
本番環境で使用されているキーが他の場所で使用されていないことを確認し、ソース管理にコミットしないようにしてください。 これにより、攻撃者がキーを取得する可能性のあるベクターの数が減ります。
設定モジュールに秘密鍵をハードコーディングする代わりに、環境変数から秘密鍵をロードすることを検討してください。
import os
SECRET_KEY = os.environ['SECRET_KEY']またはファイルから：
with open('/etc/secret_key.txt') as f:
SECRET_KEY = f.read().strip()：setting： `DEBUG`
本番環境ではデバッグを有効にしないでください。
あなたは確かにあなたのプロジェクトを開発しています ：setting： `DEBUG = True ` 、これにより、ブラウザで完全なトレースバックなどの便利な機能が有効になるためです。
ただし、実稼働環境の場合、これはプロジェクトに関する多くの情報（ソースコードの抜粋、ローカル変数、設定、使用されるライブラリなど）をリークするため、非常に悪い考えです。
環境固有の設定
：setting： `ALLOWED_HOSTS`
いつ ：setting： `DEBUG = False ` 、Djangoは、適切な値がないとまったく機能しません ：setting： `ALLOWED_HOSTS` 。
この設定は、一部のCSRF攻撃からサイトを保護するために必要です。 ワイルドカードを使用する場合は、Host HTTPヘッダーの独自の検証を実行するか、このカテゴリの攻撃に対して脆弱でないことを確認する必要があります。
また、ホストを検証するために、Djangoの前にあるWebサーバーを構成する必要があります。 リクエストをDjangoに転送する代わりに、静的エラーページで応答するか、不正なホストのリクエストを無視する必要があります。 このようにして、Djangoログ（またはエラーレポートがそのように構成されている場合は電子メール）での誤ったエラーを回避できます。 たとえば、nginxでは、認識されないホストで「444NoResponse」を返すようにデフォルトのサーバーを設定できます。
server {
listen 80 default_server;
return 444;
}：setting： `CACHES`
キャッシュを使用している場合、接続パラメーターは開発と本番で異なる場合があります。 Djangoはデフォルトでプロセスごとのローカルメモリキャッシングに設定されていますが、これは望ましくない場合があります。
キャッシュサーバーの認証は弱いことがよくあります。 アプリケーションサーバーからの接続のみを受け入れるようにしてください。
：setting： `データベース`
データベース接続パラメータは、おそらく開発と本番で異なります。
データベースのパスワードは非常に機密性が高くなります。 ：setting： `SECRET_KEY` とまったく同じように保護する必要があります。
最大限のセキュリティを確保するために、データベースサーバーがアプリケーションサーバーからの接続のみを受け入れるようにしてください。
データベースのバックアップをまだ設定していない場合は、今すぐ設定してください。
：setting： `STATIC_ROOT` および：setting：` STATIC_URL`
静的ファイルは、開発サーバーによって自動的に提供されます。 本番環境では、：setting： `STATIC_ROOT` ディレクトリを定義する必要があります。このディレクトリに：djadmin：` collectstatic` がコピーされます。
見る静的ファイルの管理（例： 画像、JavaScript、CSS） 詳細については。
：setting： `MEDIA_ROOT` および：setting：` MEDIA_URL`
メディアファイルはユーザーによってアップロードされます。 彼らは信頼されていません！ Webサーバーがそれらを解釈しようとしないようにしてください。 たとえば、ユーザーが.phpファイルをアップロードした場合、Webサーバーはそれを実行しないでください。
今こそ、これらのファイルのバックアップ戦略を確認する良い機会です。
HTTPS
ユーザーがログインできるWebサイトでは、アクセストークンがクリアに送信されないように、サイト全体のHTTPSを適用する必要があります。 Djangoでは、アクセストークンには、ログイン/パスワード、セッションCookie、およびパスワードリセットトークンが含まれます。 （電子メールで送信する場合、パスワードリセットトークンを保護するために多くのことを行うことはできません。）
HTTPとHTTPSに同じセッションCookieが使用されるため、ユーザーアカウントや管理者などの機密領域を保護するだけでは不十分です。 WebサーバーはすべてのHTTPトラフィックをHTTPSにリダイレクトし、HTTPSリクエストのみをDjangoに送信する必要があります。
HTTPSを設定したら、次の設定を有効にします。
パフォーマンスの最適化
設定 ：setting： `DEBUG = False ` 開発でのみ役立ついくつかの機能を無効にします。 また、以下の設定を行うことができます。
セッション
パフォーマンスを向上させるために、キャッシュセッションの使用を検討してください。
データベースに基づくセッションを使用する場合は、不要なデータが保存されないように、定期的に古いセッションをクリアしてください。
：setting： `CONN_MAX_AGE`
永続的なデータベース接続を有効にすると、リクエスト処理時間のかなりの部分をデータベースアカウントに接続するときに、優れたスピードアップが得られます。
これは、ネットワークパフォーマンスが制限されている仮想化ホストで大いに役立ちます。
：setting： `TEMPLATES`
キャッシュされたテンプレートローダーを有効にすると、レンダリングが必要になるたびに各テンプレートをコンパイルする必要がなくなるため、パフォーマンスが大幅に向上することがよくあります。 詳細については、テンプレートローダーのドキュメントを参照してください。
エラー報告
コードを本番環境にプッシュするときには、堅牢であることが望まれますが、予期しないエラーを除外することはできません。 ありがたいことに、Djangoはエラーをキャプチャし、それに応じて通知することができます。
：setting： `LOGGING`
Webサイトを本番環境に移行する前にログ設定を確認し、トラフィックを受信したらすぐに期待どおりに機能することを確認してください。
ロギングの詳細については、ロギングを参照してください。
：setting： `ADMINS` および：setting：` MANAGERS`
：setting： `ADMINS` には500件のエラーがメールで通知されます。
：setting： `MANAGERS` には404エラーが通知されます。 ：setting： `IGNORABLE_404_URLS` は、偽のレポートを除外するのに役立ちます。
電子メールによるエラー報告の詳細については、エラー報告を参照してください。
電子メールによるエラー報告はあまり拡張性がありません
受信トレイがレポートでいっぱいになる前に、 Sentry などのエラー監視システムの使用を検討してください。 Sentryはログを集約することもできます。
デフォルトのエラービューをカスタマイズする
Djangoには、いくつかのHTTPエラーコードのデフォルトのビューとテンプレートが含まれています。 ルートテンプレートディレクトリに404.html、500.html、403.html、および400.htmlのテンプレートを作成して、デフォルトのテンプレートを上書きすることもできます。 これらのテンプレートを使用するデフォルトのエラービューは、99 % o f Webアプリケーションには十分ですが、カスタマイズすることもできます。
