前言
随着时间增长, 看事情的思路也会产生一些变化。回顾之前作安全架构评审时的一些思路和细节, 同现在对比来看, 又有了些许思考。记录于此, 以飨读者。
架构基础
你可能会下面列的东西觉得有点虚, 但是根据经验总结来看, 一个称职的安全架构师确实需要具备这些能力。当然这并不意味着你需要在一开始就具备所有的知识。但如果你遇到的安全架构师不具有这些知识并且没有去了解的欲望, 那么很大程度上, 他并不会是一个合格的安全架构师。当然这些也只是一家之言, 权作参考。如有不同，亦可邮件交流。
职业相关
- 基础的软件工程知识, 例如敏捷开发, 软件研发流程等等;
- 基础的架构知识, 例如: SOLID原则, 组件化架构, 微服务, SOA等;
- 资深的基础安全知识和风险识别能力, 例如: 网络安全风识别及解决方案, SDL解决方案等;
- 熟练掌握基础安全涉及到的相关产品知识, 例如: waf, hids类的解决方案实现等;
资深的安全研发知识, 例如: OWASP TOP10在具体编程语言加固的编码实现;
安全架构师最好还能具备带领团队你研发安全工具的能力, 不过这一项根据具体企业内的需可能不是至关重要的一项。
企业相关
- 企业内部的研发体系流程, 例如: 语言栈, 发布周期, 发布系统, 基础类库, 中间件等等;
- 企业内部的基础设施部署, 例如: 网络规划, 服务器位置, 云上VPC划分等;
- 企业内部的组织架构, 例如: X端研发Leader, 项目经理, 产品负责人等;
安全架构
解决方案
解决方案关注的点比较多, 从评估到设计以及实施和运营等。从此处不打算介绍完整的解决方案设计流程, 仅仅谈一谈安全架构在输出解决方案时的技术关注面。
架构是个大的层次, 除却架构设计原则之外, 浅显的来看安全架构本身依托于应用架构, 网络架构, 业务架构。这也就是说至少有三个层面需要考虑, 基础设施, 应用以及业务。 具体差不多就是在基础设施之上用户通过应用访问业务时所涉及到的交互。这个应用可能是web应用, 也可能是pc应用, 亦或是Mobile应用等（一般来说对外是一个应用, 对内其实是由若干个应用组成的）。安全架构则要关注两端端内以及两端之间的架构安全。常见的关注点有以下部分:
- 业务交互流程, 其实就是看具体提供哪些功能, 哪些数据, 以什么样的逻辑提供的等等。例如从业务层面去看是否会涉及到敏感数据, 涉及到的数据是否做了处理等等;
- 应用及中间件, 应用及中间件是承载整个业务的具体体现, 也是应用安全和数据安全关注的重点, 从安全研发培训到安全包SDK, 从代码白盒扫描到卡发布，数据的生产是怎么提供给应用，又是怎么被应用消费，如何实现对应的权限控制等等;
- 基础网络架构, 一个请求怎么从客户端到达服务的, 服务直接又是经过哪些路由完成的。这一点可能是个问题所在, 需要注意的是, 软件架构师给到你的评审文档中网络架构图可能仅仅只是他了解到的一部分, 而且更多时候, 他们似乎并不关注;
- 物理部署状况, IDC还是云, 刀片服务器还是ECS？云上的话是IAAS，PAAS还是SAAS，不同形式的部署关注的侧重点亦不同。以及具体的ACL, VPC划分, 网络的规划。安全产品的位置等等都需要考虑;
- 全局稳定性, 是否设定并能够遵循SOP, 灰度机制, 回滚机制等, 用来确保在发生错误时能够缩小受损范围, 并快速恢复问题, 除此之外还要考虑安全产品本身的SLA, 以及引入安全产品后为整个链路增加了多少ms的延时, 是否能够接受等等;
其实这些都是关注在面上, 每一部分除了通用考虑点外还需要结合企业自身的情况, 视研发体系, 运维体系而定。
架构评审
谈安全架构, 就不可避免得要说安全架构师的另一个主要输出点: 架构评审。那么我们首先要知道的是: 安全架构评审的意义是什么？ 最原始的目的可能是为了在项目初期识别潜在的威胁, 提出对应的解决方案。 其次呢？在另一方面也可以看做是为了提升安全团队的影响力。当然, 高质量的输出才是提高影响力, 提高话语权。平常的话也不过只是刷下存在感。文人相轻是自古以来的问题, 即便身处架构师层次, 前后端的领域, 网络领域, 数据库领域以及安全领域的同学也有可能出现自恃“清高”的情况。当然很多时候也可能是由于参于架构评审的安全架构师无法切中要点, 缺乏全局视角以及前文提到的一些预备知识, 更导致安全部门不宜被其他架构师认可。当然安全架构师自身也有一部分的问题, 评审时的关注点过于随意而不够体系, 或者没有不清楚业务的特性也没有提前充分了解以至于沟通时问题缺乏针对性之类。
从SDL视角上来看, 架构评审有问题的话, 也就是SDL的第一步没做好。在知道了架构评审为了什么之后, 还要记住一点就是, 虽然在这个阶段不一定能得到实施, 但要却必须在架构评审阶段提出。那么如何使项目的架构朝着预期方向发展？怎么样才能够更好的输出？我们根据WHY, WHAT, HOW步骤来看下HOW部分:
- 根据PRD文档做设计域风险检查, 针对大型项目做威胁建模
- 分别向研发同学和测试同学输出安全研发和安全测试相关知识
- 在架构评审会时进行确认并输出解决方案或缓解措施
- 引入相关的安全产品,并能够以持续部署的形式提供
- 针对输出的方案进行闭环检验,追踪相关落地情况及漏洞情况
相对于架构师而言, 安全架构师更侧重于安全领域，当然这这不意味着不需要基础的架构知识。那么在做架构评审的时候, 最原始最能最直接了解到业务方的就是PRD文档里相应的架构图了(此处注意业务提供的架构图和全局架构图的差异):
- 业务领域图
- 系统依赖图
- 数据流程图
- 物理部署图
通过以上架构图可以很直接了解业务逻辑, 物理部署, 数据流向等等, 熟练的安全架构师更能直接发现对应的问题点。但想要达到所谓的知己知彼, 百战不殆，仍还依赖于踩坑的经历。(例如业务逻辑架构里使用阿里云ODPS服务进行权限控制，貌似看起来安全，但是很容易忽略掉数据是否进行了打标。如果没有打标，那么这个依托于ODPS的数据流权限控制就存在一定的缺陷。) 在了解整体架构之后, 威胁建模步骤的应该是要首先分解应用程序, 发现外部依赖关系, 找到入口点, 分析服务使用了哪些资产, 因此产生的攻击面, 针对相应的数据流进行分析等。（你他娘的还真是个人才, 说的跟教科书似的）。当然这只是理论，还是要参考设计域, 以及相关Checklist。从系统功能, 系统部署, 系统依赖等等去分析威胁, 威胁建模自古习惯STRIDE, 就不多做介绍了。那么威胁怎么分出轻重缓急呢？具体可以参考微软提出的DREAD。
不过即便能够真正的遵守规范建立起评审机制，但在大公司中, 架构评审的工作依旧可能有不少量。业务迭代变更非常快, 每周都会有几场架构评审, 怎么提升效率呢？
首先把能自动化的自动化掉, 比如说安全产品的部署, 和黑白盒的扫描。其次把不能自动化的能力转移, 相关的能力扩散到测试部门, 研发部门, 使其具有安全属性。让研发懂安全包的使用，并具有安全代码的编写能力，同时让测试部门能够拥有一些基础的渗透测试能力。再最后把既不能自动化也不能转移的能力沉淀出知识库和案例库（踩坑经历的Checklist）。这是第一大步, 第二大步就是追踪结果, 根据结果建立正向的反馈, 驱动或者推动其他团队继续跟着转。
当然还有一些细节没有写, 以及相关的架构评审表也没有贴出来,那么到底怎么样才能算一个合格的安全架构师呢？相信你的心中也有了自己的答案。并且当你具备这种视野的时候, 很多事情自己做起来也没有那么困难。
总结
安全架构并不一蹴而就，企业也不能仅仅依托于渗透测试去完善安全防御的建设。在紧跟技术进步的前提下，更需要能够准确的分辨是否炒作或者跟风。安全架构师作为企业安全部门里的一个重要角色，在具备相应能力的同时，持续学习也是不可忽视的一个方面。希望日后安全行业从业者中能够拥有更多合格的安全架构师。作为一个安全行业的小朋友，也还有许多要学习的地方。一路过来，谢了。