Django를 배포하는 방법

PART 1. 안전 제일

취약점을 수정하기 가장 좋은 시기는 개발 중입니다.

1.1 CSRF TOKEN

Django의 보안 프레임워크에서 CSRF TOKEN은 중요한 보안 전략입니다. 그러나 많은 경우 Django를 막 접한 일부 학생들은 최종적으로 작성한 양식이 POST 중에 오류를 보고하는 것을 발견하고 일부 검색 후 CSRF TOKEN 문제임을 발견하고 온라인을 따릅니다. settings.py의 모든 CSRF TOKEN 구성이 제거되고 코드가 정상적으로 실행되었습니다. 이런 종류의 작업이 웹사이트의 보안에 큰 영향을 미치고 이후 단계에서 취약점을 패치하는 데 드는 비용이 증가한다는 사실을 아는 사람은 거의 없습니다. 개발 단계에서 보안 문제를 제거하는 것이 비용이 가장 저렴합니다.

공식 문서에는 CSRF TOKEN 관련 내용이 자세히 설명되어 있으므로 여기서는 구체적인 사용법을 설명하지 않습니다. 여기서는 개발 중에 개발자에게 덜 민감하고 토큰이 성공적으로 전송되었는지 여부에 대해 특별한 주의가 필요하지 않은 보다 편리한 사용을 권장합니다.

전체 상위 템플릿 페이지에 {% csrf_token %}를 추가하고 <script> 섹션에서 다음을 설정합니다. </script>

이런 방식으로 모든 비GET|HEAD|OPTIONS| JQuery TRACE 요청에는 CSRF TOKEN이 자동으로 포함됩니다(CSRF TOKEN을 얻기 위한 코드의 일부는 나열되지 않음). 다른 HTTP 라이브러리나 Fetch를 사용하는 경우 해당 설정을 지정하면 됩니다.

1.2 API 보안 설계

경우에 따라 우리 웹 서비스는 다른 시스템의 호출을 위해 일부 API 서비스를 외부 세계에 제공할 수도 있습니다. 이러한 API 인터페이스의 경우 CSRF를 꺼야 합니다. 그렇지 않으면 CSRF를 비활성화할 수 없습니다. 정상적으로 사용됩니다. 또한 API 인터페이스가 남용되는 것을 방지하기 위해 다른 보안 조치도 취해야 합니다. 일반적인 전달 매개변수 외에도 이러한 매개변수가 중개자에 의해 변조되지 않도록 해야 하며 권한이 있는 사람만 해당 인터페이스를 호출할 수 있도록 허용해야 합니다. 이러한 이유로 타임스탬프, 서명 등 몇 가지 추가 전달 매개변수를 도입해야 합니다. access_key, access_token.

이 매개변수 쌍에는 access_key와 access_token이 포함됩니다. access_key는 호출자를 식별하는 것과 동일하며, access_token은 호출자의 비밀 키와 동일합니다. access_token의 내용은 쉽게 예측할 수 없으며, access_key는 메모리의 편의를 위해 더 간단한 문자열을 선택할 수 있습니다. 두 매개변수가 일치하는 경우에만 API 호출이 합법적인 것으로 간주됩니다.

비즈니스 요구에 따라 타임스탬프의 정확성을 선택하세요. 초 또는 밀리초를 선택할 수 있습니다. 타임스탬프를 추가하는 주요 목적은 이 호출이 재생되는 것을 방지하는 것입니다. 서버는 클라이언트가 전달한 타임스탬프가 시간 범위 내에 있는지 확인해야 합니다. 매개변수의 신뢰성을 보장하려면 또 다른 매개변수 기호를 도입해야 합니다. 타임스탬프가 재생되더라도 여전히 변조 위험이 있기 때문입니다.

sign은 해시 계산에 참여하는 모든 매개변수 값에 의해 생성되는 모든 매개변수의 서명 값입니다. 매개변수가 조금씩 변경될 때마다 매개변수의 신뢰성을 보장하기 위해 부호를 다시 생성해야 합니다. 일반적으로 사용되는 알고리즘은 매개변수 키의 알파벳 순서에 따라 매개변수 값을 정렬하고 특정 구분 기호를 사용하여 모든 매개변수를 연결한 다음 해시 계산을 수행하고 부호 매개변수를 서버에 함께 전달하는 것입니다. 예를 들어 기존 매개변수 ak=2222&at=1111&timestamp=3333&key1=aaa를 알파벳순으로 정렬하면 22221111aaa3333이고, 구분 기호(|)를 추가하면 2222(|)1111(|)aaa(|)3333이 되며, 그런 다음 이 문자열은 sha1을 계산하고 부호 값을 생성합니다. Python 코드로 작성하는 것은 비교적 간단합니다.

1.3 일부 잡다한 항목

위의 두 가지 중요한 사항 외에도 추가로 주의가 필요한 곳이 있습니다.

프로덕션 환경에서 DEBUG 모드를 끄세요.

버전 관리에 settings.py를 추가하지 말고 SECRET_KEY를 보호하세요.

ALLOWED_HOSTS를 설정하세요.

Django에서 제공하는 ORM을 사용하세요. 가능하다면 .raw()와 같은 메서드를 통해 SQL 문을 직접 실행하지 마세요. 피할 수 없는 경우 SQL 삽입 취약점을 방지하려면 매개변수를 올바르게 이스케이프 처리하세요.

필요한 경우 Django 관리를 최대한 비활성화하세요. 기본 관리 URL을 변경하세요.

PART 2. 배포 방법

git에서 코드를 가져와서 pip를 사용하여 프로젝트 종속 항목을 설치하고, Manage.py를 통해 서비스를 실행합니다. , 그런데 실제로 프로덕션 환경에서 사용할 계획인가요?

2.1 격리된 환경

일반적인 상황에서는 우리 서버에 Python 환경이 하나만 있을 것입니다. 배포 시 일반적으로 pip를 통해 프로젝트에 필요한 종속성을 설치합니다. 예배 규칙서.

여러 프로젝트를 배포할 때 이 종속성 설치 방법은 쉽게 종속성 충돌로 이어질 수 있습니다. 간단한 예를 들자면 이제 Project-A와 Project-B라는 두 개의 프로젝트가 있습니다. pip를 통해 -r 요구사항-a.txt를 설치하면 A와 B 모두 타사 패키지 third-A에 의존합니다. , 종속성 third-A가 전역 Python 환경에 설치됩니다. pip install -r 요구사항-b.txt를 다시 설치하면 이때 두 프로젝트가 의존하는 버전인 경우 third-A도 다시 설치됩니다. 예를 들어 프로젝트 A에는 버전 1.0이 필요하고 프로젝트 B에는 버전 2.0이 필요합니다. 이로 인해 종속성 충돌이 발생하고 종속성 설치가 실패하게 됩니다.

이 문제를 해결하는 방법은 무엇입니까? 우리가 쉽게 생각할 수 있는 것은 여러 개의 독립적인 격리 환경이 있고 각 프로젝트가 독립적인 환경에 배포되면 이 문제가 쉽게 해결될 것이라는 것입니다. Virtualenv는 이 문제를 해결하기 위해 탄생했습니다. 종속성 충돌을 피하기 위해 각 프로젝트마다 별도의 실행 환경을 만들 수 있습니다.

2.2 버전 관리

우리는 이전에 격리된 환경을 만들고 서로 다른 환경에 서로 다른 프로젝트를 배포하는 방법을 알고 있었지만 모든 환경에서 사용하는 Python 버전이 동일하다는 문제가 있습니다. Python 2.7(이 버전은 곧 유지되지 않을 것이라는 것을 알고 있지만 여기에 예를 제공하겠습니다), Python 3.6 및 Jython 프로젝트와 같은 여러 버전의 Python 프로젝트를 배포해야 하는 경우 하나씩 설치하는 것 같습니다. 약간 복잡합니다. 컴파일하고 설치할 때에도 특정 컴파일 매개변수가 실수로 누락되어 다시 컴파일해야 하므로 배포 작업량이 어느 정도 증가합니다.

pyenv를 사용하여 여러 Python 버전의 문제를 관리할 수 있으며, 추가로 pyenv 플러그인 pyenv-virtualenv를 사용하여 여러 Python 버전과 여러 가상 환경의 문제를 관리할 수 있습니다.

2.3 게이트웨이 인터페이스

다양한 환경의 문제를 해결한 후에는 프로젝트를 어떻게 실행할 것인지 고민해야 할 때입니다. python Manage.py runserver 0.0.0.0:80을 생각하면 좀 과합니다. 단순한.

Django에는 위의 방법을 통해 웹 서비스를 시작할 수 있는 간단한 WSGI 구현이 내장되어 있습니다. 단지 디버깅을 원하거나 소수에게만 서비스를 제공하려는 경우에도 이 솔루션은 선택 사항입니다. 별로 우아해 보이지는 않네요.

애플리케이션을 실제 프로덕션 환경에 배포하려면 django에서 제공하는 단순한 WSGI 서버가 아닌 고성능 WSGI 서버도 필요합니다. Gunicorn과 uWSGI는 모두 상대적으로 주류인 WSGI 서버입니다. 실제 배포 환경에 따라 둘 중 하나를 선택하세요.

그러나 저는 개인적으로 Gunicorn을 선호합니다. uWSGI가 많은 성능 테스트에서 우위를 점하고 있지만 Gunicorn을 선택한 이유는 uWSGI에 비해 매우 간단하고 그다지 복잡하지 않으며 거의 ​​사용하지 않는 기능 때문입니다. 해당 기능은 Nginx에서 점진적으로 지원되었으며 Gunicorn은 구성이 비교적 간단하고 편리합니다. 또 한 가지 주목해야 할 점은 Windows에 배포하려면 Apache+mod_wsgi를 사용해야 할 수도 있다는 것입니다.

2.4 역방향 프록시

WSGI 서버가 시작된 후 역방향 프록시 문제를 고려해야 합니다. 역방향 프록시를 수행하기 위해 또 다른 Nginx 계층이 있는 이유는 다음과 같습니다.

Nginx가 필요합니다. 정적 리소스를 처리합니다. Django의 DEBUG 모드를 False로 설정하면 CSS 및 JS와 같은 많은 정적 리소스를 로드할 수 없습니다. 이는 Django가 이러한 요청을 적극적으로 처리하지 않고 Nginx가 이를 처리하는 데 도움이 필요하기 때문입니다. 여러 백엔드의 부하 분산을 수행합니다. 서비스가 여러 서버에 배포되거나 기본 및 백업 배포가 있는 경우 Nginx의 간단한 설정을 통해 달성할 수 있습니다.

uWSGI 또는 Gunicorn 보안 위험을 직접 노출하는 데는 특정 문제가 있습니다. Nginx를 사용하여 HTTP 문제를 처리하세요.

또한 여기에 나열되지 않은 몇 가지 이유가 있습니다. 다시 말씀드리지만, 서비스가 매우 간단하고 소수의 사람만 액세스한다면 그렇게 복잡한 설정을 할 필요가 없습니다.

2.5 프로세스 데몬

현재 서비스 배포가 성공적으로 완료되어 정상적으로 서비스 제공을 시작하실 수 있습니다. 그러나 우리는 이에 대해 덜 생각합니다. 불행하게도 알 수 없는 이유로 Django가 종료되면 웹 서비스는 502가 됩니다. 서비스의 안정성을 보장하기 위해 Django 프로세스를 보호해야 하며, 알 수 없는 문제가 발생하여 비정상적인 종료가 발생하는 경우 필요한 프로세스를 자동으로 끌어 올려야 합니다.

Supervisor를 모니터링 도구로 사용하면 Django 프로세스의 안정적인 생존을 보장할 수 있습니다. 더 심각한 사고를 방지하려면 Supervisord 원격 명령 실행 취약점을 피하도록 주의하는 것이 중요합니다.

PART 3. 백그라운드 서비스

일반적으로 백그라운드 서비스를 시작하려면 셀러리가 보편적인 선택이지만 이렇게 무거운 종속성을 도입하고 싶지 않은 경우가 많기 때문에 방법을 찾아야 합니다. 백그라운드 서비스를 직접 시작하십시오.

간단한 방법은manage.py의 명령을 만들고, ./manage.py runcommand를 통해 백그라운드 서비스를 시작하고, 쉘 스크립트를 작성하여 서비스의 시작과 중지를 제어하거나 감독자를 통해 관리하는 것입니다.

백그라운드 프로세스가 웹 서비스와 동시에 시작되고 중지되도록 하려면 wsgi.py에 넣는 것이 좋은 선택입니다. wsgi.py에서 해당 백그라운드 서비스를 초기화하고 시작합니다. 그러나 이 접근 방식은 유연성이 부족합니다. 웹 서비스나 백그라운드 서비스를 별도로 업데이트해야 하는 경우에는 둘 다 다시 시작해야 합니다. 그러나 첫 번째 방법을 사용하면 서비스 중 하나를 별도로 업데이트할 수 있습니다.

위 내용은 Django를 배포하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!