Remote Browser Isolation 제로 트러스트 아키텍처를 어떻게 Remote Browser Isolation

Remote browser isolation RBI)는 제로 트러스트의 핵심 원칙, 즉 어떤 콘텐츠, 세션, 기기에도 암묵적인 신뢰를 절대 부여하지 말아야 한다는 점을 가장 직접적으로 구현한 기술 중 하나입니다. NIST SP 800-207 원칙 및 CISA 제로 트러스트 성숙도 모델에 따라 제어 수단을 매핑하는 보안 설계자에게 있어, RBI는 SWG URL 필터링이나 엔드포인트 탐지만으로는 해결할 수 없는 취약점, 즉 판정이 내려지기 전에 실행되는 브라우저 기반 위협을 차단합니다. 이 글에서는 RBI가 제로 트러스트의 ‘명시적 검증’, ‘최소 권한’, ‘침해 가정’ 원칙과 정확히 어떻게 연계되는지, 그리고 현대적인 SSE 스택 내에서 ZTNA, SWG, CASB, DLP와 함께 어떤 위치를 차지하는지를 설명합니다.

Remote Browser Isolation란 무엇인가요?

Remote browser isolation (Remote browser isolation Browser Isolation)Remote browser isolation 웹 브라우징 세션을 클라우드 호스팅 컨테이너 내에서 실행함으로써, 모든 웹 코드를 사용자의 엔드포인트와 물리적으로 분리하는 보안 Remote browser isolation . 로컬 기기는 활성 웹 코드를 직접 처리하지 않으며, 대신 픽셀 스트림이나 정제 및 재구성된 DOM만 수신합니다.

중견 제조업체의 조달 분석가가 신규 공급업체로부터 링크를 받는 상황을 상상해 보십시오. 해당 도메인은 지난주에 등록되었으며, URL 평판 정보가 전혀 없고, 기존 SWG(웹 게이트웨이)가 이를 차단하여(분석가를 당황하게 만들거나) 허용하여(알 수 없는 것을 신뢰하게 되는) ‘분류되지 않은’ 회색 지대에 속해 있습니다. RBI를 사용하면 해당 페이지는 일회용 클라우드 컨테이너 내에서 로드됩니다. 분석가는 양식을 작성하거나 PDF를 다운로드하는 등 완전히 상호작용이 가능한 페이지를 볼 수 있지만, 자바스크립트, 액티브X, 내장된 악성 코드 등은 절대 자신의 노트북에 닿지 않습니다. 페이지에 제로데이 취약점이 숨겨져 있더라도, 탭을 닫는 순간 삭제되는 컨테이너 내에서 무해하게 실행될 뿐입니다.

이 모델은 그 어느 때보다 중요합니다. 구글 위협 인텔리전스 그룹(GTIG)은 2024년에 실제 환경에서 악용된 제로데이 취약점 75건을 추적했으며, 이 중 44%는 기업용 기술을 표적으로 삼았습니다(GTIG, 2025년 4월). 브라우저 기반 공격 체인은 여전히 지속적인 공격 경로로 남아 있으며, RBI는 위협이 알려진 것이든 아니든 상관없이 다층적 방어 체계를 제공합니다.

제로 트러스트에서 RBI가 중요한 이유

제로 트러스트는 구매할 수 있는 제품이 아니라 일련의 설계 원칙입니다. NIST SP 800 207(2020)에 따르면, 제로 트러스트는 자산이나 사용자 계정에 대해 단순히 물리적 위치나 네트워크 위치, 또는 자산 소유권만을 근거로 암묵적인 신뢰를 부여하지 않는 것을 전제로 합니다. 그러나 브라우저는 전통적으로 암묵적 신뢰를 기반으로 작동해 왔습니다. 즉, URL이 SWG 허용 목록을 통과하거나 도메인에 유효한 인증서가 있는 경우, 엔드포인트는 서버가 전달하는 모든 코드를 로드하고 실행합니다. 이는 세션 수준 상호작용에 적용된 경계 신뢰 모델입니다.

성숙도 격차는 여전히 뚜렷합니다. 가트너(Gartner)의 2024년 제로 트러스트 도입 설문조사에 따르면, 응답 기업의 63%가 제로 트러스트 전략을 전면 또는 부분적으로 도입했다고 답했으나, 가트너는 대부분의 기업에서 제로 트러스트가 여전히 전체 환경의 절반 이하만을 포괄하며, 전체 기업 위험의 4분의 1 이하만을 완화하고 있다고 지적했습니다. 남아 있는 가장 중요한 격차 중 하나는 브라우저 세션입니다. 가트너에 따르면 브라우저는 대부분의 최신 기업 애플리케이션에 대한 주요 접근 수단이지만, 현재 안전한 기업용 브라우저를 도입한 조직은 10% 미만에 불과하며, 가트너는 2028년까지 도입률이 25%까지 상승할 것으로 예측하고 있습니다. 브라우저는 직원들이 매일 SaaS 애플리케이션, AI 도구 및 외부 사이트와 상호작용하는 공간이지만, 많은 조직은 여전히 세분화된 가시성, 정책 및 데이터 보호 통제 조치를 적용하기보다는 단순한 허용/차단 모델로만 브라우저를 다루고 있습니다.

제3자 공급업체가 호스팅하는 규제 포털에 접속하는 금융 서비스 규정 준수 담당자를 생각해 봅시다. SWG는 해당 도메인을 “정부”로 분류하여 접근을 허용합니다. 하지만 공급업체의 포털에는 취약점이 있는 플러그인이 실행 중이며, 공격자가 악성 iframe을 삽입해 놓았습니다. RBI가 없다면, 담당자의 엔드포인트는 이제 공격 표면이 됩니다. RBI가 있다면, iframe은 격리된 컨테이너 내에서 로드되므로 악성 페이로드는 엔드포인트에 도달하지 못하며, 담당자는 위협이 존재했다는 사실조차 모른 채 업무를 마칠 수 있습니다.

RBI가 세 가지 제로 트러스트 원칙과 어떻게 부합하는가

명시적으로 확인하십시오

NIST SP 800-207은 어떤 자산도 본질적으로 신뢰할 수 없다고 규정하며, 기업은 모든 리소스 요청을 평가할 때 해당 자산의 보안 상태를 평가해야 합니다. RBI는 웹 세션 계층에서 이 원칙을 실제 운영에 적용합니다. RBI는 URL 평판에 기반하여 이분법적인 신뢰 여부를 결정하는 대신, 모든 적격 세션을 격리된 환경에서 렌더링하고 컨테이너 내에서의 동작을 통해 콘텐츠를 평가합니다. 이를 통해 검증 방식이 일회성 게이트(URL 확인)에서 지속적인 격리 모델로 전환되며, 이 모델에서는 "신뢰할 수 있는" 도메인이라 하더라도 엔드포인트에서 원시 코드 실행 권한을 부여받지 못합니다.

의료 청구 처리 담당자가 파트너 포털을 열고 ‘드라이브 바이 다운로드’를 유발하는 페이지로 이동할 때, 다단계 인증(MFA), 기기 규정 준수, URL 평판과 같은 기존의 명시적 검증 단계는 이미 통과된 상태입니다. 사용자는 인증되었고, 기기는 관리되고 있으며, URL은 안전한 것으로 분류되었습니다. RBI는 추가적인 검증 단계를 더합니다. 즉, 이전의 모든 검사가 통과된 후에도 웹 콘텐츠 자체가 엔드포인트에서 실행되는 것은 신뢰되지 않습니다.

최소 권한 원칙

NIST SP 800-207은 최소 권한 원칙을 적용하여 가시성과 접근성을 모두 제한하도록 규정하고 있습니다. RBI는 웹 콘텐츠 전달에 최소 권한 원칙을 적용합니다. 사용자는 업무 수행에 필요한 정보, 즉 렌더링된 페이지의 시각적 표현만 제공받습니다. 사용자는 원시 JavaScript, CSS 또는 실행 가능한 객체를 제공받지 않습니다. RBI와 통합된 DLP 제어 기능은 세션의 기밀 수준에 따라 클립보드 작업, 인쇄, 파일 업로드 및 다운로드를 추가로 제한할 수 있습니다.

구체적인 예를 들어보자. 관리형 서비스 제공업체가 ZTNA를 통해 계약직 직원들에게 회사의 티켓팅 시스템에 대한 접근 권한을 부여한다. 계약직 직원들은 인증을 거치고, 기기 규정 준수 검사를 통과한 후 애플리케이션에 접속한다. 하지만 보안 설계자는 RBI 정책도 적용합니다. 즉, 계약업체의 세션은 격리된 환경에서 실행되며, 복사/붙여넣기 기능이 비활성화되고 다운로드가 평면화된 PDF 파일로만 제한됩니다. 계약업체는 티켓을 조회하고 수정할 수 있지만, 원시 데이터를 추출할 수는 없습니다. 이는 네트워크 접근 권한뿐만 아니라 세션 내에서 사용자가 수행할 수 있는 작업에도 ‘최소 권한 원칙’을 적용한 사례입니다.

보안 침해 발생을 가정한다

NIST SP 800 207은 네트워크가 항상 적대적이며, 외부 및 내부 위협이 상시 존재한다고 가정합니다. RBI는 설계상 이 원칙을 반영하고 있습니다. 즉, 모든 웹 페이지가 침해될 수 있다고 가정하고, 웹 콘텐츠와 엔드포인트 사이에 에어 갭을 구축합니다. 클라우드 보안 연합(CSA)이 지적한 바와 같이, RBI는 고위험 웹 세션을 격리된 일시적 클라우드 컨테이너 내에서 실행하며, 이 과정에서 사용자의 로컬 엔드포인트는 활성 웹 코드와 직접 상호작용하지 않습니다(CSA, 2026년 1월).

영업 담당자가 해킹당한 SaaS 공급업체의 마케팅 페이지를 방문할 경우, 이 페이지에서는 악용된 자바스크립트 라이브러리를 통해 파일리스 악성코드 페이로드를 전달하는데, 이 페이로드는 컨테이너 내에서 실행된 후 세션이 종료되면 삭제됩니다. 지속성 메커니즘도, 측면 이동 기회도, 엔드포인트에 남는 흔적도 없습니다. 위협이 스택 내의 다른 모든 제어 수단을 우회했음에도 불구하고, ‘침해 가정(assume breach)’ 태세는 유지됩니다.

RBI가 CISA 제로 트러스트 성숙도 모델에 어떻게 적용되는가

CISA 제로 트러스트 성숙도 모델 v2.0(2023)은 제로 트러스트를 ‘신원’, ‘기기’, ‘네트워크’, ‘애플리케이션 및 워크로드’, ‘데이터’라는 5가지 핵심 영역으로 분류하고, ‘가시성 및 분석’, ‘자동화 및 오케스트레이션’, ‘거버넌스’라는 3가지 횡단적 역량을 포함하고 있습니다. RBI는 다음과 같이 여러 핵심 영역에 동시에 기여합니다:

CISA ZTMM 기둥: RBI 기여도 및 만기 진행 상황

NIST SP 800 207은 정책 엔진(PE), 정책 관리자(PA), 정책 적용 지점(PEP)으로 구성된 아키텍처 삼원 구조를 정의합니다. 이 모델 내에서 RBI는 브라우저 세션 계층에서 PEP 역할을 수행합니다. PE는 요청 컨텍스트(사용자 신원, 기기 상태, URL 위험도, 데이터 민감도)를 평가하고, PA는 RBI 서비스에 세션을 격리하고 적절한 데이터 제어 조치를 적용하도록 지시합니다. 이는 클라우드 보안 연합(CSA, 2026년 1월)이 설명한 바와 같이 CISA의 ‘요청별 검증’ 상태 요구 사항과 일치합니다.

SSE 스택 내의 RBI: ZTNA, SWG, CASB 및 DLP와의 통합

RBI를 단독으로 사용할 경우 유용하지만 그 효과에는 한계가 있습니다. RBI의 제로 트러스트(Zero Trust) 가치가 온전히 발휘되는 것은 SWG, CASB, ZTNA, DLP를 포함하는 Security Service Edge SSE) 플랫폼 내에서 통합된 구성 요소로 작동할 때입니다.

관리 대상 기기를 사용하는 직원이 브라우저를 통해 생성형 AI 도구에 액세스할 때의 워크플로를 살펴보겠습니다. SWG는 요청을 검사하고, 대상 사이트를 분류하며, URL의 위험도를 판단합니다. CASB는 AI 애플리케이션을 식별하고 사용이 승인되었는지 확인합니다. DLP 엔진은 프롬프트 텍스트를 스캔하여 민감한 데이터가 있는지 검사합니다. 또한 AI 도구가 "모니터"로 분류되어 SWG 정책에 의해 트리거되는 RBI 세션은 직원이 도구를 사용할 수는 있지만, 고객의 개인 식별 정보(PII)를 붙여넣거나, 민감한 내용이 포함된 응답을 다운로드하거나, 규제 대상 데이터가 포함된 파일을 업로드할 수 없도록 보장합니다. 이 모든 과정은 별도의 콘솔을 가진 네 가지 독립적인 제품이 아닌, 단일 정책 엔진 내에서 이루어집니다.

가트너(Gartner)가 SASE 시장이 연평균 성장률(CAGR) 26%를 기록하며 2028년까지 285억 달러 규모로 성장할 것으로 전망하는 이유도 바로 이러한 통합 패턴 때문입니다(가트너, 2025년 2월). 기업들은 액세스, 위협 방어, 데이터 보안을 통합 플랫폼으로 통합하고 있습니다. 그 이유는 독립형 RBI, SWG, CASB, DLP 제품을 각각 연결해 사용하는 방식은 정책의 공백, 일관성 없는 적용, 운영상의 부담을 초래하여 제로 트러스트 모델을 훼손하기 때문입니다.

Skyhigh Private Access ZTNA를 DLP 스캔 및 원활한 RBI와 Private Access , 별도의 제품을 통해 트래픽을 라우팅할 필요 없이 정책이 요구할 때 사설 애플리케이션 세션을 격리합니다.

브라우저가 작업 공간이 되는 곳

브라우저는 SaaS 접속, AI 도구 사용, 파일 다운로드, 인증 정보 입력, 제3자와의 협업 등을 위한 주요 작업 공간입니다. 사내 애플리케이션을 보호하기 위해 ZTNA를 도입하면서도, 직원들이 해당 애플리케이션과 상호작용하는 브라우저 세션을 간과하는 보안 설계자라면 보안 적용에 허점이 있는 것입니다. RBI는 사용자가 이미 익숙한 브라우저(Chrome, Edge, Firefox, Safari)를 대체하는 것이 아니라, SSE 정책이 제어하는 클라우드 기반 격리 계층으로 세션을 감싸줌으로써 이러한 허점을 메워줍니다.

관리 대상이 아닌 계약직 직원이 리버스 프록시 CASB를 통해 회사의 CRM 애플리케이션에 접속합니다. CASB는 해당 계약직 직원의 인증을 수행하고 세션 제어를 적용하며, 기기가 관리 대상이 아니라는 이유로 RBI 정책을 발동합니다. 계약직 직원은 CRM을 평소와 같이 보고 사용할 수 있지만, 내부적으로는 클립보드 사용 제한 및 다운로드 차단이 적용된 격리된 환경에서 세션이 실행됩니다. 회사는 계약직 직원에게 에이전트 설치, 기기 등록 또는 전용 브라우저 사용을 강요하지 않고도 데이터를 안전하게 보호합니다.

평가 기준: 제로 트러스트 RBI에서 중점적으로 살펴봐야 할 사항

모든 RBI 구현이 동일한 제로 트러스트 가치를 제공하는 것은 아닙니다. 브라우저 격리 기능을 평가하는 보안 설계자는 다음 기준을 검토해야 합니다:

1. SSE 네이티브 통합. RBI는 SWG, CASB, ZTNA 및 DLP와 동일한 정책 엔진에 포함되어야 합니다. RBI에 별도의 콘솔, 별도의 정책 또는 별도의 트래픽 유도 기능이 필요한 경우, 운영상의 공백과 정책 불일치가 발생합니다.

2. 격리 세션 내의 세분화된 데이터 제어. 제로 트러스트(Zero Trust)는 세션 수준에서 최소 권한 원칙을 적용할 것을 요구합니다. RBI는 정책별, 사용자 그룹별, 애플리케이션 범주별로 클립보드, 인쇄, 업로드, 다운로드 및 화면 캡처 기능을 개별적으로 비활성화할 수 있도록 지원해야 합니다.

3. 관리되지 않는 기기 지원. 격리 기능을 활성화하기 위해 엔드포인트 에이전트가 필요한 솔루션은 RBI의 주요 사용 사례 중 하나인 ‘기업이 통제하지 않는 기기로부터의 접근을 차단하는 것’과 상충됩니다.

4. 성능 및 사용자 경험. RBI로 인해 눈에 띄는 지연이 발생하면, 사용자들은 이를 우회할 것입니다. 개인 기기에서 링크를 열거나, 모바일 핫스팟을 사용하거나, 아니면 IT 부서가 예외를 적용해 줄 때까지 불만을 제기할 것입니다. 격리 계층은 페이지를 네이티브 속도에 가까운 속도로 렌더링해야 합니다.

5. 렌더링 정확도. 현대의 SaaS 애플리케이션은 복잡한 자바스크립트 기반의 단일 페이지 애플리케이션입니다. RBI는 기능을 손상시키거나, 상호작용 요소를 누락하거나, 사용자 경험을 저하시키지 않으면서 이러한 애플리케이션을 처리해야 합니다.

6. 확장 가능한 정책 기반 활성화. 제로 트러스트는 모든 세션을 격리할 것을 요구하지 않습니다. 가장 효과적인 구현 방식은 보안 팀이 위험도에 기반한 트리거를 정의할 수 있도록 하는 것입니다. 예를 들어, 분류되지 않은 URL을 격리하거나, 고위험 사용자의 모든 세션을 격리하거나, 특정 SaaS 카테고리를 격리하거나, 관리되지 않는 기기에서 발생하는 모든 트래픽을 격리하는 것이 포함됩니다.

7. 가시성 및 분석. RBI는 세션 텔레메트리 데이터를 더 광범위한 SSE 분석 계층에 제공함으로써, CISA ZTMM의 ‘가시성 및 분석’ 횡단 기능에 기여해야 합니다. 즉, 누가, 언제, 어디서, 어떤 기기를 사용하여 어떤 콘텐츠에 접근했는지, 그리고 해당 행동이 기준선에서 벗어났는지 여부를 파악해야 합니다.

브라우징 사각지대가 초래하는 대가

브라우저 세션을 제로 트러스트 통제 범위 밖으로 두면 상당한 비용이 발생합니다. IBM의 ‘2024년 데이터 유출 비용 보고서’(2024년 7월)에 따르면, 2024년 전 세계 데이터 유출 사고의 평균 비용은 488만 달러에 달했습니다. 유출된 인증 정보가 가장 흔한 공격 경로로, 전체 유출 사고의 16%를 차지했습니다.

브라우저 기반 피싱은 인증 정보 탈취의 주요 수단 중 하나입니다. 급여 관리자가 복리후생 포털 로그인 페이지로 보이는 링크를 수신합니다. 해당 도메인은 갓 등록된 것으로, DMARC 검사를 통과하여 정상적인 사이트처럼 보입니다. RBI가 없는 경우, 관리자는 공격자의 페이지에 자격 증명을 입력하게 되며, 이로 인해 자격 증명 도난이 완료됩니다. RBI가 분류되지 않은 도메인에 대해 격리 정책을 적용하면, 피싱 페이지는 컨테이너 내에서 로드되고, DLP가 자격 증명 제출 패턴을 감지하여 자격 증명이 격리된 환경을 벗어나기 전에 세션이 종료됩니다.

RBI 도입의 경제적 타당성은 단순히 이론적인 차원에 그치지 않습니다. 브라우저 계층의 보안 취약점을 보완하는 조직은 가장 큰 비용을 초래하는 침해 경로, 즉 인증 정보 도용, 웹 기반 악성코드 유포, 그리고 모니터링되지 않는 브라우저 활동을 통한 데이터 유출에 대한 노출 위험을 줄일 수 있습니다.

제로 트러스트 모델에서 RBI를 도입할 때 흔히 저지르는 실수

RBI를 독립형 제품으로 배포하는 경우. SSE와 통합되지 않은 RBI는 자체 정책 사일로를 가진 또 다른 포인트 솔루션이 됩니다. SWG와 별도로 RBI를 배포하는 의료 시스템은 결국 두 개의 서로 다른 URL 분류 엔진과 두 개의 정책 콘솔을 갖게 되며, 이는 필연적으로 정책 불일치를 초래합니다. 정책 간 충돌이 발생하고 예외 사항이 급증하며, 제로 트러스트 모델의 효율성이 저하됩니다.

항상 모든 것을 격리하는 것은 아닙니다. 무분별한 격리는 컴퓨팅 자원을 낭비할 뿐만 아니라, 위험도가 낮은 세션의 성능을 저하시킵니다. 분류되지 않은 도메인, 고위험 사용자 그룹, 민감한 애플리케이션 범주를 격리하는 위험 기반 접근 방식은 마찰을 줄이면서도 더 나은 보안 성과를 제공합니다.

관리되지 않는 기기를 무시하는 경우. 일부 구현 방식에서는 에이전트가 트래픽을 격리 서비스로 우회하도록 요구하는데, 이는 RBI가 가장 큰 가치를 제공하는 구체적인 사용 사례(계약직 직원, BYOD, M&A 전환 기간)를 제외시키는 결과를 초래합니다. 개인 태블릿을 사용하는 계절별 창고 관리자를 채용하는 소매업체의 경우, 에이전트에 의존하는 트래픽 우회가 아닌 에이전트 없는 격리 기능이 필요합니다.

격리 세션 내에서 DLP를 소홀히 하는 경우. 데이터 제어 기능이 없는 RBI는 악성코드는 차단할 수 있지만 데이터 유출은 막지 못합니다. 일반 브라우저를 통해 고객 기록을 개인 이메일로 붙여넣을 수 없는 직원이라도, 클립보드 제어 기능이 적용되지 않는 한 격리 세션을 통해서는 여전히 이를 수행할 수 있습니다.

RBI를 VDI의 대체 수단으로 간주하는 경우. RBI는 전체 데스크톱이 아닌 브라우저 세션만 격리합니다. 특정 사용 사례(제3자를 위한 웹 액세스)에서는 VDI를 보완해 주지만, 네이티브 데스크톱 애플리케이션이 필요한 사용자의 경우 VDI를 대체하지는 못합니다.