运维风险管控、数据安全规范普及与漏洞情报处置：技术与管理并重的综合策略探讨。｜总第278周

0x1本周话题

话题一：咨询一个运维风险管控的问题：linux操作系统根据用户角色和用途划分了不同权限 的用户，如用户A、用户B，原则上来说，B用户只拥有查看权限，无法修改、执行用户B下的文件，但运维人员通过用户A将修改、执行权限赋给B，从而导致通过堡垒机访问时，仅需要申请用户B即可完成用户A才能授权完成的操作。想咨询一下，这种情况，有什么技术手段管控呢？

A1:看起来像是A的问题，不能随便给权限。禁止A赋权。

A2:我们在检查中发现，申请A是走了正常流程，但是审批层级相对多一级，因此，运维人员就第一次申请了用户A的权限，然后再赋权给了B，后面搞操作的时候就只申请B用户，流程就简单得多。

A3:量蛮大的，通过堡垒机输入监控b 的修改 vi 执行命令报警。

A4:没必要通过技术手段，增加系统复杂度和建设成本，感觉通过规章制度、事后审计等管理手段更合适些。考虑到特殊应急场景下，运维超管用户就是要赋予这个权限，但是要明确要求，事后审计追责。

A5:量确实是大，而且用户B可能也会在自己目录下写入。我们主要还是想能够做到自动的权限控制和监测。

A6:我们现在是对高危命令隔天报警，明年想推操作员主管30天内审核操作员操作，培训好主管。

A7:事后写审计报告，将违规行为上报。我们想的是如果能事前有技术手段或用LINUX自身的机制控制的话，更好一点。

A8:建议先看看，这些“提权”操作是不是合理合法，如果合理，制定一些标准让它变得合法，例如使用提权清单，清单内命令就可以做，但剩余不许做；如果不合理，该对提权操作告警、阻断就要执行，回归分权的初衷和意义。

A9:分析A赋权给B的是用什么技术方式，然后制度中完善对这部分的定义，技术上可以阻断或是审计这类赋权方式，一旦发现违规行为再进行处理。

A10:如果原则上B是没有权限的，那相关操作应该交给有权限的角色来操作，而不是直接给权限。不然A、B的角色就没意义了，到最后大家都有权限了。

A11:安全团队针对运维账户权限的强管控还是要慎重，要找到平衡点，而不是只站在自身或团队角度。

A12:肯定是不合理的，因为用户B定义的时候就只允许只读，所以这个用户的权限申请就相对简单，用户A的权限申请就要多审批流程。

A13:如果B在后续的运维操作中引发了事故，安全团队也没有揭示风险的话，那可能也有锅。

A14:那可以禁掉赋权或提权操作，或者监控。

A15:从我们之前的合规要求其实就是分了的，有些二线运维人员为了图方便和省事，来做的这个事情。

A16:好弄，作为安全检查发现。安全如果不敢说话就送给审计部。

A17:那个人理解还是钻了制度漏洞，要求账户提权必须申请，定时对提权操作进行审计，若发现未经批准进行提权操作的，该追责追责呗。

A18:这确实是我们自己检查发现的，但是领导的意思是最好有技术控制手段。

A19:如果是通过sudo实现的，那么通过监控/定期检查sudoers文件，或者监控sudo命令都可以发现控制。

A20:这种场景用户属性并没有变化无法监控，我理解常见的就是sudo。也有可能就是chmod。

A21:堡垒机能限制一些操作，一般来说A的权限就是修改删除之类的。B就是VIEW之类的。做一些命令监测也能发现。

A22:chmod就难管控了，常见的是建日志平台，减少这种只读需求上机操作，同时也让可读性更好，通过投入成本，以同时提高安全性和便利性。

话题二：有位大佬说过，十年后可能我们都得感谢2范式让咱们没有失业，当时不以为然。现在看3范式确实有这种感觉了，从这个感觉出发，唯一的问题就是，这些认识得传播到老板们、当高管的CISO们、监管们那里，仅刷新从业者至多能解决技术的问题，不能解决组织的问题，从而导致不可推广复制。

A1:这个需要两条腿走路，首先是从业者们形成更大共识，丰富和完善我们自己的安全体系，另外一方是影响决策层，包括杰出的从业者进入决策层。

A2:我们董事长在听数据治理报告的时候，说，数据治理我没那么关心，我关心的是数据安全。

A3:领导要的都是结果，觉得过程是你们应该考虑和做的，不关心怎么做。所以公司管理层一定要有一个能够理解安全逻辑的人，一般是技术负责人，或者是CISO直接进公司管理层。董事长/CEO对安全后果负责，但不可能有精力和专业能力对安全过程负责，所以需要安全负责人来承接。也是我在安全指标里强调，一定要把业务指标和技术指标拆开。安全太专业，只用业务指标来牵引，很可能导致雪山的不断堆积，直至崩塌。

A4:只看结果，就会陷入“出事要你有什么用，不出事要你有什么用”。不要安静的走进雪崩困局。

A5:不过大多数土财主公司，只看结果，而且是短期。过程给给面子，鼓掌意思下。最终还是只看结果，这个大家不用回避，大多数都是这样。

A6:数据安全是治理的一部分。治理也是安全的基础。但老板不会管这么多，这是底线思维，保住乌纱帽是他的使命。CISO或者安全部门经理要进入经营管理层太难了。很可能让管技术的副总CIO，CTO兼任了。很少让CISO汇报给CEO

A7:能理解，这确实是真心话。目标是数据别泄露，如果过程上必须做数据治理，那你就去做，老板要么关心红线问题，要么关心盈利问题，确实不太关心怎么做，他也无法专业评价做得对不对。

A8:谷歌和亚马逊技术安全团队都是直接向CEO汇报。通常让公司成立网络与数据安全领导小组，比如国企央企党委书记党支部书记作为小组组长，总经理等其他副总作为副组长，部门经理作为成员。

领导小组常设办公室，任命CISO兼任办公室主任，负责安全日常管理工作。国内公司这几年逐步重视安全了，汇报线也逐步靠上来了。也有很多都有于CIO CTO的汇报线。CISO四个字母的CXXO和三个字母的CXO，终归还是差那么一点意思。

CISO CSO向领导层汇报一定要让领导听懂人话，不能太技术了。做好翻译工作。说完之后再发个信息或者邮件总结一下，不然领导容易忘。强监管行业比较好办，直接引用监管发文法律法规部门规章。

A9:但大老板的思路是我不需要也不懂这些，我找个懂得来管，管的不好就换能管的好的。这个是非常正常的，甚至很多时候这才是对的——管理者不想亲力亲为，他掌舵，执行是交给别人的。

A10:体制内的，可以多读《党委（党组）网络安全工作责任制实施办法》第二条，领导班子主要负责人是第一责任人，主管网络安全的领导班子成员是直接责任。

A11:机会是有，只是说都比较难给老板明白你是可以的，但还是可能管不好。反正在他看来，这些过程的事别问我，CISO去弄，管不好就是你的事。

A12:审计就是典型这种，来查你还得你给他讲明白，不过偶尔抗抗雷应该也是做安全的基本职业道德？

A13:是的。安全就是管理风险。可能发生可能不发生，降低发生的概率，增加对抗的成本。当然，这就是价值啊。执行层面得层层落实、层层压实责任。《银行保险机构数据安全管理办法》银行保险机构应当按照“谁管业务、谁管业务数据、谁管数据安全”的原则，明确各业务领域的数据安全管理责任，落实数据安全保护管理要求。

第二条：网络安全工作事关国家安全政权安全和经济社会发展。按照谁主管谁负责、属地管理的原则，各级党委（党组）对本地区本部门网络安全工作负主体责任，领导班子主要负责人是第一责任人，主管网络安全的领导班子成员是直接责任人。

A14:只要不是顶格处罚，一般不会这么执行。都是下面的顶，除非监管想搞你，一般都让行里自己报。这是一种威慑，尽责免责，失责追责。

A15:有个很直观的，比如演习出事了，或者真的出事了，那就是CEO叫过去检讨，想派安全部负责人都不许的，内部是你的事，但批评的就是CEO，不是虚的。

A16:上纲上线就没办法了，说明事不小，监管也不敢犯原则错误。现在出现安全事故以后，媒体不让说也就罢了，但行业内的通报还远远不够，缺乏行业警示性。所以当看到微软啥的能公示案例、原因、改进啥的觉得很羡慕。

A17:其实老板们是有这个诉求的，谁谁家出事了，到底怎么个事？我们有没有问题？老板这时候是关心的，事件营销的效果可能胜过年终汇报，但太不透明了。管理层能认知到雪崩风险的时候，才是雪崩困局；否则只是雪崩陷阱。大部分行业机构连到雪崩困局的阶段都没到。

A18:这条写的非常好，不是金融行业的也可以参照。一定要把安全的责任落实到业务部门去。而不只是安全部门的事情。安全部门把规章制度、流程建好、技术工具、三同步做好，业务部门要执行好，比如DLP标签打好，分类分级做好，不然安全的效果会大打折扣。抓大放小、给业务部门提供可行的解决方案也非常重要。不能搞对立。

A19:我一直以来干安全都有一种帮老板平事的心态。2020年后，公安现场监督检查越来越频繁，这时候心态变了，主要就是公安干警在给我们下问题的时候强调：安全不是你的事，是全公司的事，不要替别人把工作全包了；不给你下问题，你怎么要资源？你现在的资源够了？要是你投入嫌多我可以不下，当时觉得他站位真高。

A20:我都是从ESG视角给高层讲安全。问题肯定是有的，但不能有大问题。每个监管执法有自己的解释权。每次基本上是领到几个问题，限期整改。监管也是尽责履责，只是当时发现了什么问题，不代表没有其他问题，如果出事了，公安照样抓人。现场检查结果向管理层汇报，公安和其他监管的执法还真有点不太一样，很多事情可大可小，但无法反驳。

A21:比如公安说你专岗人少，投入不足，我真反驳不了。是啊，我还欠他们一个head count。预算没有监管说话，现在根本要不下来。缺人手还是在内部想办法借用一下，比走招聘快，或者搞虚拟组织，按项目走。或者买个外部咨询或者产品并提供服务。

A22:公安怎么定义安全团队？必须有哪些人员和岗位，人数占比有什么要求？监管检查我们时，总是会把系统管理员，网络管理员，数据库管理员等基础运维人员都算上，都可以有相关安全职责，但安全专岗只有我一个人。

A23:都是专职的。搞网络防火墙的网络管理员是专职的，负责系统打补丁的，系统基线的，镜像制作的系统管理员是专职的，管数据库的，配权限，配备份，防止勒索的数据库管理员，是专职的，而且现在网络安全就含系统稳定性，所以这些专职的，也是专职的安全管理员。

A24:这个应该没问题，安全是运维要保障的一个重要方面，不光是可用性。为了报送或检查混进去就算了，但真正工作重点还是差很多的。

话题三：请教一下，目前监管部门日常发的漏洞情报还挺多的，还有一些从安全厂商那里获取的漏洞情报，大家收到这些漏洞情报都是怎么排查处置呢？自动化匹配的话，我们有资产管理平台也汇集了CMDB、青藤等资产信息，但是说实话资产版本信息也不是特别准确。为了尽职免责我们会定期手动给各中心、分支机构批量发漏洞排查通知（影响比较大的漏洞会立刻发），但是也不知道多久发一次合适，假如互联网资产真有相关漏洞，发晚了也不合适。请教大家都是怎么做漏洞排查的？

A1:可以把互联网资产、品牌优先收集起来，自己也每天扫描监控更新，对齐台账，命中互联网资产品牌的，优先排查，其它非重要区域的降低优先级，核心思路是：版本信息利用条件需要研判，但是否涉及尽可能有个集中初筛。

A2:前期做好资产梳理，持续优化，漏洞的话，判断影响面就根据类型和版本号，看不到版本的我一般就写个类型。需要配合进一步排查，或者相关应用或者开发进一步排查。需要返回一个内容，就是影响了哪些子业务。安全人员需要对公网的漏洞情报进行筛选确认，不影响就不用通报预警。

A3:我理解本质就是安全资产的准确性、漏洞的威胁面研判、修复的优先级？

A4:安全资产清晰是前提，漏洞判定看安全人员的，吃经验。做成一个工单流程就行，先走人工研判漏洞，排查和发单都可以自动化。人工研判关注实际风险等级，影响的具体包，影响范围。其他的调用现有CMDB HIDS接口自动排查受影响情况然后发单给对应的人员。

A5:经常碰到一个情况，有些单发过去，人家说我主机上虽然有这个包，但是根本就没运行，这个情况咋避免？

A6:要么修，要么删，选一个。初期上线时或者变更时，对发的包进行漏扫，做好左移。前面要做漏洞分析，包括验证、曝露面、利用难度、利用类型等。

A7:这个是CMDB的KPI。我理解这个问题是问CMDB实在没办法推动维护精确的情况下，如何做这个事情。

A8:这个问题我们是结合hids，把基础环境里能识别的搞出来，这部分就七七八八都有了。应用里依赖的排查，除了hids能识别的一部分，我们准备把sca再搞好，上线前必须扫一遍，这样应用侧也基本有了。

A9:主要是有时候发的漏洞没得版本，又或者涉及版本很多，这个又得费脑筋了。

A10:剩下的整改，除了钱总说的这个了，还有就是部分通过修改配置进行处置或缓释的，就得靠人复核了。这部分工作应该占比不大，重点是能不能做到位。整改嘛，看内部流程就好，不一定非得升级。最扯的是没版本的，那这部分就看情况了，真正的大问题，外网也能搜到了，搜不到的，该忽略忽略吧，不改就不改了。

A11:我觉得没必要强求“先”把CMDB全维护准了才搞漏洞管理，“先”把日志全采集了才搞态势感知，而是先抓高危风险，先搞互联网资产，以此场景把CMDB的系统、流程、分工都建立起来，再考虑全面推广。当范围是互联网边界时，就没必要讲困难了，监管不发，自己也要找情报，演习有情报也要研判，没情报也要防互联网多余暴露或老旧不下线，任何质疑都可以用实战打出话语权。然后这块跑顺了，系统、流程、考核也就都顺了，推广一下只是阶段周期问题了，并不要命。

A12:这才是正途，按暴露面来，逐步完善。互联网排查真的是要及时，必须要客服掉。 但是我理解部分团队更大的问题是，互联网资产有暴露面管理，但是基础环境和应用依赖也很难搞清楚，因为有外部部门因素，在只能管到自己一亩三分地，那要做的就是怎么减少依靠其他部门，还能做到效果。

Q:互联网边界资产必须厘清，这个是原则。有一些组件停止维护的，最新版本都存在漏洞的，怎么搞？

A13:这个只能根据具体利用条件单独出方案了。“忽略”一部分，改一部分。比如jquery这种，能利用，但是要把系统整个改掉，我觉得得不偿失。

0x2