1. 源起
在创业进程中，可能最开始我们会想着快速上线，一些性能、可用性或安全的问题是有时间就搞搞，没时间就放着；或者对于用户的一些异常行为，一些薅羊毛的行为没有特别的关注；又或者对于用户上传的个人资产没有做特别安全的隔离或保护等等。虽然现在看起来都没有引发大的问题，但是这些都是应用安全隐患，都是隐藏的雷，一旦被公众引爆，将惊天动地。
从更大的层面看应用安全，根据咨询公司 Gartner 统计数据显示，超过 75% 的安全攻击发生在代码应用层面。
Forrester 2020 年发布的调查报告 《 Forrester Analytics Global Business Technographics Security Survey，2020》中显示，在 480 家全球企业已经确认的外部攻击中， Web 应用程序和利用丢失/被盗资产，软件漏洞分别位于第1，2，4名，占比达到了 39%、35% 和 30%，其中软件漏洞主要指对于安全漏洞的利用攻击，攻击 Web 应用程序主要指基于程序的 SQL 注入、跨站脚本攻击、远程文件包含等。具体如图 1 所示：
从上图来看，应用安全，资源保护是目前我们安全防护的最佳切入点。
应用安全是应用级别的安全措施，旨在保护应用内的数据或代码免遭窃取和劫持。它涵盖了在应用开发、设计、测试、部署，上线后运营期间等发生的安全注意事项，及相对应的保护系统和方法。我们主要解决应用层和数据层的问题，网络层，物理层的问题不在本文的讨论范围之内。
从创业过程来看，我们有哪些数据泄漏的问题，我们有哪些敏感信息很容易被人看到，我们运营活动上线后有没有被薅羊毛，我们的用户里面有多少是机器注册的，我们的系统存在多少应用级漏洞，黑产是不是可以无门槛或门槛很低的获取到我们的数据或资源，我们的新业务上线时有没有东西能保证其是安全靠谱的，我们有没有办法及时发现这些问题并解决这些问题，从流程，机制，工具，系统各个层面，这就是我们这里所说的应用安全体系。
1.1 是什么
- 是在部署常用防御工具和手段（比如防火墙、WAF 和 IDS 等）的基础上我们能做的流程、机制，工具、系统；
- 是要在应用层面，去解决我们工作中经常会碰到的安全问题；
- 是我们有意识的，主动的发现应用中的安全问题，发现用户的行为异常，业务异常，并给予解决。
1.2 不是什么
- 不是公司的安全防御体系；
- 不解决非技术安全相关问题；
- 不解决所有的安全问题；
- 不解决安全合规的问题；
- 不解决超大规模类 DDoS 攻击的资源性攻击。
2. 安全问题梳理
这里我们从外部安全和内部安全来看可能面对的安全问题，外部是指对外的服务，内部是指企业内部的管理和控制，这里通过一些问题来反思现状。
外部安全
后台安全
存储安全
系统备份和恢复
如果现在数据库被人删了，怎么办？如何快速恢复？
如果现在代码全部被人删了或者 github 的账号完全不可用了，怎么办？如何快速恢复？
如果现在阿里云的账号被封了，怎么办？如果有备用的账号，如何快速切换？
配置存储
如果配置中心挂了，有没有办法快速恢复？
账号密码安全如何防护，代码配置中有吗？现在线上环境 apollo 的权限控制如何？
MQ安全
是否有必要的业务隔离？
如果突破内网，是否有一定的鉴权逻辑？
服务安全
对外服务
身份鉴权/访问控制
用户资源安全（资产保护）
用户资源是否有访问鉴权？
用户资源或资产是否存在越权访问的情况？
安全审计
对用户的登录、注册和交易日志的审计
对系统资源的异常使用的审计
对重要系统功能的执行等的审计
对其它重要用户行为的审计
通信保密性
传输通道加密
内容加密
传输加密（密钥是否存在漏洞的可能？）
抗抵赖
日志保留 6 个月
操作详细流水日志
容量安全
各服务的 QPS 上限，容量评估
资源消耗类服务的容量安全，是否存在很容易的攻击行为，如一些上传文件后的解析或者 AI 识别之类的
MQ / DB 等是否有业务隔离和容量
容错
出错信息保护
部分出错降级
对内服务
身份鉴权/访问控制
服务间/接口访问控制
服务间鉴权
调用方身份识别
抗抵赖
详细调用日志
应用生命周期的管理和隔离
数据（包括用户数据）的管理和隔离
安全框架
资源安全
商业化资源业务风控
用户账号风控
活动地址，接口地址，兑换码防穷举遍历
在活动流程和规则上提高薅羊毛的门槛，形成规范
数据安全
数据量级泄漏
业务数据泄漏
敏感数据泄露
防拖库、撞库
前台安全
应用安全
代码混淆
应用加固
安全密码控件
敏感资料保护
防代理
常见 Web 攻击
SQL 注入
CSRF
XSS
爬虫
接口安全
SSL 加密传输
参数加密
防恶意调用，频控，降级
账户安全
身份验证
登录验证码
超时控制
单点登录
防信息泄漏 内部安全
管理后台安全
严格且精细的权限控制
商业化资源需要有审核流程，更细的权限控制，只能看到自己创建或者自己有权限的
敏感信息（用户/订单/商业化）需要有针对敏感信息查阅的追溯手段和管控措施（是否考虑形成日报上报）
对于钱相关的资源需要有监控和视图
代码和部署安全
核心代码是否有专人管控
上线的代码是否有必要的审核或 Review
是否配置如同代码一样管控
CI / CD 系统是否有必要的权限控制和安全管控
CI / CD 流程是否实现自动化
CI / CD 流程是否有必要的安全保护策略，如签名和密钥
如图 2 所示：
3. 如何建立应用安全体系
业界应用安全体系的建立有两主流方法论：一个是 SDL，另一个是 DevSecOps。
3.1 SDL 简介
SDL 是由微软最早提出的概念，安全开发流程（Security Development Lifecycle），在需求分析、设计、开发、发布所有阶段都引入安全和隐私原则，帮助解决软件安全问题，重点在于开发阶段，而安全培训是 SDL 最核心的概念。
SDL 大概流程如图 3 所示：
3.2 DevSecOps 简介
DevSecOps 是”开发、安全和运营”的缩写。它是一种文化取向、自动化方法和平台设计方法，将安全性作为整个 IT 生命周期的共同责任。 DevSecOps 的出现是为了改变和优化之前安全工作的一些现状，比如安全测试的孤立性、滞后性、随机性、覆盖性、变更一致性等问题；通过固化流程、加强不同人员协作，通过工具、技术手段将可以自动化、重复性的安全工作融入到研发体系内，让安全属性嵌入到整条流水线。
DevSecOps 是应用安全 (AppSec) 领域一个相对较新的术语，通过在 DevOps 活动中扩大开发和运营团队之间的紧密协作，将安全团队也包括进来，从而在软件开发生命周期的早期引入安全。这就要求改变开发、安全、测试、运营等核心职能团队的文化、流程和工具。基本上，DevSecOps 意味着安全成为共同的责任，而参与 SDL 的每个人都有责任在 DevOps CI/CD 工作流中构建安全。把安全融入到敏捷流程中，使得敏捷性与安全性并重。
DevSecOps 在软件开发生命周期更早期切入安全相关内容，就能更容易的收敛安全问题，让安全问题的解决成本更低，暴露在线上的完全问题更少。
DevSecOps 的过程有三个关键要素：
- 授权(empowerment)
- 赋能(enablement)
- 教育(education)
授权或者放权，将控制权下放给团队，团队在理性分析的前提下，做出独立决定而不用害怕失败或影响。这里的团队成员不仅仅有开发，还有商务，产品，安全，QA 等等，所有项目成员都是奔着同一个目标：打造自己的产品。
赋能是指正确的使用掌握在团队手中的工具和资源，使其具体可操作性，如打造一种注重自动化、通过工具来解决重复任务，并尽可能减少以后的操作并增强安全性的理念。赋能不仅仅是提供知识和工具，而是让这种知识和工具能够通过多种渠道和媒介可快速获取且好用，以便它可以被团队或是个人以他喜欢的方式去使用和分享。
教育，在团队中建立安全文化，通过分享和培训让所有的成员都具备安全意识和技能是整个过程中最重要的点。
最终 DevSecOps 落地时，对整个研发团队的要求是这样的：
- 安全测试由研发团队完成；
- 测试期间发现的问题由研发团队管理；
- 线上安全问题由研发团队负责处理；
- 解决安全问题的责任在于研发团队。
3.3 选择适合自己的
SDL 相对于 DevSecOps 更偏于传统，如果要严格执行起来，其存在流程重、人员要求重等问题，一般是需要有专职的安全团队来执行。 但是要想直接达到 DevSecOps 的理想状态对于一个新创业的团队来说也是不现实的。
对于一个创业公司，可能需要更敏捷一些的方式，让敏捷性和安全性并重，所以我们更倾向于在 SDL 的基础上，融入部分 DevSecOps 的手段。
3.3.1 核心理念
- 研发团队对安全负责，一切安全问题都是研发团队的问题，专门的安全团队只提供技术支持和技术培训（可以适当花钱请第三方专业机构），规避安全信息共享壁垒和在有专职开发团队时，开发绕过安全监管等情况；
- 研发流程中全链条增加安全环节，安全不再是流程外的冗余流程，安全可以做轻，但是必须要有，特别是核心的逻辑，将安全前置；
- 专职的安全团队从实战的角度，以攻击者的角度来发现问题，反馈给研发团队自己解决（提供标准解决方案），反向考核整个研发团队的安全绩效；
- 建立高效的 SRC。
3.3.2 SDL 通用版
安全培训
｜ 安全概念、威胁评估、WEB 安全、安全测试及隐私保护
提高全体项目人员的安全意识
进行安全培训
需求分析
｜ 建立安全标准；创建安全指标；风险点评估
确定安全需求标准，制定安全需求表，供后续开发检测
设计阶段
｜ 建立设计方案标准；提出安全方案；风险评估建模
建立技术方案安全标准
对不同的业务形态提出不同的安全方案
建立风险评估模型
开发阶段
｜ 使用安全的工具、弃用不安全的函数或方法；静态扫描
使用安全的工具：包括开发团队使用的编译器，框架，组件等
弃用不安全的函数或方法
｜ 安全规范编写代码，并在开发过程中对代码进行 Review
静态分析
｜ 对代码进行安全脆弱性分析和渗透性测试
测试阶段
｜ 动态安全扫描；模糊测试；评估安全方案
动态分析（其实就是黑箱测试）- QA
模糊测试
｜ 故意向应用程序引入随机不良数据及格式，诱发程序产生故障。模糊测试的基础是必须了解熟悉程序的功能状态、设计规范等
代码审计 - SRE
｜ 代码安全扫描，开发过程中，开发人员每次更新代码都要进行扫描，并有权限查看相关项目漏洞情况，进行整改（不允许有中高危以上漏洞）。开发有权对漏洞进行忽略处理，但需要承担相应后果。若不知道如何处理，可请安全组提供解决方案。
WEB 应用扫描 - QA
人工渗透扫描 - 第三方专业安全团队
部署阶段
｜ 应急响应计划或预案；安全流程确认；发布归档
明确安全应急响应计划
构建发布流程工具卡点 AST 工具集
静态应用安全测试 (SAST)
软件组件分析 (SCA)
交互式应用安全测试 (IAST)
动态分析测试 (DAST)
发布归档
线上阶段
｜ 执行线上应急响应流程
第三方专业安全团队发现问题
安全问题等级制度
安全问题响应流程
脑图如图 5 所示：
3.3.3 我们现在可以做什么
在项目早期进行如下的投入是合适的，并且只需要开发同学的增量工作来保持良好的测试覆盖率和持续的构建
- 单元测试和集成测试的覆盖范围要足够全面，以确保生产版本的缺陷风险低到可接受的程度，而不需要主要依赖人工进行的质检工作；
- 本身安全可靠的 CI/CD 流水线；
- 经常使用的、可靠的基础设施，可用于分开部署生产环境的回滚；
- 允许代码和配置分开交付的软件架构，如配置中心。
应用安全是一个系统化的，长期的工程，对于现在的我们来说，不可能一次全链条都上，也不可能一次性的把大家的安全意识提到理想的水平。如何在保障业务快速发展的前提下，兼顾安全防护是当下我们需要考量的问题。
参照 SDL 通用版，建立较好的流程规范，安全问题等级制度和响应流程。有必要的话请第三方安全团队作为专职安全团队，定期对公司内外部做安全扫描，参照安全问题等级制度和响应流程，处理线上的问题，并且反向考核现有公司内部研发团队的安全绩效。同时研发团队在流程和意识上逐步增加安全卡点，提升开发过程中的安全质量，通过一些初步的安全工具链，快速自动识别安全问题。
4. 结语
以上纯属个人对现有应用安全的理解，供大家参考，有错误或不明确的地方欢迎指正，有更好的更完善的方法，欢迎评论探讨。
最近在看一本书，里面有一句守夜人的誓言：“若暗夜终临，吾必立于万万人之前，横刀向渊，血染天穹”，而安全于业务就是那个立于万万人之前的我们。
5. 参考资料
- https://zhuanlan.zhihu.com/p/146149814
- https://zhuanlan.zhihu.com/p/73675141
- https://www.jianshu.com/p/ba886a6a28d8
- https://cloud.tencent.com/developer/article/1587312
- https://www.whitesourcesoftware.com/wp-content/media/2021/04/forrester-report-the-state-of-application-security-2021.pdf
除了眼前的苟且,还有架构与远方。
介绍创业路上的技术选型和架构、大型网站架构、高性能高可用可扩展架构实现，技术管理等相关话题，紧跟业界主流步伐。
