정보관리기술사 학습 노트
← 목록으로
보안·개인정보
#CASB#섀도IT#클라우드보안#DLP#SSE
최종 업데이트 · 2026-09-28

CASB(Cloud Access Security Broker, 클라우드 접근 보안 중개)

1. 개요

CASB는 클라우드 서비스 사용자(단말·사용자)와 클라우드 서비스 제공자(SaaS·IaaS·PaaS) 사이에 위치하여, 조직의 보안 정책을 클라우드 접근 경로에 일관되게 강제(enforce)하는 보안 정책 시행 지점(Policy Enforcement Point)이다. 2012년 Gartner가 처음 명명한 개념으로, 가시성(Visibility)·컴플라이언스(Compliance)·데이터 보안(Data Security)·위협 방어(Threat Protection)의 네 기둥으로 정의된다.

CASB가 등장한 근본 배경은 기업 업무가 온프레미스 애플리케이션에서 SaaS로 급격히 이동하면서 전통적 경계 보안이 통제할 수 없는 영역이 생겼다는 데 있다. 과거에는 데이터와 애플리케이션이 사내 데이터센터 안에 있었으므로 방화벽·프록시·DLP 장비를 경계에 배치하면 대부분의 트래픽을 검사할 수 있었다. 그러나 Microsoft 365·Salesforce·Google Workspace·Slack 같은 SaaS로 업무가 옮겨가면서, 직원이 관리되지 않는 개인 단말이나 사외 네트워크에서 직접 클라우드에 접속하는 경로가 열렸고, 이는 경계 방화벽을 우회한다. 보안팀은 "누가 어떤 클라우드 앱을 쓰는지"조차 파악하지 못하는 상황에 놓였다.

특히 섀도 IT(Shadow IT) 문제가 심각해졌다. 부서나 개인이 IT·보안팀의 승인 없이 자체적으로 SaaS를 도입해 사용하면서, 조직은 통제 범위 밖에서 기업 데이터가 유통되는 위험에 노출되었다. 실제로 다수의 조사에서 기업이 실제 사용 중인 클라우드 앱 수는 IT 부서가 인지한 수의 몇 배에서 십수 배에 달하는 것으로 보고되어 왔다. 여기에 개인정보보호법·GDPR·금융권 클라우드 이용 가이드 등 규제가 클라우드 상 데이터의 위치·암호화·접근통제를 요구하면서, 클라우드 사용에 대한 가시성과 통제를 한 지점에서 제공하는 중개자가 필요해졌다. CASB는 "클라우드로 나가고 들어오는 모든 접근을 중개하여, 온프레미스에서 하던 보안 통제(가시성·DLP·접근제어·위협탐지)를 클라우드까지 확장한다"는 발상으로 이 공백을 메운다.

CASB는 2012년 Gartner의 명명 이후 독립 스타트업 제품(Skyhigh Networks, Netskope, Bitglass 등)으로 급성장했고, 2017~2018년 대형 보안·클라우드 기업들의 인수를 거쳐 종합 보안 스위트의 일부로 재편되었다. 이후 2019년 SASE, 2021년 SSE 개념이 등장하며 CASB는 독립 카테고리에서 통합 플랫폼의 한 기능으로 자리를 옮겨 왔다. 이러한 진화 경로 자체가 "클라우드 보안은 단품이 아니라 신원·네트워크·데이터를 아우르는 통합 통제로 수렴한다"는 흐름을 보여준다.

기존 보안 장비만으로 이 문제를 해결하기 어려웠던 이유를 짚어 두는 것이 CASB의 필요성을 이해하는 열쇠다. 경계 방화벽·IPS는 IP·포트 수준에서 트래픽을 볼 뿐, HTTPS로 암호화된 SaaS 세션 내부의 "누가 어떤 파일을 외부에 공유했는가" 같은 앱 맥락(context)을 알지 못한다. SWG는 웹 URL 필터링에는 강하지만 특정 SaaS 앱 내부의 세부 행위(테넌트 구분, 관리자 계정 여부, 특정 필드 접근)를 구분하지 못한다. 엔드포인트 보안(EDR)은 관리 단말에만 미치며 BYOD·협력사 단말은 사각지대로 남는다. 즉 클라우드 앱을 앱 수준의 맥락으로 이해하고, 관리·비관리 단말을 아울러 데이터·행위를 통제하는 전용 계층이 필요했고, 그 역할을 CASB가 담당한다. CASB의 특징은 ① 클라우드 앱 인지(App-aware) 정책, ② 관리·비관리 단말 통합 통제, ③ 저장(data-at-rest)·전송(data-in-transit) 데이터의 동시 보호, ④ 온프레미스 보안 정책의 클라우드 확장이라는 네 가지로 요약된다.

2. CASB의 개념 구조와 4대 핵심 기능(4 Pillars)

CASB는 사용자와 클라우드 서비스 사이의 중개 지점에서 트래픽·API 활동을 관찰하고 정책을 적용한다. 아래 개념도는 관리·비관리 단말이 다양한 클라우드 서비스에 접근할 때 CASB가 어떻게 중개자로 개입하는지를 보여준다.

graph LR
    U1["관리 단말(사내PC)"] --> CASB
    U2["비관리 단말(BYOD)"] --> CASB
    U3["모바일/원격 사용자"] --> CASB
    CASB["CASB 중개 지점<br/>(정책 시행 PEP)"] --> S1["SaaS(M365·Salesforce)"]
    CASB --> S2["IaaS/PaaS(AWS·Azure)"]
    CASB --> S3["섀도 IT(미승인 앱)"]
    IDP["IdP/디렉터리<br/>(신원·그룹)"] -.신원 연동.-> CASB
    POL["정책엔진<br/>(DLP·접근·위협)"] -.정책.-> CASB

CASB의 가치는 네 가지 기능 축(Four Pillars)으로 설명된다. 첫째, 가시성(Visibility)이다. CASB는 방화벽·프록시 로그를 분석하거나 트래픽을 중개하여 조직이 실제 사용하는 모든 클라우드 앱을 식별하고, 각 앱의 위험도를 점수화한 클라우드 앱 리스크 레지스트리를 제공한다. 이를 통해 보안팀은 섀도 IT를 발견하고, 위험한 앱은 차단하며, 유사 기능의 승인된 앱으로 사용자를 유도할 수 있다. 예컨대 개인용 파일공유 앱으로 사내 문서가 유출되는 정황을 로그 분석으로 포착해 해당 앱을 차단 목록에 올리는 식이다. 앱 위험 점수는 대체로 다음과 같은 요소로 산정된다.

  • 데이터 보관·주권: 데이터 저장 리전, 국외 이전 여부, 저장/전송 암호화 적용 수준
  • 인증·접근통제: MFA·SSO(SAML) 지원, 관리자 권한 세분화, 세션·비밀번호 정책
  • 규정 준수 이력: ISO 27001·SOC 2·CSAP 등 인증 보유, 과거 침해 사고 이력
  • 소유·운영 투명성: 서비스 제공자 신뢰도, 데이터 소유권·삭제 정책, 서브프로세서 공개 여부

이렇게 산정된 점수를 기준으로 조직은 "허용/조건부 허용/차단"의 3단계 정책을 세우고, 고위험 앱은 자동 차단하되 중위험 앱은 경고·로깅만 하는 식으로 통제 강도를 차등화할 수 있다. 가시성은 나머지 세 기능의 전제가 된다 — 무엇이 쓰이는지 모르면 규정 준수도, 데이터 보호도, 위협 탐지도 대상 자체를 특정할 수 없기 때문이다.

둘째, 컴플라이언스(Compliance)다. 클라우드에 저장·처리되는 데이터가 개인정보보호법·GDPR·PCI-DSS·산업별 규제를 위반하지 않는지 점검한다. 예를 들어 주민등록번호·카드번호가 규정에 어긋나게 SaaS에 저장되어 있는지 스캔하고, 데이터가 국외 리전에 저장되어 데이터 주권(data sovereignty)을 위반하는지 탐지한다. 규제 준수를 클라우드까지 확장하는 것이 핵심이다. 컴플라이언스 기능은 단순 위반 탐지에 그치지 않고, 감사·인증 대응을 위한 근거 자료(어떤 데이터가 어디에 있고 누가 접근했는지에 대한 로그·리포트)를 제공한다는 점에서 가치가 크다. 금융·의료·공공처럼 규제 강도가 높은 산업일수록 이 기능이 CASB 도입의 일차적 동인이 되는 경우가 많다.

셋째, 데이터 보안(Data Security)이다. CASB는 클라우드 상의 민감정보를 대상으로 DLP(데이터 유출 방지)를 수행한다. 콘텐츠 검사·정규식·키워드·지문(fingerprint) 기반으로 민감 데이터를 식별해 외부 공유·다운로드를 차단하거나 격리하며, 필요 시 조직이 관리하는 키로 데이터를 암호화·토큰화하여 저장한다. 온프레미스 DLP 정책을 클라우드에 그대로 적용함으로써 정책의 일관성을 유지한다. 특히 조직이 직접 관리하는 키(BYOK, Bring Your Own Key)로 암호화하면 클라우드 제공자조차 평문에 접근할 수 없어, 제공자 침해나 강제 열람 요구 상황에서도 데이터 비밀성을 지킬 수 있다는 점이 실무적으로 중요하다.

넷째, 위협 방어(Threat Protection)다. 사용자·엔터티 행위분석(UEBA)으로 계정 탈취·내부자 위협·비정상 접근을 탐지한다. 예를 들어 서울에서 로그인한 계정이 몇 분 뒤 해외에서 접속하는 '불가능한 이동(impossible travel)', 대량 다운로드, 심야 대량 삭제 같은 이상 징후를 포착하고, 클라우드에 업로드되는 악성코드를 검사한다. 위협 인텔리전스와 결합해 알려진 악성 IP·도메인과의 통신도 차단한다. 이 네 기능은 서로 독립적이지 않고 순환한다 — 가시성으로 발견한 앱·데이터에 컴플라이언스 기준을 적용하고, 데이터 보안으로 유출을 차단하며, 위협 방어로 이상 징후에 대응한 결과가 다시 가시성 데이터로 축적되어 정책을 정교하게 만든다.

아래 표는 4대 기능을 목적·대표 기술·산출물 관점에서 정리한 것이다. 다만 표는 요약일 뿐이며, 각 기능이 실제로 효과를 내려면 앞서 설명한 대로 신원·데이터 분류·정책 엔진과의 정합이 전제된다.

기능(Pillar) 목적 대표 기술·기법 주요 산출물
가시성 사용 현황·위험 파악 로그 분석·앱 리스크 점수 클라우드 앱 인벤토리·섀도 IT 목록
컴플라이언스 규제 위반 점검 콘텐츠 스캔·데이터 위치 확인 규정 위반 리포트·시정 조치
데이터 보안 유출 차단·보호 DLP·암호화·토큰화 차단·격리·암호화된 데이터
위협 방어 이상행위 탐지·대응 UEBA·악성코드 검사·위협 인텔 위험 알림·자동 대응(격리·재인증)

3. CASB 배포 방식(Deployment Modes)

CASB가 트래픽·활동에 개입하는 방법은 크게 API 기반(Out-of-band)과 프록시 기반(Inline)으로 나뉘며, 프록시는 다시 포워드 프록시와 리버스 프록시로 구분된다. 아래 상세 아키텍처도는 세 방식의 데이터 경로 차이를 보여준다.

graph TB
    subgraph API["API 기반(Out-of-band)"]
      A1["클라우드에 이미 저장된 데이터"] --> A2["CASB가 CSP API 호출"]
      A2 --> A3["사후 스캔·정책 적용(비실시간)"]
    end
    subgraph FWD["포워드 프록시(Inline)"]
      F1["관리 단말(에이전트)"] --> F2["CASB 프록시"]
      F2 --> F3["실시간 검사 후 클라우드 전달"]
    end
    subgraph REV["리버스 프록시(Inline)"]
      R1["비관리 단말(BYOD)"] --> R2["IdP 통해 CASB 경유"]
      R2 --> R3["에이전트 없이 실시간 통제"]
    end

이 세 방식은 데이터 경로에 개입하는 위치와 시점이 근본적으로 다르며, 그에 따라 커버리지·실시간성·도입 난이도가 갈린다. 아래에서 각 방식의 원리와 장단점을 차례로 살펴본다.

API 기반(Out-of-band) 방식은 클라우드 서비스 제공자가 노출한 관리 API를 CASB가 호출하여, 이미 클라우드에 저장된 데이터와 설정·공유 상태를 조회·검사하는 방식이다. 트래픽 경로에 끼어들지 않으므로 사용자 경험에 영향이 없고, 관리 단말·비관리 단말·모바일 앱을 가리지 않고 모든 데이터를 대상으로 스캔할 수 있다는 장점이 있다. 대표적으로 SaaS에 오래 방치된 공개 공유 링크나 잘못된 권한 설정을 사후에 찾아 교정한다. 다만 데이터가 저장된 뒤에 검사하므로 실시간 차단이 불가능하고, CSP가 API를 제공하는 앱에 한정된다는 한계가 있다.

포워드 프록시(Forward Proxy) 방식은 단말에 에이전트나 프록시 설정(PAC 파일)을 배포해, 사용자가 클라우드로 보내는 트래픽을 CASB가 실시간으로 가로채 검사한 뒤 전달한다. 업로드 시점에 DLP·차단을 수행할 수 있어 실시간 통제가 가능하지만, 단말에 에이전트를 설치·관리해야 하므로 조직이 통제하는 관리 단말에 적합하다. 개인 소유 BYOD 단말에는 에이전트 설치가 어렵다는 것이 약점이다.

리버스 프록시(Reverse Proxy) 방식은 단말이 아니라 클라우드 서비스 쪽에 프록시를 두는 개념으로, 사용자가 IdP(SSO)로 로그인할 때 세션을 CASB로 리디렉션하여 트래픽을 경유시킨다. 에이전트가 필요 없어 비관리 단말(BYOD)·협력사 단말에도 실시간 통제를 적용할 수 있다는 것이 가장 큰 장점이다. 다만 SAML 기반 SSO 연동이 필수이고, 클라우드 앱의 URL·API 변경에 프록시가 민감하게 반응해 호환성 이슈가 생길 수 있다.

실무에서는 세 방식을 상호 보완적으로 함께 쓰는 멀티모드(Multimode) CASB가 표준으로 자리 잡았다 — API로 저장 데이터를 사후 점검하고, 포워드 프록시로 관리 단말의 실시간 트래픽을 통제하며, 리버스 프록시로 BYOD를 커버하는 식이다. 세 방식이 커버하는 영역이 겹치지 않고 상호 보완적이기 때문이다. 예를 들어 한 조직이 사내 PC에는 포워드 프록시로 업로드 시점 DLP를 걸고, 재택근무자의 개인 노트북에는 리버스 프록시로 SSO 경유 통제를 적용하며, 이미 클라우드에 쌓인 수년치 문서는 API 스캔으로 정리한다면, 세 경로를 하나의 정책·콘솔로 아우르게 된다. 이때 중요한 설계 원칙은 정책의 단일 소스(single source of policy)를 유지하는 것이다 — 배포 방식이 셋이어도 DLP 규칙·차단 기준·로그는 한 곳에서 관리되어야 일관성과 감사 추적성이 확보된다. 인라인 프록시를 쓸 때는 TLS 복호화가 불가피하므로, 성능 저하와 프라이버시 이슈를 고려해 금융·의료처럼 민감한 트래픽만 선택적으로 복호화하고 나머지는 메타데이터 기반으로 처리하는 절충이 흔히 쓰인다.

4. 배포 방식·인접 기술 비교

CASB를 실제로 도입할 때 가장 먼저 부딪히는 설계 결정이 배포 방식의 선택이다. 이는 단순한 기술 취향의 문제가 아니라, 조직의 단말 관리 수준(관리 단말 비율)·SSO 도입 여부·규제 요구·성능 요구가 얽힌 종합적 판단이다. 배포 방식의 선택은 "무엇을 통제하려 하는가"와 "어떤 단말을 대상으로 하는가"에 따라 갈린다. 아래 표는 세 방식의 특성을 비교한 것이다.

구분 API 기반 포워드 프록시 리버스 프록시
개입 시점 사후(저장 후) 실시간(인라인) 실시간(인라인)
에이전트 불필요 필요 불필요
대상 단말 전체 관리 단말 관리·비관리(BYOD)
강점 광범위 스캔·무중단 업로드 시 차단 BYOD 실시간 통제
한계 실시간 차단 불가 BYOD 적용 곤란 SSO 필수·호환성

이 차이가 생기는 이유는 각 방식이 트래픽 경로에 대해 갖는 위치가 다르기 때문이다. API는 경로 밖에서 결과물(저장 데이터)을 검사하므로 실시간성이 없는 대신 범위가 넓고, 프록시는 경로 위에 있으므로 실시간 차단이 가능한 대신 그 경로를 강제할 수단(에이전트 또는 SSO)이 필요하다. 실무 함의는 명확하다 — 실시간 유출 차단이 목표면 프록시가, 방치된 데이터·설정 오류 교정이 목표면 API가 적합하며, 대부분은 두 가지가 모두 필요하므로 멀티모드로 구성한다. 반대로 어느 하나만 도입하면 반드시 사각지대가 남는다. API만 쓰면 유출을 사후에야 알게 되고, 프록시만 쓰면 이미 쌓인 데이터와 API로만 접근되는 서버 간(machine-to-machine) 트래픽을 놓친다.

CASB는 인접 보안 기술과 자주 혼동되지만 초점이 다르다. SWG(Secure Web Gateway)는 웹 트래픽 전반의 URL 필터링·악성차단에 초점을 두는 반면, CASB는 특정 클라우드 앱 내부의 세부 활동(공유·다운로드·특정 필드)까지 인지해 통제한다. 예컨대 SWG는 "이 사이트 접속을 허용/차단"하지만, CASB는 "이 SaaS는 허용하되 회사 계정으로만 로그인하고, 외부 도메인으로의 파일 공유는 차단"처럼 앱 내부 맥락에 따른 정밀 정책을 편다. 두 기능은 배타적이지 않고 계층적으로 함께 쓰인다. 온프레미스 DLP가 사내 네트워크·엔드포인트의 데이터 유출을 막는다면, CASB는 그 DLP를 클라우드 저장·전송 데이터로 확장한 것이다. ZTNA가 "애플리케이션에 대한 접근 자체를 신원 기반으로 허용/차단"하는 데 초점을 둔다면, CASB는 "허용된 접근 이후 앱 내부에서 일어나는 데이터 활동"을 통제한다는 점에서 상호 보완적이다. 오늘날 이 기능들은 SSE(Security Service Edge)로 통합되며, CASB는 SWG·ZTNA·FWaaS와 함께 SSE를 구성하는 핵심 축의 하나가 되었다. 즉 CASB는 독립 제품에서 SASE/SSE 플랫폼의 한 기능으로 흡수·진화하는 추세다.

5. 도입 사례와 정량 효과

CASB의 가치는 추상적 통제 개념이 아니라 구체적 위험 감축으로 나타난다. 아래는 실무에서 반복적으로 확인되는 대표 유스케이스를 네 가지로 정리한 것으로, 각각 앞서 설명한 4대 기능이 어떻게 실제 사고 예방으로 이어지는지를 보여준다. 공통적으로 CASB는 "몰랐던 위험을 보이게 만들고, 보인 위험을 정책으로 차단하며, 남은 위험을 탐지·대응한다"는 순환을 실현한다. 대표적인 유스케이스는 섀도 IT 발견과 정리다. 어느 조직이 방화벽·프록시 로그를 CASB로 분석했더니 IT 부서가 인지한 승인 앱은 수십 개에 불과했으나 실제 사용 중인 클라우드 앱은 그 십수 배에 달했고, 그중 상당수가 데이터 암호화·규정 준수가 미흡한 고위험 앱으로 분류되었다고 하자. CASB는 이들을 위험 점수로 순위화해 상위 고위험 앱을 차단하고, 유사 기능의 승인 앱으로 사용자를 유도함으로써 통제 불능의 데이터 유출 경로를 대폭 줄인다. 이 과정에서 "무엇을 쓰는지 모른다"는 근본 문제를 "무엇을 쓰는지 알고, 위험한 것만 막는다"로 전환하는 것이 핵심 성과다.

두 번째 사례는 SaaS 협업 도구의 오·과다 공유 교정이다. 협업 스토리지에서 "링크가 있는 모든 사람"으로 공개된 파일, 외부 도메인과 공유된 민감 문서, 퇴사자 계정에 남은 접근 권한 등은 사고의 단골 원인이다. CASB의 API 기반 스캔은 이미 저장된 수백만 건의 파일과 공유 설정을 사후 점검해, 규정 위반 공유를 자동으로 회수·비공개 전환하거나 소유자에게 경고한다. 실시간 통제가 어려운 이 영역을 무중단으로 정리한다는 점에서 프록시 방식이 놓치는 공백을 메운다.

세 번째 사례는 계정 탈취 대응이다. 피싱으로 탈취된 SaaS 계정이 평소와 다른 국가·시간대에서 로그인해 대량 다운로드를 시도하는 정황을, CASB의 UEBA가 위험 점수 급상승으로 포착해 세션 차단·재인증(step-up MFA)·관리자 경보를 자동 발동한다. 예컨대 로그인 지점이 수 분 사이 서울→해외로 바뀌는 '불가능한 이동'과 평소의 10배가 넘는 다운로드가 동시에 관측되면 자동 격리 정책을 트리거하는 식이다. 이처럼 CASB는 가시성→통제→탐지·대응의 순환을 하나의 계층에서 완성한다.

네 번째 사례는 퇴직·이동 인력의 데이터 반출 방지다. 퇴직 예정자가 마지막 근무일 전후에 개인 클라우드 계정으로 대량의 자료를 옮기거나, 부서 이동자가 이전 업무 자료를 계속 열람하는 것은 내부자 유출의 전형이다. CASB는 인사 시스템·IdP의 상태 변화와 연동해 해당 사용자의 다운로드·외부 공유를 강화 감시하거나 차단하고, 접근 권한을 자동 회수한다. 이는 온프레미스에서 통제하던 내부자 위협 시나리오를 클라우드 환경으로 확장한 것으로, 신원 수명주기(joiner-mover-leaver) 관리와 CASB가 맞물려 작동하는 대표적 예다.

6. 심화 — SSE·SASE로의 통합과 최신 동향

CASB는 2010년대 초 독립적인 스타트업 제품군(Skyhigh Networks, Netskope 등)으로 출발했으나, 2018년 전후 대형 보안·네트워크 기업들이 이를 대거 인수하면서 통합 플랫폼의 부품으로 재편되었다. Gartner는 2019년 SASE, 2021년 그 보안 절반을 떼어낸 SSE(Security Service Edge) 개념을 제시했는데, SSE는 CASB·SWG·ZTNA(·FWaaS)를 하나의 클라우드 서비스로 융합한 것이다. 따라서 오늘날 신규 도입에서는 CASB 단품보다 SSE/SASE 플랫폼의 CASB 기능을 채택하는 것이 일반적이다.

이러한 통합이 갖는 실무적 의미는 정책·로그·관리 콘솔의 단일화다. 과거에는 SWG·CASB·DLP·ZTNA가 각기 다른 벤더·콘솔로 운영되어 정책이 파편화되고 사각지대가 생겼으나, SSE로 통합되면 하나의 정책 엔진이 웹·SaaS·사설 앱 접근을 일관되게 통제하고 단일 로그로 감사한다. 이는 운영 인력의 부담을 줄이고 위협 대응 속도를 높인다. 다만 통합 플랫폼은 특정 벤더 종속(lock-in) 위험을 키우므로, 도입 시 기능 성숙도와 종속성 사이의 균형을 저울질해야 한다.

기능 측면의 최신 흐름으로는 SSPM(SaaS Security Posture Management)과의 결합이 두드러진다. CASB가 트래픽·데이터 접근을 통제한다면, SSPM은 SaaS 자체의 보안 설정(과도한 권한, 미적용 MFA, 외부 공유 정책 등)을 지속 점검·교정한다. 두 기능이 결합되면 "데이터 흐름 통제(CASB) + 설정 위생 관리(SSPM)"의 이중 방어가 완성된다. 나아가 저장 위치·민감도·접근권한을 데이터 자체 관점에서 관리하는 DSPM(Data Security Posture Management)과 연계하면, "어떤 데이터가 어디에 있고 누가 접근하며 어떻게 흐르는가"를 통합적으로 조망할 수 있다.

또한 생성형 AI 사용 통제가 새로운 요구로 부상했다. 직원이 ChatGPT 등 생성형 AI 서비스에 사내 민감정보나 소스코드를 붙여넣는 위험이 커지면서, CASB가 AI 앱으로의 데이터 업로드를 DLP로 검사·차단하는 AI 접근 통제가 핵심 유스케이스가 되었다. 생성형 AI 통제의 주요 지점은 다음과 같다.

  • 입력(프롬프트) 검사: 고객 개인정보·미공개 소스코드·영업기밀이 프롬프트에 포함되면 탐지·마스킹·차단
  • 앱 가시성·등급화: 조직에서 쓰이는 AI 앱을 식별하고 위험도로 분류해 허용/차단 정책 적용
  • 경로 강제: 승인된 사내 AI 게이트웨이·엔터프라이즈 플랜으로만 요청을 유도(섀도 AI 차단)
  • 감사·기록: 누가 어떤 AI에 무엇을 보냈는지 로깅해 규제 대응·사후 추적 확보

이는 앞서 살펴본 섀도 IT 통제의 논리가 '섀도 AI'로 확장된 형태로 볼 수 있으며, 데이터 유출 방지의 초점이 파일 공유에서 대화형 AI 입력으로 옮겨가고 있음을 보여준다.

국내에서도 금융·공공을 중심으로 SaaS 도입이 확산되며 CASB/SSE 수요가 늘고 있고, 「클라우드컴퓨팅법」과 CSAP(클라우드 보안인증) 체계 아래에서 클라우드 사용 통제의 근거로 활용되는 사례가 증가하고 있다. 특히 망분리 규제가 완화·재편되는 흐름 속에서, 물리적 경계 대신 CASB·ZTNA 기반의 데이터·신원 중심 통제로 무게중심이 옮겨가는 것은 정보관리기술사 답안에서 다룰 만한 최신 쟁점이다.

7. 고려사항 및 시사점

  • 단품 vs 플랫폼 선택 전략: 이미 다수 SaaS를 운영하며 특정 앱의 심층 통제가 급한 조직은 성숙한 CASB 기능을 우선 확보하되, 중장기적으로는 SWG·ZTNA와 통합된 SSE/SASE 로드맵 위에서 CASB를 선택해 정책·로그·관리 콘솔의 파편화를 피해야 한다. 신규 도입일수록 통합 플랫폼이 총소유비용(TCO)과 운영 효율에서 유리하다.
  • 배포 방식의 트레이드오프 설계: 실시간 차단(프록시)과 광범위 가시성(API)은 상호 배타적이지 않으므로, 관리 단말은 포워드 프록시, BYOD는 리버스 프록시, 저장 데이터는 API로 커버하는 멀티모드를 기본 설계로 삼는다. 다만 인라인 프록시는 복호화(SSL 인터셉트)에 따른 지연·프라이버시·인증서 관리 부담을 수반하므로, 민감도가 낮은 트래픽은 우회하는 선택적 검사 정책이 필요하다.
  • 신원·거버넌스와의 정합성: CASB의 정책은 IdP·디렉터리의 사용자·그룹·역할과 연동될 때 최소권한·조건부 접근으로서 실효를 갖는다. 제로 트러스트 원칙(항상 검증) 아래 ZTNA와 결합해 "검증된 신원 + 통제된 데이터 흐름"을 함께 강제해야 하며, DLP 정책은 데이터 분류체계(중요도 라벨링)와 일관되게 설계해야 오탐·과차단을 줄인다.
  • 가시성 사각지대 최소화: CASB의 효과는 커버리지에 비례한다. API가 지원되지 않는 앱, 서버 간 자동화 트래픽, 프록시를 우회하는 네이티브 모바일 앱 등은 사각지대로 남을 수 있으므로, 로그 수집원(방화벽·프록시·EDR)을 폭넓게 연동하고 배포 방식을 멀티모드로 조합해 통제 범위를 지속적으로 넓혀야 한다.
  • 프라이버시·법적 리스크 관리: 트래픽 복호화와 사용자 행위 모니터링은 근로자 감시·통신비밀 침해 논란을 부를 수 있으므로, 검사 범위·목적·보관기간을 사전에 고지하고 노사 합의·내부 규정으로 정당성을 확보해야 한다. 국외 리전 저장 데이터에 대한 데이터 주권 요구는 CASB의 위치·설정 점검으로 관리한다.
  • 성능·가용성 설계: 인라인 프록시는 트래픽 경로 위에 놓이므로 CASB 자체가 단일 장애점(SPOF)이 될 수 있다. 글로벌 PoP·이중화·장애 시 우회(fail-open/fail-close) 정책을 사전에 정의하고, 복호화 부하가 사용자 체감 성능을 해치지 않도록 용량을 산정해야 한다. 보안을 위해 fail-close를 택할지, 가용성을 위해 fail-open을 택할지는 자산 민감도에 따라 트래픽 유형별로 차등 적용하는 것이 바람직하다.
  • 운영 성숙도와 튜닝 부담: CASB는 도입 자체보다 운영이 관건이다. DLP 규칙의 오탐은 업무를 방해하고, 과도한 차단은 사용자가 우회 경로(다시 섀도 IT)를 찾게 만든다. 따라서 초기에는 모니터링(탐지) 모드로 정책을 학습·조정한 뒤 단계적으로 차단(강제) 모드로 전환하는 점진적 접근이 필요하며, 위험 점수 임계값·예외 목록·사용자 코칭(경고 후 허용)을 병행해 보안과 생산성의 균형을 잡아야 한다.
  • 여타 보안 체계와의 연계 운용: CASB는 홀로 작동하지 않는다. 탐지한 위협·위반 이벤트를 SIEM·SOAR로 전달해 통합 대응 워크플로에 태우고, IdP·EDR·DLP와 정책·컨텍스트를 주고받아야 효과가 배가된다. 즉 CASB는 클라우드 보안의 '눈과 손'이되, 그 신호를 처리하는 전사적 보안 운영(SOC) 체계와 맞물릴 때 비로소 완결된 통제가 된다.
  • 전망과 연계 기술: CASB는 독립 카테고리에서 SSE의 데이터·앱 보안 계층으로 흡수되며, SSPM·DSPM(데이터 보안 태세 관리)·생성형 AI 통제와 결합해 "클라우드·데이터 중심 통합 보안"으로 진화하고 있다. 기술사 관점에서는 단순 도입이 아니라 EA·클라우드 전환 전략·제로 트러스트 아키텍처와 정합된 통합 설계 역량이 요구된다. 예상 출제 방향으로는 CASB의 4대 기능과 배포 방식 서술, SASE/SSE·ZTNA와의 관계 비교, 섀도 IT·생성형 AI 통제 사례 제시 등이 유력하며, 답안은 "왜 필요한가(경계 소멸)→무엇을 하는가(4대 기능)→어떻게 적용하는가(배포·멀티모드)→어디로 가는가(SSE 통합)"의 흐름으로 구성하는 것이 효과적이다.

참고자료

한 줄 요약: CASB는 사용자와 클라우드 서비스 사이의 중개 지점에서 가시성·컴플라이언스·데이터 보안·위협 방어의 4대 기능을 API/프록시 방식으로 강제하는 보안 통제 계층으로, 섀도 IT와 SaaS 데이터 유출을 막으며 오늘날 SSE/SASE의 핵심 축으로 통합·진화하고 있다.