운영 요구사항부터 시작하세요
구성을 비교하기 전에 각 프로젝트의 애플리케이션 스택, 데이터베이스, 업로드, 예약 작업, 통합 및 예상 변경을 수집하세요. 누가 콘텐츠 접근, 배포 접근 및 호스트 관리가 필요한지 식별하세요. 이들은 서로 다른 작업입니다. 페이지를 편집하는 클라이언트는 애플리케이션 계정만 필요할 수 있지만, 운영 체제를 유지보수하는 계약자는 훨씬 광범위한 권한이 필요합니다.
또한 허용 가능한 유지보수 시간대, 다운타임을 승인하는 사람, 복구 사본이 보관되는 위치 및 운영 작업 비용을 지불하는 사람을 기록하세요. 별도 서버 또는 계정에 대한 클라이언트 요구사항이 있으면 결정 제약으로 기록하세요. 리소스 스프레드시트로는 소유권이나 접근 요구사항을 해결할 수 없습니다.
- 각 프로젝트의 주 운영자와 대체자를 지정하세요.
- 공유 종속성을 나열하세요: DNS 접근, 배포 자격 증명, 데이터베이스 서비스 및 백업 대상.
- 구성을 확정하기 전에 고객 결정이 필요한 미확인 요구사항을 표시하십시오.
서버 크기보다 접근 경계를 먼저 선택하세요
OWASP는 개인의 업무에 필요한 권한만 부여하고 의도한 제한이 유지되는지 검증할 것을 권장합니다. 이 원칙을 호스팅 요금제에 적용하십시오. 개별 신원, 프로젝트별 애플리케이션 자격 증명, 문서화된 배포 경로를 사용하십시오. 고객 이름을 딴 디렉터리는 조직적 편의를 위한 것이지 접근 정책이 아닙니다.
Docker를 사용하는 경우, 데몬 접근을 호스트 수준의 책임으로 취급하십시오. Docker의 보안 문서에 따르면 신뢰할 수 있는 데몬 운영자는 호스트 파일을 마운트하고 수정할 수 있습니다. 따라서 외부 계약자에게 무제한 Docker 제어 권한을 부여하는 것은 무관한 고객의 데이터가 있는 호스트에 적합하지 않습니다.
분리된 VPS 인스턴스는 별도의 운영체제 관리 및 릴리스 결정을 허용합니다. 그러나 각 프로젝트 내에서 신중한 권한 설정이 여전히 필요합니다. 공통 에이전시 자격 증명이나 공유 배포 계정은 분리하려 했던 위험을 다시 연결할 수 있습니다.
두 개의 가상 클라이언트 브리프를 검토하세요
아래 고객은 가상의 예시이며 실제 고객 이력이 아닙니다. 에이전시는 현재 두 프로젝트를 모두 운영하고 있지만, 접근 및 일정 요구사항이 다릅니다.
이 두 프로젝트를 함께 배치하면 Morrow의 계약자 접근 및 출시 일정이 Aster의 운영 위험의 일부가 됩니다. 별도 서버 결정은 이러한 제약을 따르며, Morrow가 특정한 수의 CPU를 필요로 한다거나 Aster가 위험이 없다고 주장하지 않습니다.
모든 테이블 열을 보려면 가로로 스크롤하세요.
| 결정 요인 | Aster Furniture: 브로슈어 사이트 | Morrow Workshops: 등록 사이트 |
|---|---|---|
| 워크로드 | 공개 페이지 및 간헐적 콘텐츠 업데이트 | 양식, 데이터베이스 및 예약된 등록 내보내기 |
| 액세스 | 고객이 콘텐츠를 편집하고 에이전시가 배포 | 외부 개발자가 호스트 관리 필요 |
| 유지보수 | 합의된 저녁 시간대 | 예약 출시 중 계획된 변경 없음 |
| 사고 영향 | 일시적인 페이지 중단은 논의 가능 | 분실 또는 중복 제출은 조사 필요 |
| 종료 요구사항 | 콘텐츠 내보내기 및 애플리케이션 이전 | 독립적으로 운영되는 환경 이전 |
| 잠정 결정 | 호환되는 에이전시 운영 사이트와 공유 고려 | 별도 VPS 및 별도 프로젝트 자격 증명 사용 |
두 방식의 전체 비용을 비교하세요
현재 구성기로 두 가지 예산 버전을 작성하십시오. 하나는 공유 구성, 다른 하나는 프로젝트별 구성입니다. 각각에 대해 선택한 기간의 호스팅 총액, 반복 옵션, 외부 서비스 및 에이전시 유지보수 시간을 별도로 나열하십시오. 이전 가격을 고객 브리프에 복사하지 마십시오. 구성이 준비된 시기와 배분을 승인한 사람을 기록하십시오.
공유 호스트의 경우 고객이 고정 비용을 어떻게 분담하고 한 고객이 떠나거나 업그레이드가 필요할 때 어떻게 되는지 합의하십시오. 균등 분담은 간단하지만 한 프로젝트가 대부분의 스토리지 증가나 운영 작업을 유발하는 경우 적합하지 않을 수 있습니다. 별도 서버는 귀속을 더 명확하게 하지만 별도의 패치, 모니터링 및 복구 작업을 추가합니다.
릴리스, 백업 및 임시 작업을 위한 리소스 여유를 남겨 두십시오. Docker 컨테이너는 기본적으로 CPU 또는 메모리 제약이 없습니다. 적절한 제한을 구성하고 결합된 워크로드를 평가하십시오. 컨테이너 목록만으로는 실행 가능한 리소스 예산을 입증할 수 없습니다.
유지보수와 복구를 프로젝트별로 설정하세요
공유 호스트에서는 운영체제 재시작이 모든 상주 프로젝트에 영향을 미칩니다. 호스트 유지보수를 공통 캘린더에 배치하고 각 고객에게 연락할 사람을 지정하십시오. 가능한 경우 애플리케이션 릴리스를 분리하고 한 프로젝트의 데이터 내보내기를 다른 프로젝트의 중요한 출시 중에 예약하지 마십시오.
복구 노트에는 비밀을 복사하지 않고 프로젝트의 데이터베이스, 파일, 구성 및 필요한 자격 증명을 식별해야 합니다. 별도의 테스트 대상으로 복원을 계획하십시오. 첫 대응으로 전체 공유 호스트를 복원하면 다른 고객의 정상적인 변경 사항을 대체할 수 있습니다.
별도 VPS 인스턴스의 경우 남아 있는 공유 서비스를 기록하십시오. 공통 DNS 계정, 백업 대상 또는 운영자는 여전히 두 프로젝트에 영향을 미칠 수 있습니다. 서버 분리는 독립적인 물리적 인프라 또는 보장된 가용성의 증거가 아닙니다.
방식을 검증하고 검토 트리거를 설정하세요
구성을 수락하기 전에 두 번째 운영자가 프로젝트 신원이 할당된 작업을 수행할 수 있고 다른 프로젝트의 파일, 백업 또는 비밀을 읽을 수 없는지 확인하게 하십시오. 애플리케이션 화면뿐만 아니라 데이터베이스 권한 및 배포된 자격 증명을 검토하십시오. 합의된 환경에서 무해한 테스트 데이터를 사용하십시오. 다른 고객의 프로덕션 데이터를 탐색하지 마십시오.
결과를 수락됨, 거부됨 또는 지정된 수정 대기 중으로 기록하십시오. 격리를 입증할 수 없는 경우 더 넓은 권한을 부여하기 전에 접근을 좁히거나 프로젝트를 이동하십시오. 성공적인 홈페이지 응답은 접근 또는 복구 검사가 아닙니다.
- 선택한 레이아웃, 승인된 비용 배분, 소유자 및 미해결 항목을 포함한 결정 기록을 유지하십시오.
- 외부 관리자가 합류하거나, 출시 일정이 변경되거나, 스토리지가 증가하거나, 고객이 떠날 준비를 할 때 선택을 검토하십시오.
- 책임 가이드를 사용하여 기술적 선택을 운영 계약으로 전환하십시오.
출처 및 검토
기술 참고 자료는 12년 2026월에 확인되었습니다. 예시는 계획 연습입니다. 참조된 소프트웨어 문서가 PrivateHostLab 서비스 기능을 입증하지는 않습니다.