saas授权体系（技术与案例详解）

【本章导读语】软件安全性的确是一个广泛而复杂的主题这一领域的最大挑，我来为大家讲解一下关于saas授权体系?跟着小编一起来看一看吧!

saas授权体系

【本章导读语】

软件安全性的确是一个广泛而复杂的主题。这一领域的最大挑

战之一是：总可能有完全不符合所有已知模式的新型安全性缺陷出现。

________Gary McGraw,《软件安全性原则》

SaaS模式的安全性有哪些需求，是否存在潜有有安全隐患，如何识别SaaS安全风险，如何做好SaaS安全服务，如何规避SaaS共享平台与数据托管的风险，如何建立安全保障体系做好安全架构设计，如何搭建安全的SaaS平台，这些都是SaaS开发和运营商不得不面对的问题。

有人说：SaaS模式的数据存储在公网上，掌握在SaaS服务商的手上。而且，黑客可能破解并进入数据服务器，获取数据，这听起来好像有些道理。有人甚至说：使用SaaS软件时，很容易把病毒带到公司的内部网络，甚至把病毒传染到其他服务器，这无形中给公司内部网络带来隐患。

也有人说：SaaS实际上提升了信息化系统的安全性，因为安装在局域网的软件系统也面临一些安全的问题，SaaS有更专业的安全保障机制及技术，SaaS系统比传统软件更可靠。

面对种种问题我们应该怎么做呢？

10.1 SaaS的安全性需求

SaaS平台和在平台之上架设的应用程序的安全性需求与一般的软件有所不同，SaaS服务软件必须是放在Internet网上，数据库有多种存放模型，所以SaaS的安全性需求有其特殊性。

10.1.1 SaaS应用程序安全需求要点

多承租者、高效的SaaS应用程序具有以下几点安全需求：

l 安全访问

系统必须架构在安全性的环境下，提供各种安全保障，并且多用户的访问必须在统一的权限控制下根据相应的功能进行访问，关键数据同时提供保密措施。

l 24小时不间断的运转

服务器应该7x24x365不间断的运转，每时每刻提供的网络服务是有效的。不会因为停电、设备故障、死机、软件死锁等系统失效而间断运行。在万一出现软、硬件故障应该及时恢复和处理。

l 永久存储

用户数据必须是永久存储的，存储不失效，数据不丢失不出差错，存储服务不失效。

l 满足不同软硬件的接入

允许异构硬件、异构操作系统的接入。满足这些需求需要有统一标准的接口、命名、开发与设计规范。

l 用户数据的安全需求

1. 用户数据的可能位于一个自行管理的环境中。

此种情况系统应该提供相应的机制，以便使用自行管理环境中的用户数据对用户进行身份验证，并使用按需环境中的访问控制数据进行授权。

SaaS提供者可以利用商用的、现成的（COTS）联合服务器，以便在不同安全域的应用程序中安全地传播联合令牌。SaaS提供者需要使用联合服务器，这与在按需环境（用于 SSO 解决方案）中的企业客户所使用的其他SSO解决方案是可互相操作的。位于自行管理环境中的联合服务器必须与SaaS提供者的网络中相应的联合服务器具有信任的关系。

使用自行管理用户帐号数据库，您还应该：

² 开发一个 Servlet 筛选器，用以从HTP Header中检索使用联合服务器进行了身份验证的用户名，并创建一个有效的主体/主题。

² 利用基于Java身份验证和授权服务（JAAS）的自行构建的安全服务，以便在授权过程中处理SaaS的多承租需求。

² 从Servlet筛选器调用安全服务应用程序的编程接口（API），来对用户进行授权。

² 使用Controller Servlet of Presentation Framework配置Servlet筛选器，它建立在模型-视图-控制器（MVC）设计模式的基础上，用以确保传入的请求满足安全需求。

2. 用户数据可能位于一个独享数据库中。

由于承租者高度的数据隔离和遵从性需求，用户数据可能位于按需环境中的专用数据库（用于每个承租者）中。系统应该提供一种根据独立的数据库域（对用户所属的承租者进行了配置）进行用户身份验证和授权的机制。

3. 用户数据可能位于一个共享的数据库中：

系统应该提供一种根据共享数据库（为用户所属的承租者配置了不同的数据库模式）进行身份验证和授权的机制。这种机制以便允许每个承租者的管理员在用户帐号目录中为该承租者创建、管理和删除用户帐号。

l 随地高速访问

SaaS提供的软件服务应该是没有世界地区差异造成的访问限制或速度限制或功能限制或存储限制。

用户的业务要随时随地能处理，您不能因为您的服务器有问题了，您的电信机房有问题了，您的南北电信隔离有问题，而使用户使用受限制。而且用户的数据是安全的，不能告诉用户您的服务器硬盘有问题某段数据丢了。用户的操作也是安全的。互联网上有许多黑客和黑客软件，用户可不想让黑客知道了自己的登陆密码。现在，使用网上银行的很多人都被窃取了银行账号丢了钱。

许多人认为Google最强大的是Google的搜索和Google的关联广告，还羡慕Goolge有钱能建电厂、能发卫星、能购买无线频段，能有大量资金并购Youtube。其实，Google最大的核心就是多年运营搭建了这个可信计算环境。这是目前唯一的一个互联网上的可信海量计算环境——没有稳定的基础，用户怎敢还相信上层的应用呢？谁还敢把数据存放在上面呢？

而国内SaaS厂商，还在用传统的做中大型管理软件的做法在做计算环境，集群、不间断电源、企业存储设备、企业备份设备。这些传统做法支撑一家大型企业应用运行没有问题，但是要服务全球，服务全球企业，这个计算环境显然是无法快速的、低成本的扩展的。最后很可能形成一个瓶颈，不是上小型机，就是把企业分配到不同的服务器集群上——就跟现在做网络游戏一样。我们无法轻松的堆砌上万台PC甚至几十万台服务器来扩展计算环境。当然，如果您想做的SaaS只想服务国内，甚至国内小企业，甚至是国内某行业的小企业，那就另当别论。对于不同目标，当然技术架构层面会发生质变，而不是裁减的量变。

10.1.2 处理各种安全需求

要处理SaaS的应用程序及安全需求，您的体系结构应该处理身份验证和授权需求。

l 按需环境中的用户帐号数据库

为什么您应该自行构建一种安全的解决方案呢？一项重要的技术需求是，SaaS应用程序可以在一个基础结构中承载多个承租者。为了处理这个需求，SaaS提供者必须提供一种运行单个SaaS应用程序实例的机制，以便容纳来自于该应用程序所支持的所有承租者的用户。

图10-1显示了SaaS应用程序的一个实例如何为多承租者的用户提供支持。Security Service为Tenant 1和Tenant 2的所有用户使用缺省的集中式Database 1。同时，为了处理 Tenant 3和Tenant 4高度的数据隔离和遵从性需求，Security Service还必须提供一种机制，以便为Tenant 3的所有用户支持专用的Database 2，并为Tenant 4的所有用户支持专用的 Database 3。

图10-1 支持多承租者的用户

安全框架需要为每个承租者提供独立的域，并提供一种机制以使用该域（以上下文为基础，对客户所属的承租者进行了配置）对用户进行身份验证。在这个示例中，上下文是决定应用程序的业务操作和使用环境的参数组合（如承租者、业务部门、地理位置，等等）。

对于在给定的时间支持多个活动的安全域，基于J2EE容器的安全框架存在一定的限制。尽管所有优秀的J2EE容器提供了配置多个域的机制，但是一次只能有一个域是活动的。J2EE安全模型以方法权限为基础，因此对于细粒度的安全访问来说，它既不切实际又很麻烦。

所以，为了基于Java身份验证和授权服务（JAAS）构建自定义的安全服务，您所需要做的就是处理上述的限制。JAAS是允许服务对用户进行身份验证、并强制实施访问控制的一组API。通过在应用程序，以及异类的身份验证和授权机制之间放置抽象层，JAAS 可以简化Java安全开发。

构建基于 JAAS 的自定义安全服务

基于 JAAS 的安全服务应该提供完成以下任务的机制：

在访问任何业务功能之前建立用户标识。

通过维护用户的访问控制列表来提供功能和数据权限。

支持用户、组合 ACL 的创建和维护。

处理SaaS应用程序的多承租需求。

允许每个承租者的管理员在用户帐号目录中为该承租者创建、管理和删除用户帐号。

与其他的企业应用程序相比，为SaaS应用程序构建安全服务的重要区别在于，支持处理多承租的需求。为了处理这个需求，安全服务应该处理下面的事项。

捕获用户上下文的方法

同样，上下文也是决定SaaS应用程序的业务操作和使用环境的参数组合（如承租者、业务部门、地理位置，等等）。

在这个场景中，体系结构应该提供自主构建的安全服务，以便根据集中式的多承租者的用户帐号数据库，以及承租者特定的专用数据库，来进行用户的身份验证和授权。体系结构还应该提供一个接口，以便承租者能够在用户帐号目录中为该承租者创建、管理和删除用户帐号。

在单点登录对于客户来说并不是非常重要的情况下，我们推荐使用这种方法。这种方法可以针对使用者用户。

l 创建三种数据体系结构

为创建多承租者的数据体系结构提供下面三种不同的方法：

1. 专用的承租者数据库

将为每个承租者提供一个专用的数据库。在客户具有高度的数据隔离需求的情况下，我们推荐使用这种方法。

2. 共享数据库，独立模式

所有的承租者都使用一个共享数据库，并且在为该承租者所创建的独立模式中，每个承租者都具有自己的一组表。安全服务可以使用图10-2中的数据库表，以支持这种专用的承租者数据库方法。

图10-2 专用的数据库模式

3. 共享数据库，共享模式

所有的承租者都将使用共享数据库和共享模式。对于这种方法，在所有表中，Tenant ID 列可以将每条记录与合适的承租者进行关联。图10-3显示了一些数据库表，安全服务可以使用它们来支持这种方法。

图10-3 共享数据库模式

根据大多数承租者的需求，选择缺省的数据体系结构策略。利用一种提供了以下功能的持久性框架：

² 配置驱动机制，该机制允许您使用一个多重数据库策略连接到数据库。

² 使用基于接口的数据访问对象（DAO）设计模式来实现持久性逻辑的机制。

² DAO Config XML 配置驱动机制，以便允许插入到不同的 DAO 实现，并提供了一种映射，以便将DAO逻辑名映射为实现细节。

对基础XML配置的需求，以便与缺省数据体系结构策略的数据库实现交互。提供自定义的XML配置，以便与那些需要使用其他数据体系结构策略的承租者的数据库实现交互。提供一种方式，以检索描述每个承租者特定的配置和扩展信息，并根据承租者上下文在运行时插入这些自定义的配置。

l 自行管理的用户帐号数据库

在这个场景中，承租者部署了一种联合服务，它为该承租者自己的用户目录服务提供了接口。当最终用户尝试访问这个应用程序时，承租者的联合服务器将对该用户进行本地身份验证，并与SaaS联合服务器进行协商，以便为该用户提供经过签名的安全令牌。SaaS提供者将使用这个由承租者的联合服务器所颁发的安全令牌进行授权。

在单点登录（SSO）对于客户来说非常重要的情况下，我们推荐使用这种方法。它还可以针对业务用户。

l 解决对软件商、服务商的信任问题。

大多数客户不能完全百分之百的完成系统的维护，此时厂商提供服务时，厂商的技术人员一样可以很方便的接触到用户数据。

另外，安装在客户局域网的系统升级的时候，都是由局域网内部服务器发起访问外网，此时内网外网对于开发厂商来说是透明的，这也存在用户对软件服务商的信任问题。

据统计，信息化系统的安全威胁90%都来自局域网内部，可怕的黑客病毒或木马程序的危害远远大于服务器被攻破；比如Arp欺骗导致内网全数据泄密，利用Arp欺骗而传播的病毒，黑客可能较容易进入核心的数据服务器。

l 解决对内部信息系统维护人员的管理和信任问题。

内网需要专门的人员和设备来解决信息化的问题，因此存在系统维护和设备维护，一般来说，内网系统由于人员上的安排和水平是否能做到很好的数据备份或异地数据备份呢？当发生重大恶性事故的时候（比如火灾、病毒），数据被丢失的可能性很大。我们需要把专业的事情给专业的服务商去做。

既然要有人员来维护服务器，那么就会存在人员信任的问题，在内网系统中一定是“管理员权限大于老板”；在一些公司信息化中，为了节省成本，很多系统被规划到一台服务器中，因此公司不同的技术人员都有可能在服务器上获取数据。技术人员因为不满足公司，而造成彻底毁损数据、泄漏数据、出卖数据的事件不在少数。

l 传统软件系统不能放在互联网上。

很多客户都有分支机构，而且老板有出差或在家中查看公司情况的需求，也就是说存在使用互联网访问系统的需求，如果一个原运行在内网的软件放在公网上，没有https加密传输协议和数字安全证书，很难说这样的系统是安全的，这仅仅是局域网系统放在互联网上的众多安全隐患之一。

10.2 SaaS安全服务10.2.1 正确认识SaaS安全服务

l SaaS安全服务是不可逆转的趋势

随着企业信息化建设的不断深入，企业对应用系统的依赖度越来越高，为了保障企业应用系统业务连续性的需求，保障应用系统服务的安全问题是企业比较关心的话题。基于SaaS模式的安全服务因交易过程简单、风险低、零维护、即买即用、避免因传统安全产品功能不适用造成投资浪费等优点将被企业所认同，协助企业信息化建设。2006年年底国际著名调查公司Forrester Research面向中小企业进行的调查研究表明，用户规模不足1000的企业倾向采用SaaS模式的安全服务。据Forrester调查结果,有44%的公司正计划在不久的将来采用SaaS模式的安全服务。在美国，Symantec公司不久前推出了SaaS托管安全服务平台SPN（Symantec Protection Network），通过互联网为用户提供数据存储、备份和应急恢复等安全服务。Symantec公司称其在未来会基于本平台进一步推出其它SaaS安全服务。

l SaaS安全服务给中小企业带来的益处

SaaS安全服务是一种使用互联网资源提供在线租用SaaS模式的安全应用服务。SaaS安全服务使企业无需再购买专业安全产品及聘请专业安全人员来管理及维护应用系统安全，企业用户只需要支付一些租用费用就可在互联网上实现基于专业安全产品和技术、由专业安全人员提供支持的高质量安全服务。

l 中小企业信息化发展的特点和面临的安全威胁

在竞争激烈的市场环境下，大多数中小企业在规模、管理、业务发展及信息化建设上和大型企业相比，都存在着较大的差距。不同企业在面临信息化过程中面对的风险威胁是相同的，但各企业针对风险威胁的应对是完全不同的。中小企业要想在竞争激烈的市场中生存下来，在信息化建设上必须比大企业更加灵活、高效、创新。随着对企业对信息的依赖，众多中小企业已经充分认识到利用互联网资源开展信息化以节约企业成本和达到有效管理的目的。尤其是邮件系统成为了企业业务高度依赖的重要信息系统之一。但是电子邮件在给企业业务带来便利的同时也带来了巨大的威胁。

根据中国互联网协会反垃圾邮件中心《2006年第四次反垃圾邮件调查报告》显示：垃圾邮件每年给国民经济造成的经济损失约为104.315亿人民币；大陆地区邮件运营商每年为过滤垃圾邮件的费用投入约为1.11亿人民币；2006年10月到2006年12月期间中国互联网用户收到的邮件中，垃圾邮件比例为58.98%；另据RadicatiGroup全球电子邮件相关数据预测，2007年电子垃圾邮件将比2006年增长75%，并且在未来5年间保持稳定的增长趋势，预测到2011年，垃圾邮件的增长率将达到85%。这表明垃圾邮件越来越影响到企业正常的业务，企业面临的邮件危害也不断加剧。下图表示了一封病毒邮件可能给企业带来的种种危害：

图10-4 带病毒邮件传播途径

² 一封含有病毒的垃圾邮件传入公司某客户端；感染病毒的客户端计算机自动通过邮件服务器邮件列表感染局域网内的所有用户，可能会影响系统运行，破坏重要数据文件；

² 病毒、蠕虫邮件在网络中传播大量占用用户网络带宽资源，严重影响企业正常业务运行；

² 企业中被感染的局域网用户机器被种植木马程序，可能导致敏感、机密信息数据泄露（如重要文件、账号密码等）；

² 内部局域网机器感染僵尸病毒进而被非法控制使用形成被控的僵尸网络，通过本地邮件服务器大量向外发大量的病毒、垃圾邮件，进而其本地邮件服务器IP地址被国内外互联网反垃圾邮件组织加入黑名单，终止其对外的任何邮件通信，严重影响业务。

上面描述种种安全威胁几乎每一个中小企业每天都会面临，具有高度的危害性。但是如果企业通过传统方式采购反垃圾邮件设备进行安全防范，必然会面临一次性的高投资、复杂的安装、后续的专业人员维护、产品升级等一系列问题。然而如果采用SaaS安全邮件服务来进行安全保护，则可以很好地规避这些问题。因为SaaS安全邮件服务不需要企业花很多钱一次性采购设备，也不需要安装任何软件或硬件，而且更重要的是免去了维护、升级的成本和麻烦。这样，中小企业就可以把有限的资源更多地投入到发展业务中。所以，SaaS安全服务为中小企业提供了一种非常实用的资源整合契机，进而提升在市场中的竞争能力。

10.2.2 如何选择SaaS安全服务

企业采用SaaS安全服务也会面临一些挑战。首先，由于SaaS安全服务刚刚兴起，如何选择一家可靠的服务供应商是一个核心问题。尤其是安全邮件服务涉及到防病毒技术、防垃圾邮件技术以及不断的病毒、垃圾邮件样本特征升级和支持，一家拥有自主、领先核心技术的服务供应商是提供可持续、优质、高效SaaS服务的前提；另外，企业信息系统中运行并存储很多重要信息，这些信息的机密性、完整性、可用性及防泄密等是企业关心的核心问题。如何保证企业在采用SaaS服务的同时保证企业自身数据的安全也是企业在选择SaaS安全服务厂商时需要考虑的。选择SaaS安全服务和服务提供商的主要标准有以下几点：

首先，SaaS安全服务本质上还是基于安全技术和产品，所以安全服务提供商应该具有业界领先、成熟的安全技术。比如SaaS安全邮件服务提供商应该具有领先、成熟的防病毒、反垃圾邮件技术。其次，SaaS安全服务提供商应该拥有这些核心技术的知识产权，以确保后续技术支持的延续性。第三，SaaS安全服务提供商应该具有业界公认的安全服务资质和良好的公司信誉，以保障服务的可靠性和可信度。最后，SaaS安全服务提供商还应该具有较强的本地技术支持能力，以提供及时的支持服务和有效的客户化能力。

目前，国内有能力提供SaaS安全服务的厂商主要集中在具有一定实力的信息安全产品和服务提供商里。其中，由冠群金辰公司推出的KILL委托安全邮件服务是比较出色的SaaS安全服务之一。KILL委托安全邮件服务是冠群金辰基于其核心产品KILL邮件安全网关提供的。据CCID调查报告表明，冠群金辰公司在2004年到2006年间连续三年居中国安全网关市场占有率首位，并且拥有反病毒、反垃圾邮件等全部核心技术。其反垃圾邮件技术在业界数次中立评测中均名列榜首。此外，冠群金辰公司具有国家安全服务资质，还是中国反垃圾邮件联盟成员单位，具有多年的安全服务经验，能够保障服务的规范性和可靠性。另外，KILL委托安全邮件服务平台参考电信运营商规模设计，完全满足中小企业的业务需求。

10.3 SaaS安全性分类

SaaS应用的风险主要来源于两个方面：一方面是SaaS模式的数据存储在公网上，黑客可能利用系统漏洞或者破解或者窃取等方式入侵数据服务器，获取数据操作权限。另一方面是客户企业的关键数据掌握在SaaS服务商的手上，存在服务商监守自盗的风险。所以我们把SaaS安全性列为如下两个部分：

1、计算机信息的安全。

2、客户信息、财务等数据信息的安全。

第1种安全问题是企业互联网应用的客观事实。即使不使用SaaS，像传统企业门户、电子商务、网上银行等经典互联网应用也同样存在这个风险。这种风险不是SaaS特有的，而是新经济转型中不可绕过的路段。

这方面请大家放心，尤其是对于中小企业和个体用户。如果您曾经使用的B/S、C/S信息系统的时候有非正版的操作系统、缺乏安全的防火墙、不稳定的硬件、网络管理人员不足等等状况的话，SaaS软件相比这样的系统优势还是很明显的。SaaS基于专业化软硬件人员，性能稳定的服务器，基于中国电信中国网通的专业化机房，计算机安全性是可以保障的。道理很简单，如果中小企业或个人对计算机信息的安全性没有足够保障的话，那么还是建议把计算机安全交给专业公司来做。就像钱一定要存在银行道理是一样的。

第2种安全问题看似是个新问题，许多企业和组织非常在意自己的客户信息、财务信息等数据，这些数据不会轻易放在公网上，比如CRM和ERP的应用。但我们同样看到CRM和ERP的应用正在被拉下神坛，走向平民化。从SAP、Oracle之前动辄几千万美元的ERP项目到现在几万美元的SAP，再到年租金几千元人民币的国货SaaS模式的金算盘ERP，我们看到了企业应用在向中小型企业市场转移。这种风险的回避，一是需要整个行业引导和教育，让客户接受服务托管的模式。SaaS厂商需要很多推广，来让客户消除一些不理解而造成的误读。需要培养有信誉并且成熟的互联网市场，现在要SaaS厂商像数年前银行推广网银一样，让客户信赖您；二是要筛选出经得起时间考验的合格的平台运营商，树立优秀的品牌保证，通过信用机制和法律协议约定来解决服务商对客户信息保密的风险问题，让用户选择可信赖的SaaS供应商。

10.4 安全性技术

l 信息安全新技术

主要包括密码技术、入侵检测系统、信息隐藏技术、身份认证技术、数据库安全技术、 网络容灾和灾难恢复、网络安全设计等。随着网络时代的到来，网络已经改变了人们的生活和工作方式。互联网技术、无线网络技术以及信息化的不断深入和发展，已经出现了在线购物、在线炒股、手机银行及网上办公等各种各样的信息应用。这些技术和方法是任何一位从事信息安全相关工作的人士必须具备的知识。

1、传输协议加密

首先，要看SaaS产品提供使用的协议，是https://还是一般的http://，别小看这个s，这表明所有的数据在传输过程中都是加密的。如果不加密，网上可能有很多“嗅探器”软件能够轻松的获得您的数据，甚至是您的用户名和密码；实际上网上很多聊天软件帐号被盗大多数都是遭到“嗅探器”的“招”了。

其次，传输协议加密还要看是否全程加密，即软件的各个部分都是https://协议访问的，有部分软件只做了登录部分，这是远远不够的。目前，Salesforce、XToolsCRM都是采取全程加密的。

2、服务器安全证书

服务器安全证书是用户识别服务器身份的重要标示，有些不正规的服务厂商并没有使用全球认证的服务器安全证书。用户对服务器安全证书的确认，表示服务器确实是用户访问的服务器，此时可以放心的输入用户名和密码，彻底避免“钓鱼”型网站，大多数银行卡密码泄漏都是被“钓鱼”站钓上的。

3、URL数据访问安全码技术

对于一般用户来说，复杂的URL看起来只是一串没有意义的字符而已。但是对于一些IT高手来说，这些字符串中可能隐藏着一些有关于数据访问的秘密，通过修改URL，很多黑客可以通过诸如SQL注入等方式攻入系统，获取用户数据。XToolsCRM采用安全码技术对传入的数据进行验证，使URL更为安全。

4、数据的管理和备份机制

SaaS服务商的数据备份应该是完善的，用户必须了解自己服务商为您提供了什么样的数据备份机制，一旦出现重大问题，如何恢复数据等。服务商在内部管理上如何保证用户数据不被服务商所泄露，也是需要用户和服务商沟通的。

5、运营服务系统的安全

在评估SaaS产品安全度的时侯，最重要的是看公司对于服务器格局的设置，只有这样的格局才是可以信任的，包括：运营服务器与网站服务器分离。

服务器的专用是服务器安全最重要的保证。试想，如果一台服务器安装了SaaS系统，但同时又安装了网站系统、邮件系统、论坛系统……，他还能安全吗？在黑客角度来说，越多的系统就意味着越多的漏洞，况且大多数网站使用的网站系统、邮件系统和论坛系统都是在网上能够找到源代码的免费产品，有了源代码，黑客就可以很容易攻入。很多网站被攻入都是因为论坛系统的漏洞。

因此，一个优秀的软件SaaS运营商，运营服务器和网站服务器应该完全隔离的，甚至域名也应该分开。

6、重视厂商的历史和专业性，有助于建立信任关系。

专业的SaaS厂商可能比用户更加注重安全，因为SaaS的“安全性”就是厂商的“饭碗”。就像在网上买东西，我们用户需要看看厂商获得用户方面的评价，和媒体的口碑，看看是否专业和专注SaaS。有些厂商仅仅把SaaS产品作为炒作的噱头，可能危害的就是用户。

l 用户帐号

用户帐号采用MD5算法进行加密，保证不会被非法人员窃取。可通过SSL对网络连接进行加密，保证登录的明文密码不被窃取。每个企业都有独立的企业号，企业管理员可定义企业级的角色并分配用户权限。

l 数据安全

数据库服务器放在单位内网，通过Web服务器和防火墙隔开，可以保证外网不能直接访问数据库中数据。

在系统中，还提供了在线备份模块，管理员可随时对数据进行手动或自动备份。系统还支持远程备份，实现了对系统的远程管理和维护。

服务器采用安全认证系统，保证只有授权用户才可以访问。

l 准确到位的内部权限设置，保证内部数据安全

权限设置包括两种：角色权限设置和组织目录权限设置。

用于设置每个用户在STS中的操作权限。用户的身份通过帐号（和密码）的设置来体现，而帐号则和角色相对应，角色则是系统内部许许多多具体权限的组合。用户使用帐号登录后，系统会根据帐号调出用户所对应的角色，确定用户可选择的模块范围以及在每个模块中的操作权限。

在角色权限设置中，角色可以自定义，一个人员可以对应多个角色。这样，就可以应用系统方便的定义每个人员的工作权限，并可以随其工作范围的变更而进行灵活调整，最大限度满足单位的需求。

图10-5 权限安全

l 组织目录权限设置

组织目录权限设置主要用于SaaS的平台模块中，该模块用于提供对单位信息、资料等内容的知识管理解决方案。单位可以根据自己的需求定义信息存放的目录结构，然后根据部门、人员、从属关系对每个文件夹或每条信息、文档设置权限。这样，单位所有信息有序存储，再辅之以严格的权限设置，既方便查询，又防止信息的泄密和失窃，建立起单位的电子信息库。

l 认证

SaaS供应商通常将创建和维护用户账户的责任下放给客户，这称作下放管理权。管理权下放造成的情况是，客户负责创建不同的用户账户，而SaaS供应商应认证有关账户。根据管理权下放模式的要求，SaaS架构师采用两种通用办法来解决认证问题：一是集中认证系统（centralized authentication system），一是非集中认证系统（decentralized authentication system）。所选的认证系统不同，将导致架构的复杂性不同，也会导致最终用户应用体验的不同，因此您在制定决策时，应根据商业模型的需要来确定应用、客户和最终用户的需要。

对于集中认证系统而言，供应商管理中央用户账户数据库，该数据库为所有应用的用户提供服务。客户的管理员被授权在用户账户目录下创建、管理和删除用户账户。登录应用的用户向应用提供认证信息，有关信息根据中央目录下的信息加以确认，如果数据有效，就允许该用户访问。

图10-6 集中式用户访问

这种方法所要求的认证基础设施相对简单，便于设计和实施，也不需要改变客户自身的用户基础设施。

不过这种方法的重要缺点之一在于，集中认证系统很难实现单点登录（single sign-on），即用户一次登录，就始终能访问企业网络。没有单点登录功能，用户总会被提示输入应用登录信息，每次都要手动再次输入。

在非集中认证系统中，客户采用可与其自己的用户目录服务相连接的联合服务 （federation service）。当最终用户尝试访问应用时，联合服务将对用户进行本地认证，并发布安全令牌，SaaS供应商的认证系统将接受安全令牌，并允许用户接入应用。

图10-7 联合认证访问

在单点登录相当重要的情况下，这是一种理想的方式，因为认证在后台进行，不要求用户记住并输入一系列相关信息。不过，非集中认证方案比集中认证方案要复杂得多，而且，如果SaaS应用有着几千家客户的话，就要与众多客户的联合服务分别建立联邦式的信任关系。

在许多情况下，SaaS供应商都希望采用混合方式，对小型客户采用集中认证系统来认证和管理，而对要求单点登录并愿为此付费的大型企业提供联合服务。

l 授权

通常，存取SaaS应用中的资源和商务功能都用“角色”的概念来管理。角色与公司中的特定岗位功能映射。每个角色都被赋予一项或更多“许可”，分配到某个角色的用户就能根据相应的“业务规则”执行行动。

图10-8 角色授权

SaaS应用内部负责对角色进行管理，角色可包含单个用户的账户以及用户群组。不同用户账户和用户群组根据需要被分配到不同的角色。

根据用户所分配到的角色，该用户可获得一项或者多项许可，以执行特定的操作或活动。这些活动通常直接与重要的商务功能或应用管理本身映射。例如，购买应用可能包括创建、提交、批准以及拒绝购买订单的相关许可；抵押经纪公司的应用会包括检查借款人信用和批准贷款的许可，等等。可根据需要向一个或多个角色分配一个许可；每个用户可根据所属的角色获得相关角色的所有许可。

应用可根据商务规则对活动和资源的使用实现比许可更精确的控制。商务规则规定了在允许使用前必须满足的条件。例如，您可使用相关商务规则，只允许用户在正常办公时间内在不同账户间转账，或者规定转账金额不得超过一定数量。

存取控制由配置域管理。每个配置域根据应用的关系策略继承上级配置域的角色、许可和商务规则，并可在适当的时候对其进行修改、添加和删除。例如，假设有家客户总部设在美国，并在加拿大多伦多设有分支机构。根配置域设有最基本的“福利管理员”角色，可针对雇员福利管理提供一系列许可，其中包括管理公司的 401（k）退休储蓄计划等。由于 401（k）计划是美国税收法律的产物，不适用于加拿大，因此我们可为加拿大办事处构建子配置域，在继承“福利管理员”角色和相关许可的同时，对角色的许可给出特殊处理，以修改401（k）计划相关内容。在修改原许可的同时，客户增加了新的许可，允许该角色修改注册退休储蓄计划（RRSP）项目，即加拿大相当于美国 401（k）的立法。

图10-9 配置域管理的角色授权

从最佳实践角度看，应用应向所有用户提供一系列默认的角色、许可和商务规则，并允许不同用户通过直观易用的界面定制这些规则和创建更多规则。

10.5 安全分析模型

基于前面的安全风险分析，SaaS平台系统必须采取相应的应对措施与手段，形成有效的安全防护能力、隐患发现能力和应急反应能力，为系统建立可靠的安全运行环境和安全的业务系统，切实保障系统安全、高效、可靠的运行。

在参考国际标准ISO17799和中华人民共和国国家标准-计算机信息系统安全保护等级划分准则（GB 17859-1999），通过借鉴ISO7498-2中所描述的开放系统互联安全的体系结构，提出了如下图所示的安全分析模型：

图10-10 安全分析模型

该模型分别从安全单元、安全要素和协议层次三个层面对应用的安全体系进行全面的分析。从上图中可以看到，所有三个层面都包含了安全管理的内容，体现了技术手段为辅、严格高效的管理为主的现代管理思想。

10.6 构建SaaS安全机制

通过上面对SaaS模式的风险分析，让我们透彻了SaaS的安全性问题。安全机制和保障措施就有了落脚点。

10.6.1 建立安全保障体系

在整体安全策略指导下，将整个安全保障体系设计为安全基础设施、业务应用系统安全和安全管理保障体系三部分。我们将涉及物理安全、网络安全和系统安全等一些共性的、各个网络域均需要的安全措施与服务归结到安全基础设施；与业务应用系统安全相关的部分归结到业务应用系统安全；与安全管理相关的归结到安全管理保障体系。

通过建设安全基础设施、安全管理保障体系和应用系统安全措施，提供鉴别、访问控制、抗抵赖和数据机密性、完整性、可用性、可控性等安全服务，形成集防护、检测、响应、恢复于一体的安全防护体系，实现实体安全、应用安全、系统安全、网络安全、管理安全，以满足安全需求：

1. 安全基础设施：

² 防火墙系统：根据各安全区域具体的安全防护策略，实现各安全区域的边界保护。

² 监控检测系统：发现和修补安全漏洞，对各种入侵和破坏行为进行检测和预警。包括脆弱性扫描、入侵检测、WEB网页防篡改等机制。

² 防病毒系统：防范病毒入侵和传播。

² 容灾备份系统：对核心组件进行容灾和备份。

2. 业务应用系统安全：

² 数据传输安全：通过数据传输加密、SSL等手段保障数据传输的安全性。

² 数据存储安全：通过关键数据加密存储、数据恢复等手段保障数据存储的安全性。

² 安全访问：提供授权管理服务，实现对信息资源和服务的有效管理和访问控制，在统一用户管理的基础上，建议提供身份真实性鉴别服务，建立可信的安全信任环境。

² 系统监控：通过对设备、软件、在线人数的监控以及日志管理等手段保障系统安全的可控性。

3. 安全管理保障体系：

² 安全管理组织：形成一个统一领导、分工负责，能够有效管理整个企业信息化的安全工作的组织体系。操作系统管理员、数据库管理员、软件应用管理员、分别由不同人员担任，禁止任何对客户数据的非授权操作。对数据的备份与恢复要通过生产控制系统以计划任务的方式完成。对任何可能对客户数据造成影响的操作均要经过分级审批。

² 安全标准规范体系：指导企业管理信息化建设的安全标准规范体系。

² 安全管理制度：包括实体管理、网络安全管理、软件管理、信息管理、敏感信息介质管理、人员管理、安全保密产品管理、密码管理、维修管理及奖惩等制度。

² 安全服务体系：系统运行后的安全培训、安全咨询、安全评估、安全加固、紧急响应等安全服务。

² 安全管理手段：利用先进成熟的安全管理技术，逐步建立安全管理系统。

4. 灾难恢复

由于存在于服务器中的数据容易受到各种因素的影响，如计算机病毒，人为误操作，黑客恶意的攻击，电源故障，自然灾害等，从而导致数据的丢失，甚至系统完全崩溃，如何快速地恢复系统，这就需要灾难恢复解决方案。

5. 灾难恢复中心

建立的一套计算机网络系统，这套系统能在突发性灾难发生，造成生产中心停止工作时，迅速并及时地接管原来运行在生产中心的所有或部分业务，达到减少或避免灾难事件发生时所造成的损失，为企业用户提供完善、优质服务的目的。

6. 灾难恢复中心的两种模式

² 非实时模式：就是利用磁带备份技术，计算机中心人员每天定时备份计算中心数据，并及时送往灾难恢复中心，尽量保证灾难恢复中心拥有计算中心的最新数据，一旦灾难发生，灾难恢复中心可将业务在较短的时间内恢复运作。这模式的特点是在数据备份问题上技术难度不大，但很难保证计算中心与备份中心间数据的实时性一致。

² 实时模式：就是在计算中心和灾难恢复中心之间通过通信线路，利用数据实时备份，将计算中心主机的数据实时送往灾难恢复中心，保证计算中心与备份中心间数据一致。当灾难发生，计算中心陷于瘫痪时，灾难恢复中心在最短的时间内，接管所有或部分业务，恢复系统正常运作。

7. 灾难恢复所需要的条件：

² 服务器本身采用较高可靠性的RAID配置，至少要求RAID5E；

² 制定合理的备份策略，不能在本机存放备份数据，备份重要数据到磁带和其它存储设备；

² 采用专业备份软件如：vertias 、legato等

8. 灾难恢复的实施步骤:

² 联系相关人员。公司需要有一种方法来迅速召集相关人员到灾难恢复现场。

² 快速找到您的灾难恢复计划。在远离办公地点的地方（如车上、家里甚至公文包）保存灾难恢复计划副本，并将副本提供一份给您的非现场存储供应商。

² 联系您的供应商，寻求他们的帮助。如果您面临实际灾难恢复计划施行，请致电专家寻求援助。如果您要从磁带上恢复数据，您的非现场灾难恢复存储供应商应当把磁带送到恢复现场，以便您的备份软件供应商能够帮助恢复存档数据。

² 调用次级站点。采用VERITAS公司提供的高可用性灾难恢复软件，可以将业务从受灾站点切换到次级站点，而不会中断业务，这有助于将灾难对员工、客户和合作伙伴的影响降至最低。

² 确定紧急次级站点。如果次级站点无法使用或者出现故障，就立刻想别的办法，即使其他所有措施都不能用，宾馆舞厅或会议中心配备的高带宽连接和空调设备也能够为灾难恢复提供足够的资源。

10.6.2 安全保障措施

l 在机房和网络上提供强有力的安全保障措施

1、建立高级IDC机房，配备完整的制冷、防尘、双路供电、消防系统。

2、提供365天全天候运营服务。

3、完善的网络架构，严密的网络安全设计，行业领先厂家的网络安全产品。

l 在用户数据的安全上提供强有力的安全保障措施

1、用户敏感信息在互联网的传送采用SSL加密传输，保证用户数据不会被窃取。

2、数据库采用双机冗余热备方案，并定期备份至异地服务器，确保用户数据安全可靠。

3、严格的用户数据授权，无须担心他人看到自己的数据。

4、数据系统中所有涉及用户机密部分全部采用不可逆加密算法密文存储，他人无法得到原始数据。

l 建立健全的管理制度

1、7×24的运维服务，严格的安全审计制度，确保服务稳定、安全。

2、坚持“用户第一，客户至上”的理念。

3、遵循ISO 27001等相关国际标准，制定严格的运行制度。

4、保密责任——合同约定

购买Saas服务的用户，将与SaaS服务提供公司签订服务合同。其中约定：双方对合同的书面资料及其它有关的商业机密负有保密责任，不得以任何形式、任何理由透露给第三方；否则，任何一方都有权利向对方请求损失赔偿，并依法追究法律责任。保密责任不因本合同的无效、提前终止、解除或不具操作性而失效。

5、设置有效安全的用户密码

为了您的帐户安全，请尽量设置复杂密码，不要设置有规律，您容易记忆的密码，同时也很可能被轻易猜出来。请参考以下建议：

密码长度为6到16个字符；

密码安全性级别说明：

A．当您仅使用英文字母、数字、特殊字符中的其中一种来设置密码时，如sqpofeHWESIS、54894565、%$#!%@等，系统会提示您密码的安全性级别为“不安全”；

B．当您使用英文字母、数字、特殊字符的任意两种组合时，如uTEh47dy61、dg%ah$aj、25$2*04!63等，系统会提示您密码的安全性级别为“普通”；

C．当您使用英文字母 数字 特殊字符的组合时，如sd8bjh*dh、sge352%ds等，系统会提示您密码的安全性级别为“安全”。

千万别把您的密码设置成以下这样，这样的密码同样安全性过低；

A．密码和会员登录名完全一致；

B．密码和您的联系方式“电话”、“传真”、“手机”、“邮编”、“邮箱”的任何一个一致，如：85027110、075585027110；

C．密码用连续数字或字母，如：3456789、987654、abcdef；

D．密码用同一个字母或者数字，如：88888888，aaaaaa；

E．密码用会员登录名或邮件地址中的一部分，如您的会员登录名是 carry770815，勿使用770815作为密码；

F．密码用您的姓名、单位名称、和任务中国有关或其他任何可轻易获得的信息。如：zhangxueyou、taskcn；

G．密码用简单有规律的数字，如：789456、123321；

请您按照系统的安全性级别提示修改您的密码，直至符合安全性要求。

如果您目前设置的就是安全性过低的密码，请立即修改密码。

无论您使用多么性能强大的硬件，无论您使用多么昂贵的软件，保证自己的PC安全才是基础中的基础。

试想如果您的个人电脑崩溃了，或者您的个人电脑被病毒纠结，或者被黑客入侵，再强大的软硬件都白搭。所以我们在本期SaaS安全专题里对个人计算机安全也提供相关资讯。

l 建立多级的网络安全防线

网络安全第一线：禁用不必要的服务和共享。

Windows提供了许许多多的服务，其实有许多我们是根本也用不上的。或许您还不知道，有些服务正为居心叵测的人开启后门。Telnet就是一个非常典型的例子。还有一个值得一提的就是NetBIOS。这些都是存在潜在的安全隐患！建议禁止相关服务。删除共享：在windows下命令行窗口输入 net share c$ /delete（以C盘为例）。

网络安全第二线：打补丁。

Microsofe公司时不时就会在网上免费提供一些补丁，有时间可以去打打补丁。除了可以增强兼容性外，更重要的是堵上已发现的安全漏洞。

网络安全第三线：

反病毒监控。这里将给大家列举国内外主流杀毒软件：

卡巴斯基（Kaspersky）、赛门铁克（Symantec、Norton）、江民（KV）、瑞星（rising）、金山毒霸（KAV）、趋势科技防毒精灵（PC-cillin）、McAfee。

网络安全第四线：网络防火墙。

Firewall 防火墙一种确保网络安全的方法。防火墙可以被安全放置在一个单独的路由器中，用来过滤不想要的信息包，也可以被安装在路由器和主机中，发挥更大的网络安全保护作用。防火墙被广泛用来让用户在一个安全屏障后接入互联网，还被用来把一家企业的公共网络服务器和企业内部网络隔开。另外，防火墙还可以被用来保护企业内部网络某一个部分的安全。

当然对于个人用户安装软件防火墙就可以了。

网络安全第五线：数据备份

对于系统可以选用Ghost（或者相关的ghost软件，如一键还原精灵等）进行备份。有条件的朋友可以将备份刻录到光盘中。这样就可以在必要时毫不费力的恢复自己的数据。另外就是即使对邮件、聊天记录、收藏夹等信息做安全备份。

10.6.3 安全保障方案

l 方案一：双机热备灾难恢复。

服务器多台做双机，WEB和杀毒服务器不做双机。双机可共享RAID，或者单独配置RAID。每台服务器配置：RAID5 多盘热备 SCSI热插拨，Win2003 应用程序 双机热备专用软件。采用RAID阵列数据恢复专用软件 。

l 方案二：采用两台IBM企业存储服务器（ESS）作为灾难恢复的主要设备。

一台放在计算中心，另一台放在灾难恢复中心。两台IBM企业存储服务器之间由光纤连接，距离最远可达4000公里，两台IBM企业存储服务器均配置PPRC（点到点远程拷备）功能，网络间采用经IBM公司认证的CNT公司网络延展器UWO。

l 方案三：采用IBM公司的企业存储服务器（ESS）和光纤通道存储磁盘阵列FAStT500。

利用RS/6000内的镜像功能，实现数据容灾。该方案的缺点是距离只有10公里，而且由于由主机来实现镜像功能，要占用一部分主机资源，而且距离越远，性能下降越大。

l 方案四：采用IBM公司的企业存储服务器（ESS）和IBM公司的LTO大型磁带库。

将数据每天备份到磁带库中，将磁带异地保存，这种方式的级别只有Tie 3.

图10-11 安全设备物理架构

10.7 安全体系架构设计10.7.1 安全体系架构设计

图10-12 系统安全设计

l 实现高性能、高伸缩性的架构

我们要实现了高性能、高伸缩性的架构特别需要考虑成本因素，即要考虑硬件成本，也要考虑软件成本。由于数据对整个应用来说是至关重要的，所以我们需要选用一个高性能、高可靠性的硬件（如小型机），数据库也要选用一个高性能、高可靠性、易维护的DB2数据库。而对于应用服务器这一块我们选用开源技术的组合，选用Tomcat 和Intel芯片的刀片服务器。通过相应的组合实现一个性价比很高的系统。

注：各个服务器的网络连接建议采用千兆网络进行连接，采用单独的交换机进行网络交换。

最初的架构（2台服务器）

我们在设计J2EE B/S应用系统的架构时，最喜欢采用2台服务器做为具体的部署架构；一台服务器做为应用服务器，一台服务器做为数据库服务器；并且由于数据的重要性，我们基本上会把一台具有较高价格、较高性能、高稳定性的服务器做为数据库服务器，并且数据库服务器安装AIX操作系统；一台配置较低、价格较低的服务器做为应用服务器，并且应用服务器安装 LINUX操作系统。我们假设数据库服务器具有8G内存、4颗CPU（IBM Power 5芯片小型机）；应用服务器具有4G内存、2 颗CPU（Intel 芯片的刀片服务器）。

相应的架构简图如下所示：

图10-13 最初的2台服务器架构

注：Tomcat 服务器所依赖的JDK，安装JDK1.6 64 bit，并且应用的SQL语句和程序以及DB2 V9.5和Tomcat都进行了较好的优化。

当用户数比较少的时候整个系统的运行效率非常高，但是随着用户数的上升，性能急剧下降。通过分析会发现DB2 V9.5的性能较好负载并不大，瓶颈在于Tomcat应用服务器负载很大, 并且机器的利用率也很高。为了提高性能，我们马上就想到需要对应用服务器做均衡负载，于是我们就得到下面所示的架构：5台服务器架构。

5台服务器架构

我们再购买3台新的Intel芯片的刀片服务器，每个新的机器配置为4G内存、2 克 CPU；每个机器都安装Linux操作系统。我们选用一台机器做均衡负载器，并且在这台机器上安装Apache Http Server做为均衡负载软件，并且我们在应用上把相应的静态页面（如 HTML、JS、图片、Flash 放到这台Apache Http Server这台机器上），以提升系统的响应时间；另外两台新的机器还是安装Tomcat应用服务器。如何使用 Apache Http Server和Tomcat做集群和均衡负载请参考：Apache HTTP Server 与Tomcat的三种连接方式介绍。并且采用Apache Http Server后，使我们的系统更加能够抵御非法攻击。

相应的架构图如下：

图10-14 5台服务器的架构

这样的架构在一定量的高并发数情况下，表现出良好的性能；但是随着并发数的继续增加，通过分析发现，DB2 V9.5的机器的压力很大、性能表现不好；而Apache Http Server服务器的压力并不是特别大；并且Tomcat应用服务器的压力也不大，内存也消耗不高；为了提高整个系统的性能和DB2数据库的可靠性和让DB2数据库提供一个可靠的、持续的服务；于是我们需要优化系统，在J2EE应用这一块增加 memcache（内存缓冲技术）并且对DB2数据库HA（新增加一台配置较低的数据库服务器，配置为4G内存，2 颗 CPU），防止数据库出现单点失效问题。于是就出现了下面所示的架构：改进型5台服务器架构。

图10-15 服务器的架构

采用此种架构后，性能得到的一定的提升，但是随着并发数目的进一步提升，系统又开始变慢，通过分析发现DB2 V9.5的压力降了下来，并且性能较好；但是Tomcat应用服务器的性能较低，经过技术分析我们可以看到每台Tomcat应用服务器的所采用内存缓存技术在极端情况下都是缓冲了同样的数据，这样就导致所消耗的内存太大，导致给每个Tomcat应用服务器所用的内存过少，并且被消耗了多余的CPU；于是我们需要更新内存缓存技术，最好有一个单点让我们来进行缓存数据。于是我们需要采用专门的机器来做为内存缓存。于是演化成下面所示的架构：7台服务器架构。

7台服务器架构

于是我们购买了新的一台机器（4CPU，8G内存），在这台机器上安装Linux操作系统，并部署相应定制开发的内存缓冲软件。

图10-16 7台服务器架构

采用此种架构后，性能得到了提高，但是并发量继续上升的话，Tomcat应用服务器的性能降低，于是我们需要继续购买与原有Tomcat应用服务器等同配置的硬件（4G内存，2 颗 CPU）。进行进一步的集群，当我们把Tomcat应用服务器的集群规模做大后，发现 Apache Http Server 瓶颈和数据内存缓冲服务器瓶颈出现，于是我们需要对 Apache Http Server服务器做集群，并且对内存缓冲技术进行进一步的升级即能够把数据的缓冲根据相应的请求信息（如根据不同的客户群进行HASH算法），把客户群 1的内存缓冲数据缓冲分布到内存缓冲服务器1上，把客户群2的内存缓冲数据分布到内存缓冲服务器2上。并且DB2 V9.5数据库也将承受不了相应的压力，我们需要对DB2 V9.5进行进一步的优化，把数据库分成两种，一种是专门做只读的数据库，一种是专门做只写的数据库。于是就出现了下面图10-17所示的架构。

Apache Http Server 群集和内存缓冲数据服务器群集架构

于是我们需要购买一台机器安装Nginx Http Server（4G 内存、2 颗CPU，安装Linux操作系统）做更高层次的集群，Nginx Http Server是一种更加轻量级的 HTTP SERVER，它能够承受比 Apache Http Server 更高的并发压力，举个形象的例子来说 Apache Http Server 能够承受3000并发压力的话，Nginx Http Server 就能够承受30000个并发压力。

图10-17 高度集群架构

此架构具有多个数据库，并且一个主数据库专门做写操作，然后发生变化的数据通过Q复制功能，把日志复制到相应的从数据库上进行数据的更新，这些从数据库专门做数据库的读操作；并且主数据库最好对应3个左右的从数据库；如果随着并发用户数继续上升的话，发现数据库的压力很大，我们就需要引入多个主从配置数据库，并且根据相应的信息（如用户群1的数据分布在主数据库1上，用户群2的数据分布在主数据库2上）。相应的架构如下所示：最终的架构

最终的架构

图 10-18 最终的架构图

相应的思路如下：

l 我们把我们应用的用户群体划分成几大类，如我们把来自用户1（即企业1）到用户n（即企业N）的数据全部存储在数据区1，把来自用户n 1（ 即企业N 1） 到用户2*n（即企业2*n）的数据全部存储在数据库2。每个数据区配置4个数据库DB2 V9.5数据库服务器，一个数据库做为主数据库（做为只写数据库），其它 3 个做从数据库（做为只读数据库），主数据库的数据发生变化的话通过Q复制把日志复制到其它三个数据库并重做日志，在从数据库更新变化的数据；并且每个数据区配置一个内存数据缓冲服务器群集，做数据缓冲。并且对用户的ID号，产生相应的HASH值，从而使用户能够对应到唯一一个数据区；

l 当某个用户通过在最外面的硬件均衡负载器（如 F5），并且此硬件均衡负载器能够做一层抵制攻击的防犯。硬件均衡负载器把这个用户的负载转发到某个Nginx Http Server负载器上。Nginx Http Server这个均衡负载器把这个请求转发到某个 Apache Http Server上；

l Apache Http Server再把这个请求转发某个Tomcat J2EE应用服务器上，Tomcat J2EE应用服务器得到此用户的ID信息，并得到相应的HASH值，就知道了此用户将需要操作哪个数据库，从而得到相应的数据区号；

l 如果此请求是只读请求信息，并且如果这个请求所需要的数据从内存缓存得到即可，则应用将先从内存缓存器服务器得到相应的数据信息如果内存缓冲不存在则去操作某个从数据库查询出相应的数据信息并更新内存缓冲；如果这个请求所需要的数据必须从数据库中获取，则去操作某个从数据库查询出相应的数据信息。

l 如果此请求是做事务的请求，则应用操作主数据库进行数据的更新。并根据需要来判断是否需要更新内存缓冲。

此种架构，存在大量的Tomcat应用服务器，可以根据需要增加相应的应用服务器进行性能的提升，但是由于存在大量的Tomcat应用服务器就会带来大量的管理问题，我们需要自己利用JMX来开发相应的模块来管理如此众多的Tomcat服务器或者可以把Tomcat应用服务器替换成Webspher Application Server v6.1，来利用WAS强大的管理功能。

并且这个架构还带来了一个这样的好处就是能够把负载请求均匀的分发到不同的 Apache Http Server服务器和Tomcat服务器，所以我们可以轻松的启用SSL机制来实现用户的数据在网络上的安全传输而不用考虑一台服务器是否能够承受得住。

分隔原则

如果您的访问权结构不是“完全访问或根本不准访问”，那么最小特权原则会非常有效。让我们假设您在度假，而您需要一位宠物看管人。您希望看管人只能进出您的车库（您不在时将宠物留在那里）但是如果您的车库没有一把单独的锁，那么您别无选择而只能让看管人进出整幢房子。

分隔背后的基本思想是如果我们将系统分成尽可能多的独立单元，那么我们可以将对系统可能造成损害的量降到最低。当将潜水艇构造成拥有许多不同的船舱，每个船舱都是独立密封，就应用了同样原则；如果船体裂开了一个口子而导致一个船舱中充满了水，其它船舱不受影响。船只的其余部分可以保持其完整性，人们就可以逃往潜水艇未进水的部分而幸免于难。

分隔原则的另一个常见示例是监狱，那里大批罪犯集中在一起的能力降到了最低。囚犯们不是居住在营房中，而是在单人或双人牢房里。即使他们聚集在一起―假定：在食堂里―也可以加强其它安全性措施来协助控制人员大量增加带来的风险。

在计算机世界里，要举出糟糕分隔的示例比找出合理分隔容易得多。怎样才能不分隔的经典示例是标准 UNIX 特权模型，其中安全性是关键的操作是以“完全访问或根本不准访问”为基础的。如果您拥有 root 特权，那么您基本上可以执行您想要的任何操作。如果您没有 root 访问权，那么就会受到限制。例如，您在没有 root 访问权时不能绑定到 1024 以下的端口。同样，您不能直接访问许多操作系统资源―例如：您必须通过一个设备驱动程序写磁盘；您不能直接处理它。

通常，如果攻击者利用了您代码中的缓冲区溢出，那人就可以对磁盘进行原始写并胡乱修改内核所在内存中的任何数据。没有保护机制能阻止他这样做。因此，您不能直接支持您本地磁盘上永远不能被擦去的日志文件，这意味着直到攻击者闯入时，您才不能保持精确的审计信息。不管驱动程序对底层设备的访问协调得多么好，攻击者总能够避开您安装的任何驱动程序。

在大多数平台上，您不能只保护操作系统的一部分而不管其它部分。如果一部分不安全，那么整个系统都不安全。有几个操作系统（诸如Trusted Solaris）确实做了分隔。在这样的情况中，操作系统功能被分解成一组角色。角色映射到系统中需要提供特殊功能的实体上。一个角色可能是LogWriter角色，它会映射到需要保存安全日志的任何客户机上。这个角色与一组特权相关联。例如，LogWriter拥有附加到它自己的日志文件的权限，但决不可以从任何日志文件上进行擦除。可能只有一个特殊的实用程序获得对LogManager 角色的访问，它就拥有对所有日志的完全访问权。标准程序没有对这个角色的访问权。即使您破解了一个程序并在操作系统终止这个程序，您也不能胡乱修改日志文件，除非您碰巧还破解了日志管理程序。这种“可信的”操作系统并不是非常普遍，很大一部分是因为这种功能实现起来很困难。象在操作系统内部处理内存保护这样的问题给我们提出了挑战，这些挑战是有解决方案的，但得出解决的结果并不容易。

分隔的使用必须适度，许多其它原则也是如此。如果您对每一个功能都进行分隔，那么您的系统将很难管理。

10.7.2 服务器安全架构

服务器安全架构分为三部分：对外安全，容灾安全，数据隔离。

l 对外安全

对外安全主要应该做到：

全面采用安全的服务器，并且剔除与业务系统无关的服务及软件系统；

采用全球数据安全证书，使用SSL加密的HTTPS协议；

运营服务器不允许程序员调试，运营服务器上不允许有程序源码，而所有的调试都在研发服务器上进行，经过测试、代码审查后，封装成版本，由版本分发服务器升级到各个运营服务器上。

防范SQL注入，注重代码防范、SQL监控、安全码技术等综合防范。

处理好数据、代码之间的关系，数据区与代码区完全隔离。

l 容灾备份

在SaaS整个系统中，因为服务器分布在全国各地，如果出现意外事故，如果按照常规重新装机，恢复时间也需要数天，在SaaS模式中是不允许这样的。

在容灾备份中心，我们使用了一个“数据收集”的慨念，在每台数据库执行SQL变更语句时，系统都会将变更的SQL语句记录下载，通过“数据收集”汇总在容灾中心的数据服务器上，并且做到了一对多备份；

对于文件来说，考虑到业务系统的实际需求，文件暂时使用每天增量备份传输。

业务系统产生庞大的日志，我们需要专门的日志服务器来管理这些日志，已方便用户查询相应的操作记录。

备用应用服务器可以在特殊的时候切换成应用服务器来替换任意一台出问题的服务器。

l 数据隔离

由于SaaS是多家企业使用一套系统，在服务器内部，如何做到企业间数据的隔离呢？最好的办法当然是在操作系统外使用VM软件（虚拟机）可以做到真正的隔离，但是这样成本很高，每台机器大约只能提供5个用户，这种模式无法满足SaaS的应用。

事实，良好的企业间数据隔离应该基于服务器架构，明确每个逻辑服务器的作用是很有必要的。如图10-19按功能实现了服务器的架构设计。

图10-19 服务器安全架构

认证服务器：主要处理用户身份确认和生成动态密码的作用，内部访问接口简单安全。

应用服务器：全部的应用程序，但是没有任何数据存储，可以直接替换，甚至可以使用SSD小容量硬盘。

大量的客户的请求、页面合成等操作都基于应用服务器，因此该服务器主要瓶颈是CPU，应使用多核处理器，且代码进行编译和优化。

数据服务器：一个企业使用一个独立的c，并且每个DataBase拥有独立的密码，并且密码可以动态修改。

按照数据库经验来说，使用DataBase字段做企业分离这种模式效率会高很多，尤其是大内存模式，但是由于安全需要，我们不得不选择更安全的独立DataBase模式，而且这个模式会让用户在迁移服务器时更便捷，但是带来的后果就是服务器必须同时打开更多的table，这需要我们针对服务器操作系统做特殊的优化才能达到要求。

文件服务器：用户上传的任何东西都只能列为数据文件，为了安全起见，需要改名存储到特定位置，绝不能简单地存储到Web服务器的wwwroot目录下，根据需求可以制定列表、上传、下载等简单的API。如图10-20是多用户多服务器的认证过程。

图10-20 多服务器用户认证过程

也许有人认为文件服务器不是很重要，甚至认为很简单，其实不是，大量的小文件存储导致文件碎片急剧增加，严重影响效率，需要独立的文件存储区域、碎片整理机制和缓冲机制。按照设计容量来说，5台应用服务器*2000企业*10000文件*10%（使用率）=1千万个文件。想象一下，即使是Windows的C盘，也就是5-6万文件，处理不当就会感觉硬盘缓慢，那么1千万个文件是什么慨念？解决办法有许多，比如：独立分区、将文件自动区分为活跃文件和长期存储文件两种区域单独处理。

10.7.3 案例分析：DB2 V9.5的安全控制功能

在现今最常见的采用J2EE架构的三层架构应用系统中，我们经常会运用J2EE应用服务器提供的安全控制功能，来控制不同用户具有访问不同业务逻辑模块（如用户1只能访问某个Servlet、用户2只能访问某个EJB或者某个EJB提供的方法），从而实现了相应的权限控制；然后在访问数据库的时候，我们通常会利用Spring框架或者J2EE应用服务器提供的连接池来访问数据库，从而可以实现连接的复用而降低了经常建立物理连接的开销。相应的架构图如下图所示：

图10-21 常见的安全控制的J2EE应用系统架构图

但是在使用系统提供的连接池功能的时候我们都是使用数据库系统提供的某个用户名、密码来访问数据库，这样就失去了在数据库系统这一级提供的丰富的安全控制功能；如在数据库系统中我们建立DBUSER1具有相应的特权，而DBUSER2具有其它相应的特权；然而采用上图所示的架构功能，这样对数据库系统来说仅仅只有一个DBUSER1这个用户来访问自己；然而对于整个系统来说有USER1、USER2、USER3这三个用户需要在数据库系统这一级进行详细的安全控制。这样的架构就导致整个系统失去了强大的数据库安全能力来控制对数据的访问。

很多软件开发商为了避免这样的问题，一般都会在数据库系统中建立相应的表结构来控制相应的访问权限或者通过J2EE应用服务器提供的一些功能来进行用户上下文的切换，但是这样的方法带来的代价就是性能的开销以及控制的力度不够，特别是无法实现对表中数据访问进行行一级的控制，如用户1只能查看表A中的某些行，而用户2只能查看表A中其它的一些行。

特别针对SaaS应用来说，它是给不同客户来使用的，也就是说是给不同的企业来使用的。就必须实现针对行一级访问的安全控制，即客户A和客户B运行同样的一条SQL语句，然后数据库系统必须返回符合相应的权限的数据给不同的客户即客户A和客户B看到的数据是不一样的；并且SaaS应用必须还要实现SaaS应用的软件运营商的数据库管理员也不能够查看数据库系统中的数据，这样才能够让用户放心，让用户感受到只有他自己才能够查看到专属他自己的数据而其他任何人是看不到的即使是软件运营商的数据库管理员。

为了实现这样的两个主要功能，以及避免图10-19所示架构的系统所带来的缺陷，我们需要利用DB2 V9.5中提供的基于标号的访问控制（LBAC）和可信上下文增强这两个功能来实现相应的解决方案。通过利用DB2 V9.5提供的这两个功能我们稍微修改下架构就可以解决SaaS应用以及其它应用所面临的问题。如下图所示：

图10-22 改进后的安全控制的J2EE应用系统架构图

改进后的架构图与原有的架构图的区别仅仅就是在数据库系统采用了DB2 V9.5，并且启用了DB2 V9.5的LBAC和可信上下文功能；然后简单的修改在J2EE应用服务器上相应的代码就可以实现充分利用DB2 V9.5提供的完整的安全控制功能。当利用了DB2 V9.5这两个功能后，相应的流程就改变成这样：

l 我们在DB2 V9.5中，针对企业1、企业2、企业3建立相应的用户名DBUSER1、DBUSER2、DBUSER3。并针对这些用户建立相应的LBAC控制信息，从而可以实现这些用户能够应用同一条SQL就能访问出符合不同用户权限的不同的数据。

l 我们确定在J2EE应用服务器连接池中连接DB2 V9.5的用户名（user）和密码（password），并在DB2 V9.5建立此用户名和密码。并且利用DB2 V9.5提供的TRUSTED CONTEXT语句建立相应的可信上下文。

l 在J2EE应用服务器配置相应的用户名（DBUSER1、DBUSER2、DBUSER3），并且在J2EE应用服务器上实现这三个用户的认证来自于DB2 V9.5的对应的DBUSER1、DBUSER2、DBUSER3这三个用户。

l 对J2EE应用服务器的DBUSER1、DBUSER2、DBUSER3这三个用户在应用服务器中的不同权限，如依照J2EE安全标准实现这三个用户具有访问不同SERVLET或者EJB的权限机制。

l 利用开源的连接池模块（或者利用Spring框架），实现一个连接池。

包装以下两块代码：

清单1.获得初始信任连接

// Create a DB2ConnectionPoolDataSource instance

com.ibm.db2.jcc.DB2ConnectionPoolDataSource dataSource =

new com.ibm.db2.jcc.DB2ConnectionPoolDataSource();

// Set properties for this instance

dataSource.setDatabaseName(“STLEC1”);

dataSource.setServerName (“v7ec167.svl.ibm.com”);

dataSource.setDriverType(4);

dataSource.setPortNumber(446);

java.util.Properties properties = new java.util.Properties();

// Set other properties using

// properties.put(“property”, “value”);

// Supply the user ID and password for the connection

String user = “user”;

String password = “password”;

// Call getDB2TrustedPooledConnection to get the trusted connection

// instance and the cookie for the connection

Object[] objects = dataSource.getDB2TrustedPooledConnection(

user,password, properties);

清单2.重用已经存在的信任连接

// The first item that was obtained from the previous getDB2TrustedPooledConnection

// call is a connection object. Cast it to a PooledConnection object.

javax.sql.PooledConnection pooledCon =

(javax.sql.PooledConnection)objects[0];

properties = new java.util.Properties();

// Set new properties for the reused object using

// properties.put(“property”, “value”);

// The second item that was obtained from the previous getDB2TrustedPooledConnection

// call is the cookie for the connection. Cast it as a byte array.

byte[] cookie = ((byte[])(objects[1]);

// Supply the user ID for the new connection.

String newuser = “newuser”;

// Supply the name of a mapping service that maps a workstation user

// ID to a z/OS RACF ID

String userRegistry = “registry”;

// Do not supply any security token data to be traced.

byte[] userSecTkn = null;

// Do not supply a previous user ID.

String originalUser = null;

// Call getDB2Connection to get the connection object for the new

// user.

java.sql.Connection con =

((com.ibm.db2.jcc.DB2PooledConnection)pooledCon).getDB2Connection(

cookie,newuser,password,userRegistry,userSecTkn,originalUser,properties);

l 用户通过浏览器访问SaaS应用，将通过J2EE应用服务器提供的安全功能，访问相应的模块；当需要访问数据库的时候，应用服务器从连接池取得一个连接，然后切换到用户访问J2EE应用服务器输入的用户；如用户DBUSER1访问J2EE应用服务器的服务，当访问应用服务器的连接池模块的时候，将利用连接池中用USER用户取得的物理数据库连接，然后调用相应的方法把连接的标识名从USER用户切换到DBUSER1用户。

l 用户（如对应的数据库用户名为DBUSER1）访问DB2 V9.5中的数据的时候，DB2 V9.5将运用LBAC功能，使此用户运行的SQL语句只会返回符合它所具有权限的数据。

上面所述的步骤解决了相应的权限控制问题，但是如何避免SaaS应用的软件运营商的数据库管理员能够查看相应客户数据的问题以及DB2 V9.5这些机制的原理到底是如何的呢？请继续阅读下面的内容。

可信上下文之建立显式可信连接并切换用户标识

可以在DB2 V9.5数据库服务器上创建一个可信上下文对象，该对象允许中间层服务器建立与数据库的显式可信连接。在建立显式可信连接后，中间层服务器可以将该连接的当前用户标识切换至新的用户标识，而不需要在数据库服务器中认证新的用户标识。

在建立与DB2 V9.5的连接时，通过在应用程序内发出显式请求可以建立显式可信连接。为了成功建立连接，安全管理员必须使用CREATE TRUSTED CONTEXT SQL语句以及与要建立的连接的属性匹配的那些属性来定义可信上下文。

l 安全管理员通过使用CREATE TRUSTED CONTEXT语句在服务器中定义可信上下文。例如清单3中所示代码：

清单3.CREATE TRUSTED CONTEXT语句示例

CREATE TRUSTED CONTEXT MYTCX

BASED UPON CONNECTION USING SYSTEM AUTHID NEWTON

ATTRIBUTES(ADDRESS '192.0.2.1')

WITH USE FOR PUBLIC WITHOUT AUTHENTICATION ENABLE;

l 要建立可信连接，请使用下面的API：getDB2TrustedPooledConnection（）和getDB2TrustedXAConnection（）；

l 切换至另一个经过认证或未经过认证的用户，请使用下面的API:getDB2Connection（）和reuseDB2Connection（）。

LBAC简介

LBAC是一种基于标号的访问控制的安全特性，从而可以实现基于行、基于列、基于表的访问控制；基于行和基于列的访问控制可以单独使用也可以混合使用。LBAC是一种极具伸缩性的数据访问控制解决方案。

LBAC基于一个新的安全管理员角色，在DB2 V9.5中增加了SECADM这个权限，它包含了相应的安全相关的特权，SECADM权限仅仅能够被具有SYSADM权限的用户即系统管理员赋予。SECADM权限是具有相应的能力实现LABC解决方案的能力，具有以下的能力：

清单4.Create and drop security label components

Create and drop security policies

Create and drop security labels

清单5.Grant and revoke security labels

Grant and revoke LBAC rule exemptions

一个具有SYSADM权限的用户（即系统管理员）缺省不具有SECADM权限，也就意味着具有SYSADM权限的用户如果没有被赋于相应地安全标号权限或者SECADM，系统管理员是不能够查看相应的敏感数据的和进行相应的访问控制权限的赋值，DB2 V9.5这个特性就实现了在SaaS应用中即使是SaaS应用的软件运营商的系统管理员也不能够查看用户数据的功能。

10.8 搭建安全的SaaS平台

搭建安全的SaaS平台体现在技术体系安全保障上。

首先，数据中心是基础。网络安全是第一屏障，硬件级安全是支撑。SaaS平台运营有责任提供此类安全保障，保证IDC的物理安全，启动千兆级硬件防火墙，使用Anti-DDOS（抗拒绝服务攻击）设备，有条件的要雇用IDS（入侵检测系统）。服务器和存储设备安全要通过设备冗余和负载均衡来解决。

其次，保障操作系统和核心架构的安全。SaaS解决方案商要选择主流的操作系统，安装最新补丁或更新，保证定期使用漏洞扫描工具进行安全评估，启用防病毒网关等。对与系统运行时相关的关键数据要进行多重备份。

第三，保障软件的应用架构和商务服务的安全。由于各个软件服务商技术水平参差不齐，安全意识也不均衡，此项是整个SaaS技术体系中最难以通过标准化控制风险的，也是未来最容易被入侵者或攻击者利用的环节。因为SaaS应用多数是通过互联网浏览器来实现，这层薄薄的C2级安全性的浏览器就成了外部与内部最重要的屏障。

不仅如此，SaaS软件的应用级安全要防范来自内部的威胁。企业A是否能够通过托管平台和技术手段获取企业B的信息？企业A的用户b是否能够获取用户c的信息？这就是对SaaS平台的ISV的选择提出了要求。为了保证客户的信息安全，我们应该从ISV的源头上把好关，我们也呼吁针对ISV的软件安全评级标准能尽快出台。

基础平台提供商的较量

当大家还在争论SaaS模式是否需要建立统一协议标准时，微软首先跳开了这个雷区。而是转向推广自己的软件加服务战略（Software Plus Service）。这一战略包括微软的Online Service、Live Services和“云计算”计划，是以DotNet技术架构为基础的。让我们看看软件加服务战略的架构，便会发现这就是一个典型的SaaS平台系统架构。

其中，开发代码为Red Dog的Windows Clouds Services将承担在线服务的“操作系统”角色，他负责管理托管环境中的主要计算和存储资源。开发代号为Zurich的STB Services，将集成开发、数据库服务、身份认证等功能，是Online Services的应用层。

图10-23 软件加服务战略的架构

在图10-21展示的架构图中，与安全标准有关的最核心的是两部分内容：Red Dog中的系统安全和Zurich中的身份认证管理。身份认证管理系统与微软Live ID Passport同簇，不但可以实现统一认证，也可以支持微软以外的第三方的软件托管。因为微软产品线长，从操作系统到企业家应用，自身的安全标准可以贯穿始终。像SharePoint、Dynamic CRM、Exchange都可以在此平台上实现统一的安全标准。

IBM在SaaS方面的研究有两年多的时间，其目标是运营平台服务提供商。IBM投资建立了IBM天津数据中心，引进高科技电子商务技术平台CSDP（Common Service Deliver Platform），以Java技术架构为基础，运用IBM面积SOA的核心技术研发出针对中小型企业信息化建设的解决方案。此平台分为几个部分：Pangoo Platform、Service adapter、Unified Service Portal、Data Adapter、Operation Support Services。

IBM同样是希望实现构建多层体系，实现从操作系统到数据库、中间件，再到商务应用的架构，与微软不同的是，IBM更倾向于做平台服务商和平台运营商的综合体，这就是为什么要建立独立IDC的原因了。而且，IBM也涉足了ISV的角色，如现在推出的“IBM中小企业管理服务包”易管通（eManager）。这使得IBM在SaaS模式的链条中的角色有些混乱，似乎有一家包揽的意味。当然，从安全标准角度，这使得IBM的安全策略与标准得以更全面的贯彻。

目前，IBM在SaaS平台推出的与安全相关的服务是ID Federation和SSO（Single Sign on）。

下面的图10-24是天宇公司（Ttyu）的SaaS平台的安全架构。

图10-24 软件加服务战略的架构

天宇公司的Ttyu平台设计思想是以统一的技术路线、一体化的平台架构为中心；实现构件化的软件装配方式；拥有成熟丰富的基础组件；通过单点登录、统一认证，基于角色、层级的特色权限管理解决平台安全性要求，体现平台无依赖性；支持多种主流数据库；保证系统具有充分的扩展能力。具体来说有以下几方面的特点：

l 更高的效率

Ttyu平台对业务做了更深的抽象，使得开发者只需要编写很少的代码量就能够快速地搭建自己的系统。

l 更高的质量

Ttyu平台使得开发者能够降低软件开发、维护及项目实施成本。

l 可控的开发周期

基于Ttyu平台开发，降低了对开发者技术要求，回避了许多应用开发的技术风险，使开发者有更多的精力去关心自己的业务需求

l 更高的软件研发管理水平

Ttyu平台对应用的开发过程进行了更深的抽象和梳理，使得开发者能够方便地管理、配置各个环节的人力、时间等要素，从而实现软件开发的工业化生产。

l 更高的产品竟争力

领先一步，赢得客户。采用Ttyu平台基于框架的开发方法，使得开发者能够领先竟争对手刚刚合适的“半步”。

10.9 小结

这样看起来，无论是传统的局域网信息化系统，还是SaaS模式的信息化系统，都会让客户关注数据安全。但如果我们有标准来衡量信息化系统的安全性，或者我们提前知晓这些风险的存在，对于用户来说是有利的。

尽管SaaS模式在信息安全与可信平台架构上有一些需要解决的问题，但只要我们能够找到问题产生的核心原因并深入剖析，是能够发现行之有效对策的。建立SaaS平台安全机制，形成安全标准，健全安全管理措施，保障SaaS安全服务。如此，我们坚信，SaaS模式能够摆脱目前的困境，打消人们的忧虑，让软件服务真正深入到各个场地和用户中。

,