DevSecOps实战_周纪海;周一帆;马松松;陶芬;杨伟强 等_AZW3_MOBI_EPUB_PDF_电子书(无页码)_周纪海;周一帆;马松松;陶芬;杨伟强 等

内容节选

研发与测试阶段改进计划的落地实施,意味着德富银行和灰石网络的DevSecOps推进工作已步入正轨。通过自动化以及安全在研发测试端的融入,产品发布与上线的效率、质量和安全性都有所提高,但是整体交付速度还是被某些瓶颈所限制,同时仍有不少质量和安全问题被暴露出来,而无法实现质的飞跃。那么问题又出在了哪里呢?带着疑问,企业的研发与安全部门联合展开了进一步的探讨。 年中的到来对德富银行往往意味着许多项目实施已经进入了攻关阶段。为了不影响下半年的业务交付目标,每年的6~8月各项目团队都在追赶进度。随着DevSecOps中研发与测试阶段的工具落地,试点团队的项目上线效率有了不小的提高。但仍有不少团队反馈,有部分安全漏洞的修复成本较高,甚至需要推翻原有的功能性设计来做二次开发,一旦遇到这类问题,反而使修复成本更高。各DevSecOps试点团队也十分担心这类问题会影响他们的项目进度,已经有几个项目经理对江宇宁提出了各自的疑虑。 江宇宁心里清楚,项目的安全与快捷本身就处于相互对立的位置,DevSecOps的实施本质上也是帮助项目团队寻找其中的平衡点,不能为了快速交付而忽视安全问题,又不能因为随着交付能力提升有更多安全问题被暴露而导致项目进度受影响。怎么解决这一问题?宇宁的心中似乎早已经有了答案。 “老汪,你觉得现在咱们的试点团队中,哪个项目暴露出来的安全问题比较棘手?” “当然是企业银行这块了,今年他们正在做系统升级转型,许多功能模块都在基于微服务架构进行升级,不少新问题被发现,听说老李那边正头大呢!”汪泉说道。 老汪提到的老李,全名李世成,是企业银行项目团队的负责人,平时他为人颇为风趣,但最近大家见他有些焦虑,按他的话说,他现在扛着团队的DevSecOps转型和业务系统转型两面大旗,不管怎样都得化焦虑为动力了。 “咱们上次讨论的关于设计与架构左移的方案看来可以从老李这边入手了,趁着他们团队正在转型新架构,加上他们在研发与测试方面的转型工作开展得挺顺利,或许咱们的方案可以帮他解决问题。”江宇宁说道。 老汪点了点头,表示赞同。 周三,信息安全团队与企业银行团队的项目例会。“老李,咱们别的就不说了,直奔主题吧!说说你们团队现在的困难。”江宇宁开门见山。 “这不,咱们业务系统升级转型,不少后台功能转微服务架构,但在设计思路上由于前期考虑不够周全,服务拆分后仍采用了单体系统下的传统认证授权模式。加上之前咱们的架构师预估不足,业务需求激增使得微服务的功能模块数量也比之前翻了数倍,导致系统性能受到影响。”老李说道。 “也就是说由于在设计阶段的考虑不足,导致系统的可用性受影响了。”老汪分析道。 “还有呢!”老李又接着说。 “嗯?”宇宁表示疑问。 “由于系统中不少业务数据属于敏感数据,所以在服务间传输是需要进行加密处理的。之前为了方便密钥管理,大量使用了公钥算法,各子服务存储中心服务的公钥,将数据使用公钥加密后再通过链路传输给中心服务器,中心服务器获取密文后再使用私钥进行解密获得明文数据。”老李接着说。 “这思路没错,哪里又遇到问题呢?”宇宁问。 “还是由于之前的预判失误,没想到业务增长导致需要进行加密传输的数据量激增,后果可想而知了吧!”老李苦笑了一下。 “由于公钥加密算法的开销较大,一般仅用于小规模或关键数据运算,但像你们这么大规模的数据运算,势必直接导致你们中心服务器的运算开销增大,性能再次受到影响。”宇宁说。 “你们之前没有考虑到该类型敏感数据属于业务数据,数据量会随着业务增长而增长吗?”老汪接着问。 “所以我们也承认这确实是设计缺陷,为了方便密钥管理而忽视了数据量带来的计算开销影响,导致使用了不合适的算法。”老李回答道。 “其实对于这类业务数据,我们一般会建议项目团队使用对称加密算法,然后将密钥管理及运算的工作交由运营中心的硬件安全模块HSM来进行。”宇宁接着说。 老李叹了口气:“可不是么,这就是雪上加霜啊!” 老汪边听边思索着说:“按照以前传统SDL的流程,你们做完系统设计后会交由咱们信息安全部门进行审查,进行安全风险评估,帮你们找到潜在的系统威胁及风险。但由于咱们两边各司其职,并没有很好地协作,咱们安全团队也不熟悉你们的业务场景,所以在威胁及风险的判断上有许多方面考虑不周全。” “这次服务性能下降的问题,在信息安全范畴里显然属于系统的可用性受到了影响,应该在评估当中有所预判,但很明显由于你们那边的设计缺陷,再加上我们这边不熟悉你们的业务场景导致了该问题的发生,而后期修复起来成本也很大。”宇宁接着分析。 “是这个道理。”老李点了点头。 “其实针对设计与架构安全审查的左移计划咱们信息安全部门这边也已经制定好了。在整个DevSecOps的实施过程中,我们首先帮助项目团队实现了研发测试的安全左移,但这是不够的。如果说安全测试针对的是如何发掘产品中的安全漏洞......

  1. 信息
  2. 作者简介
  3. 前言
  4. 第1章 DevSecOps的演进与落地思考
  5. 1.1 DevOps简介
  6. 1.2 DevSecOps简介
  7. 1.3 互联网行业推动DevSecOps的动机与目标
  8. 1.4 金融行业推动DevSecOps的动机与目标
  9. 1.5 总结
  10. 第2章 DevSecOps的实施解决方案和体系建设
  11. 2.1 DevSecOps现状调研
  12. 2.2 流程和方法论:敏捷开发与CI/CD
  13. 2.3 技术:工具与自动化
  14. 2.4 文化与组织结构
  15. 2.5 DevSecOps框架与模型的建立
  16. 2.6 总结
  17. 第3章 DevSecOps转型——从研发入手
  18. 3.1 安全意识和能力提升
  19. 3.2 安全编码
  20. 3.3 源代码管理和安全
  21. 3.4 持续集成
  22. 3.5 代码质量和安全分析
  23. 3.6 制品管理及安全
  24. 3.7 总结
  25. 第4章 持续测试和安全
  26. 4.1 持续测试——DevOps时代的高效测试之钥
  27. 4.2 测试执行提效之自动化测试
  28. 4.3 测试执行提效之精准测试
  29. 4.4 测试流程提效:迭代内测试
  30. 4.5 持续测试下的“左移”和“右移”
  31. 4.6 应用安全测试左移
  32. 4.7 DevSecOps影响着测试的方方面面
  33. 4.8 总结
  34. 第5章 业务与安全需求管理
  35. 5.1 业务功能需求管理
  36. 5.2 安全需求管理
  37. 5.3 总结
  38. 第6章 进一步左移——设计与架构
  39. 6.1 为什么需要微服务架构
  40. 6.2 微服务拆分与设计
  41. 6.3 微服务开发与组合:微服务开发框架
  42. 6.4 微服务改造:单体系统重构
  43. 6.5 安全设计与架构安全
  44. 6.6 快速检查表的使用
  45. 6.7 完整风险评估——威胁建模
  46. 6.8 合规性检查
  47. 6.9 总结
  48. 第7章 DevSecOps运维和线上运营
  49. 7.1 配置和环境管理
  50. 7.2 发布部署策略
  51. 7.3 持续监控和安全
  52. 7.4 日志分析
  53. 7.5 事件响应与业务的连续性
  54. 7.6 身份认证和访问控制
  55. 7.7 数据管理和安全
  56. 7.8 安全众测
  57. 7.9 红蓝对抗
  58. 7.10 DevOps平台的安全
  59. 7.11 RASP
  60. 7.12 总结
  61. 第8章 DevSecOps度量体系建设
  62. 8.1 持续反馈和度量驱动
  63. 8.2 度量指标的定义与成熟度模型
  64. 8.3 度量平台的建立、安全管控和可视化
  65. 8.4 度量实践常见的问题和误区
  66. 8.5 实践中如何正确使用度量
  67. 8.6 研发效能度量实践
  68. 8.7 总结
  69. 第9章 云原生场景下的DevSecOps应用
  70. 9.1 云原生带来的新变化
  71. 9.2 云原生DevSecOps实施流程
  72. 9.3 云原生DevSecOps相关安全工具
  73. 9.4 云原生DevSecOps的落地应用和演进趋势
  74. 9.5 总结
  75. 后记
  76. 参考文献