배포 전 체크리스트

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.

장고는 보안 기능을 많이 갖고 있습니다. 몇몇은 내장된 기능으로 항상 켜져있습니다. 다른 몇몇은 선택할 수 있는데 그 이유는 항상 보안 기능들이 적절하지 않거나 개발에 불편함을 가져올 수 있기 때문입니다. 예를 들어 강제로 HTTPS를 활성화 하는 것은 모든 웹사이트에 적합하지 않을 수도 있고, 로컬 개발환경에선 비실용적일 수도 있습니다.

성능 최적화는 편의를 위한 또다른 범주의 거래입니다. 예를 들어, 캐싱은 상용 환경에서 유용할 수 있지만 로컬 개발 환경에서는 실용적이지 않을 수 있습니다. 오류 보고의 필요성에도 큰 차이가 있습니다.

설정에 대한 체크리스트는 다음과 같습니다.

  • 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’, Django는 : 설정에 ALLOWED_HOSTS. 의 적합한 값이 없으면 전혀 작동하지 않습니다

이 설정은 일부 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`

캐시를 사용하는 경우 연결 매개 변수는 개발 및 운영에서 다를 수 있습니다. Django의 기본값은 프로세스당:ref:로컬 메모리 캐싱 1은 바람직하지 않을 수 있다.

캐시 서버의 인증확인은 약한 경우가 많습니다. 응용프로그램 서버로부터의 연결만 허용하는지 확인합니다.

:설정:`DATABASES`

데이터베이스 연결 매개 변수는 개발 및 운영에서 서로 다를 수 있습니다.

데이터베이스 암호는 매우 민감합니다. 당신은 SECRET_KEY.을 똑같이 보호해야 한다.

보안을 최대화하려면 데이터베이스 서버가 응용프로그램 서버의 연결만 허용해야 합니다.

데이터베이스에 대한 백업을 설정하지 않은 경우 지금 바로 수행하십시오!

:설정:`STATIC_ROOT`  그리고 :설정:`STATIC_URL`

정적 파일은 개발 서버에서 자동으로 제공됩니다. 프로덕션에서 :seting:’를 정의해야 합니다.STATIC_ROOT’ 디렉토리. 여기서 :djadmin:’collectstatic’은 이들을 복사한다.

더 많은 정보를 원하면 How to manage static files (e.g. images, JavaScript, CSS) 를 확인하세요

MEDIA_ROOT and MEDIA_URL

미디어 파일은 사용자가 업로드합니다. 그들은 믿을 수 없어요! 웹 서버가 해당 문서를 해석하지 않도록 하십시오. 예를 들어 사용자가 “.php” 파일을 업로드하면 웹 서버가 실행하지 않아야 한다.

지금 바로 이러한 파일의 백업 전략을 확인해 보십시오.

HTTPS

사용자가 로그인할 수 있는 웹 사이트는 액세스 토큰을 명확하게 전송하지 않도록 사이트 전체 HTTPS를 적용해야 합니다. Django에서 액세스 토큰에는 로그인/암호, 세션 쿠키 및 암호 재설정 토큰이 포함됩니다(이메일로 보내는 경우 암호 재설정 토큰을 보호하는 데 많은 작업을 수행할 수 없습니다).

HTTP 및 HTTPS에 동일한 세션 쿠키가 사용되므로 사용자 계정이나 관리자와 같은 중요한 영역을 보호하는 것만으로는 충분하지 않습니다. 웹 서버는 모든 HTTP 트래픽을 HTTPS로 리디렉션하고 HTTPS 요청만 Django로 전송해야 합니다.

HTTPS를 설정한 후 다음 설정을 사용하도록 설정하십시오.

성능 최적화

설정 :setting:`DEBUG = False 은 개발에만 유용한 여러 기능을 사용하지 않도록 설정합니다. 또한 다음 설정을 조정할 수 있습니다.

세션

성능 향상을 위해 :ref:’캐시 세션’을 사용하는 것을 고려하십시오.

데이터베이스 지원 세션을 사용할 경우 정기적으로:ref:’이전 세션 지우기’를 수행하여 불필요한 데이터를 저장하지 않도록 합니다.

:설정:`CONN_MAX_AGE`

요청 처리 시간의 상당 부분을 데이터베이스 계정에 연결할 때 :ref:’영구 데이터베이스 연결’을 활성화하면 속도가 상당히 빨라질 수 있습니다.

따라서 네트워크 성능이 제한된 가상화된 호스트에서 많은 도움이 됩니다.

:설정:`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`

웹 사이트를 프로덕션 상태로 전환하기 전에 로깅 구성을 검토하고 일부 트래픽이 수신되는 즉시 해당 구성이 제대로 작동하는지 확인합니다.

로깅에 관한 자세한 내용은 :doc:`/topics/logging`을 참조하세요

:설정:`ADMINS` 그리고 :설정:`MANAGERS`

이메일에 의한 500 에러는 :설정:`ADMINS`에게 알려질 것입니다

:설정:`MANAGERS` 오류 404가 표시됩니다. :설정:`IGNORABLE_404_URLS` 가짜 보고서를 필터링하는 데 도움이 될 수 있습니다.

이메일로 에러를 알리는 방법에 대한 자세한 내용은 How to manage error reporting 을 참조하세요

메일로 에러를 알려주는것은 좋지 않을수도 있습니다

보고서에 의해 받은 편지함이 플러시되기 전에 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.

Back to Top