호스팅 옵션
웹 사이트 사이트의 호스팅 옵션은 일반적으로 다음 중 하나입니다.
- 전용 서버
- 가상 사설 서버 (VPS)
- 공유 호스팅
전용 서버를 사용하면 실제 컴퓨터에서 하나의 사이트 만 호스팅되며 구성은 컴퓨터 자체만큼 안전합니다.
VPS를 사용하면 소프트웨어가 다른 사용자의 가상 컴퓨터와 동일한 실제 컴퓨터에서 실행됩니다. 그러나 기능적으로는 전용 서버와 동일합니다. 가장 중요한 것은 VPS에 전용 서버의 개인 정보 보호 및 보안 기능이 있다는 것입니다.
공유 호스팅을 사용하면 웹 사이트가 다른 사용자와 공유되는 파일 시스템에 있습니다. 불행히도, 이것은 전용 서버 나 VPS에서 실행될 때보 다 덜 안전합니다. 이 기사의 나머지 부분에서는 공유 호스팅 환경에서의 WCMS 보안에 대해 설명합니다.
환경
공유 호스팅 환경은 웹 서버, 파일 시스템, 설정 파일, 데이터베이스 및 일부 사용자로 구성된 것으로 간주 될 수 있습니다.
다음 예에서는 소유자 계정이 "tom"이고 설정 파일 (데이터베이스 자격 증명 보유)의 이름이 "settings.php"인 것으로 가정합니다.
웹 서버 프로세스는 구성에 따라 소유자 계정 "tom"의 사용자 권한 또는 "www"그룹의 그룹 권한으로 실행될 수 있습니다.
또한 표준 Gnu / Linux 또는 Unix 환경이 가정되며 독자는 별도의 읽기 (r), 쓰기 (w) 및 실행 / 액세스 디렉토리 (x) 권한이 3 개의 블록으로 분할 된 Unix 액세스 제어 시스템을 이해한다고 가정합니다. (사용자, 그룹, 기타).
특정 설정에 대해 계속 논의하기 전에 만족시키려는 조건을 나열하면 도움이 될 수 있습니다.
- 웹 사이트가 작동하려면 웹 서버에 사이트를 구성 하는 모든 파일에 대한 읽기 액세스 권한이 있어야 하고 사이트를 구성하는 모든 디렉토리에 대한 디렉토리 액세스 권한이 있어야합니다.
- 안전한 작동을 위해 웹 서버는 처리하는 파일에 대한 쓰기 액세스 권한이 없어야합니다.
- 안전한 작동을 위해 악의적 인 사용자가 실행 한 웹 스크립트에는 다른 사용자가 소유 한 파일에 대한 읽기 권한 이 없어야합니다 .
- 소유자가 CLI를 사용하여 자신의 사이트에서 작업하려면 사용자는 자신의 파일에 대한 읽기 및 쓰기 권한 이 있어야 합니다.
- CLI를 사용하여 다른 사용자가 파일에 액세스 하지 못하도록하려면 "other"블록에 권한이 설정 되어 있지 않아야합니다.
불행히도, 공유 호스트에서는 5 개 중 4 개만 가질 수 있습니다 . 공유 호스트에서 5 가지 조건을 모두 만족시킬 수있는 방법은 없습니다 .
내가 아는 한 공유 호스트 공급자는 두 가지 구성을 사용합니다. 파일과 디렉토리를 가장 잘 보호하기 위해 사용할 수있는 권한과 구성이 충족하지 못하는 조건에 대해 아래에서 설명합니다.
구성 1 : 웹 서버가 소유자로 실행 중
이것이 가장 널리 사용되는 AFAIK 구성입니다. 웹 서버가 파일 소유자로 실행 중입니다. 이는 악의적 인 사용자가 자신의 웹 서버 사용자를 사용하여 다른 사용자의 파일을 읽는 스크립트를 실행할 수 없음을 의미합니다. 이 유형의 구성은 또한 CLI에서 사용자를 서로로부터 보호합니다.
그러나 이는 소유자와 웹 서버에 대해 별도의 권한을 가질 수 없음을 의미합니다. 이 유형의 설정으로 조건 2를 만족 시키려면 업로드 디렉토리를 제외한 모든 웹 서버에 대한 쓰기 액세스를 방지하기 위해 소유자에 대한 쓰기 권한을 제한해야합니다.
권한 :
Directories: 500 r-x --- --- tom.tom
Files: 400 r-- --- --- tom.tom
settings.php: 400 r-- --- --- tom.tom
Upload Dir.: 700 rwx --- --- tom.tom
불행하게도, 이는 조건 4를 만족시킬 수 없음을 의미합니다. 즉, CLI를 통해 사이트를 유지할 수 없습니다. 소유자는 일종의 웹 기반 대시 보드를 사용하여 사이트에 액세스하도록 제한됩니다 (권장자는 액세스가 제한되지 않은 일부 준비 서버에서 사본을 유지 관리하고 준비 서버에서 변경 한 내용을 공유 호스트로 미러링하는 것이 좋습니다). ).
구성 2 : 웹 서버가 www 그룹의 구성원으로 실행 중
이 구성은 덜 전문적인 일부 공유 호스트 솔루션 공급자가 사용합니다. 웹 서버가 www 그룹의 구성원으로 실행 중이며 그룹 블록을 통해 필요한 읽기 권한이 부여됩니다.
권한 :
Directories: 750 rwx r-x --- tom.www
Files: 640 rw- r-- --- tom.www
settings.php: 640 rw- r-- --- tom.www
Upload Dir.: 770 rwx rwx --- tom.www
이러한 설정은 소유자가 CLI를 통해 파일에 대한 전체 액세스 권한을 부여하고 웹 서버가 읽기 액세스로만 제한 할 수 있다는 이점이 있습니다.
그러나 또한 조건 3을 충족시키지 못합니다. 즉, 공유 호스트의 불량 사용자 (또는 호스트를 공유하는 다른 사용자의 사이트를 손상시킨 해커)가 스크립트를 실행하여 읽을 수 있는 파일을 읽을 수 있습니다. 웹 서버. 이렇게하면 악성 스크립트가 데이터베이스 자격 증명을 사용하여 settings.php 파일에 액세스 할 수 있으므로 사이트를 완전히 인수하는 것이 쉽지 않습니다.
이 유형의 구성을 피하는 것이 좋습니다.
부록 : 공유 호스트를 사용하는 것이 얼마나 위험합니까?
신용 카드 번호 나 의료 기록과 같은 민감한 것을 공유 호스트에 두지 않을 것입니다. 그러나 공유 호스팅은 저렴하며 그 매력이 있습니다. 내 사이트 중 일부에 대해 공유 호스팅을 사용합니다. 나는 아직 해킹을받지 않았지만, 위험이 존재한다는 것을 알고 있으며 그것이 일어날 날에 대비하고 있습니다. 해킹당한 경우 공유 호스트의 모든 항목 을 삭제 하고 안전한 준비 서버에 보관하는 미러 복사본에서 사이트를 다시 설치합니다.
"config 2"에서 주요 문제는 다른 것 입니다. 일부 경우 다른 손상됩니다와 호스트를 공유하는 웹 사이트, 웹 사이트는 점심입니다. 잘 모르고 통제 할 수없는 다른 당사자에게 보안을 부여하는 것은 좋은 생각이 아닙니다. 이것이 제가 추천하는 것이 "config 2"-타입 호스팅 배열을 피하는 것입니다.
"config 1"을 사용하면 웹 사이트의 보안 만 제어 할 수 있습니다. 이 방법이 더 좋습니다 (특히 수행중인 작업을 알고있는 경우). 그러나 그것은 바보가 아닙니다. 완벽한 사람은 없으며 사이트를 손상시키고 사이트가 손상되면 공격자는 해당 호스트에 저장된 모든 파일에 액세스 할 수 있습니다. 다시 말해, 해킹 당했을 때 피해를 최소화하려면 다른 사람이 접근 할 경우 해를 입힐 수있는 물건 을 호스트에 두지 마십시오 . 특히, 해당 공유 호스트에 이메일을 보관 하지 마십시오 . 전자 메일에는 일반적으로 많은 양의 중요한 데이터가 있으므로 "사용자"로 실행되는 웹 서버 근처에서는 원하지 않습니다.
웹 애플리케이션이 민감한 데이터를 처리하는 경우 예산이 전용 호스트 또는 VPS를 허용하는지 확인하십시오.
Drupal.org에서 파일 권한 및 소유권 보안 에 대한이 안내서를 참조 할 수도 있습니다 .