以下为正文内容：

考虑到上述经验具备可复制的特点，项目组对办公网7层零信任落地过程进行了完整的总结。本文会按照项目背景、产品设计、系统架构设计、运营和灰度方案、常见问题处置手册几个章节，详细讲解落地方案。如有疑问，请在百度安全公众号下留言咨询。

1. 解决办公安全问题

     （1）提供SaaS化的零信任网关服务

     （2）提供身份服务和账号风控能力

     （3）提供私有化部署完整解决方案(准入、零信任网关、桌管等能力)

经过调研，我们发现零信任架构可以提供如下安全能力：

     （1）加密访问: 提供透明的加密访问能力

     （2）认证鉴权: 提供透明的SSO认证能力，以及域名级别访问控制能力

     （3）操作审计: 谁在什么时间点请求了哪个内网服务

     （4）安全防护: 提供WAF能力、用户异常访问动作序列等风控能力

因此，结合风险现状和零信任的安全价值，我们认为目前最好的方案就是建设办公网零信任网关，收敛绝大多数访问入口，并根治这个安全风险。

1. 业务功能: 提供便捷的、稳定的使用体验，允许在公网使用零信任系统

2. 稳定性: 办公类业务系统全部发布到零信任网关，能够支撑全员同时在线办公，全年无重大线上事故

3. 安全能力: 已接入的业务系统完成加固，包括HTTPS、最小化访问权限、WAF防护、风控能力等等

     1. Windows可基于Windivert、WFP或者tap实现

     2. Mac可以基于utun或者网络扩展实现

     1. 用户体验问题，通过短连接方式+CDN节点，解决小运营商、弱网环境等访问体验差的问题

     1. 业务低成本实现SSO认证、加密访问、认证鉴权等安全能力

     2. 统一访问入口、收敛生产网端口开放策略，通过减少生产网攻击面来提升内网的健壮度

3. 最后是业务沟通接入方面。百度存在大量无人维护的历史业务，经常会有找不到负责人的情况；对于内部重要的业务，需要做好实际风险控制，并与业务方建立信任感。

     a. 支持多机房保活。设计异地灾备、自动降级和熔断措施等能力

     b.不依赖任何外部服务。要假设服务(MySQL、redis、SSO等等)都会出现故障，比如访问超时、服务挂掉、数据全部丢失，需要设计完善的兜底措施。

     c. 有完善的应急预案（包括用户侧、业务系统、依赖服务三个部分）。针对各类故障有设计完善的SOP，对每一个动作都要有完成时间预估，确保风险可控；每季度模拟故障演练，确保人员操作熟练、流程成熟运行（核心人员要保持稳定）

     a. 就近访问保证体验。基于用户网络接入方式和地域，自动选择接入节点

     1. 网络层。百度采用内部的LB进行流量分发，需要提前与负责的同学沟通业务流量情况。

     2. 操作系统层。在内存充足的情况下，需要调大文件描述符上限、连接数上限(net.core.somaxconn)、缓冲区大小(tcp_rmem/tcp_wmem)等等，可根据压力测试结果进行调整。

     1. 测试目标: 挑选典型场景的沙盒环境进行，定位当前硬件配置下网关的抗压能力和瓶颈点，并根据实际情况进行优化。

     2. 测试方法: 既要进行全链路压力测试，也要针对单个组件进行测试。

      1. 不影响IDC内部访问，最小化对业务的影响

      2. 出现问题可以快速回滚DNS配置，DNS TTL设置为60秒，加上终端的缓存3-5分钟能可以生效

      3. 除兼容性问题以外，业务可以免改造接入

      4. 可以按照办公区就近接入不同的网关，提升访问体验

      1. 实现基于view + match-clients划分区域，让不同的源IP返回不同的解析结果

      2. 使用Response Policy Zone方案实现单个域名劫持

      1. HTTPS证书有效性。项目组把百度内部域名合并到了一张证书，并设置了到期前自动提醒。不过域名越多，证书就会越大，请求时带宽损耗比例也会相应增大，因此可根据项目实际情况进行调整。

      2. 云上资源的续费和释放保护。项目组使用了独立的百度云账户，并对重要的系统资源设置了释放保护，避免日常运维时误操作。

     1. 办公基础设施: 邀请核心用户参与灰度测试，之后跟业务沟通接入

     2. 部门级别业务系统: 按照体系推进

      1. 由于DNS服务器在内网，所以需要同时下发一个内网DNS和一个公网DNS，且顺序需要是内网DNS在前，否则用户在脱离内网环境后可能会无法办公

      1. 影响面控制。在流量低峰期接入，降低影响面；但是也不能太晚，太晚了可能找不到业务值班人

      2. 快速响应。出现问题第一时间跟进排查

      3. 值班信息公示。不是所有的问题都可以通过监控主动发现，业务侧、用户侧需要有联系到项目组的途径

百度目前还在零信任落地的第一阶段，未来我们还会继续发布后续阶段的落地经验，请大家留意【百度安全】公众号后续的文章。如有疑问，欢迎大家在公众号咨询，如在北京可约现场交流。

零信任架构实战系列：干掉密码，无密码化方案落地

零信任架构实战系列：如何选择零信任架构

零信任实战系列：远程办公实战（视频）

零信任架构远程办公实战

阅读原文

跳转微信打开

创业了，其实应该有不少朋友通过各种渠道知道了我要出来创业的事情，也有人好奇在做什么，为什么创业，有没有拿投资等等，不如就借此聊聊吧！

长按识别二维码

联系我

阅读原文

跳转微信打开

修订了部分问题和完善了一些逻辑，立足于甲方安全职业的发展路径。

一、招聘吐(hao)槽(nan)

这是一件因吐槽而引起的文章，为什么要吐？无他、太难了！！！君不见现在为了招人用尽奇招，技术文章后面必跟招聘广告已成标配不说，还要真人曝光奔赴直播现场，只为求得一员。

一方面反映出安全行业人才缺口极大，但另外一方面又有大量的简历和候选人被过滤掉，想来这里面是不是出现了某种偏差？

为啥？最直观的感受是发出去的JD，收到的简历中70%以上都是渗透类，然后里面90%又都是web安全类的简历，实习生也是如此，70% - 80%都是web安全方向的，安全其他方向岗位的不在一个级别上。

但这点其实是和企业安全岗位供需不匹配的，安全已经不是一个人的安全了，各个方向都是精彩纷呈！一次群里吐槽后，有了这篇文章。

SO...带着一众大佬还有腾讯安平lake总的寄(tiao)语(kan)，小议下甲方安全职业发展，因为我主要工作经历在甲方，所以仅从甲方角度来谈，高度和格局有限，内容仅供参考，不服欢迎来辩！

二、甲方安全的变迁

记得参加第一份正式安全工作是在2004年，安全还处在很容易与网管划等号的时代，了解一点的会说：“杀毒的吧！”，不懂的会说：“在哪个商场当保安啊，很辛苦吧！”。

现在安全已经有了翻天覆地的变化，不管是安全变为国家战略，还是国家安全周、首都安全日等宣传，上至企业，下至百姓让更多人对安全有了更深入的认识，回家再也不会被人问在哪个商场上班了，要求千里取QQ也日益少见。

而安全行业本身在公司的重要性也在不断提高，从网管兼安全，到归属运维，再到和运维平级，再到出现CSO、CISO，而分工也越来越专业化，有了更精细的部门岗位划分，以及出现了较明确的职业发展路径。这些说明行业已经走向成熟化了，这是一个重要的标志！

这个过程和企业业务的发展其实是强关联的，而且随着企业业务形态的变化，安全的关注重点也在不断的变化，例如：

• 终端/网络安全：2000年左右终端/网络安全是关注重点，尤其是CIH、冲击波、震荡波等蠕虫爆发，以及大量终端漏洞被工具化抓肉鸡，让企业对安全有了初步直观认识，但多数公司安全是网管兼职状态，甲方少有全职安全团队；

• web安全：在2000年后web2.0的发展，一批互联网公司兴起，由于业务依托web服务直接暴露在公网中，瘫痪业务挂黑页让互联网企业经营直接受到危害，一些先行的大互联网公司组建了全职安全团队；

• 业务安全：在web2.0发展的同时，电商、网游也是互联网第一波红利行业，带动了最早的一批职业黑产，比如外挂、私服、刷单，业务安全这个领域也有了细分，甲方也有了独立业务安全部门，专注在特定领域；

• 移动安全：2013随着4G的发布移动时代迎来了大发展，业务纷纷转向移动端也带来了重新打包，仿冒，外挂等黑产，也催生了移动安全市场；

• 云安全：移动时代的同时对企业市场还有个重大影响是云化，业务云端迁移的过程也给甲方安全带来了很多变化，公私有云的融合带来安全架构变化，比如内部安全被弱化；

• 安全合规：2011年CSDN等一系列网站密码泄露让社工库成了必备“工具”，随后国内外一系列事件，到2017年网安法、18年GDPR颁布、数据和隐私安全成了合规热点，甲方可有可无的合规岗位变的越发重要，也催生了全知科技这样的先行者；

• 其他：还有很多如IOT安全、内容安全等，这些不再独立列举了，能简单回顾下安全关注的发展过程就好。

那么这些给安全职业发展带来的是什么？即业务类型越来越多变，安全也越来越复杂，需求和分工越来越专业化。

三、甲方职业发展

如果用前文的关注点来分析，你会发现安全岗位是在逐渐细分的，例如：

• 为了解决web安全问题：细分为以黑盒为主的渗透测试、白盒为主的代码审计，评审为主的SDL工程师等；

• 为了解决业务安全问题：细分为外挂防护的逆向工程师，关注账号业务的业务风控，建立模型的算法工程师，抓捕为主的黑产打击；

• 为了解决移动安全问题：细分为移动安全测试，移动安全加固等；

• 为了解决安全合规问题：有等保/27001方向的合规工程师，数据安全方向的数据安全，隐私方向的隐私安全等；

• 此外还有，安全产品、安全开发、安全SRC运营等细分的安全职业

如果从大的归类上，甲方安全需求会有以下几个大类：

• 基础安全类

• 合规/数据安全类

• 业务安全类

• 安全开发类

• 安全管理类

上述大类下根据公司规模体量，又会进一步拆分出小部门，越大型公司安全投入越多的，越会细分来提高专业性。

这样安全从“兼职安全”到“独立安全”再到“安全细分”，在成熟的甲方公司，安全职业发展上也独立出了明确的职业路径，类似这样：

大体上甲方安全最终都会走上技术序列和管理序列，两个序列越往后互换的难度和成本越高，两类序列在很多互联网公司中多数已实现待遇类似，管理和技术只是工作偏重点不同的方向去划分，相对的要求和区别在于：

• 技术序列：越往上要求技术越精通，越要有技术前瞻性；

• 管理序列：越往上要求对业务理解越深入，越要有统筹规划能力；

所以如果从发展路线上来看，不同岗位不同的路径，都是有良好的发展前景。但现实情况是，很多人都挤在了web安全这条路上，从长远发展路径上看，这会让走这条路的竞争更激烈。那么为什么会这样，以及如何选择可以价值最大化？

四、供需问题

从现状上来说，目前安全职业供需很不均衡，学校和行业自身的引导上也存在偏科问题，大部分学校的人才培养、社会的宣传都集中在渗透方向或是web安全上。

比如CTF类的比赛，SRC的挖洞奖励，虽然本意都是激励漏洞挖掘，但因为web安全低门槛易实战的特点，导致大量人才都集中到这上面了，其他方向的人寥寥无几，但是从上面章节内容可以看出，企业安全对各个领域都有广泛的需求，而且随着行业发展，专精化的特点，供需问题会越发突出，所以可能web类安全在未来行业进一步成熟会率先饱和。

为什么会这样？

• web安全业务应用广泛，架构上安全考虑不多，存在的问题较多，也容易造成严重的后果，所以需求最大；

• web安全上手门槛较低（专精不低），3-6个月的培训班出来即可干活，也有很多场景可以随时练手；

• 容易获得成就感，不管是CTF比赛、SRC漏洞奖励、白帽沙龙这些都很容易获得极大物质和精神成就感，以及他可以，我也可以的的状态；

• 其他方向不容易有场景，也就是说想深入提升不容易；

• 甲方对安全的理解，现在还存在很多一个人的安全团队，这类公司高层很难对安全有深入理解，更不会考虑到资源的安排，web安全多数也是最紧迫的安全需求，这点也是现实情况。

关注和思考

• 首先php之类的语言在企业业务中快速被淘汰中，java类的框架安全性也在不断增强和完善，安全文化进一步的提升后，web安全漏洞已经相对比以前少了很多，从owasp top10 近10年排名也可以看出，未来web安全会越来越健壮；

• 易上手，快速入行也会存在竞争激烈的问题，单一的web攻击利用不会带来特别高的独特价值，如果走这条路需要不断扩充自己的能力，比如代码审计，工具开发能力，SDL等，实际上也可以看到web安全时代大佬们，已经在其他领域开始了更深入的发展；

• 其他方向入手门槛高，从另外一方面来说其实也是提高了竞争门槛，形成了差异化竞争；

• 未来5年后随着行业进一步细分，不同安全行业领域互换的成本会增大，企业更倾向在该领域有长时间发展的人，而非中途转过来的，文首截图部分其实可以看到一些公司安全已经开始行动了，安全其他领域缺口越来越大，开始扩充培养方式。

归纳下，可以着眼考虑下安全行业长远发展趋势，以及自身对技术的定位和特点，不用局限在眼前的利益上或易于入门上。

例如通过快速上门，掌握了一些web安全知识，可以用扫描器来找一些漏洞，但是没有java等编程语言基础，也不擅长去深入挖掘web漏洞，自身感觉会快进入一个平台期，如果这样就不如换个赛道。

当然了本文绝非贬低web安全带来的价值，实际上web安全长期都会是企业安全必不可少的岗位，只是考虑是否是自己的最佳选择？

五、最后要说什么？

• 甲方企业的安全建设不是由单一岗位推动，而是一个群力的合作，每个领域都需要专业的人才；

• 甲方安全职业发展路径已经越来越专业化，分工越来越明确，专业能力要求越来越高；

• 新入行的同学，不要把目光只聚集在web安全上，从长远的发展来看其他各个方向并不会差，差异化能力很重要；

• 如果在甲方安全长期发展，应该多挑战安全场景，去解决企业安全问题，丰富自己的能力，有解决问题能力的人，未来会走的更远；

• 技术和管理线各有各的挑战和发展，结合自身特点和规划来选择和发展。

六、活动

另外今天晚上4月23日，我在Freebuf有招聘直播，欢迎扫码预约，来直播间和我交（bian）流（lun），还可以拿限定奖品，或是招聘直推！

https://live.freebuf.com/detail/0c1b102816084c7092180e4d8395ad35/?code=45b600a3f8000fa20401eb1654f7530e

招聘详细岗位介绍、分析等见下述文章：

招聘 | 完美世界集团信息安全部招聘，加入我们，有你才完美~

硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

安全硬核招聘的总结与兑奖

heyi@pwrd.com 欢迎直投，推荐入职送最新最贵的手机！也可以加我微信，微信投递效果一样。

希望本文对你能有所价值，欢迎关注、在看、转发、置顶一波流！不胜感激！

扫描二维码

关注原创干货

小议安全

阅读原文

跳转微信打开

各公司安全招人用尽奇招，出卖技术带招聘，顶着大油头上招聘直播，软硬兼施请小姐姐为招聘代言的...这背后是什么原因？今天来聊聊这个话题，还有限时活动哦！

一、招聘吐(hao)槽(nan)

这是一件因吐槽而引起的文章，为什么要吐？无他、太难了！！！君不见现在各大公司招人用尽奇招，技术文章后面必跟招聘广告已成标配不说，大佬们顶着油亮又稀缺的发型奔赴直播现场，只为求得一员。

一方面反映出安全行业人才缺口极大，但另外一方面又有大量的简历和候选人被过滤掉，想来这里面是不是出现了某种认知偏差？

为啥？最直观的感受是发出去的JD，收到的简历中70%以上都是渗透类，然后里面90%又都是web安全类的简历，实习生也是如此，70% - 80%都是web安全方向的，安全其他方向的完全不在一个数量级上。

安全各个方向都是精彩纷呈啊！然后一次群里吐槽后，萌生了这篇文章。

SO...带着一众大佬还有腾讯安平lake总的寄(tiao)语(kan)，小议下安全职业，因为我主要工作经历在甲方，所以仅从甲方角度来谈，另外高度和格局有限，内容仅供参考，不服来辩！

二、甲方安全的变迁

记得参加第一份正式安全工作是在2004年，安全还处在很容易与网管划等号的时代，了解一点的会说：“杀毒的吧！”，不懂的会说：“在哪个商场当保安啊，很辛苦吧！”。

现在安全已经有了翻天覆地的变化，不管是安全变为国家战略，还是国家安全周、首都安全日等宣传，让更多人对安全有了更深入的认识。

安全行业本身在公司的重要性也在不断提高，从网管兼安全，到归属运维，再到平级，再到出现CSO、CISO，而分工也越来越专业化，有了更精细的部门岗位划分，以及出现了较明确的职业发展路径。

这个过程和企业业务的发展其实是强关联的，而且随着企业业务形态的变化，安全的关注重点也在不断的变化，例如：

• 终端/网络安全：2000年左右终端/网络安全是关注重点，尤其是CIH、冲击波、震荡波等蠕虫爆发，以及大量终端漏洞被工具化抓肉鸡，让企业对安全有了初步直观认识，但多数公司安全是网管兼职状态，甲方少有全职安全团队；

• web安全：在2000年后web2.0的发展，一批互联网公司兴起，由于业务依托web服务直接暴露在公网中，瘫痪业务挂黑页让互联网企业经营直接受到危害，一些先行的大互联网公司组建了全职安全团队；

• 业务安全：在web2.0发展的同时，电商、网游也是互联网第一波红利行业，带动了最早的一批职业黑产，比如外挂、私服、刷单，业务安全这个领域也有了细分，甲方也有了独立业务安全部门，专注在特定领域；

• 移动安全：2013随着4G的发布移动时代迎来了大发展，业务纷纷转向移动端也带来了重新打包，仿冒，外挂等黑产，也催生了移动安全市场；

• 云安全：移动时代的同时对企业市场还有个重大影响是云化，业务云端迁移的过程也给甲方安全带来了很多变化，公私有云的融合带来安全架构变化，比如内部安全被弱化；

• 安全合规：2011年CSDN等一系列网站密码泄露让社工库成了必备“工具”，随后国内外一系列事件，到2017年网安法、18年GDPR颁布、数据和隐私安全成了合规热点，甲方可有可无的合规岗位变的越发重要，也催生了全知科技这样的先行者；

• 其他：还有很多如IOT安全、内容安全等，这些不再独立列举了，能简单回顾下安全关注的发展过程就好。

那么这些给安全职业发展带来的是什么？即业务类型越来越多变，安全也越来越复杂，分工和需求都越来越专业化。

三、甲方职业发展

如果用前文的关注点来分析，会发现安全岗位在逐渐细分，例如：

• 为了解决web安全问题：细分为以黑盒为主的渗透测试、白盒为主的代码审计，评审为主的SDL工程师等；

• 为了解决业务安全问题：细分为外挂防护的逆向工程师，关注账号业务的业务风控，建立模型的算法工程师，抓捕为主的黑产打击；

• 为了解决移动安全问题：细分为移动安全测试，移动安全加固等；

• 为了解决安全合规问题：有等保/27001方向的合规工程师，数据安全方向的数据安全，隐私方向的隐私安全等；

• 此外还有，安全产品、安全开发、安全SRC运营等细分的安全职业

如果从大的归类上，甲方安全需求会有以下几个大类：

• 基础安全类

• 合规/数据安全类

• 业务安全类

• 安全开发类

• 安全管理类

上述大类下根据公司规模体量，又会进一步拆分出小部门，越大型公司安全投入越多的，越会细分来提高专业性。

安全从“兼职安全”到“独立安全”再到“安全细分”，甲方安全职业发展上也有了明确的职业路径，类似这样：

大体上甲方安全最终都会走上技术序列和管理序列，两个序列越往后互换的难度和成本越高，两类序列在很多互联网公司中多数已实现待遇类似，管理和技术只是工作偏重点不同的方向去划分，相对的要求在于：

• 技术序列：越往上要求技术越精通，越要有技术前瞻性；

• 管理序列：越往上要求对业务理解越深入，越要有统筹规划能力；

所以如果从发展路线上来看，不同岗位不同的路径，都是有良好的发展前景。但现实情况是，很多人都挤在了web安全这条路上，从长远发展路径上看，这会让走这条路的竞争更激烈，所以接下来谈谈选择？

四、供需问题

目前安全职业供需很不均衡，行业的引导上也存在偏科问题，大部分学校的人才培养、社会的宣传都集中在渗透方向或是web安全上。

比如CTF类的比赛，SRC的挖洞奖励，虽然本意都是激励漏洞挖掘，但因为web安全低门槛易实战的特点，导致大量人才都集中到这上面了，其他方向的人寥寥无几，但是从上面章节内容可以看出，企业安全对各个领域都有广泛的需求，而且随着行业发展，专精化的特点，供需问题会越发突出。

为什么会出现这种问题？

• web安全业务应用广泛，架构上安全考虑不多，存在的问题较多，也容易造成严重的后果，所以需求最大；

• web安全上手门槛较低（专精不低），3-6个月的培训班出来即可干活，也有很多场景可以随时练手；

• 容易获得成就感，不管是CTF比赛、SRC漏洞奖励、白帽沙龙这些都很容易获得极大物质和精神成就感，以及他可以，我也可以的的状态；

• 甲方对安全的理解，现在还存在很多一个人的安全团队，这类公司高层很难对安全有深入理解，更不会考虑到资源的安排，web安全多数也是最紧迫的安全需求。

应考虑的问题

• php之类的语言在企业业务中快速淘汰，java类的框架安全性增强，web安全漏洞已经相对比以前少了很多，从owasp top10 近10年排名也可以看出，未来web安全会越来越健壮；

• 易上手快速入行也会存在竞争激烈的问题，实际上web安全时代大佬们，已经在其他领域开始了更深入的发展；

• 未来5年后行业进一步细分，不同安全行业领域互换的成本会增大，企业更倾向在该领域有长时间发展的人，而非中途转过来的，文首截图部分其实可以看到一些公司安全已经开始行动了；

简单的说，可以着眼考虑下安全行业长远发展趋势，不要局限在眼前的利益上，当然了本文绝非贬低web安全带来的价值，实际上web安全长期都会是企业安全必不可少的岗位，但这是是否是你的最佳选择？

五、最后要说什么？

• 甲方企业的安全建设不是由单一岗位推动，而是一个群力的合作，每个领域都需要专业的人才；

• 甲方安全职业发展路径已经越来越专业化，分工越来越明确，专业能力要求越来越高；

• 新入行的同学，不要把目光只聚集在web安全上，从长远的发展来看其他各个方向并不会差；

• 如果在甲方安全长期发展，应该多挑战安全场景，去解决企业安全问题，丰富自己的能力，有解决问题能力的人，未来会走的更远；

• 技术和管理线各有各的挑战和发展，结合自身特点和规划来选择和发展。

六、活动

容易吗？晚上开会完，赶这篇文章在公司写到凌晨1:00，只为了赶在活动前做些宣传......

4月23日，完美世界freebuf安全招聘直播现场，请扫码预约，欢迎来直播间和我交（bian）流（lun），拿限定奖品！

https://live.freebuf.com/detail/0c1b102816084c7092180e4d8395ad35/?code=45b600a3f8000fa20401eb1654f7530e

招聘详细岗位介绍、分析等见下述文章：

招聘 | 完美世界集团信息安全部招聘，加入我们，有你才完美~

硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

安全硬核招聘的总结与兑奖

heyi@pwrd.com 欢迎直投，推荐入职送最新最贵的手机！也可以加我微信，微信投递效果一样。

有感受到诚意吗？如果有感受到，请关注、在看、转发、置顶一波流！不胜感激！

扫描二维码

关注原创干货

小议安全

阅读原文

跳转微信打开

对于密码，相信不少人都有欲除之而后快的念头，那么我们是否可以干掉密码？又会有哪些挑战？本文是对干掉密码的实践，以及如何结合零信任进行实施。

密码是良药还是毒药？

（1）密码/口令起源

正文开始前，为避免混淆先明确，本文内所说的密码实则是登陆口令，特指静态密码，而非对通讯或内容加密的对称或非对称密码。

在《左传》中，2000多年前的吴国与楚国在交战时，吴王的船被楚军截获，十分着急的吴国士兵在一个漆黑的夜晚，派了3个士兵乔装成楚兵，潜入进去楚军，为了避免黑夜认错人，按照事先约定好的，以“余皇”为暗号进行身份确认，后夺回了吴王船只。

从此，“暗号”开始在军中使用，一般在对敌战争中能见度不高时，用来辨别敌我，后来又称“暗号”为“口令”沿袭至今。（故事未经考证）

（2）密码的“危害”

从上述故事可以看出，密码的安全机制是在于，密码只有拥有者和验证者才知晓，通过对密码的校验来识别身份，如果密码泄露了，就可以伪装身份，现今大多数网站、系统的认证也是如此，账号和密码背后代表了你的身份和权限。

常规情况来说，密码应该是安全的，理论上不会被其他人知道，但真实的情况却不是这样，密码成了现在最容易攻击的一大薄弱点，大体上针对密码以下攻击方式都会导致密码失效：

• 弱口令：弱口令是非常普遍的情况，本质上是违反人要追求便利的心理，违反了人性；

• 密码盗取：有多少看客曾经将密码放到txt中，或记录在便签纸上？或是中个木马通过键盘记录，都很容易导致密码被盗取，而密码复杂性在这类场景下毫无意义；

• 撞库攻击：一般不会有人对每个网站都设置独立的密码，原因还是违反了人性，所以一旦某一个网站密码被泄露，账号很容易在其他网站中被撞，大概率会登陆成功，在外暗网内的密码社工库已经达到惊人的规模了；

• 拖库攻击：直接从服务端上把账号和密码盗走，方式多样，最终结果都是数据库被拿走，用户对此是毫无感知的，至于密码复杂的意义在于服务端有没有进行加密，加密可以增加被爆破的难度。

从上述情况可以看到，密码被盗是大概率事件，就算你有良好的习惯，也无法保障其他地方不出问题。

而在企业中，密码带来的安全风险就更严峻，很多APT案例，都是以获取到管理员密码为里程碑，如驱动人生的供应链攻击，如下图：

（图1）腾讯御见分析报告

在针对驱动人生的攻击中可以看到，前期准备、横向移动的阶段性成果，都是以获取到管理员账号密码为里程碑，并且在目标达成后很快就实施了后续的攻击，迅速达成战果。

这类型的攻击在企业安全事件中也是层出不穷，导致密码讽刺的由应该提供保护，变成了加害方，密码不再是安全要素而是风险要素。

去密码化方案分析

那么我们能否干掉密码，用更安全的方式来替代它呢？答案显然是可以的，而且这个目标应该是多数企业应该达成的目标，会是一个长期趋势。

（1）密码在企业中的应用

在尝试干掉密码前，有必要先了解清楚密码在企业中的应用范围，对方下药疗效才更好。如果按照密码使用对象来区分，会有下面几类对象：

面向客户

• 业务密码：QQ、游戏账号之类

面向员工

• 办公PC密码

• 企业邮箱密码

• 业务IM密码

• 网络准入密码

• VPN密码

• 代码仓库密码

• 业务系统密码

• OA网站密码

• ......

面向管理员

• 网络设备密码

• 服务器登陆密码

• 安全设备登陆密码

• 管理后台密码

• ......

面向系统服务

• API-KEY：服务API调用认证

• 数据库密码

• ......

这四类对象，需要采用的解决方案各不一样，本文聚焦在企业内部用户“员工”和“管理员”这两类角色上，业务账号安全、服务口令安全留在后续再做探讨。

（2）密码挑战

在面向员工和管理员的密码安全问题上，企业安全已经奋战很多年了，各大公司都采用过很多方式，例如下面这些：

• 密码复杂策略：通过域控、后台密码策略等方式，强制要求密码满足复杂度要求，比如我知道业界某知名公司要求密码长度在15位以上，15位以下被视为弱口令；

• 密码生命周期：要求定期密码进行更换，以及禁止使用之前曾经用过的密码，防止密码来回使用，目的就算密码被泄露了，也只在密码生命周期内可用；

• 主动爆破：包括不限于直接用密码破解机对域控密码进行破解，用扫描器进行爆破，用基线系统进撞密码，目的是主动发现弱密码；

• 社工库撞库：前几年法律不完善时，为了降低社工库危害，很多企业安全团队会自己下载社工库后去撞公司员工账号，目的也是为了主动发现被泄露的密码；

• 除此外还有口令管理制度、安全意识培训，这些并没有什么用的方式...

上述方案在人性面前，都是naive，多年的企业安全经验上，有违人性的规则，必然会被绕过，比如：

• 密码复杂度策略：类似这样“123456qwerty!@#$%^”看似安全的复杂密码，或是写在电脑旁的便签纸上，更为了方便贴在显示器下广而告之；

• 密码生命周期：每次都要设新密码，记不住怎么办？在密码后通过+1、-1方式来循环；

• 最终你会发现，规则有多强，人的创意就会有多高。

（3）替代密码方案的选择

那么什么样的密码才是安全的呢？我总结了个强度四要素，可以用来做评估供参考，如下：

弱密码要素

• 可知：可以被获取到；

• 可预测：可以通过其他信息预测到，比如生日，姓名；

• 可重放：可以被重复使用；

• 单一维度：维度单一，一输皆输。

强密码要素

• 不可知：不能或难以被获取；

• 不可预测：强随机性，不能或难以被预测；

• 不可重放：一次有效，无法被重复使用；

• 多维度：维度多样化，需要多维度组合，某一个维度被泄露不影响整体安全。

基于上述标准，引入现在场景的密码替代技术，可以快速评估密码替代方案是否安全、健壮，如下表：

上表可以看出，大众普遍认识的生物识别并不安全，而多数运维使用的证书登陆也并不太安全，至于以前手机上常见的手势方式验证就更弱了。

传统的OTP+PIN码的方式是相对安全的，也是我们首选方案，但需要说明但是，考虑到用户体验等问题，我们也使用了扫码等方案来适用不同场景，并非单纯的一刀切。

而每引入一个新的方案，一定会带来新的风险，比如OTP+PIN的方式安全依赖密钥种子和算法安全性，本文假定这些方案都被用最优方式落地，因此不做进一步衍生讨论了。

去密码化方案设计

明确了需求、挑战和密码替代方式后，就可以开始进行去密码化方案设计了，在方案设计上需要考虑：需求是否能被满足、是否可以扩展、是否具备弹性、是否稳定、以及易用，同时设计时也需要考虑后续如何落地的问题。

（1）需求实现

需求实现上一个重要考虑是不是能支持员工、管理员使用的密码场景，通过对密码场景进行梳理分类，会发现需要支持的认证方式主要有下面几类，只要支持了这些认证方式，对应的系统、场景也就可以支持到了。

Form网页认证：

• OA网站

• 内部业务系统

• 后台管理网站

• 知识库等

PAM认证：

• Linux类服务器认证

Windows KDC认证：

• Windows类系统

Radius认证：

• 网络准入、无线网准入

• 网络设备认证

• VPN认证

私有协议：

• 企业IM认证

• exchange客户端认证

（2）统一认证系统架构

为了提高用户体验，降低成本，建立统一的认证中心是很有必要的，尤其是集团化的公司，随着分公司、人员和业务的增多，如果是分散的架构，会导致要投入的人力成本大幅增加。

等部署实施完，随着人员在不同公司、业务之间的流动，又会加剧管理的复杂度，最终因用户体验下降，项目难以被推进。

（图2）统一认证系统架构

绿色-核心区

• Auth服务：认证系统核心，用于算法、密钥种子、密钥生成方式；

• Auth-DB：用于存储用户、认证代理、授权等相关信息；

红色-认证代理和认证接口

• Form认证代理：用于提供web系统OTP认证接入；

• PAM认证代理：用于Linux类系统使用OTP认证接入；

• Windows认证代理：用于Windows类系统使用OTP认证接入；

• auth接口：私有协议或是特殊场景下使用auth接口来获取认证信息；

• Radius：对接Radius服务，用于网络设备、准入、VPN类的OTP认证接入；

蓝色-用户区

• 激活服务：用户自助系统，用于用户自主激活，PIN码设置，手机更换，找回等；

• 软、硬令牌：OTP载体，实际上由于智能手机的普及，通过手机软令牌会给用户更好的体验，硬件令牌往往用于一些特殊场景；

黄色-管理区

• 系统管理后台：用于权限分配、用户锁定、禁用、认证代理管理等功能

（3）认证代理实现

在认证代理实现上，区分不同认证代理是为了解决不同认证场景，本质上都是将认证请求转发到auth中来认证，例如Form网页认证代理，将输入的账号和密码转给auth服务进行验证，返回认证结果给业务网站。

除form外，其他几类认证都有开源或是相关解决方法，现将常用的几类实现原理简要进行介绍，如果需要进一步研究和实现的可以根据文章后面的参考链接，进一步学习。

PAM认证代理

可拔插验证模块（PAM）是Linux自带的功能，是为了通过统一的接口、配置，以可扩展方式实现不同的认证接入。

（图3）PAM框架

在PAM框架上，对于相关的认证管理、账号管理、会话管理、口令管理都进行了封装，开发者不用关心底层使用的服务模块，可以比较快速的实现，网上也有很多样例可以参考。

（图4）PAM配置架构

认证代理实现上按照PAM标准，开发好对应的SO后通过PAM配置文件，指定什么样的应用场景下使用OTP认证，比如远程登陆，或是本地登陆，su之类。

Windows认证代理

Windows的OTP认证代理实现相对复杂，原因是windows不像Linux提供了比较好的接入方式，是个黑盒状态，需要通过劫持方式来嵌入OTP的认证，但这类方式并非完美实现，主要实现逻辑如下：

（图5）2003交互式登陆流程

上图是windows 2003、XP版本的windows认证逻辑，区别在于左边的是走的本地认证，右边的走的域认证，嵌入OTP认证后的逻辑如下：

• CTRL+ALT+DEL：进入交互式认证，启动GINA（账号密码输入框）

• GINA：输入用户名和密码后，转发至本地LSA进行验证，如果是域的话会转给域LSA由AD进行认证；

• New process：认证通过后，OTP 认证代理需要劫持认证状态，转入OTP的认证，认证通过后放行认。

（图6）windows2008登陆流程

windows2008后登录逻辑有了较大调整，引入了票据机制，整个逻辑更加复杂，但对OTP类的登录来说，过程还是一样，走完windows认证后进行劫持，再通过OTP认证。

需要说明的是，这类方案不是完美方案，会导致用户需要两次认证，用户体验并不好。如果你有更好的解决方案，请告诉我，谢谢。

Radius认证代理

远程认证拨号用户服务（RADIUS）主要用于网络接入设备和认证服务器之间承载认证、授权、计费和配置信息。通常用于网络设备认证、VPN认证和网络准入等认证，支持PPP、CHAP、EAP等协议。

（图7）Radius认证代理

Radius分为client、server端，client一般是网络设备、准入程序，由client发起认证请求，server端进行验证。

如果要集成OTP或其他认证方式，一般通过认证代理转发模式，即不对认证协议进行改造，而是等用户输入的用户名、密码之类信息传递过来后，讲认证请求转到认证服务中进行验证再返回给Radius，或是更粗暴些，直接将Radius服务端进行改造，将认证逻辑换到OTP上。

密码代填方案（差）

先说明密码代填不是一个好方案，一般是用于解决一些老旧商业系统无法支持OTP的情况，这类系统由于是黑盒模式，又不提供接口或是SDK，导致接入改造难度比较大。

（图8）密码代填

这类场景在万不得已的情况下可以考虑密码代填方式，好处是实现相对容易，但问题是要代填密码，也就是说会导致保存明文密码。

这类方式一旦认证代理如果出了问题，可以绕过验证，以任意人账号登录后面的系统，风险还是比较高的，通常不得已不要使用这类方式。如果一定要用可以通过对明文密码加密、密码随机化，密码一次性使用等方式来加强保护，但本质上还是不安全，并非是安全的方案。

有一些身份认证的乙方公司会使用这类方案来做集成，如果遇到这类要考虑下安全风险。

（4）用户身份绑定

统一认证架构后，令牌其实已经变成了唯一认证来源，不管想做什么，都需要令牌来。包括零信任中设备->用户->应用的信任关系，也是依赖于令牌。也就是说账号和OTP令牌实际是用户在网络空间中的投射。

考虑到近万员工已经不可能一对一来支持，或是通过管理员下发令牌来进行身份绑定和激活了。因此需要把激活过程变成自助模式，通过对员工实体身份对校验来进行激活绑定，以及结合员工状态来自动实现禁用、回收等工作。

该环节需要考虑比较多的是，怎么证明你就是你的问题，以及如何让用户好理解，引导上尽可能的方便不要造成用户的困惑，以及设备更换后，需要重新绑定等问题。

与零信任架构结合

本质上这个无密码化方案是完全可以和零信任架构脱钩，独立运行，但有了零信任架构会带来用户体验上的很多好处。

（1）实施挑战

方案开发和落地是两个事情，里面有巨大的鸿沟，尤其是当你实施时，需要面对大量用户时会面临很多技术和非技术的挑战，例如：

（图9）实施挑战

• 不开心：你要改变我的习惯，不开心，用不惯请你改回来；

• 没头脑：令牌怎么激活？帮助文档在哪里？你能不能帮我搞？

• 业务为王：业务出了问题你负责吗？我业务出问题了，就是上你们的搞的。

• 你爸爸：要集成？厂家不支持，厂家要费用，厂家没时间，厂家已经倒闭了...

上面这些是在涉及用户的安全方案落地中常见问题，而要做无密码化方案，势必要改变用户习惯，需要业务配合接入，而业务也要考虑自己的业务稳定性，这些挑战都需要运营、开发、业务携手来克服。

（2）零信任架构整合

通过零信任架构，在一定程度上可以解决或减轻上述问题，主要原因是零信任集中了各类系统的入口，统一了身份，从而也可以天然可以统一认证方式。

（图11）零信任集成架构

类似上述架构，Form类认证的网站业务可以全部放在网关后，服务器登陆维护可以用网页版堡垒机方式进行集成，移动办公和零信任终端agent集成等，关于这部分内容之前写的零信任实战远程办公中有写，感兴趣的可以看文末索引回顾，就不重复了。

用户体验好不好是安全方案能否落地的关键因素，尤其是在互联网公司，一个不小心就会被在论坛上喷，造成很大的压力。

通过零信任可以统一用户体验，账号、令牌、权限的激活均变为一次性操作，然后结合大量的自助引导，以用户体验为目标的UI设计，自助化的流程系统等，以一套标准培养用户习惯，最终达成预期目标。

结束语

这个方案是零信任架构中一个附带成果，个人觉得对企业安全来说，能解决密码安全问题可以给安全带来很大提升，而方案从设计、开发到实施落地，实际用了很长时间，团队也在背后付出了巨大努力，中间一个比较有价值的体会是，尽量避免违反人性去推动安全。

最终，某天终于发布了取消静态密码登陆的通告，将集团用户都切换到无密码化的环境中，解决了多数密码场景。

但要认清现实的是，实际情况还是有很多问题在等待解决，比如exchange客户端问题、数据库密码问题，API密钥问题，OTP和自动化运维的冲突问题等。

而大范围的使用过程中，还需要考虑HA问题、分布式架构等问题，这些未在文中一一展开来说，如果有需要后续再展开来说。或是直接加入我们，一起来解决企业安全问题，欢迎给我发简历 heyi@pwrd.com 。

参考

PAM的应用开发：http://www.ibm.com/developerworks/cn/linux/l-pamdev/index.html

PAM认证模块：http://www.yulongjun.com/linux/20170720-02-pam/index.html

Windows登录流程：https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc780332(v=ws.10)?redirectedfrom=MSDN

Radius介绍：https://en.wikipedia.org/wiki/RADIUS

历史文章

零信任架构远程办公实战

零信任架构实战系列：如何选择零信任架构

零信任实战系列：远程办公实战（视频）

硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

关于我

我是何艺，从事甲方安全16年，目前负责完美世界集团安全工作，聚焦在企业安全建设、零信任、安全架构、安全分析与响应、数据安全等领域，今年开始尝试写公众号“小议安全”，坚持输出有干货的原创。

构思到写完一篇文章大概需要3-5个晚上或是1-2天周末时间，如果这篇文章对你有价值，关注、在看、转发三连，会是对我最大的支持，谢谢！ 

扫描二维码

关注原创干货

小议安全

阅读原文

跳转微信打开

向抗击新冠肺炎疫情斗争牺牲烈士，和逝世同胞深切哀悼

跳转微信打开

这个是之前受邀在freebuf公开课的视频，主要是使用零信任架构进行远程办公，过程的一些考虑和实际使用情况，和公众号之前的图文内容差不多，略有扩充。

这个是之前受邀在freebuf公开课的视频，主要是使用零信任架构进行远程办公实战，和公众号第一篇零信任文章内容是差不多的，主要包含几个方面：

1. 零信任架构历史和原理介绍

2. VPN方案和零信任方案在远程办公上的对比

3. 零信任架构远程办公方案的实施过程

4. 实践的效果与问题总结
   

因为之前有朋友问能否做些直播分享，但因为平时要工作，空闲时间也都留给写公众号文章了，所以直播方式后面再找机会在弄吧，正好之前freebuf公开课的时候录过一段视频，先把这个视频放上来看看反馈。
另外因为公众号的限制，视频只能上传30分钟，所以分为上下集分开放了，方便观看。

上集

下集

历史文章

• 零信任架构实战系列：远程办公

• 零信任架构实战系列：如何选择零信任架构

• 硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

• 安全硬核招聘的总结与兑奖
  

如果觉得文章对你有价值，关注、点赞、转发会是最好的支持，也会鼓励我继续写下去，谢谢支持，素质三连哦！

扫描二维码

持续更新中

小议安全

阅读原文

跳转微信打开

零信任和传统安全的区别在哪里，是否有价值，以及什么场景可以考虑去选择零信任架构，这是本文试图解答的问题？

传统安全模型优缺点

（1）边界安全模型历史

在internet发展初期80年代时，各大学校纷纷接入internet，在87年时接入节点数已达数万，这个期间有第一届TCP/IP 协议会议召开，也有第一封中国发出的email，还有第一次的网络蠕虫事件让当时1/10的节点受到影响。

受蠕虫事件影响，在1988促使DARPA成立了CERT（计算机危机快速响应小组）来应对网络安全事件，而在89年Clifford Stoll完成了布谷鸟的蛋一书，详细讲述了德国密码破译小组通过网络入侵到美国的计算机设施中的真实故事。

1989年随着第一个包过滤防火墙面世，也正式拉开了长达数十年的边界防御安全模型思想，之后虽然防火墙一直在迭代更新，架构也在更新，但本质核心思想并没有离开。

（2）边界安全模型优点

防火墙的诞生是来自很质朴的思想，即外部发生威胁（火灾）时，通过防火墙快速切断威胁保护内部安全，也就是说它的思想核心在于边界的阻断，如下图：

（图1）边界安全模型图

在该模型中，将网络划分为不可信（untrust）和可信（trust）两个区域，记得直到2000年初期，我配置过的一些防火墙接口还是以此为区分。在这个安全思想下，安全是基于网络的位置来定义的。用防火墙或网络设备上ACL将网络切分边界，进行隔离，从不可信网络进入到可信网络的数据包，要经过防火墙的检查，规则允许下才会被放行。

这类方式在初期的时候是有效的，因为当时的网络规模不大，业务也不复杂，很好的阻断了蠕虫类攻击传播和一些未授权的访问，总的来说有以下优点：

• 简单可靠：结构简单没有复杂的架构，网络规划实施后，可以保持相当长时间的稳定运行；

• 规则清晰：根据防火墙类型，基于IP或5元组规则，允许、还是拒绝，清晰明了；

• 阻断彻底：基于网络层的阻断，规则明确后，可以彻底防止被阻断的流量进入网络中，实现彻底的阻拦；

• 业务侵入低：业务不用做过多改造，除非规则配置错误，多数情况下业务是无感的。

（3）边界安全模型的缺点

但随着时代的发展，网络节点数量爆发式增长，各类新的应用也不断涌现，对网络规则的管理成本已经越来越高，而攻击已经发展出各式各样的攻击模式出来，可以轻松越过安全边界，如下图：

（图2）边界安全模型风险

在攻击过程中，黑客可以通过邮件等方式将病毒、蠕虫或后门以正常的业务通道，绕过防火墙的检测投递到trust网络中，或是以物理潜入方式、WIFI接入等方式绕过边界的防火墙控制，直接在内部发起进攻。

即便随着边界安全模型产品的升级，例如防毒墙、WAF、下一代防火墙加入对协议内容的检测，依然无法有效阻止安全攻击。

这是因为传统的边界安全模型重点在于边界的防护，对已经通过边界的行为防御能力有限，再加上安全管理常常外紧内松，疏于内部安全管理，因此黑客一旦进入到内部后攻击难度大幅降低。传统安全模型主要的缺点有：

• 无法防御内部攻击：内部的攻击，横向移动在传统的边界安全模型中难以被检测到，更加难以被防护；

• 
  

• 边界防御容易被绕过：边界防护中，基于网络层的ACL过于粗放，对于混杂在正常业务中的恶意行为，C2难以检测，并且随着全局加密趋势，检测能力被进一步削弱；

• 安全检测容易有盲点：边界安全模型难以完整的全面检测，无法还原所有的轨迹，导致安全检测很容易出现盲点，因为数据的缺失又会进一步影响检测的质量。 

零信任安全模型优缺点

（1）零信任架构历史

在上面的攻防过程中，传统安全模型也在不断的自我发展，例如纵深防护理念，通过多点防护，多点检测，利用纵深空间来换取检测时间。

在对抗过程中，零信任安全模型也被演化出来，2010年的Forrester发布的Zero trust architecture，即是通过将网络尽可能的微分段，在网关处设置流量分析等检测能力，来加强防护，以及检测效率。关于Forrester的零信任架构可以参看原文，或是我上一篇：零信任架构实战远程办公，不再过多叙述。

而Google在2009年遭受过极光行动等安全事件后也意识到，传统的安全模型并不能保护企业安全，纵深防御理念虽然最终目标是可以检出事件，但主动防御能力不够，对高价值资产攻击一旦成功后，损失是难以接受的。

在此背景下Google启动了beyond corp 项目，并在2014年发布了相关项目白皮书，应该也是业界第一个真正落地零信任理念的公司，也是我们的主要参考对象，本文后续也以beyondcorp为案例进行分析。

（2）零信任架构的优点

在该模型下，Google屏弃了传统边界安全模型思想，将安全思想转入到信任关系的建立上，即安全的可信链路的建立，从终端设备通电开始，从硬件底层开始，信任链条就开始逐层向上建立，一步步直到对最终资源的访问。

而传统的边界安全模型中，信任其实是来自对你网络地址的识别，即你IP代表你的身份，IP可信你就是可信的，你的环境是否安全并不是它考虑对象。

（图3）beyond corp project架构

在新的模型下，上层的信任关系是来自人、设备、资源权限的关系，下层有设备加电后芯片级的校验、、系统完整性校验，通过TPM对到上层设备的校验，横向过程还有后端服务之间的可信校验，以及零信任强调的（never trust， always verify）理念。

（图4）零信任架构安全模型

在零信任架构下，传统的边界已经不在重要，即便你在内网同样也是处于“不可信”状态，每一次对资源的访问，都会要经过信任关系的校验和建立，即内外是一致的策略。

安全是建立在信任链之上，如果信任链被打破，那么对资源的访问权限则被自动取消。在这个模型下，有几个显著的优点：

• 安全可靠性更高：因为链条的信任关系是环环相扣，因此中间发生任何异常变化，会更容易被发现被检测到；

• 攻击难度大：信任链条是多维度组成，例如对用户的信任是通过生物校验和多因素认证，对设备的信任是通过主机准人关系，基线状态，运行状态判断，而维度越多，黑客要攻击的成本就越高，从而入侵的难度也就越大；

• 持续校验，从不信任：每一次对资源的请求，都是一次重新校验的过程，安全的状态是动态，因此检测也是动态持续发生，这样如果产生了异常，可以迅速感知并阻断；

• 除此外还有一些全链路分析、集中管控，资产容易管理，包括远程办公等等优点，但这些并不是架构核心优点，因此不再过多描述。

（3）零信任缺点

听起来挺美好的，那么零信任架构是不是完美的？

一直以来我有一个观点，即试图用一个方案解决安全风险时，一定会带来新的风险，这个方案的好坏，很大程度是依赖这个新风险是否可接受。

用人话来说，就是你引入一个新的安全方案的时候，一定会带来新的风险，而对新的风险是否能接受，它是否可控，是决定你这个方案是否可行的关键因素。

所以零信任架构必然也是有它的风险，并且风险不能有效管理，可能会带来更大的问题。在我看来零信任架构有几个缺点：

• 单点风险：因为对资源的控制都集中在网关上了，因此一旦单点故障会导致整个业务中断；

• 集中化权限风险：零信任架构实时上是把很多风险收敛给集中起来了，但并非这个风险就不存在了，比如集中化管理中，如果管理失控了会带更大风险；

• 复杂化风险：因为整个架构涉及多个组件，足够复杂，容易出现业务异常后问题不能及时发现和处理，以及出现业务有任何问题，都是你的责任的情况；

• 凭证风险：为了平衡用户体验，一般零信任架构都会内置SSO功能，这样对于身份的凭证安全、或是注册设备的凭证安全问题、这些凭证的风险都可能会破坏信任体系；

• 投资风险：从我们整个周期来看，零信任架构建设周期比一般架构体系要来的长，这样可能会出现项目未完工，人已经走了的情况，后续接手的人是否还认可这个理念，是否要会从头来过，这些都是建设过程的风险。

和传统安全模型的对比

如果将两者放到一起，就会发现，优缺点是有显著区别的，比如传统安全模型结构简单，但零信任架构复杂，可是安全防护能力强，如下表：

零信任架构的选择

快到尾声了，这个时候可以试图去探讨下，也就是文章开头的问题，什么样的场景是需要零信任架构的，我个人看法如下：

（1）建议上的场景

• 有高价值资产：这个应该是所有选择零信任架构的前提，只有资产有价值，需要保护才需要安全的大力投入；

• 业务严重依赖网络：如果你的业务严重依赖网络，有从内部被恶意破坏的可能，内部控制又很混乱，这种需求可以通过零信任来收敛权限降低风险；

• 需要防范内部：如果内部是要作为不可信源来进行防护，那么可以考虑零信任架构，因为它对内部权限，身份的识别以及管控会更加严格，可以全程回溯；

• 是APT的目标：如果有被针对性的长期攻击风险，可以考虑上零信任来加强安全防护能力，抵御攻击；

• 有钱有资源：土豪还有什么好说的，高大上的统统来就好，这样的公司让我们做朋友就好了！

（2）可以不用上的场景

• 为了远程办公：第一篇零信任远程办公文章发出去后，很多人找我咨询，因为疫情，公司需要远程办公，看了我的文章后考虑上零信任来解决远程办公需求，这里面其实有两个误区：

• 
  

• 疫情不是常态，社会秩序必然会尽快恢复正常，为了一次性偶发场景是否要大成本投入需要衡量；

• 很多公司并没有很强的安全需求，用VPN已经可以很好的解决办公需求了，有安全需求的通过VPN+云桌面等扩展方案，同样兼顾安全，如果是这类需求其实也可以衡量下成本；

• 追求新架构和新趋势：好的安全方案应该是贴合自己的场景去设计，新的不一定适合自己，追寻新趋势同时也意味着会引入不可预料的风险，因此追新不应该为优先原因；

（3）不要去上的场景

• 成本投入不足：零信任架构会需要改变公司的IT基础架构，改变业务，不管是技术还是管理都需要很大的改变，如果不能坚持长期投入，比如自研方式可能做到一半人走了，商采部署的方案到一半预算就被砍了，到时都会让公司利益受损；

• 运营能力不足：如上个章节所说，零信任其实会引入一些新的风险，比如集中化管控带来的安全内部的风险，单点故障风险，运营人员被入侵控制的风险，都会因为零信任架构的集中化模式，大大方便了黑客，所以缺乏好的运营和管理会导致更大的风险，而安全运营能力的建设，悲观的看很多公司并不具备好的运营能力。

结束语

这篇可能作为零信任实战系列的开篇文章会比较好，但因为整个零信任架构相对庞大，后续的文章，我会根据反馈的问题，参考大家关注点做排序，因此不一定是线性来写，但尽量会一篇文章说明一个或多个问题或是观点。

另外对于零信任并不会太过多去参考一些“标准”，实际在建设过程中也甚少参考，而是根据实际需求和场景结合资源来做，所以内容或是观点不一定是“标准”答案，大家可以带着辩证的态度去看，也欢迎找我探讨。

注：关于Google被APT触发了零信任项目等均为臆想与推断，并无内部一手消息。

参考：

互联网发展史 https://baike.baidu.com/item/互联网发展史/4635625

beyondcorp project研究论文 https://research.google.com/pubs/pub43231.html

历史文章

• 零信任架构实战系列：远程办公

• 硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

• 安全硬核招聘的总结与兑奖
  

如果觉得文章对你有价值，关注、转发是最好的支持，谢谢支持，素质三连！

扫描二维码

持续更新中

小议安全

阅读原文

跳转微信打开

对这次硬核招聘的一次总结，以及兑奖信息。

硬核

招聘

兑奖

总结

如果进来只是看看谁中奖，应该会很无趣吧，也挺浪费大家的时间的。公众号有个定位，希望都是原创，以及能有收获，因此即便是兑奖文，也努力去写点什么，希望能给带来点价值。

1

一次招聘实验

这次有奖招聘发起前，做了一些争取，因为这种社交招聘包括奖励方式，多少是打破了一些常规，很感谢公司、我的老板和HR们上上下下都很支持，很快就解决了流程、费用上的一些问题。

也正是因为这样，给自己带了一些压力和责任，也促使了我想换种方式来发招聘文章，做一次不一样的尝试，看是否会有不一样的结果。

传统的招聘文章大家都见的比较多了，主要形式基本是下面几点：

• 职位描述
• 能力需求描述
• 福利和薪资待遇
• 公司或团队的基本介绍

这种方式其实不错的，一目了然，也是常规做法，站在公司角度来告诉候选人，我需要什么，但不是从求职者角度来去提供信息。

在日常和候选人面试的时候，我一定会有的一个环节，就是介绍公司、业务、团队和对这个职位的定位，而且越是心仪的求职者越是会详细的来介绍。

这是为什么，几个观点：

• 面试就像相亲（某HRD总结），越透明越减少大家相互试错的成本，如同SDL；
• 对候选人负责，避免以模糊和忽悠的方式招过来后落差太大，虽然有时多少会渲染一些岗位前景；
• 对心仪的候选人，希望这个过程中能传达出自己的诚意。

而从得到的反馈来看，很多候选人是在意这些信息的，即便你不去介绍，往往也会主动问起。所以我想为什么不在招聘的时候先去提供这些信息呢？也就有了上一篇《硬核安全招聘》的文章。

在文中，把我觉得对选择安全团队重要的几个方面做了说明：

• 安全部门定位：主要想传达安全部门的发展方向，在公司的地位与业务关系，这些决定了团队自身是否得到重视，自身是否有能力去引领公司的安全建设，安全建设方式和候选人是否对路；

• 安全部门组织架构：部门的架构决定了分工安排，是做万精油，还是走专精方向，以及这个部门的发展阶段，通过这个地方应该都可以看出来；

• 招聘人员定位：所招的人过来后会具体做的事情，面临的挑战与成长机会，尤其是未来的成长目标。

简单的说，就是从公司角度、部门角度、个人角度做了系统化的一个介绍，希望候选人可以结合自身需求做个全面了解，有的放矢，另外也是想表达我们招人的诚意。

2

实际效果

那么实际效果如何？可以从两个方面来评价，一个是从文章传播来评价，因为是社交招聘，文章的阅读量决定了获取到信息的人数，第二个是从从实际招人角度来评估。

（1）招聘文章传播

发文前因为担心广告类的文章不好传播，毕竟大佬多，更不好意思让同为招人困惑的甲方安全大佬们去转发，所以还特别弄了个转发有奖活动。

从最终的结果来看，5天时间这篇文章的阅读量有5000多人，一共转发了300多次，而微信好友里面有500多位打开过（感谢各位好友）。

以安全公众号文章的角度来看，传播力度算中等水平？可以一定程度起到社交圈广而告之的作用了，但如果是以安全垂直行业的受众来看应该还是比较低的。

另外文章发布后受到了一些好评，会有些朋友特意过来鼓励（再次感谢）。

（2）招人效果

涉及公司招聘数据不便给出详细数据，总的来说有一定的效果，有热心（iPhone大法）朋友的推荐、也有看对眼立刻发出去的offer、也有互相没看对眼的，但总体上招聘还需继续努力，空缺还是很大。

3

总结

总结下个人看法，好的一面是这种方式会很真实，以比较坦诚、透明的去介绍我们，初始印象多少会有加分。

但从接收的推荐和简历数量来看，有一定效果，但并没有大幅增长，是低于我自己的预期的，所以实际的情况，可能这是一种自嗨，候选人最关心的，可能还是我在群里讨论时说的，“公司规模大不大，名头响不响，给的钱多不多是硬吸引力”。

但无论如何，应该还算是个不错的尝试，让大家多了解我们也好，顺便说一句，推荐人送手机这个活动持续有效。

如果你有不一样的看法，欢迎告诉我。

4

获奖名单

获奖名单如下图，用了公众号自带的分享统计功能，我自然是可以被剔除了，其他人会在明天，也就是周四联系大家确认地址，把奖品一一送出,尴尬的发现，需要中奖用户主动联系我。

往期推荐

1.零信任架构远程办公实战

2.硬核安全招聘，有干货有福利，还有顶配iPhone等你拿

3.完美世界招聘详细JD描述

感谢耐心看完，如果觉得有价值的话，还请帮忙“关注，点赞，转发”三连击，这会是最好的鼓励。

扫描二维码

关注安全原创

小议安全

阅读原文

跳转微信打开

对安全管理、架构、人员规划上的一些想法，以及对招聘岗位的定位，希望能带来价值。

安全部门的自我定位

一个公司对安全部门的定位应该是多方位的，不同视角对安全的期望和定位会有很大差异，会直接导致安全工作的开展，例如：

• 公司对安全的定位：不出事，少花钱应该是多数公司的定位，甚至是“不出事要你何用，出了事情要你何用”的尴尬定位；

• 业务对安全的定位：别搞我，少烦我，同样是多数业务部门的心声，轻者勉励配合，重则见安全如见瘟神。

这个时候安全对自我的定位就很重要了，上面都是客观存在的事实，但不代表正确，因为行业不一样，对安全的理解是不一样的，而安全负责人应该是要清楚的，这时的自我的定位往往决定了未来的方向，如果定位是救火队，最后可能会成为杰出的救火英雄，而我们的定位如下：

• 自我定位：服务业务、集中资源，统筹规划，翻译成人话就是业务优先，不能为了安全而让业务死掉（是的，我们不是安全第一），而集中资源，统筹规划是因为安全的成本并不低，集中资源和统筹才可以用尽量少的资源来获得较大的成效，安全需要考虑成本。

从结果上来看，按这个定位，一步步走下来是可以获得公司和业务的理解与支持。目前我们负责了全集团安全，通过集中化的平台以较低的成本输出各种安全服务来支撑业务，并不断的提高安全效率来让业务感受到安全是和业务一个方向，获得业务的理解和支持。

安全部门组织架构

我理解的安全组织架构并没有好坏、也没有标准之分，只有适合不适合，因为每个公司环境和发展阶段都不尽相同，我们的安全组织架构经历过三个阶段，如下：

（1）扁平化架构

其实就是穷，几个人的安全部还要什么组织架构不是。这个阶段的特点是每个人都身兼数职，安全运维、渗透、开发混在一起，大家工作起来也不分你我，效率其实不低，但问题是虽然能救火，但长远规划很难落地和做精，过了救火阶段后就不适合后面的阵地战了。

（2）攻、防、开发为模型架构

这个阶段特点因为资源相对充足点了，可以专人专事，而一般负责人的精力也不足以支撑超过10个以上同学了，因此这个阶段将部门以攻击、防御为视角进行了拆分，主要目的是：

• 明确职能，专人专事来保障结果与质量；

• 通过攻击团队来发现问题，以攻促防；

• 通过防守团队进行安全建设，构建防护体系，检验攻击效果；

• 通过开发团队来输出系统、平台，提供火力支援。

这个模式我们进行了很长一段时间，但后续问题也开始凸显，即评价体系难以落地，因为安全监控、响应分散在攻击和防守团队中，让自己评估自己是没有意义的。

（3）攻、防、检测、双开发模型

为了弥补裁判的问题，这个阶段将团队进行了进一步的拆分，将安全检测独立出来，负责安全分析、规则维护、事件调查与响应，以及将开发团队也拆分为两个小组，主要的目的如下：

• 形成，攻击、防护、检测的三角模型，三个部门可以互相检验和促进；
• 开发分为两个小组，分别为：
• 防护体系开发，即我们的零信任架构体系开发，支持防护体系的建设和提升；
• 检测体系开发，即我们的SOC、SADB、可视化分析等系统开发，支援安全分析能力的提升；
• 满足大家职业发展的需求，对管理方向的提供上升空间，技术方向提供专精空间。

招聘职位定位于分析

（北京地区）

这是篇硬核招聘文，这里是我们迫切要招的一些岗位，在这里对阐述下对这些岗位的定位与规划，当然最好的体验是加入我们！

（1）高级开发工程师

负责零信任体系中很非常重要的Linux agent、server端开发，我们的零信任定位是统一架构全端覆盖，包括服务器的覆盖，这个岗位会负责Linux端agent、server端的功能迭代。

游戏行业是会遇到真实的APT攻击，也会遇到很专业的rootkit、入侵手法，因此这个岗位在入侵检测技术对抗上会有很真实的挑战，以及会从攻，防，检测团队中获取一手需求与反馈来改进系统。

（2）业务安全工程师

游戏是完美世界核心业务之一，除此外我们还有很多互联网业务，因此在业务安全上，账号安全、薅羊毛、漏洞刷分等场景都会遇到。

这个岗位会借助我们统一分析平台的能力，协同业务，识别业务风险，建立风控模型，推动开发部门进一步完善平台能力。这部分的挑战在于，业务类型多变，如何找寻规则形成较为通用的方法，以及如何让安全数据发挥更大的价值。

（3）风控算法工程师

这个岗位是和业务安全工程师合作的岗位，即负责相关系统的开发。现有的SOC上我们已实现了实时、离线、机器学习、SOAR安全流程编排等能力，但在风控上还很薄弱，需要进一步丰富和完善风控模块和能力，给业务提供支撑。

另外借助零信任架构体系，安全解决了数据质量不高的痛点，可以形成完整的闭环，如何支撑这些海量数据的安全分析，更智能的关联，也是其中的挑战。

（4）渗透工程师

负责内网渗透、线上业务安全测试，通过内部红蓝对抗方式，推动安全运营能力的提升，用攻击来检验安全防守、分析团队的能力。

另外渗透工程师可以借助部门内的主、被动式扫描器，安全资产、钓鱼系统来提高攻击效率，以及将将重复性工作推动开发转为自动化的方式，让攻击测试也能效率化。

（5）安全运维工程师

负责零信任架构体系的实施、管理，运营。安全运维不是一个轻松的活，事实上充满了挑战，因为攻击团队只需要利用一个点就可以进行突破，而安全防守团队需要面对全集团数万设备，数百个业务系统的安全加固、权限管理、漏洞修复。

安全运维工程师一大方向是将繁琐重复性的工作转为自助和自动化，进而演变为以安全角度对业务整体环境进行评估，发现薄弱点并设计解决方案。毕竟没有人比安全运维工程师更懂业务。

（6）安全合规工程师

一直以来在合规上我们有着自己的想法，不请外部咨询顾问，所有的合规流程都自己走，这是因为合规本应该是安全最基本的要求。这里的挑战是如何找到业务和合规的平衡，保证合规的同时不要影响到业务的发展，将合规的需求融入到了安全体系、平台中，用系统来支撑合规。

这个阶段中我们希望把合规引导到数据安全方向，对合规的定位是对外、也对内，更要对自己，以合规推动标准化、数据安全系统化工程落地。

入职完美优劣势分析

任何一个选择都是有正有负，找到适合自己的是最重要的，因此我会从自己的视角尽量客观的分析入职完美安全的优劣势，希望对你的选择有所帮助：

（一）劣势

• 超大规模的场景：不是垄断型头部企业，没有春晚那类数亿人刷刷的超大场景，但有还算丰富的场景类型，安全各个领域都会涉及；（基础安全、渗透、移动安全、应急响应、业务安全、黑产等）

• 不成熟：无论是我自己还是系统、架构，我想是不如一线大厂的，事实上我们一直在不断试错，不断改进的路上；

（二）优势

• 讲人文关怀的公司：应该是少有让你每周都放下工作，强制你去学习的公司了，董事长对员工的成长关怀甚于你自己，公司氛围鼓励大家去尝试，去试错；

• 有理想的安全部门：追求卓越，希望真正解决公司安全问题的同时，可以提升自己，这也是为什么零信任架构、安全自动编排、等新技术，我们都乐于探索，并且有能力落地执行；

• 平等的工作氛围：没有森严的等级，勾心斗角的人际关系，有话直说既是完美的文化，也是部门的文化；

• 工作与生活的平衡：没有996、没有强制加班，只要结果棒，不加班年底绩效一样可以是S级；

• 友善的业务环境：没有山头、站队一说，业务普遍给予安全很大的支持与包容。（不然零信任架构也推不动...）

福利环节、福利福利福利

感谢你耐心的看到这里，写公众号是认真的，招聘是认真的，福利更是要认真，申请了两大福利：

（1）关注公众号,并转发有奖（3月18日 12:00截止）

• 转发本文，第一名，赠送完美世界 火炬之光游戏绝版大手办一个；

• 转发本文，第二、三名，赠送完美世界 姜小虎鼠年手办一个；

• 转发本文，第四 ～ 十名，赠送完美世界 好运茶二盒；

注：排名根据微信公众号后台统计数据，公平公正，需要先关注哦。

（2）推荐有奖（招满为止）

• 急招岗位：高级开发、业务安全、风控算法工程师，推荐入职后赠送 iPhone11 pro顶配

• 普招岗位：渗透、安全运维、合规工程师，推荐入职后赠送华为meta30 pro顶配

我叫何艺，甲方安全16年，目前负责完美世界安全工作，聚焦在安全管理、零信任架构、体系建设，安全架构和安全分析上，争取做个不走偏，服务型领导，欢迎加入我们。

欢迎推荐简历，邮箱：heyi@pwrd.com

也可微信直投：

相关链接：

（1）招聘JD详细介绍 （也可点击原文查看）

（2）零信任架构远程办公实战

“ 尝试开始多做一些输出，即便是招聘也希望能带来点价值，不要浪费大家时间，如果觉得有所价值，请素质三连，关注、点赞、转发，后续会提供更多原创内容来感谢大家的支持。”

长按扫码关注

阅读原文

跳转微信打开

这次我们把零信任架构真实的用到了大规模远程办公支持中，本文即是对这一次实战的总结，希望对评估零信任架构的人有所帮助。

前言

受当前疫情影响，大部分互联网公司都进入了远程办公模式，同时给安全也带来了很多挑战，安全边界被打破，数据安全风险，权限管控无序，蠕虫的蔓延，黑客的攻击，核心业务被暴露等等......

相对应的是很多安全公司也提出了远程办公安全解决方案，零信任架构是其中一个热门话题，也有很多人在问，什么是零信任架构，它真的能解决上面的问题吗，是否如宣传所言可以几小时内极速上线？

我们因为零信任架构项目启动较早已闭环上线运行，这次也借这个契机，集团全面推行了零信任架构远程办公模式，本文则是对这次实战的一次总结，希望对大家评估零信任远程办公方案时有所帮助。

零信任架构简介

零信任并不是一个新概念，早在2010年的时候Forrester的 John kindervag就提出了zero trust architecture理念,希望可以解决传统边界安全带来的问题，之后又有云安全联盟的软件定义边界（SDP）模型，以及google的beyondcorp project以各自不同的思想来实践，直到ISC2018大会后该理念在国内迅速传播开来，并越来越受到行业重视，在这里对这几类架构进行简单介绍，便于后续内容理解。

（1）Zero trust architecture（ZTA）

ZTA在2010年提出的时候，是希望可以解决传统边界安全模型无法防御内部威胁，或是被突破边界后的威胁而提出，主要的思想是在网络层，将网络尽可能小的分段，并通过隔离网关来控制出入流量，并辅以其他安全能力来减少传统边界被突破后的风险，类似于网络微隔离。

在实现上ZTA提议将交换机扁平化便于弹性扩展，以中心化、集中化的模式进行统一管理。在网关中对网络数据实现可视分析能力，并整合传统内容过滤、访问控制、数据防泄密、web应用防火墙等能力在隔离网关上。

以现在的眼光来看，2010年的ZTA可以看作是对传统网络安全模型的一次架构升级，本质上区别并不大，只是网络层面上划分的更细，功能整合的更多，和现在我们所谈的零信任架构的核心思想还是有比较大的区别的。

（2）软件定义边界（SDP）

2013年云安全联盟推出了软件定义边界(SDP)模型，该模型抽象了client、controller、gateway、resources等几类角色，主要思想是引入了对身份和设备的识别校验，通过controller统一授权后，将访问请求调度给SDP网关来对后面保护的资源进行访问。

在SDP中参与安全控制的核心角色是前三类，分别承担的主要功能如下：

• client：部署在用户终端处，负责对设备和人的认证授权；

• controller：SDP的核心认证、评估和策略管理中心，由它来分配资源；

• Gateway：受保护资源的防护节点，负责隧道的加密、访问控制来实现对后面的资源保护。

一次完整的访问过程是需要经过授权的client经controller认证以及评估安全性后，分配到指定的gateway上通过加密方式访问后面的资源，可以对网络到上层应用进行全面保护，云安全联盟也试图通过这种架构来解决不同的云安全模式，例如SaaS、PaaS的场景。

SDP是实际上得到了很多厂家支持的方案，很多网络安全设备公司出的零信任解决方案大多来自SDP的模型。

（3）Google beyondcorp Project

google的beyondcorp应该是业界第一个真正落实零信任架构的公司，并在14年开始将该项目以白皮书方式陆续发表，在byondcorp里面，明确了用户、设备、应用的安全关系，通过以不信任的持续鉴权模式来建立可信链条，从而允许访问后面的业务，在这里面有几个核心要素：

• 信任机制建立：即可信的设备、用户和应用，只有三者建立了可信关系后，才可以对后面的资源进行访问；

• 动态安全评估：即安全是动态变化的过程，因此对于上面三个因素是否安全这个评估应该也是动态进行，一旦发现不安全后会采取降低，禁用等方式来防范或止损；

• 安全不分内外网：即是否安全不取决于你处于内网还是公网，无论内网应相同对待和相同安全，这是基于这个原因同时结合远程办公需求，google通过beyondcorp实现了远程办公需求，也是这次我们参考的对象。

我们的零信任架构

我们的零信任架构实践是从15年开始调研，16年分阶段开发，用了较长时间来摸索和一步步落地闭环。在架构上主要是参考了google的beyondcorp project，同时结合了公司安全其他需求，以及自己的一些安全理念，整体架构如下：

核心思想同样是建立基于用户、设备、应用的三者信任链，以及动态的安全评估机制，在架构设计上按照分层思想设计，即在网络层、主机层、应用层上分别设有三套独立的系统，系统可以独立其他系统运行，也可以系统之间进行联动，通过联动来实现更强的安全防护能力。

后端服务中有统一的用户目录服务、PKI体系和OTP认证等系统，来支持设备、人、应用的多因素鉴权，结合系统对零信任架构体系闭环，里面几个核心系统主要功能是：

• 网络安全管理系统：负责网络边界ACL管控和网络准入控制，联动主机安全和应用安全系统，实现经认证的设备的入网和不安全隔离控制；

• 主机安全管理系统：安装在windows、mac、移动终端上的agent和主机安全网关，实现人和设备的信任关系建立，设备安全状态的检查，漏洞的修复处理等功能；

• 应用安全管理系统：包含web安全网关、策略服务器，负责对web资源的保护与授权，对符合user->device->appliction信任链的请求放行。

此外还有一些核心辅助系统，SADB、SOC等系统，来实现更复杂的动态安全分析检测等能力，因为这次重点在远程办公实践，因此不过多讲解。

与VPN方案的对比

（1）SSL VPN方案简介

VPN是非常古老但又很有效的远程办公方案，原理是客户端通过internet与公司的VPN网关建立隧道，形成一个被加密后的安全虚拟网络，在零信任架构并不热门之前，哪怕是现在，应该也是绝大部分公司的远程办公首选。

注：VPN方案有多种，其中SSL VPN通常为多数公司用于员工远程办公方案，本文中VPN方案均指SSL VPN。

（2）SSL VPN方案安全分析

为了有助理解VPN和零信任在远程办公安全上的区别，画了两者访问流程图进行说明，下面是VPN方式对资源的请求过程，大体可以分为鉴权建立隧道和资源访问两个阶段：

1. 鉴权阶段：登陆VPN虚拟网关，对账号进行鉴权后建立SSL VPN隧道并下发IP和路由（网关模式）；

2. 资源访问阶段：认证通过建立隧道后，以后对业务的访问不需要再次鉴权，由VPN网关转发业务请求报文来实现对内网资源的访问。

VPN方案在安全上的考虑主要有三点：

1. 对账号的鉴权；

2. 会话隧道的加密安全；

3. 基于IP和端口的网络层权限控制。

（2）零信任架构方案安全分析

零信任架构对资源的访问过程，有鉴权和资源请求两个阶段，但这里会有明显不一样的安全考虑与区别，如下：

1. 鉴权阶段：对设备、账号、应用的信任链进行鉴权，通过后建立SSL双向加密会话；

2. 资源访问阶段：每一次对资源的请求，需要重走鉴权阶段进行重新鉴权，如果这个过程中发现了变化会禁止对资源的访问，资源访问方式由web网关进行转发。

零信任架构在安全上的控制主要有下面几点：

1. 不再仅基于账号进行鉴权，而是账号、设备、应用三者的权限关系；

2. 每次对资源的访问都是重新鉴权的过程，即零信任；

3. 用户终端纳入安全评估中，终端安全风险可以被控制；

4. 保障会话过程中的加密安全；

5. 基于应用权限进行控制，可以实现更低颗粒度度控制；

（3）对比总结

在VPN方案很成熟的今天为什么要考虑新方案，我想最大的原因还是在于安全性上。VPN方案是来自传统边界安全思想，在安全有很多缺点，比如仅对账号进行鉴权，对客户端的安全无法控制，以及一次鉴权后之后的访问就畅通无阻了，还有管控规则过于粗放等问题。

下面的问题是，使用零信任架构是否又真的能解决这些问题？又会带来哪些问题？是否真的适合远程办公？

零信任远程办公方案实施

整个远程办公方案的实施实际留给我们的只有2、3天时间，整个过程上来说还是遵照了需求分析、方案准备和实施三个步骤。

（1）需求分析

再怎么完美的安全方案如果不能解决远程办公需求，其实是没有任何意义的。对远程办公需求根据我们的场景可以归为两大类，如下：

通用办公需求

• 即时通讯沟通类：通过即时通讯类系统进行内部沟通、会议；

• 内部网站访问类：访问公司内的OA、WIKI等内部系统；

• 移动办公类：流程审批、通知公告、信息登记等。

特殊需求

• 开发环境访问类：数据库访问、测试环境访问、测试系统访问等；

• 远程系统管理类：服务器维护、远程办公PC访问等。

同时这些需求带给安全的风险与挑战有下面几大类

• 需要较高的质量来保证远程办公体验；

• 短时间大量用户集中远程办公，VPN设备需要有较强的处理能力；

• 员工远程办公环境的风险不可控，不能确定是否会有病毒、蠕虫或攻击进来；

• 企业数据可能会落地到个人设备中，这个设备可能是借的三大姑七大姨，数据安全难以控制。

（2）方案准备

上述需求中，零信任架构大部分是容易解决的，但也有解决成本比较高的，主要难点在即时通讯类的商业产品整合上，以及一些复杂的开发需求上，如下：

• 即时通讯沟通类：增强多因素认证，可用但不完美的支持；

• 内部网站访问类：http类业务通过安全网关，完美支持；

• 移动办公类：整合到了架构中的安全app上，完美支持；

• 开发环境访问类：特殊需求较多，对无法代理的业务难以支持；

• 远程系统管理类：以http协议over方式整合到架构中，相对较好支持。

从上述可以看到，当前我们的零信任架构可以解决大部分办公需求，但是并不能完全解决所有远程办公需求，所以实际工作中我们零信任和VPN两套方案都有上线，用于满足不同的业务需求。

（3）方案实施

在实施阶段需要做的工作，主要是把架构对互联网开放，大部分人力上的工作是在对用户的引导和支持上。针对这些问题，我们做了很多指南还有一些流程自动化的工作来应对同时支撑大量用户的办公接入。

从员工角度来看，需要做的就是按照指引安装agent，认证激活后和在公司内一样，正常去使用业务系统。

实践效果与问题

自方案上线后已经有1个多月了，整体上经受住了考验，因为同时上线了两套方案，对两类方案的优劣势也有了更多体会。

（1）VPN方案的优缺点

VPN优点：

• 可以满足所有远程办公需求

• 使用简单

VPN缺点：

• 处理性能局限：VPN商业设备处理有局限，例如可支持的加密带宽不能超过xxxM，形成瓶颈；

• 难以快速扩容：因为涉及设备采购，上下线网络设备兼容性，紧急情况下扩容难度较大；

• 网络质量要求较高：VPN模式如果网络质量不佳，很容易引起VPN中断，导致所有的会话全部中断，很影响用户体验；

• 安全风险不易控制：VPN模式决定了安全边界在VPN网关上，对于客户端发生的安全事件是无感也无法控制。

（2）零信任架构的优缺点

零信任架构优点：

• 处理能力强：网关主要处理的是HTTP协议，用普通服务器即可，可以有很好的处理能力；

• 可快速扩容：使用LVS等负载均衡方案，可以快速横向或纵向扩容；

• 网络质量要求低：因为不是建立隧道，而是基于HTTPS的请求，网络质量不高的时候不会引起所有会话全部中断；

• 安全控制力强：零信任架构中安全的边界在用户终端上，有更强的控制和感知能力；

• 使用“简单”：用户认证授权完后，对用户的打扰较少，但这个依赖agent设计能力，设计不好会带来更大的用户使用成本。

零信任架构缺点：

• 一些特殊的远程办公需求难以满足，或是要花费很大成本来实现，例如不支持代理的C/S应用，一些特定的协议访问等

（3）其他的问题

这是第一次安全部门来主导大规模远程办公的支持，有很多意想不到的事情，例如：

• 20%不看帮助的用户，占用了80%的人力支出；

• 直面用户，安全工程师要承担很多低价值的热线工作；

• 墨菲定律一定会发生；

• 解决一个问题的同时，也会带来新的问题。

结束语

综上，从实际运行的情况来看，零信任架构无疑在安全上能带来很多优势，甚至用户使用上也是可以很简单，并且是可以真正落地，让用户去使用的方案。

但同时零信任架构的远程办公部署，应该是要提前准备好的事情，绝非短时间可以上线的方案，所以我很难相信能像一些厂家广告宣传一样，快速上线。

另外一方面，如果想用令信任架构取代VPN，要看公司的办公需求还有公司自身的技术能力，因为5% - 10%的特殊需求可能要花费很大的成本才可以转化上去。

硬广时间

（1）招人、招人、招人

我们团队正在招人，氛围不错，鼓励创新，有很强开发能力，也资源和环境，人际关系平等，没有996。如果你想成长，一起做更有价值的事情，真心欢迎加入我们，岗位JD，联系方式可扫码了解。

（2）完美SRC的双倍活动正在搞起，如果是发现我们零信任架构漏洞，更有额外奖励，欢迎大家来挖。

最后祝大家百毒不侵！

阅读原文

跳转微信打开

庚子之年，回首过去入安全这行已16年，从小兵到负责集团安全，还记得第一次面试时的忐忑，担心经验不够，无法证明

庚子之年，回首过去入安全这行已16年，从小兵到负责集团安全，还记得第一次面试时的忐忑，担心经验不够，无法证明自己，真等年限变长后，反而越发觉得工作经验说明不了什么，你做过什么，带来过什么价值，是个什么样的人才是最好的证明。

尝试写公众号，既是希望对过去的经验有所总结，更是希望自己能进步，放空，才能更好的吸收。如果我写的对你有所帮助，请告诉我，那会是很好的认可。

如果想深入交流，或是过来加入我们，欢迎加我微信。

阅读原文

跳转微信打开