포트 사이의 방화벽은 호스트 경계가 아니다

웹사이트는 443에서 응답하고, VPN은 1194에서 응답하며, 방화벽은 정확히 그 둘만 허용하고, 검토는 통과한다. 그 순서 어디에서도 웹 워커가 무엇을 읽을 수 있는지, 어떤 파일을 다시 쓸 수 있는지 묻지 않았다. 침해된 워커는 제어 소켓이나 쓰기 가능한 설정 디렉터리에 닿을 수 있다면 열린 포트가 필요 없다. 경계는 권한이고, 리스너는 눈에 잘 띄는 부분일 뿐이다.

별도의 서비스 이름은 라벨에 불과하고, 별도의 정체성이 곧 보안 속성이다.

포트가 아니라 워커의 권한을 세라

실행 사용자, 그 그룹, 권한, 파일시스템 보기에서 시작하라. 우연히 VPN 그룹에 속한 서비스 계정은 열린 포트 없이도 키 자료를 읽을 수 있다. 쓰기 가능한 마운트가 나머지 절반이며, 업로드와 캐시는 정책 파일과 비밀에서 멀리 있어야 하고, 불필요하게 공유된 쓰기 가능 디렉터리는 정돈된 이름을 무력화한다. 권한 있는 부모와 권한 없는 워커는 하나의 권한을 공유하지 않으므로 그 작업을 수행할 프로세스를 확인하라.

데몬 시작 중에 VPN 키를 읽을 수 있다고 해서 웹 워커가 그것을 필요로 하는 것은 아니다. 데몬이 하는 읽기와 애플리케이션에 부여된 접근을 분리하라.

보이는 것보다 많이 주는 소켓

일부 엔드포인트는 메트릭 피드의 옷을 입은 관리용 API다. VPN의 관리 인터페이스는 세션을 바꾸고, 클라이언트를 끊고, 상태를 읽을 수 있다. 컨테이너 런타임 소켓은 더 넓어서, 그것에 접근하는 것은 사실상 호스트 제어이며, 웹 애플리케이션에 필요한 범위를 훨씬 넘는다. 둘 다 평범한 애플리케이션의 마운트 집합에 속하지 않고, 수신 포트를 세어도 나타나지 않는다.

관리 리스너를 로컬 주소에 바인딩하기는 시작일 뿐 완전한 제한이 아니다. 그 주소로 들어오는 모든 경로가 여전히 중요하므로 의도한 소스와 인터페이스만 허용하라.

컨테이너는 하나의 커널을 공유한다

컨테이너는 프로세스, 파일시스템, 네트워크 경계를 더하지만 호스트와 하나의 커널을 공유하므로, 권한 선택과 호스트 마운트와 데몬 접근이 결정적이다. 호스트 비밀을 마운트하거나 특권 런타임 제어를 부여하면 컨테이너라는 라벨이 암시하는 경계가 지워진다. 별도 VM은 실제로 별도 게스트 커널을 주지만, 하이퍼바이저, 관리 정체성, 스토리지, 백업은 공유된 채로 남는다. 설정과 업데이트에 이름 있는 소유자가 있는 경계를 고르라.

아무도 유지하지 않는 더 정교한 구성은 실제로 검토되는 단순한 구성보다 나쁘다.

먼저 거부를, 다음으로 서비스를 시험하라

워커의 실제 맥락에서 승인된 점검을 사용해 VPN 정책을 바꿀 수 없고, 불필요한 비밀을 읽을 수 없으며, 관리 인터페이스에 닿을 수 없음을 확인하라. 관리자로서의 성공적인 읽기는 그 거부에 대해 아무것도 시험하지 않는다. 그다음 웹사이트, 허용된 평범한 VPN 작업, 그리고 재시작할 때 각각에 무슨 일이 일어나는지 검증하라. VPN 복구에 의존하지 않는 복구 경로를 남겨 두어 실수가 복구 가능하게 하라.

두 역할은 여전히 CPU, 메모리, 업링크 용량, 유지보수 이벤트를 공유한다. 권한 경계가 깨끗하더라도 그 공유 자원은 계획에 포함되어야 한다.

각 프로세스가 무엇을 할 수 있는지, 멈추면 무엇이 실패하는지, 어떤 경계가 공유된 채 남는지 기록하라. 포트 수는 그 기록이 아니다.