。

随着平台业务越来越复杂专项压测全链路压测、内部压测、灾备演练、降级演练、限流、巡检监控、应用健康度、混沌演练红蓝对抗如下图所示。

随着平台业务越来越复杂红蓝对抗的作用愈来愈明显下面将详细介绍大数据平台在大促备战工作中是如何开展红蓝对抗的。

一、红蓝对抗介绍

红蓝对抗是网络安全领域常见的一种对抗性演练方法是指为发现并整改企业内外网资产及业务数据深层次安全隐患在确保业务平稳运行的前提下整合平台安全威胁监测能力、应急处置能力和防护能力以真实网络环境开展实兵红蓝对抗演练提高并完善安全防护技术与管理体系。

蓝方代表攻击方红方代表防守方。

红蓝对抗模拟了真实的网络攻击和防御过程在受控的环境中进行蓝方通过模拟各类威胁和攻击手段对红方进行攻击测试其防御能力和系统高可用情况。

红方则负责防御和应对寻找并修复系统中的问题并且收集关于攻击者的信息。

1.保证监控告警有效性

红蓝对抗可帮助产研验证监控告警的配置有效性通知及时性信息准确性。

红蓝对抗通过识别可能导致系统发生错误的潜在问题帮助提高系统的可靠性。

3.降低风险

红蓝对抗通过识别可能被恶意攻击者利用的潜在弱点帮助降低发生线上问题的相关风险。

红蓝对抗模拟了生产环境的场景但却不会对生产环境产生风险从测试角度来看保障系统的质量。

三、红蓝对抗实践

红蓝对抗演练实践主要包括演练公告、人员指定与任务分配、演练前场景梳理、红蓝对抗过程、演练结果收集、演练复盘共6个部分。

1、演练公告

第一、本次红蓝对抗主负责人组织对抗演练启动会、确定对抗演练时间范围、指定实时|离线演练接口人。

第二、实时|离线产品提前邮件|咚咚通知业务用户将进行红蓝对抗演练。

2、人员指定与任务分配

首先指定本次红蓝对抗的主负责人。

负责整个红蓝对抗演练的统筹工作包括方案制定、演练对抗文档落地、场景收集通知及复核、组织攻击方发起及防守方防御过程、演练复盘工作。

其次分别指定实时和离线侧备战接口人。

充当蓝方攻击方主要是指定演练攻击场景、发起系统攻击。

再次分别指定实时和离线侧backup兜底人员。

一般为核心研发人员由于发起攻击的具体时间是不确定为避免蓝方发起攻击后红方由于各种特殊原因不能及时处理故障导致影响线上正常业务backup兜底人员可快速的恢复系统。

最后分别指定实时和离线侧演练监测员。

一般为测试人员主要是记录演练过程中发出的告警信息mdc、ump以及复核演练记录文档。

3、演练前场景收集

该部分是演练前最重要的环节主要包括确定演练应用范围、确定攻方演练场景。

3.1、确定演练应用范围

演练应用建议优先选取应用等级L0和L1的应用具体可根据业务需要进行选取。

另外可通过以下两种方式快速查询对应的应用

http://XXX.jd.com/dashboard/4/node/XXX

详细演练应用列表由实时|离线接口人经过C3领导复核通过提供输出攻方批量注入场景收集

3.2、收集演练故障场景

cpu使用率高、内存使用率高、磁盘使用率高、网络延迟、网络丢包、进程终止、mysql请求延迟异常、jimdb请求延迟异常等。

底层集群

主要是运维人员通过脚本、命令等方式进行故障注入。

主要包括以下演练场景

数据库实例CPU打高、hdfs队列打满、计算任务pending、RSS集群繁忙、zk节点宕机异常等。

有了演练场景产品也发送了演练通知邮件后就可以进行红蓝对抗了。

这里要说明几点

全体成员

今天17:3021:30大数据平台实时离线进行红蓝对抗演练不定时进行故障突袭。

请各位同学将跟进处理过程在本群进行同步。

每个环节问题发现、故障诊断、故障处理确定后立马发消息不要最后发总结

每个环节问题发现、故障诊断、故障处理确定后立马发消息不要最后发总结1、问题发现

【问题发现】

产品-服务名称xx问题已处理已恢复并给出告警恢复/监控截图。

4.2、【蓝方】创建执行演练任务

蓝方在混沌工程平台按照之前收集的演练场景创建演练任务或批量创建演练任务。

如下图

网络延迟、丢包故障可能演练失败原因限制网络故障演练该宿主机内核版本存已知BUG不能演练

演练时长建议大于5分钟原因有些应用配置的mdc报警周期范围是5分钟内如果演练时长小于5分钟可能收不到报警。

4.3、【红方】防守修复故障

蓝方发起攻击后红方会收到咚咚报警按照既定预案进行故障修复。

部分截图如下

4.4、【红方】系统恢复

有些演练场景进程终止不会自动恢复需要红方手动重启系统应用服务确保生产应用服务均正常。

4.5、【红方蓝方】演练结束

红蓝对抗演练结束后红蓝双方均填写“红蓝对抗演练场景”文档蓝方填写混沌任务链接、混沌演练场景、演练状态、混沌演练执行开始时间、混沌演练执行结束时间。

红方填写排查人、告警信息、根因、排查到原因时间、排查过程描述包含排查过程使用工具辅助决策判断、计划解决方案应急预案、预估影响

5、演练结果收集主负责人复核演练结果、梳理分离演练问题让红蓝双方尽早完善。

主要存在以下问题

**1)

处理不完整**红方处理完ns失败问题后未通知用户处理失败任务。

未收到报警

未触发告警阈值。

例蓝方攻击时cpu利用率90%但mdc报警规则配置的是95%。

mdc平台禁用告警。

例mdc暂时禁用了模版中心的MDC监控与告警。

6、演练复盘

主负责人组织红蓝对抗复盘会议提供演练结果、问题列表实时离线架构师均参加从演练过程、演练效果等角度对本次演练进行评价或建议。

告警级别需要自查修正。

目前部分告警级别配置偏低cpu利用率大于90%时报【警告】建议改为【紧急】。

延长攻击时间。

找某几个应用攻击时间为30分钟验证防守人员是否真正摘流量。

混沌演练常态化。

可通过混沌工程平台-常态演练进行并结合值班表增加演练频次以战养兵。

分步演练【警告】、【紧急】场景。

第一步先攻击10分钟触发【警告】的场景第二步再攻击10分钟触发【紧急】的场景。

java方法异常、延迟场景未演练。

后续期望测试人员通过forcebot压测来支持流量流入。

可提高创建任务效率目前的批量创建演练任务功能只能一个一个的添加应用进行创建。

混沌工程平台提供常态化混沌演练api。

方便用户自定义创建常态化演练任务。

混沌工程平台支持在平台内查看mdc、ump告警。

减少用户在多个平台系统来回切换。

四、总结

通过本次红蓝对抗演练既有效的增强了大数据平台系统应用的抗风险能力降低了生产环境系统发生故障的概率又大大的提升了研发人员解决问题故障的能力也沉淀了一套快速高效的演练的方案。

作者京东零售