앱이 mTLS와 SSO를 쓰는데 사이트 VPN이 여전히 필요할까요?
앱 로그인이 결코 다루지 않는 경로를 따라가 보고, 사설 네트워크 접근이 불필요한지 아니면 여전히 호스트로 가는 유일한 길인지 판단하십시오.
mTLS로 로그인하고 대시보드가 로드되며, 사이트 VPN이 이제 불필요하다는 주장은 새벽 두 시에 데이터베이스를 복원해야 할 때까지만 그럴듯하게 들립니다.애플리케이션의 TLS 경계는 하나의 경로만 설명합니다.호스트, 데이터베이스, 백업 대상, 클라우드 계정은 각자 고유한 진입 경로와 고유한 신원, 고유한 승인자를 가지고 있으며, 그중 어느 것도 성공한 로그인으로 검증되지 않습니다.
로그인 화면에서 바깥으로 걸어가십시오
일반 사용자처럼 로그인하고 요청이 거치는 모든 홉, 곧 브라우저, 에지, 애플리케이션 리스너, 세션 저장소, 백엔드 API를 적으십시오.각 홉에는 소유자와 인증 결정이 있습니다.이제 호스트에 패치를 적용하는 사람을 위해, 그리고 야간 백업을 작성하는 작업을 위해 같은 걸음을 반복하십시오.그 경로들은 보통 첫 홉에서 이미 갈라집니다.
그 갈라짐이 바로 답할 가치가 있는 질문입니다.사이트 VPN은 그 두 번째 경로의 모든 경로가 스스로 서는 진입 및 권한 부여 정책을 가질 때만 불필요합니다.
앱 로그인이 결코 다루지 않는 다섯 경로
아래 표는 인벤터리 템플릿이며 배포 점검표가 아닙니다.두 번째 열은 여러분의 환경이 오늘 실제로 강제하는 내용으로 채우십시오.
| Channel | Access decision to identify |
|---|---|
| Application API | Accepted TLS peer, application identity, permitted operations |
| Operating-system administration | Approved entry path, administrative identity, host permissions |
| Database maintenance | Database identity, protected connection, authorized maintenance role |
| Backup and restore | Service identity, allowed source, access to stored copies |
| Cloud control plane | Account and role permissions governing infrastructure changes |
하나의 신원 공급자를 공유한다고 해서 이 권한들이 합쳐지지는 않습니다.API 요청을 보낼 수 있는 사용자가 그렇다고 해서 VM 디스크를 교체하거나 애플리케이션의 자격 증명으로 데이터베이스를 복원할 권한을 얻지는 않습니다.NIST는 제로 트러스트 아키텍처 개요에서 바로 이 이유로 리소스 인증과 권한 부여를 네트워크 위치와 분리해 둡니다.
티켓을 읽을 수 있는 지원 엔지니어가 그렇다고 해서 그 뒤의 호스트에서 콘솔을 열 권한을 얻지는 않습니다.
경로는 대안이 닫혀 있을 때만 실제입니다
사설 관리 리스너로 도달 가능 범위를 제한하는 것은, 그 제한이 실제로 강제되고 그림으로만 남지 않는다면, 사이트 VPN의 정당한 대체물입니다.흔한 실패는 모든 인터페이스에 여전히 바인딩된 서비스, 계약자를 위해 열린 보안 그룹 규칙, 인터넷에서 도달 가능한 관리 포트처럼 아무도 기억하지 못한 대체 리스너입니다.
다이어그램이 아니라 리스너를 확인하십시오.호스트에서 ss -ltnp로 실제로 무엇이 바인딩되었는지 나열하고 관리 포트가 사설 주소에 있는지 확인하십시오.클라우드 콘솔에서 워크로드 서브넷의 인바운드 규칙을 읽고 관리용 항목에 0.0.0.0/0이 있는지 찾으십시오.그다음 그 시험이야말로 질문에 답하기 때문에 사설 경로 바깥에서 연결을 시도하십시오.
SSH에 세계에 열린 규칙이 하나만 있어도 터널 설계의 모든 논거가 무너집니다.
설계를 비교하기 전에 지도를 작성하십시오
인벤터리의 각 행마다 누가 신원을 승인하는지, 누가 접근 규칙을 갱신하는지, 누군가 떠날 때 누가 자격 증명을 제거하는지, 경로 자체가 끊길 때 누가 복구를 맡는지 기록하십시오.행마다 네 개의 이름이면 답이 공유 계정과 삼 년 된 위키 페이지인 행을 드러내기에 충분합니다.
그다음 경로마다 허용 하나와 거부 하나를 검증하십시오.허용은 의도한 신원이 의도한 경로로 리소스에 도달할 수 있음을 증명합니다.거부는 비슷한 신원이 도달할 수 없음을 증명하며, 사람들이 건너뛰는 시험이 바로 이것이므로 대체 리스너가 감사에서 살아남습니다.제안된 설계를 이 결과들과 비교하고, 이들 중 어느 것도 시험한 적이 없는 애플리케이션의 TLS 구성과 비교하지 마십시오.
사이트 VPN이 여전히 제 몫을 하는 곳
터널이나 좁은 게이트웨이는 데이터베이스 유지 관리 포트, 백업 대상, 하이퍼바이저 콘솔, 대역 외 관리처럼 리소스에 요청별 자체 인증이 없을 때 올바른 답입니다.그 리스너들은 네트워크를 신뢰하므로, 호출자를 인증하는 것은 네트워크여야 합니다.
그것이 유일한 답은 아닙니다.리소스별 권한 부여를 종료하는 게이트웨이는 서브넷 전체 터널보다 좁을 수 있고 공유 점프 호스트보다 나은 감사 추적을 남깁니다.
작업 순서는 인벤터리를 완료하고, 대안을 닫고, 행마다 거부 하나를 검증한 뒤에야 터널을 폐기하는 것입니다.어떤 행이 거부를 만들어내지 못한다면, 만들어낼 수 있을 때까지 사설 경로를 유지하십시오.