2025年10月20日·1 分钟
Jay Chaudhry 与 Zscaler：为云规模构建的零信任
从实践角度看 Jay Chaudhry 和 Zscaler 如何通过云安全、零信任和合作伙伴分销，构建领先的企业安全公司。
从实践角度看 Jay Chaudhry 和 Zscaler 如何通过云安全、零信任和合作伙伴分销，构建领先的企业安全公司。
这不是 Jay Chaudhry 的传记。它是关于 Zscaler 如何帮助重塑企业安全的实用故事——以及为什么它的技术和商业选择很重要。
你会并行学到两件事：
现代企业安全是一套控制措施，让员工可以安全使用互联网和内部应用，而不再假设“处于公司网络内部”的东西就一定安全。它不再是为数据中心建更大的围墙，而是每次都检查谁在连接、连接到什么以及是否应该允许该连接。
到最后，你能一句话概括 Zscaler 的核心押注，识别零信任取代 VPN 思维的场景，并理解为什么分销策略可能和产品设计一样重要。
Jay Chaudhry 是一位连续创业者，最广为人知的是作为 Zscaler 的创始人兼 CEO，推动企业安全从“保护公司网络”向“无论用户在哪里都保护用户和应用”转变。在创办 Zscaler 之前，他先后建立并出售了多家安全公司，这让他近距离看到攻击者行为和企业 IT 的快速变迁。
Chaudhry 在 Zscaler 的关注点很直接：随着工作和应用从公司网络迁移（走向公共互联网和云服务），把所有流量导回中央数据中心进行检测的旧模型开始失效。
这种变化给 IT 团队带来了痛苦的权衡：
Zscaler 的出发点是：安全需要跟随用户，而不是跟随建筑。
突出的是创始人对产品愿景的主导如何在早期影响公司战略：
这不是市场宣传的改变；它推动了产品决策、合作伙伴关系，以及 Zscaler 向保守企业买家解释“为什么要这样做”。随着时间推移，这种清晰性帮助把“云交付安全”和“零信任”从理念转成预算项——大公司可以购买、部署并标准化它们。
多年来，企业安全围绕一个简单想法构建：把“重要的东西”放在公司网络内部，并在外面筑一道墙。那道墙通常是一堆本地设备——防火墙、网页代理、入侵防护——部署在少数几个数据中心。远程员工通过 VPN 进入，相当于把内部网络扩展到他们所在之处。
当多数应用都在公司数据中心时，这个模型还算可行。网页流量和应用流量通过相同的关卡，安全团队可以在此进行检测、记录和阻断。
但该模型依赖两个假设，而这两点开始不再成立：
随着员工变得更为移动且 SaaS 采用加速，流量模式被颠覆。咖啡馆里的员工需要快速访问 Office 365、Salesforce 和几十个基于浏览器的工具，往往根本不经过公司数据中心。
为了继续执行策略，许多公司选择把流量“回传”：先把用户的互联网和 SaaS 请求导到总部检查，然后再发出去。结果是可预见的：性能缓慢、用户不满、以及对放宽控制的不断压力。
复杂性激增（更多设备、更多规则、更多例外）。VPN 在授予广泛网络访问时变得过载且存在风险。每个新分支或并购意味着又一次硬件部署、更多的容量规划和更脆弱的架构。
正是这种需要在不强制通过物理周界的情况下提供一致安全的差距，为可随用户和应用移动的云交付安全创造了机会。
Zscaler 的决定性押注一句话说来简单，但执行困难：把安全作为云服务交付，部署靠近用户，而不是作为放在公司网络内的盒子。
在这里，“云安全”并不只是保护云服务器。它意味着安全本身运行在云端——所以分支、家庭或移动中的用户会连接到附近的安全接入点（PoP），在那儿执行策略。
“在线”就像在前往目的地的路上设置了一个安全检查站。
当员工访问网站或云应用时，他们的连接会被引导先经过该服务。服务根据策略进行可行检查，阻止风险目的地，扫描威胁，然后把允许的流量转发出去。目标是用户无需“在公司网络上”也能获得企业级保护——安全随用户而行。
云交付安全改变了 IT 和安全团队的日常现实：
该模型也契合现在企业的工作方式：流量经常直接去往 SaaS 和公共互联网，而不是先回总部。
把第三方放在在线路径中会带来真实的担忧，需要评估：
因此核心押注不仅是技术问题——还是对云提供商能否可靠、透明且全球化地执行策略的运营信心押注。
零信任的简单原则是：不要因为某东西“在公司网络内部”就假定它安全。 相反，始终验证用户是谁、他们用的设备是什么，以及他们是否应该访问某个应用或数据——在关键时刻每次都这样做。
传统的 VPN 思维就像给某人一张通行证，一旦进门就能打开整栋楼。VPN 连接后，许多系统把该用户视为“内部”，这可能暴露过多内容。
零信任翻转了这种模型。更像是允许某人进入一个房间完成一项任务。你不会被广泛地“加入网络”；你只被允许访问你被批准的应用。
一位承包商需要访问某个项目管理工具两个月。采用零信任时，他可以只被允许进入该单个应用——不会意外获得访问工资或内部管理工具的路径。
一名员工在出差时使用自带设备（BYOD）。零信任策略可以要求更强的登录检查，或者在设备过旧、未加密或有被攻破迹象时阻止访问。
远程办公变得更容易保护，因为安全决策跟随用户与应用，而不是物理办公室网络。
零信任不是一个买了就能“开”的单一产品。它是一种通过工具与策略实现的安全方法。
它也不是以敌对方式“谁都不信任”。实际操作中意味着信任需要持续获得，通过身份检查、设备状态和最小权限来实现——以便错误和入侵不会自动扩散。
把 Zscaler 看作一个位于人和他们想要访问的目标之间的云端“控制点”最容易理解。它不再相信公司网络边界，而是基于用户是谁和环境如何评估每次连接，然后应用相应策略。
大多数部署可用四个简单部分描述：
概念上，Zscaler 把流量分为两条路：
这种区分很重要：一条是关于安全上网，另一条是关于精确访问内部系统。
决策不再基于可信的办公 IP 地址，而是基于信号，例如用户是谁、设备健康状况（受管 vs 非受管，已打补丁 vs 过期）以及如何/从何处连接。
做得好的话，这种方法能减少暴露的攻击面，限制如果出现问题时的横向移动，并把访问控制变成更简单、一致的策略模型——尤其是在远程工作和云优先应用栈成为默认时。
提到“企业安全”，人们往往会想到私有应用和内部网络。但大量风险来自开放的互联网一侧：员工浏览新闻站点、点击邮件链接、使用基于浏览器的工具或把文件上传到网页应用。
安全网页网关（SWG）就是为使日常上网更安全而建立的品类——而且不强制把每个用户的流量都回环到中央办公地点。
最简单的说，SWG 是用户与公共网络之间的一个受控检查点。它不会被动信任设备可达的目的地，而是应用策略和检测，帮助组织减少访问恶意站点、危险下载和意外数据泄露的风险。
典型保护包括：
当工作从固定办公室迁移到 SaaS、浏览器和移动设备时，格局发生了变化。如果用户和应用无处不在，把流量回传到单一公司周界会增加延迟并产生盲点。
云交付的 SWG 与新现实相匹配：策略随用户而动，流量能在更靠近连接处被检查，安全团队在总部、分支和远程办公之间获得一致控制——无需把互联网当作例外来处理。
VPN 的设计理念基于“在网络上”就能访问应用的时代。当应用散布在多个云、SaaS 和少数本地系统时，这种思维就行不通了。
面向应用的访问翻转默认行为。用户不会被放到内部网络（然后希望分段策略生效）；用户只与特定应用建立连接。
概念上，它像一个代理连接：用户证明自己是谁以及允许访问的内容，然后为该应用创建一条受控的短路径——无需把内部 IP 范围发布到互联网，也不会给用户广泛的“内部”可见性。
网络分段很强大，但在真实组织里也易碎：并购、平坦 VLAN、遗留应用和例外会不断累积。应用分段更容易理解，因为它映射到业务意图：
这样就减少了隐性信任，并让访问策略更易读：你可以按应用和用户组审计它们，而不是追踪路由和子网。
多数团队不会一夜之间替换 VPN。实用的部署通常是：
当面向应用的访问做好后，收益会迅速显现：VPN 相关支持工单减少、访问规则更清晰且安全/IT 更能解释、用户体验更顺畅——特别是对只想直接使用应用而不想“先连接网络”的远程或混合办公人员来说。
优秀的安全产品并不会自动成为企业标准。实际上，企业安全的“分销”是厂商触达、赢得并成功在大组织内部署的一套路径——通常要通过其他公司来完成。
在安全领域，分销通常涵盖：
这些不是可选项，而是将厂商与预算、决策者和实现能力连接起来的管道。
大企业购买时谨慎。合作伙伴提供：
对像 Zscaler 这样的平台而言，采用往往依赖于真实的迁移工作——把用户从遗留 VPN 模式迁移、集成身份并调优策略。合作伙伴能让这种变迁变得可管理。
云交付把业务从一次性安装转向订阅、扩展与续约。这改变了分销：合作伙伴不再只是“成单方”。他们可以成为持续的部署伙伴，如果计划设计得当，他们的激励就与客户成果对齐。
密切关注合作伙伴激励、合作伙伴使能质量（培训、落地手册、联合销售支持），以及合同签署后客户成功交接的顺畅程度。许多部署失败并非因为产品弱，而是因为厂商、合作伙伴与客户之间的职责不清。
安全采购很少从“我们需要更好安全”开始。它通常源于网络变化打破了旧假设：更多应用迁移到 SaaS、分支采用 SD-WAN、或远程办公成为常态。当流量不再经过中央办公室时，“在总部保护一切”的模型就会变成慢连接、混乱的例外和盲点。
Zscaler 常被与 SASE 和 SSE 一并提及，因为这些术语描述了安全交付方式的转变：
真正的“收益翻译”不是缩写本身，而是更简单的运维：更少的本地设备、更易的策略更新，以及无需把流量回传到数据中心就能更直接地访问应用。
公司通常在以下情形评估 SSE/SASE 风格方案：
当这些触发点出现时，类别就自然“到位”了——因为网络已经先发生了变化。
购买零信任平台通常是容易的部分。让它在错综复杂的网络、遗留应用和真实用户中运作才是项目成功或停滞的关键。
遗留应用是常见的拦路虎。旧系统可能假定“在网络内部=可信”，依赖硬编码的 IP 白名单，或在流量被检测时故障。
其他摩擦点是人为的：变更管理、策略重设计以及“谁负责什么”的争论。从广域网络访问转向精确的应用级规则，迫使团队记录实际工作方式，这会暴露长期被忽视的差距。
当安全不单干时，部署会更顺利。预计需要协调的角色包括：
从低风险群体入手（例如某个单部门或部分承包商），并事先定义成功指标：更少 VPN 工单、更快的应用访问、可测量的暴露面减少或可见性改进。
分阶段运行试点：按应用类别迁移、调优策略再扩展。目标是快速学习，而不是把整个公司当成测试环境。
从第一天就规划日志和故障排查：日志存放在哪里、谁能查询、保留多久、警报如何接入事件响应。如果当“应用被阻止”时用户无法得到帮助，即便安全模型没问题，信心也会迅速下降。
一个常被忽视且能加速落地的做法是内部工具：用于异常请求、访问审查、应用清单、部署跟踪与报告的简易门户。团队越来越倾向于自己构建这些轻量“胶水应用”，而不是等厂商路线图。像 Koder.ai 这样的平台可以通过聊天驱动的工作流，帮助团队快速原型并发布内部 Web 工具——在你需要一个 React 前端配合 Go/PostgreSQL 后端，并随着策略和流程成熟快速迭代时尤其有用。
把安全控制从自有设备迁到云端平台能简化运维，但也改变了你的赌注。一个明智的决定不是“零信任对遗留”，而是理解新的失效模式。
如果一个平台提供网页安全、私有应用访问、策略执行和日志，你减少了工具碎片化，但也集中化了风险。合同争议、定价变动或产品缺口的影响面会更大。
云安全在用户与应用之间增加了一个跳点。当运行良好时，用户几乎感觉不到；当某个区域发生故障、路由问题或容量问题时，“安全”可能看起来像“网络宕机”。这不是针对某家厂商，而是依赖持续连通性的普遍问题。
零信任不是万能盾。策略范围定义不当（过宽、过严或在组间不一致）会增加暴露或中断业务。策略引擎越灵活，就越需要纪律性。
分阶段推广有用：从明确用例（例如某类用户或应用）开始，度量延迟和访问效果再扩展。用明白的话定义策略，早期实现监控告警，并规划冗余（多区域路由、断电应急访问和记录化回退路径）。
明确你要保护的数据类型（受监管 vs 非受监管），把控制对齐到合规需求，并安排定期的访问审查。目标不是基于恐惧采购，而是确保新模型在失败时是可控且可预测的。
Zscaler 的反复经验是聚焦：把策略执行移到云端并使访问以身份为驱动。评估厂商（或构建产品）时，问一个简单问题：“哪个架构押注能让其他一切更简单？”如果回答是“视情况而定”，那么以后在成本、部署时间和例外上会看到复杂性。
“零信任”之所以奏效，是因为它把承诺翻译为可量化的收益：减少隐性信任、减少网络布线工作并在应用上云后获得更好控制。对于团队，这意味着购买结果而不是口号。写下你想要的结果（例如“无入站访问”“应用最小权限”“远程用户一致策略”）并把每项映射到可测试的具体能力。
企业安全通过信任网络传播：经销商、GSI、MSP 和云市场。创始人可以借鉴：尽早打造面向合作伙伴的产品——清晰的打包、可预测的利润、部署手册和共享指标。安全负责人也应利用合作伙伴：将其用于变更管理、身份集成和分阶段迁移，而不是试图让每个内部团队都快速提升技能。
从一个高流量用例开始（通常是互联网访问或一个关键应用），衡量前后效果并扩展。
关键部署问题：
别只是“卖安全”——要卖迁移路径。成功的故事通常是：痛点 → 最简单的第一步 → 可量化的胜利 → 扩展。构建能在 30–60 天内让价值可见的入职与报告流程。
一种创始人友好的做法是把核心产品补充以易于构建的配套应用（评估工作流、迁移追踪、ROI 计算器、合作伙伴门户）。如果你想在不重建完整遗留开发流水线的前提下实现这些，Koder.ai 适合通过聊天生成全栈应用——有助于快速将内部或面向客户的工具推向生产，并随着你的分销动作演进迭代。
如需深入，请参见 /blog/zero-trust-basics 和 /blog/sase-vs-sse-overview。有关包装思路，请访问 /pricing。
零信任是一种方法论：访问决策基于身份、设备状态和上下文逐次判断，而不是因为“在内部网络就安全”而放松。
在实践中，这意味着：
传统 VPN 通常把用户“放到网络里”，这可能无意中暴露更多系统。面向应用的访问则反过来：
“Inline”（在线检测）意味着流量在到达互联网或云应用之前，先通过一个安全检查点。在云交付模式下，该检查点位于附近的PoP（接入点），提供能力包括：
目标是实现一致的安全性，而无需把流量都回传到总部进行检查。
把远程用户的网页和 SaaS 流量回传到中央数据中心进行检查，然后再发回互联网，通常会失败，因为它：
安全网页网关（SWG）保护用户在浏览互联网和使用 SaaS 时的活动。常见的 SWG 能力包括：
当大部分流量指向互联网且用户不再统一处于公司防火墙后，SWG 尤其重要。
云端交付的安全能简化运维，但也改变了你所依赖的内容。需要评估的关键权衡包括：
一个低风险的试点通常在范围明确且可衡量时更容易成功：
目标是在不把整个公司变成试验场的情况下快速学习。
错误配置之所以仍是头号风险，是因为从“网络访问”迁向“应用/策略访问”要求团队精确定义意图。为降低风险：
SSE 是指从云端在“边缘”交付的安全控制（比如 SWG 和私有应用访问），让用户无论身在何处都能得到一致保护。SASE 则把这个安全模型与网络能力（通常是 SD-WAN）结合起来，将连接性与安全一并设计。
在采购角度：
大企业通常通过合作伙伴购买并需要落地实施能力。渠道合作伙伴、SI 和 MSP 的作用包括：
强大的合作生态常常决定一个平台是成为标准还是在小规模部署后停滞。