배포 전 체크리스트¶
인터넷은 위험한 환경입니다. Django 프로젝트를 배포하기 전에 보안, 성능 및 작업을 염두에 두고 설정을 검토해야 합니다.
장고는 보안 기능을 많이 갖고 있습니다. 몇몇은 내장된 기능으로 항상 켜져있습니다. 다른 몇몇은 선택할 수 있는데 그 이유는 항상 보안 기능들이 적절하지 않거나 개발에 불편함을 가져올 수 있기 때문입니다. 예를 들어 강제로 HTTPS를 활성화 하는 것은 모든 웹사이트에 적합하지 않을 수도 있고, 로컬 개발환경에선 비실용적일 수도 있습니다.
성능 최적화는 편의를 위한 또다른 범주의 거래입니다. 예를 들어, 캐싱은 상용 환경에서 유용할 수 있지만 로컬 개발 환경에서는 실용적이지 않을 수 있습니다. 오류 보고의 필요성에도 큰 차이가 있습니다.
설정에 대한 체크리스트는 다음과 같습니다.
Django에서 예상되는 수준의 보안을 제공하도록 설정해야 합니다.
각 환경에 맞도록 설정해야 합니다.
선택적인 보안 기능들을 활성화시켜야 합니다.
성능 최적화가 적용돼야 합니다.
에러 보고가 제공되어야 합니다.
이 설정들 중 대부분은 예민할 수 있고 감추어져야 합니다. 만약 여러분이 프로젝트의 소스코드를 배포한다면, 대부분은 개발 환경에 최적화된 설정으로 배포하고 상용 환경에서 사용할 별도의 설정을 사용할 것입니다.
manage.py check --deploy 명령 실행¶
문서아래에 설명된 일부 검사는 : 옵션을 사용하여 자동화할 수 있습니다.check –deploy’ 옵션을 선택하십시오. 옵션 설명서에 설명된 대로 프로덕션 설정 파일에 대해 실행하십시오.
Switch away from manage.py runserver¶
The runserver command is not designed for a production setting. Be
sure to switch to a production-ready WSGI or ASGI server. For a few common
options, see WSGI servers or
ASGI servers.
중요 설정¶
:설정:`SECRET_KEY`¶
비밀 키는 큰 임의 값이어야 하며 기밀로 유지되어야 합니다.
프로덕션에 사용된 키가 다른 곳에서 사용되지 않는지 확인하고 소스 제어에 커밋하지 않도록 하십시오. 이렇게 하면 공격자가 키를 얻을 수 있는 벡터 수가 줄어듭니다.
설정 모듈의 비밀 키를 하드코딩하는 대신 환경 변수에서 로드하는 것을 고려하십시오.
import os
SECRET_KEY = os.environ["SECRET_KEY"]
또는 파일로부터
with open("/etc/secret_key.txt") as f:
SECRET_KEY = f.read().strip()
비밀 키를 순환하는 경우 SECRET_KEY_FALLBACKS::를 사용할 수 있습니다.
import os
SECRET_KEY = os.environ["CURRENT_SECRET_KEY"]
SECRET_KEY_FALLBACKS = [
os.environ["OLD_SECRET_KEY"],
]
적절한 때에 ``SECRET_KEY_FALLBACKS``에서 오래된 비밀 키가 제거되었는지 확인하십시오.
:설정:`DEBUG`¶
프로덕션에서 디버그를 사용 가능으로 설정하지 않아야 합니다.
다음을 설정하여 프로젝트를 개발하고 있는 것이 확실합니다.브라우저의 전체 추적과 같은 편리한 기능을 제공하므로 ‘DEBUG = True’입니다.
그러나 프로덕션 환경에서는 이 방법이 매우 좋지 않습니다. 프로젝트에 대한 많은 정보(소스 코드, 로컬 변수, 설정, 사용된 라이브러리 등)를 유출하기 때문입니다.
특정한 환경 설정¶
:설정:`ALLOWED_HOSTS`¶
:설정:’DEBUG = False’, Django는 : 설정에 ALLOWED_HOSTS. 의 적합한 값이 없으면 전혀 작동하지 않습니다
이 설정은 일부 CSRF 공격으로부터 사이트를 보호하는 데 필요합니다. 와일드카드를 사용할 경우 “Host” HTTP 헤더에 대한 자체 검증을 수행하거나 그렇지 않을 경우 이 공격 범주에 취약하지 않은지 확인해야 합니다.
또한 호스트를 검증하기 위해 Django 앞에 있는 웹 서버를 구성해야 합니다. 정적 오류 페이지로 응답하거나 Django에 요청을 전달하는 대신 잘못된 호스트에 대한 요청을 무시해야 합니다. 이렇게 하면 Django 로그(또는 그런 방식으로 구성된 오류 보고가 있는 경우 이메일)에서 가짜 오류를 피할 수 있습니다. 예를 들어 nginx에서 인식할 수 없는 호스트에서 “444 No Response”를 반환하도록 기본 서버를 설정할 수 있습니다.
server {
listen 80 default_server;
return 444;
}
:설정:`CACHES`¶
캐시를 사용하는 경우 연결 매개 변수는 개발 및 운영에서 다를 수 있습니다. Django의 기본값은 프로세스당:ref:로컬 메모리 캐싱 1은 바람직하지 않을 수 있다.
캐시 서버의 인증확인은 약한 경우가 많습니다. 응용프로그램 서버로부터의 연결만 허용하는지 확인합니다.
:설정:`DATABASES`¶
데이터베이스 연결 매개 변수는 개발 및 운영에서 서로 다를 수 있습니다.
데이터베이스 암호는 매우 민감합니다. 당신은 SECRET_KEY.을 똑같이 보호해야 한다.
보안을 최대화하려면 데이터베이스 서버가 응용프로그램 서버의 연결만 허용해야 합니다.
데이터베이스에 대한 백업을 설정하지 않은 경우 지금 바로 수행하십시오!
:설정:`STATIC_ROOT` 그리고 :설정:`STATIC_URL`¶
정적 파일은 개발 서버에서 자동으로 제공됩니다. 프로덕션에서 :seting:’를 정의해야 합니다.STATIC_ROOT’ 디렉토리. 여기서 :djadmin:’collectstatic’은 이들을 복사한다.
더 많은 정보를 원하면 정적 파일 관리하기(이미지, 자바스크립트, 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`¶
캐시된 템플릿 로더를 활성화하면 각 템플릿을 렌더링해야 할 때마다 컴파일하지 않아도 되므로 성능이 크게 향상되는 경우가 많습니다. 설정:`DEBUG = False <DEBUG>`인 경우 캐시된 템플릿 로더가 자동으로 활성화됩니다. 자세한 내용은 :class:`django.template.loaders.cached.Loader`를 참조하십시오.
오류 알림¶
코드를 프로덕션으로 푸시할 때쯤이면 강력한 기능이 발휘되지만 예기치 않은 오류를 배제할 수는 없습니다. 고맙게도, Django는 오류를 포착하고 그에 따라 통지할 수 있습니다.
:설정:`LOGGING`¶
웹 사이트를 프로덕션 상태로 전환하기 전에 로깅 구성을 검토하고 일부 트래픽이 수신되는 즉시 해당 구성이 제대로 작동하는지 확인합니다.
로깅에 관한 자세한 내용은 :doc:`/topics/logging`을 참조하세요
:설정:`ADMINS` 그리고 :설정:`MANAGERS`¶
이메일에 의한 500 에러는 :설정:`ADMINS`에게 알려질 것입니다
:설정:`MANAGERS` 오류 404가 표시됩니다. :설정:`IGNORABLE_404_URLS` 가짜 보고서를 필터링하는 데 도움이 될 수 있습니다.
이메일로 에러를 알리는 방법에 대한 자세한 내용은 오류 보고를 관리하는 방법 을 참조하세요
메일로 에러를 알려주는것은 좋지 않을수도 있습니다
보고서에 의해 받은 편지함이 플러시되기 전에 Sentry_와 같은 오류 모니터링 시스템을 사용하는 것이 좋습니다. Sentry는 로그를 집계할 수도 있습니다.
기본 오류 보기 사용자 지정¶
Django에는 여러 HTTP 오류 코드에 대한 기본 보기 및 템플릿이 포함되어 있습니다. 루트 템플릿 디렉토리에 404.html, 500.html, 403.html 및 ``400.html` 템플릿을 생성하여 기본 템플릿을 재정의할 수 있습니다. 99%의 웹 응용 프로그램에는 이러한 템플릿을 사용하는 :ref:`기본 오류 뷰 <error-views>`가 충분하지만, :ref:`사용자 정의 <customizing-error-views>`할 수도 있습니다.
