关于重保这件事

| 分类 安全工程师  | 标签 安全随笔 

简写两笔感悟,有空下次再续。 首先从管理上来看,在驱动安全落地的两种方式中: 事件驱动管理驱动 中,重保是一件极为有利于推动企业进行安全整改的事件, 属于事件驱动中的经典事件。由于一般情况下重保都是由政府或者监管机构发起的,而且随着国家对于网络安全的重视,这些策略可以说是很痛的打在企业身上,能够极为有效的推动安全部门的落地工作。至于无论是事件驱动还是管理驱动,在我的认知里,沟通才是最为重要的。不要一开始就想着事件驱动,而是应该首先做好沟通。当沟通的结果不满足预期时,此时再进行事件驱动,本着外来的和尚会念经原则,利用外部提交过来的一些问题推动内部的发展。但是注意不要把自己放在研发、运维的对立面,而应该是互相协作。共同为客户提供好的安全保障。

第二点谈一谈重保实现的形式,重保往往是注重于形式化。有时候可能不切中实际落点。和企业安全防御的建设本身有些出入。但是并不意味着重保是无效的。同时往往也能暴露出一些问题。就是永远不要以战术上的勤奋,去掩盖战略上的懒惰。一群人,日日加班,在重保期间,24h online, 应急止血。这从另一方面只能说明了一件事,事前的企业安全架构没有做好,检测和止血的能力也没有自动化。同样仅仅依靠重保期间的高强度工作去应付检测时不起作用的。尤其是疲于奔命的应急和毫无预演和规范的止血操作。但是如果企业能够吸收重保带来的教训,能够在接下来的时间段内提高自身的安全建设,也是值得。总的来说,不能止于形式。

第三点谈一谈相反的一种情况,就是大促和重保。大促时候的重保往往和监管的等保,政府的护网不同。大促是企业本身做出的关于营销方面的重大决定。无论是确保风控本身,还是企业安全本身。在大促期间的保障行为毫无疑问是极为重要的。但是针对大型的互联网公司,大促可能带来超大流量,不亚于一次超大型的DDOS,虽然此时有些防护是在ISP和CDN上做了清洗,同时也通过人机验证过滤掉了一批用户。但是此时的流量和用户依旧是巨大的。同时无论是反爬还是安全设备也往往在此时会进行降级,比如不再全量检测,规则也进行降级。只保留核心的waf规则等等,避免把串联在边界的安全设备打垮,同时由于业务请求量的激增,也会导致日志收集系统流量暴涨。为了避免相关联的系统崩溃,有时也会关闭日志。尽可能的把资源全部留在业务上。那么这个时候怎么办?老虎打盹的时候需要依赖边界栅栏,边界的硬抗加硬件分光,大数据的检测平台,即便常用的日志收集出现问题,也要尽可能的保障在边界的检测行为。根据大促的特点,不会是全时段的,可以针对大促的不同时段,调整对应的规则,进行降级等等。另外还有很重要的一点就是提前做好演练。不要降级降挂了,在真正实操的时候出现了暗坑。此时业务当先,一切都将措手不及。还想到一件事,事件的统一收口: “核按钮”。 以及风险的统一收口:各种降级开关。


上一篇     下一篇