突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周

admin 2022年4月19日01:27:30企业安全评论8 views6518字阅读21分43秒阅读模式

‍‍‍‍‍

突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周


突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周


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没法支持。所以还是看场景,况且关键分析性能略糟糕。


突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周


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 本周精粹


供应商及人员安全管理


金融实践群精华回顾之三 - 职业欠钱理解的安全运营


关于大型互联网企业DevSecOps体系构建的总结与思考


0x3 2022年第14周运营数据


金融业企业安全建设实践群 | 第142期

本周群里共有 80 位群友参与讨论,群发言率为17.74%,群发言消息数为 470 条,人均发言数为 5.88 条。


企业安全建设实践群 | 第67期

本周群里共有 50 位群友参与讨论,群发言率为14.75%,群发言消息数为 163 条,人均发言数为 3.26 条。 


0x4 群友分享


【安全资讯】


2022全球重大网络安全事件盘点


eCapture:无需CA证书抓https网络明文通讯


安全牛《中国网络安全行业全景图(第九版)》发布


关于开展“清朗·2022年算法综合治理”专项行动的通知


国内上市公司遭遇电信诈骗:邮箱遭入侵,被骗2275万元


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


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


往期群周报:


如何用量化指标梳理网络安全等级保护系统定级?疫情形势下怎样确保远程工作安全?算法备案与算法安全管理制度建设探讨 | 总第141周


如何有效杜绝员工github泄密?应用漏洞数量的增降改变 VS 安全与研发能力向上汇报?数据安全运营怎么做?| 总第140周


监管单位未发现被监管单位长期违规是否要承担渎职失察责任?安全技术培训的价值如何体现?安全架构与安全体系的探讨 | 总第139周


如何进群?

如何下载群周报完整版?

请见下图:


突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周


原文始发于微信公众号(君哥的体历):突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周

特别标注: 本站(CN-SEC.COM)所有文章仅供技术研究,若将其信息做其他用途,由用户承担全部法律及连带责任,本站不承担任何法律及连带责任,请遵守中华人民共和国安全法.
  • 我的微信
  • 微信扫一扫
  • weinxin
  • 我的微信公众号
  • 微信扫一扫
  • weinxin
admin
  • 本文由 发表于 2022年4月19日01:27:30
  • 转载请保留本文链接(CN-SEC中文网:感谢原作者辛苦付出):
                  突发灾难状况下单位的开发工作如何解决?安全远程办公方案暨大数据分析技术栈ELK vs clickhouse探讨| 总第142周 http://cn-sec.com/archives/920311.html

发表评论

匿名网友 填写信息

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: