Data access method based on zero-trust architecture and related products

Abstract

The invention discloses a data access method based on a zero-trust architecture and a related product. The method comprises the following steps: acquiring multi-factor data; performing dynamic analysis based on the multi-factor data to obtain a trust score; if the trust score is smaller than a preset threshold value, issuing an access denial instruction; if the trust score is greater than or equal to a preset threshold, generating a single access token; and reading storage records of a plurality of sub-blocks in the block chain based on the single access token, determining a target sub-block, and performing decryption and recombination processing on the target sub-block to obtain the to-be-accessed data. Dynamic analysis is carried out through multi-dimensional data, and a trust score reflecting the access credibility is generated. And judging whether the access authority is granted or not according to a scoring result, thereby realizing minimum authorization and refined authority control. And when the data is accessed, the storage positions of the encrypted data sub-blocks are retrieved from the block chain according to the token information, and the plurality of encrypted sub-blocks are decrypted and recombined, so that the complete data content is restored, and the data confidentiality and the anti-leakage capability are improved.

Description

Technical Field

[0001] The present application relates to the field of data security technology, and in particular to a data access method and related products based on a zero-trust architecture. Background Art

[0002] Traditional cloud storage relies on a perimeter defense model, assuming the internal network is trustworthy. However, this assumption is vulnerable to insider threats, advanced persistent threats, and distributed attacks. Furthermore, with the increasing popularity of cloud computing, the distributed nature of data storage and access makes static security policies difficult to adapt to a dynamically changing environment. Traditional cloud storage's log systems are susceptible to tampering and lack dynamic response mechanisms, making them unable to meet strict compliance reviews and resulting in low data access security. Summary of the Invention

[0003] Based on the above problems, this application provides a data access method and related products based on zero-trust architecture, with the aim of improving the security of data access.

[0004] The embodiments of this application disclose the following technical solutions:

[0005] The first aspect of the present application provides a data access method based on a zero-trust architecture, including:

[0006] Obtaining multi-factor data; the multi-factor data including at least user credentials, device fingerprints, biometrics, and behavioral patterns;

[0007] Performing dynamic analysis based on the multi-factor data to obtain a trust score;

[0008] If the trust score is less than a preset threshold, an access denial instruction is issued;

[0009] If the trust score is greater than or equal to the preset threshold, generating a single access token;

[0010] The storage records of multiple sub-blocks in the blockchain are read based on the single access token, a target sub-block is determined, and the target sub-block is decrypted and reassembled to obtain the data to be accessed.

[0011] Optionally, the performing dynamic analysis based on the multi-factor data to obtain a trust score specifically includes:

[0012] A trust assessment model is used to score user credentials, device fingerprints, biometrics, and behavior patterns respectively to obtain a user credential score, a device fingerprint score, a biometric score, and a behavior pattern score; the trust assessment model is constructed based on a random forest algorithm;

[0013] The user credential score, the device fingerprint score, the biometric score, and the behavior pattern score are weighted and summed to obtain the trust score.

[0014] Optionally, the method further includes:

[0015] Get the data to be stored;

[0016] Splitting the data to be stored to obtain multiple sub-blocks;

[0017] Encrypting each sub-block to obtain multiple encrypted sub-blocks;

[0018] Multiple encrypted sub-blocks are stored in multiple clouds in a dispersed manner, and the storage record of each encrypted sub-block is stored in the blockchain.

[0019] Optionally, encrypting each sub-block to obtain multiple encrypted sub-blocks specifically includes:

[0020] Each sub-block is encrypted using the Shamir password sharing algorithm to obtain multiple encrypted sub-blocks; the encrypted sub-blocks are obtained by independent AES-256 password authentication encryption.

[0021] Optionally, the step of encrypting each sub-block to obtain multiple encrypted sub-blocks further includes:

[0022] The password corresponding to each encryption sub-block is updated regularly and dynamically.

[0023] Optionally, the method further includes:

[0024] During the access process, the user's operation behavior is recorded in real time. If abnormal behavior is detected, the user's operation behavior will be blocked and the administrator will be notified.

[0025] A second aspect of the present application provides a data access device based on a zero-trust architecture, comprising:

[0026] An acquisition module for acquiring multi-factor data; the multi-factor data includes at least user credentials, device fingerprints, biometrics, and behavioral patterns;

[0027] A scoring module, configured to perform dynamic analysis based on the multi-factor data to obtain a trust score;

[0028] A first judgment module is configured to issue an access denial instruction if the trust score is less than a preset threshold;

[0029] A second judgment module is configured to generate a single access token if the trust score is greater than or equal to the preset threshold;

[0030] The decryption and reassembly module is configured to read the storage records of multiple sub-blocks in the blockchain based on the single access token, determine the target sub-block, and perform decryption and reassembly processing on the target sub-block to obtain the data to be accessed.

[0031] The third aspect of the present application provides a computer device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data access method based on the zero-trust architecture provided in the first aspect.

[0032] The fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the data access method based on the zero-trust architecture provided in the first aspect.

[0033] The fifth aspect of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the data access method based on zero trust architecture provided in the first aspect.

[0034] Compared with the existing technology, this application has the following beneficial effects:

[0035] The present application includes obtaining multi-factor data; the multi-factor data includes at least user credentials, device fingerprints, biometrics, and behavioral patterns; performing dynamic analysis based on the multi-factor data to obtain a trust score; if the trust score is less than a preset threshold, issuing an access denial instruction; if the trust score is greater than or equal to the preset threshold, generating a single-access token; reading storage records of multiple sub-blocks in the blockchain based on the single-access token, determining a target sub-block, and decrypting and reassembling the target sub-block to obtain data to be accessed.

[0036] This application collects multi-dimensional data such as user credentials, device fingerprints, biometrics, and behavioral patterns, conducts dynamic analysis, and generates a trust score that reflects the credibility of access. The score result determines whether to grant access rights: if the score is lower than the set threshold, the access request is rejected; if the score meets the standard, a single-use temporary token is generated for this access, achieving minimized authorization and refined permission control. When accessing data, the storage location of the encrypted data sub-block is retrieved from the blockchain based on the token information, and multiple encrypted sub-blocks are decrypted and reassembled to restore the complete data content. Among them, the original data is divided into multiple sub-blocks, each encrypted with an independent key and distributed and stored in multiple cloud nodes, which improves the security of data access and enhances data confidentiality and anti-leakage capabilities. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0038] Figure 1 A data access method and related products based on a zero-trust architecture provided in an embodiment of the present application;

[0039] Figure 2 A structural diagram of a data access device based on a zero-trust architecture provided in an embodiment of the present application. DETAILED DESCRIPTION

[0040] As described earlier, current cloud storage relies on a perimeter defense model, assuming the internal network is trustworthy. However, this trust mechanism is significantly vulnerable to insider threats, advanced persistent attacks, and distributed attacks. Furthermore, with the development of cloud computing, data storage and access are becoming increasingly decentralized, making static security policies difficult to adapt to the dynamically changing usage environment. Furthermore, traditional systems' logs are easily tampered with, and the lack of effective dynamic response mechanisms makes it difficult to meet stringent compliance audit requirements, limiting overall security.

[0041] Cloud storage resources are protected through firewalls, virtual private networks (VPNs), and static access control lists (ACLs), typically assuming that all internal users and devices are trusted. However, this perimeter-based trust model cannot effectively address internal threats or compromised devices. Furthermore, because access control policies are statically configured, permissions cannot be dynamically adjusted based on user behavior or contextual information. Furthermore, with the prevalence of multi-cloud and hybrid cloud architectures, the perimeter security model is insufficient for distributed resource management and therefore cannot meet the security requirements of modern cloud storage environments.

[0042] Ensure data confidentiality through full-disk encryption, file-level encryption, or the cloud provider's built-in encryption features (such as server-side encryption). While static encryption can protect data during storage and transmission, it typically applies a unified encryption policy to all data and lacks granular control for users or scenarios. In addition, static encryption cannot prevent the leakage of sensitive data of internal users with access rights. At the same time, users are generally required to fully hand over password authentication management to the cloud provider, which also brings potential trust risks.

[0043] In view of the above problems, the present application provides a data access method and related products based on a zero-trust architecture, the method comprising: obtaining multi-factor data; the multi-factor data including at least user credentials, device fingerprints, biometrics, and behavior patterns; performing dynamic analysis based on the multi-factor data to obtain a trust score; if the trust score is less than a preset threshold, issuing an access denial instruction; if the trust score is greater than or equal to the preset threshold, generating a single-access token; reading the storage records of multiple sub-blocks in the blockchain based on the single-access token, determining the target sub-block, and decrypting and reassembling the target sub-block to obtain the data to be accessed.

[0044] The core of this application is to combine zero-trust architecture with cloud storage to propose a dynamic, distributed access control and data protection solution. Based on the principle of "never trust, always verify," zero trust addresses cloud storage security issues facing insider threats and data breaches through real-time authentication and dynamic authorization. It is suitable for enterprise and multi-cloud scenarios. By collecting heterogeneous data from multiple sources, including user credentials, device fingerprint information, biometric features, and operational behavior patterns, a multi-dimensional identity profile is constructed. Based on this profile, a dynamic assessment is performed to generate a trust score that measures the credibility of access requests. Based on this score, intelligent access decisions are made: if the score does not meet the preset security threshold, the access request is denied; if the score meets the authorization criteria, a temporary access token valid only for this access is generated, thus achieving least privilege and fine-grained access control. During the data access phase, the encrypted data sub-block storage location is located and retrieved from the blockchain based on the access token. Multiple distributed encrypted sub-blocks are then collaboratively decrypted and reassembled to restore the complete original data. Among them, the original data is divided into several sub-blocks, each sub-block is processed using an independent encryption mechanism and stored in different cloud service nodes, which effectively enhances the security of data during transmission and storage, and improves the confidentiality and anti-leakage capabilities of the system.

[0045] First, several noun terms that may be involved in the embodiments below in this application are explained.

[0046] Zero Trust Architecture: A network security model that assumes all access requests are untrusted and require real-time verification and authorization.

[0047] Dynamic Trust Score: A value calculated in real time based on multi-factor authentication to assess the trustworthiness of a user or device.

[0048] Data Sharding: A technology that divides complete data into multiple independent sub-blocks.

[0049] Single-Use Access Token: A temporary authorization credential generated for a single request, with time or scope restrictions.

[0050] Blockchain Record: Use blockchain technology to store data location and access logs to ensure that they cannot be tampered with and are traceable.

[0051] In order to help those skilled in the art better understand the present invention, the following will clearly and completely describe the technical solutions in the embodiments of the present invention in conjunction with the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of this application.

[0052] Figure 1 The present invention provides a data access method and related products based on a zero-trust architecture, such as Figure 1 As shown, data access methods based on zero trust architecture include:

[0053] S101: Acquire multi-factor data.

[0054] Multi-factor data can be set accordingly based on actual conditions. For example, multi-factor data includes at least user credentials (such as username / password, PIN code, etc.), device fingerprints (such as device unique identifier (IMEI, MAC address, browser fingerprint, etc.), used to identify whether it is a trusted device), biometrics (such as fingerprints, facial recognition, iris scanning, etc.) and behavioral patterns (such as user operating habits (typing rhythm, sliding trajectory, login time, geographic location, etc.)). Compared with traditional single-factor authentication, the use of multi-factor authentication in this application significantly improves the accuracy and security of identity recognition.

[0055] In financial scenarios, businesses need to share sensitive data (such as transaction records) across institutions or regions, but unauthorized access and leakage must be prevented. Traditional static encryption and access control cannot meet the needs of real-time verification and fine-grained authorization in dynamic collaboration. For example, when sharing data between banks, it is necessary to ensure that only specific business scenarios access specific files at specific times. Therefore, this application proposes S102: dynamic analysis based on the multi-factor data to obtain a trust score. Trust scoring based on multi-factor data prevents unauthorized access and leakage.

[0056] Specific analysis methods can be tailored to specific circumstances. For example, a machine learning model can be used to score each piece of multi-factor data to generate a trust score, or a pre-set rule engine can be used to score each piece of multi-factor data to generate a trust score. Regardless of the analysis method used, each piece of multi-factor data must serve as the foundation to ensure the relative objectivity and accuracy of the trust score. This requires continuous verification, rather than a one-time authentication process, to avoid biased information scoring.

[0057] Traditional cloud storage relies on static authentication (such as fixed passwords or certificates). This application introduces real-time multi-factor authentication (MFA) combined with machine learning models to generate a dynamic trust score. The score integrates user credentials, device fingerprints, biometrics, and behavioral patterns (such as login time and IP address), and adjusts in real time based on environmental changes. Unlike traditional methods with fixed thresholds, the scoring model can adaptively learn, for example, to identify abnormal login patterns (such as access during off-hours), improving the accuracy and flexibility of verification.

[0058] S103: If the trust score is less than a preset threshold, an access denial instruction is issued.

[0059] A threshold (e.g., 0.9) can be set based on the specific situation. For example, if a trader logs in from a branch registration terminal, their score might be 0.93. If they log in from their home network, their score drops to 0.75, triggering secondary verification (e.g., mobile OTP). A preset threshold (e.g., 90 points) can be set as the basis for determining whether to grant access. If the trust score is less than the preset threshold, a denial of access is issued. If the trust score is greater than or equal to the preset threshold, the next step is allowed, generating a single-access token. This prevents low-trust access requests from accessing sensitive resources, improving system security.

[0060] S104: If the trust score is greater than or equal to the preset threshold, a single access token is generated.

[0061] Once the trust assessment is passed, the system generates a one-time access token (such as a JWT or UUID) for subsequent data access. This token has a time limit (e.g., 5 minutes), expires after use, is not reusable, and can be tied to a specific data resource. This reduces the risk of long-term token leaks, implements the principle of least privilege, and facilitates auditing and tracking.

[0062] This application generates a single-use JWT token for each request. The scope and validity period (e.g., 20 minutes) of permissions are adjusted in real time based on dynamic trust scores and policies, replacing traditional long-term permission assignments. Minimizing permissions and using a temporary design mitigates the risk of abuse. For example, access to specific customer data is limited to a temporary period, requiring revalidation after expiration.

[0063] Data access requires strict logging and auditing, and services must provide tamper-proof logs and real-time anomaly detection capabilities. Traditional cloud storage log systems are susceptible to tampering and lack dynamic response mechanisms, making them unable to meet strict compliance reviews. Therefore, this application proposes S105: reading the storage records of multiple sub-blocks in the blockchain based on the single access token, determining the target sub-block, and decrypting and reassembling the target sub-block to obtain the data to be accessed.

[0064] S105 is primarily designed to dynamically assign permissions based on verification results and policies, limiting the scope of user operations on cloud storage resources. Tokens are used to access encrypted data stored on the blockchain. For example, data is segmented into multiple sub-blocks on the blockchain; each sub-block may be protected by a different encryption algorithm or key. The system uses token information to locate and read multiple relevant sub-block records. Blockchains are tamper-proof and traceable; the sub-block splitting mechanism enhances data privacy and facilitates permission control when multiple parties collaborate on access.

[0065] The system decrypts multiple sub-blocks (possibly requiring multi-party key collaboration), then reconstructs the original data and returns it to the user. Decryption may involve threshold cryptography or multi-signature mechanisms; data reconstructed must ensure integrity and consistency; and full data access is only possible through a complete authorization process. Even if partial data is leaked, the full content cannot be restored. This enables fine-grained data access control, improving the system's fault tolerance and anti-attack capabilities.

[0066] This application utilizes multi-factor authentication, device fingerprinting, and behavioral analysis to generate a dynamic trust score to determine user trustworthiness, improve identity verification accuracy, and reduce the risk of forgery. This dynamic trust score enables continuous verification and risk awareness. A single-use token is generated for each request, and permissions are dynamically adjusted based on policy to minimize authorization and mitigate the security risks associated with long-term credential exposure. Data is segmented into multiple sub-blocks and encrypted separately, with password authentication dynamically updated by the management service to enhance confidentiality. The encrypted sub-blocks are stored across multiple cloud nodes, with the blockchain recording their location and operations to ensure distributed security and auditability. The system monitors access behavior, using machine learning to detect anomalies, automatically rejecting suspicious requests and issuing alerts.

[0067] The above is the main technical solution of this application. Now we will introduce the expansion and implementation of the main technical solution of this application. The details are as follows:

[0068] Regarding S102 performing dynamic analysis based on the multi-factor data to obtain a trust score, the present application provides an optional embodiment:

[0069] With the escalation of cyberattack methods (such as credential theft and insider threats), businesses need a security system that can evaluate trust in real time and respond quickly. Static authentication and fixed permissions are no longer able to defend against complex attacks, prompting the introduction of dynamic trust scoring and single-time authorization mechanisms. Therefore, this application proposes to use a trust assessment model to score user credentials, device fingerprints, biometrics, and behavior patterns respectively, to obtain user credential scores, device fingerprint scores, biometric scores, and behavior pattern scores; the trust assessment model is constructed based on the random forest algorithm.

[0070] The user credential score, the device fingerprint score, the biometric score, and the behavior pattern score are weighted and summed to obtain the trust score.

[0071] This application also provides a specific embodiment:

[0072] Multi-factor authentication (MFA) collects user and device information, such as a bank trader entering their employee ID and password, and a terminal providing a hardware fingerprint (such as a MAC address). This information is then combined with the fingerprint scan and contextual data (such as the login IP address and time). These inputs are fed into a pre-trained machine learning model (based on a random forest algorithm) for comprehensive evaluation, generating a dynamic trust score (ranging from 0 to 1). The score weighting is configurable, for example, device trustworthiness accounts for 40%, behavioral consistency accounts for 35%, and biometrics accounts for 25%.

[0073] Simply put, when a trader logs in, the score calculation is completed within 500 milliseconds. If the trader passes, the next step is reached; if the trader fails, the trader is rejected or requires additional verification. The trust assessment model is updated monthly based on access logs and supports high concurrency (processing 1,000 requests per second). Data transmission is encrypted using TLS 1.3.

[0074] Enterprises are increasingly adopting multi-cloud strategies, requiring a unified protection solution to manage distributed data while maintaining high availability and fault tolerance. Existing solutions lack integrated support for data sharding, encryption, and access tracking in multi-cloud environments, making it difficult to address single points of failure or cross-platform attacks. This application proposes an optional embodiment for such situations:

[0075] Get the data to be stored.

[0076] The data to be stored is divided into multiple sub-blocks.

[0077] Each sub-block is encrypted to obtain multiple encrypted sub-blocks.

[0078] This application does not limit the encryption method. For example, each sub-block is encrypted using the Shamir password sharing algorithm to obtain multiple encrypted sub-blocks; the encrypted sub-blocks are obtained by independent AES-256 password authentication encryption.

[0079] This application combines data sharding (based on the Shamir password sharing algorithm) with multi-level encryption, with encrypted sub-blocks distributed across multiple cloud nodes (such as public, hybrid, and private clouds). Each sub-block uses independent password authentication, which is dynamically managed and regularly rotated. This overcomes the single point of risk inherent in traditional centralized encrypted storage. Even if some sub-blocks are leaked, data cannot be restored. The distributed architecture also enhances fault tolerance and adapts to the multi-regional operational needs of banks.

[0080] Multiple encrypted sub-blocks are stored in multiple clouds in a dispersed manner, and the storage record of each encrypted sub-block is stored in the blockchain.

[0081] This application utilizes a private blockchain to record data sub-block locations and access logs. Each record includes a timestamp and hash value to ensure immutability. Access requests and storage operations are logged on-chain, forming a complete audit chain. Compared to traditional logging systems, which are susceptible to tampering, blockchain provides decentralized trust and meets the strict compliance requirements of the financial sector.

[0082] In specific applications, considering the security of the password, the present application also provides an optional embodiment to regularly and dynamically update the password corresponding to each encryption sub-block.

[0083] This application also provides a specific embodiment:

[0084] Sharding and encryption protect financial data, preventing complete data leakage. Uploaded data (e.g., a 1GB file of customer transaction records) is split into multiple sub-blocks (e.g., five 200MB blocks) using the Shamir key sharing algorithm with a threshold k = 3 (recovery requires three sub-blocks). Each sub-block is encrypted using a separate AES-256 key. The key is generated by the bank's key authentication service and stored in a hardware security module (HSM). The key authentication service rotates the key every 15 days, and old key authentications are archived to support historical decryption. Sharding and encryption are performed client-side, encrypted before upload, and only the ciphertext is stored on the server. When traders upload transaction records, the client encrypts and uploads them in shards, decrypting and reassembling them upon download. Sharding supports adjustable parameters (5-10 sub-blocks); the encryption process is multi-threaded, taking approximately 2 seconds for 1GB of data. Customer account data is stored in shards and encrypted, preventing hackers from gaining access to the entire data, even if they compromise a single node, thus protecting privacy.

[0085] This application also provides a specific embodiment:

[0086] Encrypted sub-blocks are stored in a distributed manner across multiple cloud nodes to improve fault tolerance and security. Encrypted sub-blocks are distributed across multiple clouds (such as public clouds, private clouds, and hybrid clouds), and a consistent hashing algorithm is used to ensure balanced distribution. For example, five sub-blocks are stored in nodes in the United States, Europe, and Asia. The storage location and metadata (sub-block ID, URL) are recorded in a private blockchain run by a bank consortium, and each record contains a timestamp and SHA-256 hash. When data is requested, the system queries the location from the blockchain, extracts the sub-blocks, and reassembles them. When traders query data, the system reads the blockchain records, extracts the sub-blocks from multiple nodes, and returns them after reassembly. Dynamic node expansion is supported, and the hash ring automatically adjusts; the blockchain processes 500 records per second with a delay of approximately 200 milliseconds. When branch traders access headquarters data, the system extracts sub-blocks from multiple clouds. If the cloud service goes down, it can still be restored from other nodes to ensure business continuity.

[0087] Regarding the generation of a single access token in S104, this application also provides an optional embodiment:

[0088] A single-use access token is generated based on the policy. The token uses the JSON Web Token (JWT) format and contains the trader's ID, permission scope (e.g., "read only the last 30 days of client A's transactions"), expiration date (e.g., 15 minutes), and signature. It is encrypted and authenticated by the server using RSA-2048. The policy is stored in a database and supports conditional rules, such as "traders can only access clients they are responsible for" or "high-value transactions require approval." The client requests resources with the token, and the server verifies the signature and validity.

[0089] Simply put, when a trader requests data, the system generates and returns a single-use access token. Traders use this token to access data, and revalidation is required upon expiration. This token is stored in a Redis cache, with validation latency under 100 milliseconds and dynamically adjustable expiration times (5-60 minutes). Traders are granted temporary access to view client transaction records; any attempt to access other client data is denied, ensuring minimal permissions.

[0090] To further ensure security during access, this application also provides an optional embodiment:

[0091] During the access process, the user's operation behavior is recorded in real time. If abnormal behavior is detected, the user's operation behavior will be blocked and the administrator will be notified.

[0092] Monitor operations in real time, detect anomalies, and record tamper-proof logs to meet financial compliance. Record access details (trader ID, time, resource ID). Anomaly detection uses the isolation forest model to analyze behavioral patterns. For example, a trader queries multiple high-net-worth accounts in a short period of time, triggering an alarm. The alarm is pushed to the dashboard and the permissions are suspended. Logs are synchronized to the blockchain to ensure integrity, using the PBFT consensus mechanism. When traders operate, the system records them in real time. If anomalies are detected (such as batch downloads), they are immediately blocked and the administrator is notified. The log collection delay is less than 1 second, and the anomaly detection accuracy is 95%; the blockchain supports 10 years of data archiving. If a trader attempts to steal customer data, the system identifies the anomaly, automatically blocks it, and archives the log for relevant review.

[0093] This application combines distributed log collection with anomaly detection models (such as Isolation Forest) to monitor access behavior in real time. When anomalies are detected (such as bulk downloads of customer data), permissions are automatically suspended and an alert is issued. Going beyond traditional post-event audits, this proactive defense mechanism responds instantly to threats as they occur, protecting sensitive bank data from internal and external attacks.

[0094] This application provides an application embodiment:

[0095] A trader needs to query the transaction records of customer A and enter his ID and password. The terminal uploads the fingerprint and IP address. The identity verification module generates a score (0.92>0.9) and passes the verification.

[0096] The access control module generates a JWT token with the permission of "read-only customer A's transaction records" and is valid for 20 minutes.

[0097] The data fragmentation and encryption module decrypts and reconstructs the data, extracting 3 out of the 5 sub-blocks (Shamir threshold).

[0098] The distributed storage module queries the blockchain and extracts sub-blocks from the cloud service.

[0099] The monitoring and auditing module records operations. If a trader attempts to download, the system detects an anomaly, rejects the attempt, issues an alarm, and logs the attempt on the blockchain.

[0100] This application integrates zero-trust architecture and cloud storage technology, and uses dynamic trust scoring and distributed data sharding encryption as core mechanisms to build a set of high-security cloud storage solutions for modern business scenarios. Real-time identity authentication is performed for each access request, and a dynamic trust score is generated by combining multi-factor authentication and behavioral analysis to achieve fine-grained and adaptive permission control; at the same time, the original data is divided into multiple sub-blocks, each encrypted with an independent key and then distributed and stored on multiple cloud nodes, effectively preventing the risk of single-point leakage. All operation logs are recorded through the blockchain to ensure that access behaviors are traceable and cannot be tampered with, and supplemented by real-time monitoring and anomaly detection mechanisms to enhance overall defense capabilities. This application directly responds to the shortcomings of traditional cloud storage in the face of advanced threats, static policy failures, and compliance challenges, and realizes the dynamic, intelligent, and auditable process from identity authentication, access control to data protection. It is particularly suitable for industry scenarios such as finance and government affairs that have extremely high requirements for data security and compliance. For example, in bank customer information management, it can ensure the integrity and confidentiality of sensitive information such as account data and transaction records during storage and access, support data sharing and business continuity across institutions and multinational branches, have good fault tolerance and flexibility, and meet the needs of minimum permission granting, continuous risk assessment and active defense in complex business environments.

[0101] Figure 2 A structural diagram of a data access device based on a zero-trust architecture provided in an embodiment of the present application is shown as follows: Figure 2 As shown, based on the data access method based on the zero-trust architecture provided in the previous embodiment, the present application also provides a data access device based on the zero-trust architecture, including:

[0102] The acquisition module is used to obtain multi-factor data; the multi-factor data includes at least user credentials, device fingerprints, biometrics and behavioral patterns.

[0103] The scoring module is used to perform dynamic analysis based on the multi-factor data to obtain a trust score.

[0104] The first judgment module is configured to issue an access denial instruction if the trust score is less than a preset threshold.

[0105] The second judgment module is configured to generate a single access token if the trust score is greater than or equal to the preset threshold.

[0106] The decryption and reassembly module is configured to read the storage records of multiple sub-blocks in the blockchain based on the single access token, determine the target sub-block, and perform decryption and reassembly processing on the target sub-block to obtain the data to be accessed.

[0107] As an optional embodiment, the scoring module specifically includes:

[0108] The model scoring unit is used to use a trust assessment model to score user credentials, device fingerprints, biometrics and behavior patterns respectively to obtain user credential scores, device fingerprint scores, biometric scores and behavior pattern scores; the trust assessment model is constructed based on a random forest algorithm.

[0109] A weighted summation unit is configured to perform a weighted summation on the user credential score, the device fingerprint score, the biometric score, and the behavior pattern score to obtain the trust score.

[0110] As an optional embodiment, the device further includes:

[0111] The collection module is used to obtain the data to be stored.

[0112] The segmentation module is used to segment the data to be stored to obtain multiple sub-blocks.

[0113] The encryption module is used to encrypt each sub-block to obtain multiple encrypted sub-blocks.

[0114] The decentralized storage module is used to disperse and store multiple encrypted sub-blocks in multiple clouds, and store the storage record of each encrypted sub-block in the blockchain.

[0115] As an optional embodiment, the encryption module is specifically configured to:

[0116] Each sub-block is encrypted using the Shamir password sharing algorithm to obtain multiple encrypted sub-blocks; the encrypted sub-blocks are obtained by independent AES-256 password authentication encryption.

[0117] As an optional embodiment, the device further includes:

[0118] The update module is used to regularly and dynamically update the password corresponding to each encryption sub-block.

[0119] As an optional embodiment, the device further includes:

[0120] The abnormal behavior detection module is used to record the user's operation behavior in real time during the access process. If abnormal behavior is detected, the user's operation behavior will be blocked and the administrator will be notified.

[0121] An embodiment of the present application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement a data access method based on a zero-trust architecture.

[0122] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements a data access method based on a zero-trust architecture.

[0123] An embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements a data access method based on a zero-trust architecture.

[0124] It should be noted that the various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device and equipment embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments. The device and equipment embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components indicated as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment. A person of ordinary skill in the art can understand and implement it without expending creative work.

[0125] The above is merely one specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A data access method based on zero trust architecture, characterized in that: The data access method based on the zero trust architecture includes: Obtaining multi-factor data; the multi-factor data including at least user credentials, device fingerprints, biometrics, and behavioral patterns; Performing dynamic analysis based on the multi-factor data to obtain a trust score; If the trust score is less than a preset threshold, an access denial instruction is issued; If the trust score is greater than or equal to the preset threshold, generating a single access token; The storage records of multiple sub-blocks in the blockchain are read based on the single access token, a target sub-block is determined, and the target sub-block is decrypted and reassembled to obtain the data to be accessed.

2. The data access method based on zero trust architecture according to claim 1, characterized in that: The dynamic analysis based on the multi-factor data to obtain a trust score specifically includes: A trust assessment model is used to score user credentials, device fingerprints, biometrics, and behavior patterns respectively to obtain a user credential score, a device fingerprint score, a biometric score, and a behavior pattern score; the trust assessment model is constructed based on a random forest algorithm; The user credential score, the device fingerprint score, the biometric score, and the behavior pattern score are weighted and summed to obtain the trust score.

3. The data access method based on zero trust architecture according to claim 1, characterized in that: The method further comprises: Get the data to be stored; Splitting the data to be stored to obtain multiple sub-blocks; Encrypting each sub-block to obtain multiple encrypted sub-blocks; Multiple encrypted sub-blocks are stored in multiple clouds in a dispersed manner, and the storage record of each encrypted sub-block is stored in the blockchain.

4. The data access method based on zero trust architecture according to claim 3, characterized in that: The encryption process of each sub-block to obtain multiple encrypted sub-blocks specifically includes: Each sub-block is encrypted using the Shamir password sharing algorithm to obtain multiple encrypted sub-blocks; the encrypted sub-blocks are obtained by independent AES-256 password authentication encryption.

5. The data access method based on zero trust architecture according to claim 3, characterized in that: The encryption process is performed on each sub-block to obtain multiple encrypted sub-blocks, and then the following steps are further included: The password corresponding to each encryption sub-block is updated regularly and dynamically.

6. The data access method based on zero trust architecture according to claim 1, characterized in that: The method further comprises: During the access process, the user's operation behavior is recorded in real time. If abnormal behavior is detected, the user's operation behavior will be blocked and the administrator will be notified.

7. A data access device based on zero trust architecture, characterized in that: The data access device based on zero trust architecture includes: An acquisition module for acquiring multi-factor data; the multi-factor data includes at least user credentials, device fingerprints, biometrics, and behavioral patterns; A scoring module, configured to perform dynamic analysis based on the multi-factor data to obtain a trust score; A first judgment module is configured to issue an access denial instruction if the trust score is less than a preset threshold; A second judgment module is configured to generate a single access token if the trust score is greater than or equal to the preset threshold; The decryption and reassembly module is configured to read the storage records of multiple sub-blocks in the blockchain based on the single access token, determine the target sub-block, and perform decryption and reassembly processing on the target sub-block to obtain the data to be accessed.

8. A computer device comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the data access method based on a zero-trust architecture as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the data access method based on zero trust architecture described in any one of claims 1 to 6 is implemented.

10. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the data access method based on zero trust architecture described in any one of claims 1 to 6 is implemented.

Images