Multi-tenant data isolation and sharing method and system in SaaS mode

Abstract

The invention relates to the technical field of data transmission and network security, and discloses a multi-tenant data isolation and sharing method and system in an SaaS mode, and the method comprises the steps that a data owner client executes data isolation hierarchical encryption and blind storage, and deploys a sharing strategy to a block chain; the SaaS platform responds to the access request, calculates a risk score in combination with context features and historical audit data, and executes blind state key conversion after risk assessment and strategy contract verification are passed; and the receiver client verifies the signature, decrypts to obtain the plaintext data and returns the audit log. According to the invention, through a blind storage and blind calculation mechanism, isolation of data ownership and platform management right is realized, and the risk of plaintext data leakage caused by unauthorized access of a platform administrator and key leakage of a server side is effectively prevented; and meanwhile, a dynamic risk assessment mechanism is utilized to identify account embezzlement and brute force cracking risks, and safe sharing of data is guaranteed.

Description

Technical Field

[0001] This invention relates to the field of data transmission and network security technology, specifically to a method and system for multi-tenant data isolation and sharing under the SaaS model. Background Technology

[0002] With the rapid development of cloud computing technology, the SaaS (Software as a Service) model has become the mainstream delivery form for enterprise applications due to its low cost, ease of maintenance, and high scalability. Under the SaaS model, multi-tenant architecture allows multiple tenants to share the same hardware resources and software services, greatly improving resource utilization. Especially in scenarios such as financial auditing, medical collaboration, and government office work, there are frequent and highly sensitive data sharing and transfer needs between different tenants of the SaaS platform (such as enterprises and regulatory agencies, hospitals and insurance companies).

[0003] In a SaaS multi-tenant system, the platform acts as the hub for data storage and transfer, playing a crucial role as a data custodian and trust center. Only by ensuring the security and privacy isolation of data during storage, transmission, and sharing can enterprises support data sharing. However, existing SaaS platforms, due to blurred trust boundaries and limitations in their security architecture, generally suffer from issues such as the lack of separation between data ownership and management rights, and passive identity defense when handling cross-tenant data sharing. This makes it difficult to meet high-level data security compliance requirements. Therefore, for the data security architecture under the existing SaaS model, achieving physical-level data isolation and dynamic sharing authorization through technical means is the foundation and prerequisite for ensuring tenant data sovereignty and privacy security.

[0004] Currently, traditional SaaS data sharing technologies generally adopt a centralized trust model, mainly including reliance on database logical isolation, unified key management on the server side, and static account password authentication. This approach has several shortcomings: First, the data storage architecture carries trust risks. Data is often stored in plaintext or encrypted only using keys hosted on the server side. This means the platform has decryption privileges, posing a risk that platform administrators may use high privileges to access sensitive tenant data, making blind data storage on the platform impossible. Second, the authentication mechanism lacks dynamic awareness. Traditional static authentication relies solely on account passwords or fixed tokens, failing to identify malicious acts such as account theft and brute-force attacks. When attackers steal legitimate credentials, the system cannot block them based on environmental characteristics (such as abnormal devices or logins from different locations), posing a high risk of data leakage. Therefore, a multi-tenant data isolation and sharing method and system under the SaaS model is urgently needed to solve these problems. Summary of the Invention

[0005] To address the problems in related technologies, this invention provides a method for multi-tenant data isolation and sharing in a SaaS model, thereby overcoming the aforementioned technical problems in existing related technologies.

[0006] To solve the aforementioned technical problem, the present invention is achieved through the following technical solution: In a first aspect, embodiments of the present invention provide a method for multi-tenant data isolation and sharing in a SaaS model, specifically including: the data owner tenant client performs data isolation and layered encryption, generates a storage package containing data ciphertext and key ciphertext, and uploads it to the SaaS platform for blind storage; the data owner tenant formulates a sharing strategy and deploys it to a blockchain smart contract, while generating a re-encryption authorization signal and sending it to the SaaS platform; the SaaS platform responds to the access request of the data recipient tenant, initiates a dynamic risk assessment mechanism, collects the contextual characteristics of the requester and calculates a risk score by combining it with historical audit behavior data on the blockchain; when the risk assessment is passed, the strategy contract status on the blockchain is verified and key ciphertext conversion is performed; the data recipient tenant client performs auditing and double decryption, verifies the legality of the data source and decrypts to obtain plaintext data, while simultaneously sending the audit log back to the blockchain; As a preferred embodiment of the multi-tenant data isolation and sharing method in the SaaS model described in this invention, the data owner tenant client constructs a storage package comprising: Generate a unique identifier for the business data; generate a one-time random symmetric key and symmetrically encrypt the business data to generate ciphertext; obtain the identity public key of the data owner tenant and encapsulate the one-time random symmetric key using a proxy re-encryption algorithm to generate initial key ciphertext; construct a data storage package, sign it using the private key of the data owner tenant, and upload it to the SaaS platform.

[0007] As a preferred embodiment of the multi-tenant data isolation and sharing method in the SaaS model described in this invention, the method is based on the contextual characteristics of the requester. The blockchain is used to retrieve historical audit data and calculate risk scores, expressed as follows: ; In the formula, This represents the environmental anomaly coefficient. For environmental risk weighting coefficients, This is the credit risk weighting coefficient. The number of successful feedback audit logs recorded by the requester on the blockchain. The total number of requests initiated by the requester is greater than or equal to 1.

[0008] As a preferred embodiment of the multi-tenant data isolation and sharing method under the SaaS model described in this invention, the environmental anomaly coefficient is expressed as: ; In the formula, Indicates the indicative function, when the device fingerprint collected this time... Not in the known device whitelist When the condition is met, the function value is 1; otherwise, it is 0. Indicates the weighting coefficient of the device fingerprint; Let be the velocity penalty function, when This value is 1 when the physical speed limit is exceeded, and 0 otherwise. These are the weighting coefficients of the velocity penalty function; This is a time outlier factor, which takes a value of 1 when the request time is outside the tenant's preset working time window, and 0 otherwise. The weighting coefficients for the time outlier factor.

[0009] As a preferred embodiment of the multi-tenant data isolation and sharing method under the SaaS model described in this invention, the risk assessment mechanism includes: setting a risk assessment threshold. If the risk score If the system determines there is a security risk, it will directly reject the request and terminate the process; if the risk score is low... The system determines that the environment is safe and continues to execute the strategy contract status verification.

[0010] As a preferred embodiment of the multi-tenant data isolation and sharing method under the SaaS model described in this invention, the generation of re-encryption authorization signaling includes: the data owner tenant client using its own private key and the recipient's public key to generate a re-encryption authorization key based on the proxy re-encryption algorithm; The re-encrypted authorization key is encrypted and encapsulated using the SaaS platform's public key and sent to the SaaS platform for hosting via a secure channel.

[0011] As a preferred embodiment of the multi-tenant data isolation and sharing method under the SaaS model described in this invention, the execution key ciphertext conversion includes: the SaaS platform calling a re-encryption function, using the re-encryption authorization key to ciphertext the initial key. Converted into ciphertext that the recipient can decrypt. .

[0012] As a preferred embodiment of the multi-tenant data isolation and sharing method under the SaaS model described in this invention, the auditing and double decryption performed by the receiving tenant client includes: verifying the legality of the SaaS platform signature; and re-encrypting the key ciphertext using the receiving tenant's private key. Decryption is performed to obtain the original symmetric key; the symmetric key is used to decrypt the ciphertext data to obtain plaintext data; the receiving tenant client generates an audit log containing the decryption status and the hash of the conversion credential, and uploads it to the blockchain.

[0013] Secondly, embodiments of the present invention provide a multi-tenant data isolation and sharing system under a SaaS model, comprising: a data isolation encapsulation module, deployed on the data owner tenant client, used to generate a random symmetric key to encrypt business data, and use a proxy re-encryption algorithm to generate key ciphertext to achieve blind data storage; a blockchain policy governance module, connecting the client and the blockchain network, used to store the sharing policy on the blockchain and generate re-encryption authorization signaling; a risk assessment module, deployed on the SaaS platform, used to collect request environment fingerprints and behavioral characteristics, calculate risk scores and compare them with preset risk assessment thresholds to block abnormal risk requests; a blind proxy conversion module, deployed on the SaaS platform, used to perform ciphertext conversion operations after the policy contract status verification is passed, converting the initial key ciphertext into a re-encryption key that the data receiving tenant can decrypt; and an audit decryption verification module, deployed on the data receiving tenant client, used to verify the conversion signature, decrypt and obtain data, and generate audit logs of the access behavior and write them back to the blockchain.

[0014] Thirdly, embodiments of the present invention provide a computer device, including a memory and a processor, wherein the memory stores a computer program, and the computer program, when executed by the processor, implements any step of the multi-tenant data isolation and sharing method under the SaaS model as described in the first aspect of the present invention.

[0015] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements any step of the multi-tenant data isolation and sharing method under the SaaS model as described in the first aspect of the present invention.

[0016] The present invention has the following beneficial effects: 1. This invention, through a data isolation and encapsulation module and a blind proxy conversion mechanism, ensures that plaintext data and symmetric keys are generated and decrypted only on the tenant client. The SaaS platform only performs key re-encryption operations in the encrypted state. This blind storage and blind computation mode prevents platform administrators, even those with the highest server privileges, from retrieving the original key, thereby isolating data ownership from platform management rights and effectively avoiding the risk of plaintext data leakage due to unauthorized access by platform administrators and server-side key leaks.

[0017] 2. This invention employs a dual verification mechanism of risk assessment and strategy validation to dynamically adjust access standards. For example, the system calculates risk scores and introduces reputation risk weights to constrain users' historical audit behavior. For accounts that frequently request data but rarely upload legitimate audit logs, the high weighting will raise their risk scores above the risk threshold, leading the system to judge them as malicious attempts and directly reject their requests. This mechanism achieves a balance between ensuring normal cross-device office work and defending against high-frequency malicious attacks. It ensures that verified requests not only have environmental characteristics (such as device fingerprints and geographical location) within a secure range but also possess a good historical audit reputation, thus solving the problem that traditional static identity verification cannot identify account theft and brute-force attacks under legitimate identities.

[0018] 3. This invention satisfies the trust requirement of data immutability through a closed loop of blockchain strategy governance and auditing. By utilizing blockchain to record sharing strategies and audit hashes, in the event of unauthorized data transfer, the authorization time, conversion time, and decryption certificate can be traced through on-chain records, clearly defining responsibility. Simultaneously, the receiving client can only maintain its high credibility and obtain subsequent access rights by automatically generating and uploading audit logs after successful decryption. This mechanism achieves evidence retention of the data access path, meeting the compliance and accountability requirements for data confidentiality in scenarios such as finance and healthcare.

[0019] Of course, any product implementing this invention does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

[0020] To more clearly illustrate the technical solutions of the embodiments of the invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the invention. For those skilled in the art, the drawings can be obtained from these drawings without creative effort.

[0021] Figure 1 The flowchart provides a method for multi-tenant data isolation and sharing under the SaaS model for this invention.

[0022] Figure 2 This is a flowchart illustrating the dynamic risk assessment and strategy contract verification process provided by the present invention.

[0023] Figure 3 This is a schematic diagram of the modules of the multi-tenant data isolation and sharing system under the SaaS model provided by the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Example 1 In traditional SaaS data sharing technologies, data is often stored in plaintext or only encrypted with server-side keys, which poses a risk of unauthorized access by platform administrators. Furthermore, traditional static authentication cannot identify account theft and brute-force attacks, posing a risk of data leakage.

[0026] To solve the above technical problems, such as Figure 1 As shown, Embodiment 1 of the present invention provides a method for multi-tenant data isolation and sharing in a SaaS model. Specifically, Embodiment 1 uses a financial scenario as an example: In an enterprise-level financial SaaS platform, tenant A (the data owner) needs to share an annual financial audit report with tenant B (a regulatory agency, the data recipient), requiring that it be valid only within a specific time window, and that the SaaS platform itself not be able to see the report content. It should be noted that while Embodiment 1 uses a financial audit scenario as an example, the present invention is also applicable to other SaaS multi-tenant scenarios such as medical record sharing and government data transfer.

[0027] In the specific implementation of Example 1: Tenant A's client performs data isolation and layered encryption, generating a storage package containing encrypted data and encrypted keys, which is then uploaded to the SaaS platform for blind storage. This method ensures that the SaaS platform only holds the encrypted data and cannot deduce the original key through a hybrid encryption mechanism, achieving data isolation at the physical level and effectively solving the problem of platform administrators using high privileges to access tenants' sensitive data. Tenant A formulates a sharing policy and deploys it to a blockchain smart contract, while simultaneously generating a re-encrypted authorization signaling message and sending it to the SaaS platform. This method uses the key management layer to record the sharing policy, achieving trustlessness of the SaaS platform and ensuring the immutability of the authorization list and revocation status, thereby avoiding the risk of malicious tampering in traditional centralized permission management. The SaaS platform responds to Tenant B's access request by initiating a dynamic risk assessment mechanism, collecting information from the requester's upper and lower bounds. This method calculates a risk score by combining textual features with historical audit behavior data on the blockchain. Once the risk assessment is passed, the status of the strategy contract on the blockchain is verified and the key ciphertext conversion is executed. By introducing reputation risk and environmental risk, this method can automatically intercept access requests with abnormal environments and low reputation, solving the problem that traditional static identity verification cannot identify account theft and brute-force attacks, and achieving a balance between normal office work and attack defense. At the same time, blind conversion ensures that even during the conversion process, the SaaS platform cannot snoop on the plaintext key. Tenant B's client performs auditing and double decryption, verifying the legality of the data source and decrypting to obtain the plaintext data, while sending the audit log back to the blockchain. This method achieves closed-loop evidence storage for the data access path. Once a data breach occurs, the entire process of authorization, conversion, and decryption can be traced through on-chain records, ensuring clear and unambiguous liability and leaving no room for denial.

[0028] Furthermore, to better illustrate the technical solution of Embodiment 1 of the present invention, a detailed description of the multi-tenant data isolation and sharing method under the SaaS model is provided, specifically including the following: S1. The client performs data isolation and layered encryption, generating a storage package containing data ciphertext and key ciphertext, and uploads it to the SaaS platform for blind storage. This includes the following sub-steps: S11. First, tenant A's client calls its local random number generator to generate a unique identifier for the business data. Specifically, it uses the UUIDv4 standard to automatically generate a 128-bit random string as... The formula for generating the formula is: For example, "550e8400-e29b-41d4-a716-446655440000", where This represents a function for generating universally unique identifiers based on random numbers. The plaintext index is stored on the SaaS platform and is also written into subsequent steps as a key index parameter to achieve logical anchoring between on-chain authorization policies and off-chain encrypted data; secondly, the client locally generates a one-time high-strength random symmetric key. (256 bits), using this key to access business data Perform symmetric encryption to generate ciphertext. The calculation formula is as follows: ,in, This indicates that a symmetric encryption algorithm is used for encryption, specifically the SM4 algorithm; simultaneously, business data is calculated. Integrity hash value ; S12, The client constructs an initial access policy. The initial access policy only allows users with the same set of identity attributes as tenant A to decrypt. The client then introduces a proxy re-encryption (PRE) algorithm to obtain tenant A's public key. For symmetric keys Perform asymmetric encryption encapsulation to generate the initial key ciphertext. Specifically, this is reflected in the following formula: ,in, This is a proxy re-encryption function, representing an encryption operation performed using the proxy re-encryption (PRE) algorithm.

[0029] S13. Construct a data storage package Then, the storage package is signed using tenant A's private key and uploaded to the SaaS platform.

[0030] In this embodiment 1, a hybrid encryption mechanism is employed, applying the computationally intensive PRE algorithm only to extremely small symmetric keys, thereby improving the system's encryption processing efficiency. Specifically, for example, tenant A generates an SM4 symmetric key "0x7F3A..." and encrypts 500MB of financial data in just 1.5 seconds; subsequently, the 32-byte SM4 key is encrypted using an elliptic curve (ECC) based PRE algorithm to generate the key ciphertext. The storage package received by the SaaS platform contains... It's garbled text. It's gibberish; the platform can't deduce it no matter how it calculates it. This key is in plaintext, thus achieving data isolation at the physical level and solving the problem of unauthorized access by platform administrators.

[0031] S2. The data owner formulates a sharing strategy and deploys it to the blockchain smart contract, while simultaneously generating a re-encrypted authorization signaling message and sending it to the SaaS platform. This includes the following sub-steps: S21. When tenant A decides to share data, the client defines the sharing policy. The strategy includes the recipient's identity. Target data index Access start time and end time , which is represented as .

[0032] S22, The client calculates the hash value of the sharing strategy. It then calls the blockchain smart contract interface to mark the hash value and authorization status as "Active" and writes it into the key governance layer DLT (such as a consortium blockchain based on Quorum) to ensure the irrevocability of the sharing strategy.

[0033] S23. Tenant A's client generates a re-encryption authorization key for tenant B based on the sharing policy information recorded on the key governance layer (DLT) and the PRE algorithm. Then, it is encrypted using the SaaS platform's public key and sent to the SaaS core platform for hosting. The specific steps are as follows: a. Obtaining input parameters: The client reads tenant A's private key from local storage. And the public key of target tenant B obtained from the blockchain. ; b. Generate a re-encryption authorization key: Based on the existing proxy re-encryption algorithm, using tenant A's private key. And tenant B's public key Generate re-encryption authorization key ; For example, this embodiment 1 uses a proxy re-encryption algorithm based on elliptic curve bilinear pairing, assuming that the coefficients are established at order of prime. bilinear group , and target group There exists a bilinear mapping on top. : .set up for The generator. The specific steps are as follows: Define parameter: Tenant A's private key Public key Tenant B's private key Public key ; Tenant A's client calculates the re-encryption authorization key This can be reflected by the following formula: ; In the formula, The operation is in the modulus Performed within a finite field, i.e. .

[0034] c. Secure Encapsulation and Transmission: The generated re-encryption authorization key Afterwards, tenant A's client uses the SaaS platform's public key. right The encryption is performed and sent to the SaaS platform via a secure Transport Layer Security (TLS) channel. It's important to note that the SaaS platform runs in a Trusted Execution Environment (TEE, such as Intel SGX), ensuring the re-encryption key is encrypted and isolated in memory and destroyed immediately after the conversion is complete.

[0035] In this embodiment 1, the risk of centralized access control being easily tampered with is addressed by utilizing a DLT record sharing strategy. Specifically, for example, tenant A sets a policy that allows user ID "Auditor_01" to be active within a time window. Internal access, of which The current time is displayed. The client generates a blockchain transaction with a transaction hash of "0xabc123...", and the smart contract records this authorization status. If tenant A wants to cancel sharing midway, they only need to send a "Revoke" command to the contract, and the on-chain state immediately becomes "Invalid". Any subsequent conversion attempts by the SaaS platform will be rejected, thus preventing the permission management from being tampered with.

[0036] S3, such as Figure 2 As shown, the SaaS platform responds to the request by performing dual verification of risk assessment and strategy contract validation, as well as encrypted conversion; specifically, it includes the following sub-steps: S31. Tenant B initiates a data-related request to the SaaS platform. The SaaS platform first initiates a dynamic risk assessment mechanism to collect the contextual characteristics of this request. ; in, This indicates that when tenant B initiates this data access request, the logical network address of its client on the Internet is obtained by the SaaS platform server when it receives the HTTP / HTTPS request by parsing the header of the network data packet. This represents a unique identifier generated based on the hardware attributes and software environment of tenant B's client device. It is used to distinguish between cases where the IP addresses are the same (e.g., both are at the same office network exit) but the physical devices are different. This effectively prevents accounts from logging in on unauthorized unfamiliar devices. With user authorization, the SaaS platform's front-end SDK uses WebGL fingerprinting technology combined with system APIs to collect a set of non-sensitive feature data, including screen resolution, operating system version, browser kernel version, etc. After feature concatenation, it is calculated using a hash algorithm (such as SHA-256). This represents the absolute time of the server system when the SaaS platform receives the access request from tenant B, which is directly generated by the system clock of the SaaS platform server. This indicates the physical geographic region (usually accurate to the city or administrative district level) where tenant B is located when initiating the request, using an IP address mapping method, based on... Query the country and city code of the client mapped from the IP geographic information database.

[0037] S32 and SaaS platforms combine request characteristics with historical behavior records on the blockchain to calculate risk scores. : ; In the formula, Environmental risk weights; Credit risk weight; This is the environmental anomaly coefficient (such as login from a different location, brand new equipment). This indicates the number of times tenant B has successfully decrypted data and uploaded valid audit logs / decryption credentials to the blockchain in all past access requests; This represents the total number of data access requests initiated by tenant B to the SaaS platform, as recorded in the blockchain ledger up to the current moment. 1; The proportion of tenant B's historical behavior where they only request data but do not provide audit results; for example, a user frequently requests keys ( The number of records with successful on-chain decryption is very large, but the number of records with successful decryption is relatively small. (very small), then The small value indicates that the user is attempting to maliciously crack the key, posing a significant security risk; it is important to emphasize that this is the first application by a new user ( When this is the case, risk scores are not calculated; risk scores are set directly. The value is fixed at 0; In this embodiment 1, the system pre-maintains a baseline behavioral profile of tenant B in the database, including a list of frequently used device fingerprints. Commonly used IP network segments Regular active periods The last successfully accessed geographical location and time Environmental anomaly coefficient It is obtained by comparing the characteristics of the current request with the user's baseline behavioral profile stored in the system database, and calculating the deviation, which is expressed as: ; In the formula, Indicates the indicative function, when the device fingerprint collected this time... Not in the known device whitelist When the condition is met, the function value is 1; otherwise, it is 0. Indicates the weighting coefficient; This represents the geographic movement speed, calculated by dividing the spherical distance between the currently requested geographic coordinates and the coordinates of the last successful access by the time difference. The spherical distance is calculated using the Haversine formula. Let be the velocity penalty function, when When the physical speed limit is exceeded (such as 1000 km / h or the maximum flight speed of a commercial aircraft), this item takes a value of 1; otherwise, it takes a value of 0. This is used to identify illogical location movements. For example, if a user was in Beijing 10 minutes ago and is now in New York making a request, the speed far exceeds the physical limit, and in this case, the value is 1. These are the weighting coefficients of the velocity penalty function; This is a time outlier factor, which takes a value of 1 when the request time is outside the tenant's preset working time window, and 0 otherwise. The weighting coefficients for the time outlier factor.

[0038] Set risk assessment thresholds ;like If the system determines there is a security risk, it will directly reject the request and terminate the process; if The system determined that the environment was safe and continued with the subsequent steps. In this embodiment 1, the weighting coefficient , , as well as , The risk factor judgment matrix is ​​constructed based on the analytic hierarchy process and calculated as follows: , , Determination: The system categorizes environmental features into hard features and soft features. Device fingerprints and movement speed are considered hard features; anomalies in these features strongly suggest abnormal attack behavior. Request time, on the other hand, is a soft feature, potentially leading to misjudgments due to factors such as overtime work or cross-time zone operations. Based on this, a judgment matrix for environmental risk factors is constructed. If we set device fingerprint and movement speed to be equally important (scale 1), and both are equally important relative to request time (scale 2, indicating slightly important), then: The matrix is ​​then subjected to the maximum eigenvalue calculation and normalization, resulting in an eigenvector weight distribution of approximately (0.4, 0.4, 0.2). To facilitate integer operations in the computer system, the weights are uniformly expanded (×10). Therefore, in this embodiment 1... , , The possible values ​​for are: , , .

[0039] , Determination: Considering that this embodiment is applied to a high-security financial audit scenario, the defense strategy focuses more on identifying persistent malicious attempts. If a user's historical behavior shows a large number of requests that have not been decrypted (i.e.... A higher value indicates that the account may be undergoing a brute-force or credential stuffing attack, a risk more destructive than a single environmental anomaly. Therefore, when constructing the global risk assessment matrix, setting the importance scale of reputation risk relative to environmental risk to 2, then... The weight ratios calculated based on this matrix are as follows: Therefore, in this embodiment 1 , The possible values ​​for are: , The purpose of this weighting is to amplify the impact of historical malicious behavior on the total risk score, thereby quickly blocking attempts by low-credit accounts.

[0040] Risk assessment threshold The risk boundary superposition analysis method is used to determine the risk level. Its logic is that the system must ensure business continuity for legitimate users in special scenarios (such as equipment replacement or emergency overtime) while resolutely blocking requests with significant attack characteristics. Based on the aforementioned weighting system, The safety upper limit is derived from the following three typical critical scenarios, and the analysis is as follows: A scenario involving a single hard feature anomaly: Suppose a legitimate user upgrades their computer due to a device update, but still initiates requests during normal working hours and locations, and this user has a perfect audit history reputation. The risk score calculated at this point Since 4≤ The request was allowed, which ensures that the business will not be interrupted due to a single-dimensional environmental change in normal device update and iteration scenarios. Scenario involving the overlay of hardware and software features: Assuming a legitimate user uses a new device to handle an urgent task outside of working hours, and the user has perfect credit at this time, the calculated risk score would be... ,because ≤ The request was approved. This represents the system's maximum risk tolerance for explainable emergency work behavior. However, in this critical state, if a user's historical reputation has even a slight flaw, resulting in a reputation score increase of only 0.1, the risk score becomes 6.1, thus triggering blocking. This demonstrates the system's sensitivity to user reputation in critical high-risk environments, effectively preventing attackers from using emergency windows for probing. Scenario with dual hard feature anomalies: Assuming a user logs in abnormally from a different location (abnormal trigger speed) and uses a new device, even without considering historical reputation, the risk score... It will also exceed the risk assessment threshold. The request was rejected, which means that the system can ignore reputational issues and forcibly block attacks with obvious physical contradictions (such as short-term cross-border movement and unregistered devices).

[0041] In summary, this embodiment can adjust the risk assessment threshold. Setting it to 6 allows one hard feature anomaly to be superimposed with one soft feature anomaly at the same time. Any risk superposition exceeding this combination (such as two hard features occurring concurrently, or reputation anomalies accompanying a critical environment) will be judged as an illegal intrusion by the system and will be blocked.

[0042] Based on the established weighting system and risk assessment thresholds, by combining features across four dimensions, the system can construct a comprehensive profile of the access environment. For example, when a risk assessment threshold is detected... A cross-border leap occurs in a short period of time, or When the device is brand new and has never been recorded before, the risk score will increase significantly, thus identifying the risk of account theft. Specifically, for example: suppose tenant B uses a brand new computer (device = 1) outside of working hours (time = 1), and the geographical location is normal (speed = 0), then... Get , , Then the risk score Risk assessment threshold ,but The system determines that there is a security risk and will reject the request; The above examples demonstrate that this method can calculate risk scores based on the collected request context features and in conjunction with a risk assessment mechanism. Then, by comparing with risk assessment thresholds In contrast, this automatically blocks access requests from abnormal environments and those with low credibility, solving the problem that traditional static authentication cannot identify account theft and brute-force attacks; for example, in the example above, the system sets a credibility risk weight ( This amplifies the impact of historical behavior on final decisions, meaning that even accounts with legitimate identities can be affected if there is a large amount of malicious probing behavior—requesting data without providing audit results (i.e.,...) When the risk level is low, its overall risk score is affected by the high weighting of the risk factor. It will be raised to the risk assessment threshold. The above actions, which resulted in system rejection, achieved a balance between ensuring normal cross-device office operations and defending against high-frequency malicious attacks. This ensured that requests that ultimately passed verification not only had environmental characteristics within a controllable range but also possessed a good historical audit reputation. Ultimately, the focus of network security defense was placed on suspicious entities whose behavioral patterns deviated from the baseline, preventing data theft and a collapse of trust between the platform and tenants. This solved the problem in SaaS multi-tenant scenarios of supporting flexible data sharing while preventing malicious unauthorized access under legitimate identities.

[0043] S33. If the risk assessment is approved, the SaaS platform, acting as a light node, queries the blockchain. Authorization to The strategy contract status is monitored, and the SaaS platform maintains a synchronized strategy cache database locally, subscribing to on-chain events (EventLog) to update the local cache in real time. If the returned status is "Active" and the current time meets the requirements... If so, the verification is successful.

[0044] S34 and SaaS platforms call the re-encryption function, utilizing... Ciphertext of the initial key Converted into ciphertext that the recipient can decrypt. For example, if the initial key ciphertext is in the form of... ( It is determined by the encryption function A one-time random number generated in tenant A's client is used to check the key. (After encryption and encapsulation), the converted ciphertext Represented as: ; Therefore, it utilizes the authorization key The encryption layer of the ciphertext is mapped from tenant A's public key to tenant B's private key. and its public key In the relevant format, tenant B can decrypt the ciphertext, thereby transferring ownership of the ciphertext; SaaS platform uses service private key Signing of transformed metadata Generate data packets This is returned to tenant B to prevent the SaaS platform from returning forged key ciphertext to tenant B.

[0045] In this embodiment 1, the SaaS platform acts as a blind computing agent, never accessing the plaintext key. Specifically, for example, if tenant B initiates a request within the authorization period, the SaaS platform queries the blockchain and finds the authorization valid. The platform performs a bilinear pairing mapping operation, converting tenant A's encrypted key packet into a format that tenant B's private key can open. During this process, the SaaS platform's memory only contains... , and All three are in encrypted form, and even if the platform administrator exports the memory data, they will not be able to recover the original symmetric key. This helps prevent data leaks and resolves the issue of platform administrators accessing data without authorization.

[0046] S4. The receiving client performs auditing and double decryption to verify the legitimacy of the data source and obtain the plaintext. At the same time, it sends the audit log back to the blockchain. This includes the following steps: S41. After receiving the encrypted packet, tenant B's client first verifies it using the SaaS platform's public key. This ensures the data has not been tampered with by a man-in-the-middle; then, tenant B's private key is used. Re-encrypt the key ciphertext Decrypt to obtain the original symmetric key. The decryption formula is expressed as: .

[0047] S42, Tenant B uses a symmetric key encrypted data Decryption yields plaintext data. Upon successful decryption, the client automatically generates a record containing the decryption status and the hash of the conversion credential. The audit logs are uploaded to the blockchain, and these logs will be used for subsequent calculations. This forms the basis for a closed-loop reputation system.

[0048] In this embodiment 1, a closed-loop evidence storage system for the data access path is implemented. Specifically, for example, after tenant B's client verification is successful, the symmetric key "0x7F3A..." is decrypted, allowing access to a 500MB financial report. The system automatically generates an access confirmation transaction in the background and uploads it to the blockchain. In the event of a future data breach, the on-chain data can trace when tenant A authorized the data, when the SaaS platform transitioned, and when tenant B decrypted the data. This clearly defines responsibility, leaves no room for denial, ensures network security, and resolves the issue of unauthorized access by platform administrators.

[0049] Example 2 As a second embodiment of the present invention, such as Figure 3 As shown in Example 1, this example also discloses a multi-tenant data isolation and sharing system under the SaaS model, which specifically includes: a data isolation encapsulation module, a blockchain strategy governance module, a risk assessment module, a blind proxy conversion module, and an audit decryption verification module.

[0050] The data isolation and encapsulation module is deployed on the sending tenant client. It is used to generate a high-strength symmetric key locally on the sending tenant client to encrypt business data, and encapsulate the symmetric key based on the proxy re-encryption algorithm and the identity public key to generate key ciphertext, ensuring that the SaaS platform cannot access the data plaintext and achieving physical isolation. The blockchain strategy governance module connects the tenant client and the blockchain network. It is used to generate smart contracts for shared strategies and store them on the chain. Through the immutability of the blockchain, it manages the authorization list and revocation status, realizes the separation of access control and data custody, and is responsible for generating re-encrypted authorization signals and sending them to the SaaS platform. The risk assessment module is deployed on the SaaS platform. When the SaaS platform receives an access request, it collects the requester's environmental fingerprint (such as IP address and geographical location) and behavioral characteristics, calculates a dynamic risk score, and triggers subsequent blockchain query and re-encryption operations when the score is lower than the preset risk assessment threshold to block legitimate identity attacks in abnormal environments. The blind agent conversion module is deployed on the SaaS platform and is used to perform key ciphertext conversion operation using re-encryption authorization signaling, under the premise that the risk assessment is passed and the blockchain policy is verified to be effective, to obtain a re-encryption key that the target tenant can decrypt. The audit decryption verification module is deployed on the receiving tenant's client. It is used by the receiving tenant to verify the legality of the conversion signature, decrypt to obtain the symmetric key and business data, and generate an audit hash of the access behavior to write back to the blockchain.

[0051] In the specific implementation of Implementation 2 above, firstly, tenant A uses the SM4 algorithm to encrypt the report body through the data layered encryption and encapsulation module, and uses the elliptic curve algorithm to encapsulate the key. The SaaS platform only stores the encrypted package. This method employs a hybrid encryption system, addressing the low efficiency of asymmetric encryption under large data volumes while ensuring the platform stores data without requiring it to be viewed. Secondly, through the blockchain policy governance module, tenant A formulates a policy contract containing tenant B's identity and validity period, stores it on the blockchain, and generates a re-encryption key. This method utilizes DLT recording and verification sharing policies to achieve trustlessness of the SaaS platform, ensuring the immutability of authorization and revocation. Then, the risk assessment module quantifies and determines the security risk rating of this access. Furthermore, the SaaS platform, through a blind-state proxy re-encryption module, automatically verifies the on-chain contract state and performs a blind-state conversion when tenant B initiates a request. This method ensures that computational resources are only consumed for conversion when the on-chain authorization is active, improving the system's resistance to attacks. Finally, tenant B verifies the SaaS signature and decrypts the data through the audit and decryption verification module, automatically uploading audit logs. This method achieves evidence retention of the data access path, fully meeting strict compliance and accountability requirements.

[0052] This embodiment also provides a computer device applicable to a multi-tenant data isolation and sharing system under a SaaS model, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement a multi-tenant data isolation and sharing method under a SaaS model as proposed in the above embodiment.

[0053] The computer device can be a terminal, comprising a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad on the computer device's casing, or an external keyboard, touchpad, or mouse.

[0054] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements a multi-tenant data isolation and sharing method under a SaaS model as proposed in the above embodiments. The storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as Static Random Access Memory (SRAM), Electrically Erasable Programmable Read-Only Memory (EEPROM), Erasable Programmable Read Only Memory (EPROM), Programmable Red-Only Memory (PROM), Read-Only Memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0055] In the description of this specification, references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0056] The preferred embodiments of the invention disclosed above are merely illustrative of the invention. These preferred embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. This specification selects and specifically describes these embodiments to better explain the principles and practical applications of the invention, thereby enabling those skilled in the art to better understand and utilize the invention.

Claims

1. A method for multi-tenant data isolation and sharing in a SaaS mode, characterized in that, The method comprises the following steps: The data owner tenant client performs data isolation and layered encryption to generate a storage package containing data ciphertext and key ciphertext, and uploads the storage package to the SaaS platform for blind storage; The data owner tenant formulates a sharing policy and deploys the sharing policy to a smart contract on a blockchain, and generates a re-encryption authorization signaling and sends the re-encryption authorization signaling to the SaaS platform; The SaaS platform responds to an access request of a data receiver tenant, starts a dynamic risk assessment mechanism, collects context features of the requester, and calculates a risk score in combination with historical audit behavior data on the blockchain; When the risk assessment passes, the state of the policy contract on the blockchain is verified, and key ciphertext conversion is performed; The data receiver tenant client performs audit and double decryption, verifies the legitimacy of the data source, and decrypts to obtain plaintext data, and meanwhile, audit logs are returned to the blockchain.

2. The method for multi-tenant data isolation and sharing in SaaS mode according to claim 1, characterized in that, The data owner tenant client builds the storage package by performing the following steps: A unique identifier of business data is generated, a one-time random symmetric key is generated, and the business data is symmetrically encrypted to generate data ciphertext; An identity public key of the data owner tenant is obtained, and the one-time random symmetric key is encapsulated by using a proxy re-encryption algorithm to generate initial key ciphertext; The data storage package is built, and the data storage package is signed by using a private key of the data owner tenant and is uploaded to the SaaS platform.

3. The method for multi-tenant data isolation and sharing in SaaS mode of claim 1, wherein, According to the context characteristics of the requester , query the blockchain to obtain historical audit data, and calculate a risk score, the expression of which is: ； In the formula, is an environmental anomaly coefficient, is an environmental risk weight coefficient, is a credit risk weight coefficient, is the number of successful feedback audit logs recorded by the requestor on the blockchain, is the total number of requests initiated by the requestor and is greater than or equal to 1.

4. The method for multi-tenant data isolation and sharing in SaaS mode of claim 3, wherein, The environmental anomaly coefficient is represented as: ； wherein, is an indicator function, which equals 1 when the device fingerprint of the current collection is not in the known device whitelist , and 0 otherwise, is the weight coefficient of the device fingerprint; is a velocity penalty function, which equals 1 when the velocity exceeds the physical moving limit velocity, and 0 otherwise, is the weight coefficient of the velocity penalty function; is a time outlier factor, which equals 1 when the request time is outside the working time window preset by the tenant, and 0 otherwise, is the weight coefficient of the time outlier factor.

5. The method for multi-tenant data isolation and sharing in SaaS mode of claim 4, wherein, The risk assessment mechanism comprises: setting a risk assessment threshold If the risk score The system determines that there is a security risk, directly rejects the request, and the process terminates; if the risk score The system determines that the environment is safe, and continues to perform policy contract state verification.

6. The method for multi-tenant data isolation and sharing in SaaS mode of claim 1, wherein, The re-encryption authorization signaling is generated by using a private key of the data owner tenant and a public key of the receiver based on the proxy re-encryption algorithm; The re-encryption authorization key is encrypted and encapsulated by using a public key of the SaaS platform, and is sent to the SaaS platform through a secure channel.

7. The method for multi-tenant data isolation and sharing in SaaS mode of claim 6, wherein, The performing the key ciphertext conversion comprises: the SaaS platform calling a re-encryption function, using a re-encryption authorization key to convert the initial key ciphertext into ciphertext that can be decrypted by the receiving party . .

8. The method for multi-tenant data isolation and sharing in SaaS mode of claim 7, wherein, The receiving tenant client performs audit and double decryption, including: verifying the legality of the SaaS platform signature; using the receiving private key to encrypt the re-encryption key ciphertext Decrypt to obtain the original symmetric key; decrypt the data ciphertext using the symmetric key to obtain the plaintext data; the receiving tenant client generates an audit log containing the decryption state and conversion credential hash, and uploads it to the blockchain.

9. The method for multi-tenant data isolation and sharing in SaaS mode of claim 1, wherein, The sharing policy contains an identity ID of a receiver, a target data index, an access start time and an end time; a hash value and an authorization state of the sharing policy are written into a smart contract on the blockchain, and are used for real-time state checking by the SaaS platform.

10. A multi-tenant data isolation and sharing system under SaaS mode, adopting the multi-tenant data isolation and sharing method under SaaS mode as claimed in any one of claims 1-9, characterized in that, The method comprises the following steps: A data isolation encapsulation module is deployed on the data owner tenant client, and is used for generating a random symmetric key to encrypt business data, and generating key ciphertext by using a proxy re-encryption algorithm to realize blind storage of data; A blockchain policy management module is connected with the client and the blockchain network, and is used for on-chain storage of a sharing policy and generation of a re-encryption authorization signaling; A risk assessment module is deployed on the SaaS platform, and is used for collecting a request environment fingerprint and behavior features, calculating a risk score, and comparing the risk score with a preset risk assessment threshold to block abnormal risk requests; A blind proxy conversion module is deployed on the SaaS platform, and is used for performing a ciphertext conversion operation to convert initial key ciphertext into a re-encryption key that can be decrypted by the data receiver tenant after the state of the policy contract is verified; An audit decryption verification module is deployed on the data receiver tenant client, and is used for verifying a conversion signature, decrypting to obtain data, and generating audit logs of an access behavior and writing the audit logs back to the blockchain.

Images