삽질도 두드려 보고,

DESIGN YOUR EXPERIENCE

배포 준비

토픽 삽질도 두드려 보고, > 서버 프로그래밍 > Apache HTTPD for Windows

SECRET_KEY

 settings.py 파일을 보면 SECRET_KEY 변수가 존재할 것이다. 이 키는 Django 내에서 로그인과 같은 세션을 유지하고, 비밀번호 생성, 쿠키, 암호화 서명 등에 사용된다. 이 키 값을 공격자가 탈취하면 서비스의 암호화된 로직이나 데이터에 접근할 가능성을 크게 열어준다. 그러므로 이 키를 소스제어에 포함시키거나 커밋시키지 않도록 한다.

 이미 소스제어에 커밋된 상태라면 Django Secret Key Generator 도구를 이용해 새 키 값을 배포해야 한다.

 운영체제 환경변수에 등록, 키 값을 파일로 분리, 소스 제어에서 제외하는 등 몇 가지 SECRET_KEY를 비공개하는 방법이 있다. 자신 또는 팀의 상황에 따라 더 간단한 방법을 사용하면 된다.

디버그 모드 해제

 settings.py 파일에 DEBUG 변수가 있다. 개발 과정에서 Django 오류 페이지를 띄워 여러가지 디버깅에 필요한 정보들을 출력하는 기능을 한다. 소스코드의 자세한 로직과 데이터 내용까지 보여주므로 실제 배포 단계에서는 이를 False로 바꾸어 클라이언트가 내부 소스코드를 보지 못하게 해야 한다. 또한 오류 페이지 대신 적절한 404 등의 정식 오류 페이지를 띄우게 한다.

ALLOWED_HOSTS

 DEBUG 플래그가 False일 때 Django는 ALLOWED_HOSTS 리스트에 자신이 실제로 서비스를 런칭할 웹 사이트의 도메인이 없으면 DisallowedHost 예외를 발생시키며 작동하지 않는다. CSRF 공격으로부터 웹 사이트를 보호하기 위해 필요한 조치이며, DEBUG가 True일 땐 기본값으로 127.0.0.1과 localhost 값이 암시적으로 추가된다. 실제 서비스를 제공할 도메인 주소를 기입한다.

DATABASES

 SECRET_KEY처럼 소스제어에 추가해서도, 공개해서도 안되는 변수다. SECRET_KEY에서 처리했던 비공개 방법과 같은 방법을 사용하면 된다. 그러므로 settings.py 파일을 소스제어에서 제외시켜 따로 보관하는 것이 가장 간단하다.

HTTPS

 아무리 서버 단에서 데이터를 암호화하고 비공개 처리 하더라도 클라이언트와 서버 사이에 오가는 데이터가 노출되면 말짱 도루묵이다. 요즘은 사회공학적 해킹 또는 APT 공격으로 인해, 속도를 핑계 삼아 단순 로그인 세션만 암호화 처리하는 것은 취약한 조치이다. 웹 사이트 전체를 HTTPS로 암호화시켜 제 3자에게 노출되는 정보를 최소화해야 한다.

CSRF_COOKIE_SECURE

 HTTP를 통한 CSRF 쿠키 전송을 금지하려면 True로 설정한다.

SESSION_COOKIE_SECURE

 HTTP를 통한 세션 쿠키 전송을 금지하려면 True로 설정한다.

확인

 Deploy 전 필수 준비 사항들이 제대로 설정되었는지 확인하는 명령이 있다.

python manage.py check --deploy

댓글

댓글 본문