1. 概述

信息系统的安全运行关系到业务的安全，而完善的安全功能设计是保障整体系统安全性的前提，参考软件开发生命周期的各阶段分组，并在其中嵌入了针对安全保障的各类手段和措施，以确保该系统在最终的需求、设计、开发、测试、发布各阶段均能满足下列业务系统安全目标：

• 登录过程防假冒以及信息泄漏；
• 交易过程防假冒、防抵赖以及防止信息泄漏；
• 保障系统可用性。

此次业务安全需求分析进行了下面具体活动：

• 需求收集，包括合规需求、安全体系框架和安全指南参考；
• 需求分析；
• 安全功能规范框架形成；
• 安全功能规范。

通过最终形成的安全功能规范，可以从需求和设计的角度分析系统在设计阶段前需要明确的各类安全要求，并最终形成统一的功能规范框架；通过对每一条具体功能需求的满足，以确保其安全概要设计和具体设计细则能够真正从企业业务安全需求出发，并全面有效地控制网上交易系统可能面临的风险。

2. 需求收集

需求收集的路径包括行业指引、国际标准、合规要求以及最近安全指南。

2.1. 行业指引《网上基金销售信息系统技术指引》

《网上基金销售信息系统技术指引》，经征求监管部门及行业机构意见建议，并经协会理事会审议通过，自2025年1月1日起正式实施。其中对象包括门户网站、系统投资者端和系统服务端三方面。目的是为了保障网上基金销售的保密性、完整性和可用性。

以下是与安全相关的内容截取：

2.2. 国际标准《ISO/IEC 27002：2022》

为确保以体系化的方式全面识别和分析系统可能存在的风险，并结合系统的业务特点与防护需求，在需求收集阶段采纳了ISO/IEC 27002：2022的指导原则。

• 8.25 安全开发生命周期
• 8.26 应用程序安全要求
• 8.27 安全系统架构和工程原理（在开发生命周期中安全设计、实施和运营信息系统）
• 8.28 安全编码
• 8.29 开发与验收安全性测试（上线前安全测试）
• 8.30 外包开发
• 8.31 开发、测试和生产环境的隔离

2.3. 合规要求《等级保护》第三级安全计算环境设计技术要求

• 用户身份鉴别
• 自主访问控制
• 标记和强制访问控制
• 系统安全审计
• 用户数据完整性保护
• 用户数据保密性保护
• 客体安全重用
• 程序可信执行保护

2.4. 安全指南《OWASP Top 10 for 2021》

2025版本预计2025年上半年发布

A01：2021-访问控制失效；94% 的应用程序经过某种形式的访问控制失效测试。映射到访问控制失效的 34 个常见弱点枚举 (CWE) 在应用程序中的出现次数比任何其他类别都要多。

A02：2021-加密故障；之前称为敏感数据泄露，这是一种广泛的症状，而不是根本原因。这里重新关注的是与加密相关的故障，这种故障通常会导致敏感数据泄露或系统入侵。

A03：2021-注入；94% 的应用程序经过某种形式的注入测试，映射到此类别的 33 个 CWE 在应用程序中出现次数排名第二。跨站点脚本现在在本版中属于此类别。

A04：2021-不安全设计；重点关注与设计缺陷相关的风险。如果我们真的想让行业“向左发展”，就需要更多地使用威胁建模、安全设计模式和原则以及参考架构。

A05：2021-安全配置错误；90% 的应用程序都经过了某种形式的配置错误测试。随着越来越多的人转向高度可配置的软件，这一类别的上升并不奇怪。以前的 XML 外部实体 (XXE) 类别现在属于这一类别。

A06：2021-易受攻击和过时的组件；默认漏洞和影响权重 5.0 被计入其分数。

A07：2021-识别和身份验证失败；现在包括与识别失败更相关的 CWE。

A08：2021-软件和数据完整性故障；侧重于在未验证完整性的情况下做出与软件更新、关键数据和 CI/CD 管道相关的假设。这是通用漏洞和暴露/通用漏洞评分系统 (CVE/CVSS) 数据中权重最高的影响之一，映射到此类别中的 10 个 CWE。2017 年的不安全反序列化现在已成为这个更大类别的一部分。

A09：2021-安全日志记录和监控故障；此类别已扩展，包括更多类型的故障，测试起来具有挑战性，并且在 CVE/CVSS 数据中没有得到很好的体现。但是，此类别中的故障可能会直接影响可见性、事件警报和取证。

A10：2021-服务器端请求伪造。数据显示，发生率相对较低，测试覆盖率高于平均水平，漏洞利用和影响潜力的评级也高于平均水平。此类别代表了安全社区成员告诉我们这很重要的情况，即使目前数据中没有说明这一点。

3. 安全需求框架

通过对来自于行业合规要求的收集，参考ISO27002：2022、等级保护等体系框架、网上基金销售信息系统技术指引以及OWASP Top 10 for 2021形成来自于适用于系统的安全要求。

业务安全需求框架

4. 系统安全功能规范

4.1. 访问控制

自主访问控制：应在安全策略规定的范围内，允许用户对其创建的资源拥有相应的访问权限，并能够将这些权限部分或全部授予其他用户。

权限控制粒度：应明确自主访问控制的主体和客体的细化程度，例如，主体可以细化到用户级别，客体可以细化到文件、数据库表、记录或字段级别。

特权管理：各类访问操作应尽量采用满足任务需求的最小权限原则。

4.2.资源控制

空闲会话限制：当应用系统中通信双方之一在一段时间内未进行任何操作时，另一方应具备自动终止会话的能力，以避免长时间保持非活动的会话。

会话限制：应具备以下功能：限制系统的最大并发会话连接数；限制单个账户的多重并发会话数量；限制在特定时间段内可能出现的并发会话连接数。

资源配额：应支持为访问账户或请求进程设定资源使用的最大和最小配额；能够检测并警报系统服务水平低于预定的最低标准；提供服务优先级设置功能，安装后依据安全策略配置账户或进程的优先级，并根据优先级分配系统资源。

4.3. 身份鉴别

标识与认证：系统应支持用户身份标识和认证功能。在用户注册时，通过用户名和唯一的用户标识符确认用户身份，并确保用户标识在系统生命周期内的唯一性。

认证机制：在用户登录或重新连接系统时，应采用由安全管理中心控制的认证手段，包括口令、生物特征数据、数字证书等，并至少结合两种或以上具有足够安全强度的方式对用户进行认证。其中，至少一种认证方法的认证数据应具备不可伪造性。如采用密码作为认证手段，可增强密码的强度管理，例如设置密码的长度、复杂性、定期修改要求以及限制登录失败次数等。对于用户发起的关键操作（如申购或赎回），可进一步增加口令确认环节。

认证数据保护：对认证数据应进行严格的保密性和完整性保护，确保数据不被泄露或篡改。

4.4. 操作审计

安全事件记录：应对系统中的相关安全事件进行记录，内容需包含事件的主体、客体、发生时间、事件类型及处理结果等信息。

用户操作记录：在确保业务系统性能的前提下，尽可能详尽地记录用户登录后的关键操作，至少包括用户名、操作时间、操作内容以及操作结果。

特定安全事件告警：应具备对特定安全事件进行报警的能力，并可采取措施如终止违规进程等。

审计记录使用：应支持对审计记录进行分类、查询和分析，以便于追溯和研究。

审计记录保护：应确保审计记录免受破坏或未经授权的访问，同时采取措施防止审计记录丢失。

4.5. 数据安全

完整性机制：应采用基于密码技术的完整性校验机制或其他具备相应安全强度的校验方法，防止未经授权的非法篡改。

完整性校验：应对用户数据在存储和处理过程中的完整性进行验证，以检测其是否遭到破坏。

异常恢复：在数据完整性受损的情况下，应具备对关键数据进行修复或恢复的能力。

数据加密：通过密码技术支持的保密保护机制或其他具备同等安全强度的手段，实现数据的保密性保护。

加密技术与强度：应采用经国家信息安全管理机构认可的加密技术及其对应的加密强度。

4.6. 授权管理

访问授权：应用软件应支持对菜单、查询功能和报表功能进行基于权限的访问控制。

授权清单：应用软件应具备自动生成访问权限清单的功能，以便管理员对账户及其权限进行核查和清理。

4.7. 通信安全

密码技术：应使用密码技术确保通信过程中数据的完整性，防止传输或接收的数据被篡改、删除或插入。在通信双方建立连接前，应通过密码技术进行会话初始化验证。

通信加密：应对通信过程中的所有报文或整个会话内容进行加密处理。

加密技术与强度：应采用经国家信息安全机构认可的加密技术。

数字加密技术的应用：在与银行或其他支付系统进行数据通信时，应采用数字加密技术（如数字证书）对数据进行严格加密处理，以防止数据被篡改。

4.8. 电子签名

数据原始证据：应具备在需求情况下，为数据发送方或接收方提供数据原始发送证据的能力（这里主要指的是电子签名，采用第三方证书的方式）。

数据接收证据：应具备在需求情况下，为数据发送方或接收方提供数据接收证据的能力。

4.9. 软件容错

输入验证：应具备数据有效性校验功能，确保通过人机接口或通信接口输入的数据，其格式和长度均符合系统预设要求。

自动保护：应具备自动保护机制，在发生故障时能够自动保护当前的所有运行状态。

自动恢复：应具备自动恢复能力，当故障发生后，能够立即启动新进程，恢复系统至原有的工作状态。