시작하기 전에
- 각 구성 요소가 보유한 데이터가 포함된 서비스 인벤토리.
- 멤버, 편집자 및 관리자 역할 목록.
- 네트워크 또는 로그인 설정을 변경하기 전에 권한 있는 테스트 계정과 문서화된 복구 경로.
1. 사람과 작업을 설명하세요.
각 서비스에 대해 다음 문장을 완성하세요. "이 역할의 사람은 이러한 종류의 기기에서 이 작업을 수행해야 합니다." 공개 시간표 읽기, 내부 절차 편집 및 데이터베이스 유지 관리는 서로 다른 작업입니다. 한 자원봉사자가 가끔 원격 접근이 필요하다는 이유만으로 서비스를 공개하지 마세요.
네트워크 접근과 애플리케이션 권한 부여를 분리하세요. 로그인 페이지에 도달하는 것은 회원 파일을 읽을 권한이 아닙니다. 반대로 서비스를 사설 네트워크 뒤에 숨긴다고 해서 어떤 회원이 콘텐츠를 편집하거나 내보낼 수 있는지 결정되지는 않습니다. 두 계층과 누군가 떠날 때 접근 권한을 제거하는 프로세스를 모두 기록하세요.
계정 복구를 같은 논의에 포함하세요. 한 사람만 잠금을 해제할 수 있는 사설 서비스는 초기 접근 규칙이 제한적으로 보이더라도 다른 종류의 실패를 초래합니다.
2. 작은 접근 매트릭스를 작성하세요.
다음은 가상의 커뮤니티 워크숍 설정입니다. 선택 사항은 토론을 위한 예시이며, 완성된 네트워크 설계가 아닙니다.
| 구성 요소 | 의도된 대상 | 허용된 작업 | 확인 |
|---|---|---|---|
| 공개 시간표 | 누구나 | 승인된 날짜 읽기 | 로그아웃한 방문자는 회원 노트를 볼 수 없음 |
| 워킹 위키 | 멤버 및 편집자 | 읽기; 편집자는 편집만 가능 | 멤버는 절차를 변경할 수 없음 |
| 파일 라이브러리 | 지정된 그룹 계정 | 할당된 영역 내에서 읽기 또는 업로드 | 떠난 계정은 파일을 다운로드할 수 없음 |
| 애플리케이션 관리 | 권한 있는 유지관리자 | 설정 및 계정 관리 | 일반 멤버는 설정을 열 수 없음 |
| 데이터베이스 | 애플리케이션 및 유지관리 경로 | 필수 애플리케이션 작업 | 의도하지 않은 공개 리스너 없음 |
각 행 옆에 실제 메커니즘을 작성하세요. 애플리케이션 계정, 승인된 사설 접근 방법 또는 기타 문서화된 통제입니다. 메커니즘과 테스트가 없는 "사설"은 레이블일 뿐입니다.
3. 로그인 페이지 주변의 경로를 검토하세요.
리버스 프록시, 애플리케이션 리스너, 데이터베이스 포트 및 관리 도구를 나열하세요. 애플리케이션에 신중하게 구성된 로그인 화면이 있더라도 다른 인터페이스에 계속 접근할 수 있을 수 있습니다. 변경하기 전에 배포된 구성을 검사하고, 원격 접근을 제어하는 모든 항목에 대한 복구 경로를 유지하세요.
Docker가 설정의 일부인 경우 별도로 확인해야 합니다. 명시적인 호스트 주소가 없는 포트 매핑은 일반적으로 모든 호스트 주소에 게시됩니다. 루프백 바인딩은 문서화된 기본 NAT 사례에서 접근을 제한하지만, 네트워크 모드, 직접 라우팅 및 이전 Docker 동작이 중요합니다. 실제 토폴로지에 대한 문서를 읽고, 사용하는 IPv4 및 IPv6 경로를 통해 연결 가능성을 확인하세요. Docker 포트 게시 및 매핑.
4. 안심시키는 레이블이 아닌 실제 통제를 확인하세요.
네트워크 규칙을 생성하는 소프트웨어와 함께 방화벽을 검사하세요. Docker는 게시된 컨테이너 트래픽이 일반적인 UFW 입력 규칙이 적용되기 전에 우회될 수 있다고 문서화하고 있습니다. 따라서 깨끗해 보이는 UFW 상태가 컨테이너 포트에 접근할 수 없음을 증명하지는 않습니다. 빠른 해결책으로 Docker의 방화벽 관리를 비활성화하지 마세요. 문서에 네트워킹 결과가 설명되어 있습니다. Docker 패킷 필터링 및 방화벽.
애플리케이션 역할을 별도로 확인하세요. 예를 들어 BookStack은 역할 능력을 결합하고 콘텐츠 수준 재정의를 허용하므로 사용자의 실질적 권한이 할당된 하나의 역할 이름과 다를 수 있습니다. 전체 할당을 검토하고 대표적인 페이지와 첨부 파일을 테스트하세요. BookStack 권한 규칙.
5. 전송 및 신뢰를 계획에 포함하세요.
회원에게 제한된 서비스도 자격 증명과 비공개 콘텐츠를 포함합니다. 회원에게 브라우저 경고를 무시하도록 가르치는 대신 실제 클라이언트에 대한 HTTPS 및 인증서 신뢰를 계획하세요. 인증서 갱신 소유권과 실패 검사를 도메인 접근과 함께 노트북에 유지하세요.
Caddy의 문서는 공개 인증서 검증과 로컬 인증 기관을 구분합니다. 클라이언트는 경고 없이 인증서를 사용하려면 로컬 기관을 신뢰해야 합니다. 공개 인증서의 경우 HTTP 및 TLS-ALPN 검증에는 각각의 인바운드 경로가 필요합니다. DNS 검증은 별도로 구성된 대안입니다. 의도된 접근 경계에 맞는 방법을 선택하세요. Caddy 자동 HTTPS 및 로컬 신뢰.
이것은 접근 계획 단계이며, 인증서만으로 애플리케이션이 비공개되거나 적절히 승인된다는 주장이 아닙니다.
6. 허용 및 거부 경로를 모두 테스트하세요.
로그아웃한 방문자, 일반 회원 및 편집자를 위해 별도의 브라우저 세션을 사용하세요. 일반 페이지, 직접 로컬 첨부 파일 URL, 내보내기 작업 및 관리 경로를 확인하세요. 계정을 제거하거나 역할을 변경한 후 다시 테스트하세요. 예상치 못한 성공이 편의로 오인되지 않도록 작업을 시도하기 전에 예상 결과를 기록하세요.
테스트를 위해 권한이 부여된 네트워크에서 공개 서비스에 연결할 수 있고 의도된 비공개 인터페이스는 연결할 수 없는지 확인하세요. 다르게 확인될 수 있는 호스트 이름뿐만 아니라 관련 주소 패밀리와 실제 엔드포인트를 테스트하세요. 날짜, 소스 네트워크 및 결과를 기록하세요. 이러한 확인은 귀하의 설정에서 수행해야 하며, 여기서 완료된 것으로 주장되지 않습니다.
로그아웃 상태와 권한 없는 회원으로 기밀 포함 이미지를 직접 URL로 테스트하세요. BookStack 이미지는 로컬 첨부 파일과 달리 기본적으로 공개됩니다. 제한된 페이지만으로는 충분하지 않습니다. 검토 이미지 보안 그리고 접근 가이드의 저장소 및 권한 구분 경계를 수용하기 전에.
7. 실패한 경계는 재검토 결정으로 처리하세요.
권한 없는 계정이 데이터를 읽을 수 있다면 접근 확장을 중단하고 역할 상속, 공유 및 직접 파일 경로를 검사하세요. 비공개 포트에 연결할 수 있다면 추측으로 다른 계층을 추가하기 전에 바인딩 및 네트워크 규칙을 검토하세요. 의도된 유지 관리자가 연결할 수 없다면 모든 사람에게 더 넓은 접근을 부여하는 대신 문서화된 복구 경로를 사용하세요.
수정된 규칙과 반복 가능한 검사를 다음에 넣으세요: 접근 노트북. 다음에 연결하세요: 서비스 인벤토리 및 복구 연습. 이러한 경계는 올바르게 구현될 때 원치 않는 접근을 줄입니다. 익명성을 보장하거나 업데이트 및 신중한 데이터 처리의 필요성을 제거하지는 않습니다.
이 노트 뒤의 문서
실제로 실행하는 버전에 대한 설명서를 사용하십시오. 이 예시는 계획 자료이며, Hoszen VPS에서의 테스트 기록이 아닙니다.