直播数据安全

1.1系统性能与数据备份

1.1.1负载均衡

SaaS系统通常很难准确预测用户的规模和实际使用量，用户增长的速度和消耗资源的速度也并不是线性的。为了应对各种使用峰值，凌立使用了阿里云的负载均衡服务（ELB）和用于自动增加计算资源的Auto Scaling组服务。这样当用户的使用量上升时，我们的系统就可以自动根据当前的负载情况，增加底层的计算资源，从而保障系统的性能和用户的体验不会折损。

1.1.2DevOps

DevOps就是将软件功能开发（Development）和系统运维（Operation）结合在一起。因为这些软件系统都是在不断的功能和版本升级中，而同时所有的用户都不间断的使用着这些功能，这样传统的所谓管理员事先计划一个当机时间进行Offline的系统升级维护的方式是不能采用的。所以必须由经验丰富的开发人员和运维人员一起利用各种管理的工具和系统来对整个SaaS服务进行监控和维护。

　　　在凌立所提供的系统中，我们利用了阿里云的数项DevOps相关服务，包括监控、审计、代码版本管理和发布管理、代码测试自动化工具等，24小时不间断的自动监控整个系统。在出现意外状况时，使用一些自动化脚本先进行干涉，并通过各种消息机制通知我们的DevOps服务人员，参与到case的处理中。

1.1.3数据备份方案

　　　系统中的数据主要分为租户数据库和租户数据文件。因为我们采用了阿里云/AWS平台，所以我们的数据备份服务也是使用了云存储服务。因为云存储是没有容量限制的，所以我们避免了通常备份方案执行中备份存储空间规划和耗尽的问题。

l租户数据库的备份

RDS服务提供了数据库快照备份机制，由RDS服务每天定时自动生成数据库的备份快照。最后我们使用亚马逊云/阿里云服务提供的API接口，将每天的数据库备份快照自动归档到云存储上。

l租户数据文件的备份

　　　系统的租户数据文件（比如DA资料、会议照片、视频等）使用了AWS阿里云的云存储服务S3，而S3服务本身底层架构中就不存在单点故障，并提供了高达 99.99%的数据持久性，理论上几乎不会丢失任何文件。

　　　但基于数据最高安全的考虑，我们还是使用了AWS/阿里云的另一项专门用于数据备份的云存储服务Glacier服务，定期自动的对我们存储在S3上的租户数据文件归档到Glacier云储存上。

1.1.4灾难恢复解决方案

（1）灾难的定义

　　　灾难分为自然灾害和非自然灾害。 自然灾害是指由火灾、 地震等引发的一系列灾害直接导致公司的业务中断、电力故障、网络故障等。非自然灾害是指人为的造成的如服务器断电、软件错误、人为故意破坏、恶意代码、木马植入、恐怖袭击等。

（2）灾难恢复项目小组的制定与职能

1.管理组：统筹规划，指挥各小组按照既定计划进行执行。

2.部门恢复组：负责制定各部门情况制定应急备案，确定各部门数据和财产的保护方式并执行保护，确定各部门数据的恢复方式并执行恢复。

3.计算机恢复组：负责对全公司范围内的计算机故障进行排除、 恢复范围包括系统、必备办公软件。

4.损坏评估组：负责对公司损失的重要数据、 财务进行总体评估。并针对相应损失的财产进行汇总并结合拥有的保险进行申报。

5.安全组： 负责灾难发生后的人员、数据、财务的安全进行保护。并制定相应的安全策略。

6.设备支持组：负责对公司服务器、网络设备、交换机的故障进 行排除，制定相应解决重建方案。

7.数据恢复组：负责对公司各平台数据进行恢复，并制定相应数据恢复组：负责对公司各平台数据进行恢复，数据恢复方案。数据恢复方案。

8.市场和客户关系组：负责对外进行信息发布、制定相应应急措施应对客户疑问等。

各小组共同职能：

1.负责计划的执行

2.与其它组之间进行信息交流，监督计划的测试和执行

3.所有或是某一个成员可能领导特定的组

4.协调恢复过程

5.评估灾难，执行恢复计划，联系组长

6.监控并记录恢复的过程

（3）业务恢复过程

　　　自然灾害引起的灾难恢复流程

　　　由自然灾害引起的灾难往往影响较大， 可能会直接导致一些基础设施的无法使用，甚至会对导致人员减少。因此对于自然灾害引发的灾难恢复流程相对特殊且繁琐。

1.数据抢救

　　　灾难发生时， 需在保证人身安全的情况对公司的重要数据进行抢救，抢救的范围主要包括：记录公司重要信息的文件、资料，存储公司重要数据的磁带，存放重要数据的硬盘、服务器。此过程需由安全组进行统筹指挥，按照既定的计划执行，各组成员、公司员工必须服从安全组的统一调度和指挥

2.损坏评估及启动应急预案

　　　灾难发生后各小组需根据情况汇报损失情况给损坏评估组，损坏评估组根据汇总信息进行消息告知披露。披露损坏信息包括：

a)公司重要生产、监视测量、办公设备

b)拥有在可以执行计划之内的关键性功能的员工

c)保存公司重要数据的介质

d)网络、通讯设备 各小组人员根据披露的损坏信息情况进行应急预案启动，如选举临时领导、使用备份服务器、备份通讯设备进行替代等。

3.业务恢复计划

　　　业务恢复计划需要多个小组支持与配合， 总体可划分为以下几个阶段：

a)IT 基础设施恢复阶段： 此阶段主要的目标是将对于保存数据的基础设施、业务系统 所在的主机、公司网络架构进行恢复。首先根据损失评估小组给出的报告分析可继续利用的 IT 基础设施，如供电设施、交换 机、服务器、防火墙等。若有损坏不可用的设备，需及时同代理 商进行沟通借用或新购相应设备。此阶段由设备支持组执行。

b)系统恢复阶段：系统恢复主要针对关键应用主机，为节约时间需同时针对各个服务器系统 进行快速恢复。此阶段由数据恢复组执行。

c)网络恢复阶段

d)网络恢复阶段的主要针对以下几点进行：

l关键商业应用系统的内部局域网和网络设备的支持

l外部广域网和电信服务

l待恢复系统和终端用户（公司同事）间的通讯

此阶段由数据恢复组同设备支持组共同执行。

e)业务平台恢复阶段：在此阶段的恢复工作主要围绕日常工作常用的业务平台进行， 常用的业务平台主要为：互动直播视频云服务平台等。平台恢复的工作分为两个部分。

l业务系统数据恢复

l业务系统重搭建

l业务系统数据导入

　　　业务系统数据恢复：

　　　数据恢复小组首先须对业务系统的数据进行恢复， 需要寻找 相应的恢复设备完成此操作，目前我们主要利用磁带机和可正常 工作的主机进行数据恢复工作。 需要将抢救出的磁带和硬盘接连 在对应设备上恢复出数据。

　　　业务系统重搭建：

　　　为提高业务恢复效率，数据恢复小组成员需分工协作，共同 完成业务系统的重搭建工作，由于一些业务系统的特殊性，需尽 快与相应平台的供应商接口人取得联系， 并申请临时可用的加密狗、许可文件等。各个平台负责人需对自己管理的平台在短时间内进行重搭建。

　　　业务系统数据导入：

　　　数据恢复小组成员需根据导出的数据结合自己管理的业务 平台进行数据导入，并测试可行性。再导入成功并可使用后及时同个小组成员负责人进行通知。

　　　非自然灾害引起的灾难恢复流程

　　　非自然灾害引起的灾难恢复通常破坏较小， 但是风险程度仍不可忽视， 如电力故障导致的关键业务系统无法运行同样会给我们的公司带来一定的影响。但由于破坏程度的不同，我们将引入业务持续计划（BCP）这样一个概念。 业务持续计划是为了防止正常业务行为的中断而被建立的计划。当面对由于人为造成的故障或灾难以及由此造成的财产损 和正常业务不能正常使用时，BCP 主要被设计用来保护关键业务步骤。BCP 是最小化对于业务的干扰效果和使业务能恢复正常运行的计划。RTO（Recovery TimeObject）恢复时间是指运维部门同公司签订的故障响应恢复时间，如确保在 1 小时内排除故障，使业务系统重新恢复工作。RPO (Recovery Point Objective)恢复点目标，该指标规定在灾难发生后，公司所能够容忍的数据丢失量，该指标由运维部门同公司签订。对于 RTO 和 RPO 目标的实现，需要人力、物力的支持，因此对于高效，最小化的 BCP 指标，往往也会花费大量的财力资源。在执行业务持续计划的同时，由于造成的灾难和破坏性并不严重，因此可直接进入业务平台恢复阶段。

1.1.5灾难恢复测试报告

版本 RTO RPO 操作部门 时间

V1.0 1h 1min-15min 运维部 2021-10-23

说明 测试环境模拟 h 数据库表文件被人为误删除，造成关键业务不可用

（1）演练流程图

（2）灾难恢复人员体系架构

技术小组 运维小组 测试小组

成员 所有成员 所有成员 所有成员

（3）演练过程和演练结果

a)测试小组在测试环境测试业务，突然发现关键业务运行不正常，系统报错500状态错误。

b)测试小组报告给技术小组，技术小组排查技术故障的同时通知给运维小组，开始排查问题。

c)数据库管理员定位到数据库问题，报告给领导后，评估损害程度后，开始开始通过 DBS数据备份系统恢复数据。

d)在DBS控制台通过恢复功能，选择之前的全量备份和增量备份文件进行恢复单个表。25分钟后恢复完成。

e)测试小组测试后业务正常。RTO和RPO均符合预期。

1.1.6系统压力测试报告

1.2系统安全性

　　　系统的安全性必须从底层设计就要开始考虑，并且在增加系统的安全性等级的同时，又要能同时不破坏用户的良好使用体验，以及不影响到系统的整体性能。

1.2.1OAUTH身份认证

　　　在我们的系统中，对于用户身份的认证我们使用了国际通用标准OAUTH（Open Authorization）。OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息（如用户名与密码），即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权，因此OAUTH是安全的。

　　　结合国内的信息安全现状，我们在OAUTH 2架构和协议的基础上还添加了手机短信验证码的校验步骤。符合国家对Internet系统的实名制要求，也给OAUTH架构增加了额外的安全性。

　　　获取资源访问的Token

　　　在以上两种（注册或登录）步骤中，用户输入短信验证码后，服务端成功校验验证码后，就会与服务端进行基于OAUTH协议的Token发放与获取流程，服务端将获取一个有期限限定的资源访问Token和一个同样有期限限定的Refresh Token。通常Refresh Token的有效期比资源访问Token的有效期要长一些。随后用户在服务端中发起的所有资源访问请求，都由服务端提供这个有效的资源访问Token给服务端。

　　　而当资源访问Token有效期过期之后，而同时Refresh Token的有效期还没有过期，这时服务端会自动使用Refresh Token问服务端请求一个新的资源访问Token（和新的Refresh Token）。

　　　而如果连Refresh Token也过期，从安全角度出发，服务端必须重新走一遍让用户登录进行身份验证的流程（发送短信验证码）。

1.2.2虚拟私有云

　　　在我们系统最底层的是通常采用的时阿里云/AWS计算平台，阿里云/AWS本身就提供了很多安全机制，其中的所谓虚拟私有云（VPC：Virtual Private Cloud）是其提供的网络层级的安全手段。

　　　我们可以根据我们的网络规划，创建相应的VPC。VPC本身就是一个虚拟网络，它在逻辑上将我们的云计算资源与阿里云/AWS平台中其他客户的云计算资源隔离开。

VPC中提供了网络路由、Internet网关、VPN网关等网络工具，并允许我们在其中创建多个子网，指定其中某些子网可以通过Internet网关访问外网，也就是通常我们说的DMZ区域。而将其它的子网隔绝在Internet之外。子网之间可以通过设定的路由进行互通。

l子网A

　　　我们将图例中的子网A设置成我们SaaS系统的内网（Intranet），所有在这个子网中的计算资源和实例不能从Internet上直接访问。所以我们将数据库，API服务实例，业务逻辑处理单元实例等系统组件服务放在了该子网中

l子网B

　　　我们将图例中的子网B设置成我们SaaS系统的DMZ区域，在这个子网中的计算资源和实例被允许从Internet上直接访问。所以我们将Web Server，Mobile Server等用户交互单元的计算服务实例放置在这个子网中。系统的最终用户通过网页、App等终端方式来访问和获取相应的软件功能服务。

lVPN

　　　对于系统的开发与运维工作，我们使用了VPC内置的VPN网关功能，在阿里云/AWS的VPC和我们公司内网之间建立持久的VPN通道。这样我们的开发和维护人员就可以方便的在公司内连接至VPC中没有Internet连接权限的子网A中做相应的工作了。如在紧急情况下，我们的工作人员还可以通过安全的VPN连接从家中拨入公司网络，从而也能访问到阿里云中的相关资源。

1.2.3程序访问权限和DevOps权限

　　　阿里云/AWS平台提供的另外一项重要的安全机制是身份与访问管理（Identity and Access Management）。我们利用这套安全工具来管理我们系统程序本身运行时的资源访问权限和我们的运维人员的系统访问权限。

l程序访问权限

　　　我们的系统是基于SOA的架构进行设计，所以其中有众多的组件服务，每一个服务程序都需要访问不同的资源，比如数据库中的数据表，云存储中的文件等。如果按照传统的软件配置模式，每一项资源的访问都需要生成和配置相应的密码和Token，大量的内部密码Token管理起来很麻烦，而且潜在的安全风险很大。而阿里云/AWS的IAM机制可以让我们无需为资源的访问生成密码Token，我们只需创建相应的IAM角色，将资源的访问权限赋予角色，再把角色分配给服务计算实例上即可。这样只要程序是运行在具有相应角色的服务计算实例（虚拟服务器）上的，就会自动获取这些角色拥有的资源访问权限。

　　　而根据我们的前面描述的设计，关键的API和业务数据和逻辑处理单元所在的服务计算实例都位于VPC的内网中，可以安全的运行和访问各种资源；而位于外网的用户交互处理单元的服务计算实例因为并不需要直接读取资源和写入数据，所以我们并不需要给它们分配IAM角色。这样它们也就根本没有访问资源的权限了。

l运维人员访问权限

　　　而在我们开发和运维人员的管理中，我们利用IAM机制去创建相应的用户和组。将用户对应到具体的人，将组对应到具体的岗位，这样就可以自然而然的进行权限的分配和管理了。同时我们启用阿里云/AWS内置的各种审计功能，对所有开发和运维人员的操作进行记录和审计。确保所有人都按规定和规范开展工作。

1.3系统扩展性

1.3.1基于SOA的技术架构

　　　面向服务的体系结构（Service-Oriented Architecture，SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务），通过这些服务之间定义良好的接口和契约联系起来。如果一个大的系统基于SOA的架构来做设计，那么即使系统再复杂、再庞大，也会具有良好的扩展性和灵活性。

　　　凌立系统以SOA架构为基础，将复杂的功能进行分解，将通用的功能进行归类，以松耦合的方式将各种功能打包成一个一个的服务。服务之间通过JSON格式的数据进行调用与数据交换，并将数据存储、业务逻辑处理、用户界面交互等进行分层。

1.3.2云服务

　　　位于凌立架构最底层的是阿里的阿里云服务，提供了程序运行的计算环境和数据存放的存储空间，并且还提供了多种可以直接使用的应用服务，比如对列和工作流等。阿里云所有的云服务本身也都是基于SOA结构的。

1.3.3数据存储

　　　凌立使用了阿里云的关系型数据库服务（RDS）来存储租户的业务数据、使用阿里云的云存储服务（OSS）来存储所有的相关的数据文件，包括图片、资料文件、视频文件等等。而这些文件和其他相关的业务对象的元数据（Meta Data）被存放到了阿里云的非关系型数据库中（DynamoDB）。并且所有这一切的数据都按国内的法规要求全部存放到了阿里云位于我国境内的站点中。

　　　在凌立的架构中，存在不限数量的多个租户数据库。根据每个租户不同的规模和使用量，我们就可以很灵活的将不同的租户部署到不同的租户数据库中，从而避免对计算和存储资源的竞争。

1.3.4Cloud API

　　　按照SOA的设计思路，凌立把一些通用的、公共的系统功能做成了API服务（我们称之为云API），可以提供给整个系统中其他模块进行调用，这些公共服务主要包括：用户身份认证、移动消息推送、文件存储、文件格式转换、照片存储与管理、后台任务管理等。并且因为SOA的架构，所以未来我们还会增加更多的API服务。

1.3.5业务逻辑处理单元

　　　在API之上，是凌立的业务逻辑处理单元，里面包含了各种系统的业务和数据处理程序（服务）。这里的程序并不和最终用户进行交互，而实际上这些服务是由更上一层的用户交互处理单元来调用。在定制和二次开发中，这里的业务和数据处理服务是可以被二次开发的程序替换的，这样就会很方便的让客户添加定制的、特定的功能了。

1.3.6用户交互层

　　　而在业务处理单元之上的就是负责与最终使用软件的用户进行用户界面（UI）交互的处理程序（服务）了。根据用户使用的不同终端方式，凌立分别提供了基于网页浏览器的Web Server，基于移动终端设备（手机、平板）的Mobile Server，以及通过WebSocket接口使用的企业社交聊天服务Chat Server。并且因为SOA的服务架构，未来如果有新的用户交互终端出现，凌立也可以方便的添加新的交互服务程序。

1.3.7非关系型数据库使用

　　　而这些文件的元数据（Meta Data）被存放到阿里云提供的Dynamo DB中。Dynamo DB是一种非关系型（NoSQL）数据库，Dynamo DB的数据存储全部使用SSD硬盘，这样就为我们的租户文件提供了超高速的检索性能。