讨论saas的数据安全性

讨论saas的数据安全性篇1

关于Saas相对本地部署应用的类似于低成本、快实施、零运维等等各种好处在各种介绍中已经非常多了，相信大家也容易理解并且认可，我就不再补充。今天我想重点说说客户最担心的数据安全问题，本地部署在数据安全性上就一定会比Saas好吗？

讨论这个问题之前必须先对客户所担心的数据安全问题进行一下明确与界定，根据与客户沟通的经验，在Saas模式下客户说到的安全问题无非是这三个方面：其一，Saas平台的数据丢失，不可还原；其二，Saas平台的数据被第三方以技术手段非法获取；其三，Saas平台的数据被平台方出于商业目的恶意透露。那么我们针对这三个问题一个个来分析一下，是不是本地部署这三个问题就完全解决了呢？

对于 “数据丢失不可还原”理论上对于任何一个系统都是存在的，没办法完全杜绝，能做的就是降低丢失的概率。具体措施就是数据备份，相对成熟的互联网公司对数据备份都相当重视；有专门的DBA团队设计非常周密的备份方案，备份的技术手段也是自动与高效的，并且会进行定期的还原演练。比喻在dayHR，我们的DBA团队就给客户的数据设计了三套并存的备份方案，分别会进行机房本地、研发网、第三方机房（加密）的备份；备份周期是每日增量与每周全量，并且每两周会进行一次备份还原演练。通过这些措施基本上杜绝了“数据丢失不可还原”的可能性。

那企业本地部署系统“数据丢失不可还原”问题就不会存在呢？非常遗憾，根据我本人十多年为企业提供IT服务的经验来看，在企业本地部署的系统“数据丢失不可还原”的机率大于成熟互联网公司100倍都不止。我曾遇到过删除整个数据库无法还原的，也曾遇到过将整个服务器格式化，丢失所有数据的，林林总总非常之多。受限于意识、技术手段、备份设备、人才等等各方面的影响，除开极少数在企业IT做得非常优秀的公司外，绝大多数公司在数据备份方面做得都非常不专业。最严重的是不备份，出了问题彻底歇菜；一般的会在数据库机器上做个备份，硬盘坏了依然没啥作用；即使备份不出问题，但是从不演练，等到关键节点要做恢复时发现恢复不了。所以对于“数据丢失不可还原”这个担心来说，成熟Saas平台的可靠性远远高于企业本地部署。

那对于“数据被第三方以技术手段非法获取”是不是本地部署机率会更小呢？如果企业彻底断开外网，所有应用不能从外网访问包括移动应用，那这个答案是肯定的！如果在互联网时代特别是移动互联网大行其道的时代，一个企业能做到与外网的完全隔离，我确实无话可说，第三方也确实没有办法通过技术手段非常获取你的数据。

但是我相信绝大多数企业肯定还是要与外网相通的，你的内部应用为了方便员工，也是需要向外网开发放。一但开放，同Saas平台一样“数据被第三方以技术手段非法获取”的可能性就存在，那么我们只需要对比一下，这种机率谁大谁小就可以了。互联网公司将安全普遍当成头等大事，在人才、设备、工具上投入都非常之多；一般来说都会有专门的安全团队负责平台的安全，会部署一系列安全相关的软硬件工具以提高平台的安全性。对于安全来说更核心的是日常的基本功，比喻说团队的安全意识培养、程序开发过程中的安全考虑、对于主机的所有日志的安全审计、安全事件应对演练等等，只有这些东西做到位，才可能保证到平台安全，降低“数据被第三方以技术手段非法获取”的可能性。对于我们dayHR的安全团队来说，在部署了基本的网络防火墙与应用防火墙、一些安全监控工具外，其日常最重要的工作就是审计与传教：审计就是对主机各种日志的审计，发现隐藏在日志中的各种异常与风险，并针对性的采取措施；传教就是对整个研发团队传导安全理念，培训安全知识，从而提高整个研发团队的安全水平。

据我了解，一般的企业（排除一些真的重视安全以及土豪公司哈）IT部都没有专业的安全团队；更重要的是，认为应用就部署在内网，安全问题不严重，在意识上就不注意安全问题。安全其实上是一个很奢侈的事儿，舍不得投入根本做不好安全；安全人才特别稀缺、要价很高，安全解决方案与工具都很贵；再加上如果没有吃过安全的亏，完全没有安全意识。所有这一切都造成了在一般的企业中要想做安全都是非常困难的事儿，从各大漏洞平台的统计来看，企业应用与政府应用是低级高危漏洞的高发区。而互联网公司由于行业特点与自由的核心利益所然，必须做好安全，相对来说系统更加安全。所以成熟的Saas平台比一般企业维护的内部系统更加安全，“数据被第三方以技术手段非法获取”机率更小。

对于第三点“Saas平台的数据被平台方出于商业目的恶意透露”，换成直白点的话，就是将客户的数据去卖钱。这个问题其实上不是技术上的问题了，是一个商业模式上的问题；如果一个Saas平台的盈利模式是靠出卖客户的数据去赚钱，我相信他很难成长起来。首先投资商不会给他投钱，其次客户也不会选择他的服务。打造一个成熟的Saas平台需要大量的金钱投入，比喻说dayHR走到今天这个规模，已经投入了上亿的资金。只要我们这个平台上出了一例我们自己因商业利益透漏了客户的资料，整个平台的信誉就完了，相信也没有客户会选择我们的服务了，也就意味着上亿的投入打了水漂，你觉得我们能做这样的事吗？

对于Saas平台来说，确实会利用一部分用户数据；但这种利用一定是基于大数据这个角度，任何时候平台都不会对于特定客户数据进行透漏。就像我们远观一片森林，可看清葱绿、广大、起伏，但是看不清每棵树是什么树、长什么样、有多少枝丫与叶片。

关于Saas平台的数据安全我经常会给同事们说一个例子，在此也以这个例子结尾吧！十年之前网上支付刚起步时，有多少人质疑其安全性不敢使用；而如今，网上支付是绝大多数网民最普通的日常动作了。不是网上支付的安全性问题已经彻底解决，而是趋势不可阻挡。企业Saas也一样，数据安全性问题也只是其发展过程中的一个小小的波折，大势不可阻挡！

讨论saas的数据安全性篇2

随着互联网的飞速发展, 软件市场需求的日益增长, 软件生产力的大幅提升, 以及用户对软件核心价值观的转变, 必然导致软件的服务化趋势, 从而催生Saa S商业模式。Saa S是一个以软件租用为主体的新型模式, 其目标是减少IT成本和所需的工作。成熟的Saa S软件开发商多采用一对多的软件交付模式, 也就是一套软件多个用户使用。这种新模式的产生使软软件服务朝着更加标准化的方向发展, 对软件问题及扩展需求做出更快的响应;同时使得每个企业在软件采购、构建、维护、程序管理的负担大大减轻了。所以很受中小企业的欢迎。

但是在Saa S系统使用和推广中, 系统的安全性特别是数据的安全受到用户的普遍关注。

1 Saa S应用的数据安全问题

在传统应用中, 应用服务器和数据库设备、网络都是部署在客户自己企业, 系统维护都是由客户自己掌握, 每个客户的数据自然是完全独立互不扰的, 这样客户觉得很安全、很踏实。传统应用程序部署模式如图1所示。

而在Saa S应用中, 应用服务器、数据库设备不再由客户自己管理, 而是部署在软件服务运营上处, 系统维护也不再由客户负责。另外, Saa S应用是完全基于互联网使用的, 用户所有的交互和数据都需要通过互联网。Saa S软件服务提供方式如图2。客户开始觉得不放心了。数据存到哪里了?会不会丢失?各个用户之间的使用会不会冲突?数据会不会被其他用户看到?数据传输安全与否?会不会受到黑客的攻击等。以上这些都成了客户使用Saa S应用的顾虑。这就要求Saa S应用在设计时, 需要更加系统的考虑安全问题, 并采用更可靠的安全技术和手段来保证系统的高可用性, 保证数据的完整性和保密性。

2 Saa S系统的数据安全解决方案

对于Saa S应用来说, 数据安全确实是一个备受关注的问题。只有构建安全可靠的Saa S应用, 让客户可以安全、稳定地使用系统, 是赢得市场的关键和基础。

2.1 权限控制体系

权限管理就是要实现用户使用系统功能访问控制, 保证有效用户正常使用系统的同时, 防止非法用户和无权限用户对系统功能的使用。与传统应用的权限管理不同的是, Saa S应用的权限管理需要对用户的权限进行控制, 并基于用户的授权模式。

在Saa S应用中, 我们同样可以采用RBAC (Role-Base Policies Access Control) 权限模型体系, 不过在Saa S应用中用户是按用户隔离的, 而角色既会是全局的, 也会是用户角色的, 而用户的角色是需要进行隔离的。

全局角色由系统管理员分配, 可以对系统内的所有许可进行分配。用户角色由用户管理员分配, 只能对用户所购买的功能进行授权。

2.2 身份认证体系

身份认证就是实现对用户身份的识别和验证, 这是保证整个系统应用安全的基础。通过严格的身份认证, 防止非法用户使用系统, 或伪装成其他用户来使用系统。

目前比较常用的身份认证有集中认证、非集中认证、混合认证等三种。

集中认证就是由Saa S应用系统提供一个统一的用户认证中心。所有用户都到这个中心来管理和维护各用户的身份数据, Saa S应用直接到统一的认证中心对用户身份进行校验。集中式认证在用户身份的安全性上更容易得到保障。同时大多数中小型用户没有自己专门的身份认证中心, 所以对于大多数中小型Saa S应用采用集中认证是比较合适的。

2.3 日志管理策略

如果用户在系统中做了一些错误的操作, 导致用户的重要数据丢失或者出错了, 用户可能会怀疑这些错误是由于Saa S系统的原因造成的, 或者其他用户的操作造成的。

日志就是要对用户在系统中的操作行为和操作的数据等进行记录, 以便对应用在系统的操作进行查证, 以保证用户行为是不可伪造的、不可销毁的、不可否认的。也就是说, 用户在系统的行为是有据可查的, 不能在系统中伪造自己的行为, 或者伪造其他用户的行为, 同时是不能销毁这些证据的, 不能否认自己的行为。

对于Saa S应用可以从操作日志和数据日志两方面来保证。

(1) 操作日志:是辨别用户在系统中的行为的一个重要依据, 对于系统使用和系统运用分开的Saa S系统就显的尤为重要。记录用户在系统中所访问的每一个页面, 在各页面中所做的每一个行为都记录下来, 记录用户的身份和行为的时刻。行为日志记录的实现采用面向页面的方案来实现, 例如通过过滤器或拦截器的方式, 对所有的页面请求行为及页面的提交行为进行拦截, 然后将其记录在日志文件中。

(2) 数据日志:对用户在系统中所做操作的数据进行记录, 记录数据的变更过程及变更的历史。这在多人操作同一个数据的系统中显的尤为重要。

日志记录是对用户在系统中的行为进行查证的依据, 是用来跟踪和保障系统安全的。日志本身的安全也很关键, 所以对日志记录的处理首先应该是只读的, 加上时间戳, 不应该被认为修改或伪造;其次, 日志记录必须进行加密处理;第三, 只对用户管理员开放, 用户只能查询自己的日志记录。

2.4 用户数据隔离方案

传统的应用因为每个用户的设备是独立的, 相互之间数据是绝对隔离的, 而且应用也是相对对立的。而对于Saa S应用来说, 应用部分不再是独立的, 而数据设备可能不再是独立的了, 至少对于用户来说是不可预知的。所以必须采用数据隔离的方法来保证用户数据仍然像传统应用一样安全。

数据隔离就是要对用户之间的数据进行隔离, 已确保各用户数据的完整性和保密性。

数据隔离方案的实现一般有以下三种:

(1) 独立数据库:一个用户一个数据库, 这种方案的用户数据隔离级别最高, 安全性最好, 但是成本也高。

(2) 共享数据库, 数据模式 (Schema) 隔离:多个或所有用户共享数据库, 但一个用户单独一个模式。这种方案为用户提供了一定程度的逻辑数据隔离, 但并不是完全隔离;同时每个数据库可以支持更多的用户, 成本较低。其缺点是管理比较复杂。

(3) 共享数据库, 数据模式共享:用户共享同一个数据库, 同一个模式, 但为每个需要隔离的业务表加上用户ID来实现用户用户数据的隔离。这是共享程度最高、隔离级别最低的模式, 但是系统的实施成本最低。这种方案会增加设计开发时对安全的开发量。数据的备份和恢复最困难也是其另外一个主要缺点。

2.5 敏感数据加密

在传统应用中, 对用户身份密码要进行加密, 但是很少对用户的业务数据进行加密, 因为数据库都是自己管理。但是在Saa S应用中数据库是由运营商来管理的, 对于用户来说, 运营商及数据库管理员是不完全值得信任的。所以必须对一些敏感数据, 比如用户密码、财务数据、关键客户数据等进行加密, 以保证数据的安全性。

用户身份密码采用不可逆的加密算法, 如MD5。对于用户其他敏感的业务数据, 应该采用可逆的对称加密算法或非对称加密算法。

数据加密的密码对用户来说是透明的, 所以可以在创建用户的过程中由系统自动生成, 用户的数据密码key产生后, 用管理员的密码明文进行加密后和身份数据一起存储。即每个用户都需要用其身份密码明文对数据密码进行aes加密, 为了防止数据密码泄露, 再将加密后的数据密码密文和用户身份数据一起存储。

2.6 安全的数据传输

Saa S应用是完全基于互联网使用的, 如果改用明文传输的话, 将会很容易受到各种各样的网络攻击。这将导致数据段的保密性和完整性难以得到保障, 应用的安全性也很难实现。因此, 对于Saa S应用中敏感数据的传输建议采用安全超文本传输协议HTTPS进行传输, 普通的Web页面直接采用H T T P协议传输。

2.7 网络攻击防范

由于用户是通过互联网来使用Saa S应用, 所以Saa S应用必定有一部分内容是部署到公网上的。为了保证整个系统的安全, 暴露在公网的这部分内容越少越好。因此Saa S应用要对整个系统进行分层设计和部署, 只把系统界面层 (Web) 部署在公网上, 而将更重要的应用服务器和数据库服务器部署在防火墙内。

3 结束语

本文分析了基于Saa S模式的应用与传统应用在系统数据安全方面的不同点, 对基于Saa S模式下的系统数据安全处理提出一些具体的解决方案。目前基于Saa S模式的应用仍然处于市场的培育和发展期, 作为一种新的软件设计模式, 其安全性应该得到充分和有力的保障, 只有构建安全可靠的Saa S应用, 让客户可以安全、稳定地使用系统, 才能让Saa S更好的赢得市场, 带来更好的发展。

摘要：在基于SaaS (Software as a Service) 模式的系统应用的使用和推广中, 如何保证用户数据的完整性、安全性、保密性是用户普遍关心的问题, 也是SaaS应用系统设计中必须重点考虑的一个方面。本文主要从SaaS应用系统数据安全性必须重点考虑身份认证、权限控制、日志管理、数据隔离、敏感数据加密、数据安全传输、网络攻击等方面, 阐述了构建基于SaaS模式应用的数据安全解决方案。

关键词：SaaS,数据安全,软件,计算机网络

参考文献

[1]写亿民.互联网和软件融合成就SaaS.软件世界.2006.

[2]赵安军.网络安全技术与应用[M].人民邮电出版社.2007.

讨论saas的数据安全性篇3

虽然SaaS能够提供灵活和具有成本效益的应用使用环境来取代传统模式，但它并非没有风险。因为转移到托管平台，而不是留在自己内部，企业必然会牺牲许多对于营运环境的控制。特别是在SaaS里，你几乎只能选择要上传或不上传某些数据，而剩下的就不是你能掌控了。但是你还是得为自己的数据保护负起法律和监管责任。

SaaS环境下的风险有许多种，而且大多数都和它所提供的好处相关。正如前面提到的，你的供应商透过某些网络分析来了解你对服务平台的使用状况，他们也能够存取你所有的数据，这会产生未经授权存取或被内部员工监控的风险。

五个关键的安全问题要问你的SaaS供应商：

1.渗透测试：如何以及多常进行整个环境的渗透测试，是否有能力自己独立对部分环境进行渗透测试？如果没有常常进行深入的渗透测试，你就不能得知当前安全状况的全貌。

2.数据安全：在使用资源共享的SaaS供应商数据中心时，如何对储存和传输中的数据进行加密？谁可以拿到加密金钥？是否有做权责区分(separation of duties)，并将加密金钥和数据维护分开负责？供应商是否能提供你SAS 70报告？

3.多租户：是否有提供单一租户托管的选项？还要确认单一租户是否只包括应用程序，还是也包括数据储存的部份？

4.灾难复原：当发生灾难性故障、受到外部入侵或数据遗失时，有准备备份和回复的程序吗？备份的数据储存在哪里(再次提醒，需要加密)以及如何有效地回复？

5.用户验证：SaaS应用程序的登入程序为何？是否使用多因子认证？是否可以和客户正在使用中的认证机制做整合？

讨论saas的数据安全性篇4

数据的内存中表示形式

在 ADO 中，数据的内存中表示形式为记录集。在 ADO.NET 中，它为数据集。它们之间有重要的差异。

表的个数

记录集看起来像单个表。如果记录集将包含来自多个数据库表的数据，则它必须使用 JOIN 查询，将来自各个数据库表的数据组合到单个结果表中。

相反，数据集是一个或多个表的集合。数据集内的表称为数据表；明确地说，它们是 DataTable 对象。如果数据集包含来自多个数据库表的数据，它通常将包含多个 DataTable 对象。即，每个 DataTable 对象通常对应于单个数据库表或视图。这样，数据集可以模仿基础数据库的结构。

数据集通常还包含关系。数据集内的关系类似于数据库中的外键关系，即它使多个表中的行彼此关联。例如，如果数据集包含一个有关投资者的表和另一个有关每个投资者的股票购买情况的表，则数据集可能还包含一个关系来连接投资者表的各个行和购买表的对应行。

由于数据集可以保存多个独立的表并维护有关表之间关系的信息，因此它可以保存比记录集丰富得多的数据结构，包括自关联的表和具有多对多关系的表。

数据导航和游标

在 ADO 中，您使用 ADO MoveNext 方法顺序扫描记录集的行。在 ADO.NET 中，行表示为集合，因此您可以像依次通过任何集合那样依次通过表，或通过序号索引或主键索引访问特定行。DataRelation 对象维护有关主记录和详细资料记录的信息，并提供方法使您可以获取与正在操作的记录相关的记录。例如，从 Investor 表的“Nate Sun”的行开始，可以定位到 Purchase 表中描述其购买情况的那组行。

“游标”是数据库元素，它控制记录导航、更新数据的能力和其他用户对数据库所做更改的可见性。ADO.NET 不具有固有的游标对象，而是包含提供传统游标功能的数据类。例如，在 ADO.NET DataReader 对象中提供只进、只读游标的功能。有关游标功能的更多信息，请参见数据访问技术。

将打开连接的时间降至最低

在 ADO.NET 中，打开连接的时间仅足够执行数据库操作，例如“选择”(Select) 或“更新”(Update)，

您可以将行读入数据集中，然后在不保持与数据源的连接的情况下使用它们。在 ADO 中，记录集可以提供不连接的访问，但 ADO 主要是为连接的访问设计的。

ADO 和 ADO.NET 中的不连接处理之间存在一个显著差异。在 ADO 中，通过调用 OLE DB 提供程序来与数据库通信。但在 ADO.NET 中，您通过数据适配器（OleDbDataAdapter、SqlDataAdapter、OdbcDataAdapter 或OracleDataAdapter 对象）与数据库通信，这将调用 OLE DB 提供程序或基础数据源提供的 API。ADO 和 ADO.NET 之间的主要区别在于：在 ADO.NET 中，数据适配器允许您控制将对数据集所做的更改传输到数据库的方式，方法是实现性能优化、执行数据验证检查或添加其他任何额外处理。

注意数据适配器、数据连接、数据命令和数据读取器是组成 .NET Framework 数据提供程序的组件。Microsoft 和第三方供应商可能会提供其它提供程序，这些提供程序也可集成到 Visual Studio 中。有关不同 .NET 数据提供程序的信息，请参见 .NET 数据提供程序。

在应用程序间共享数据

在应用程序间传输 ADO.NET 数据集比传输 ADO 不连接的记录集要容易得多。若要将 ADO 不连接的记录集从一个组件传输到另一个组件，请使用 COM 封送。若要在 ADO.NET 中传输数据，请使用数据集，它可以传输 XML 流。

相对于 COM 封送，XML 文件的传输提供以下便利之处：

更丰富的数据类型

COM 封送提供一组有限的数据类型（由 COM 标准定义的那些类型）。由于 ADO.NET 中的数据集传输基于 XML 格式，所以对数据类型没有限制。因此，共享数据集的组件可以使用这些组件一般会使用的任何丰富的数据类型集。

性能

传输大型 ADO 记录集或大型 ADO.NET 数据集会使用网络资源；随着数据量的增长，施加于网络的压力也在增加。ADO 和 ADO.NET 都使您可以最大限度地降低所传输的数据。但 ADO.NET 还提供另一个性能优势：ADO.NET 不需要数据类型转换。而需要 COM 封送来在组件间传输记录集的 ADO，则需要将 ADO 数据类型转换为 COM 数据类型。

穿透防火墙

防火墙可以影响试图传输不连接的 ADO 记录集的两个组件。请记住，防火墙通常配置为允许 HTML 文本通过，但防止系统级请求（如 COM 封送）通过。

因为组件使用 XML 交换 ADO.NET 数据库，所以防火墙可以允许数据集通过。

光伏电站安全性讨论篇5

从太阳能光伏发电等新能源的使用角度看，有许多特有的优点:

1、分布式光伏发电可实现就近供电，不必长距离输送，避免了长距离输电线路的损失;

2、太阳能不用燃料，运行成本很低;

3、太阳能发电没有运动部件，不易用损坏，维护简单，特别适合于无人值守情况下使用;

4、太阳能发电不会产生任何废弃物，没有污染、噪声等公害，对环境无不良影响，是理想的清洁能源;

5、太阳能发电系统建设周期短，方便灵活，而且可以根据负荷的增减，任意添加或减少太阳能方阵容量，避免浪费。这些优点使得分布式光伏发电不存在较高的操作难度和危险性，安全性得到了保障，为广泛推广提供了现实的可行性。

但从运行维护的角度来说，光伏发电也并非完全安全无隐患的。与独立占地的大型地面电站不同，分布式光伏发电需要依附居民住宅、工业厂房、仓库、商业大楼、学校市政建筑等，而这些建筑物载体一般都有人口密集、配装有相关精密仪器设备或存放有易燃物质的特点，所以分布式光伏发电对于安全性能的要求就更加严格，必须要保证光伏发电不影响这些建筑物原有的生产生活功能，对人员、生产、物资不产生安全隐患。

为了避免安全事故的发生，在开展电站方案设计及设备选型之时，会严格做好一系列准备工作。

第一：分析安装分布式光伏发电系统的载体建筑，做好合理安全的空间规划，必须安排专门的空间区域放置光伏组件和配电逆变等发电设备，尽量避免非专业人员接触发电设备，以免引发安全事故。

第二：对选用设备的品质和产品认证齐备情况进行充分的了解，确认逆变器所获得的认证证书和认证质量，不仅需要将EMC(电磁兼容)问题作为重要考虑内容，必要时要采用相关的辅助措施，以防出现发电设备对原有电子设备的电磁干扰，同时还需要在逆变器输出汇总点设置易于操作、可闭锁、且具有明显断开点的并网总断路器，以确保电力设施检修维护人员的人身安全，杜绝可能出现的孤岛效应。

第三：在完成以上要求的基础上，对防火、接地、应对强风方面加大防护力度。

第四：另一方面，在分布式光伏发电系统的正常运行过程中，我们应当坚持对发电系统进行安全性定期检查，同时不断提高分布式光伏发电系统的智能化运维能力，将所有可能出现的安全故障第一时间得到反馈，在保证发电效率的同时提高整个系统的安全性。具体来说，除了基本的消防安检措施外，还特别要求光伏系统具备自我检测、识别异常并主动停止异常发电组串工作的功能，降低火灾发生可能性。发电系统的任何一个环节，光伏电池、组串汇流、逆变设备等，都可以作为这一智能自检自控功能的加装应用载体。

SaaS环境下的安全问题篇6

云计算(Cloud Computing)是以网络技术、虚拟化技术、分布式计算技术为基础,以按需分配为业务模式,具备动态扩展、资源共享特点的新一代网络化计算模式。云计算中提及的“云”是网络、互联网的一种比喻说法。随着云计算的快速发展,云安全问题日渐突出并得到了广泛的关注。

云计算的服务模式包括基础设施即服务(Infrastructureas-a-Service,Iaa S)、平台即服务(Platform-as-a-Service,PaaS)和软件即服务(Software-as-a-Service,SaaS)。SaaS是发展最快、应用最广泛的服务模式,它的特点为通过互联网存取应用服务,用户只需要向软件提供商租用这些应用,应用的升级和维护工作也由软件提供商全权负责。本文描述了SaaS环境下的安全问题,为SaaS应用的开发和使用提供了一定的安全参考。

1 Saa S的发展

SaaS的概念起源于1999年之前。“软件即服务”的常见用法和简称始于刊登在2001年2月的SIIA(Software&Information Industry Association:美国软件与信息产业协会)的白皮书“战略背景:软件即服务”。

1998年,第一个SaaS应用程序由亚特兰大的WebTransit公司开发。最早的SaaS应用是Salesforce.com将其提出的SaaS运用于CRM(Customer Relationship Management:客户关系管理)行业。它是一种通过Internet提供软件的模式,厂商将应用软件统一部署在自己的服务器上,客户可以根据自己实际需求,通过互联网向厂商定购所需的应用软件服务,按定购的服务多少和时间长短向厂商支付费用,并通过互联网获得厂商提供的服务。

在中国,八百客于2006年2月推出了全球首个中文SaaS在线企业管理软件平台800APP(CRM),随后推出了全球首个中文应用软件协同开发平台800APP COMPOSITE,于2008年底再次融资成功,成为中国第一家获得海外投资的SaaS企业,是中国SaaS市场的技术领先者及最大的SaaS模式企业管理应用系统提供商和专业服务商,致力为于客户创造长期的价值和潜在的增长,助力中国企业快速有效实现管理自动化。

目前国内的主流SaaS服务提供厂商有八百客、天天进账网、中企开源、CSIP、阿里软件、友商网、伟库网、金算盘、CDP、百会创造者、奥斯在线等。

2 Saa S应用服务体系架构

SaaS是软件级别的云计算服务,也是最成熟、最出名、应用最广泛的一种云计算服务,在这种服务模式下,用户通过互联网来使用安装在服务提供商那的软件。

在详细的描述SaaS环境下的云安全问题之前,本部分先给出SaaS应用服务体系架构。基于Philippe Kruchten提出“4+1”视图,该体系架构给出了应用开发、物理部署和用户使用这三个角度的视图,如图1所示。

用户使用视图:从用户的角度给出应用的使用过程。

物理部署视图:描述了软件如何映射到硬件。

应用开发视图:从程序开发的角度出发,给出业务逻辑。

3 Saa S环境下的云安全问题

下面基于SaaS应用服务体系架构(图1所示),描述SaaS环境下的云安全问题。

3.1 用户使用层

在用户通过浏览器登录SaaS云应用系统以及使用该系统的过程中,数据会在客户端和服务端之间不断的传输,传输过程中存在大量的数据的安全性问题。下面从浏览器、身份认证、数据加密三方面说明用户使用层的安全问题。

浏览器:浏览器普遍成为云服务应用的客户端,而所有的因特网浏览器毫无例外地存在软件漏洞,这些软件漏洞加大了终端用户被攻击的风险,从而影响了云应用的安全。换言之,数据传输通道未使用或未完全使用https,是导致云安全问题的一个因素。

身份认证:身份认证分为两种,一种是传统的“账号+密码”身份验证,一种是使用PKI(Public Key Infrastructure:公钥基础设施),PKI是一种遵循既定标准的密钥管理平台,它能够为所有网络应用提供加密和数字签名等密码服务及所必需的密钥和证书管理体系。传统的“账号+密码”身份验证方式中的密码为静态密码,是由用户设定的一串静态数据,而静态密码一旦设定,除非用户自己更改,否则保持不变。因此,会导致静态密码容易被偷看、猜测、字典攻击、暴力破解、窃取、监听、重放攻击、木马攻击等。采用PKI认证可以解决上述安全问题,但对于同一个SaaS平台上的应用,如果是每个应用的登录都要进行PKI认证,那么用户每天要登录很多系统请求服务,登录的次数越多,就越容易泄露密码,从而降低了整体的安全性,增加了密码被非法截获的可能性。

数据加密:传输过程中数据没有加密,则数据被截获后,隐私非常容易外泄。

3.2 物理部署层

物理部署层的主要组件为路由器、入侵检测、防火墙、交换机、物理服务器和虚拟化环境,每个组件都会存在安全性问题。

路由器:路由器的加密等级不够,则会导致网络不安全,从而进一步致使隐私信息不安全。

入侵检测:入侵检测是防火墙之后的第二道安全闸门,若不使用入侵检测系统,则为黑客的攻击提供了方便,也不能实时监控网络传输以及分析内外部网络的入侵信号,不能及时的实施补救措施。

防火墙:防火墙能根据网络系统的安全策略有效地控制出入网络的信息流,且本身具有较强的抗攻击能力,是否启用防火墙,一定程度上决定着内部网络的信息安全。

交换机:同路由器一样,交换机的加密等级也直接影响到网络信息的安全。

物理服务器:首先是物理环境,服务器运行的物理安全环境非常重要,主要是指服务器机房的设施状况,包括通风系统、电源系统、防雷防火系统以及机房的温度、湿度条件等,这些因素会影响到服务器的寿命和所有数据的安全。其次是服务器是否加密,存放数据的磁盘是否加密,这些将直接影响服务器存储的数据以及其上应用的安全性。再次,服务器是否加固直接影响服务器的安全性。服务器前端是否部署了负载均衡设备,以实现多台服务器之间的负载均衡和高可用性。

虚拟化环境:虚拟化技术(Virtualization Techniques)是在软、硬件之间引入虚拟层,为应用提供独立的运行环境,屏蔽硬件平台的动态性、分布性、差异性等,支持硬件资源的共享与复用,并为每个用户提供相互独立、隔离的计算机环境,同时方便整个系统的软硬件资源的高效、动态管理与维护。虚拟化技术是云计算的三大核心技术之一,其应用的安全性问题是因为云安全研究的重点。虚拟化环境如图2所示。

在虚拟化环境中,虚拟化安全问题体现在虚拟机层、虚拟化平台层和虚拟化环境三方面:

(1)虚拟机层

虚拟机层安全问题分为数据存储和虚拟机两方面,而虚拟机的安全问题体现在虚拟镜像文件和操作系统内核上。

数据存储:“一种数据是不能丢,但是可以泄露,可以放在云端;另一种是绝对不能泄露,不能放在云端”,数据存储安全问题指的就是数据泄露问题,有以下六点:

(1)上面提及的路由器、入侵检测、防火墙、交换机和物理服务器是否做好安全措施,是能否保证数据存储安全的一部分原因。

(2)文件和数据库信息是否加密,也影响存储数据的安全性。文件加密:只对涉及到安全信息的文件进行加密,并且根据文件长度和秘密等级选择合适的加密算法。数据库加密:因为对数据库的所有信息都加密,将会导致索引检索等功能不能实现,所以可只对敏感的数据字段加密。

(3)用户数据隔离存储。首先,一个用户一个数据库,用户数据隔离级别最高,安全性最好,若出现故障,数据比较容易恢复,但成本很高。其次,用户数据只是逻辑上隔离的话,如果出现故障,数据恢复比较困难,因为恢复数据库将牵扯到其他用户的数据。

(4)密钥保护:在对文件等进行对称加密算法后,对该对称算法的密钥(如图3所示)是否使用非对称加密算法加密,例如RSA(公钥加密算法,1977年由Ron Rivest、Adi Shamirh和Len Adleman在美国麻省理工学院开发的)算法是一种非对称加密算法,直接影响数据的存储安全。

(5)服务提供商内部窃取用户数据,非常影响数据的存储安全性,大多时候,数据信息的泄露是由人为故意导致。

(6)数据存放在物理服务器和虚拟机系统中。在服务器灾备管理不完善导致服务中断、服务提供商倒闭使得服务无法继续提供等情况下,若服务没有数据的备份及恢复功能,数据就会随着服务的关闭或中断而丢失。

虚拟机镜像:在虚拟化环境里,一个虚拟机镜像会被大量复制,将会造成大量服务器都存在相同漏洞。

操作系统内核:虚拟主机是病毒、木马的重要攻击对象,因此操作系统内核是否采用加固技术,计算/存储节点、虚拟主机等是否得到保护,也是数据存储安全的一个保证点。

(2)虚拟化平台层

虚拟化平台的核心是虚拟机监控器(VMM:Virtual Machine Monitor),负责监控和管理其上的各个虚拟机(VM:Virtual Machine)。虚拟化平台承载了大量虚拟机,须重点防护和管控。多个虚拟机运行于同一个虚拟化平台,若虚拟化平台未做好网路隔离,恶意攻击者可轻易对其它虚拟机发动攻击。

(3)虚拟化环境

在一个虚拟机系统中,由同一管理员负责管理数据中心、服务器和网络等,失去了“1+1>2”的分管机制特征。

由于云的动态调度性,虚拟机可以从一个虚拟化平台迁移到另一个虚拟化平台。对有着不同安全级别及防护需求的虚拟化环境,传统的安全防护机制不易将安全策略套用到对应的虚拟机,造成安全管理上极大的复杂性。

在虚拟化环境中,管理员很容易添加或启动一个非法的虚拟机。此外,虚拟机镜像是以文件的形式存在,可随意复制与散播,不但内部员工更容易监守自盗,攻击者入侵后更可轻易地复制一个完全相同的运行环境。

3.3 应用开发层

应用开发层分为页面展示、配置管理、接口控制、业务逻辑和数据访问五部分,主要的安全问题如下。

(1)页面展示层是否有辅助性的安全设置,比如密码控件、图片验证码、手机确认码等。

(2)若未对用户输入的合法性进行判断,容易发生注入问题,例如SQL注入,SQL注入是指通过把SQL命令插入到Web表单递交,或者是输入域名或页面请求的查询字符串,最终达到欺骗服务器执行恶意的SQL命令。通过SQL注入可以获取数据库信息,导致隐私泄露。

(3)权限配置是否完整,即功能权限或者数据权限是否清晰正确,将会导致用户数据是否泄露给其它用户,从而引发数据安全问题。

(4)数据库中数据是否隔离以及隔离的级别等影响了数据的安全性,隔离级别越高,越不容易泄露用户信息给其它用户。

4 结论

本文从SaaS应用服务体系架构的用户使用、物理部署和应用开发三个层面出发,分别分析了SaaS应用存在的安全问题,说明SaaS应用需要注意的安全问题非常多。本文只给出了安全问题,下一步工作是通过分析问题,结合实际应用,提出问题的解决方案。