一种SaaS应用下提高数据安全性的方法、装置及系统

摘要

本申请公开了一种SaaS应用中提高数据安全性的方法，该方法为：在创建客户时，针对该客户的客户标识ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码；根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并允许所述至少一个用户根据解密后的数据密码获得解密后的业务数据。这样，便可以有效避免管理人员对数据密码的泄露和恶意使用，从而有效地防止了业务数据的泄露，提升了业务数据的安全性。本申请同时公开了一种在SaaS应用中使用的服务器和SaaS应用系统。

说明书

技术领域

本申请涉及计算机领域，特别涉及一种SaaS应用下的数据加密方法、装置及系统。

背景技术

应用软件即服务(Software as a Service，SaaS)是随着互联网技术的发展和应用软件的成熟，而开始兴起的一种完全创新的软件应用模式。它是一种通过Internet提供软件的模式，运营商将应用软件统一部署在自己的服务器上，客户可以根据自己实际需求，通过互联网向运营商定购所需的应用软件服务，按定购的服务多少和时间长短向运营商支付费用，并通过互联网获得运营商提供的服务。在SaaS应用中，客户不用再购买软件，而改为向运营商租用基于Web的软件，并且无需对软件进行维护，这样，便使得客户不必在硬件维护和软件维护方面耗费大量的人力物力，从而大大节省了企业经营成本。

通常，应用SaaS技术的数据库是由运营商管理的，而对于客户来说，其并不希望自身的业务数据被他人查看，尤其是一些涉及隐私的敏感业务数据，更不希望被他人浏览、使用和统计；例如，公司的财务数据。

有鉴于此，现有技术下通常采用以下两种方式对客户的业务数据进行加密，以防止业务数据的泄露。

第一种加密方式为：数据库加密。

所谓数据库加密，即是采用数据库提供的加密功能，由数据库管理员来设定密码，并且对所有数据采用同一个密码进行加密。

采用数据库加密的缺点在于：其一，密码由数据库管理员设定，因此，具有权限的数据库管理员可以查看客户的业务数据，这在很大程度上降低了业务数据的存储安全性；其二，数据库管理员使用的设定的密码针对整个数据库进行加密，一旦密码泄露，整个数据库中存储的业务数据的安全性便难以得到保障。

第二种加密方式为：客户端硬件加密。

所谓客户端硬件加密，即是向客户提供一个硬件加密器(例如，U盘加密)，从而在客户端实现业务数据的加密。

采用客户端硬件加密的缺点在于：其一，各客户端分别对业务数据进行加密，不利于网络侧服务器进行统一管理；其二，过度依赖客户端，不适合于SaaS应用；第三，若归属于同一客户标识(ID)的多个用户需要使用相同的业务数据，则需要为每个用户提供一个硬件加密器，从而增加了实现成本；其四，密码由客户端保存容易被木马程序破解。

发明内容

本申请实施例提供一种SaaS应用下提高数据安全性的方法、装置及系统，用以在SaaS应用中，避免业务数据的泄露。

本申请实施例提供的技术方案如下：

一种SaaS应用中的数据加密方法，包括：

在创建客户时，针对该客户的客户标识ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码；

根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密，允许所述至少一个用户根据自身的用户身份密码，获得解密后的数据密码；

按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据。

一种SaaS应用中使用的服务器、包括：

创建模块，用于针对客户标识ID创建至少一个归属于所述客户ID的用户；

密码生成模块，用于针对所述客户ID生成用于加密业务数据的数据密码，以及在创建所述至少一个用户时，根据指示设置该用户的用户身份密码；

第一处理模块，用于根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；

第二处理模块，用于在按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据。

一种SaaS应用系统，包括：

网站服务器，用于创建客户标识ID，并对归属于该客户ID的业务数据进行逻辑处理；

认证服务器，用于针对所述客户ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码；根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据；

存储服务器，用于保存业务数据，以及各用户的用户身份数据。

本申请公开了一种SaaS应用中的数据加密方法，该方法为：在创建客户时，针对该客户的客户标识ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码，以及根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密，以及在按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据所述数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据。这样，便可以有效避免管理人员对数据密码的泄露和恶意使用，从而有效地防止了业务数据的泄露，提升了业务数据的安全性。

附图说明

图1为本申请实施例中SaaS应用系统体系架构图；

图2为本申请实施例中认证服务器功能结构示意图；

图3为本申请实施例中在SaaS应用下创建客户流程图；

图4为本申请实施例中在归属于ID1的不同用户之间传递KEY1流程图；

图5为本申请实施例中在SaaS应用下用户使用业务数据流程图；

图6为本申请实施例中在SaaS应用下用户修改登录密码流程图。

具体实施方式

为了在SaaS应用中，避免用户的业务数据泄露，提升业务数据安全性，本申请实施例中，在创建客户时，针对该客户的客户标识ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码；根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据。

本实施例中，根据数据密码对业务数据进行加密时，可以对全部的业务数据进行加密，也可以仅对其中的部分敏感业务数据加密。

下面结合附图对本申请优选的实施方式进行详细说明。

参阅图1所示，本申请实施例中，应用SaaS技术的系统包括客户端10、网站服务器11、认证服务器12、存储服务器13和管理终端14，其中，

管理终端14，用于指示网站服务器11创建客户和该客户的客户ID，以及指示认证服务器12设置归属于该客户ID的至少一个用户的用户身份密码；

网站服务器11，用于创建客户标识ID，并对归属于该客户ID的客户相关数据，例如客户名称、客户所在地区、客户所属行业、联系人及电话、传真等信息，进行逻辑处理；

认证服务器12，用于针对所述客户ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码；根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据；

存储服务器13，用于保存业务数据，以及各用户的用户身份数据，该用户身份数据中包含的数据内容具体在以下实施例中介绍。

参阅图2所示，本申请实施例中，认证服务器12包括创建模块120、密码生成模块121、第一处理模块122和第二处理模块123，其中，

创建模块120，用于针对客户ID创建至少一个归属于所述客户ID的用户；

密码生成模块121，用于针对该客户ID生成用于加密业务数据的数据密码，以及在创建所述至少一个用户时，根据指示设置该用户的用户身份密码；

第一处理模块122，用于根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；

第二处理模块123，用于在按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并在确定所述至少一个用户获得解密后的数据密码时，向其提供解密后的业务数据。

基于上述SaaS应用的系统架构，参阅图3所示，本申请实施例中，后台的管理终端14在使用SaaS技术的系统中创建一个客户的详细流程如下：

步骤300：管理终端14向认证服务器12发送登录请求消息。

步骤301：认证服务器12向管理终端14返回登录响应消息。

步骤302：管理终端14向网站服务器11发送用于创建客户ID的请求消息。

步骤303：网站服务器1创建客户ID，本申请实施例中，将创建的客户ID称为ID1。

步骤304：网站服务器11向认证服务器12发送用于创建归属于ID1的管理员用户的请求消息。

步骤305：认证服务器12针对ID 1初始创建一个具有管理员权限的用户身份，本实施例中，将其称为用户1。

在实际应用中，也可以创建两个或两个以上具有管理员权限的用户，本申请仅以创建一个为例进行说明。

步骤306：认证服务器12根据客户的指示设置用户1的用户身份密码，本实施例中，用户身份密码即为用户的登录密码，并且将用户1初始设置的登录密码称为登录密码1。

步骤307：认证服务器12针对ID 1随机生成用于加密业务数据的数据密码，以下称为KEY 1。

在实际应用中，对业务数据的加密是针对同一个客户ID进行的，而一个客户ID可以由多个用户同时使用，因此，在业务使用过程中，针对一个客户ID可能会产生多个用户的业务数据，那么，在归属于同一客户ID的多个用户之间，要考虑到业务数据的共享问题，例如，不能因为用户A对业务数据A进行了加密，而导致用户B不能使用业务数据A；所以，本申请实施例中，针对一个ID 1设置一个统一的随机生成的数据密码KEY 1，归属于该客户ID的多个用户(包括用户1)均使用KEY 1对自身产生的业务数据进行加密。

步骤308：认证服务器12采用用户1的登录密码1对KEY 1进行可逆加密。

实际应用中，若KEY 1以明文形式记录，那么，客户的业务数据被泄露时，KEY 1也同样存在被泄露的危险，从而无法有效地保障业务数据的安全，可见，为了保证KEY 1的安全，必须对其进行加密存储。由于考虑到KEY 1是用于对业务数据进行加密和解密的，因此，对KEY 1加密时选择的可逆加密算法必须是可还原的，可以采用对称加密算法加密，例如，高级加密标准(AdvancedEncryption Standard，AES)、数据加密标准(Data Encryption Standard，DES)；当然也可以采用公共钥匙加密算法(也称非对称密钥密码算法)，例如，RSA算法(该算法以发明者的名字命名：Ron Rivest，AdiShamir和Leonard Adleman)，数字签名算法(Digital Signature Algorithm，DSA)等加密算法；在本实施例中，KEY1需要包含公开密钥和私有密钥，并且不存在被传递和保存的问题，因此，考虑到加密和解密流程的执行效率，采用对称加密算法优于采用非对称加密算法，本文后续以最优的AES加密算法为例进行说明。另一方面，为了防止KEY 1的泄露，较佳地，将其与具有管理员权限的用户1的用户身份数据一并保存。

步骤309：认证服务器12对用户1的登录密码1进行加密，本实施例中，采用MD5算法对登录密码1进行加密。

本实施例中，对登录密码1的加密是不可逆转的，可以采用Hash算法(又称散列算法或报文摘要)进行加密，例如，信息-摘要算法(Message-DigestAlgorithm 5，MD5)，安全哈希算法(Secure Hash Algorithm，SHA1)等。

步骤310：认证服务器12指示存储服务器13保存创建用户1时产生的用户身份数据，以下称为用户资料1。

本实施例中，用户资料1中包含了经MD5加密后的登录密码1的密文，以及经登录密码1加密后的KEY 1的密文。

步骤311：存储服务器13将用于表示用户资料1保存完毕的存储成功响应消息，发往认证服务器12和网站服务器11。

步骤312：网站服务器11在本地设置归属于ID1的用户1的相关信息，该相关信息包含但不限于：用户名称、用户登录名、初始登录密码、用户性别、电话及联系方式等等。

此时，用户1便可以通过自身使用的客户端10与网站服务器11进行信息交互，以使用SaaS应用下的各种业务了。

步骤313：网站服务器11指示存储服务器13保存用户1在业务使用过程中产生的业务数据。

步骤314：存储服务器13将用于表示业务数据保存完毕的存储成功响应消息，发往认证服务器12和网站服务器11。

在上述实施例中，针对ID 1设置数据密码KEY 1后，将其与用户资料1一起存储，但归属于ID 1的所有用户均需要使用KEY 1对自身产生的业务数据进行加密，因此，在创建归属于ID 1的其他用户时，需要将KEY 1传递给其他用户。参阅图4所示，本实施例中，用户1在创建用户2的过程中，向用户2传递KEY 1的详细流程如下：

步骤400：归属于ID 1的具有管理员权限的用户1，通过客户端10向认证服务器12发送登录请求消息，在该登录请求消息中携带用户1输入的登录密码1。

步骤401：认证服务器12对用户1输入的登录密码1进行MD5加密。

本实施例中，在用户1的创建过程中，由于采用MD5算法对设置的登录密码1进行加密，因此，加密后得到的密文是不可逆的，那么，在用户1登录时，认证服务器12只对用户1输入的登录密码1再次进行MD5加密，并将得到的密文与用户资料1中包含的密文进行比较，若一致，则确定用户1通过登录验证。

步骤402：认证服务器12从存储服务器13获取用户资料1。

步骤403：认证服务器12根据用户资料1对加密后的登录密码1进行检验。

步骤404：确定用户1通过校验后，根据登录密码1对用户资料1中包含的KEY 1的密文进行AES解密得到KEY 1。

步骤405：认证服务器12向客户端10返回登录成功响应消息。

步骤406：用户1通过客户端10指示认证服务器13创建归属于ID 1的用户2。

步骤407：认证服务器12创建归属于ID 1的用户2。

步骤408：认证服务器12根据用户1的指示设置用户2的登录密码，以下称为登录密码2。

步骤409：认证服务器12根据登录密码2对KEY 1进行AES加密。

步骤410：认证服务器12对登录密码2进行MD5加密。

步骤411：认证服务器12指示存储服务器13保存用户2的用户身份数据，以下称为用户资料2。

同理，用户资料2中同样包含经登录密码2加密后的KEY 1的密文，以及经MD5加密后的登录密码2的密文。

步骤412：存储服务器13将存储成功响应消息发往认证服务器13和客户端10。

基于上述两个实施例，参阅图5所示，本申请实施例中，用户1通过客户端10使用SaaS应用中的业务数据的详细流程如下：

步骤500：归属于ID 1的具有管理员权限的用户1，通过客户端10向认证服务器12发送登录请求消息，在该登录请求消息中携带用户1输入的登录密码1。

步骤501：认证服务器12对用户1输入的登录密码1进行MD5加密。

步骤502：认证服务器12从存储服务器13获取用户资料1。

步骤503：认证服务器12根据用户资料1对加密后的登录密码1进行检验。

步骤504：确定用户1通过校验后，根据登录密码1对用户资料1中包含的KEY 1的密文进行AES解密得到KEY 1。

步骤505：认证服务器12向客户端10返回登录成功响应消息。

步骤506：客户端10指示网站服务器11查看归属于ID1全部的业务数据。

步骤507：网站服务器11从存储服务器13获取业务数据1。

步骤508：网站服务器11指示认证服务器12对业务数据1进行AES解密。

步骤509：认证服务器12根据KEY 1对业务数据1进行AES解密。

步骤510：认证服务器12向网站服务器11和客户端10返回业务数据1的数据明文，以下称为数据明文1。

步骤511：用户1在客户端10上对数据明文1进行相应修改后，向网站服务器11返回修改后的数据明文1，以下称为数据明文1’。

步骤512：网站服务器11对数据明文1’进行业务逻辑处理。

步骤513：网站服务器11指示认证服务器12对处理后的数据明文1’进行加密。

步骤514：认证服务器12根据KEY 1对数据明文进行AES加密，生成密文形式的业务数据1’。

步骤515：认证服务器12向网站服务器11返回业务数据1’。

步骤516：网站服务器11指示存储服务器13保存业务数据1’。

步骤517：存储服务器13将存储成功响应消息发往网站服务器11和客户端10。

从上述实施例中可以看出，业务数据的AES加密和AES解密流程，均由网络侧的认证服务器12完成，因此，KEY 1始终由认证服务器保管，不会向外泄露，从而有效地保障的KEY 1的安全性。

基于上述各实施例可以看出，KEY 1对于用户1或用户2来说是透明的，即不可见的，并且是归属于ID 1的所有用户共用的，因此，不能对KEY 1进行轻易修改。但归属于ID 1的各用户的登录密码却是可以修改的，而KEY 1在不同的用户身份数据中，是根据各用户的登录密码进行加密的，因此，某用户的登录密码一旦修改，则需要根据新的登录密码对KEY1重新进行加密。参阅图6所示，本实施例中，用户1对自身的登录密码进行修改的详细流程如下：

步骤600：归属于ID 1的具有管理员权限的用户1，通过客户端10向认证服务器12发送登录请求消息，在该登录请求消息中携带用户1输入的登录密码1。

步骤601：认证服务器12对用户1输入的登录密码1进行MD5加密。

步骤602：认证服务器13从存储服务器13获取用户资料1。

步骤603：认证服务器13根据用户资料1对加密后的登录密码1进行检验。

步骤604：确定用户1通过校验后，根据登录密码1对用户资料1中包含的KEY 1的密文进行AES解密得到KEY 1。

步骤605：认证服务器12向客户端10返回登录成功响应消息。

步骤606：用户1通过客户端10指示认证服务器13将用户的登录密码1修改为登录密码1’。

步骤607：认证服务器12对登录密码1’进行校验。

所谓对登录密码1’进行校验，即是指对登录密码1’的长度、复杂性和包含非法字符情况进行检验。

步骤608：认证服务器12对登录密码1’进行MD5加密。

步骤609：认证服务器12根据登录密码1’对KEY 1进行AES加密。

步骤610：认证服务器12指示存储服务器13保存用户最新的用户身份资料，即用户资料1’。

步骤611：存储服务器13将存储成功响应消息发往认证服务器12和客户端10。

上述各实施例中，AES算法和MD-5算法仅为举例，根据认证系统的具体应用环境，也可以采用其他的可逆加密算法代替AES算法，以及采用其他的加密算法代替MD-5算法，在此不再赘述。

综上所述，在上述实施例中，认证服务器12在创建客户时，为每一个客户生成一个独立的随机的数据密码，有效防止了管理人员的泄露和恶意使用，同时，针对客户的客户标识ID生成用于加密业务数据的数据密码，以及创建至少一个归属于所述客户ID的用户，并根据指示设置该用户的用户身份密码，以及根据归属于所述客户ID的至少一个用户的用户身份密码对所述数据密码进行加密；以及在按照所述至少一个用户的指示，对应所述客户ID保存相关的业务数据时，根据针对该客户ID生成的数据密码对该业务数据进行加密，并允许所述至少一个用户根据解密后的数据密码获得解密后的业务数据。其中，业务数据在网络侧的网站服务器11内进行集中的业务逻辑处理，并在处理后由认证服务器12对全部或部分业务数据进行加密存储，可见，所有加密流程由认证服务器统一处理，从而有效地避免了业务数据的泄露，提升了业务数据安全性。另一方面，用户不需要记住数据密码，可以无感知地透明地使用SaaS应用系统中的各项业务，从而方便了用户的使用，提升了用户体验；并且，不需要增设客户端设备，从而避免了用户使用成本的增加。

以上所述认证服务器、存储服务器等可以是物理上相互独立的多台服务器，也可以位于同一台服务器内具有不同功能的软件或硬件。

为了描述的方便，以上所述认证服务器的各部分以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件或硬件中实现。

显然，本领域的技术人员可以对本申请中的实施例进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请实施例中的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请中的实施例也意图包含这些改动和变型在内。