支付公司核心账务系统总体设计方案v1.doc

《支付公司核心账务系统总体设计方案v1.doc》由会员分享，可在线阅读，更多相关《支付公司核心账务系统总体设计方案v1.doc（28页珍藏版）》请在麦多课文档分享上搜索。

1、 乐视核心账务系统总体设计方案 北京市万隆然博科技有限责任公司 乐视核心账务系统总体设计方案 技术方案概要书 杨磊 2014-9-21 乐视核心账务系统总体设计方案 1 / 27 目录 1. 项目背景 . 1 2. 系统方案 . 1 2.1. 总体流程 1 2.2. 系统架构 2 2.3. 系统功能设计 3 2.3.1. 前置子系统 3 2.3.2. 核心子系统 4 2.3.3. 清结算子系统 5 2.3.4. 管理子系统 11 3. 系统设计原则 . 13 4. 网络拓扑图 . 14 5. 系统部署 . 16 5.1. 系统运行环境 16 5.2. 数据管理 16 5.3. 文件系统管理 1

2、6 5.3.1. 文件系统空间管理策略 16 5.3.2. 文件系统归档备份策略 17 5.4. 数据库管理 17 5.4.1. 数据库文件系统空间管理 策略 17 5.4.2. 数据库存储空间估算 18 5.4.3. 数据库空间管理策略 18 5.4.4. 数据库备份策略 18 6. 信息类别及处理原则 . 19 6.1. 业务分级处理 19 6.2. 数据分级保护 20 7. 7. 应用层安全设计 . 20 7.1. 身份认证 21 乐视核心账务系统总体设计方案 2 / 27 7.2. 访问控制 21 7.3. 数据加密 22 7.4. 数据完整性和不可否认性 22 7.5. 代码安全 2

3、2 7.6. 异常监控 23 7.7. 业务安全管理 23 7.8. 审计跟踪 23 乐视核心账务系统总体设计方案 1 / 27 1. 项目背景 本文档是乐视支付核心账务系统的设计文档，文中对系统的整体架构进行描述，对开发设计、系统测试、并行上线等阶段提供指导作用。同时，本文档划分了系统的组成结构，并定义了各组成模块的实现功能、以及采用的相关技术，指导各子模块的设计工作及开发工作。文档内容可以等价于以往项目定义文档中的软件架构 HLD 和平台环境 HLD。 本文档的阅读对象是软件开发人员、业务规范设计人员、软件测试人员、系统安装人员及用户代表。 核心账务系统一期只实现了全网与一家财富公司直连。

4、 2. 系统方案 2.1. 总体流程 总体主要的流程包括开立账户、注销账户两个主要流程。 开立账户流程 1） 客户与乐视签订互联网支付服务协议 2） 客户提交开户材料 3） 核实客户身份证明文件 4） 为客户开立结算账户并通过登记的联系方式通知客户 5） 客户登录系统完成客户账户初始化（修改密码、指定对应的银行结算账户） *客户在银行开立的账户称为客户银行结算账户，客户在公司开立的非银行结算账户称为客户交易账户。 乐视核心账务系统总体设计方案 2 / 27 2.2. 系统架构 项目的体系结构如下图所示： 图 1体系架构 整个项目的系统结构如下图所示： 乐视核心账务系统总体设计方案 3 / 27

5、 图 2 系统架构 2.3. 系统功能设计 2.3.1. 前置子系统 2.3.1.1. 综合交易前置子系统 包括的功能及组件： 协议适配 支持多种协议，如 HTTP， WS 等等 格式校验 根据配置的校验规则检验报文的格式 格式转换 对于外部的报文格式统一转为统一支付内部的统一消息模型 乐视核心账务系统总体设计方案 4 / 27 2.3.1.2. 文件前置子系统 包括的功能及组件： 对账文件上传 上传文件至网状网、银行、天猫商城等 文件服务器 ； 获取对账文件 从省移动，银行、天猫等文件服务器获取文件； 任务调度 该组件用于管理并执行系统定时任务； 文件验签 该组件用于文件内容进行验签； 2.

6、3.1.3. 支付网关子系统 包括的功能及组件： 用户签约 用户通过该功能与银行建立签约关系； 支付扣款 系统通过该功能通知银行从指定账户中扣款； 2.3.2. 核心子系统 包括的功能及组件： 2.3.2.1. 消息收发 该组件发送 ,监听前置发送到请求队列中的消息 乐视核心账务系统总体设计方案 5 / 27 2.3.2.2. 插件调度 接收到的前置发送的消息后，根据业务编码调用不同的业务插件完成具体业务的处理 2.3.2.3. 消息映射 该组件映射统一消息模型到数据模型 2.3.2.4. 数据持久 把映射后的数据存储到数据库中 2.3.2.5. 日志处理 该组件负责把日志的内容打印到不同的日

7、志文件中 2.3.2.6. 异步流水处理 该组件负责把操作流水的数据存储到数据库中 2.3.3. 清结算子系统 2.3.3.1. 调度管理子系统 2.3.3.1.1. 流程管理 流程管理主要包括任务定义和流程编排两个模块。 任务定义主要负责定义原子任务以及该任务相关的所有公共参数。 流程编排主要负责按具体的业务规则编排一系列的原子任务，并设置各原子任务的执行顺序及与该任务的特殊参数。 乐视核心账务系统总体设计方案 6 / 27 2.3.3.1.2. 任务管理 任务管理主要实现监控已调度的业务流程， 任务列表页面上可以查看当前任务的执行的状态，以及对出错的业务流程重做或接着异常点继续执行该流程。

8、包含查询任务列表、重新执行该业务流、异常恢复。 查询任务列表 任务列表包括当前任务的详细信息：业务流程名、提交时间、执行时间、任务状态等信息。其中任务状态包括：未启动、成功、失败、停止，对于正在执行的任务的状态页面需异步刷新；操作栏中有启动、恢复操作。 启动任务 当一个运行中的任务由于业务约束或其它异常导致该任务失败后，可以在列表页中找到该任务并执行启动任务操作，该业务流程会被重新执行。 恢复任务 当一个运行中的 任务由于业务约束或其它异常导致该任务失败后，可以在列表页中找到该任务并执行恢复任务操作，该业务流程执行中断点之后未完成的原子任务。 2.3.3.1.3. 计划任务管理 计划任务主要是

9、对某一个业务流程设置属性及业务规则，自动创建并执行该任务。该模块主要包含创建、编辑、删除、查询计划化任务。 计划任务属性及业务规则： 1、 计划名称：文本框，由中文、字母、数字下划线组成，长度为 64 位； 2、 开始时间：时间控件，不能小于当前时间； 3、 过期时间：时间控件，不能小于当前时间； 4、 时间设置：单选框，枚举类型：执行一次、每几天执行、任务重复间隔。 创建计划任务 管理或运维人员通过后台管理页面输入计划任务属性，新建计划。调度引擎 乐视核心账务系统总体设计方案 7 / 27 会定时检查计划任务，如达到计划任务指定时间，则该任务启动并执行。 编写计划任务 管理或运维人员可以编辑

10、计划任务中的任一属性。 删除计划任务 管理或运维人员可以删除某计划任务，非物理删除，标志删除。 查询计划任务 管理或运维人员可以通过输入开始时间、结束时间和计划名称查询符合上述要求的任务。 2.3.3.1.4. 计算资源管理 计算资源管理（或计算节点管理）主要负责管理各个计算资源 的元数据。 计算资源的元数据包括该组件标识、名称、版本号、包括 IP、端口、服务地址、状态、最大任务数、当前任务数等。 计算资源元数据，包括如下属性： 资源标识：资源的唯一编号 资源名称：资源的名称 版本号：资源版本号 IP 地址：组件所在服务器的 IP 地址 端口：组件所在服务器的的端口 接口地址：服务接口调用地址

11、，如 http:/ip:port/spi/validate.do 状态：组件实时运行状态，正常或宕机； 最大任务数：组件最大并发任务数； 当前任务数：组件当前共有多少 任务在运行； 2.3.3.1.5. 系统管理 系统管理包括操作员管理、权限管理、参数配置和操作日志管理。 乐视核心账务系统总体设计方案 8 / 27 2.3.3.2. 调度引擎子系统 2.3.3.2.1. 计划任务调度 查询缓存或后台数据库计划任务数据，当该任务预设的时间到达后，立即调度该任务。 2.3.3.2.2. 计算资源管理 负责集中管理并维护分布式计算节点信息，这些信息包括计算节点的状态（正常或宕机）、当前任务数、最大任

12、务数。 节点可分配任务的规则： 计算节点状态为正常，当前任务数小于该节点的最大任务数时，可分配任务给该节点去执行。 计算节点状态为正常，当前任务数等于或大于该节点的最大任务数时，任务将会等待，直到当前任务数小于该节点的最大任务数时，任务才可分配到该节点上去执行。 计算节点状态为宕机，该节点不可用，任务不会分配到该节点上去执行。 2.3.3.2.3. 流程实例管理 管理并维护正在运行的流程实例整个生命周期，监控流程的启动、停止、完成、失败等事件，并针对相应的事件做相应的处理。 2.3.3.2.4. 任务实例管理 管理并维护正在运行的任务实例整个生命周期，监控任务的启动、停止、完成、失败等事件，并

13、针对相应的事件做相应的处理。 乐视核心账务系统总体设计方案 9 / 27 2.3.3.2.5. 调度策略管理 根据集群中各计算节点处理 能力，合理的安排任务到计算节点中去执行 2.3.3.2.6. 接口管理 接口管理主要包含以下内容： 服务器端接口： 1. 任务回执接口：接收任务引擎执行消息 2. 流程控制接口：接收调度管理系统发送过来的请求，完成对流程的启动、停止、停止全部流程等管理控制工作 客户端端接口： 1. 任务调度接口：分发任务到任务引擎执行具体任务接口 2. 心跳检测接口：定时去检测任务引擎是否存活 3. 任务控制接口：停止任务引擎任务 2.3.3.3. 任务引擎子系统 2.3.3

14、.3.1. 任务队列管理 负责对任务执行接口以及任务控制接口的报文消息缓存管理，实现消息异步处理 2.3.3.3.2. 任务线程池管理 对任务采用线程一一对应方式管理，实现任务实时的启动、暂时、停止的控制 2.3.3.3.3. 任务元数据管理 对调度引擎发过来的流程 ID 以及任务 ID 查询任务参数表以及系统参数表，封装成 map，提供功能插件以及公共组件使用。 乐视核心账务系统总体设计方案 10 / 27 2.3.3.3.4. 业务功能插件 实现任务功能的实际业务向导处理（例如：先做那个子任务在做那个子任务），具体实现由公共组件完成。 2.3.3.3.5. 公共组件 对子任务的具体实现 2

15、.3.3.3.6. 接口管理 提供对任务执行接口、任务控制接口以及心跳回执接口的实现 2.3.3.4. 银商 应用组件 2.3.3.4.1. 银商 对账 银商 对账主要包括以下几个功能： A. 预处理 主要负责文件检测、文件备份、文件校验（文件名校验、文件头尾记录校验、记录级校验）、异步入库（ Oracle、 HDFS）、 Hive 建表。 B. 文件比对 采用 Hive 进行账单文件比对，主要包括 其它应用系统 账单文件、 财富公司 账单文件、以及统一支付账单文件的三方比对，并生成差异文件。 C. 差异生成 对已生成的生成差异文件进行合并 D. 差异处理 根据差异文件更新账单流水信息 乐视核

16、心账务系统总体设计方案 11 / 27 2.3.4. 管理子系统 2.3.4.1. 后台管理 2.3.4.1.1. 我的首页 个人信息 修改密码 2.3.4.1.2. 业务管理 个人账号管理 企业账号管理 2.3.4.1.3. 结算管理 单笔付款申请 结算审批 2.3.4.1.4. 风控管理 账号黑名单 规则管理 2.3.4.1.5. 状态监控 服务状态总揽 风险监控 操作日志 乐视核心账务系统总体设计方案 12 / 27 2.3.4.1.6. 统计报表 交易统计 转账报表 支付报表 退货报表 充值报表 提现报表 2.3.4.1.7. 系统管理 系统菜单设置 系统角色设置 系统用户设置 2.3

17、.4.2. 前台管理 2.3.4.2.1. 账户管理 客户信息 2.3.4.2.2. 交易管理 对账文件查询与下载 退款审核 交易明细 2.3.4.2.3. 虚拟账户 虚拟账户 乐视核心账务系统总体设计方案 13 / 27 提现 转账 虚拟交易查询 网上充值 网上充值查询 交易明细 2.3.4.2.4. 系统管理 证书安装 密码管理 3. 系统设计原则 对支付服务平台而言，系统整体安全的重要性是不言而喻的。因此，在系统规划和设计时，在技术和产品选择时，应将安全性放在首位予以考虑，并尽量遵循国际标准、国家标准、行业标准或行业惯例。 为了实现上述安全目标，在对乐视系统平台安全体系的设计中，在乐视系

18、统平台的建设中，乐视公司投入大量的人力、物力、财力，从制定周密的信息系统安全策略开始，加强管理和监督，制定严密的灾难恢复体系和管理制度，不断进行改进和完善。 乐视系统平台信息安全体系遵循如下原则。 需求、风险、代价平衡分析的原则 网络系统中没有绝对的安全，需通过安全风险分析，从系统建设需求、安全风险、安全投入、收益等方面找到平衡点，来规划安全体系。在考虑安全性的同时，需要平衡安全和成本、安全和效率、安全和方便性之间的矛盾。 多重保护的原则（全局防御的原则） 任何安全保护措施都不是绝对安全的，都可能被攻破。但是建立一个多重保护系统，各重保护相互补充，当一重保护被攻破时，其它重保护仍可保护信息的

19、乐视核心账务系统总体设计方案 14 / 27 安全。 多层次（网络 OSI 参考模型中的逻辑层次）保护的原则 安全体系的规划应贯穿 OSI 参考模型的各个层次，如在链路层和网络层实施包过滤，在表示层实施加密传送，在应用层设置专用程序代码、运行应用层审计软件，在应用层之上启动代理服务等。 网络分段的原则（物理和逻辑） 网络分段是保证安全的重要措施。网络分段可分为物理分段和逻辑分段。网络可从物理上分为若干段，即通过交换器连接各段。对于 TCP/IP 可进行逻辑分段，即把网络分成若干 IP 子网，各子网通过路由器连接，并在路由器上建立可访问表，来控制各子网间的访问。 设多个安全单元的原则 把整个网络

20、的安全性赋予多个安全单元，如路由器、屏蔽子网、网关，形成了多 道安全防线。 易操作、灵活性的原则（安全措施由人完成） 安全措施与网络的灵活性是一对矛盾，安全体系的规划应以不影响系统的正常运转和易操作、灵活性为前提。 最小授权的原则（分散权力，降低灾难程度） 特权（超级）网络要有制约措施，分散过大的集中权力，以降低灾难程度。 综合性原则（设备 技术 策略 管理） 计算机网络系统的安全应从物理上、技术上、管理制度（如安全操作乃至计算机病毒的防范等）上以及安全教育上全面采取措施，相互弥补和完善，尽可能地排除安全漏洞。 4. 网络拓扑图 系统的网络拓扑图如下所示： 乐视核心账务系统总体设计方案 15

21、/ 27 同城备份中心W E B 服 务 区应 用 服 务 区前 置 服 务 区监控专线接入区专线接入区前置服务区应用数据库服务区WEB服务区互联网接入区业 务 操 作 终 端q z - s w - Bf c - s w - 0 2f c - s w - 0 1a p p - s w - Bw e b - s w - Bw e b - s w - Aa p p - s w - AI n t e r n e t用 户监控操作中心数 据 库 服 务 器（ H A ）应 用 服 务 器B A N K - R T - B外 联 机 构 业 务 系 统q z - s w - A前 置 服 务 器A P

22、P - F W - 0 1磁 盘 阵 列光 纤交 换 机电 信A P P - F W - 0 2B A N K - R T - AM o n i t o r - f wm o n i t o r - r t - B磁 带 机防 火 墙（ 国 内 品 牌 ）防 火 墙（ 国 外 品 牌 ）防 火 墙（ 国 外 品 牌 ）防 火 墙（ 国 内 品 牌 ）心 跳 线心 跳 线W e b 服 务 器防 火 墙（ 国 外 品 牌 ）心 跳 线b a n k - f w - A b a n k - f w - BA P P - F W - 0 3A P P - S W - 0 4SDH监 控 终 端m o

23、 n i t o r - r t - AI N T - T E L - R T 0 1i n t e r n e t - f w - 0 1 i n t e r n e t - f w - 0 2I D S 引 擎I D S 感 应 器审 计 引 擎负 载 均 衡 器（ 集 群 ）负 载 均 衡 器（ 集 群 ）负 载 均 衡 器（ 集 群 ）心 跳 线应 用 服 务 器审 计 系 统数 据 中 心N M S 、 I D S控 制 中 心R a 服 务 器千 兆 以 太 网交 换 机千 兆 以 太 网交 换 机千 兆 以 太 网交 换 机I N T - C N C - R T 0 1联 通P

24、S T N商 户审 计 系 统管 理 中 心黑 洞 0 1 黑 洞 0 2加 密 机 控 制 中 心金 融 数 字 加 密 机 2金 融 数 字 加 密 机 1数 据 库 服 务 区专 线 接 入I n t e r n e t - f wI n t e r n e t - r tI n t e r n e t图 3网络拓扑图 乐视核心账务系统总体设计方案 16 / 27 5. 系统部署 5.1. 系统运行环境 系统运行平台如下： 操作系统： Linux 数据库： Oracle 10G 中间件： WebLogic 主机服务器： IBM pcserver 存储： 磁阵 5.2. 数据管理 涉及在线

25、数据保存与历史数据备份，文件系统和数据库都通过 IBM Tivoli 软件再备份到 IBM TSM3310 磁盘库。为了提高数据库恢复的效率，备份路径都指定为硬盘，硬盘上的备份数据至少保留 7 天才能删除，即一个数据库全备的周期。 5.3. 文件系统管理 5.3.1. 文件系统空间管理策略 文件系统随着业务处理空间使用会不断增长，需要定期清理不使用空间，为业务处理腾出空间。文件系统清理包括： 1） 操作系统清理目录，包括 /var 等。 2） 业务系统运行临时目录。 3） 业务系统运行日志目录。 文件系统中与业务有关的清理，参考目前生产配置，确定空间管理策略，总体策略如下： 乐视核心账务系统总

26、体设计方案 17 / 27 1） 日志备份。 a) 超过 200M 日志文件需要备份。 b) 应用日志保存 7 天。 2） 业务文件 a) 上下发文件，根据不同业务保存时间 7-140 天不等。 b) 其他接口文件。根据不同业务类型进行具体制定。 5.3.2. 文件系统归档备份策略 文件系统需要进行定期归档备份，包括操作系统备份和业务文件系统备份。 1） 操作系统备份 参考目前生产系统备份策略，每周就进行全备，备份归档目录包括 /、 /var、 /usr、home、 /opt 等。 2） 业务文件系统备份 参考目前生产系统备份策略，进行每周全备、每天增量备份，备份目录包括任何业务系统认为有必要

27、备份的目录，典型的目录类型如下： (1) 应用程序目录 (2) 应用配置目录 (3) 归档目录 (4) 业务运行的关键目录 5.4. 数据库管理 5.4.1. 数据库文件系统空间管理策略 文件系统随着业务处理空间使用会不断增长，需要定期清理不使用空间，为业务处理腾出空间。文件系统清理包括： 1） 操作系统清理目录，包括 /var 等。 2） 数据库 trace 文件目录，包括 oracle 和 grid 用户 ORACLE_BASE 下 diag 产生的dump 和 trace 文件。 乐视核心账务系统总体设计方案 18 / 27 5.4.2. 数据库存储空间估算 【以每个月 5 亿笔的交易量

28、测算以下存储的空间】 交易核心数据（前线库 Oracle 保留 30 天的数据） 存储空间（ 12288G 12T） Oracle 数据文件 = 每个月 5 亿笔交易 * 12 条数据 * 1K（包含索引文件） = 6144G Oracle 日志文件 = = 6144G 清结算后线库 Oracle 数据库（ 2793G+3352G 6T） 流水数据文件 = 每个月 5 亿笔交易 * 平均每笔数据大小 500B * 3（三方流水） * 4 个月 = 2793 G 结果数据文件 = 每个月 5 亿笔交易 * 平均每笔数据大小 300B * 24 个月 = 3352 G 5.4.3. 数据库空间管理

29、策略 数据库在业务系统投入使用后，会随着业务数据量增长而容量进行增长。因此，在数据库的日常运维中，监控数据库的空间是一项非常重要的内容。 1）分区增长，对于采用日期分区的，随着时间增长进行分区的滚动创建。 2）数据库存储空间增长。需对投入使用的数据库进行空间使用率监控，在高于特定使用率时，需提前通知平台工程师进行空间扩容。 具体数据库表管理策略与具体数据表数据存储周期相关，在具体业务概要设计中确定。 5.4.4. 数据库备份策略 数据库的备份，我们使用数据库备份和数据表备份的策略进行。每周日进行数据库的全库备份，其它日期进行数 据库的日志备份。为了避免日志溢出，我们 乐视核心账务系统总体设计方

30、案 19 / 27 在每天成功备份日志后，并确认无误后。即删除数据库服务器中对应的日志。 前线库 Oracle：使用 rman 脚本定时将数据库备份到本地硬盘，备份数据库和日志归档文件，日志备份完毕删除归档，冗余策略为 2，即本地保存两个完整备份集。 后线库 Oracle：为了实现数据库备份的自动化，我们可以使用 Oracle ASE 提供的 Job Schedule 工作计划功能，定制指定时间指定的备份作业，可以沿用一期备份策略。 为了提高数据库恢复的效率，备份路径都指定为硬盘，硬盘上的备份数据至少保留 7 天才能删除，即一个数据库全备的周期。数据库备份成功后，通过 IBM Tivoli 软

31、件将备份结果从文件系统备份到 IBM TSM3310 磁盘库。 备份类型 频率 备份时间 说明 数据库全备 1 次 /周 周日， 2 点 前线库 Oracle 和后线库 Oracle 备份到本地硬盘，次日凌晨再备份到磁带库。 数据库日志备份 6 次 /周 周 1 到周 6，每天2 点 备份到本地硬盘，次日凌晨再备份到磁带库 对于一些重要的数据表，使用 bcp 导出明文文件的方式，将数据以表的方式备份出来。 6. 信息类别及处理原则 6.1. 业务分级处理 根据业务风险程度，把支付交易分成若干级别，采用不同的安全控制手段来 乐视核心账务系统总体设计方案 20 / 27 控制业务的安全性。下面定义

32、了若干级风险，风险系数依次越来越大 : 序号 风险度 描述 0 无风险 如信息服务等交易 1 普通风险 如账户查询等 2 二级风险 客户内部账户转帐等 3 三级风险 客户网上充值等业务 4 四级风险 客户约定账户支付 5 五级风险 网上支付，如 B2B 和 B2C 等 6 六级风险 委托支付 6.2. 数据分级保护 系统中涉及商业秘密的数据具体见表。 数据类别 密级 保密期限 客户信息 商业机密 长期 客户账户信息 商业机密 长期 与客户签定的业务协议 商业机密 长期 客户业务信息 商业机密 长期 客户密码信息 商业绝密 长期 针对这些数据我们建议采用不同的安全保护措施： 1、商业机密数据，采

33、用明文存储，密文传输，并施加数据对象级的访问控制； 2、商业绝密数据，采用密文存储和密文传输。 7. 7. 应用层安全设计 应用层安全是乐视系统平台安全体系中的重要组成部分，主要包括：身份认证、访问控制、业务安全管理、业务审计、异常业务监控、数据安全以及数据完整性、不可否认性等内容。 乐视核心账务系统总体设计方案 21 / 27 7.1. 身份认证 乐视系统平台在用户登录或关键交易处理时使用一种或多种身份认证方式，包括用户名 /静态口令、图形验证码、数字证书等。 静态口令认证 用户名 /静态口令是最容易被接受、也最广泛使用的身份认证手段，乐视系统平台使用用户名 /静态口令进行身份认证。 口令质

34、量策略： 1、口令的复杂性必须满足同时包含字母和数字； 2、口令的长度必须不小于 6 位； 3、首次登录强制性要求用户修改初始密码。 账号锁定策略： 、一天内口令多次认证失败，自动锁定用户； 、账号锁定后，隔天自动解锁或人工解锁； 图形验证码 图形验证码是防止暴力破解密码攻击的有效手段，乐视系统平台提供图形验证码的辅助用户身份认证。 数字证书认证 乐视系统平台采取中国金融认证中心的数字证书，将证书存储于 USB Key，证书与用户绑定，对企业用户、内部操作员提供必要的双因子强身份认证。 7.2. 访问控制 乐视系统平台对系统资源、应用功能、数据资源进行严格的授权管理和访问控制： 1、系统提供基

35、于角色的应用软件功能的访问控制，包括角色定义，角色的权限管理，用户的角色管理。 2、系统提供基于角色和组织机构的数据对象的访问控制能力。 3、用户权限的分配遵循最小特权 的原则。 乐视核心账务系统总体设计方案 22 / 27 4、提供系统资源（文件、 URL）级别的访问授权控制手段 供应链网络支付系统对用户进行角色管理，包括业务管理岗、业务处理岗、资金管理岗、商务岗等，不同的角色分配不同的权限。 7.3. 数据加密 乐视系统平台在数据的传输、存储中，采取了必要的加密措施。 对商业机密数据，采用明文存储，密文传输，并施加数据对象级的访问控制；对商业绝密数据，采用密文存储和密文传输。 传输安全 所

36、有的涉密信息在公网必须以密文的形式传输。乐视系统平台使用 128 位SSL 协议或 VPN 技术，对用户与服务器之间、第三方与乐视之间的数据传递进行加 密保护，使用安全控件技术对用户在客户端浏览器输入的口令进行增强加密保护。 存储安全 乐视系统平台的用户身份信息使用数据库存储，静态口令作为商业绝密数据，在数据库中用单向散列算法加密存储，防止反向解密攻击。 7.4. 数据完整性和不可否认性 SSL 技术在保障信息加密传输的同时，提供数据完整性的保护。对关键业务操作，使用存储于 USB Key 的数字证书进行数字签名，在强身份认证的同时，实现数据完整性和不可否认性。 7.5. 代码安全 在登录功能

37、上做了防止 SQL 以及 JS 注入式攻击处理，用包含特殊字符的字符串无法登录系统，防止有人通过注 入 SQL 语句等手段恶意登陆网站获取机密数据，极大的提高了系统安全性。 在提交表单上做了安全设置，防止提交 JS 以及一些非法字符，进行恶意攻 乐视核心账务系统总体设计方案 23 / 27 击的情况，同时在每个提交表单上，根据所提交内容不同，通过 JS 以及正则表达式等手段进行验证，屏蔽掉一些非法可疑的输入，保证了输入信息的可靠性，完整性。 7.6. 异常监控 乐视系统平台建立了应用监控系统，运行人员可实时了解应用系统运行状况，当异常发生时，监控系统会通过电子邮件、手机短信等各种方式提示运行人

38、员。 7.7. 业务安全管理 业务安全性是乐视系统平台安全的重点，业务的安全管理规则主要有以下方面： 客户业务权限检查 为了保证业务的安全性，客户在进行业务操作时，有业务权限检查、支付限额检查、日支付限额检查等多种控制措施。 定向支付 乐视系统平台的对外资金结算账户是有确定范围的，可以有效控制业务风险。 复核机制 供应链网络支付系统通过多个不同岗位角色进行复核制约，防范业务风险。客户支付账户由业务管理岗设置，客户提出支付申请，需要经业务处理岗生成确认单、商务岗发确认单、客户回传确认单后，经财务授权人签批，资金管理岗核对后，才 能进行资金的支付结算。 7.8. 审计跟踪 审计跟踪是指乐视系统平台

39、生成、记录、存储和分析与应用用户有关的安全活动信息。应用层审计跟踪可以分为四类，包括： 1、应用核心安全事件的审计； 2、应用访问的审计跟踪； 乐视核心账务系统总体设计方案 24 / 27 3、应用业务交易相关的审计跟踪； 4、应用错误或调试日志信息。 业务事件的审计跟踪 业务事件的审计是强制的，不可关闭的，包括对下列可审计事件生成审计跟踪记录： 1、用户身份信息的创建、修改、删除； 2、用户认证信息的修改； 3、用户使用身份认证机制； 4、应用业务流程和配置的变更； 5、用户对业务操作的处理。 对每一个可审计事件，其审计记录包括： 1、序号； 2、日期和时间； 3、事件类型； 4、主体身份；

40、 5、请求的源 IP 地址； 6、事件结果（成功 /失败）； 7、客体的前映像和后映像； 8、数据鉴别码（ SHA-1）。 业务事件的审计跟踪存放在数据库中。审计跟踪在线保存时间至少 60 天，备份保存时间为长期。 应用访问的审计跟踪 应用访问的审计跟踪使用 Web 服务器的访问日志代替，可以记录时间、源IP 地址、访问的 URL 等信息。 应用错误或调试日志信息 乐视系统平台系统自动维护应用的错误和调试日志，并可以根据日志的级别设置来启用相应的日志。错误和调试日志采用文本文件存放在应用系统的日志目录中。日志文件应该设置严格的访问控制权限，只允许系统管理员访问。系统可 乐视核心账务系统总体设计方案 25 / 27 以定义日志文件的容量大小，当超过该容量时就创建一个新的文件。