2025년 10월 20일·7분
제이 차우드리와 Zscaler: 클라우드 규모를 위한 제로 트러스트
제이 차우드리와 Zscaler가 클라우드 보안, 제로 트러스트, 파트너 기반 유통을 활용해 엔터프라이즈 보안 리더가 된 과정을 실용적으로 분석한 글입니다.
제이 차우드리와 Zscaler가 클라우드 보안, 제로 트러스트, 파트너 기반 유통을 활용해 엔터프라이즈 보안 리더가 된 과정을 실용적으로 분석한 글입니다.
이 글은 제이 차우드리 전기라기보다 Zscaler가 어떻게 엔터프라이즈 보안을 재구성했는지, 그리고 그들이 내린 기술적·상업적 선택이 왜 중요했는지를 실용적으로 설명합니다.
병행해서 두 가지를 배우게 될 것입니다:
현대적 엔터프라이즈 보안은 직원들이 인터넷과 내부 앱을 안전하게 사용하도록 허용하는 통제의 집합입니다. ‘회사 네트워크 내부라 안전하다’는 전제를 더 이상 믿지 않고, 매번 누가 연결하는지, 무엇에 연결하는지, 그리고 그 연결을 허용해야 하는지를 확인하는 것이 핵심입니다.
끝에는 Zscaler의 핵심 베팅을 한 문장으로 설명할 수 있고, 제로 트러스트가 VPN 시대의 사고방식을 어디서 대체하는지 인식하며, 유통 전략이 제품 설계만큼이나 중요할 수 있음을 이해하게 될 것입니다.
제이 차우드리는 Zscaler의 창업자 겸 CEO로 잘 알려진 연쇄 창업자입니다. 그는 Zscaler 이전에도 여러 보안 스타트업을 세우고 매각했으며, 이를 통해 공격자 행태와 엔터프라이즈 IT가 얼마나 빠르게 변하는지 직접 목격했습니다.
차우드리의 초점은 명확했습니다: 업무와 애플리케이션이 기업 네트워크 밖(공용 인터넷과 클라우드 서비스)으로 이동함에 따라 모든 트래픽을 중앙 데이터센터로 라우팅해 검사하던 오래된 모델이 붕괴되기 시작했습니다.
이 변화는 IT 팀에 고통스러운 딜레마를 만들었습니다:
Zscaler의 창업 전제는 보안은 ‘건물’을 따라가야 하는 것이 아니라 ‘사용자’를 따라가야 한다는 것이었습니다.
특히 눈에 띄는 점은 창업자 주도의 제품 비전이 초기에 회사 전략에 깊은 영향을 미쳤다는 것입니다:
이것은 단순한 마케팅 수식어가 아니었고 제품 결정, 파트너십, 보수적 엔터프라이즈 구매자에게 ‘왜’를 설명하는 방식에 영향을 주었습니다. 시간이 지나며 그 명확성은 “클라우드 전달 보안”과 “제로 트러스트”를 개념에서 예산 항목으로 바꾸는 데 기여했습니다—큰 기업들이 구매하고 배포하고 표준화할 수 있는 것으로요.
오랫동안 엔터프라이즈 보안은 ‘좋은 것’을 기업 네트워크 내부에 두고 그 주위에 벽을 쌓는 단순한 아이디어를 기반으로 했습니다. 그 벽은 보통 몇몇 데이터센터에 놓인 온프레미스 어플라이언스(방화벽, 웹 프록시, 침입 방지 등)의 스택이었습니다. 원격 직원은 VPN을 통해 들어왔고, 이는 그들이 어디에 있든 내부 네트워크를 확장했습니다.
대부분의 애플리케이션이 회사 데이터센터에 있을 때는 이 방식이 비교적 잘 작동했습니다. 웹 트래픽과 애플리케이션 트래픽은 같은 병목을 통과했고, 보안팀은 검사·로그·차단을 할 수 있었습니다.
하지만 이 모델은 두 가지 전제를 가지고 있었고, 그것들이 사실이 아니게 되었습니다:
직원들이 더 모바일해지고 SaaS 채택이 가속화되면서 트래픽 패턴이 역전되었습니다. 커피숍에 있는 사람이 Office 365, Salesforce, 수십 개의 브라우저 기반 도구에 빠르게 접근해야 했고, 종종 기업 데이터센터를 전혀 통하지 않았습니다.
정책을 계속 적용하려고 많은 회사가 트래픽을 “백홀(backhaul)”했습니다: 사용자의 인터넷·SaaS 요청을 먼저 본사로 보내 검사한 뒤 다시 보냈습니다. 결과는 예측 가능했습니다: 느린 성능, 불만족스러운 사용자, 통제 허물기 압력 증가.
복잡성이 급증(더 많은 어플라이언스, 더 많은 규칙, 더 많은 예외). VPN은 광범위한 네트워크 접근을 부여할 때 과부하와 위험을 초래했습니다. 각 지점이나 인수합병은 또 다른 하드웨어 롤아웃, 더 많은 용량 계획, 더 취약한 아키텍처를 의미했습니다.
그 간극—물리적 경계를 강제하지 않고 일관된 보안을 필요로 하는 상황—이 사용자를 따라가고 애플리케이션을 따라가는 클라우드 전달 보안의 기회를 만들었습니다.
Zscaler의 정의적 베팅은 말로는 간단하지만 실행은 어려웠습니다: 보안을 회사 네트워크 내부에 있는 박스가 아니라 사용자 근처에 위치한 클라우드 서비스로 전달하겠다는 것입니다.
이 문맥에서 ‘클라우드 보안’은 클라우드 서버만을 보호한다는 뜻이 아닙니다. 보안 그 자체가 클라우드에서 동작한다는 뜻입니다—지점에 있는 사용자가 가까운 보안 PoP에 연결하면 그곳에서 정책이 집행됩니다.
‘인라이닝’은 목적지로 가는 길에 보안 검사소를 통과시키는 것과 같습니다.
직원이 웹사이트나 클라우드 앱에 접속할 때 그 연결은 서비스로 먼저 유도됩니다. 서비스는 정책에 따라 가능한 범위를 검사하고, 위험한 목적지를 차단하며, 위협을 스캔한 뒤 허용된 트래픽을 전달합니다. 목표는 사용자가 ‘기업 네트워크에 있어야’ 기업급 보호를 받는 것이 아니라 보안이 사용자와 함께 이동하도록 하는 것입니다.
클라우드 전달 보안은 IT·보안 팀의 일상 현실을 바꿉니다:
이 모델은 또한 기업이 실제로 작동하는 방식과 일치합니다: 트래픽은 종종 SaaS와 공용 인터넷으로 직접 향하고, ‘먼저 본사로 가라’는 방식과는 다릅니다.
제3자를 인라인에 두는 것은 팀이 평가해야 할 현실적 우려를 제기합니다:
핵심 베팅은 기술적 요소뿐 아니라 클라우드 제공자가 글로벌 규모로 신뢰성 있게 정책을 집행할 수 있다는 운영상 신뢰에 관한 것입니다.
제로 트러스트의 간단한 원칙은: ‘회사 네트워크 내부’라는 이유만으로 안전하다고 가정하지 말라는 것입니다. 대신 항상 검증합니다—사용자가 누구인지, 어떤 장치인지, 특정 앱이나 데이터에 접근해야 하는지 여부를 필요한 때마다 확인합니다.
전통적 VPN 사고방식은 누군가가 건물 앞문을 통과하면 전체 건물 출입증을 주는 것과 비슷합니다. VPN 연결 후 많은 시스템은 그 사용자를 ‘내부’로 취급해 의도치 않은 노출을 낳습니다.
제로 트러스트는 그 모델을 뒤집습니다. 이는 한 사람에게 **한 작업을 위한 한 방(room)**에 대한 접근을 주는 것과 비슷합니다. 네트워크에 광범위하게 ‘조인’하지 않고, 승인된 특정 앱만 도달할 수 있게 허용됩니다.
계약직 직원이 두 달 동안 프로젝트 관리 도구에 접근해야 하는 경우, 제로 트러스트에서는 그 단일 앱에만 접근을 허용할 수 있습니다—급여 시스템이나 내부 관리자 도구로의 우발적 경로를 차단하면서요.
직원이 BYOD(개인 노트북)를 사용해 여행 중인 경우, 제로 트러스트 정책은 더 강한 로그인 검사 요구 또는 장치가 오래됐거나 암호화되지 않았거나 침해 징후가 있으면 접근을 차단할 수 있습니다.
원격 근무는 보안 결정이 물리적 사무실 네트워크가 아니라 사용자와 애플리케이션을 따른다는 점 때문에 더 안전하게 관리됩니다.
제로 트러스트는 단일 제품을 사서 ‘켜는’ 것으로 끝나는 것이 아닙니다. 도구와 정책을 통해 구현되는 보안 접근 방식입니다.
또한 ‘아무도 믿지 말라’는 적대적 태도를 의미하지 않습니다. 실무에서는 신뢰를 지속적으로 얻는다는 의미로, 신원 확인, 장치 상태 검증, 최소 권한 접근을 통해 실수와 침해가 자동으로 확산되지 않도록 합니다.
Zscaler는 사람이 무엇에 접근하려 하는지 사이에 놓이는 클라우드 ‘제어 지점’으로 이해하는 것이 가장 쉽습니다. 기업 네트워크 경계를 신뢰하는 대신, 각 연결을 사용자 신원과 상황을 바탕으로 평가하고 적절한 정책을 적용합니다.
대부분 배포는 네 가지 간단한 요소로 설명할 수 있습니다:
개념적으로 Zscaler는 트래픽을 두 갈래로 분리합니다:
이 분리는 중요합니다: 한 갈래는 안전한 인터넷 사용에 관한 것이고, 다른 한 갈래는 내부 시스템에 대한 정밀한 접근에 관한 것입니다.
결정은 신뢰된 사무실 IP 주소에 기반하지 않습니다. 대신 사용자가 누구인지, 장치 상태(관리되는지 여부, 패치 상태), 어디서/어떻게 연결하는지 같은 신호에 기반합니다.
잘 구현되면 공격 표면이 줄고, 무언가 잘못됐을 때 수평 이동이 제한되며, 접근 통제가 더 단순하고 일관된 정책 모델로 전환됩니다—특히 원격 근무와 클라우드 우선 애플리케이션 스택이 기본이 되는 상황에서 유효합니다.
사람들이 ‘엔터프라이즈 보안’이라 말할 때 내부 네트워크와 프라이빗 앱을 먼저 떠올리지만, 큰 위험은 오픈 인터넷 측에 있습니다: 직원들이 뉴스 사이트를 보거나 이메일의 링크를 클릭하거나 브라우저 기반 도구를 사용하거나 웹 앱에 파일을 업로드하는 행위 등입니다.
보안 웹 게이트웨이(SWG)는 매일의 인터넷 접근을 보다 안전하게 만들기 위해 만들어진 범주로, 모든 사용자의 트래픽을 중앙 사무실로 되돌려 보내지 않고도 보호를 제공합니다.
단순히 말해, SWG는 사용자와 공용 웹 사이의 통제된 검사 지점 역할을 합니다. 디바이스가 도달하는 무엇이든 신뢰하는 대신, 게이트웨이는 정책과 검사를 적용해 조직이 악성 사이트, 위험한 다운로드, 우발적 데이터 유출로부터 노출을 줄일 수 있게 합니다.
일반적 보호 기능은 다음을 포함합니다:
사용자가 어디에나 있고 애플리케이션도 어디에나 있다면 트래픽을 단일 기업 경계로 백홀하는 것은 지연을 초래하고 맹점을 만듭니다.
클라우드 전달 SWG는 새로운 현실에 부합했습니다: 정책이 사용자를 따르고, 트래픽은 사용자가 연결하는 지점 근처에서 검사될 수 있으며, 본사·지점·원격 근무 전반에 걸쳐 보안 팀이 일관된 통제를 가질 수 있습니다—인터넷을 예외처럼 취급하지 않고요.
VPN은 ‘네트워크에 있다’는 것이 ‘앱에 도달할 수 있다’는 것과 동일하던 시기를 위해 만들어졌습니다. 애플리케이션이 여러 클라우드, SaaS, 소수의 온프레미스 시스템에 분산되면서 그 사고방식은 깨집니다.
앱 중심 접근은 기본값을 뒤집습니다. 사용자를 내부 네트워크에 넣고 세그멘테이션 정책이 유지되기를 바라는 대신, 사용자는 특정 애플리케이션으로만 연결됩니다.
개념적으로 이는 중개 연결처럼 작동합니다: 사용자는 자신이 누구이며 무엇에 접근 가능한지 증명하고, 그 후 내부 IP 범위를 인터넷에 공개하지 않고도 그 앱에 대한 짧고 제어된 경로가 만들어집니다.
네트워크 세분화는 강력하지만 실제 조직에서는 취약합니다: 합병, 플랫 VLAN, 레거시 앱, 예외가 쌓이기 쉽습니다. 앱 세분화는 비즈니스 의도에 직접 대응하기 때문에 이해하기 쉽습니다:
이렇게 하면 암묵적 신뢰가 줄고 접근 정책을 애플리케이션과 사용자 그룹 단위로 감사할 수 있어 더 명확합니다.
대부분 팀은 VPN을 한 번에 대체하지 않습니다. 실용적 롤아웃은 보통 다음과 같습니다:
앱 중심 접근이 잘되면 성과가 빠르게 드러납니다: VPN 관련 지원 티켓 감소, 보안·IT가 설명하기 쉬운 명확한 접근 규칙, 네트워크에 먼저 연결하지 않고도 앱이 제대로 동작하는 원격·하이브리드 직원의 더 원활한 사용자 경험 등입니다.
훌륭한 보안 제품이 자동으로 엔터프라이즈 표준이 되지는 않습니다. 현실적으로 ‘유통’은 벤더가 큰 조직 내부에 도달하고, 승리하며, 성공적으로 배포되는 경로 모음을 의미하며—종종 다른 회사를 통해 이루어집니다.
보안에서 유통은 보통 다음을 포함합니다:
이들은 선택적 추가 기능이 아니라 벤더를 예산, 의사결정자, 구현 역량에 연결하는 파이프입니다.
대기업은 신중하게 구매합니다. 파트너는 다음을 제공합니다:
플랫폼 채택은 종종 실무적 마이그레이션 작업—레거시 VPN 패턴에서 사용자 이동, 아이덴티티 통합, 정책 튜닝—에 달려 있습니다. 파트너는 그 변화를 관리 가능한 것으로 만들 수 있습니다.
클라우드 전달은 비즈니스를 일회성 설치에서 구독, 확장, 갱신으로 바꿉니다. 이는 유통을 변화시키는데: 파트너는 단순한 ‘거래 성사자’가 아니라 고객 성과에 맞춘 지속적 롤아웃 파트너가 될 수 있습니다—프로그램이 잘 설계되어 있다면요.
파트너 인센티브, 파트너 활성화의 품질(교육, 플레이북, 공동 영업 지원), 그리고 계약 후 고객 성공 핸드오프가 얼마나 깔끔한지 면밀히 살펴보세요. 많은 배포 실패는 제품 자체가 약해서가 아니라 벤더·파트너·고객 간 소유권이 불명확해져서 발생합니다.
보안 구매는 보통 “더 나은 보안이 필요하다”는 것으로 시작하지 않습니다. 네트워크 변화가 오래된 가정을 깰 때 시작됩니다: 더 많은 앱이 SaaS로 이동하거나, 지점이 SD-WAN으로 전환되거나, 원격근무가 영구화되는 경우 등입니다. 트래픽이 더 이상 중앙 사무실을 통하지 않으면 ‘본사에서 모든 것을 보호한다’는 모델은 느린 연결, 복잡한 예외, 맹점으로 바뀝니다.
Zscaler는 종종 SASE와 SSE 대화에 함께 언급됩니다. 이 라벨들은 보안이 어떻게 전달되는지의 변화를 설명합니다:
실제 ‘이점의 번역’은 약어가 아니라 운영 단순화입니다: 온프레 박스 감소, 정책 업데이트 용이성, 데이터센터를 통해 트래픽을 우회하지 않고도 앱에 직접 접근 가능.
기업은 일반적으로 SSE/SASE 스타일 접근을 평가할 때 다음 상황을 마주합니다:
이러한 트리거가 나타나면 범주는 자연스럽게 ‘도착’합니다—네트워크가 이미 변했기 때문입니다.
제로 트러스트 플랫폼을 구매하는 것은 보통 쉬운 부분입니다. 지저분한 네트워크, 유산 애플리케이션, 실제 사람들을 가로지르는 환경에서 작동하게 만드는 것이 프로젝트의 성쇠를 가릅니다.
반복되는 문제는 레거시 앱입니다. 오래된 시스템은 ‘네트워크 내부 = 신뢰’로 가정하거나 하드코딩된 IP 허용 목록에 의존하거나 트래픽을 검사하면 동작이 깨집니다.
다른 마찰 요인은 인간적 요소입니다: 변화 관리, 정책 재설계, ‘누가 무엇을 소유하는가’에 대한 논쟁. 광범위한 네트워크 접근에서 정밀한 앱 수준 규칙으로 이동하면 팀이 실제 업무 방식을 문서화하도록 강제하고, 이는 오래 방치된 간극을 드러낼 수 있습니다.
보안이 단독으로 운영하려 들지 않을 때 롤아웃이 더 원활합니다. 다음과 조정하세요:
낮은 위험 그룹(예: 한 부서 또는 계약직 하위집단)으로 시작하고 성공 지표를 사전에 정의하세요: VPN 티켓 감소, 애플리케이션 접근 속도 개선, 노출된 공격 표면 감소, 가시성 향상 등.
파일럿은 반복으로 운영하세요: 한 앱 카테고리씩 마이그레이션하고 정책을 튜닝한 뒤 확장합니다. 목표는 전체 회사를 실험장으로 만들지 않고 빠르게 배우는 것입니다.
첫날부터 로깅과 문제 해결 계획을 세우세요: 로그가 어디에 저장되는지, 누가 쿼리할 수 있는지, 보관 기간은 얼마인지, 알람이 사고 대응에 어떻게 연결되는지. 사용자가 “앱이 차단됐다”고 할 때 도움을 받을 수 없으면 신뢰는 빠르게 떨어집니다—보안 모델이 견고하더라도요.
많은 팀이 간과하는 가속 요인은 내부 도구입니다: 예외 요청 포털, 접근 검토, 앱 인벤토리, 롤아웃 추적, 보고서용 가벼운 포털 등. 팀들은 종종 공급자 로드맵을 기다리기보다 이런 ‘접착’ 앱을 직접 빠르게 만들어 사용합니다. Koder.ai 같은 플랫폼은 채팅 기반 워크플로로 React 프론트엔드와 Go/PostgreSQL 백엔드를 포함한 내부 웹 도구를 신속히 프로토타이핑하고 배포하는 데 도움이 될 수 있습니다—정책과 프로세스가 성숙해지면서 빠른 반복이 필요할 때 유용합니다.
보안 통제를 여러분이 소유한 어플라이언스에서 클라우드 전달 플랫폼으로 옮기면 운영은 단순해질 수 있지만, 동시에 무엇에 베팅하는지가 바뀝니다. 좋은 결정은 ‘제로 트러스트 대 레거시’의 문제가 아니라 새로운 실패 모드를 이해하는 것입니다.
하나의 플랫폼이 웹 보안, 프라이빗 앱 접근, 정책 집행, 로깅을 제공하면 도구 스프롤을 줄일 수 있지만 위험도 집중됩니다. 계약 분쟁, 가격정책 변경, 제품 격차는 여러 기능에 더 큰 충격을 줄 수 있습니다.
클라우드 보안은 사용자와 애플리케이션 사이에 추가 홉을 둡니다. 잘 작동할 때는 사용자가 거의 느끼지 못합니다. 한 지역에 장애, 라우팅 문제, 용량 문제가 생기면 ‘보안’이 ‘인터넷이 다운된 것처럼’ 보일 수 있습니다. 이는 어느 한 벤더의 문제라기보다 항상 연결성에 의존하는 것의 본질적 문제입니다.
제로 트러스트가 마법의 방패인 것은 아닙니다. 너무 관대하거나 너무 제한적이거나 그룹 간 일관성이 없는 잘못된 정책 범위는 노출을 증가시키거나 업무를 방해할 수 있습니다. 정책 엔진이 유연할수록 규율이 더 필요합니다.
단계적 롤아웃: 명확한 사용 사례(예: 특정 사용자 집단 또는 앱 카테고리)로 시작하고 지연 및 접근 결과를 측정한 뒤 확장하세요. 정책을 평이한 언어로 정의하고 모니터링·알림을 조기에 구현하며 중복성(다중 지역 라우팅, 비상 접근, 문서화된 대체 경로)을 계획하세요.
어떤 유형의 데이터를 보호하는지(규제 대상 대 일반) 파악하고, 컴플라이언스 요구사항에 맞춘 통제를 정렬하며, 정기적 접근 검토를 일정에 넣으세요. 목표는 공포 기반 구매가 아니라 새 모델이 안전하고 예측 가능하게 실패하도록 만드는 것입니다.
Zscaler의 반복 교훈은 집중입니다: 보안 집행을 클라우드로 옮기고 접근을 신원 기반으로 만들라. 벤더를 평가하거나 제품을 만들 때 간단한 질문을 던지세요: “다른 모든 것을 단순하게 만드는 한 가지 아키텍처적 베팅은 무엇인가?” 답이 “상황에 따라 다르다”라면 비용, 롤아웃 시간, 예외에서 복잡성이 드러날 것입니다.
‘제로 트러스트’는 암묵적 신뢰 가정 감소, 네트워크 배선 감소, 온프레에서 앱 이동 시 더 나은 통제라는 실용적 약속으로 작동했습니다. 팀에게 의미 있는 것은 결과를 사고 팔라는 것입니다, 버즈워드가 아니라. 원하는 결과(예: “인바운드 접근 없음”, “앱에 대한 최소 권한”, “원격 사용자에 대한 일관된 정책”)를 적고 각 항목을 테스트할 수 있는 구체적 기능에 매핑하세요.
엔터프라이즈 보안은 신뢰 네트워크를 통해 확산됩니다: 리셀러, GSI, MSP, 클라우드 마켓플레이스. 창업자는 초기에 파트너 친화적 제품을 구축하세요—명확한 패키징, 예측 가능한 마진, 배포 플레이북, 공유 메트릭. 보안 리더는 파트너를 변화를 위한 수단으로 활용하세요: 파트너를 통해 변화 관리, 아이덴티티 통합, 단계적 마이그레이션을 수행하면 모든 팀을 재교육하려는 시도를 대신할 수 있습니다.
한 개의 고유 사용 사례(종종 인터넷 접근 또는 하나의 중요한 앱)로 시작해 전후를 측정하고 확장하세요.
핵심 롤아웃 질문:
단순히 ‘보안’을 팔지 마세요—마이그레이션 경로를 팔아라. 승리하는 스토리는 보통 다음과 같습니다: 문제 → 가장 간단한 첫 단계 → 측정 가능한 성과 → 확장. 온보딩과 보고로 30–60일 내 가치를 보여줄 수 있도록 구축하세요.
창업자 친화적 패턴 중 하나는 핵심 제품을 보완하는 빠르게 제작 가능한 동반 앱(평가 워크플로, 마이그레이션 트래커, ROI 계산기, 파트너 포털)을 제공하는 것입니다. 전체 레거시 개발 파이프라인을 다시 구축하지 않고 이를 만들고 싶다면, Koder.ai는 채팅으로 전체 스택 앱을 ‘vibe-coding’ 방식으로 생성하도록 설계되어 있어 내부 또는 고객 대상 툴을 빠르게 프로덕션에 투입하고 유통 모션이 진화함에 따라 반복하기에 유용합니다.
더 깊이 파고들고 싶다면 /blog/zero-trust-basics 및 /blog/sase-vs-sse-overview를 참조하세요. 패키징 아이디어는 /pricing을 방문하세요.
제로 트러스트는 접근 결정이 요청별로 신원(identity), 장치 상태(device posture), 컨텍스트에 기반해 내려지는 접근 방식으로, ‘네트워크 내부라 안전하다’는 가정을 하지 않는다는 의미입니다. 실무적으로는:
전통적 VPN은 사용자를 ‘네트워크에 넣어’ 여러 시스템에 접근하게 하는 방식입니다. 앱 중심 접근은 모델을 뒤집습니다:
“인라인(inline)”은 트래픽이 인터넷이나 클라우드 애플리케이션에 도달하기 전에 보안 검사 지점을 통과한다는 뜻입니다. 클라우드 전달 모델에서는 이 검사 지점이 가까운 **PoP(포인트 오브 프레즌스)**에 위치해, 제공자는:
목표는 본사로 트래픽을 모두 돌려보내지 않고도 일관된 보안을 제공하는 것입니다.
백홀(backhauling)은 원격 사용자의 웹·SaaS 트래픽을 중앙 데이터센터로 보내 검사한 뒤 다시 인터넷으로 내보내는 방식입니다. 이 방식은 보통 다음과 같은 문제를 낳습니다:
보안 웹 게이트웨이(SWG)는 사용자가 인터넷을 탐색하고 SaaS 앱을 사용할 때 이들을 보호합니다. 일반적인 SWG 기능은:
대부분 트래픽이 인터넷으로 향하고 사용자가 단일 기업 방화벽 뒤에 있지 않을 때 특히 유용합니다.
클라우드 전달 보안은 운영을 단순화할 수 있지만 의존 구조를 바꿉니다. 주요 평가 항목은:
성공 확률이 높은 파일럿은 범위를 좁히고 측정 가능하게 설계합니다:
목표는 전체 회사를 테스트 환경으로 만들지 않고 빠르게 학습하는 것입니다.
구성 오류는 ‘네트워크 접근’에서 ‘앱/정책 접근’으로 전환할 때 팀이 의도를 정확히 정의해야 하기 때문에 흔합니다. 위험을 줄이려면:
SSE는 사용자 근처에서 클라우드로 제공되는 보안 통제(예: SWG, 프라이빗 앱 접근)를 말합니다. SASE는 여기에 네트워킹 측면(대개 SD-WAN)을 결합해 연결성과 보안을 함께 설계합니다.
구매 관점에서:
대기업은 종종 파트너를 통해 구매하고 구현 역량을 필요로 합니다. 채널 파트너, SI, MSP는:
강력한 파트너 생태계는 플랫폼이 표준이 될지 소규모 배치에서 멈출지를 좌우할 수 있습니다.