Identity-Aware Proxy를 사용한다면 VPN이 아직 필요할까요?

가정은, ID를 인식하는 프록시가 내부 앱 앞에 서면 VPN은 장식일 뿐이고 클라이언트는 떠나도 된다는 것입니다. 이는 사람이 브라우저에서 쓰는 대화형 HTTPS 앱이라는 좁은 한 경우에만 맞고, 나머지 모든 곳에서는 조용히 실패합니다. 프록시는 리소스에 대한 요청을 승인하고, VPN은 클라이언트를 네트워크 범위로 들입니다만, 이 두 경계가 일치하는 경우는 드뭗니다. 터널을 폐기하기 전에 다이어그램의 제품 이름이 아니라 현장이 실제로 수행하는 작업을 비교하세요.

두 게이트는 서로 다른 것을 승인한다

애플리케이션 게이트는 이 ID에서 온 이 요청이 이 보호된 리소스에 도달해도 되는지 결정합니다. Google의 Identity-Aware Proxy 개요가 설명하는 것이 바로 이 형태로, HTTPS 앱 앞의 중앙 승인 계층을 IAM 역할이 움직입니다. 경계는 리소스이고 접근의 단위는 요청입니다. 라우팅된 VPN은 더 거칠고 넓은 일을 하며, 클라이언트를 정의된 네트워크 범위로 들이고, 그다음에도 앱이 그 클라이언트가 무엇을 할 수 있는지 결정합니다.

어느 모델도 다른 쪽을 함의하지 않습니다. 게이트를 통과하는 것은 특정 레코드를 읽는 것에 대해 아무 말도 하지 않고, 네트워크에 있는 것은 행동 허가에 대해 아무 말도 하지 않습니다.

프록시가 덮지 않고 VPN이 덮는 것

SSH 세션, 데이터베이스 클라이언트, 메시지 브로커, 그리고 어느 브라우저도 열지 않는 내부 호스트 이름은 웹 프록시가 있다고 해서 접근 가능해지지 않습니다. 각각은 자기 프로토콜을 쓰고, 각각은 자체 인증 경로나 그것을 나르는 네트워크가 필요합니다. 이것이 이전 첫날 사람들이 발견하는 간극이며, 대개 호스트 이름을 더 이상 해석할 수 없는 노트북을 든 온콜 엔지니어에게서 나옵니다.

반대 간극도 똑같이 현실입니다. 클라이언트를 서브넷으로 들이는 VPN은 그 안의 사람을 인증하지 않고, 그 서브넷의 침해된 기기는 네트워크가 허용하는 것을 물려받습니다. 요구가 감사 가능한 ID로 요청별 승인이라면 라우팅만으로는 그것을 만들 수 없습니다. 대부분의 조직은 결국 둘 다 운영하고, 흥미로운 질문은 어느 리소스 앞에 어느 쪽이 설 수 있는가입니다.

클라이언트 워크플로가 아키텍처 다이어그램보다 많이 결정한다

리다이렉트와 가끔의 MFA 챌린지가 있는 브라우저 로그인은 북마크를 클릭하는 사람에게 좋은 경험입니다. cron 작업, CLI, 빌드 에이전트에는 브라우저가 없고 대화형 프롬프트에 답할 수 없으므로 문서화된 비대화형 경로나 터널이 필요합니다. 그 요구의 발견은 대개 설계가 승인된 뒤에 일어납니다.

앱을 세기 전에 클라이언트를 세세요. 대시보드 하나는 백 명을 서비스할 수 있지만, 데이터베이스 포트 하나는 팀 전체를 막을 수 있습니다.

기기 상태는 어느 게이트의 속성도 아니다

VPN 클라이언트 설치가 준수 검사는 아니고, 브라우저 기반 설계가 관리 기기 정책을 지킬 수 없다고 자동으로 정해지지도 않습니다. 둘 다 상태 신호와 통합될 수 있고, 둘 다 없이 배포할 수 있습니다. 제품의 형태에서 추론하지 말고 어느 집행이 있는지, 정책은 누구 것인지, 실패한 기기는 어떻게 되는지 물으세요.

같은 주의가 접근 회수에도 적용됩니다. 프록시에서 그룹 멤버십을 지우는 것과 터널의 인증서를 폐기하는 것은 지연이 다른 다른 작업이며, 둘 중 하나는 퇴사 시 대개 잊힙니다.

무엇이든 폐기하기 전에 대체 경로를 찾으세요

프록시 뒤의 보호되지 않은 오리진, 그것을 우회하는 두 번째 호스트 이름, 이전 설계에서 남은 넓은 사설 경로가 실제로 어느 게이트가 유효한지 결정합니다. 허용되는 작업과 거부되는 작업을 콘솔이 아니라 실제 클라이언트로 시험하고, 한 번도 등록되지 않은 기기에서 시험하세요. 거부 사례가 게이트가 무언가를 하는지 알려줍니다.

다음으로 등록, 업데이트, 접근 회수, 그리고 새벽 2시에 잠긴 사람의 복구 경로라는 인수인계를 쓰세요. 프롬프트나 클라이언트 앱을 없애는 것은 팀 사이로 책임을 옮기는 뿐 책임을 지우지 는 않습니다.

이번 주에 결정한다면 제품 목록이 아니라 작업 목록에서 시작하고, 브라우저가 할 수 있는 것을 표시하고, 나머지가 살아남는 네트워크 접근을 정당화하게 하세요.