CASB 도입 2026, Shadow IT·SaaS 보안·운영 기준

CASB 도입을 검토하는 보안 운영실과 SaaS 접근 대시보드 — CASB는 Shadow IT 목록, SaaS 데이터 정책, 세션 제어 책임을 한 회의 안에서 맞추는 보안 운영 체계다.

CASB 도입을 검토하는 조직은 보통 SaaS가 이미 너무 많이 퍼진 뒤에 회의를 시작한다.

문제는 제품 기능이 아니라 어떤 앱을 허용하고, 어떤 접속을 막고, 어떤 예외를 누가 승인할지 아직 정해지지 않았다는 점이다.

Microsoft 문서는 CASB가 Shadow IT 발견, 클라우드 앱 위험 평가, DLP 정책, 비관리 장치 제어, 악성 파일 대응을 다룬다고 설명한다.

이 글은 원문 요약이 아니라 CASB를 사야 하는 팀이 PoC 범위와 운영 기준을 먼저 고정하도록 만든 실무 검토 메모다.

핵심 요약

CASB는 SaaS 목록을 보는 도구가 아니라 Shadow IT 발견, 앱 검사, 인라인 세션 제어, DLP, 예외 승인을 묶는 운영 체계다.
Microsoft 365 중심이면 Defender for Cloud Apps 범위와 라이선스 전제를 먼저 확인하고, 네트워크 경로가 핵심이면 SSE·SWG 연동을 같이 본다.
PoC는 모든 SaaS를 막는 방식이 아니라 상위 50개 앱 분류, 고위험 공유 탐지, 비관리 장치 다운로드 제어부터 시작해야 한다.
견적은 사용자 수만 보지 말고 로그 수집원, 앱 커넥터, 세션 프록시, DLP 정책 튜닝, 예외 처리 시간을 따로 적어야 한다.

이 글이 필요한 사람

Microsoft 365, Salesforce, GitHub, Slack, Notion 같은 SaaS 사용량이 늘었지만 허용 앱 목록이 정리되지 않은 보안 담당자
개인 클라우드와 생성형 AI 웹앱 업로드를 막아야 하지만 VPN, SWG, DLP, CASB의 경계가 헷갈리는 IT 관리자
CASB 견적을 받았는데 사용자 라이선스와 로그 수집, 앱 커넥터, 세션 제어 비용을 분리하지 못한 구매 담당자
임직원의 비관리 노트북, 외부 협력사 계정, 모바일 브라우저에서 SaaS 파일 다운로드를 제한하려는 보안 아키텍트
감사 대응용으로 Shadow IT 목록과 승인·차단 근거를 남겨야 하는 컴플라이언스 담당자

CASB 도입의 첫 질문은 허용 앱 목록이다

CASB를 바로 인라인 차단 장비처럼 보면 PoC가 흔들린다.

먼저 해야 할 일은 최근 30일의 방화벽, 프록시, EDR 네트워크, IdP 로그인 로그에서 실제 SaaS 목록을 뽑는 것이다.

Microsoft Learn은 Defender for Cloud Apps가 SaaS 앱 보호, 위협 방어, 데이터 제어, 보안 태세 관리를 제공한다고 설명한다.

같은 문서에서 Office 365 Cloud App Security는 전체 Defender for Cloud Apps가 아니라 Office 365 앱 커넥터 중심의 부분 집합이라고 구분한다.

이 차이를 모르면 라이선스는 샀는데 Salesforce, GitHub, 외부 SaaS 업로드가 정책 범위 밖에 남는다.

이 조건이면 CASB 도입 전 허용 앱 목록과 차단 후보 목록을 먼저 분리해야 한다.

사용자가 몰래 쓰는 앱을 한 번에 막으면 업무 우회가 생기므로 위험 등급, 대체 앱, 데이터 유형을 함께 적어야 한다.

공식 문서 기준 핵심 사실

Microsoft의 CASB 설명은 Shadow IT 발견, 앱 위험 평가, 지속 모니터링, DLP 정책, 비관리 장치 보호, 악성 파일 탐지를 주요 사용 사례로 제시한다.
Defender for Cloud Apps 개요는 SaaS 보호를 기존 CASB 범위보다 넓게 보고, 앱 사용 모니터링과 데이터 제어를 결합한다고 설명한다.
Get started 문서는 Cloud Discovery, 앱 커넥터, 앱 거버넌스, 조건부 접근 앱 제어, SIEM 에이전트 연결 같은 순서형 작업을 포함한다.
Microsoft의 에디션 비교 문서는 전체 Defender for Cloud Apps와 Office 365 Cloud App Security의 커버리지 차이를 표로 제시한다.
해당 비교 문서는 cloud discovery 범위에서 34,000개 이상 cloud apps와 750개 이상 Office 365 유사 앱이라는 차이를 보여준다.
Zscaler는 CASB를 SaaS와 IaaS 데이터 보호, inline 실시간 보안, out-of-band scanning을 함께 쓰는 multimode 구조로 설명한다.
Palo Alto Networks는 CASB를 SASE의 핵심 기능 중 하나로 보고, 기존 정적 앱 라이브러리 기반 CASB의 한계를 지적한다.
CISA CPG와 NIST CSF는 특정 CASB 제품 문서는 아니지만 자산 식별, 접근 통제, 로그, 대응 절차를 정책 근거로 삼기 좋다.

공식 문서의 공통점은 CASB가 한 가지 차단 버튼으로 끝나지 않는다는 점이다.

앱 발견, 앱 연결, 세션 제어, DLP, 악성 파일 대응, 티켓 라우팅을 한 운영 흐름으로 엮어야 한다.

CASB, DLP, SWG, CNAPP를 섞어 사면 안 되는 이유

구분	주요 보호 위치	강한 지점	먼저 볼 한계	CASB 도입 판단
CASB	SaaS 앱, 클라우드 앱 사용, 앱 커넥터, 세션	Shadow IT 발견과 SaaS 데이터 정책을 업무 앱 단위로 다룬다.	네트워크 전체 위협 차단이나 클라우드 워크로드 런타임 보호는 별도 축이다.	비관리 SaaS와 외부 공유가 핵심이면 우선 검토한다.
DLP	문서, 이메일, 엔드포인트, 저장소	민감정보 유형과 정책 예외를 데이터 중심으로 관리한다.	앱 사용 위험과 Shadow IT 목록을 단독으로 완성하지 못할 수 있다.	민감정보 정의가 먼저라면 DLP 정책을 CASB에 연결한다.
SWG·SSE	웹 트래픽, 브라우저, 원격 사용자 경로	URL 필터링, 악성 사이트 차단, 인라인 세션 제어에 강하다.	앱 커넥터 기반 SaaS 내부 파일 상태는 별도 커넥터가 필요할 수 있다.	비관리 장치 다운로드와 개인 클라우드 업로드가 핵심이면 같이 본다.
CNAPP	클라우드 워크로드, 계정, 컨테이너, IaC	CSPM, CWPP, CIEM, 취약점, 런타임 리스크를 클라우드 인프라 단위로 본다.	사용자의 SaaS 협업 문서와 Shadow IT는 CASB 범위가 더 직접적이다.	AWS, Azure, GCP 계정 위험이 주제라면 CNAPP가 우선이다.
IAM·IdP	사용자, 그룹, 인증, 조건부 접근	SSO, MFA, 위험 로그인, 권한 수명주기를 통제한다.	로그인 이후 SaaS 파일 공유와 다운로드 제어는 별도 정책이 필요하다.	조건부 접근 신호를 CASB 정책의 입력값으로 쓴다.

이 표를 회의 앞부분에 놓으면 제품 이름보다 보호 위치로 대화가 바뀐다.

CASB 도입은 DLP나 IAM을 대체하는 프로젝트가 아니라 SaaS 사용 경로에 두 정책을 붙이는 프로젝트에 가깝다.

라이선스와 운영 비용은 숫자 기준으로 분리한다

CASB 견적은 공개 가격표가 부족한 경우가 많아 사용자 수만 보고 비교하면 거의 틀린다.

Microsoft 365 enterprise 비교 페이지는 Enterprise Agreement 고객을 보통 250개 초과 라이선스 규모로 설명하고, 구독 취소 뒤 데이터 보존을 일반적으로 90일로 안내한다.

Microsoft 에디션 비교 문서는 Defender for Cloud Apps의 cloud discovery가 34,000개 이상 앱을 다루고, Office 365 Cloud App Security는 750개 이상 유사 앱 범위라고 설명한다.

이 숫자는 가격표가 아니라 범위와 구매 전제의 기준선이다.

견적서에는 사용자 월액, 수집 로그 GB, 앱 커넥터 수, 인라인 세션 제어 대상 앱, 정책 튜닝 시간을 별도 행으로 받아야 한다.

비용 항목	공식 문서에서 확인한 숫자·단위	견적 질문	실무 판단
구매 규모 전제	Microsoft enterprise 비교 페이지는 Enterprise Agreement를 보통 250개 초과 licenses 규모로 설명한다.	우리 조직은 EA, CSP, 직접 구매, 보안 add-on 중 어떤 경로인가.	대규모 계약이면 단가보다 포함 기능과 add-on 경계를 먼저 본다.
데이터 보존 전제	Microsoft는 구독 취소 후 데이터 검색 가능 기간을 일반적으로 90일로 설명한다.	CASB 로그와 정책 증거 보존 기간은 제품 기본값과 계약에서 몇 일인가.	감사 대응 조직은 보존 기간과 export 비용을 별도 비용으로 본다.
앱 발견 범위	Defender for Cloud Apps는 34,000개 이상 cloud apps discovery 범위를 제시한다.	우리 로그에서 실제로 분류해야 할 상위 앱 50개와 전체 앱 수는 얼마인가.	앱 라이브러리 숫자보다 우리 조직의 상위 위험 앱 분류가 더 중요하다.
부분 제품 범위	Office 365 Cloud App Security는 750개 이상 Office 365 유사 앱 범위로 설명된다.	현재 라이선스가 전체 Defender for Cloud Apps인지 부분 기능인지 확인했는가.	부분 기능으로 PoC하면 Shadow IT 범위를 과소평가할 수 있다.
운영 지표 범위	첫 PoC는 30일 로그 수집, 상위 50개 앱 분류, 48시간 오탐 리뷰 SLA로 잡는다.	보안팀이 매주 몇 시간 정책 튜닝과 예외 승인에 쓸 수 있는가.	월 구독료가 낮아도 튜닝 시간이 길면 총비용은 올라간다.

비용 검토의 결론은 견적 숫자를 맞히는 것이 아니라 숨은 비용 단위를 분리하는 것이다.

사용자 라이선스와 운영 시간을 분리해 두면 공급자별 가격표가 달라도 같은 표로 비교할 수 있다.

PoC는 차단보다 관찰과 경고에서 시작한다

CASB 도입 PoC를 첫날부터 차단으로 시작하면 업무팀이 우회 브라우저와 개인 계정을 만든다.

첫 2주는 발견 모드로 두고 앱 목록, 사용자 그룹, 데이터 유형, 외부 공유 이벤트를 쌓는 편이 안전하다.

그다음 2주는 고위험 조합에만 경고와 사유 입력을 적용한다.

예를 들어 비관리 장치에서 계약서 파일을 외부 공유 링크로 받는 경우는 다운로드 차단 후보로 올린다.

반대로 영업팀이 승인된 CRM에서 PDF 제안서를 외부 고객에게 보내는 경우는 경고와 라벨 확인으로 충분할 수 있다.

최근 30일 로그에서 SaaS 앱 목록과 사용자 그룹별 사용량을 추출한다.
허용 앱, 검토 앱, 차단 후보 앱을 데이터 오너와 함께 3단계로 나눈다.
상위 50개 앱에 대해 위험 등급, 업무 대체 앱, 저장 데이터 유형을 기록한다.
Microsoft 365, CRM, 코드 저장소, 파일 공유 앱부터 앱 커넥터 권한을 검토한다.
비관리 장치, 외부 IP, 위험 로그인, 신규 국가 접속을 조건부 접근 신호로 연결한다.
민감정보 정책은 주민번호, 결제정보, 계약서, 소스코드 비밀값처럼 실제 데이터 유형으로 시작한다.
첫 차단 정책은 다운로드 금지가 아니라 warn, justify, monitor 단계로 운영 반발을 줄인다.
예외 승인에는 데이터 오너, 만료일, 티켓 번호, 사유, 재검토 날짜를 반드시 넣는다.
SIEM과 티켓 시스템으로 high severity 이벤트가 가는지 모의 이벤트로 검증한다.
월간 리뷰에서 앱 재분류, 오탐, 예외 만료, 신규 SaaS 승인 여부를 결정한다.

실무 시나리오 1: Microsoft 365 중심 조직

실무 시나리오 1은 Microsoft 365 사용률이 높고 외부 공유 링크와 Teams 파일 다운로드가 감사 이슈인 회사다.

이 경우는 Defender for Cloud Apps, Purview DLP, Entra 조건부 접근의 경계를 먼저 표로 나눈다.

CASB 정책은 SharePoint와 OneDrive 외부 공유, 비관리 장치 다운로드, OAuth 앱 권한, 고위험 로그인 세션을 한 묶음으로 본다.

이 조건이면 Office 365 Cloud App Security만으로 충분한지 전체 Defender for Cloud Apps가 필요한지 라이선스 문서로 확인해야 한다.

PoC 성공 기준은 외부 공유 차단 건수가 아니라 데이터 오너가 예외를 승인하고 만료시킬 수 있는지다.

실무 시나리오 2: SaaS가 많은 스타트업·개발 조직

실무 시나리오 2는 GitHub, Notion, Slack, Figma, 생성형 AI 웹앱, 개인 클라우드가 섞인 개발 조직이다.

이 경우는 금지 앱 목록을 먼저 쓰면 실패한다.

개발팀이 쓰는 SaaS를 승인 앱, 검토 앱, 개인 계정 금지 앱으로 나누고 대체 경로를 제공해야 한다.

소스코드와 앱 커넥터 키는 GitHub Secret Scanning, DLP, CASB 업로드 경로를 같이 봐야 빠진 구멍이 줄어든다.

이 조건이면 CASB만 사는 것보다 IdP 그룹, 브라우저 정책, DLP 민감정보 유형을 먼저 정비하는 편이 빠르다.

정책 설계는 앱 커넥터, 인라인, 로그 수집을 분리한다

정책 모드	적용 위치	첫 정책 예시	오탐 위험	운영 owner
앱 커넥터	승인된 SaaS 내부 파일과 설정	외부 공개 링크와 민감 문서 조합 탐지	기존 공유 문서가 한꺼번에 걸릴 수 있다.	SaaS 관리자와 데이터 오너
인라인 세션 제어	브라우저 업로드·다운로드와 비관리 장치	비관리 장치에서 계약서 다운로드 차단	프록시 경로와 사용자 경험 이슈가 생길 수 있다.	보안팀과 네트워크팀
Cloud Discovery	방화벽·프록시·EDR 로그	상위 50개 미승인 SaaS 앱 분류	로그 필드가 부족하면 앱 식별이 틀릴 수 있다.	보안 운영팀
DLP 연동	민감정보 유형과 라벨	개인정보 포함 파일의 외부 공유 경고	정규식 오탐과 업무 예외가 많을 수 있다.	보안팀과 개인정보 담당자
SIEM·티켓 연동	경보와 대응 증거	high severity 이벤트 자동 티켓 생성	경보가 많으면 담당자가 무시할 수 있다.	SOC와 서비스 오너

정책 모드를 분리하면 PoC 범위도 작아진다.

앱 커넥터로 이미 저장된 위험 공유를 찾고, 인라인 세션 제어로 신규 다운로드를 막고, 로그 수집으로 미승인 앱을 분류하는 순서가 안전하다.

CASB 도입 전 정책 스켈레톤

아래 YAML은 제품 설정 파일이 아니라 도입 회의에서 범위 누락을 막기 위한 검토 스켈레톤이다.

# casb-scope-intake.yml
# 목적: CASB 도입 PoC 전에 보호할 SaaS, 접속 경로, 데이터 정책, 예외 책임자를 고정한다.
# 실제 제품의 커넥터 이름과 정책명은 Microsoft Defender for Cloud Apps, SSE, DLP 문서에 맞게 바꾼다.

business_scope:
  target_departments:
    - sales
    - finance
    - engineering
    - external_partner_users
  sanctioned_saas:
    - microsoft_365
    - salesforce
    - github_enterprise
    - servicenow
  unmanaged_saas_review:
    discovery_window_days: 30
    minimum_user_count: 5
    risk_threshold: high

control_modes:
  app_connector:
    use_for: sanctioned_saas_inventory_and_file_scan
    first_policy: detect_public_link_and_external_share
  inline_session_control:
    use_for: unmanaged_device_and_high_risk_login
    first_policy: block_download_or_require_label
  log_discovery:
    use_for: shadow_it_baseline
    sources:
      - firewall_proxy_logs
      - endpoint_network_events
      - identity_sign_in_logs
  dlp_integration:
    sensitive_types:
      - personal_identifier
      - contract_document
      - source_code_secret
      - payment_data

exception_workflow:
  approver: data_owner
  expiry_days: 30
  evidence_ticket: required
  quarterly_review: required
  break_glass_reason: required

success_metrics:
  shadow_it_apps_classified: 100_percent_of_top_50
  high_risk_external_shares_reduced: monthly_trend_down
  false_positive_review_sla_hours: 48
  policy_change_audit: every_release

핵심은 승인 앱 목록과 미승인 앱 목록을 제품 콘솔이 아니라 데이터 오너 회의에서 먼저 확정하는 것이다.

정책에 만료일 없는 예외가 생기면 CASB는 곧 예외 저장소가 된다.

준비 점수와 예외 만료를 자동으로 확인한다

CASB 도입은 구축보다 운영 준비가 더 자주 실패한다.

아래 Python 예시는 특정 벤더 인터페이스를 호출하지 않고 회의 전 빠진 준비 항목을 찾는 방식이다.

# casb_readiness_check.py
# 목적: 특정 CASB 벤더 인터페이스를 호출하지 않고 도입 회의에서 빠진 준비 항목을 찾는 검증용 스켈레톤이다.
# 입력은 SaaS 관리자 export, IdP sign-in log, proxy/firewall log, DLP policy list, 보안 티켓에서 가져온다고 가정한다.

CHECKS = {
    "sanctioned_saas_inventory_done": 15,
    "shadow_it_log_source_connected": 15,
    "identity_risk_signal_available": 10,
    "data_owner_for_top_apps_named": 10,
    "dlp_sensitive_types_defined": 10,
    "unmanaged_device_policy_tested": 10,
    "app_connector_permissions_reviewed": 10,
    "exception_expiry_workflow_defined": 10,
    "siem_ticket_route_tested": 5,
    "license_cost_structure_confirmed": 5,
}

sample = {
    "sanctioned_saas_inventory_done": True,
    "shadow_it_log_source_connected": True,
    "identity_risk_signal_available": False,
    "data_owner_for_top_apps_named": True,
    "dlp_sensitive_types_defined": True,
    "unmanaged_device_policy_tested": False,
    "app_connector_permissions_reviewed": False,
    "exception_expiry_workflow_defined": True,
    "siem_ticket_route_tested": True,
    "license_cost_structure_confirmed": False,
}

score = sum(weight for key, weight in CHECKS.items() if sample.get(key))
missing = [key for key in CHECKS if not sample.get(key)]
print({"score": score, "missing": missing})

예외 승인도 만료되지 않으면 정책 품질이 빠르게 떨어진다.

아래 SQL은 30일이 지난 예외와 승인 뒤에도 이벤트가 계속 발생하는 정책을 리뷰 목록으로 올리는 예시다.

-- casb_exception_review.sql
-- 목적: 30일이 지난 CASB 예외와 반복 승인자를 찾아 데이터 오너 회의에 올린다.
-- 실제 테이블명은 CASB 콘솔 export, SIEM, 티켓 시스템 스키마에 맞게 바꾼다.

select
  exception_id,
  app_name,
  user_group,
  policy_name,
  business_reason,
  approved_by,
  created_at,
  expires_at,
  event_count_after_approval
from casb_policy_exceptions
where expires_at < current_date
   or event_count_after_approval > 20
order by expires_at asc, event_count_after_approval desc;