注：上期精彩内容请点击：如何安全部署蜜罐；安全告警处置的制度及规范

话题一：

企业在实施零信任安全体系中可能会遇到挑战和困难，如员工教育宣传、系统集成和部署复杂等问题，对此大家有什么好的解决方案和建议？

A1：

我们遇到的更多的是对现有系统的改造，可以理解成就是集成部署的问题，这要是按照规矩实现零信任，要做的工作是真不少的。

A2：

系统集成和部署复杂这点根本不用担心的， 一般都是供应商做的。员工教育宣传，可以公开培训， 录个PPT， 现在员工很多都用过Citrix Workspace这种，不算白纸。

A3：

在设计阶段，可能需要结合公司实际情况，零信任方案是否可以给员工带来方便，例如是否给员工的很多远程场景带来操作体验上的便利，厂商外部维护等第三方接入场景是否更简便规范，员工电脑端是否可以安装更少的Agent，如果可以做到的话，其实是可以有内部驱动力去推零信任的；

在实施阶段，需要考虑用户认证是否有单一的信任来源，是否有持续维护的资产库，看是否具备一些实施零信任的基础条件，基础初步具备后，然后对于不同系统进行分类，规划有端与无端的方案，循序渐进做对接，可以从安全自己管的系统开始做，再到业务影响最小的系统开始做，逐步覆盖面向员工侧的系统。

A4：

我觉得技术上的解决方案不是难度，每个企业的落地方案都不一样，最好的方式是落地在企业信息安全的平衡点上，也就是了解企业需要实现这个零信任的基本盘。零信任也不是不信任，而是减少用户的信任交互成本，减少的成本就是信息安全投入的成本，在这个的信任交互成本里面可以从认证授权、MFA、权限分离、访问轨迹跟踪和识别来实现，安全每增加一个信任计算，成本就要增加，用户的感知交互就会减少，用户学习成本就会降低。

A5：

权限收紧是个艰难且看老板的事情，大部分就当VPN用就好了吧，也没啥特殊的。

A6：

我们做的比较传统，主要还是严格的内外网与堡垒机+跳板机实施的，这样可能会降低一点效率，但是对于规模不大的情况来说，确实挺皮实的，这样操作就可以不用操心后面的系统集成与部署问题。

前公司到是号称实施了零信任，但就是各种关键操作时不停的发验证码，我感觉一切安全基于验证码。

A7：

我这遇到的问题是业务目标与安全目标不一致；员工教育的话先推行攻防演练或者漏洞挖掘竞赛，然后针对发现问题，进行员工教育。部署的话尝试与业务纵横联动，解决安全风险。以前和厂商推进过这种模式，后续问题一言难尽，比如业务密码容易猜，跳板机能够登录其他业务服务器；外网堡垒机被打穿，所有堡垒机可访问,业务卒；堡垒机账号共用问题等等。

Q：零信任安全体系在建设时如何与现有安全体系衔接协同，以达到更好的安全保护效果？

A8：

其实这个问题不存在，两张图说明下：

现有安全体系大多数都是这样的：

上了零信任以后，如果零信任稳定投入使用的话，基本传统安全体系都要废掉的。这个问题好比，开特斯拉，怎么维持开燃油车的手动排档？

A9：

首先要明确零信任的卡点位置，卡VPN或者SSO、云桌面？然后就是与业务系统对接卡点系统的事情（需要开发还是乙方厂商支持），最后就是近源问题（DMZ区域划分与策略）。

举个例子，使用云桌面卡点，所有运维登录必须连接VPN（带硬Token）然后使用云桌面，登录云桌面后再登录堡垒机。业务服务器与测试服务器使用网闸隔离，数据库放防泄漏。各家场景不同，用的方案也不同。

A10：

互联网方案一般是SSO作为统一入口，不分内外网。运维走堡垒机通混合云，办公网终端管理为证书入网，VPN为商业产品，建立超级APP（带多因素认证）作为应用汇总。

Q：在混合云和多云环境中，数据传递和接口调用等场景往往面临更多的安全风险，如何利用零信任模型来保证云环境业务的安全性？

A11：

点对点鉴权，身份倒是可以保障，传输安全就不好说了。

A12：

访问控制进一步精细化，限制生产应用的访问权限。或者终端All in one，实现多个数据采集和风险自动处置。

A13：

其实从终端去入手，结合上面顶层设计会更简单高效，因为上层是已经建设过了，不需要重复投资，只需要在终端就是底层地块建设就行，能实现效果就好。

A14：

现在有IAM统一登录，Web系统访问都到IAM进行认证，改造成SDP+IAM的情况，怎么让Web流量都过SDP的网关呢，通过DNS调度吗？

A15：

是的，有些产品针对域名会做DNS解析引流到SDP网管。解析引流，可能更准确的说叫劫持。

A16：

零信任安全体系，我理解就是我对所有人都不相信，如果将这个想法融入到建设中来。

再说俗点，我身份机制怎么建立。对于不同安全域之前的访问都会有你是谁？怎么证明？所有安全域访问应用之前都会有你是谁？怎么证明？只要梳理清楚资产，然后看怎么加入你是谁、怎么证明的产品，就搞定了啊。

A17：

实施分为两步：

1.应用、业务、办公等等解耦；

2.引入产品加入流程。

难点也比较明显，业务如何解耦，该怎么做，为什么？引入的产品卡入什么流程，为什么卡这里？有可能部分企业做不到这种，那就要按照企业实际情况而定了。

A18：

其实最难的是推动，目前因为历史原因太多的弱口令，SSO也只有口令登录，计划先OTP双因素，再逐步结合SDP，内部一顿沟通，推行困难很大。大家都喜欢简单的方式，特别是传统行业。

A19：

API 管理一直是企业非常难搞的坑，加上Token虽然方便使用，但是研发用于小测试脚本，脚本泄露容易造成Token丢失，Token的丢失也就意味着API权限和数据泄露。

企业常用Yapi框架，或者二开其他框架解决Token时效问题。阿帕奇基金会推出Apisix项目可用于解决K8S API问题的开源方案（项目不成熟谨慎测试）。

A20：

像是AK/SK一般企业对于密钥管理不规范很难受，不少企业都吃过AK/SK泄露，导致阿里云/腾讯云失陷。

这是源于企业对于API安全理解不到位，AK/SK申请无正规流程，AK/SK无回收机制，等等原因导致。

这点是否能利用零信任模型来覆盖，还有待商议。

A21：

AK/SK？可以参考CIS benchmarks里的要求，结合权限治理来弄。

其实基线里的已经很全面了，比如控制台登录权和API调用分开、单独用RAM账户授权而非授权给角色。

举几个例子：

1.避免将"Root"账号用作日常使用（必须）：“Root”账户是云账户下资源的所有者。该账户并具有对资源的完全控制权限。最小化使用此账户，并采用最小权限原则进行访问管理，可以减少意外或未经授权的更改以及特权凭据的泄露风险。

2.避免使用主账号访问密钥Access Keys（必须）：删除与“Root”用户帐户关联的访问密钥可以限制攻击者入侵账户的方式。此外，删除“Root”访问密钥可以鼓励创建和使用基于角色的帐户，并建议基于最小化权限原则进行配置。

3.保RAM 策略只附加给组或Roles，而不是用户。

4.确保任何单个IAM用户只有一个可用的Access key（必须）：Access keys是IAM用户的长期凭证。保护账户的最佳方法之一是不允许用户拥有多个访问密钥。

阿里云基线、AWS基线、华为云基线都或多或少提到过的，我这个云基线文档也只是针对这些做个精简和汇总。具体身份权限配置要求的从这里扩展一下就差不多能发制度规范了。

A22：

Root应该禁用，创建应急超管用户，或者创建一个只具备Sudo权限的，用于调试安装 。或者限制Sudo能力，把配置权限、安装权限进一步细化，或者直接特权账号管理类工具接管超级用户。

但是量大就不能这么玩。几百台机器可以这么干，不然维护Root密码就是个大问题，维护人员本身会成为风险点。

话题二：

在业务信息安全的规划上，量化的目标有哪些呢？比如今年抵御90%无差别攻击，那么那么明年呢？

A1：

伪命题啊，这是给自己套坑，还不如算漏洞发现修复这种量化。

A2：

安全这种不敢打包票，做内部的安全治理，搞点在可控范围内的，像完成多少业务系统安全测试啥的。

A3：

我认为体现安全量化目标，应该从漏洞发现数量/修复数量包含高中低发现数量/修复数量，上线检测总量/已完成上线数量，代码审计数量/已整改代码数量，告警数量/处理告警数量，应急响应事件/处理事件数量，反正你们有啥数据都可以做，数据少就细化。

A4：

能发现的才能量化、外部攻击类的只要被人打穿一次就完蛋了，量化啥？

A5：

不要给出准确值，打包票这种风险太大了，就是安全规划建设，也没人敢说，今年的规划一定就能完成所有的工作。

A6：

规划的范围大概分管理、技术、运营，管理、技术就提定性的内容，运营的内容就容易量化。

Q：大家有没有安全顶层设计的方案思路供参考？

A7：

指的是业务安全、IT还是其他？

A8：

是IT，我们企业的信息安全顶层设计。

A9：

这个问题，应该是企业整个大安全的顶层设计，包括合规体系、运营、网络安全、备份、数据、认证、终端等等这些。

A10：

这个业务安全也涉及呀，还有打印机安全，上网准入这些，这块我们理解为IT安全。

A11：

业务安全包含在整体的SDLC管理里面，从建设的生命周期来进行管理，里面会包含一些合规要求的，不过很难做到的。这些包含在哑终端，以及网络里面做。

A12：

这块很大，很杂，理解的范畴也不太一样。

A13：

是的，每一块很大，不过做顶层设计，就不会太细致，但是会大致要求规范好，给出建设路径。

A14：

SDLC是一个大框，很多安全都能通过SDLC做整个周期的闭环。

A15：

一般还是有脉络可寻的，从企业的第一步合规体系搭建（底层理论支持），安全边界搭建、安全运营设计、应用安全、数据安全、终端安全、身份认证管理，一步一步推进，由合规到外部，由外部转内部，内部转细节，基本也就这些，放到任何一个企业都有一定通用性的。

A16：

但是目的呢？打个比方，应用安全和安全运营的最终目的是不是抵御风险？

A17：

不单单是抵御风险，更多是主动去发现、防御风险。

A18：

主动发现和防御风险，目的也是抵御风险？这个可以量化吗？

A19：

可以量化，量化指标主要就是SDLC发现的漏洞及检测风险。

A20：

目的也是为了抵御风险，在做之前，并不知道能发现多少漏洞和风险。

A21：

所以做了之后以及持续运营之后的一个量化数据对比，那你不做永远不能发现风险，当然方案永远是方案，真正在做也都是选择性做的。

A22：

先做过程控制，再针对卡点设指标。

A23：

实际过程中肯定是一样一样推进的，但是都是有路线可循的，有些可以先做，可以后做，看企业情况选择。

A24：

路线图都是虚的，把要做的项目放进去。

A25：

肯定会实际填充的具体的工作，但是顶层设计肯定不会太过于细致的。

A26：

大部分路线图所有企业都能套，但是落地价值没有，为自己企业做量身定制的路线图就需要把项目放进去，至少充实PPT吧，领导其实关注这个。

A27：

这个就是细化工作内容了，根据实际以及问题，能做哪些事情，规划哪些事。

其实顶层设计方案就像画饼一样的设计方案，给那些领导看，我能最终能做完的大致样子，其中也会提及给企业带来的一些价值，然后在搭配实际工作内容。

零信任始终是近年来网络安全行业的热门话题，对于在实施过程中遇到的挑战和困难，由于每个企业落地方案不同，需要掌握好企业信息安全的平衡点，了解企业需要实现零信任的基本盘，减少用户、员工的信任交互成本，从而降低学习零信任的成本。

本期话题还聊到了安全顶层设计的方案思路，总体而言，需要在不单单抵御风险的基础上进行设计，还需要去主动发现、防御风险，从合规体系搭建开始，由合规到外部，由外部转内部，内部转细节。可通过SDLC对漏洞及检测风险指标进行量化。

本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！

【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】

注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员

“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。

FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：

金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理  

运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监