05 看懂其他设计师的技术方案

不是问题的问题

  看懂其他人设计师的技术方案对于技术人员来说都不屑于讲的问题，说句调侃的话，对于有节操的程序员这个问题都不好意思提这个问题。当然也有人想这个问题其实每个人都要解决的，不光是安全架构设计师，要不然是没有办法合作的。我这个里想强调的是开发团队内部由于在开发的过程中有非常多的交流，对于方案的理解不是很依赖或者说就不依赖设计的文档的，很多设计文档都是事后的总结，但是对于安全架构设计师通常就没有那么频繁的交流机会了.

读其他人设计方案的误区

  与开发团队的资源不同，安全架构设计师可是不会分为Java、C/C++、.Net等等这么多的资源的，我们不得不做到兵来将挡水来土掩，Java问题需要处理，C/C++项目也要参加。同时项目不可能等我们先学习.Net语言之后再做安全设计或者评估.
    误区一：关注开发语言的细节（语言的特性必须依赖于具体开发的能力已经和开发合作）
  技术方案中大部分内容是说明功能模块的，并且功能模块的定义往往是考虑开发的便利性的（康威定理），所以想从这份已功能视角的技术方案中提取安全问题和方案是有不少困难的。
    误区二：过分关注功能实现细节
    误区三：按照开发的思路分析设计文档

分两步走看技术方案的方法

  1,重新组织设计方案，将逻辑模块归类为路由，注册，认证，授权，数据的生命周期管理，系统的生命周期管理。生命周期指的是从出生到消亡。
  2,带着安全的问题列表检查第一步重新编组过的设计方案。

卖个关子

  具体如何操作上述两个步骤后期将会说明.

本节思考

  1，你自己是如何读其他人的方案的，碰到过什么问题？

传送门

  
  安全架构设计师成长路上的三维坐标系