VPN 뒤의 SaaS 관리 영역: 어떤 주소를 신뢰해야 하는가?

원본은 노트북의 터널 주소가 아니라 VPN 게이트웨이의 이그레스 주소를 봅니다. 구성된 프록시 헤더만 신뢰하고, 그다음 모든 관리 작업을 게이트하십시오.

공개 SaaS 페이지는 누구에게나 열려 있을 수 있지만 그 뒤의 관리 작업은 VPN 밖의 모든 사람을 거부합니다. 이를 가능하게 하는 메커니즘은 숨겨진 메뉴나 별도의 로그인 페이지가 아니라 요청을 전달한 네트워크 경로에 대한 검사입니다. 주소 증거를 잘못 잡으면 검사는 실제 관리자를 잠그거나 헤더를 입력할 수 있는 누구든 들여보냅니다. 원본이 실제로 무엇을 받는지부터 시작하십시오.

터널 뒤에서 원본이 실제로 받는 것

브라우저가 인터넷 트래픽도 운반하는 VPN을 통해 공개 사이트에 도달하면 게이트웨이는 연결이 나가기 전에 변환합니다. SaaS는 게이트웨이의 공개 이그레스 주소, 보통 하나의 주소나 작은 범위를 보며, 노트북의 터널 주소는 절대 보지 않습니다. 그래서 10.90.0.42을 허용 목록에 넣으면 실패하고, RFC 1918 전체를 넣으면 더 크게 실패합니다: 후자는 당신에게 도달할 수 있는 모든 사설 네트워크를 들여보내기 때문입니다. 조건을 걸 가치가 있는 유일한 주소는 조직이 출구에서 실제로 소유한 주소입니다.

curl -s https://ifconfig.me
dig +short admin.example.com

분할 터널링은 이 가정을 조용히 깨뜨립니다. VPN이 사설 사무실 경로만 운반하면 공개 관리 호스트명으로 가는 요청은 로컬 ISP를 통해 나가고 원본은 주거용 주소를 봅니다. 연결된 VPN 아이콘은 이 특정 목적지에 대해 아무것도 증명하지 않으므로 터널이 아니라 목적지를 시험하십시오.

출구 주소가 사용자마다 다르면 어떤 정책을 쓰기 전에 멈추고 라우팅을 고치십시오. 일부 관리자에게만 맞는 조건은 사고가 날 때까지 문제를 숨기므로 조건이 없는 것보다 나쁩니다.

주소를 다시 쓰는 프록시만 신뢰하십시오

대부분의 공개 사이트는 CDN이나 리버스 프록시 뒤에 있으므로 원본의 소켓 주소는 방문자가 아니라 그 프런트엔드의 것입니다. 프런트엔드는 보통 원래 주소를 헤더로 전달하며, 그 헤더는 원본이 알려진 프록시에서만 받아들이지 않는 한 공격자가 제어합니다. 신뢰할 소스 목록을 명시적으로 구성하고 원본을 다른 어디에서도 도달할 수 없게 만드십시오. 그 뒷부분이 없으면 공격자는 프록시를 건너뛰고 헤더를 직접 보냅니다.

set_real_ip_from 192.0.2.0/24;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
curl -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin

같은 논리가 PROXY 프로토콜에도 적용됩니다: 리스너가 프록시만 도달할 수 있고 다른 것은 도달할 수 없는 인터페이스에 바인딩되어 있을 때만 신뢰할 수 있습니다. 주소 컨텍스트가 없으면 기본 허용으로 흘러가지 말고 보호된 검사를 실패시켜야 합니다. 없는 헤더는 신뢰할 수 있는 경로의 증거가 아닙니다.

조건을 모든 보호된 작업에 붙이십시오

검사를 메뉴를 렌더링하는 페이지가 아니라 모든 보호된 작업이 지나는 권한 부여 경계에 두십시오. 라우트 그룹, 미들웨어 또는 정책 계층은 모두 작동하지만, 핸들러마다 복사하는 것은 다음 분기에 누군가 추가하는 핸들러에 그것이 없기 때문에 작동하지 않습니다.

user = requireAuthenticatedSession()
requirePermission(user, "admin")
requireVpnEgress(verifiedClientAddress(request))
performProtectedOperation(user, request)

같은 경계는 어느 것도 먼저 HTML 페이지를 요청할 필요가 없는 JSON API, 내보내기, 서명된 다운로드 URL, WebSocket 핸드셰이크도 포괄해야 합니다. VPN이 켜져 있을 때 발급된 다운로드 링크는 다운로드 엔드포인트가 다시 검사하지 않는 한 이후에도 유효합니다. 장기 세션에도 재평가 규칙이 필요하며, 그렇지 않으면 인증된 요청 하나가 영구적인 예외가 됩니다. 기본 거부만이 직원 교체를 견디는 설정입니다.

공유 캐시는 검사를 우회하는 다른 길입니다. 보호된 응답을 이미 보유한 캐시는 원본에 접촉하지 않고 그것을 제공할 수 있으므로 관리 응답을 비공개로 표시하고 공유 저장소에서 빼십시오. 캐시가 그것을 제공해야 한다면 접근 검사가 제공 전에 실행되어야 하며, 이는 보통 공유 캐시일 수 없다는 뜻입니다.

방금 닫은 우회 경로를 시험하십시오

행복한 경로가 아니라 매트릭스를 연습하십시오: VPN을 통과하는 관리자, 그것 없이 같은 관리자, 그것을 통과하는 비관리자, 위조된 주소 헤더입니다. 프런트엔드를 완전히 건너뛰는 원본 직접 요청과 캐시된 응답 요청도 추가하십시오.

curl -sI https://admin.example.com/export.csv
curl -s -H 'X-Forwarded-For: 198.51.100.27' https://origin.example.com/admin
curl -s https://admin.example.com/api/me -o /dev/null -w '%{http_code}\n'

각 요청은 정책이 약속한 상태를 반환해야 하고, 로그는 어떤 주소 증거가 사용되었는지 기록해야 합니다. 이중 스택 원본은 시험한 것과 다른 소스 패밀리를 볼 수 있으므로 IPv6은 따로 다루십시오. 고객이 처음 불평할 때 변경이 되돌려지지 않도록 일반 고객 작업은 VPN 밖에서도 작동하게 두십시오. 놀라운 통과가 보이도록 실행 전에 각 행의 예상 결과를 적으십시오.

이그레스 주소는 허용된 네트워크 경로를 증명할 뿐 사람도 관리 장치도 아닙니다. 인증과 권한 옆의 한 조건으로 유지하면 제품 전체를 VPN 전용 서비스로 만들지 않고도 관리 영역은 좁게 유지됩니다. 그 분리가 설계이며 그 한계가 아닙니다.

관련 글