重大演练活动期间大佬们在讨论些什么...?| 总第158周

0x1 本周话题TOP2

话题1：各位好，请教一个问题，运维部门通过堡垒机访问生产系统，都是1对1的堡垒机么，因为堡垒机license限制，采用通过堡垒机+跳板机的方式，进行运维操作，堡垒机应该都可以记录所有情况吧，和1对1添加堡垒机有什么区别吗？

A1：跳板机不好做内容审计，都是录屏的数据，而且审计溯源的话没那么容易。另外还有一点，跳板机的话，账号密码是不受控的。跳板机容易失控

A2：主机运维的同事，嫌堡垒机一台一台跳太慢了。喜欢自己搞个跳板机。用ssh免密登录。想深度pk运维，就推1对1，如果不想的话，走跳板机也忍了吧

A3：他们人员是大头。不光是主机，还有网络的，dba的，都有这个问题

A4：不用跳板机，权限变更会非常频繁。运维保连续性，业务优先，安全第二

A5：你们堡垒机有将网络也纳入吗？还是网络又搞一个3A或4A？

A6：dba管那么多库，网络管那么多设备，让他一个一个走堡垒机，他们估计弄死安全的心都有了

A7：目前我们运维也想弄堡垒机+跳板机，我不想答应

A8：我觉得最好的是明确责任，运维老大自己定，出问题别找安全。也不全是矛盾。 比如堡垒机托管了所有服务器和网络设备密码，这一点也减轻了运维不小的压力

A9：他们用ssh免密，也不用密码登录。安全pk运维、安全pk开发、安全pk业务，这么多都要pk，主攻方向在哪？看看自己的人员、级别、老板的厌恶程度，再看看自己能不能pk赢吧

A10：其实想着pk 争个输赢，这个出发点我觉得就错了。就直接把俩部门按到对立面去了

A11：让别人按照咱们的想法行事，能这么简单，不pk能推下去？

A12：那为什么要按照咱们的想法？咱们的想法就一定是对的？他们就不能有自己的想法？

A13：运维想用跳板机，安全不想给呀。听谁的。两个都有道理。那就看看有没有什么办法能解决

A14：一个为了效率，一个为了安全。两者把理由充分描述清楚，看看有没有更好的方案，如果找不到，只能上升到共同的老板那里决策了。吵架是真的难受，事情越推越难。我觉得解决方案就是一方的妥协

A15：嗯，主要是没必要以输赢的观点去干这事。否则对方妥协觉得自己赢了，或者自己妥协觉得自己输了，心里还难过。得从根本上解决问题，研发为啥要上生产，把这部分需求解决了，堡垒机大部分压力就下来了。剩下的风险分类解决。这肯定是核心运维人员的需求

A16：我了解很多人上生产就看看日志。弄一个日志中心在线查看，解决大部分需求。当然日志中心也是一个坑。

A17：研发不会给跳板机的。运维那是刚需，还是得满足。运维人数一般可控。

A18：感谢各位的回答，看来是一个常见的痛点问题，我现在是IT风险+IT审计，去PK安全+运维，安全反馈（1）1对1成本高，并且堡垒机有license限制了（2）也可以录屏录像有记录。运维认为1对1可以，让安全去要求（但是我觉得运维也是说说，用跳板机方便很多）。

A19：把运维的需求也拆分一下，能白屏化的白屏化，这样运维很多事情也不用等堡垒机了。

A20：请教白屏化就是说的自动化运维吧，公司运维成熟度估计还没那么高

A21：白屏化，就是web页面使用。这样就不用登录系统底层了。登录生产的人越多，风险面越大，安全越不可管控。光正常操作带来的误报，就会让安全监控同学裂。

A22：这个涉及到运维体系建设方面了，我们可以从整体上给方向性建议，具体方案还得运维自己拿了。白屏化WBE页面使用，是为了满足研发和业务同事吧，运维自己白屏化的多么，有哪些工作可以白屏化，能否帮忙举例说说

A23：安全越到后面越是一个体系化的活，体系化不单是指安全自身的体系化，而是要和业务结合起来，业务自身的能力会直接影响到安全能力。 比如跳板机，初级的是控制跳板机安全，高级点会还会控制跳板机到服务器安全，但更高级点，是业务基本不需要用跳板机，运维管理全部靠系统来做，安全是对接到这个系统上，控制这个系统的过程安全。

A24：就拿跳板机这个例子，咱们之前不还是独立的空间运维吗。越做对于攻击的门槛越高

A25：当科技能力成熟度未达到一定高度的时候，只能根据现状调整安全方案，找到相互能否接受的平衡点

A26：已经没了，效率太低，后来开始往上面说的系统方向去做了，运维走自动化，安全去控制设计和过程的安全，减少跳板机的使用，这样用的人少了，对抗也转移了。鸟哥我后来有个很深的体会，安全真的不能为了安全而安全，一定要考虑业务效率，结合业务去做，安全去支撑业务，这样大家都爽，业务也会当你是自己人，很多事情也就好做了。

A27：看公司是合规驱动、业务驱动、或者事件驱动，安全人员做好选择。还是看老板的态度，给100快钱投入，让达到10000快的效果，出了问题，还按10000快的标准要求到处打板子，最后就是it人员的内卷了。最后发现都是政策驱动、考核导向驱动。

A28：大概是因为基于自身利益价值判断而不是企业利益价值判断吧

A29：在国有企业的安全建设中，听得最多的一句话叫尽职免责，但事实上这个尽职免责的程度很难界定，尽好大的职免好大的责，没得易量化的指标，安全工作的实质还是以风险为底线的，御外容易防内难，牵扯的方面太多了……

A30：这种我总感觉是有风险的，如果仅仅考虑政策驱动，考核驱动，最后的结果其实就是合规、不担责任就行，安全能力的建设反而没那么重要，但合规和不担责不代表不会出事，安全如果更进取，把业务弄好了，个人前景和位置才更稳吧。

A31：政策是安全建设资源的源动力，考核是安全建设落地的源动力，这两者如果都没有，企业的安全建设可能没办法开展，我没有表达过安全建设不重要，而是以风险底线的建设才符合企业发展的方向，个人认为最后企业的安全管理很可能会朝着合规的方向演进，等保就是安全合规的最直接体现。

A32：本质上说安全是个业务属性，或业务品质属性，业务本身没有发展或效益，你去追求这个品质属性的成本就经济效益不太好，经济效益问题会从根本上制约你对这个品质的追求。政策也好，考核也好，实质上是个强经济效益指标。投资收益比的核心问题

A33：安全然则还有一种属性，ZZ站位属性。所以安全得做，必须做，但也必须考虑投资收益比的问题……所谓ZZ属性，最后还是要换算成经济因素的，在选择取舍的时候，总是俗话说要算个账的，哪怕是比较粗略

A34：给老板两个选项，只有1000W，给业务系统升级需要1000W，能带来3000W的收入，但安全上存在个人信息泄露风险；解决安全风险需要1000W，但无法给企业带来实际效益，老板怎么选？关键是投了1000w，还有风险

A35：风险有或然性，把这个钱劈开，不求完美解决风险，把大头用来追求确定性收益，小头用来平衡或然性风险。这个就要看信息泄露风险带来的损失了

A36：安全风险是一种可能，出现的机率问题，就算很多做了等保的企业还是出了问题，所以回到刚刚那位群友说的，都是基于自身利益价值判断而不是企业利益价值判断，而老板的自身价值利益与企业的自身价值利益息息相关……这个话题的前提必定不是违法经营。一般不会这么绝对，即使是信息泄露，也有主要矛盾和次要矛盾，可以花点钱做一部分。总归有分层空间的

A37：是的 所以安全就是拿来平衡偶然性和解决偶然性问题的，买的是一个机率。安全是相对的，不安全是绝对的，没有谁能保证一定没有风险……因为人就是最大的风险

A38：执行层面要做好不容易，需要做事的人有“安全为业务服务”的观念。以前经常听到的声音“业务傻X”、“xxx不听话”，对接起来安全和业务两边都难受。安全团队自我观念的转变其实也挺难的。合规是baseline，安全建设没有止境。资源都有限，拿不到更多的资源，只能迭代（卷）自己

A39：安全不尽要谈钱ROI，还得谈处罚和安全和企业负责人的政治前途。比如体制内的公司，服务器被勒索了，主要数据和业务不能运转了，结果怎么样？

话题2:说点细节：其实漏洞圈内小范围流传已经至少一个月了，厂家还辟过谣，昨天上午终于开始发补丁，马上有人开始逆了补丁，知道了问题在哪里。于是昨天下午2点开始，大规模扫描，大规模干。于是…带来一个问题，如何安全的修复漏洞？

A1：sxf ？这种属于成本对抗了，可以采用加钱加人的方案。哪一家不重要，其实几大厂这次活动估计都会出这个问题，某某信和数字厂最近应该也要发补丁

A2：恩恩，就像我在另外一个群里说的那样，老奇还喷云厂商，实际上安全厂商自己遮遮掩掩的，总是掩盖漏洞问题

A3：云端补貌似比发补丁好很多，补丁的次生伤害。

A4：其实也没啥好遮掩或者不好意思的，本质上说，这活动既提高一线队伍的社会输出水平，也是提高社会企业的管理基准线，普及面这么高的大好事儿，自然是要不少成本的，说成是头部单位的装备竞赛大秀也很正面

A5：问题是：这个问题是否有好的解决方案

A6：其实微软的方案还是有一定的可借鉴性的 既然漏洞不开避免 修复时间差会产生新的安全隐患 那就约定一个定期版本升级发布的时间 防守能第一时间修复 攻击者也就没那么大动力了 如果防守的不作为不及时修复 那就该被教育

A7：是一种思路…但我觉得不够好，技术手段还是要想办法弥补一些安全意识的缺失。这是方向，例如密码强度强制要求就是。和攻击者比逆向技术对抗是个挺卷的事，这技术的确也一直在发展只是没那么好的效果 技术门槛有点高

A8：不能从这个方向下手，这个方向肯定是死胡同，我认为正确的方向是集中管理。例如SaaS服务短时间内全面升级。例如自动升级。例如统一强制升级。当然这些看似简单的策略实施起来很多细节

A9：是的，风险与收益并存。所以要细化场景，达成业界共识

A10：补丁分级，紧急漏洞补丁默认自动下载补丁包升级，默认策略开启，但是给客户自由关闭的选项，防止被担心是厂商后门

A11：内存加载技术早就很成熟了 只不过是把双刃剑 安全要求高的部门既不让内外网打通访问 也不让搞远程变更运维这套 后来就只能停留在灰色地带发展了

A12：私聊也在和四大行的主管在聊这个事，他的意见是：自动升级不敢搞。漏洞晚点打，只是可能出问题;系统可用性，一定会被监管搞死。再啥内存加载，也会被逆啊

A13：是的 监管合规是底线 碰不得。所以纯SaaS服务 不给用户细节才是王道。可惜国内SaaS服务一直发展的不太顺利

A14：金融行业 监管太强势了 处罚也重 管理责任 主体责任都在企业

A15：sase吗？

A16：很多漏洞都是这样，厂商发补丁时没在野利用，发了后就逆向开始竞速了

A17：把接入风险都转给saas厂商

A18：微软，谷歌也一样。所以我说以后 甲方的安全那就是在做合规的 看看saas服务厂商是不是达到安全要求。未来估计SaaS在国内短期内还是发展不起来 毕竟大甲方客户都是被强监管的 认知很难快速转变。SaaS服务商的安全审计 可能就是大家未来主要工作了

A19：那就一个第三方审计saas就好了，甲方不用人去审计。

A20：SaaS推进难度很大，传统厂商不会同意，甲方内部也不会同意。现在升级XX服VPN补丁，厂商早上才给升级方案。昨晚人行态势感知系统发下架风险提示。厂商强行升级需要甲方授权，设备购买后就是甲方资产，没授权是不能ota的。

A21：这个以前跟同行讨论过，通用的办法是没有的，或者说成本过高。不过具体到某些类型的产品，例如VPN这个场景，可能有一些思路。

A22：权责归位还是应该让甲方有主动选择空间。对于甲方来说，业务和安全都SaaS后，再出问题可以在监管那免责或者让监管直接通报服务商吗？如果服务商逐渐合并到很少的几家，甲方是不是就剩下买单了。最后出问题也会说应用开发的不安全

A23：对于上级监管，甩锅给厂商和服务商其实没有用，责任还是自己的，处罚也是自己的。甲方肯好好买单是个好现象

A24：安全责任不能外包，安全责任不能以合同约定的形式进行转移，所以自己该想辙还得想辙，该努力还得努力，不能全指望公有云和SaaS解决问题

A25：这次好几家都要求供应商签责任承诺函的吧

A26：这个有法律效力么

A27：肯定有，双方盖了公章的，不过到时候估计也是扯皮。。

A28：经济赔偿责任可以转嫁，刑事责任的话应该转不了吧

A29：用好公有云会大大提升安全能力，相当与找了个专业安全外包

话题3:

A1：安全产品是有漏洞的、供应链都是有风险的、云防护、人脸识别技术也都是可能被绕过的。以前是不要想着买个防火墙就能解决安全问题，现在是不要想着建一套安全体系就能解决安全问题

A2：很多安全产品代码质量都不行

A3：这样子互测挺好的，提升安全产品安全性。不上安全产品反倒安全一些

A4：以后都国产了 挖漏洞的要换方向了

A5：

A6：天天讲sdl，devsecops。估计这些sdl和devsecops产品开发都没有遵循

A7：某眼的默认口令是360***** 哈哈哈，虽然已经分家好多年了

A8：所以，就不讲机制了，不要纸面，靠实战。这个很现实，但是安全从业人员却经常表现的很意外。。。 我很奇怪为什么大家都会这么意外

A9：别说，我一直也反思觉得安全人应该好好学学王阳明的思想，尤其是知行合一理念

A10：你们没发现吗？这群里470人，很少有研发侧的人吧？研发的人和我们安全的人，语言是不太通的，哪怕安全公司内部也一样，我管过几年的研发，头疼得要死

A11：成天教育和指导别人，自己有没有做得很好，都践行安全最佳要求了

A12：一些不写代码的人去指责写代码的人过程不合适，不够细心考虑安全问题？

A13：刚才某厂商之前管研发的VP来找我说事，我才知道他去管安服了、然后说了几个安全方面的事，他自己都承认他不在安全圈。这就是现状，头牌安全大厂…

A14：好的工程基础背景的人，要求他同时业务非常了解熟悉，安全一大门内容也擅长，有违天理

A15：我觉得不意外啊，以前业务线因不执行安全方案被我说教，说教方案中就有一句话：修复代码你写不来就我写，我安全写的代码你们敢用么？

A16：俗话说的双料复合型人才已经难得，你不能指望三料四料复合人才遍地跑

A17：安全产品的研发，还是要从“研发”里招聘，而不是从“安全”里招聘

A18：革命尚未成功、同志仍需努力

A19：开发架构业务安全，四料

A20：不能这样理解。安全厂商产品研发的头应该要懂安全，这个没问题

A21：比如说我刚才跟PP说的那个可以缓解发补丁被逆向问题的办法，你们想想，在一个企业里，需要什么角色才能推动这个方案的落地？

A22：hackerone 的 2022 年报告里分析攻击面扩大的四条原因之一就是安全人员要不停学习各种 code 和架构，知识结构跟不上。

A23：

A24：反了吧？我一直认为产品安全是研发的责任，安全侧是指导和规范管理

A25：开发、运维、IT、安全，各有各的问题，且难协同

A26：领导们看上去 有漏洞给了补丁 修上就好了 没补丁是问题 有补丁不及时修那是实施人员的问题 不需要他操心

A27：我的屁股在安全，所以我是一直努力安全权利大，责任小，不断努力。DevSecOps理念是安全领导Dev和Ops，Sec为核心啊

A28：研发的意识需要有人不断提醒

A29：实际上在大厂，业务为王

A30：dev和ops的理解是，我俩联手服务业务，sec加塞儿进来搞啥

A31：在哪里都是业务为主。权责要统一，出安全问题不能定位到研发的责任就没用

A32：那必须的、我家也是业务为王的，我们安全是要给业务让路的。在哪都是业务为主。从架构设计就要考虑了。安全更多是在做安全跟业务的平衡。也不能全靠开发。安全很多时候都是给业务让路的吧

A33：这是意识问题，不全靠他，但责任在他，安全是做指导和规范、检查的职能部门。现实是DevSecOps随时可以去掉sec

A34：架构也是研发吧，前置左移这个是没错的。提醒越早越好。但需要安全同学经验、能力和对业务、研发的理解要到位。信息安全属于风险管理的本质，决定了投入一定是有限的...

A35：我们安全人不能这样思考和实践吧，我们要站住了才对吧？每个安全从业人员都承担安全布道者的责任和角色。安全厂商会惊讶滴滴居然有个表的数据没有加密，但是却不觉得自己的产品都是漏洞是问题

A36：就说上海的事吧，再大和我有什么关系。研发任务完不成，实实在在扣绩效，安全补个漏洞，咱们能给人加绩效吗

A37：不过安全还是适度为好，从企业来说有合理的roi。单纯的技术人员只会想越安全越好

0x2 本周精粹

休刊

0x3 群友分享

【安全资讯】

https://x.threatbook.com/v5/article?threatInfoID=17404&source=share

阿里巴巴与蚂蚁终止《数据共享协议》

https://m.toutiao.com/article/7124519787186782760/?app=news_article&timestamp=1658811203&use_new_style=1&req_id=202207261253220101381722071005D95D&group_id=7124519787186782760&tt_from=weixin&utm_source=weixin&utm_medium=toutiao_ios&utm_campaign=client_share&wxshare_count=5

--------------------------------------------------------------------------------

【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。

往期群周报：

如何进群？

如何下载群周报完整版？

请见下图：