实施零信任的困难和挑战；安全顶层设计思路探讨 | FB甲方群话题讨论
▎各位 Buffer 晚上好，FreeBuf 甲方群话题讨论第 210期来了！FB甲方社群不定期围绕安全热点事件、前沿技术、运营体系建设等话题展开讨论，Kiki 群助手每周整理精华、干货讨论内容，为您提供一手价值信息。
注：上期精彩内容请点击：如何安全部署蜜罐；安全告警处置的制度及规范
本期话题抢先看
1. 企业在实施零信任安全体系中可能遇到哪些挑战和困难？
2. 在混合云和多云环境中如何利用零信任模型来保证云环境业务的安全性？
3. 在业务信息安全的规划上，量化的目标有哪些呢？
4. 安全顶层设计方案思路探讨
话题一：
企业在实施零信任安全体系中可能会遇到挑战和困难，如员工教育宣传、系统集成和部署复杂等问题，对此大家有什么好的解决方案和建议？
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：
这个就是细化工作内容了，根据实际以及问题，能做哪些事情，规划哪些事。
其实顶层设计方案就像画饼一样的设计方案，给那些领导看，我能最终能做完的大致样子，其中也会提及给企业带来的一些价值，然后在搭配实际工作内容。
FreeBuf 观点总结
零信任始终是近年来网络安全行业的热门话题，对于在实施过程中遇到的挑战和困难，由于每个企业落地方案不同，需要掌握好企业信息安全的平衡点，了解企业需要实现零信任的基本盘，减少用户、员工的信任交互成本，从而降低学习零信任的成本。
本期话题还聊到了安全顶层设计的方案思路，总体而言，需要在不单单抵御风险的基础上进行设计，还需要去主动发现、防御风险，从合规体系搭建开始，由合规到外部，由外部转内部，内部转细节。可通过SDLC对漏洞及检测风险指标进行量化。
本期话题讨论到此结束啦~此外，FreeBuf甲方社群每周开展不同的话题讨论，快来扫码加入我们吧！
【申请流程：扫码申请-后台审核（2-5个工作日）-邮件通知-加入社群】
注：目前1群、2群已满，如有疑问，也可添加Kiki群助手微信：freebuf1024，备注：甲方会员
“FreeBuf甲方群”帮会已建立，该帮会以三大甲方社群为基础，连接1100+甲方，持续不断输出、汇总各行业知识干货，打造网安行业甲方专属资料留存地。现“FreeBuf甲方群”帮会限时开放加入端口，让我们一同加入，共同建设帮会内容体系，丰富学习交流地。
FreeBuf甲方群成员（因篇幅限制仅展现部分行业成员）：
金融行业：贝宝金融 安全负责人、成都农商银行 信息安全负责人、晋商银行 安全负责人、北京银行 安全负责人、君龙人寿 技术负责人、合合信息 合规负责人、合生 信息安全负责人、航天产业投资基金IT负责人、工银金融 信息安全负责人、前海联合基金 信息安全负责人、天弘基金 安全负责人、阳光保险 信息安全部负责人、南京证券 安全负责人、宝马金融 信息安全经理
运营商：中国联通 网络安全主管、中国电信 信息安全技术主管、上海电信 网络安全主管、天津电信SOC主管、太平洋电信 研发总监
精彩推荐