前言
软件设计处于软件工程中的核心地位，开发不管采用何种开发模式，都离不开软件设计。当需求分析完成后进入设计阶段，设计的好坏直接影响着软件的质量。好的设计方案能够让团队有一个清晰的愿景和路线图，作为技术领导力让整个团队更容易协作。设计方案的制定需要多方参与，需要网络工程师、架构师、数据库管理员、安全等角色多方评审，确保功能需求、非功能需求和约束能够被满足，好的设计是开发出高质量软件的基础。
设计、架构与安全
从软件开发生命周期的角度，软件设计可以看作是从软件需求规格说明书出发，根据需求分析阶段确定的功能，设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法等内容，形成软件的具体方案，从整体到局部，从概念设计到详细设计。软件设计的工作包括：应用架构设计、网络架构设计、接口设计、角色权限设计、流程设计、数据库设计、界面设计等。
所有的架构都是设计，但并非所有设计都是架构。设计方案需要考虑到成本、许可协议、技术战略、兼容性、用户习惯。产品经理纠结于用户需要什么功能，却比较少关注非功能需求和约束，往往会模糊地给出“快、稳定、安全”的主观要求。安全作为方案评审中的重要角色，需要评估复杂又抽象的方案，要求比较高的综合能力，确保安全风险可防可控的情况下满足实际业务需求。
应用架构设计
应用架构关注的是宏观结构，其含义是把软件从结构上分解为多个通过一定关系联系的构件，常见的应用架构是两层架构和三层架构。
两层架构分为应用层和数据层，应用层承担信息展示及逻辑处理，数据层负责数据存储和管理。图示如下：
三层架构分为表示层、业务逻辑层和数据层，表示层承担信息的输入输出和展示，业务逻辑层承担业务处理，数据层承担数据的存储和管理。图示如下：
通常来说，三层架构比两层架构安全，不同分层直接的访问需要进行身份验证，如业务逻辑层验证表示层的用户账号密码，数据层验证业务逻辑层的数据库账号密码。三层架构的业务逻辑层承担对用户数据和权限的校验，合理的接口设计可以将大部分非法请求拒绝。接口设计需要考虑防重放攻击、防数据篡改、防信息泄露、防未授权访问、防程序化攻击(爬虫、条件竞争)等风险，可以通过时间戳timestap+签名sign+token+ssl的常见技术来对接口进行安全设计。
网络架构设计
网络上按照区域通常分为内网、外网和DMZ区域，内网主要是办公区、管理区、数据存储区和专用区，比如银行的现金业务和非现金业务需要隔离，需要设置专用区，外网主要是客户和合作伙伴、DMZ是内外网之间的缓冲区。如下是常见的web应用网络架构设计：
在进行安全设计时需要考虑到不同网络区域的安全级别不同，比如DMZ区是不安全的区域，不能保存敏感业务数据，外网文件传入内网需要进行病毒扫描，内网文件上传到外网需要进行敏感信息检测，另外一些特殊应用需要划分VLAN，达到逻辑隔离的目的。
角色权限设计
应用的角色权限设计需要满足两个原则：最小权限和职责分离。每个角色应该有明确的职责，只能分配必要的权限，权限需细化到读、写、删除、执行等具体操作，这样可以避免过分授权。重要的操作需要分解为两人以上执行，降低不当操作带来的风险。比如数据录入角色只能写数据，数据复核角色只能读复核的数据，不能修改。另外系统默认账户角色需禁用，特权账户角色需开启双因素认证，避免密码丢失或默认密码带来的安全风险。
通过限制不同用户的权限可以有效降低攻击面。
流程设计
业务流程设计上需要避免常见的业务安全风险，如账号注册流程如果不对用户的信息进行严格验证可能出现羊毛党批量注册养号风险，登录流程可能出现撞库、暴力破解风险，支付流程可能出现虚假交易、洗钱套现风险，营销活动流程可能出现黄牛屯号、薅羊毛风险。业务流程设计需要考虑到各种可能出现的场景，结合目前黑灰产的特点对薄弱环节进行加强，提高攻击者成本。
其他设计如数据库设计需要做好数据库的分离，数据库用户权限需做好设置，避免应用系统使用root用户访问数据库。界面设计需要避免一些不安全的功能界面，如执行自定义sql语句、shell命令的调试功能等。
安全设计检查表
安全设计评审需要投入大量人力，而且周期很长，需要不断的访谈，收集信息，项目的需求文档，架构设计图，流程图等，而常见的安全设计问题是可以通过汇总形成checklist然后逐项检查的，checklist包括身份认证、权限控制、日志处理、数据验证、数据加密、数据签名等检查项，以下是部分示例：
安全设计检查表可以帮助评审人员快速对设计方案进行检查，但缺失针对性，无法做到个性化定制，因此只能作为过渡，还需要进一步探索更贴近业务的评审方式。
威胁建模
目前免费的威胁建模工具多数是客户端软件，如微软和owasp都推出了威胁建模工具，缺点是只能单机安装，不利于团队协作，另外英文的威胁描述和安全控制方案很不友好，无法直接推送给产品经理和架构师做方案设计参考。
最终基于web前端技术实现了在线威胁建模，可以针对不同的业务线定制安全威胁库和消减威胁建议库，实现针对性的安全设计评审。这里没有严格按照微软的威胁建模方法，而是基于团队的习惯进行应用架构、业务流程和角色权限的威胁分析，如下示例：
黄色标识资产，红色标识威胁，绿色标识安全控制措施
应用架构威胁分析：
业务流程威胁分析：
角色权限威胁分析：
最终汇总的威胁分析结论如下：
总结
安全设计评审是SSDLC的重要环节，虽然有威胁建模工具可以辅助分析，但这些工具多是国外的，威胁库的设计和描述对国内用户很不友好，而且作为单独的软件无法与其他版本管理工具集成。将威胁建模过程进行适当改动可有效地落地安全设计评审活动，将威胁建模分析可视化、规范化，后续的安全测试环节也可以参考历史的评审结论进行针对性测试。
