Private resource access method and device based on cloud platform, electronic equipment and storage medium

Abstract

The invention relates to the technical field of access protection of private resources, in particular to a private resource access method and device based on a cloud platform, electronic equipment and a storage medium. The method comprises the following steps: a tenant registers a cloud platform account and obtains a unique identifier and a key, and a user registers an account in a tenant service system and binds a tenant identity; after the registration of the tenant and the user is completed, the user logs in a tenant service system, user service Token and tenant Token authorization are obtained, and Token expiration deadline is set based on a risk awareness dynamic adjustment mechanism; after login is completed, the user carries the user service token to upload private resources to the cloud platform for storage, and the cloud platform verifies tenant Id and tenant Key of the tenant to generate a unique source Id. According to the invention, the user can directly obtain the private data resource from the cloud platform, the business application service of the tenant only needs to be authorized, and the queried private data resource does not need to pass through the business application service of the tenant.

Description

Technical Field

[0001] The present invention relates to the technical field of access protection of private resources, and in particular to a method, device, electronic device and storage medium for accessing private resources based on a cloud platform. Background Art

[0002] In the traditional cloud platform's method of accessing private resources, every time a user accesses private data resources, they must go through the tenant's business application server for transfer. This situation puts enormous network pressure on the tenant's business application service. Since this process requires all accesses to go through the business application server, during the resource access process, especially in large file transfer scenarios, all data must first be received by the business server before being forwarded to the cloud platform or user end. This not only increases the number of network hops, but also leads to excessive consumption of bandwidth resources on the server side. Especially when the concurrent access volume is large, the transmission link between the business server and the cloud platform can easily become a performance bottleneck, significantly extending the overall delay of data upload / download. The business server needs to perform computationally intensive operations such as encryption and decryption, and permission verification for each request. As the user scale expands, high-frequency request processing will lead to contention for server CPU and I / O resources, causing the single request response time to increase linearly with the increase in load, further reducing the user experience. Therefore, the present application provides a method, device and storage medium for accessing private resources based on a cloud platform. Summary of the Invention

[0003] The purpose of the present invention is to provide a method, device and storage medium for accessing private resources based on a cloud platform, so as to solve the problem proposed in the above background technology that the access to private resources of traditional cloud platforms causes huge network pressure on business servers and leads to low end-to-end response efficiency due to redundant data transfer and centralized processing.

[0004] To achieve the above objectives, the present invention provides a method for accessing private resources based on a cloud platform, comprising the following steps: S1. The tenant registers a cloud platform account, obtains a unique identifier and key, and registers an account in the tenant business system and binds the tenant identity. S2. After tenant and user registration is complete, the user logs in to the tenant business system, obtains user business token and tenant token authorization, and sets the token expiration deadline based on a risk-aware dynamic adjustment mechanism; S3. After logging in, the user uploads private resources to the cloud platform with the user business token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and performs hashing to generate the publicly exposed publicSourceId. The mapping between the sourceId and publicSourceId is encrypted and stored in the blockchain. S4. After storage is completed, the user carries the tenantId, tenant token, and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization, and queries whether the cache exists based on the tenantId and userId. S5. After reading the resources, the cloud platform and the tenant's business system proactively clear the cache of tenantId, userId, and token.

[0005] As a further improvement to this technical solution, in S2, the user logs in to the tenant business system, obtains the user business token and tenant token authorization, and sets the token expiration deadline based on a risk-aware dynamic adjustment mechanism, including the following steps: S2.1. The user submits userName and userPassword to log in to the tenant's business application service; S2.2. The business application service verifies user information, generates a user business token and a tenant token, splits the tenant token into shards, and transmits them through different channels. The user business token contains the userId, which is encrypted with the tokenKey held by the business application service itself. The tenant token contains the tenantId and basic user information, which is encrypted with the tenantKey. The tenant token contains the tenantId and basic user information. S2.3. Set the token expiration deadline based on a dynamic adjustment mechanism based on risk perception; S2.4. The business application service sends a request to the cloud platform with the tenantId, tenantKey, userId, and expiration deadline. S2.5. The cloud platform caches tenantId and userId and sets the same expiration deadline; S2.6. The business application returns the token, tenant token, user basic information, and tenantId to the user.

[0006] As a further improvement to this technical solution, in S2.2, the tenant token is split into fragments and transmitted through different channels, including the following steps: S2.21. After generating a tenant token, dynamically adjust the number of shards and the length of each shard based on the real-time system load, the risk score of the currently logged-in user, and the current network conditions. S2.22. Generate an additional biometric verification code using the biometric recognition sensor on the user device and associate the biometric verification code with the reassembly process of the token shards. S2.23. Select the Tor network as the transmission channel and transmit the token fragments through the Tor network; S2.24. Add a time watermark to each token fragment to record the time when the fragment was generated and sent. On the user device side, after receiving all fragments, first check the time watermark. If the timestamp of a fragment exceeds the time t, the fragment is considered invalid and the server is asked to resend it. During the reassembly process, the reassembly algorithm is used to sort and combine the fragments according to their content and time watermarks. S2.25. For the remaining Token fragments, they are delivered through HTTP Header and other secure backup application layer channels. At the same time, different priorities and confirmation mechanisms are set for each delivery channel.

[0007] As a further improvement to this technical solution, in S3, users upload private resources to the cloud platform with their business token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and then performs a hash process, including the following steps: S3.1. The user uploads private resources to the tenant's business application service with a token. S3.2. The tenant's business application service decrypts the token using the tokenKey, obtains the userId, and uploads private data resources to the cloud platform along with the tenantId, tenantKey, and userId. S3.3. The cloud platform verifies the tenantId and tenantKey. If verification is successful, it stores the private resource data. It then generates a sourceId for this private resource data, hashes the sourceId with a random salt value, and generates the publicly exposed publicSourceId. The mapping between the sourceId and the publicSourceId is encrypted and stored in the blockchain. The corresponding relationship between the tenantId, userId, and sourceId is also stored. The sourceId is then returned to the tenant's business application service. S3.4. The tenant's business application service stores the correspondence between sourceId and userId in the tenant's local business application service database; S3.5. The tenant's business application service returns the sourceId to the user.

[0008] As a further improvement of this technical solution, in S4, the user carries tenantId, tenant token and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocol for verification and authorization, and queries whether the cache exists based on tenantId and userId of the user, including the following steps: S4.1. The logged-in user accesses the cloud platform with tenantId, tenant token, and publicSourceId, requests the resource corresponding to sourceId, and introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization. S4.2. After verification, the cloud platform matches the tenantKey with the tenantId, then uses the tenantKey to parse the tenant token, obtain the userId, and then checks whether the cache exists based on the tenantId and userId. S4.3. If the cache exists, refresh the cache expiration time of tenantId and userId, match the resource based on sourceId, and return it; S4.4. If the cache does not exist, it means that the tenant token has expired. At this time, the user carries the token to request the tenant's business application service. The tenant's business application service uses the tokenKey to decrypt the token, obtain the userId, and then generate the tenant token. It then repeats steps S2.4 to S2.6 and steps S4.1 and S4.2 in the login process.

[0009] As a further improvement to this technical solution, in S4.1, dynamic fog computing nodes and a lightweight privacy computing verification protocol are introduced for verification and authorization, including the following steps: S4.11. Deploy fog computing nodes at the edge network. Each node stores partially encrypted tenantId+userId state shards and splits the key using the Shamir secret sharing algorithm. S4.12. The cloud platform distributes the tenant token to the fog node; S4.13. Each fog node uses the local shard key to decrypt the tenant token and verify the validity of the userId through secure multi-party computation. S4.14. After verification, the fog node generates a zero-knowledge proof to prove the validity of the user's permissions; S4.15. Call the blockchain to query the sourceId corresponding to the publicSourceId, and use fog nodes exceeding the threshold number r to collaboratively decrypt; S4.16. Dynamically decide whether to restrict access based on a dynamic adaptive risk assessment model; S4.17. After verification, the cloud platform returns the resource corresponding to sourceId and records the hash operation in the blockchain audit log.

[0010] As a further improvement of the present technical solution, in S4.16, dynamically determining whether to restrict access based on a dynamic adaptive risk assessment model includes the following steps: S4.161. When a user requests a resource, the fog node collects a multi-dimensional data stream of risk factors in real time. Risk factors include behavioral anomalies, device fingerprints, location risks, network environment, and time context. S4.162. Standardize and feature-engineer the risk factor data and input them into a multi-layer neural network model to capture the complex nonlinear relationships between risk factors and generate a high-dimensional risk feature vector. S4.163. Map the risk feature vector to a high-dimensional tensor space to construct a spatiotemporal evolving risk field: in, Representing a tensor network evolving over time; Indicates time, It represents the time dependence coefficient, reflecting the weights under different dimensions; Indicates the total dimension; Index variable representing the dimension; represents a vector; represents the weight coefficient, Indicates a time Evolution, and Dimensions related to a vector of indices, Indicates that Different vectors Perform tensor product operations; Tensor Network Map to a continuous homology complex and extract the Betti numbers: ; in, represents the risk score; Represents the weight of each order of Betti number; represents persistence in the analysis of persistent homology; S4.164, if If the value is greater than the threshold e, the access control policy is triggered.

[0011] In another aspect, the present invention provides a device for accessing private resources based on a cloud platform, the device comprising: The registration unit is used to provide the tenant with a unique identifier and key when registering a cloud platform account, and to bind the tenant identity when the user registers an account in the tenant business system; Login unit, used for dual-Token authorization after tenant and user registration is completed; The storage unit is used to generate a unique resource identifier when users upload private resources to the cloud platform for storage; The reading unit is used to verify and authorize users when reading resources from the cloud platform; The clearing unit is used to actively clear the authorization cache.

[0012] In another aspect, the present invention provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any one of the above methods when executing the program; On the other hand, the present invention provides a storage medium having a computer program stored thereon, wherein the computer program implements the steps of any of the above methods when executed by a processor.

[0013] Compared with the prior art, the present invention has the following beneficial effects: 1. In the cloud platform-based private resource access method, device, electronic device and storage medium, users can directly obtain private data resources from the cloud platform. The tenant's business application service only needs to be authorized. The queried private data resources do not need to go through the tenant's business application service, which greatly reduces the pressure on the tenant's business application server; private data resources do not require the business application service to be involved, which greatly improves the efficiency of resource acquisition.

[0014] 2. This cloud-based private resource access method, device, electronic device, and storage medium achieves a high level of security and privacy protection by implementing a dual authentication mechanism and dual token authorization, combining blockchain technology to encrypt and store resource identifier mappings, and utilizing dynamic fog computing nodes for security verification and authorization. It also incorporates a risk-aware dynamic adjustment mechanism based on multi-dimensional information such as user behavior, intelligently adjusts token validity periods and security measures, and employs a lightweight privacy computing protocol to prevent the leakage of sensitive information. Furthermore, through efficient resource management and access control strategies, it not only optimizes system response speed and resource utilization efficiency, but also ensures the transparency and immutability of data operations, providing users with a secure, reliable, and efficient cloud service experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] Figure 1 The figure is a flow chart of the overall method of the present invention. DETAILED DESCRIPTION

[0016] 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 ordinary technicians in this field without making creative efforts are within the scope of protection of the present invention.

[0017] Example 1: Please refer to Figure 1 As shown, this embodiment provides a method for accessing private resources based on a cloud platform, including the following steps: S1. The tenant registers a cloud platform account, obtains a unique identifier and key, and registers an account in the tenant's business system and binds the tenant's identity (the cloud platform provides resource hosting services for tenants, including authentication, storage, query and other functions. The cloud platform provides each tenant with a tenant service unique identifier and a corresponding tenant service key to authenticate the tenant service; the tenant pays the cloud service provider, hosts the resources to the cloud service provider, and provides application services to users at the same time; the user is the tenant's user and obtains application services from the tenant).

[0018] In this embodiment, a tenant completes registration on the cloud platform and obtains an account, thus becoming a tenant of the cloud platform. After completing registration, each tenant will obtain a tenant unique identifier tenantId and a key tenantKey; the user brings the user name, password and basic information to register the tenant's business application service account, and the business application service generates a user unique identifier userId and saves the user name, password, userId and basic information.

[0019] S2. After tenant and user registration is complete, the user logs in to the tenant business system, obtains user business token and tenant token authorization, and sets the token expiration deadline based on a risk-aware dynamic adjustment mechanism; In this embodiment, a user logs in to the tenant service system, obtains a user service token and a tenant token authorization, and sets a token expiration deadline based on a risk-aware dynamic adjustment mechanism. The following steps are included: S2.1. The user submits userName and userPassword to request to log in to the tenant's business application service.

[0020] S2.2. The business application service verifies user information, generates a user business token and a tenant token, splits the tenant token into shards, and transmits them through different channels to prevent intermediaries from intercepting them completely. The user business token contains the userId, which is encrypted with the tokenKey held by the business application service itself. The tenant token contains the tenantId and basic user information (userId, username, etc.), and the tenant is encrypted with the tenantKey. Among them, by fragmenting the token and transmitting it through different communication paths, the risk of man-in-the-middle attacks (MitM) can be significantly reduced. Even if an attacker is able to intercept some fragments, they cannot obtain the complete token information because each fragment only contains a part of the complete token information. The number and length of fragments are dynamically adjusted according to the real-time system load, user risk score and network conditions. In high-risk situations, the number of fragments is increased to improve security, and in poor network conditions, the fragment length is increased to reduce transmission overhead, thereby optimizing the balance between security and efficiency. Combined with biometric recognition sensors (fingerprint recognition), biometric verification is required every time a token fragment is received. Only after successful verification can the fragment be processed. This adds an extra layer of security to the verification process, ensuring that even if the fragments are intercepted, they cannot be used without biometric verification. Splitting the tenant token into shards and passing them through different channels includes the following steps: S2.21. After generating a tenant token, dynamically adjust the number of shards and the length of each shard based on the real-time system load, the risk score of the currently logged-in user, and the current network conditions. In this embodiment, in cases of high risk scores, the number of shards is increased to enhance security; in cases of poor network conditions, the shard length is appropriately increased to reduce transmission overhead. S2.22. Generate an additional biometric verification code using the biometric sensor on the user device (fingerprint recognition in this embodiment). This biometric verification code is associated with the token fragment reassembly process. On the user device, after all token fragments have been received and are ready for reassembly, or upon receiving the first key fragment, the user is required to perform biometric verification. Only after successful verification can the fragments be processed and reassembled. If fingerprint recognition is used, a fingerprint verification interface pops up when verification is required. Only after successful verification can the received fragments be stored in the local buffer and subsequently reassembled. S2.23. Select the Tor network as the transmission channel. The "Tor network" is a distributed anonymous network designed to enable anonymous communication. When data is transmitted in the Tor network, it undergoes multiple layers of encryption, and each node (also called a "hop") passes through it, and decrypts it one layer at a time until it reaches the target website or service. This way, even the nodes along the way cannot simultaneously know the source and destination of the communication. Transmit the token shards (preferably 1-2 token shards in this embodiment) through the Tor network. On the server side, use Tor's server interface to encapsulate the shard data into Tor data packets and send them. On the user device side, run the Tor client to receive and decrypt these shards. This can hide the actual communication path between the user and the server, making man-in-the-middle attacks more difficult. S2.24. Add a time watermark to each Token fragment, recording the time when the fragment was generated and sent. After receiving all fragments, the user device first checks the time watermark. If the timestamp of a fragment exceeds the time t (more than 5 minutes in this embodiment), the fragment is considered invalid and the server is required to resend it. During the reassembly process, a reassembly algorithm is used to sort and combine the fragments based on their content and time watermarks. The reassembly algorithm analyzes the data characteristics and time sequence information of each fragment to intelligently reconstruct the original information, rather than relying on a fixed order. This ensures accurate reassembly even if the fragment order is incorrect or delayed. S2.25. The remaining token fragments are primarily delivered via HTTP headers, optionally supplemented by other secure alternative application layer channels (such as separate HTTPS requests or secure WebSocket connections, to avoid using SMS to deliver the token content itself). Furthermore, different priorities and confirmation mechanisms are set for each delivery channel. In this embodiment, fragments delivered via HTTP headers are given higher priority. If no confirmation is received within a certain period of time, they are resent via an alternative secure application layer channel. If a fragment is too large to be delivered via HTTP headers, it is delivered via the HTTPS request body.

[0021] S2.3. Set the token expiration deadline (the sum of the tenant token generation time and the tenant token expiration time, in milliseconds) based on a risk-aware dynamic adjustment mechanism. Introduce a risk assessment platform into the existing system architecture. This platform is responsible for receiving user behavior data, device information, geographic location information, etc., and uses machine learning algorithms and models to assess risks. This platform will work closely with the authentication system and token management module to achieve dynamic adjustment of the expiration time.

[0022] The token expiration deadline is set based on a risk-aware dynamic adjustment mechanism, which includes the following steps: S2.31. Collect user login frequency characteristics, device type used by users when logging in, geographic location characteristics of users logging in, and number of failed accesses; S2.32. Build a user risk assessment model based on the collected features, train the model with historical data, and predict the risk level of each user login; S2.33. Each time a user logs in, the user risk assessment model generates a comprehensive risk score based on the current behavior data and historical behavior data. The comprehensive risk score indicates the risk level of the current login behavior. The risk score of each individual feature ( , , , ) is calculated by the corresponding sub-model or rule set based on the original feature data and normalized (mapped to the range of 0-100) for weighted summation: ; in, represents the comprehensive risk score; The risk weight representing the frequency of logins; Indicates the user's login frequency characteristic risk score; Indicates the risk weight of the equipment type; Indicates the risk score of the user's device type characteristics; Indicates the risk weight of the login geographical location; Indicates the risk score of the user's login geographic location feature; The risk weight representing the number of failed accesses; Indicates the risk score of the access failure count feature; S2.34. Mapping the Composite Risk Score to the Expiration Deadline: ; in, Indicates the expiration date of the Token; Indicates the maximum expiration deadline; Indicates the minimum expiration deadline. Indicates the comprehensive risk score the maximum value that can be achieved; S2.35. If the user's comprehensive risk score is high (for example, greater than the reference threshold a, or calculated according to the formula in S2.34), Significantly below the average level), the validity period of the Token will be shortened accordingly. According to the calculation of S2.34, the higher the comprehensive risk score, The closer (In S2.34 In the formula, when the comprehensive risk score The higher the It will get closer and closer to 1. It will get closer and closer ,therefore It will get closer and closer , and vice versa, the lower the comprehensive risk score, the closer it is to For example, if the model is assessed as low risk, the system will give a longer token expiration time (close to , for example, 24 hours); If the risk score is medium, the system will give a medium-length token expiration time (such as 4 hours), and at the same time, other security measures can be enhanced (such as adding verification codes, restricting access, etc.); If the risk score is high, the system will significantly shorten the token validity period (close to , such as 30 minutes or less) and require users to perform additional authentication (such as multi-factor authentication, identity verification, etc.).

[0023] S2.4. The business application service sends a request to the cloud platform with the tenantId, tenantKey, userId, and expiration date.

[0024] S2.5. The cloud platform caches tenantId and userId and sets the same expiration deadline.

[0025] S2.6. The business application returns the user's business token, confirmation that the tenant token has been sharded, basic user information, and tenantId to the user. The user client is responsible for receiving and reassembling the tenant token shards according to the mechanism in S2.22-S2.24.

[0026] S3. After logging in, the user uploads private resources to the cloud platform with the user business token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and performs hashing to generate the externally exposed publicSourceId. The mapping relationship between sourceId and publicSourceId is encrypted and stored in the blockchain (private data resources are the user's private data resources and can only be accessed by the current user. Others have no access unless authorized (including default authorization).

[0027] In this embodiment, a user uploads private resources to the cloud platform with a user service token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and then performs a hash process, including the following steps: S3.1. The user uploads private resources to the tenant's business application service with a token. S3.2. The tenant's business application service decrypts the token using the tokenKey, obtains the userId, and uploads private data resources (one at a time) to the cloud platform along with the tenantId, tenantKey, and userId. S3.3. The cloud platform verifies tenantId and tenantKey. After verification, it stores the private resource data. It then generates a sourceId for this private resource data, combines the sourceId with a random salt value, and performs hashing to generate the publicly exposed publicSourceId (in this embodiment, HASH(sourceId||salt)). The mapping relationship between sourceId and publicSourceId is encrypted and stored in the blockchain. Only fog nodes can decrypt it through MPC, preventing external attackers from obtaining the real resource identifier by enumerating publicSourceId. Resource access requires authorization from fog nodes, hiding the original mapping relationship. At the same time, the correspondence between tenantId, userId, and sourceId is stored, and the sourceId is returned to the tenant's business application service. S3.4. The tenant's business application service stores the correspondence between sourceId and userId in the tenant's local business application service database; S3.5. The tenant's business application service returns the sourceId to the user.

[0028] S4. After storage is completed, the user carries the tenantId, tenant token, and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization, and queries whether the cache exists based on the tenantId and the userId. In this embodiment, the user carries tenantId, tenant token, and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization, and queries whether the cache exists based on tenantId and userId. The following steps are included: S4.1. Logged-in users access the cloud platform with tenantId, tenant token, and publicSourceId, requesting the return of resources corresponding to sourceId. Dynamic fog computing nodes and lightweight privacy computing verification protocols are introduced for verification and authorization. Dynamic fog computing nodes and lightweight privacy computing verification protocols refer to an advanced computing model that utilizes distributed computing resources (fog nodes) close to users for real-time data processing and permission verification, while ensuring data security and user privacy through optimized privacy protection algorithms. Through the triple innovation of decentralized verification, fuzzy resource identification, and dynamic permission control, the cache dependency, permission rigidity, and mapping exposure problems of the original solution are solved. Dynamic fog computing nodes provide a distributed architecture to support the deployment of privacy computing protocols, while privacy computing protocols enhance the security of collaboration between fog nodes. In addition, the decentralized verification process combined with privacy protection technology can achieve secure authorization without relying on centralized caching, while reducing the attack surface. Among them, dynamic fog computing nodes and lightweight privacy computing verification protocols are introduced for verification and authorization, including the following steps: S4.11. Deploy fog computing nodes at the edge network. Each node stores a partially encrypted tenantId+userId state shard and splits the key using the Shamir secret sharing algorithm. (The principle of the Shamir secret sharing algorithm is to split the secret into multiple parts and distribute them to different participants so that the original secret can only be recovered when a sufficient number of parts are combined, thus ensuring the security and controllability of the secret.) S4.12. The cloud platform distributes the tenant token to the fog nodes, ensuring that each fog node participating in the verification process can receive the necessary tenant token; S4.13. Each fog node uses the local shard key to decrypt the tenant token and verifies the validity of the userId through secure multi-party computation (MPC) (Secure Multi-Party Computation (MPC) is a cryptographic technology that allows multiple parties to jointly complete computing tasks without disclosing their private data, ensuring data privacy and computational accuracy). This does not require exposing the full key, thus protecting data privacy and ensuring that only authorized users can access resources. S4.14. After verification, the fog node generates a zero-knowledge proof (ZKP) (a cryptographic method that allows one party to prove to another party that a statement is correct without revealing any actual information) to prove the validity of the user's permissions without revealing any keys or user information. S4.15. Call the blockchain to query the sourceId corresponding to the publicSourceId, and use fog nodes exceeding the threshold number r to collaboratively decrypt; S4.16. Dynamically decide whether to restrict access based on a dynamic adaptive risk assessment model. This model constructs nonlinear relationships among multi-dimensional risk factors and simulates the spatiotemporal evolution of the risk field through a dynamic tensor network to achieve the following: Risk factors (behavioral anomalies, device fingerprints, location risks, network environment, and time context) are no longer independent, but instead form a high-dimensional manifold structure through complex feature mapping. Risk status is assessed in real time through machine learning models, responding to environmental changes in real time. Combining fog nodes with blockchain smart contracts enables distributed risk field synchronization. Furthermore, by constructing a nonlinear correlation of multi-dimensional risk factors, the risk level of the current access request can be assessed more accurately, which includes considering the complex interaction of multiple factors such as behavioral anomalies, device fingerprints, location risks, network environment and time context; the model can collect and analyze the data stream of risk factors in real time, quickly adapt to environmental changes, and make decisions based on the latest threat intelligence to ensure timely response to potential threats; using dynamic tensor networks to simulate the spatiotemporal evolution of risk fields, it can identify the changing trends of risk patterns, warn of possible security threats in advance, and take corresponding flow control measures to prevent the occurrence or spread of attacks; unlike traditional fixed rule sets, dynamic adaptive risk assessment models allow the system to flexibly adjust strategies based on actual operating conditions. For example, when high-risk activities are detected, access control strategies such as downgraded access and secondary verification are automatically triggered, which improves the system's self-protection capabilities and flexibility in responding to emergencies; Based on the dynamic adaptive risk assessment model, dynamically decide whether to limit access, including the following steps: S4.161. When a user requests a resource, the fog node collects a multi-dimensional data stream of risk factors in real time. Risk factors include behavioral anomalies, device fingerprints, location risks, network environment, and time context. S4.162. Risk factor data is standardized and feature-engineered, and then fed into a multi-layer neural network model to capture the complex nonlinear relationships between risk factors and generate high-dimensional risk feature vectors. These feature vectors are learned by the model to dynamically reflect the interactions between risk factors and provide standardized input for subsequent dynamic risk analysis.

[0029] For example, a multi-layer perceptron (MLP) or recurrent neural network (RNN, if time series are considered) can be used to learn and output these feature vectors. The calculation process can be summarized as follows: ; in, Represents the generated risk feature vector; MLP represents the multi-layer neural network model.

[0030] S4.163. Map the risk feature vectors to a high-dimensional tensor space to construct a spatiotemporally evolving risk field. (Constructing a spatiotemporally evolving risk field means using the aforementioned tensor representation to simulate the behavior of risk factors over time and space. The resulting "risk field" is a model that describes the distribution of risks at different points in time and locations. This allows for more accurate assessment and prediction of the development trends of potential threats, allowing for the implementation of appropriate preventative measures.) in, Representing a tensor network evolving over time; Indicates time, It represents the time dependence coefficient, reflecting the weights under different dimensions; Indicates the total dimension; Index variable representing the dimension; represents a vector; represents the weight coefficient, Indicates a time Evolution, and Dimensions related to a vector of indices, Indicates that Different vectors Perform tensor product operations; Tensor Network Mapping to a continuous homology complex, extracting the Betti number, and identifying the global structural characteristics of the risk field (such as vulnerabilities and attack paths). The Betti number counts the number of "holes" in different dimensions: the 0-dimensional Betti number represents the number of connected components, the 1-dimensional Betti number represents the number of rings, the 2-dimensional Betti number represents the number of cavities, and so on: ; in, represents the risk score, which is the total risk assessment value calculated based on a series of topological invariants; Represents the weight of each order of Betti number, reflecting the importance of topological features of different dimensions, Index variable representing the dimension; represents the persistence in the analysis of persistent homology, that is, the degree to which a topological feature persists over the entire time interval. represents the upper limit of the time integration, i.e., the time window or observation period; S4.164, if When the value is greater than the threshold e, the access control policy is triggered. The access control policy includes downgraded access (limiting resource resolution or download rate), secondary verification (requiring biometric authentication), and blockchain audit actions (recording abnormal events in an unalterable ledger).

[0031] S4.17. After verification, the cloud platform returns the resource corresponding to the sourceId and records the hash operation in the blockchain audit log. Recording the hash operation in the blockchain audit log means storing the hash value of the data operation on the blockchain to create an unalterable and transparent record for subsequent audits and verification of the authenticity and integrity of these operations.

[0032] S4.2. After verification, the cloud platform matches the tenantKey with the tenantId, then uses the tenantKey to parse the tenant token, obtain the userId, and then checks whether the cache exists based on the tenantId and userId. S4.3. If the cache exists, refresh the cache expiration time of tenantId and userId (the current time plus the expiration time of the tenant token, in milliseconds), match the resource based on sourceId, and return it; S4.4. If the cache does not exist, it means that the tenant Token has expired. At this time, the user brings the token to request the tenant's business application service. The tenant's business application service uses the tokenKey to decrypt the token, obtain the userId, and then generates the tenant Token. It then repeats steps S2.4 to S2.6 and steps S4.1 and S4.2 in the login process. To prevent the Token from being expired due to the Token validity period ( ) The risk assessment mechanism may repeatedly set the authentication timeout period too short, causing users to fall into a cycle of repeated authentication failures. The system should monitor such continuous failures. If S4.4 is triggered abnormally frequently within a short period of time, mitigation measures such as temporarily setting a minimum guaranteed token validity period, increasing the authentication retry interval, or clearly notifying the user of a temporary authentication service problem after a certain number of retries are reached can be implemented to ensure service availability and user experience.

[0033] S5. After reading the resources, the cloud platform and the tenant's business system will proactively clear the cache of tenantId, userId, and token to ensure resource security. In this embodiment, the user carries a token to request the tenant's business application service. The tenant's business application service parses the token to obtain the userId, and then uses the tenantId, tenantKey and userId to request the cloud platform. The cloud platform deletes the cache of tenantId and userId, and the tenant's business application service deletes the token cache.

[0034] Embodiment 2: This embodiment provides a device for accessing private resources based on a cloud platform, the device comprising: The registration unit is used to provide the tenant with a unique identifier and key when registering a cloud platform account, and to bind the tenant identity when the user registers an account in the tenant business system; Login unit, used for dual-Token authorization after tenant and user registration is completed; The storage unit is used to generate a unique resource identifier when users upload private resources to the cloud platform for storage; The reading unit is used to verify and authorize users when reading resources from the cloud platform; The clearing unit is used to actively clear the authorization cache.

[0035] Embodiment 3: This embodiment provides an electronic device, comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any one of the above methods when executing the program; This embodiment further provides a storage medium on which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented.

[0036] The above shows and describes the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The above embodiments and descriptions are merely preferred examples of the present invention and are not intended to limit the present invention. Various changes and improvements may be made to the present invention without departing from the spirit and scope of the present invention. Such changes and improvements fall within the scope of the present invention. The scope of protection claimed in the present invention is defined by the appended claims and their equivalents.

Claims

1. A method for accessing private resources based on a cloud platform, characterized in that: The following steps are involved: S1. The tenant registers a cloud platform account, obtains a unique identifier and key, and registers an account in the tenant business system and binds the tenant identity. S2. After tenant and user registration is complete, the user logs in to the tenant business system, obtains user business token and tenant token authorization, and sets the token expiration deadline based on a risk-aware dynamic adjustment mechanism; S3. After logging in, the user uploads private resources to the cloud platform with the user business token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and performs hashing to generate the publicly exposed publicSourceId. The mapping between the sourceId and publicSourceId is encrypted and stored in the blockchain. S4. After storage is completed, the user carries the tenantId, tenant token, and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization, and queries whether the cache exists based on the tenantId and userId. S5. After reading the resources, the cloud platform and the tenant's business system proactively clear the cache of tenantId, userId, and token.

2. The method for accessing private resources based on a cloud platform according to claim 1, characterized in that: In S2, the user logs in to the tenant business system, obtains the user business token and tenant token authorization, and sets the token expiration deadline based on a risk-aware dynamic adjustment mechanism, including the following steps: S2.

1. The user submits userName and userPassword to log in to the tenant's business application service; S2.

2. The business application service verifies the user information, generates the user business token and tenant token, splits the tenant token into shards, and transmits the tenant token through different channels; The user business token contains the userId and is encrypted with the tokenKey held by the business application service itself. The tenant token contains the tenantId and basic user information and is encrypted with the tenantKey. S2.

3. Set the token expiration deadline based on a dynamic adjustment mechanism based on risk perception; S2.

4. The business application service sends a request to the cloud platform with the tenantId, tenantKey, userId, and expiration date. S2.

5. The cloud platform caches tenantId and userId and sets the same expiration deadline; S2.

6. The business application returns the token, tenant token, user basic information, and tenantId to the user.

3. The method for accessing private resources based on a cloud platform according to claim 2, wherein: In S2.2, the tenant token is split into shards and transmitted through different channels, including the following steps: S2.

21. After generating a tenant token, dynamically adjust the number of shards and the length of each shard based on the real-time system load, the risk score of the currently logged-in user, and the current network conditions. S2.

22. Generate an additional biometric verification code using the biometric recognition sensor on the user device and associate the biometric verification code with the reassembly process of the token shards. S2.

23. Select the Tor network as the transmission channel and transmit the token fragments through the Tor network; S2.

24. Add a time watermark to each token fragment to record the time when the fragment was generated and sent. On the user device side, after receiving all fragments, first check the time watermark. If the timestamp of a fragment exceeds the time t, the fragment is considered invalid and the server is asked to resend it. During the reassembly process, the reassembly algorithm is used to sort and combine the fragments according to their content and time watermarks. S2.

25. For the remaining Token fragments, they are delivered through HTTP Header and other secure backup application layer channels. At the same time, different priorities and confirmation mechanisms are set for each delivery channel.

4. The method for accessing private resources based on a cloud platform according to claim 3, wherein: In S3, users upload private resources to the cloud platform with their business token for storage. The cloud platform verifies the tenant's tenantId and tenantKey, generates a unique sourceId, combines the sourceId with a random salt value, and performs a hash process, including the following steps: S3.

1. The user uploads private resources to the tenant's business application service with a token. S3.

2. The tenant's business application service decrypts the token using the tokenKey, obtains the userId, and uploads private data resources to the cloud platform along with the tenantId, tenantKey, and userId. S3.

3. The cloud platform verifies the tenantId and tenantKey. If verification is successful, it stores the private resource data. It then generates a sourceId for this private resource data, hashes the sourceId with a random salt value, and generates the publicly exposed publicSourceId. The mapping between the sourceId and the publicSourceId is encrypted and stored in the blockchain. The corresponding relationship between the tenantId, userId, and sourceId is also stored. The sourceId is then returned to the tenant's business application service. S3.

4. The tenant's business application service stores the correspondence between sourceId and userId in the tenant's local business application service database; S3.

5. The tenant's business application service returns the sourceId to the user.

5. The method for accessing private resources based on a cloud platform according to claim 4, characterized in that: In S4, the user carries tenantId, tenant token, and publicSourceId to read resources from the cloud platform. The business system introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization, and queries whether the cache exists based on tenantId and userId. The following steps are included: S4.

1. The logged-in user accesses the cloud platform with tenantId, tenant token, and publicSourceId, requests the resource corresponding to sourceId, and introduces dynamic fog computing nodes and lightweight privacy computing verification protocols for verification and authorization. S4.

2. After verification, the cloud platform matches the tenantKey with the tenantId, then uses the tenantKey to parse the tenant token, obtain the userId, and then checks whether the cache exists based on the tenantId and userId. S4.

3. If the cache exists, refresh the cache expiration time of tenantId and userId, match the resource based on sourceId, and return it; S4.

4. If the cache does not exist, it means that the tenant token has expired. At this time, the user carries the token to request the tenant's business application service. The tenant's business application service uses the tokenKey to decrypt the token, obtain the userId, and then generate the tenant token. It then repeats steps S2.4 to S2.6 and steps S4.1 and S4.2 in the login process.

6. The method for accessing private resources based on a cloud platform according to claim 5, characterized in that: In S4.1, dynamic fog computing nodes and lightweight privacy computing verification protocols are introduced for verification and authorization, including the following steps: S4.

11. Deploy fog computing nodes at the edge network. Each node stores partially encrypted tenantId+userId state shards and splits the key using the Shamir secret sharing algorithm. S4.

12. The cloud platform distributes the tenant token to the fog node; S4.

13. Each fog node uses the local shard key to decrypt the tenant token and verify the validity of the userId through secure multi-party computation. S4.

14. After verification, the fog node generates a zero-knowledge proof to prove the validity of the user's permissions; S4.

15. Call the blockchain to query the sourceId corresponding to the publicSourceId, and use fog nodes exceeding the threshold number r to collaboratively decrypt; S4.

16. Dynamically decide whether to restrict access based on a dynamic adaptive risk assessment model; S4.

17. After verification, the cloud platform returns the resource corresponding to sourceId and records the hash operation in the blockchain audit log.

7. The method for accessing private resources based on a cloud platform according to claim 6, characterized in that: In S4.16, dynamically determining whether to restrict access based on the dynamic adaptive risk assessment model includes the following steps: S4.

161. When a user requests a resource, the fog node collects a multi-dimensional data stream of risk factors in real time. Risk factors include behavioral anomalies, device fingerprints, location risks, network environment, and time context. S4.

162. Standardize and feature-engineer the risk factor data and input them into a multi-layer neural network model to capture the complex nonlinear relationships between risk factors and generate a high-dimensional risk feature vector. S4.

163. Map the risk feature vector to a high-dimensional tensor space to construct a spatiotemporal evolving risk field: ; in, Representing a tensor network evolving over time; Indicates time, It represents the time dependence coefficient, reflecting the weights under different dimensions; Indicates the total dimension; Index variable representing the dimension; represents a vector; represents the weight coefficient, Indicates a time Evolution, and Dimensions related to a vector of indices, Indicates that Different vectors Perform tensor product operations; Tensor Network Map to a continuous homology complex and extract the Betti numbers: ； in, represents the risk score; Represents the weight of each order of Betti number; represents persistence in the analysis of persistent homology; S4.164, if If the value is greater than the threshold e, the access control policy is triggered.

8. A device for accessing private resources based on a cloud platform, characterized in that: The device comprises: The registration unit is used to provide the tenant with a unique identifier and key when registering a cloud platform account, and to bind the tenant identity when the user registers an account in the tenant business system; Login unit, used for dual-Token authorization after tenant and user registration is completed; The storage unit is used to generate a unique resource identifier when users upload private resources to the cloud platform for storage; The reading unit is used to verify and authorize users when reading resources from the cloud platform; The clearing unit is used to actively clear the authorization cache.

9. An electronic device, characterized in that: include: A memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the steps of the method according to any one of claims 1 to 7 are implemented when the processor executes the program.

10. A storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Images