기업 웹 앱을 VPN 뒤로 옮기기: 전환 안내서

사용자 쪽에서 변화를 상상해 보십시오. 누군가 북마크를 클릭하고 익숙한 로그인 페이지를 기대하지만, 호스트 이름이 이제 터널 안에서만 응답하기 때문에 대신 연결 오류를 받습니다. 그 한 순간에는 마이그레이션 계획이 올바르게 해내야 할 모든 것, 즉 이름, 경로, 인증서, 계정, 그리고 그 뒤의 작업이 담겨 있습니다. 아래 단계를 그 순서대로 진행하면 전환은 더 이상 도약이 아닙니다.

1단계: 사용자가 오늘 무엇을 하는지 적으십시오

주소 표시줄의 호스트 이름, 포트, 사람들이 수행하는 작업, 사용하는 계정부터 시작하십시오. 주요 작업 세 가지를 말할 수 없다면 인수 단계에서 고장 난 작업을 알아보지 못할 것이므로 공개 진입점을 닫을 준비가 되지 않은 것입니다.

그다음 비공개 대상이 누구인지 정하십시오. 기업 VPN의 직원은 시작일 뿐 답이 아닙니다. 계약자, 지원 인력, 재무 팀이 모두 앱이 필요할 수 있고 모두 같은 게이트웨이 뒤에 있지 않을 수 있습니다.

2단계: 터널과 로그인을 분리하십시오

사용자가 VPN을 통해 앱에 도달해도 브라우저는 여전히 앱 자체의 엔드포인트로 TLS 연결을 엽니다. 인증서는 그 이름과 일치해야 하고 앱은 여전히 계정을 인증합니다. 터널은 둘 중 어느 것도 대체하지 않습니다.

여기서 마이그레이션이 조용히 잘못됩니다. 누군가 비공개 주소에 더 이상 유효한 인증서가 필요 없다고 결정하고, 사용자는 경고를 클릭해 넘어가는 법을 배우고, 조직은 공개 노출을 보안 경고 무시 훈련 프로그램과 맞바꾼 셈이 됩니다. 앱에 정말 내부 인증서가 필요하다면 내부 기관에서 발급하고 신뢰를 제대로 배포하십시오. 그것은 통제된 변경이며, 경고 페이지는 아닙니다.

권한 부여는 이미 있는 곳에 두십시오. NIST의 제로 트러스트 아키텍처 개요는 네트워크 위치가 민감한 작업을 부여할 이유가 아니라고 직접 말합니다. 터널 안에 있다고 해서 읽기 전용 계정이 관리자가 되어서는 안 됩니다.

3단계: 직원이 아닌 호출자를 찾으십시오

앱 구성을 열고 ID 공급자의 콜백 URL, 결제 공급자의 웹훅, 예약된 가져오기, 모니터링 프로브, 파트너의 API 클라이언트처럼 앱과 통신하는 모든 것을 나열하십시오. 각각은 소유자가 있는 의존성이며 각각 다른 시점에 깨집니다.

남아야 하는 각각에 대해 지원되는 경로를 정하십시오. 웹훅 공급자는 직원 VPN에 참여할 수 없으므로 자체 인증을 갖춘 좁은 범위의 통합 엔드포인트를 노출하거나 통합 모델을 바꾸십시오. 콜백이 하나 있다고 앱 전체를 공개로 두는 것은 선택이며 대개 잘못된 선택입니다.

각 예외를 목적지, 허용된 작업, 인증, 소유자와 함께 적으십시오. 통합에 일반 VPN 계정을 넘겨주는 것이 예외를 영구화하는 방법입니다. 통합은 그것을 추가한 프로젝트보다 오래 살아남기 때문에 다음 접근 검토에서 목록을 검토하십시오. 만료일이 없는 예외는 아무도 내리지 않은 영구적인 설계 결정입니다.

4단계: DNS 레코드만이 아니라 공개 경로를 폐기하십시오

게시 체인, 즉 DNS, 로드 밸런서 리스너, 리버스 프록시 규칙, 호스트 방화벽, 그리고 여전히 이전 주소를 가리키는 모든 대체 이름을 따라가십시오. 두 주소 체계를 모두 확인하십시오. 이전 CNAME이나 IPv6 리스너가 여전히 앱을 제공한다면 기본 A 레코드 변경은 거의 아무것도 증명하지 못합니다.

동시에 비공개 이름이 터널 안에서 확인되고 인증서가 사용자가 입력할 이름을 포함하는지 확인하십시오. 숫자 주소를 붙여넣어야 하는 사용자는 증상을 발견한 것이지 해결책을 찾은 것이 아닙니다.

VPN 대상을 앱 경로로 제한하십시오. 사무실 네트워크에 대한 광범위한 접근은 하나의 노출 결정을 더 큰 결정과 맞바꾸며, 관리 인터페이스는 사용자 규칙을 상속하는 대신 자체 허용 소스가 필요합니다.

5단계: 인수를 직접 수행하십시오

승인된 사용자로 연결하고 북마크를 열고 인증서를 확인하고 로그인하여 실제 작업 하나를 수행하십시오. 그런 다음 그 작업이 없어야 할 계정으로 시도해 거부되는지 확인하십시오. 그다음 VPN 밖의 장치에서 시도해 앱에 도달할 수 없음을 확인하십시오.

유지한 각 통합에 대해 반복하고, 자체 테스트 도구의 200이 같은 것이라고 가정하지 말고 공급자의 전달 로그를 읽으십시오. 성공적인 VPN 로그인은 이 결과들 중 어느 것의 증거도 아닙니다.

6단계: 나쁜 날을 연습하십시오

터널 중단 시 작업이 멈추는지 다른 승인된 접근 방식이 이어받는지 정하십시오. 무엇을 선택하든, 문서화되지 않은 복구 수단으로서의 긴급 공개 재개는 결국 압박을 받는 누군가가 수행하게 되므로 적어 두고 한 번 시험하십시오.

게이트웨이와 앱을 유지하는 관리자에게 소유자와 제거 날짜를 붙여 복구 접근을 유지하십시오. 변경과 그 되돌림 조건을 같은 곳에 기록하여 실패한 마이그레이션이 고칠 사람들을 잠그지 않게 하십시오.

전환 후에도 패치, 계정 수명 주기, 앱 권한 부여, 감사는 여전히 귀하의 몫입니다. 터널은 진입점을 좁혔지만 그 작업들 중 어느 것도 넘겨받지 않았습니다.