브라우저 수준 제어를 통한 SaaS 애플리케이션 보안 강화

귀사의 CASB는 계약직 직원이 Salesforce에서 고객 목록을 관리 대상이 아닌 노트북으로 다운로드하는 것을 차단합니다. 5초 후, 같은 계약직 직원이 테이블 전체를 선택하여 클립보드에 복사한 뒤, 개인 Gmail 작성 창에 붙여넣고 ‘보내기’를 클릭합니다. CASB는 이 과정을 전혀 감지하지 못했습니다. 하지만 브라우저는 이를 감지했으며, 적절한 제어 기능이 있었다면 이를 막을 수도 있었을 것입니다. 이 가이드는 SaaS 보안 관리자와 CASB 운영자가 브라우저 수준의 제어 기능을 단계적으로 적용하여 이러한 보안 허점을 메우는 방법을 단계별로 안내합니다. remote browser isolation (RBI), secure web gateway SWG) 정책, DLP 및 세션 조치 —를 적용하여 해당 취약점을 해소하는 단계별 접근 방식을 안내합니다.

필수 준비 사항: 시작하기 전에 갖춰야 할 것들

브라우저 수준 제어 기능을 활성화하기 전에, 사용 중인 환경이 네 가지 기본 조건을 충족하는지 확인하십시오. 이 과정을 생략하면 정책 충돌, 사용자 불편, 그리고 적용 범위 미비 등의 문제가 발생할 수 있습니다.

1. 이미 포워드 프록시 및 리버스 프록시 모드가 적용된 CASB가 구축되어 있습니다. 정책 적용의 기본 기준으로, 승인된 SaaS 애플리케이션에 대한 인라인 트래픽 검사(리버스 프록시)와 섀도우 IT 가시성 확보(포워드 프록시)가 필요합니다. CASB가 API 전용으로만 구축된 경우, 브라우저 제어 기능이 제공하는 인라인 경로가 부족합니다.

2. 통합 DLP 정책 엔진. 브라우저 수준의 제어 기능은 CASB 및 이메일 DLP 정책에서 사용하는 것과 동일한 데이터 분류 체계(PII, PHI, 금융 기록, 소스 코드, 지적 재산권 등)를 참조해야 합니다. DLP 정의가 서로 분리된 상태로 관리되고 있다면, 우선 이를 통합하는 것부터 시작하십시오. 분류 체계가 일관되지 않으면 한 채널에서 허용하는 내용을 다른 채널에서 차단하는 상황이 발생할 수 있습니다. 중앙 집중식 DLP 플랫폼을 도입하면 이러한 분산 현상을 방지할 수 있습니다.

3. ID 제공자(IdP) 통합 및 기기 상태 평가. 브라우저 제어 기능은 사용자의 신원과 사용 중인 기기에 따라 유연하게 조정될 때 훨씬 더 유용해집니다. 개인용 MacBook을 사용하는 마케팅 계약직 직원은 관리형 Windows 엔드포인트를 사용하는 정규직 재무 분석가보다 더 엄격한 제어 조치를 받아야 합니다. 이를 위해서는 ID 제공자(IdP)와의 SAML/OIDC 연동 및 기기 상태 점검(관리형 대 비관리형, OS 패치 수준, 디스크 암호화 상태)이 필요합니다.

4. 민감도 등급이 분류된 SaaS 애플리케이션 목록. 어떤 SaaS 애플리케이션에 민감한 데이터가 저장되어 있는지 파악하지 않고서는 브라우저 정책의 적용 범위를 설정할 수 없습니다. 데이터 민감도 등급(매우 높음, 높음, 중간, 낮음)별로 상위 20~50개 SaaS 애플리케이션을 분류하십시오. CSA의 ‘SaaS 거버넌스 모범 사례’에서는 SaaS 라이프사이클의 모든 단계(평가, 도입, 사용, 종료)에서 위험을 평가할 것을 권장합니다. 이 목록은 정책 적용 범위를 설정하는 데 필요한 기초 자료가 됩니다.

1단계: 고위험 시나리오에서 클립보드 및 다운로드 간극 해소

위험이 가장 높고 사용자 수가 가장 적은 부분부터 시작하십시오. 바로 민감한 SaaS 애플리케이션에 접근하는 관리되지 않는 기기들입니다.

1단계를 정당화하는 시나리오: 제3자 감사인이 개인 노트북에서 SSO를 사용하여 귀사의 Workday 인스턴스에 로그인합니다. 귀사의 CASB 리버스 프록시는 해당 세션을 인증하고 정책에 따라 파일 다운로드를 차단합니다. 하지만 감사관은 직원 보상 보고서를 열고, 급여 데이터 30행을 선택하여 복사한 뒤, 새 탭을 열어 개인 Google 스프레드시트를 열고 해당 데이터를 붙여넣습니다. CASB는 인증된 Workday 세션과 Google 스프레드시트 세션, 즉 서로 별개이며 개별적으로 허용되는 두 가지 이벤트를 감지했습니다. 클립보드 작업이 전적으로 브라우저의 렌더링 컨텍스트 내에서 이루어졌기 때문에, CASB는 두 세션 간에 데이터가 이동하는 것을 전혀 감지하지 못했습니다.

구현 사항: Tier 1(중요) 및 Tier 2(높음) SaaS 애플리케이션에 액세스하는 모든 비관리형 기기 세션 remote browser isolation (RBI) remote browser isolation 활성화하십시오. RBI는 SaaS 애플리케이션을 클라우드 호스팅 컨테이너에서 렌더링하고, 사용자의 브라우저로 픽셀 데이터만 스트리밍합니다. 이 아키텍처를 통해 세션 동작을 세밀하게 제어할 수 있습니다:

복사/붙여넣기 제한: 격리된 세션에서 클립보드의 쓰기/읽기 작업을 차단하거나, 붙여넣기는 허용하되 복사는 차단하여 데이터가 SaaS 앱 컨텍스트를 벗어나지 못하도록 방지합니다.

다운로드 차단: 렌더링된 세션에서 파일 다운로드를 완전히 차단하거나, 특정 파일 유형으로만 다운로드를 제한합니다.

인쇄 차단: 인쇄 및 PDF로 인쇄 명령을 비활성화합니다.

스크린샷 워터마킹: 렌더링된 스트림에 사용자의 이메일 주소와 타임스탬프가 포함된 가시적 또는 포렌식 워터마크를 삽입하여 스크린 캡처를 방지합니다.

NIST SP 800-53 SC 7은 정보 흐름을 제어하고 악의적인 공격 및 오류로 인한 잠재적 피해를 제한하기 위해 경계 보호 메커니즘을 통해 시스템 구성 요소를 격리할 것을 규정하고 있습니다. RBI는 SaaS 애플리케이션의 데이터와 사용자의 로컬 장치 사이에 바로 이러한 경계를 형성하여, 네트워크 프록시로는 구현할 수 없는 정보 흐름 제어를 시행합니다.

적용 범위 제한: 1단계에서는 관리되지 않는 기기와 계약업체 직원에게만 이러한 통제 조치를 적용하십시오. 에이전트가 배포되어 있고 보안 상태가 검증된 관리 대상 엔드포인트의 경우, 생산성을 유지하기 위해 (클립보드 차단 없이 워터마킹만 적용하는 등) 덜 엄격한 통제 조치를 적용할 수 있습니다.

2단계: 브라우저 DLP를 관리 대상 엔드포인트로 확대하고 SaaS 적용 범위를 넓히기

1단계가 안정화되면(일반적으로 4~6주간의 원격 측정 데이터 수집 및 정책 조정이 끝난 후), 관리 대상 기기와 더 광범위한 SaaS 애플리케이션으로 적용 범위를 확대하십시오.

2단계를 정당화하는 시나리오는 다음과 같습니다. 관리 대상 노트북을 사용하는 전임 영업 담당자가 Chrome을 통해 Salesforce에 접속합니다. 이 담당자는 고객 계정 레코드를 열어 연락처의 이름, 회사명, 전화번호를 복사한 뒤, 이를 ChatGPT에 붙여넣어 맞춤형 연락 이메일을 생성합니다. 파일을 다운로드한 적도 없고, Salesforce 공유 규칙을 위반한 적도 없습니다. 하지만 고객의 개인 식별 정보(PII)는 브라우저 클립보드를 통해 귀사가 통제하는 SaaS 환경을 벗어나 제3자 AI 도구로 유입된 것입니다.

CSA의 ‘SaaS 보안 현황 보고서(2025)’에 따르면, 조직의 63%가 외부로 데이터가 과도하게 공유된 사례를 보고했으며, 56%는 직원들이 민감한 데이터를 승인되지 않은 SaaS 앱에 업로드한다고 밝혔습니다. 이러한 행위들은 대개 기존 통제 수단이 놓치는 바로 그 클립보드 및 업로드 경로를 통해 이루어집니다. 브라우저 수준의 DLP는 데이터가 승인되지 않은 목적지에 도달하기 전에 이러한 행동을 차단하는 통제 수단입니다.

배포 대상:

SWG는 관리 대상 엔드포인트에 대해 DLP 검사를 적용했습니다. secure web gateway 브라우저 트래픽을 가로채어, 양식 필드 제출, 웹 앱에 대한 클립보드 붙여넣기 이벤트, 브라우저를 통한 파일 업로드 등 전송 중인 데이터에 DLP 분류를 적용합니다. 이를 통해 앞서 언급한 Salesforce에서 ChatGPT로 데이터를 전송하는 시나리오를 차단할 수 있습니다.

민감한 범주에 대한 선택적 RBI 적용. 모든 브라우징을 차단하기보다는, 사용자의 행동이 위험 신호를 유발할 때(예: 고객 데이터 객체에 접근, 내보내기 보기 열기, 회사 인증 정보를 사용하여 AI 도구로 이동 등) Tier 1 및 Tier 2 SaaS 앱으로의 세션을 RBI를 통해 라우팅합니다.

세션 녹화 방지를 위한 워터마킹. 민감한 데이터가 표시되는 세션에 눈에 띄는 워터마크를 적용하여, 사용자가 화면을 촬영할 경우 워터마크를 통해 해당 이미지가 특정 사용자, 세션 및 타임스탬프와 연결되도록 합니다.

NIST SP 800-53 AC 4의 정책 설계 원칙: 애플리케이션 및 서비스 수준에서 접근 제어 메커니즘을 적용함으로써, 네트워크 수준 제어만으로는 달성할 수 없는 수준의 정보 보안을 강화하고 정보 흐름을 제어할 수 있습니다. 브라우저 수준의 DLP 및 RBI는 바로 이러한 애플리케이션 및 서비스 수준에서 작동하며, 네트워크 수준의 CASB 프록시가 도달할 수 없는 영역까지 제어 기능을 확장합니다.

3단계: 브라우저 제어 기능을 SSE 정책 프레임워크에 통합하기

브라우저 제어 기능을 독립적인 계층으로 배포하면 별도의 정책, 별도의 콘솔, 별도의 사고 대기열 등 운영상의 부담이 발생합니다. 3단계에서는 브라우저 수준의 적용을 더 광범위한 Security Service Edge (SSE) 플랫폼과 통합하여, 단일 정책 엔진이 CASB, SWG, DLP, RBI 및 ZTNA에 대한 결정을 모두 관리할 수 있도록 합니다.

3단계를 도입해야 하는 시나리오: SOC에 세 가지 경고가 접수됩니다. 사용자가 섀도우 SaaS 앱에 접속했다는 CASB 경고, 동일한 사용자의 브라우저 세션에서 DLP 패턴이 일치했다는 SWG 경고, 클립보드 복사가 차단되었다는 RBI 경고입니다. 단 한 명의 사용자가 단 한 번의 일련의 작업을 수행했을 뿐인데, 콘솔 세 개, 분석가 세 명, 티켓 세 개가 발생합니다. 통합 SSE 정책은 이를 단일한 상호 연관된 이벤트로 통합하고, 단일 대응 워크플로를 적용합니다.

배포 대상:

단일 조건문 내에서 사용자 신원, 기기 상태, SaaS 앱 민감도 등급, 데이터 분류 및 브라우저 작업 유형(다운로드, 클립보드, 인쇄, 업로드)을 참조하는 통합 정책 규칙.

SSE 플랫폼이 특정 신호들의 조합(예: 관리되지 않는 기기가 Tier 1 애플리케이션에 액세스하는 동시에 DLP가 해당 페이지에서 민감한 콘텐츠를 감지하는 경우 등)을 감지하면, 세션을 자동으로 완전한 RBI 모드로 격상시키는 적응형 격리 기능입니다.

SIEM/SOAR로 세션 텔레메트리 데이터를 전송하여, 브라우저 수준 이벤트(클립보드 차단, 워터마크 삽입, 다운로드 차단)를 CASB, SWG 및 ZTNA 이벤트와 함께 확인할 수 있도록 하여 상호 연관성 분석 및 조사가 가능하게 합니다.

CISA의 제로 트러스트 성숙도 모델은 조직이 세분화된 접근 제어 및 통합된 위협 방어 기능을 통해 배포된 애플리케이션을 관리하고 보호함으로써, ‘애플리케이션 및 워크로드’와 ‘데이터’ 두 가지 핵심 영역 전반에 걸쳐 최적의 성숙도를 달성하도록 요구합니다. 브라우저 수준 제어 기능을 SSE 정책에 통합하는 것이 바로 브라우저를 통해 액세스하는 SaaS 애플리케이션에 대해 해당 지침을 실제로 적용하는 방법입니다.

통합 지점: 브라우저 컨트롤이 기존 스택과 연결되는 곳

브라우저 수준의 제어 기능은 기존의 보안 도구를 대체하는 것이 아니라, 이들 도구 간의 적용 공백을 메워줍니다. 중복을 방지하고 적용 범위를 확보하기 위해 통합 지점을 명확히 파악해야 합니다.

실제 통합 시나리오를 생각해 보겠습니다. 한 의료 기관이 CASB API 모드를 사용하여 Box에 저장된 PHI를 스캔하고 공유 정책을 적용한다고 가정해 봅시다. 하지만 개인 태블릿을 사용하는 전문 간호사가 브라우저를 통해 환자 문서를 열었을 때, API 스캔은 이미 실행된 상태이므로 메시징 앱으로 환자 진단 내용을 클립보드에 복사하는 것을 막을 수 없습니다. 클립보드 제한 및 워터마킹 기능이 포함된 RBI 세션을 활용하면, 개인 태블릿에 엔드포인트 에이전트를 설치할 필요 없이 이러한 보안 허점을 메울 수 있습니다. Skyhigh Security 관리되지 않는 기기에서 클라우드 앱을 보호하기 위해 채택한 접근 방식은 리버스 프록시, RBI 및 DLP를 통합된 정책으로 결합함으로써 바로 이러한 사용 사례를 해결합니다.

지표 및 성공 기준

브라우저 수준 제어 기능은 기존 CASB 단독 배포 환경에서는 생성할 수 없었던 텔레메트리 데이터를 생성합니다. 배포 전에 지표(메트릭)를 정의해 두면 그 가치를 입증하고 정책을 최적화할 수 있습니다.

운영 지표 (매주 추적):

사용자/앱/기기 유형별로 클립보드 차단 이벤트를 분석하십시오. 특정 사용자의 클립보드 차단 건수가 급증하는 경우, 데이터 유출 시도가 있었음을 나타내거나 정상적인 업무 흐름에 비해 정책이 지나치게 제한적임을 시사할 수 있습니다. 이상치를 조사하십시오.

다운로드 차단 내역을 확인하세요. SaaS 앱 및 사용자 역할별로 추적할 수 있습니다. 특정 앱에서 차단된 다운로드 건수가 많다면, 사용자에게 안전한 대안(예: 읽기 전용 뷰어 또는 통제된 내보내기 워크플로)이 필요할 수 있습니다.

워터마크로 인해 수사가 촉발되었습니다. 워터마크가 찍힌 스크린샷이나 인쇄된 문서가 수사를 통해 사용자에게까지 추적된 횟수를 집계해 보십시오. 그 횟수가 적더라도 이는 억제 효과가 있음을 입증합니다.

정책 예외 요청. 브라우저 제어에 대한 예외를 요청한 사용자 수와 그 사유를 추적합니다. 특정 앱에 대한 예외 요청 건수가 많다면, 해당 정책을 개선해야 함을 시사합니다.

위험 감소 지표 (분기별 추적):

SaaS 클립보드 또는 업로드 경로와 관련된 민감 데이터 사고의 감소. 동일한 SaaS 앱 및 사용자 집단을 대상으로, 브라우저 제어 기능 적용 전후의 사고 발생 건수를 비교해 보십시오.

관리되지 않는 기기의 세션 제어 적용 범위. RBI를 통과하는 관리되지 않는 기기의 SaaS 세션과 RBI를 우회하는 세션의 비율을 측정합니다. Tier 1 애플리케이션의 경우 95% 이상의 적용 범위를 목표로 합니다.

브라우저 기반 정보 유출 시도를 탐지하는 데 걸리는 평균 시간. 브라우저 텔레메트리 기능을 활용하면 탐지 시간이 며칠(사후 DLP 스캔 경보에 의존할 경우)에서 몇 초(실시간 클립보드 차단)로 단축될 것입니다.

버라이즌의 2025년 DBIR 보고서에 따르면, 데이터 유출 사고의 60%는 사용자의 클릭, 복사, 업로드, 붙여넣기 등 ‘인적 요인’과 관련이 있는 것으로 나타났습니다. 브라우저 수준 제어 기능은 바로 이러한 인간의 행동에 대한 집행 텔레메트리 데이터를 생성하여, 네트워크 및 API 제어 기능으로는 전혀 포착하지 못하는 공격 경로에 대해 SOC(보안 운영 센터)가 가시성을 확보할 수 있게 해줍니다. 한편, 포레스터(Forrester) 보고서에 따르면 데이터 침해 사고의 약 5분의 1이 내부자 사고에서 비롯된다고 합니다(2026). 브라우저 세션 제어 기능은 내부자가 가장 빈번하게 악용하는 클립보드 및 업로드 경로에 대해 직접적이고 실시간적인 제어를 제공합니다.

흔히 저지르는 실수

실수 1: 첫날부터 모든 사용자에게 완전한 RBI 격리 기능을 적용하는 것. 완전한 픽셀 스트리밍 격리는 브라우징 경험을 변화시킵니다. 지연 시간이 약간 증가하고, 일부 브라우저 확장 프로그램이 작동하지 않게 되며, 복잡한 웹 앱의 렌더링 방식이 달라질 수 있습니다. 이를 5,000명의 직원에게 동시에 적용하면 헬프데스크에서 항의가 쇄도할 것이며, 경영진은 프로젝트를 중단시킬 것입니다. 관리 대상이 아닌 기기와 고위험 앱부터 시작하세요. 점진적으로 확대해 나가세요.

실수 2: 관리 대상 기기와 비관리 대상 기기에 동일한 브라우저 정책을 적용하는 것. 비관리 대상인 계약직 직원의 노트북에는 클립보드 차단 및 다운로드 차단 기능이 전면적으로 적용되어야 합니다. 반면, 에이전트가 설치되어 있고 디스크 암호화가 검증되었으며 최신 패치가 적용된 관리 대상 기업 엔드포인트의 경우, 워터마킹 및 선택적 붙여넣기 제한만으로도 충분할 수 있습니다. 기기 상태에 따라 정책을 차별화하십시오. EDR이 설치된 관리 대상 기기에서 유출된 인증 정보의 위험 프로필은 가시성이 전혀 없는 비관리 대상 기기에서 유출된 인증 정보의 위험 프로필과 근본적으로 다릅니다. 브라우저 정책은 이러한 비대칭성을 반영해야 합니다.

실수 3: DLP 정책에서 AI 도구 대상 사이트를 간과하는 것. 많은 조직이 브라우저 DLP를 구성하여 개인용 클라우드 저장소, 웹메일 등 기존의 ‘섀도우 IT’ 범주에 속하는 서비스로의 업로드를 차단했지만, AI 어시스턴트를 포함시키는 것을 잊었습니다. 현재 AI 도구는 복사하여 붙여넣거나 업로드된 데이터가 전송되는 가장 흔한 무단 대상 중 하나입니다. SWG 및 DLP URL 범주를 업데이트하여 생성형 AI 서비스를 포함시키고, 다른 승인되지 않은 앱에 적용하는 것과 동일한 클립보드 및 업로드 제한을 적용하십시오.

실수 4: 브라우저 제어 기능을 SSE 정책의 확장 기능이 아닌 독립된 프로젝트로 취급하는 것. 브라우저 제어 기능이 별도의 정책이 적용된 별도 콘솔에 존재할 경우, 이는 SOC가 무시하게 되는 또 하나의 도구가 될 뿐입니다. 3단계부터 이를 SSE 플랫폼에 통합하여, 단일 인시던트 워크플로우 내에서 브라우저 이벤트가 CASB, SWG 및 ZTNA 이벤트와 상호 연관되도록 해야 합니다.

실수 5: 정책을 수립하기 전에 SaaS 애플리케이션을 민감도 수준에 따라 분류하지 않는 것. 민감도 등급별 SaaS 목록이 없으면, 과도하게 차단하여(저위험 애플리케이션을 격리시켜 사용자의 불편을 초래하거나) 반대로 차단이 부족하여(중요한 애플리케이션에 대한 통제 조치를 소홀히 하거나) 문제가 발생합니다. 대기업은 일상적으로 수십 개에서 수백 개에 달하는 SaaS 서비스를 이용하고 있으며, 이러한 분류 작업은 선택 사항이 아닙니다. 이는 보안 허점과 사용자 반발을 모두 방지하는 맞춤형 정책의 토대입니다.