Jay Chaudhry 与 Zscaler：为云规模构建的零信任

这篇文章解释了什么（不仅仅是创始人侧写）

这不是 Jay Chaudhry 的传记。它是关于 Zscaler 如何帮助重塑企业安全的实用故事——以及为什么它的技术和商业选择很重要。

你会并行学到两件事：

• 一种安全模型： 当你的应用和用户分散在云服务、办公室和家庭时，“零信任”如何运作。\n- 一种商业模型： 安全公司如何被大企业接受——那些企业决策缓慢、通过合作伙伴采购并避免高风险迁移。

用通俗话解释“现代企业安全”

现代企业安全是一套控制措施，让员工可以安全使用互联网和内部应用，而不再假设“处于公司网络内部”的东西就一定安全。它不再是为数据中心建更大的围墙，而是每次都检查谁在连接、连接到什么以及是否应该允许该连接。

我们会反复回到的三大支柱

1. 云交付： 安全功能从本地设备迁移到能全球扩展的服务。\n2. 零信任： 访问基于身份、上下文和策略——而不是网络位置。\n3. 分销： 企业安全通过采购现实传播：渠道合作伙伴、既有厂商和可重复的部署路径。

你将带走的要点

到最后，你能一句话概括 Zscaler 的核心押注，识别零信任取代 VPN 思维的场景，并理解为什么分销策略可能和产品设计一样重要。

一页看懂 Jay Chaudhry：创始人的视角

Jay Chaudhry 是一位连续创业者，最广为人知的是作为 Zscaler 的创始人兼 CEO，推动企业安全从“保护公司网络”向“无论用户在哪里都保护用户和应用”转变。在创办 Zscaler 之前，他先后建立并出售了多家安全公司，这让他近距离看到攻击者行为和企业 IT 的快速变迁。

他选择解决的问题

Chaudhry 在 Zscaler 的关注点很直接：随着工作和应用从公司网络迁移（走向公共互联网和云服务），把所有流量导回中央数据中心进行检测的旧模型开始失效。

这种变化给 IT 团队带来了痛苦的权衡：

• 如果强制把所有流量回传总部，性能会下降，用户会绕过控制。\n- 如果让用户直接访问云应用，可见性和策略执行就会削弱。

Zscaler 的出发点是：安全需要跟随用户，而不是跟随建筑。

由创始人驱动的愿景如何塑造了一个品类

突出的是创始人对产品愿景的主导如何在早期影响公司战略：

• 云优先交付，而不是发布需要客户维护的设备。\n- 可扩展的策略执行，把检测放到更贴近用户连接的位置。\n- 清晰的架构观点：减少隐性信任、持续验证访问，并把互联网和云视为默认环境。

这不是市场宣传的改变；它推动了产品决策、合作伙伴关系，以及 Zscaler 向保守企业买家解释“为什么要这样做”。随着时间推移，这种清晰性帮助把“云交付安全”和“零信任”从理念转成预算项——大公司可以购买、部署并标准化它们。

为什么旧的周界模型开始失效

多年来，企业安全围绕一个简单想法构建：把“重要的东西”放在公司网络内部，并在外面筑一道墙。那道墙通常是一堆本地设备——防火墙、网页代理、入侵防护——部署在少数几个数据中心。远程员工通过 VPN 进入，相当于把内部网络扩展到他们所在之处。

旧有模型的实践情况

当多数应用都在公司数据中心时，这个模型还算可行。网页流量和应用流量通过相同的关卡，安全团队可以在此进行检测、记录和阻断。

但该模型依赖两个假设，而这两点开始不再成立：

• 用户主要在办公室、使用受管网络。\n- 应用主要在周界内部。

它为何崩解：漫游用户、SaaS 与开放网络

随着员工变得更为移动且 SaaS 采用加速，流量模式被颠覆。咖啡馆里的员工需要快速访问 Office 365、Salesforce 和几十个基于浏览器的工具，往往根本不经过公司数据中心。

为了继续执行策略，许多公司选择把流量“回传”：先把用户的互联网和 SaaS 请求导到总部检查，然后再发出去。结果是可预见的：性能缓慢、用户不满、以及对放宽控制的不断压力。

安全团队首先感受到的痛点

复杂性激增（更多设备、更多规则、更多例外）。VPN 在授予广泛网络访问时变得过载且存在风险。每个新分支或并购意味着又一次硬件部署、更多的容量规划和更脆弱的架构。

正是这种需要在不强制通过物理周界的情况下提供一致安全的差距，为可随用户和应用移动的云交付安全创造了机会。

云交付安全：核心押注

Zscaler 的决定性押注一句话说来简单，但执行困难：把安全作为云服务交付，部署靠近用户，而不是作为放在公司网络内的盒子。

在这里，“云安全”并不只是保护云服务器。它意味着安全本身运行在云端——所以分支、家庭或移动中的用户会连接到附近的安全接入点（PoP），在那儿执行策略。

什么是“在线”检测（不用行话解释）

“在线”就像在前往目的地的路上设置了一个安全检查站。

当员工访问网站或云应用时，他们的连接会被引导先经过该服务。服务根据策略进行可行检查，阻止风险目的地，扫描威胁，然后把允许的流量转发出去。目标是用户无需“在公司网络上”也能获得企业级保护——安全随用户而行。

为什么企业会被吸引

云交付安全改变了 IT 和安全团队的日常现实：

• 部署更简单： 每个地点需要维护的设备更少。\n- 更新更快： 保护可以集中更新，无需等待本地升级周期。\n- 策略更一致： 跨办公室、远程员工和多云环境使用同一套规则。

该模型也契合现在企业的工作方式：流量经常直接去往 SaaS 和公共互联网，而不是先回总部。

权衡（不炒作）

把第三方放在在线路径中会带来真实的担忧，需要评估：

• 信任与数据处理： 什么被检查、记录、解密（如果有）以及如何保留。\n- 可见性差异： 有些团队会怀念“设备级”的触感视图，即便仪表盘更好。\n- 服务依赖性： 故障或区域性性能问题会迅速成为业务问题。

因此核心押注不仅是技术问题——还是对云提供商能否可靠、透明且全球化地执行策略的运营信心押注。

给非技术读者解释零信任

零信任的简单原则是：不要因为某东西“在公司网络内部”就假定它安全。 相反，始终验证用户是谁、他们用的设备是什么，以及他们是否应该访问某个应用或数据——在关键时刻每次都这样做。

转变：从“网络访问”到“应用访问”

传统的 VPN 思维就像给某人一张通行证，一旦进门就能打开整栋楼。VPN 连接后，许多系统把该用户视为“内部”，这可能暴露过多内容。

零信任翻转了这种模型。更像是允许某人进入一个房间完成一项任务。你不会被广泛地“加入网络”；你只被允许访问你被批准的应用。

简单的日常示例

一位承包商需要访问某个项目管理工具两个月。采用零信任时，他可以只被允许进入该单个应用——不会意外获得访问工资或内部管理工具的路径。

一名员工在出差时使用自带设备（BYOD）。零信任策略可以要求更强的登录检查，或者在设备过旧、未加密或有被攻破迹象时阻止访问。

远程办公变得更容易保护，因为安全决策跟随用户与应用，而不是物理办公室网络。

零信任不等于什么

零信任不是一个买了就能“开”的单一产品。它是一种通过工具与策略实现的安全方法。

它也不是以敌对方式“谁都不信任”。实际操作中意味着信任需要持续获得，通过身份检查、设备状态和最小权限来实现——以便错误和入侵不会自动扩散。

Zscaler 方法的高层地图

把 Zscaler 看作一个位于人和他们想要访问的目标之间的云端“控制点”最容易理解。它不再相信公司网络边界，而是基于用户是谁和环境如何评估每次连接，然后应用相应策略。

核心构建块

大多数部署可用四个简单部分描述：

• 用户： 员工、承包商、合作伙伴——任何登录的身份。\n- 应用与目的地： 公开互联网站点（SaaS、网页）和私有应用（内部系统）。\n- 策略： 类似“财务可以访问工资系统”、“阻止风险文件上传”或“离线时要求更严格检查”的规则。\n- 云端执行： 云安全服务在靠近用户连接处执行这些策略，而不是把流量回传到单一数据中心。

两条通道：互联网安全与私有应用访问

概念上，Zscaler 把流量分为两条路：

• 互联网/SaaS 安全（安全网页网关）： 保护浏览与云应用使用——过滤、检测并控制进出用户会话的内容。\n- 私有应用访问： 在不让用户像传统 VPN 那样“在网络上”的情况下，提供对内部应用的特定连接。

这种区分很重要：一条是关于安全上网，另一条是关于精确访问内部系统。

“身份 + 上下文”去掉行话

决策不再基于可信的办公 IP 地址，而是基于信号，例如用户是谁、设备健康状况（受管 vs 非受管，已打补丁 vs 过期）以及如何/从何处连接。

这些会带来什么结果

做得好的话，这种方法能减少暴露的攻击面，限制如果出现问题时的横向移动，并把访问控制变成更简单、一致的策略模型——尤其是在远程工作和云优先应用栈成为默认时。

安全网页网关：互联网一侧的故事

提到“企业安全”，人们往往会想到私有应用和内部网络。但大量风险来自开放的互联网一侧：员工浏览新闻站点、点击邮件链接、使用基于浏览器的工具或把文件上传到网页应用。

安全网页网关（SWG）就是为使日常上网更安全而建立的品类——而且不强制把每个用户的流量都回环到中央办公地点。

SWG 解决了什么问题

最简单的说，SWG 是用户与公共网络之间的一个受控检查点。它不会被动信任设备可达的目的地，而是应用策略和检测，帮助组织减少访问恶意站点、危险下载和意外数据泄露的风险。

典型保护包括：

• URL 过滤： 按类别、信誉或策略允许/拒绝访问\n- 恶意软件拦截： 阻止已知恶意文件、可疑脚本和钓鱼目的地\n- 数据控制： 检测并阻止向未批准地点上传敏感数据

随着 SaaS 和移动用户增长，云 SWG 为什么加速

当工作从固定办公室迁移到 SaaS、浏览器和移动设备时，格局发生了变化。如果用户和应用无处不在，把流量回传到单一公司周界会增加延迟并产生盲点。

云交付的 SWG 与新现实相匹配：策略随用户而动，流量能在更靠近连接处被检查，安全团队在总部、分支和远程办公之间获得一致控制——无需把互联网当作例外来处理。

用面向应用的访问替代 VPN 思维

VPN 的设计理念基于“在网络上”就能访问应用的时代。当应用散布在多个云、SaaS 和少数本地系统时，这种思维就行不通了。

在不暴露网络的情况下访问私有应用

面向应用的访问翻转默认行为。用户不会被放到内部网络（然后希望分段策略生效）；用户只与特定应用建立连接。

概念上，它像一个代理连接：用户证明自己是谁以及允许访问的内容，然后为该应用创建一条受控的短路径——无需把内部 IP 范围发布到互联网，也不会给用户广泛的“内部”可见性。

为什么从业务角度看应用分段优于网络分段（大多数情况下）

网络分段很强大，但在真实组织里也易碎：并购、平坦 VLAN、遗留应用和例外会不断累积。应用分段更容易理解，因为它映射到业务意图：

• 财务人员可以访问财务应用。\n- 承包商可以访问单一项目工具。\n- 管理员能访问特权控制台——但需更严格检查。

这样就减少了隐性信任，并让访问策略更易读：你可以按应用和用户组审计它们，而不是追踪路由和子网。

常见的采用路径

多数团队不会一夜之间替换 VPN。实用的部署通常是：

1. 先从一个导致 VPN 痛点的内部应用入手（帮助台、开发门户、HR 工具）。\n2. 扩展到一个部门，然后对下一组应用重复。\n3. 在过渡期间保留 VPN 作为回退，逐步缩减其使用。

可以衡量的业务成果

当面向应用的访问做好后，收益会迅速显现：VPN 相关支持工单减少、访问规则更清晰且安全/IT 更能解释、用户体验更顺畅——特别是对只想直接使用应用而不想“先连接网络”的远程或混合办公人员来说。

分销：企业安全如何真正规模化

优秀的安全产品并不会自动成为企业标准。实际上，企业安全的“分销”是厂商触达、赢得并成功在大组织内部署的一套路径——通常要通过其他公司来完成。

“分销”实际上包含什么

在安全领域，分销通常涵盖：

• 渠道合作伙伴与经销商，他们介绍产品、与其他工具打包并帮助走采购流程。\n- 系统集成商（SI）与托管服务商（MSP），他们设计部署、连接身份与网络，并运行后续运维。\n- 技术联盟（身份提供商、端点厂商、云平台），这些使部署更顺畅并增强买家信心。

这些不是可选项，而是将厂商与预算、决策者和实现能力连接起来的管道。

渠道为何比人们预期的更重要

大企业购买时谨慎。合作伙伴提供：

• 信任与验证（“我们以前做过这个”）\n- 实施帮助，当内部团队人手不足时\n- 采购触达，通过审批供应商名单和既有合同\n- 地理与行业覆盖，无需在每个地方建立庞大的直销团队

对像 Zscaler 这样的平台而言，采用往往依赖于真实的迁移工作——把用户从遗留 VPN 模式迁移、集成身份并调优策略。合作伙伴能让这种变迁变得可管理。

云交付如何改变销售节奏

云交付把业务从一次性安装转向订阅、扩展与续约。这改变了分销：合作伙伴不再只是“成单方”。他们可以成为持续的部署伙伴，如果计划设计得当，他们的激励就与客户成果对齐。

评估供应商时要注意的点

密切关注合作伙伴激励、合作伙伴使能质量（培训、落地手册、联合销售支持），以及合同签署后客户成功交接的顺畅程度。许多部署失败并非因为产品弱，而是因为厂商、合作伙伴与客户之间的职责不清。

类别时机：云、远程办公与 SASE/SSE

安全采购很少从“我们需要更好安全”开始。它通常源于网络变化打破了旧假设：更多应用迁移到 SaaS、分支采用 SD-WAN、或远程办公成为常态。当流量不再经过中央办公室时，“在总部保护一切”的模型就会变成慢连接、混乱的例外和盲点。

为什么时机很关键

Zscaler 常被与 SASE 和 SSE 一并提及，因为这些术语描述了安全交付方式的转变：

• SSE（Security Service Edge）：通俗地说是从云端交付的安全控制，让用户无论身在何处都获得一致保护。\n- SASE（Secure Access Service Edge）：相同理念，加上网络部分（通常是 SD-WAN），把连接性和安全一起规划。

真正的“收益翻译”不是缩写本身，而是更简单的运维：更少的本地设备、更易的策略更新，以及无需把流量回传到数据中心就能更直接地访问应用。

实用清单：团队评估这些解决方案时的触发点

公司通常在以下情形评估 SSE/SASE 风格方案：

• 云迁移显著增加了面向互联网和 SaaS 的流量\n- SD-WAN 部署改变了分支路由并暴露出现有控制的缺口\n- VPN 容量与用户体验成为长期问题（尤其是承包商）\n- 各办公室因工具按站点部署而导致策略不一致\n- 团队需要更快为新地点、并购或远程用户上手\n- 审计需要更清晰的可见性：谁从哪里访问了哪个应用

当这些触发点出现时，类别就自然“到位”了——因为网络已经先发生了变化。

落地现实：哪些因素决定部署成败

购买零信任平台通常是容易的部分。让它在错综复杂的网络、遗留应用和真实用户中运作才是项目成功或停滞的关键。

最常见的采纳障碍

遗留应用是常见的拦路虎。旧系统可能假定“在网络内部=可信”，依赖硬编码的 IP 白名单，或在流量被检测时故障。

其他摩擦点是人为的：变更管理、策略重设计以及“谁负责什么”的争论。从广域网络访问转向精确的应用级规则，迫使团队记录实际工作方式，这会暴露长期被忽视的差距。

需要早期参与的利益相关者

当安全不单干时，部署会更顺利。预计需要协调的角色包括：

• 安全与网络团队（流量引导、分段决定）\n- IT/服务台（设备状态、入职与用户支持）\n- 合规/风险（日志、数据处理、审计期望）\n- 业务应用负责人（哪些是关键、哪些可以容错、哪些将很快变动）

降低风险的试点策略

从低风险群体入手（例如某个单部门或部分承包商），并事先定义成功指标：更少 VPN 工单、更快的应用访问、可测量的暴露面减少或可见性改进。

分阶段运行试点：按应用类别迁移、调优策略再扩展。目标是快速学习，而不是把整个公司当成测试环境。

运维现实：Day-2 工作

从第一天就规划日志和故障排查：日志存放在哪里、谁能查询、保留多久、警报如何接入事件响应。如果当“应用被阻止”时用户无法得到帮助，即便安全模型没问题，信心也会迅速下降。

一个常被忽视且能加速落地的做法是内部工具：用于异常请求、访问审查、应用清单、部署跟踪与报告的简易门户。团队越来越倾向于自己构建这些轻量“胶水应用”，而不是等厂商路线图。像 Koder.ai 这样的平台可以通过聊天驱动的工作流，帮助团队快速原型并发布内部 Web 工具——在你需要一个 React 前端配合 Go/PostgreSQL 后端，并随着策略和流程成熟快速迭代时尤其有用。

风险与权衡（不炒作）

把安全控制从自有设备迁到云端平台能简化运维，但也改变了你的赌注。一个明智的决定不是“零信任对遗留”，而是理解新的失效模式。

集中风险（一个厂商，多个功能）

如果一个平台提供网页安全、私有应用访问、策略执行和日志，你减少了工具碎片化，但也集中化了风险。合同争议、定价变动或产品缺口的影响面会更大。

性能与可用性依赖性

云安全在用户与应用之间增加了一个跳点。当运行良好时，用户几乎感觉不到；当某个区域发生故障、路由问题或容量问题时，“安全”可能看起来像“网络宕机”。这不是针对某家厂商，而是依赖持续连通性的普遍问题。

错误配置仍然是头号风险

零信任不是万能盾。策略范围定义不当（过宽、过严或在组间不一致）会增加暴露或中断业务。策略引擎越灵活，就越需要纪律性。

买家如何降低这些风险

分阶段推广有用：从明确用例（例如某类用户或应用）开始，度量延迟和访问效果再扩展。用明白的话定义策略，早期实现监控告警，并规划冗余（多区域路由、断电应急访问和记录化回退路径）。

真正重要的治理

明确你要保护的数据类型（受监管 vs 非受监管），把控制对齐到合规需求，并安排定期的访问审查。目标不是基于恐惧采购，而是确保新模型在失败时是可控且可预测的。

要点总结：团队与创始人可以借鉴的做法

1) 清晰的产品论比长功能清单更重要

Zscaler 的反复经验是聚焦：把策略执行移到云端并使访问以身份为驱动。评估厂商（或构建产品）时，问一个简单问题：“哪个架构押注能让其他一切更简单？”如果回答是“视情况而定”，那么以后在成本、部署时间和例外上会看到复杂性。

2) 明确品类定位是增长策略

“零信任”之所以奏效，是因为它把承诺翻译为可量化的收益：减少隐性信任、减少网络布线工作并在应用上云后获得更好控制。对于团队，这意味着购买结果而不是口号。写下你想要的结果（例如“无入站访问”“应用最小权限”“远程用户一致策略”）并把每项映射到可测试的具体能力。

3) 渠道比直销更快地规模化企业安全

企业安全通过信任网络传播：经销商、GSI、MSP 和云市场。创始人可以借鉴：尽早打造面向合作伙伴的产品——清晰的打包、可预测的利润、部署手册和共享指标。安全负责人也应利用合作伙伴：将其用于变更管理、身份集成和分阶段迁移，而不是试图让每个内部团队都快速提升技能。

4) 给考虑云/零信任的安全负责人实用建议

从一个高流量用例开始（通常是互联网访问或一个关键应用），衡量前后效果并扩展。

关键部署问题：

• 身份的“事实来源”是什么（以及组成员关系）？\n- 如何处理遗留应用、承包商和 BYOD？\n- 策略归属是谁：安全、网络还是共享？

5) 给创始人的分销与品类打造建议

别只是“卖安全”——要卖迁移路径。成功的故事通常是：痛点 → 最简单的第一步 → 可量化的胜利 → 扩展。构建能在 30–60 天内让价值可见的入职与报告流程。

一种创始人友好的做法是把核心产品补充以易于构建的配套应用（评估工作流、迁移追踪、ROI 计算器、合作伙伴门户）。如果你想在不重建完整遗留开发流水线的前提下实现这些，Koder.ai 适合通过聊天生成全栈应用——有助于快速将内部或面向客户的工具推向生产，并随着你的分销动作演进迭代。

如需深入，请参见 /blog/zero-trust-basics 和 /blog/sase-vs-sse-overview。有关包装思路，请访问 /pricing。