0x1 本周话题TOP3
话题1: 想请教群里的专家们，现在这种突发灾难状况下，单位里的开发工作如何解决？有何比较完善的方案么？
A1:远程办公，我们的工作并没有受到影响。
A2:有没有一种可能，通过云桌面开发。不过网络的稳定性和云桌面操作的流畅度是个问题,而且成本高，建设周期长。具体感受看看某大厂推进了多少年，吐槽和因此跑路的人有多少。目前云桌面不会降本。所以，老板得认可这项的价值。
A3:VPN进来以后是云桌面开发？云桌面挺方便的呀，还能做数据防泄漏控制，但成本确实是上升了。我们现在运维都用云桌面，然后走到哪都能运维。
A4:或者就是给开VPN。
A5:每天都看我们公司开发吐槽云桌面。
Q:云桌面好用吗？我之前试用过的，总觉得卡顿。
A6:云桌面带来的成本压力需要转移到项目成本分摊，推动起来就容易了。IT成本暴增，老板不会同意，远程开发不方便又不是致命的问题。
A7:卡，是网络？处理能力？图形？硬盘I/O?内存？这些问题定位了才好解决。
A8:云桌面的最大问题就是成本和网速。我有个看法，不知大家同意否：研发和测试一部分投入到行业云。这样成本是计费的，容易分摊。行业云还能做到监管合规和数据安全的一定平衡。
A9:行业云上去后，本质也是云桌面吧。大家说的云桌面以公有云的为主还是私有云那种啊，是先连VPN再连云桌面还是直接把云桌面放到互联网上呢？
A10:上云后，网速、io都可以快速调整。云就是成本问题，成本要上去些。网速这个问题是不是多弄一些站，就近连接可以，比如北京的连北京这里的桌面云，上海连上海的。
A11:本质上也是桌面，或者私有云。银行上云的合规要求可能更复杂。io是个瓶颈，对io无要求的可以忽略。比实际的需求还要多一些，行业云好些。
Q:你们的桌面软件安全这块儿一般都干些啥？
A12:我们好像没有，没咋注意这个问题。除了尽量用正版，还有其他的么？公司不大可能所有软件都用正版。
A13:用开源啊。换个故事讲，云桌面的作用是为了保证业务连续性。开源也行啊，问题是会不会对引入的软件进行安全方面的规范。现在好多云桌面的用户最大的诉求是数据防泄漏。所以用行业云，数据落地即加密，合规又安全。数据的话，用加密呗。
A14:云桌面体验比起本地PC确实差很多，无论是易用性，性能和速度方面。感觉如果可以，本地coding，等有网络了上传回单位，是不是从性能和使用体会来说会好很多。只不过单机编码的业务场景多吗？或者是不是还涉及到存量代码的获取问题？
A15:这就是个泄密场景。做好终端安全+远程权限+强化审计，是目前的应急策略。
A16:如果是远程办公，终端安全，可能没法管了，因为允许byod才能提高效率。
A17:那也得有BYOD的软件啊。挂上EDR并不违和。
话题2：请问大家安全远程办公有啥好方案吗？
A1:简单点VPN,正规点VDI+VPN。
A2:vdi算高成本解决方案吗？听说云桌面不便宜。
A3:不是为了降低成本的，是为了统一管理和数据不落地。现在都在研究SDP零信任的解决方案吧。
A4:抛开成本，现在云桌面性能ok了吗，比如开发岗。vdi远程看东西做简单操作还行，受网络和其他制约因素太多了。
Q:嗯，那感觉VPN+VDI推不全，SDP我理解就是替代VPN，那数据泄露问题呢，我用私人电脑，装公司SDP客户端，数据下到本地，外泄，这条路怎么封？
A5:看来你们是人数不多？我们这之前测的人也不算很多就不太行了，五个人就比较吃力了。
A6:10多年前的东西了，现在很成熟。。看看citrix。
A7:入网检查，这个不难，软件进程这些都加上
A8:啥不太行了，是在本地跑模型算法还是做渲染。做做流程的给4核，开发给8核，不够则扩16核，内存给CPU的2倍GB，每周强制重启，没有不能干的。
A9:资源配足一点，普通编码应该没问题。不能数据落地的不要使用直接发布应用的模式，可以用sdp+沙箱或vdi。因为一般sdp应用互联网场景，终端是个人的。你把数据落出来再通过dlp去管控是不合适的。
A10:钱不够的话，VDI会很难受。最终变成了桌面投诉。存储的钱其实可以省下来。不提供漂移，RPO，要求保存在线上，存储就省下一大笔钱。cpu内存那是省不了的
A11:刚用起来的时候大家都挺爽，后面系统有些问题卡顿了，投诉会多点。建议有windows系统方面的维护人员或者维保，ad域做用户管理的偶尔也会有些认证问题。
话题3：想问下银行和券商的朋友，面对海量的安全日志，安全检测规划这块，都是怎么做的？怎么做到海量日志的过滤和筛选呢？如果不做过滤和筛选，那这么多日志信息怎么确保风险动态清零呢？
A1:关联分析，专家规则，AI。技术栈ELK，现在开源的标准方案，splunk的最大对手。
A2:splunk的收费模式决定了只适合小公司玩，体量一定不能大。另外现在去买个安全态势感知产品，背后技术栈清一色的elk+hive，大数据技术有可能不同，elk都一样。
Q:每天多大日志量？怎么一个集群规模配置？时效性和动态联动？没有人喜欢用结构化的日志分析吗？
A3:结构化看量，量不大没问题,，至少一天几十T没问题。clickhouse?
A4:clickhouse很好用啊，然后在做日志关联也很方便跨库跨集群，风控的时候能关联很多非日志的数据。es的话还要手动搭桥……现在看ch比es更有优势。
A5:原来是对着elk说的。ch不知道市场接受度怎么样，我公司就没人用。
A6:ch压缩比很高，就看使用场景。es适合非结构化的，依赖全文索引，能比较方便的找到关联问题，缺点是加了索引数据太大了。如果是全局搜索，ch没法支持。所以还是看场景，况且关键分析性能略糟糕。
A7:调用链那种日志模版规范那种，相当好。Ch是结构化，在一些特定场景里，需要联动其他非日志数据之类，会很方便，缺点是过于要求结构。两个混着用，兜底坑数据还是丢hadoop没什么可以讲的。那冷数据也用不到ch了。hadoop有点过时了，ch的olap还是很强的。ch虽强，但是它是一个分析工具，不是数仓。CH不是分析工具吧。回头问问我们大数据的人，反正公司没引入的组件也用不了。
A8:在ch里可以用url这个tablefunction去调es的数据，两个联动起来可以提高很多计算分析的性能。但如果ES自身不存原始数据，CH去调ES能查到什么东东吗？
A9:dictionary又可以很快速地构建一个类似udf的东西，省去了各种不必要的join。CH目前看只需要ES的1/8-1/10的容量。
A10:es你当它是ch的某个数据源就行。ch这个好，谁用谁知道。
A11:那就是数据没有省咯，只不过可以快速关联。因为运维里面，特别是日志非标准的情况下，CH用起来很艰难。在互联网里面，日志格式标准统一，那是挺好的。好像之前CH在运维火的时候，是携程搞起来的。
A11:CH适合大量数据关联分析和查询.
A12:纯互联网公司的日志基本就是nginx access.log。主要场景就是具体针对 url_path，http_status，resp_time 这几个字段做统计，不用啥全文搜索。这种情况下，确实对比 es 有优势。数值统计特别快。
A13:我举个例，我前厂有es做全量request response, 这部分的东西因为requestheader和responseheader的异构问题，还有cookie的异构问题所致的，这里边主要对几个值做索引，这样es可以很快的关联出其他相关的数据。然后一些基本的业务数据放mysql，部分数据用了特定的rpc加密。然后http accesslog丢ch, 部分业务数据t+0.5丢ch。这时候有个场景，我可以通过access日志很快的找到最基本的异常，然后把异常丢给es去做索引，es把关联数据返回，丢给ch, ch做临时表，然后通过dict从子节点上继续跑递归做出风险向量，然后就可以很好的描述一个请求在一个大的时间窗口内的风险系数。
中间dict打通mysql和rpc, 然后还可以同样打通ch其他节点，这样甚至可以跑出来一个小的神经网络(如果性能够的话）。
如果是业务上也行，针对于反黑产反诈骗场景，只要去关心后端接口的设计，其他就丢给ch去关联就好。当然笛卡尔积这种，啥玩意儿都跑不动。然后类似kibana, 需要展示或者图形做参考的话，用redash, deepins都可以，也可以把数据回写到es用kibana, 如果只是纯值类时序数据，也可以丢grafana。总的来说ch是真正的优势是可以打通很多数据源的快速分析，存储虽然压缩也很强，但是为了存储还能做别的事情，还是放到通用方案里。存储成本上大概是es的1/10-1/25，以我前厂的数据量比较的话…当然es加索引的空间占用会比较指数，所以数据量大了以后成本会进一步拉开。不足之处就是计算成本的运维，要是sql写不好，也很闹心，学习成本偏高。
A15:现在安全日志非结构化太严重了，而且结构还经常变，ch团队应该不会给好脸色。不过海量数据es真的太多问题了。
A16:clickhouse数仓杠杠的。日志分为热、温、冷数据，hot log放es splunk全文索引那，warm 或cold log放clickhouse那。有钱的话splunk全搞定，话说splunk可以买断、不限流量。
Q:sls用的啥技术栈？
A17:ES+CK+Hudi，基本上能覆盖主要场景了。
A18:个人拙见，sls套装，就………ilogtail的配置管理什么比较不错，目前开源的采集这点一直都很缺。你的链路是 agent采集到sls 然后sls 同步到你机房吗？
A19:第一步，传到sls 第二步，主动去消费sls。sls是全文索引比较贵，你还是放mq里面吧。
A20:我看到topic，以为是kafka。咋放mq，没给我这个选项。
A21:买一个kafka的云服务。你要用ilogtail啊？我还以为agent自己的呢。某云的产品，很多日志都放sls上，Sls有个external logstore。
A22:没有，我的需求很简单，把我的原始日志弄下来，我自己会处理。同步到idc。这个接口有了。
A23：就是把sls 同步到你机房的什么应用？可以参考下面的解决方案，跟你自己写一个api去拽差不多。然后，sls还开了一个mysql协议，可以拿aksk连上去，当数据库拽……
参考链接：https://help.aliyun.com/document_detail/118986.html
A24:如果是flume的话，有个flume-sls-datasource插件，是官方的。现在给我的就是sls的api，文档也有，但是按写入计费，还是消费计费，没人清楚，我先试着联调了。原理是拿ak给生成一个sts, 然后读每100毫秒还多久读一次消费组的cursor。
A25：不用读 sls可以主动将日志送不过去。sls用来存存冷数据还行，要分析还是不够。我拽本地来分析的，有些情报啥的只有本地有。都聊到这了，某云开放api控制安全组（做自动封禁）的接口吗？
A26:通过syslog 或者https 将日志同步到你的siem系统。你如果要用的话，只能拿datalake或者之类的云数据库做个连接，这个从成本上看其实也很贵。我不太推荐生拽。自动封禁啥啊 ecs的 还是eip slb的？都是有api的。
A27:Ecs那边的文档里有，这个安全组控制啥云都有api吧？
A28:eip 不好控制 你得买云防火墙控制云防火墙就比较贵了。
A29:ebpf的话部署率和稳定性也是问题啊，而且ebpf解决不了vpc总体的流量。现在的采购模式、预算模式在未来应该会改一改，订阅模式和按量计费模式越来越打破一次性付费机制。所有主机都上了，vpc也无所谓了吧。主机agent需要一个团队维护，人少不好搞。
A30:epbf最大风险还是稳定性担忧。不过如果是对内提供的，就从链接过去的抓请求了，client看。现在agent对抗那么厉害，一个ring0 ebpf就瞎了。
A31:这个是管理维度了，一般这种都是需要搞权限去跑的，属于存活监控了。ebpf很重要，但是只有他还是不行。另外ebpf做流量复制，效率太低性能扛不住.
A32:agent被下了没告警吗？
A33:flow是五元组吧，没有流量内容应该。ebpf都到内核了，会占不少内存和流量。pcap都比他底层。内容你就要依赖包解析了，主机内可以xdp, vpc没可以流量镜像。性能都会比他好。
A34:flow应该是五元组，aws的tm对要mirror的机器也是有要求的。nitro芯片的ec2才可以。我以前的经验，flow用来构建网络的拓扑还是很有用且高效的，也能用来做一些nids相关的事情，现在没了这个东西，有点抓瞎。如果初次上云，我个人建议把安全组（sg）规划好，以白名单的形式去落地，可以做到网络层面的控制，做二个切面，一个控制流，一个数据流。相比较后期的治理会轻松很多，如果已经上云了再去做治理推动，难度就比较大了，如果全k8s模式会好弄一些，这也算是安全左移吧。网络的安全架构设计可以让nids之类基于网络做入侵检测的更准确，因为相比较清晰很多。
A35:一看就是实战后的经验，安全组规划不好，后期的运营债务会越积越多，一般我们都建议结合vpc acl和安全组一起做，对于变动不大的边界防御以acl为主，主机层面的安全组最好结合类似于lambda服务这种形态处理，减少运营管理成本。
A36:其实大部分的公司上云的时候很难会去考虑安全问题尤其边界这块。所以一旦上云成型，边界安全的债务累计是很重的。如果说有个什么工具能快速的帮企业理清边界，能给出规划就再好不过了。比如从流量，合理性，集中出口之类，现在这块确实也是云安全产品的一个盲区，只有个cspm能略微喊喊，但是给出合理性建议也很难。
A37:对云厂商来说，roi极低。另外就是云上标准各不相同，学习成本也很高，最后传统网工上来一把调网络，一个月过去了网络调好了，剩下的就不敢碰了，否则又是一个月。
0x2 本周精粹
0x3 2022年第14周运营数据
金融业企业安全建设实践群 | 第142期
本周群里共有 80 位群友参与讨论，群发言率为17.74%，群发言消息数为 470 条，人均发言数为 5.88 条。
企业安全建设实践群 | 第67期
本周群里共有 50 位群友参与讨论，群发言率为14.75%，群发言消息数为 163 条，人均发言数为 3.26 条。
0x4 群友分享
【安全资讯】
--------------------------------------------------------------------------------
【金融业企业安全建设实践群】和【企业安全建设实践群】每周讨论的精华话题会同步在本公众号推送（每周）。根据话题整理的群周报完整版——每个话题甲方朋友们的展开讨论内容——每周会上传知识星球，方便大家查阅。
往期群周报：
如何用量化指标梳理网络安全等级保护系统定级？疫情形势下怎样确保远程工作安全？算法备案与算法安全管理制度建设探讨 | 总第141周
如何有效杜绝员工github泄密？应用漏洞数量的增降改变 VS 安全与研发能力向上汇报？数据安全运营怎么做？| 总第140周
监管单位未发现被监管单位长期违规是否要承担渎职失察责任？安全技术培训的价值如何体现？安全架构与安全体系的探讨 | 总第139周
如何进群？
如何下载群周报完整版？
请见下图：
原文始发于微信公众号（君哥的体历）：突发灾难状况下单位的开发工作如何解决？安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周
- 左青龙
- 微信扫一扫
-
- 右白虎
- 微信扫一扫
-
评论