一种多租户模型的数据加解密方法、系统及存储介质与流程

1.本技术涉及数据安全服务的技术领域，尤其是涉及一种多租户模型的数据加解密方法、系统及存储介质。


背景技术：

2.随着进入数字化时代，数据同时兼具国家安全、数字经济、社会治理、个人隐私等多个属性，随着国家多项法案的制定实施，新时代数据安全治理的新局面正慢慢呈现，面对大数据的洪流，数据安全问题如何进行应对，用户隐私如何进行保护，是每一个企业比对考虑并进行采取的措施。
3.数据安全的重点之一就是为敏感数据做加密存储，这也是满足监管合规的必要条件，相关技术中的各种应用程序自主完成数据加密的技术差异性非常大：加密算法、加盐方式、存储结构各不相同，不利于管理和维护。
4.以用户姓名、手机号、身份证号等信息的加密为例，相关技术中包括以下步骤：应用系统的开发人员在代码中增加aes或其他加解密算法，实现加密、解密方法；将密钥加密存储或存放在应用系统中的安全软件中；找到姓名、手机号、身份证号存储的代码，增加加密方法，并记录返回的密文和iv；找到姓名、手机号、身份证号存储的代码，增加解密方法，调用时传递密文和iv。
5.但是使用相关技术中的方法，加解密算法需要由应用系统自行实现，且如果一个企业中存在较多应用系统，那密钥和加解密算法会分散至各个应用系统中，不利于企业进行管理维护。


技术实现要素：

6.为了实现中心化的加解密服务以便于企业进行管理维护，本技术提供一种多租户模型的数据加解密方法、系统及存储介质。
7.第一方面，本技术提供的一种多租户模型的数据加解密方法，采用如下的技术方案：一种多租户模型的数据加解密方法，其特征在于，包括：加解密服务器接收服务启动指令；所述加解密服务器接收应用系统基于加密指令发出的明文数据和与所述明文数据相对应的加密标识，所述加解密标识预存在所述应用系统中集成的加解密工具包内；所述加解密服务器对所述加密标识进行验证；验证通过后，所述加解密服务器从硬件安全模块中获取相对应的密钥并通过所述密钥对所述明文数据进行加密，以得到相应的密文数据；所述加解密服务器将所述密文数据发送至所述应用系统中以完成加密。
8.在其中的一些实施例中，所述加解密服务器接收应用系统基于解密指令发出的密文数据和与所述密文数据相对应的解密标识，所述解密标识预存在所述应用系统中集成的
加解密工具包内；所述加解密服务器对所述解密标识进行验证；验证通过后，所述加解密服务器从所述硬件安全模块中获取相对应的密钥并通过所述密钥对所述密文数据进行解密，以得到相应的明文数据；所述加解密服务器将所述明文数据发送至所述应用系统中以完成解密。
9.在其中的一些实施例中，所述加密标识和所述解密标识中皆包括apisign，所述apisign为签名，所述apisign的生成过程，具体包括以下步骤：所述应用程序获取企业端颁发的apisignkey，并将所述apisignkey发送至所述加解密工具包内，所述apisignkey由所述加解密服务器预先通过私密通道发送至所述企业端；所述加解密工具包获取所述apisignkey，并加入相应的时间戳和随机数以得到签名因素集；使用签名加密方法对所述签名因素集进行加密以生成相应的所述apisign。
10.在其中的一些实施例中，所述加解密服务器对所述加解密标识或解密标识进行验证，包括以下步骤：所述加解密服务器调用与所述应用程序中的apisignkey相对应的myapisignkey；所述加解密服务器将所述apisign进行解码以得到签名因素集，并获取所述签名因素集内的时间戳和随机数，并将所述时间戳和随机数加入至所述myapisignkey以得到验证签名因素集；使用签名加密方法对所述验证签名因素集进行加密以生成相应的myapisign，将所述myapisign与所述apisign进行比对；若所述myapisign与所述apisign相等，则验证通过。
11.在其中的一些实施例中，所述加密标识还包括keyid，所述keyid为密钥唯一标识，所述加解密服务器从硬件安全模块中获取相对应的密钥并通过所述密钥对所述明文数据进行加密，以得到相应的密文数据，包括以下步骤：所述加解密服务器获取所述加密标识中的keyid，并从所述硬件安全模块中获取与keyid相匹配的密钥；使用所述密钥对所述明文数据进行加密，以得到相应的密文，将所述密钥添加至所述密文中，再添加随机向量至密文中，以得到多元结构的密文数据，所述密文数据的组合结构为encrypt-{keyid}-{iv}-{密文}，其中encrypt为固定前缀，iv为本次加密的随机向量，密文是加密后的数据做base64后的字符串。
12.在其中的一些实施例中，所述加解密服务器硬件安全模块中获取相对应的密钥并通过所述密钥对所述密文数据进行解密，包括以下步骤：所述加解密服务器通过所述密文数据中的{keyid}获取密文数据中keyid的参数，并根据keyid的参数从所述硬件安全模块中获取与keyid相匹配的密钥；所述加解密服务器通过所述密文数据中的{iv}获取密文数据中随机向量的参数；所述加解密服务器通过所述密钥与所述随机变量对所述密文数据进行解密。
13.在其中的一些实施例中，所述加解密服务器判断接收的是明文数据还是密文数据，若接收的是明文数据，则判断所述明文数据是否为所述应用系统基于加密指令发出的，
若不是，则取消加密且生成相应的错误报告，并将所述错误报告与所述明文数据一同退回至所述应用系统中；若接受的是密文数据，则判断所述密文数据是否为所述应用系统基于解密指令发出的，若不是，则取消解密且生成相应的错误报告，并将所述错误报告与所述密文数据一同退回至所述应用系统中。
14.在其中的一些实施例中，所述加解密服务器进行加密或解密后，所述加解密工具包对所述密文数据或明文数据进行存储，并在预设时间内对所述加解密工具包内存储的密文数据进行筛选，以判断是否所有所述密文数据皆为多元结构数据，若存在不是多元结构数据的密文数据，则根据所述密文数据内的{keyid}识别其相对应的应用程序，并将所述密文数据发送至该应用程序以进行重新加密。
15.第二方面，本技术提供的一种多租户模型的数据加解密系统，采用如下的技术方案：一种多租户模型的数据加解密系统，其特征在于：包括应用系统、加解密工具包、加解密服务器和硬件安全模块，其中，所述应用系统用于接收加密指令，并基于加密指令发出明文数据；所述应用系统还用于接收解密指令，并基于解密指令发出密文数据；所述加解密工具包集成在所述应用系统内，用于接收应用系统发出的明文数据和密文数据，用于存储与应用程序发出的明文数据相对应的加密标识或与密文数据相对应的解密标识，当应用系统接收到加密指令后，将明文数据和加密标识发送至加解密服务器，当应用系统接收到解密指令后，将密文数据和解密标识发送至加解密服务器；所述加解密服务器用于接收服务启动指令，并接收明文数据和加密标识，所述加解密服务器对所述加密标识进行验证，验证通过后，所述加解密服务器从硬件安全模块中获取相对应的密钥并通过所述密钥对所述明文数据进行加密，以得到相应的密文数据；所述加解密服务器将所述密文数据发送至所述应用系统中以完成加密；所述加解密服务器用于接收服务启动指令，还用于接收密文数据和解密标识，所述加解密服务器对所述解密标识进行验证，验证通过后，所述加解密服务器硬件安全模块中获取相对应的密钥并通过所述密钥对所述密文数据进行解密，以得到相应的明文数据；所述加解密服务器将所述明文数据发送至所述应用程序中以完成解密；所述硬件安全模块用于根据用户配置添加、删除密钥，并对密钥进行存储，以供所述加解密服务器获取密钥。
16.在其中的一些实施例中，所述密文数据为多元结构数据，所述多元结构数据的组合结构为encrypt-{keyid}-{iv}-{密文}，其中encrypt为固定前缀，iv为本次加密的随机向量，密文是加密后的数据做base64后的字符串。
17.第三方面，本技术提供的一种计算机存储介质，采用如下的技术方案：一种计算机存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至8中任一项所述的多租户模型的数据加解密方法。
18.综上所述，本技术包括以下至少一种有益技术效果：1.本技术通过基于多租户的技术提供加密、解密http/https服务，面对多个应用系统时，每个应用系统无需发开其单独的加解密算法，也无需关心密钥的存储位置、存储状态，所有应用系统在进行加解密操作时，都是通过加解密服务器进行的，而密钥都是存储在
基于第三方认证的硬件安全模块中，企业端无需考虑密钥的位置，以此降低了应用系统的数据泄露的风险，也便于企业进行管理维护；2.中心化的加解密服务可以集中地对密钥进行管理，便于企业管理者颁发密钥、定期更换密钥；3.密文数据为创新设置的多元密文结构，使得解锁时无需提供额外的密钥和盐，可通过密文直接解密，标准化的密文结构同时也便于企业进行管理和维护。
附图说明
19.图1是本技术实施例中多租户模型的数据加解密方法的整体结构示意图；图2是本技术实施例中多租户模型的数据加解密系统的原理图；图3是本技术实施例中多租户模型的数据加解密系统的模块示意图。
具体实施方式
20.为更清楚地理解本技术的目的、技术方案和优点，下面结合附图和实施例，对本技术进行了描述和说明。然而，本领域的普通技术人员应该明白，可以在没有这些细节的情况下实施本技术。在一些情形下，为了避免不必要的描述使本技术的各方面变得晦涩难懂，对已经在较高的层次上描述了众所周知的方法、过程、系统、组件和/或电路将不作过多赘述。对于本领域的普通技术人员来说，显然可以对本技术所公开的实施例作出各种改变，并且在不偏离本技术的原则和范围的情况下，本技术中所定义的普遍原则可以适用于其他实施例和应用场景。因此，本技术不限于所示的实施例，而是符合与本技术所要求保护的范围一致的最广泛范围。
21.除另作定义外，本技术所涉及的技术术语或者科学术语应具有本技术所属技术领域具备一般技能的人所理解的一般含义。本技术所使用的术语仅出于描述特定实施例的目的，而不旨在于对本技术的限制。如本技术所使用的“一”、“一个”、“一种”、“该”、“这些”等类似的词并不表示数量上的限制，它们可以是单数或者复数。在本技术中所涉及的术语“包括”、“包含”、“具有”及其任何变体，其目的是涵盖不排他的包含；例如，包含一系列步骤或模块（单元）的过程、方法和系统、产品或设备并未限定于列出的步骤或模块（单元），而可包括未列出的步骤或模块（单元），或者可包括这些过程、方法、产品或设备固有的其他步骤或模块（单元）。
22.在本技术中所涉及的“多个”是指两个或两个以上。通常情况下，字符“/”表示前后关联的对象是一种“或”的关系。在本技术中所涉及的术语“第一”、“第二”、“第三”等，只是对相似对象进行区分，并不代表针对对象的特定排序。
23.本技术所涉及的术语“系统”、“引擎”、“单元”、“模块”和/或“块”是一种用于按级别区分不同级别的不同组件、元件、零件、部件、装配件、或功能的一种方法。这些术语可以被其他能够达到相同目的的表达替换。通常，本技术涉及的“模块”、“单元”或“块”是指硬件或者固件中体现的逻辑或软件指令的集合。本技术描述的“模块”、“单元”或“块”可以作为软件和/或硬件实现，并且在作为软件实现的情形下，他们可以被存储在任何类型的非易失性计算机可读存储介质或存储设备中。
24.在一些实施例中，软件模块/单元/块可以被编译并被链接到可执行程序中。将意
识到，软件模块可以是可从其他模块/单元/块或从其自身调用的，和/或可以响应于检测到的事件或中断而被调用。配置为在计算设备上执行的软件模块/单元/块可以设置在计算机可读存储介质上，例如光盘、数字视频盘、闪存驱动器、磁盘、或任何其他有形媒体，或作为数字下载（并且可以最初以压缩或可安装的格式存储，该格式需要在执行之前进行安装、解压或解密）。这样的软件代码可以部分地或全部地存储在正在执行的计算设备的存储设备上，并应用在计算设备的操作之中。软件指令可以被嵌入到固件，例如eprom中。还将意识到，硬件模块/单元/块可以被包括在连接的逻辑组件中，例如门和触发器，和/或可以被包括在可编程单元中，例如可编程门阵列或处理器。本文描述的模块/单元/块或计算设备功能可以被实现为软件模块/单元/块，还可以以硬件或固件来表示。通常，本文描述的模块/单元/块，它们可以与其他模块/单元/块组合，或者尽管它们是物理组织或存储的，但也可以被划分为子模块/子单元/子块。该描述可以适用于系统、引擎或其一部分。
25.将理解的是，当单元、引擎、模块或块被称为在另一单元、引擎、模块或块“上”、“连接”或“耦合至”另一单元、引擎、模块或块时，其可以直接在其它单元、引擎、模块或块上，与其连接或耦合或与之通信，或者可以存在中间单元、引擎、模块或块，除非上下文另有明确说明。在本技术中，术语“和/或”可包括任何一个或以上相关所列条目或其组合。
26.以下结合附图1-3对本技术作进一步详细说明。
27.本技术实施例公开一种多租户模型的数据加解密方法。
28.如图1所示，一种多租户模型的数据加解密方法包括：s100，加解密服务器接收服务启动指令。
29.启动指令由用户发出，以通知加解密服务器准备进行加解密任务。
30.s200，加解密服务器接收应用系统基于加密指令发出的明文数据和与明文数据相对应的加密标识，加密标识预存在应用程序中集成的加解密工具包内。
31.如图1和图2所示，应用系统为企业端使用的操作环境，一般由计算机硬件系统、系统软件、应用软件组成。计算机基本硬件系统由运算器和控制器、存储器、外围接口和外围设备组成。系统软件包括操作系统、编译程序、数据库管理系统、各种高级语言等。应用软件由通用支援软件和各种应用软件包组成。多个用户可以使用不同的应用系统，一个用户也可以使用多个应用环境。
32.企业端向应用系统发送加密指令，应用程序将明文数据和与明文数据相对应的加密标识发送至加解密服务器上。加解密标识预存在应用程序中集成的加解密工具包内。
33.加解密工具包也称为加解密sdk，sdk是一些项目的软件开发工程师为特定的平台，硬件平台，操作系统，软件框架等开发的开发工具集合以应用于应用软件开发。sdk包括广义上指辅助开发某一类软件的相关文档，范例和工具的集合。
34.对加解密功能高度封装的加解密工具包，支持本地缓存、面向对象存取等功能，简化了应用程序的接入和使用。
35.应用系统可以选择开启加解密工具包的本地缓存功能，减少网络请求开销。本地缓存功能是将经过加、解密后的明文数据或密文数据暂存在本地，以key/value形式体现，key是明文数据，value是密文数据，以及key是密文value是明文。
36.加密标识内包括apisign和keyid。apisign为签名，用于后续与后续加解密服务器的端口进行验证，keyid为密钥唯一标识，用于后续加解密服务器寻找与明文数据相关联的
密钥。
37.s300，加解密服务器对加密标识进行验证。
38.加解密服务器对加密标识进行验证就是对加密标识中的apisign进行验证。其中，apisign的生成过程如下：s310，应用程序获取企业端颁发的apisignkey，并将apisignkey发送至加解密工具包内。
39.s320，加解密工具包获取apisignkey，并加入相应的时间戳和随机数以得到签名因素集。
40.s330，使用签名加密方法对签名因素集进行加密以生成相应的apisign。
41.apisignkey是预先通过私密通道发送至企业端的，每一个应用系统皆对应有一个单独的apisignkey。而为了使签名具有唯一性，还需要在apisignkey上添加时间戳和随机数以得到签名因素集。唯一性是指：为了防止别人重复使用请求参数问题，需要保证请求的唯一性，就是对应请求只能使用一次，这样就算别人拿走了请求的完整链接也是无效的。
42.其中随机数的作用是：在请求中添加一个随机数，加解密服务器记录随机数，如果有多次重刷数据可以根据随机数进行判断，看这个请求的随机数在之前的请求中是否出现，若重复出现则说明该请求已经出现过。
43.时间戳的作用是：加解密服务器一致记录大量随机数，会增加服务器的负担和计算量，这时加入一个时间戳，时间戳的大小可以进行调节，如设置为5分钟，在5分钟的时效过去后，清空加解密服务器中的所有随机数记录，且该签名请求无效。以此通过时间戳来判断一个签名验证请求是否过期，这样就算被人拿走完整的签名验证请求也是无效的。
44.对签名因素集进行加密时的签名加密方法在本实施例中为md5。md5算法的简要的叙述可以为：md5以512位分组来处理输入的信息，且每一分组又被划分为16个32位子分组，经过了一系列的处理后，算法的输出由四个32位分组组成，将这四个32位分组级联后将生成一个128位散列值。其主要包括填充、初始化变量、处理分组数据、输出四个步骤，md5就是对签名添加其具有唯一性的“指纹”，当这个签名发送至服务器后，服务器根据签名内的数据进行重新计算并使用md5添加另一个“指纹”，最后看两个“指纹是否相同”，以此判断该签名是否收到了篡改。
45.生成apisign后，加解密服务器对加密标识的验证包括以下步骤：s340，加解密服务器调用与应用程序中的apisignkey相对应的myapisignkey。
46.加解密服务器会预先将一个apisignkey通过私密通道发送至企业端的应用系统中，并同时生成与apisignkey相同的myapisignkey并进行存储。当应用程序对加解密服务器的端口进行验证请求时，加解密服务器根据apisignkey调用与其相同的myapisignkey，以实现加解密服务器与多个应用程序中的某一应用程序唯一性连接。
47.s350，加解密服务器将apisign进行解码以得到签名因素集，并获取签名因素集内的时间戳和随机数，并将时间戳和随机数加入至myapisignkey以得到验证签名因素集。
48.加解密通过对apisign解密或直接获取签名因素集内的时间戳和随机数，并将时间戳和随机数加入到myapisignkey以得到验证签名因素集，验证签名因素集用于对签名因素集进行验证。
49.s360，使用签名加密方法对验证签名因素集进行加密以生成相应的myapisign，将
myapisign与apisign进行比对。
50.使用md5算法对myapisignkey、时间戳、随机数进行加密，并得到相应的myapisign，将myapisign和apisign进行比对，看两个值是否相同，以此判断验证是否被进行篡改或是否具有唯一性。
51.s370，若myapisign与apisign相等，则验证通过。
52.如果myapisign与apisign相等，则验证通过，若两个值不相同，则说明时间戳或随机数可能发生了变化，可能是被收到篡改或不具有唯一性，验证不通过，并将明文数据和明文标识重新发送回应用系统中。
53.s400，验证通过后，加解密服务器从硬件安全模块中获取相对应的密钥并通过密钥对明文数据进行加密，以得到相应的密文数据。
54.如图1和图2所示，具体包括：s410，加解密服务器获取加解密标识中的keyid，并从硬件安全模块中获取与keyid相匹配的密钥。
55.硬件安全模块可以使用基于第三方认证的硬件安全模块对多个配对于加解密服务器的应用程序的密钥进行统一存储。企业端可以在硬件安全模块中添加、删除密钥。
56.当加解密服务器获取到keyid后，因为keyid为密钥的唯一标识，加解密服务器可以根据keyid在硬件安全模块中找到与这个keyid相匹配的密钥，keyid和密钥是一对一相互匹配的。
57.多个应用系统，每个应用系统都在硬件安全模块中添加有单独的密钥，且每个应用系统自身的keyid都是不同的，根据某一keyid在众多的密钥中找到相匹配的密钥。
58.s420，使用密钥对明文数据进行加密，以得到相应的密文，将密钥添加至密文中，再添加随机向量至密文中，以得到多元结构的密文数据，密文数据的组合结构为encrypt-{keyid}-{iv}-{密文}。
59.其中，encrypt为固定前缀，iv为本次加密的随机向量，密文是加密后的数据做base64后的字符串。
60.而其中的keyid就是上述中加解密sdk发送至加解密服务器的。将密文数据设置成创新式的多元密文结构，便于后续在解密过程中寻找密钥。同时，这种密文数据结构也可以使明文数据和密文数据之间形成较大的直接差别，便于加解密服务器进行识别，以此提高企业对敏感数据进行管理和维护。
61.s500，加解密服务器将密文数据发送至应用系统中以完成加密。
62.s600，加解密服务器接收应用系统基于解密指令发出的密文数据和与密文数据相对应的解密标识，解密标识预存在应用系统中集成的加解密工具包内。
63.其中解密标识包括apisign，其中解密标识中的apisign的生成方法与加密标识中的apisign的生成方法一致，具体过程如上述s310-s330。
64.s700，加解密服务器对解密标识进行验证。
65.加解密服务器对解密标识的验证方法与加解密服务器对加密标识的验证方法相同，也就是与上述的s340-s370的步骤一致。
66.s800，验证通过后，加解密服务器从硬件安全模块中获取相对应的密钥并通过密钥对密文数据进行解密，以得到相应的明文数据。
67.具体包括以下步骤：s810，加解密服务器通过密文数据中的{keyid}获取密文数据中keyid的参数，并根据keyid的参数从硬件安全模块中获取与keyid相匹配的密钥。
68.在进行解密时，无需再提供与应用系统相对应的keyid随密文数据一同发送至加解密服务器中，而是可以直接通过密文数据进行解密。可以直接从多元结构的密文数据中获取keyid值，并直接根据keyid去寻找相对应的密钥，省去了加解密工具包将keyid发送至加解密服务器，加解密服务器对keyid进行解析的过程，减少加解密服务器的计算量。也减少了在传输过程中keyid被拦截篡改的风险。
69.s820，加解密服务器通过密文数据中的{iv}获取密文数据中随机向量的参数。
70.iv为随机向量，也就是“盐”值，在对明文数据进行加密时，会在得到的密文中添加一定的“盐”值，“盐”是个随机数值，只有加解密服务器知道“盐”值的大小，加盐的目的是为了防止会有人非法获取到密文数据后，想将密文数据进行解密时，因为不知道“盐”值，故密文数据在散列时与知道“盐”值的散列是不同的，故无法对密文数据进行解密。
71.同时，若两个应用系统发出的明文数据恰好是相同的6位数密码，那么为了避免两个密码之间出现冲突，所以在每个密码中放置不同的“盐”值，所以在两个密码相同时，其散列值也是不同的。
72.s830，加解密服务器通过密钥与随机变量对密文数据进行加密。
73.加解密服务器直接通过多元结构的密文数据中得到keyid和随机向量，并根据keyid获取相应的密钥进行解密。
74.s900，加解密服务器将明文数据发送至应用系统中以完成解密。
75.同时，多元结构的密文数据还可以使服务器自动快速识别一个数据是否为密文数据，不会对密文数据进行重复加密，也不会对明文数据进行重复解密，使得应用系统可以平滑上线升级，消除停机、网络抖动等业务影响。
76.具体包括：加解密服务器判断接收的是明文数据还是密文数据，若接收的是明文数据，则判断明文数据是否为应用系统基于加密指令发出的，若不是，则取消加密且生成相应的错误报告，并将错误报告与明文数据一同退回至应用程序中。
77.若接收的是密文数据，则判断密文数据是否为应用系统基于解密指令发出的，若不是，则取消解密且生成相应的错误报告，并将错误报告与明文数据一同退回至应用程序中。
78.加解密服务可以根据接收到的数据的结构快速判断这是明文数据还是密文数据，并调取应用系统中的指令，看数据和指令是不是相对的，若是对明文数据进行解密指令或对密文数据进行加密指令，那么就存在了重复加、解密，加解密服务器可以快速响应阻止，并发送错误报告至应用系统以提醒企业端减少出现错误指令。
79.同时，因为在本实施例中，多租户的模式，多个应用系统共用一个加解密服务器，所以在这种情况下，标准的密文结构，有助于企业对敏感数据进行管理和维护，比如定期筛选是否所有敏感数据都以该密文结构进行存储、通过{keyid}部分识别哪个应用系统请求了加密。
80.具体包括：
加解密服务器进行加密或解密后，加解密工具包对密文数据或明文数据进行存储，并在预设时间内对加解密工具包内存储的密文数据进行筛选，以判断是否所有密文数据皆为多元结构数据，若存在不是多元结构数据的密文数据，则根据密文数据内的{keyid}识别其相对应的应用程序，并将密文数据发送至该应用程序以进行重新加密。
81.基于上述的方法，本技术通过基于多租户的技术提供加密、解密http/https服务，面对多个应用系统时，每个应用系统无需发开其单独的加解密算法，也无需关心密钥的存储位置、存储状态，因为所有应用系统在进行加解密操作时，都是通过加解密服务器进行的，应用系统只需要基于指令将明文数据或密文数据发送给加解密服务器就可以，而密钥都是存储在基于第三方认证的硬件安全模块中，企业端无需考虑密钥的位置，以此降低了应用系统的数据泄露的风险，也便于企业进行管理维护。
82.同时中心化的加解密服务可以集中地对密钥进行管理，便于企业管理者颁发密钥、定期更换密钥。
83.如图2和图3所示，在另一个实施例中，还公开了一种多租户地数据加解密系统，包括应用系统、加解密工具包、加解密服务器和硬件安全模块。
84.加解密工具包集成在应用系统内，用于接收应用系统发出的明文数据和密文数据，用于存储与应用程序发出的明文数据相对应的加密标识或与密文数据相对应的解密标识，当应用系统接收到加密指令后，将明文数据和加密标识发送至加解密服务器，当应用系统接收到解密指令后，将密文数据和解密标识发送至加解密服务器。
85.加解密服务器用于接收服务启动指令，并接收明文数据和加密标识，加解密服务器对加密标识进行验证，验证通过后，加解密服务器从硬件安全模块中获取相对应的密钥并通过密钥对明文数据进行加密，以得到相应的密文数据；加解密服务器将密文数据发送至应用系统中以完成加密。
86.加解密服务器用于接收服务启动指令，还用于接收密文数据和解密标识，加解密服务器对解密标识进行验证，验证通过后，加解密服务器硬件安全模块中获取相对应的密钥并通过密钥对密文数据进行解密，以得到相应的明文数据；加解密服务器将明文数据发送至应用程序中以完成解密。
87.硬件安全模块用于根据用户配置添加、删除密钥，并对密钥进行存储，以供加解密服务器获取密钥。
88.密文数据为多元结构数据，多元结构数据的组合结构为encrypt-{keyid}-{iv}-{密文}，其中encrypt为固定前缀，iv为本次加密的随机向量，密文是加密后的数据做base64后的字符串。
89.在另一个实施例中，还公开了一种计算机存储介质，其上存储有计算机程序，计算机程序是被处理器执行时实现上述任一项实施原理为：如图1和图3所示，基于上述的方法，本技术通过基于多租户的技术提供加密、解密http/https服务，面对多个应用系统时，每个应用系统无需发开其单独的加解密算法，也无需关心密钥的存储位置、存储状态，因为所有应用系统在进行加解密操作时，都是通过加解密服务器进行的，应用系统只需要基于指令将明文数据或密文数据发送给加解密服务器就可以，而密钥都是存储在基于第三方认证的硬件安全模块中，企业端无需考虑密钥的位置，
以此降低了应用系统的数据泄露的风险，也便于企业进行管理维护。
90.同时中心化的加解密服务可以集中地对密钥进行管理，便于企业管理者颁发密钥、定期更换密钥。
91.以上均为本技术的较佳实施例，并非依此限制本技术的保护范围，故：凡依本技术的结构、形状、原理所做的等效变化，均应涵盖于本技术的保护范围之内。