VPN 사용자에게는 서브넷이 아니라 한 서비스에 대한 접근을 주세요

한 계약업체에게는 내부 웹 애플리케이션 하나만 있으면 되고 다른 것은 필요 없으므로, 쉬운 답은 그에게 서버 서브넷으로 가는 터널을 주는 것입니다. 그것은 그가 스캔하는 날까지 작동합니다. 도달 가능성, 라우팅, 애플리케이션 권한이 서로 맞아야 하는 세 가지 별개의 제어이기 때문에 더 좁은 설계는 더 많은 고민을 요구합니다.

요구 사항을 서브넷이 아니라 서비스로 작성하세요

대상 호스트, 프로토콜, 포트에서 시작하고, 그다음 도달해야 하는 사용자 또는 기기 그룹을 추가하세요. 프라이빗 DNS 영역은 애플리케이션이 이름을 확인할 때만 포함하고, ID 공급자는 로그인 흐름에 필요할 때만 포함하세요. 나머지는 아직 정당화하지 않은 의존성입니다.

서브넷은 네트워크 팀의 구현 세부 사항이고, 서비스는 비즈니스가 요청한 것이며 검토하고 폐기할 수 있는 단위입니다.

의존성 목록이 세 항목을 넘으면 애플리케이션에 자체 설계 논의가 필요할 가능성이 큽니다.

좁게 라우팅하되 강제는 다른 곳에서 하세요

좁은 경로나 선택기는 터널에 어떤 패킷을 실을지 알려 줄 뿐 인가 정책이 아닙니다. 게이트웨이 필터, 대상 호스트의 방화벽, 애플리케이션 자체의 권한 모델이 접근이 결정되는 곳입니다. 한 주소만 덮는 경로는 좋은 시작이고, 결심한 사용자를 막는 제어는 아닙니다. 바로 그 분리가 터널을 다시 설계하지 않고 필터를 바꿀 수 있게 합니다.

반대로 엄격한 필터를 가진 넓은 경로도 정당할 수 있지만, 관련된 모두가 둘 중 어느 것이 강제를 수행하는지 알 때만 그렇습니다.

강제 지점을 명시적으로 문서화하지 않으면 다음 변경이 그것을 실수로 옮깁니다.

서비스가 실제로 보는 출발지를 확인하세요

대상은 변환 여부에 따라 클라이언트 풀 주소나 게이트웨이 주소를 봅니다. 호스트 방화벽 규칙과 로그는 실제 출발지와 일치해야 합니다. 여러 사용자가 변환된 출발지를 공유하면 그 호스트의 사용자별 규칙으로는 구분할 수 없고, 이는 설계 제약이지 버그가 아닙니다.

변환은 라우팅을 단순하게 하지만 출발지 신원을 파괴하며 감사와 사용자별 규칙에 중요하므로 의도적으로 선택하세요.

둘 중 무엇을 선택했는지 그것에 의존하는 규칙 옆에 적으세요.

애플리케이션 인가는 선택 사항이 아닙니다

포트에 도달한다고 역할이 부여되지는 않습니다. 애플리케이션은 네트워크 계층이 사용자가 편집할 수 있는 레코드를 표현할 수 없으므로 여전히 자체 로그인과 자체 권한이 필요합니다. 내부 서브넷의 모든 요청을 신뢰하는 서비스는 좁은 터널을 하나의 탈취된 자격 증명에 대한 전체 접근으로 바꿉니다. 터널은 누가 소켓을 열 수 있는지 결정하고, 애플리케이션은 그것으로 무엇을 할 수 있는지 결정합니다.

도달 가능한 호스트가 적으면 애플리케이션 수준의 실수를 악용할 곳도 적어지므로 여기서 좁은 설계는 두 번 이득을 봅니다.

네트워크 규칙과 애플리케이션 역할을 별도 시스템에 두고, 별도로 폐기하세요.

허용된 경로와 거부된 경로를 모두 증명하세요

권한이 있는 사용자로 연결해 무해한 대표 작업을 하나 수행한 다음, 도달할 수 없어야 하는 대상을 시도하세요. 앞부분만 시험하는 설계는 시험된 것이 아니며, 설계를 증명하는 것은 거부 시험입니다. 규칙을 바꿀 때마다 새 세션으로 시험하고, 요청은 도착하지만 응답이 오지 않으면 반환 경로를 보세요.

수용 시험을 통과시키려고 전달 필터를 끄면 시험 대상 자체가 바뀌므로 끄지 마세요.

사용자가 더 이상 서비스가 필요하지 않으면 원격 ID와 애플리케이션 역할을 각자의 시스템에서 폐기하고 둘 다 기록하세요. strongSwan 전달 가이드는 경로의 게이트웨이 쪽을 다룹니다.