Layered isolation-based sandbox development method, system and equipment and storage medium
By employing a layered, isolated sandbox development approach and dual algorithms (SM2/SM4/AES), physical isolation and field-level authorization control between the development and runtime states are achieved, resolving security and isolation issues in multi-entity data sharing and ensuring data and key security.
Patent Information
- Application Number
- CN202511859589.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-10
- Publication Date
- 2026-05-12
AI Technical Summary
Existing data sandbox technology cannot form a reliable data flow link among multiple data providers, developers, and operators, lacks a multi-entity collaborative data sharing mechanism, and traditional sandboxes have problems such as ineffective isolation between development and operation environments, high risk of sensitive information leakage, and reliance on single-point storage for key security.
A layered, isolated sandbox development approach is adopted. By constructing development configuration data, a sandbox model, and an application sandbox, physical isolation between the development and runtime states is achieved. Field-level authorization control and key management are carried out using a dual-algorithm combination encryption and decryption method of SM2 and SM4/AES.
It achieves complete isolation between development and runtime states, avoids the impact of configuration errors on production applications, ensures that sensitive data is not accessed during development, implements field-level sensitive data control and key security, and solves the problems of sensitive information leakage and key leakage in traditional sandboxes.
Smart Images
Figure CN122020635A_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of data security and privacy computing technology, specifically relating to a sandbox development method, system, device, and storage medium based on layered isolation. Background Technology
[0002] With the deepening of digital transformation, industries such as finance, social security, healthcare, government affairs, and enterprises have accumulated a wealth of high-value data resources. Effective sharing, integration, and utilization of this data would provide ample support for risk control, business decision-making, intelligent services, and innovative applications. However, in practice, data sharing commonly suffers from unclear responsibilities, uncontrollable privacy, and high costs associated with cross-entity collaboration. This leads various organizations to prefer keeping their data closed rather than opening it up in the absence of security guarantees. Data remains locked within their respective institutions for extended periods, forming typical "data silos" that severely limit the release of its value.
[0003] The concept of "data sandboxes" has emerged in the industry. However, most existing data sandbox technologies serve only a single organization and fail to establish a reliable data flow link between multiple data providers, developers, and operators, lacking a multi-entity collaborative data sharing mechanism. Furthermore, traditional sandboxes are mostly single-layered structures, meaning configuration, development, testing, and operation are all performed simultaneously in the same environment. This structure presents two significant problems: first, the development and runtime environments are not effectively isolated; errors, misconfigurations, or security vulnerabilities in the development environment can directly impact production applications; second, developers may still have access to some real data within the sandbox, failing to fundamentally avoid the risk of sensitive information leakage and thus failing to meet the high-level data security requirement of "usable but invisible."
[0004] Meanwhile, existing sandbox technologies suffer from weak data protection mechanisms. They typically use only a single algorithm to encrypt the entire data, failing to achieve field-level control or provide fine-grained authorization and dynamic access control for sensitive fields. Key management mechanisms are also inadequate, relying on single-point storage for key security; a key leak exposes the entire dataset. Furthermore, most traditional sandboxes lack trusted auditing mechanisms, relying heavily on database logs for recording key steps such as data flow, permission requests, application deployment, and service calls. These logs are easily tampered with and are difficult to use as reliable evidence in multi-party environments, failing to establish sufficient trust in data providers. Summary of the Invention
[0005] In view of the above-mentioned shortcomings of the prior art, the present invention provides a sandbox development method, system, device and storage medium based on layered isolation to solve the above-mentioned technical problems.
[0006] In a first aspect, the present invention provides a sandbox development method based on layered isolation, comprising: Obtain the raw data and construct the development configuration data based on the raw data; Based on the development configuration data, the initial sandbox is instantiated to build the sandbox model; Based on the sandbox model, a runtime environment is loaded in a trusted data space to build a physically isolated application sandbox; Controlled data access is performed based on the application sandbox, and key decryption and field decryption are configured within the application sandbox.
[0007] In one optional implementation, raw data is obtained, and development configuration data is constructed based on the raw data, including: Import the raw data from the business database into the trusted data space, and extract the field names, field types, field lengths and data source identifiers from the raw data to obtain the field data; In the trusted data space, field authorization configuration is performed on field data. The field authorization configuration includes allowed fields, authorization time limits, field sensitive attributes, encryption identifiers, and encryption algorithm types. The fields that need to be encrypted are determined based on the encryption identifier, and the encrypted fields are obtained. Based on the encryption identifier and encryption algorithm type, a random symmetric key encryptKey is generated, and the encryptKey is encrypted using a preset SM2 public key to obtain the encryption strategy; Based on the encryption policy and field authorization configuration, an authorization identifier authId is generated, and the encryption policy is associated with the authorization identifier authId to obtain the field access control rules; Development configuration data is obtained based on allowed access fields, encrypted fields, encrypted identifiers, encryption policies, and field access control rules.
[0008] In one optional implementation, based on development configuration data, an initial sandbox is instantiated to construct a sandbox model, including: Based on the allowed access fields, encrypted fields, encrypted identifiers, encryption policies, and field access control rules in the development configuration data, build the initialization configuration environment; To create a sandbox instance, allocate an isolated running container to the initial sandbox, load allowed access fields, mask unauthorized fields, and ensure that encrypted fields exist in ciphertext form. Based on sandbox instances, allowed access fields, encrypted fields, and field access control rules, coding, compilation, and testing operations are performed in an isolated runtime container to obtain development and runtime results; Based on the development and operation results, the program files, model files, runtime dependencies, and runtime parameters of the sandbox instance are encapsulated and bound to the authorization identifier authId to obtain the sandbox model associated with the authorization identifier authId.
[0009] In an optional implementation, based on a sandbox model, a runtime environment is loaded in a trusted data space to construct a physically isolated application sandbox, including: Based on the sandbox model associated with the authorization identifier authId, an application sandbox is created. The application sandbox is deployed in a physically isolated manner in the trusted data space, resulting in the application sandbox deployment environment. Based on the application sandbox deployment environment, the sandbox model is loaded. The loading process includes importing the program file, model file, runtime dependencies and runtime parameters of the sandbox model. During the loading process, the binding relationship between the sandbox model and the authorization identifier authId is maintained to obtain the runtime loading configuration. The runtime environment of the application sandbox is built based on the runtime loading configuration. The runtime environment includes the program execution environment, network isolation policy and resource allocation parameters. A unique call entry point for the sandbox model is set in the runtime environment to obtain the runtime environment configuration. Based on the runtime environment configuration, the application sandbox is physically isolated from the development sandbox, sandbox instances, and development configuration data, so that the runtime environment configuration runs independently in a trusted data space, resulting in a physically isolated application sandbox.
[0010] In an optional implementation, controlled data access is performed based on an application sandbox, and key decryption and field decryption are configured within the application sandbox, including: The application sandbox, which is based on physical isolation, receives data access requests and queries the access control rules in the field according to the authorization identifier authId in the application sandbox to obtain the access control configuration. Based on the access control configuration, determine whether the target field is an encrypted field. For encrypted fields, read the encryption policy associated with the authorization identifier authId. The encryption policy includes an encryption identifier, an encryption algorithm type, and an encryptKey encrypted with an SM2 public key to obtain decryption initialization information. Based on the decryption initialization information, the encryptKey is decrypted using a pre-set SM2 private key inside the application sandbox to obtain the decryptKey. The decryptKey exists only in the application sandbox memory, thus obtaining the key decryption result. Based on the key decryption result, the encrypted field is decrypted at the field level according to the encryption algorithm type inside the application sandbox. The field-level decryption process does not write the decrypted data to the disk or transmit it outside the application sandbox, thus obtaining the field decryption result. Based on the field decryption result, the field decryption result is merged with the access result of the unencrypted field to form a controlled data access result. This controlled data access result is used in the isolated environment of the application sandbox and prevents the controlled data access result from flowing back to the development sandbox or sandbox instance.
[0011] In an optional implementation, the method further includes: performing an encryption step, comprising: Based on the field access control rules, the original data corresponding to the encrypted field is encrypted at the field level using a symmetric encryption algorithm, including SM4 or AES, to obtain the field ciphertext. Based on the field ciphertext, the encryptKey used for symmetric encryption is asymmetrically encrypted using the SM2 public key to obtain the key encryption result; Based on the key encryption result, the field ciphertext and the key encryption / decryption result are written into the development configuration data and sandbox instance to obtain the development-state ciphertext storage structure; Based on the development-mode ciphertext storage structure, only the ciphertext and encryption policy of the fields are allowed to be accessed in the development mode, while the decryptKey or plaintext of the fields are not allowed to be accessed, thus obtaining the development-mode field access restriction configuration.
[0012] In an optional implementation, the method further includes: performing a decryption step, comprising: Based on the development-state ciphertext storage structure, the key encryption result and field ciphertext are obtained within the application sandbox according to the authorization identifier authId, thus obtaining the runtime decryption preparation information; Based on the runtime decryption preparation information, the encryptKey is decrypted using a pre-set SM2 private key inside the application sandbox to obtain the decryptKey. The decryptKey is then written into the session memory of the application sandbox to obtain the runtime key information. Based on the runtime key information, the field ciphertext is decrypted at the field level according to the corresponding symmetric encryption algorithm to obtain the field decryption result; Based on the field decryption results, the plaintext of the fields is used for model inference, algorithm execution, and business processing within the application sandbox without being written to disk, logged, or cached in persistent space, thus obtaining controlled field usage results; Based on the controlled field usage results, the memory of decryptKey and field decryption results is cleared at the end of the session to obtain the session cleanup result.
[0013] Secondly, the present invention provides a sandbox development system based on layered isolation, comprising: The configuration data building module is used to obtain raw data and build development configuration data based on the raw data; The sandbox model building module is used to instantiate the initial sandbox and build the sandbox model based on the development configuration data. The application sandbox building module is used to load the runtime environment in the trusted data space based on the sandbox model and build a physically isolated application sandbox. The decryption configuration module is used to perform controlled data access based on the application sandbox and to configure key decryption and field decryption within the application sandbox.
[0014] Thirdly, a device is provided, comprising: Memory is used to store sandbox development programs based on hierarchical isolation; A processor is configured to implement the steps of the layered isolation-based sandbox development method provided in the first aspect when executing the layered isolation-based sandbox development program.
[0015] Fourthly, a computer-readable storage medium is provided, on which a layered isolation-based sandbox development program is stored, wherein when the layered isolation-based sandbox development program is executed by a processor, the steps of the layered isolation-based sandbox development method provided in the first aspect are implemented.
[0016] The beneficial effects of the present invention are that the layered isolation sandbox development method, system, device and storage medium provided by the present invention completely isolate the development state from the runtime state through the layered structure formed by development configuration data, sandbox instances, sandbox models and application sandboxes. This avoids the risk of production applications being directly affected by configuration errors, debugging operations or code defects in traditional single-layer sandboxes, and at the same time avoids developers from coming into contact with real data during the development process.
[0017] By configuring combinations of allowed access fields, encrypted fields, encryption identifiers, encryption algorithm types, and authorization identifiers (authId), sensitive data control at the field level is achieved. This allows for finer-grained data usage control, moving from overall table-wide control to single-field control, overcoming the limitations of existing technologies that can only perform overall encryption and cannot authorize data at the field level. By employing a dual-algorithm composite encryption and decryption method using SM2 and SM4 / AES, the encryptKey is encrypted with SM2, and the field content is encrypted with a symmetric encryption algorithm. Memory-level dynamic decryption is then performed within the runtime application sandbox, solving the problem of traditional sandboxes using only a single encryption algorithm, where a key leak results in complete data loss.
[0018] By loading the SM2 private key within the application sandbox and performing decryptKey decryption, field-level decryption, and memory cleanup upon session termination in the session memory, the plaintext keys and fields generated during the decryption process exist only in the session memory of the application sandbox and are removed after the session ends. This ensures that sensitive data is no longer retained after the session ends, thus creating a cleanup state for the current session and ensuring that it will not be accessed in subsequent sessions or other modules.
[0019] Furthermore, the design principle of this invention is reliable, the structure is simple, and it has a very wide range of application prospects. Attached Figure Description
[0020] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0021] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.
[0022] Figure 2 This is a schematic flowchart of a method according to another embodiment of the present invention.
[0023] Figure 3 This is a schematic flowchart of a method according to another embodiment of the present invention.
[0024] Figure 4 This is a schematic flowchart of a method according to another embodiment of the present invention.
[0025] Figure 5 This is a schematic block diagram of a system according to an embodiment of the present invention.
[0026] Figure 6 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation
[0027] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.
[0028] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.
[0029] The layered isolation-based sandbox development method provided in this embodiment of the invention is executed by a computer device, and correspondingly, the layered isolation-based sandbox development system runs on the computer device.
[0030] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The implementing entity can be a sandbox development system based on layered isolation. Depending on different requirements, the order of steps in this flowchart can be changed, and some can be omitted.
[0031] like Figure 1 As shown, the method includes: S1. Obtain raw data and construct development configuration data based on the raw data.
[0032] S2. Based on the development configuration data, instantiate the initial sandbox and build the sandbox model.
[0033] S3. Based on the sandbox model, load the runtime environment in the trusted data space and build a physically isolated application sandbox.
[0034] S4. Perform controlled data access based on the application sandbox, and configure key decryption and field decryption within the application sandbox.
[0035] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.
[0036] Obtain the raw data and construct the development configuration data based on the raw data, including: The raw data is imported from the business database into the trusted data space. Field names, field types, field lengths, and data source identifiers are extracted to obtain field data. Field authorization configurations are then performed on the field data within the trusted data space. These configurations include allowed access fields, authorization time limits, field sensitivity attributes, encryption identifiers, and encryption algorithm types. Fields requiring encryption are determined based on the encryption identifiers to obtain encrypted fields. A random symmetric key, `encryptKey`, is generated based on the encryption identifier and encryption algorithm type, and encrypted using a pre-set SM2 public key to obtain an encryption policy. An authorization identifier, `authId`, is generated based on the encryption policy and field authorization configurations, and the encryption policy is associated with the `authId` to obtain field access control rules. Finally, development configuration data is obtained based on the allowed access fields, encrypted fields, encryption identifiers, encryption policies, and field access control rules.
[0037] Specifically, the data provider first logs into the Trusted Data Space and imports raw data from the business database into the Trusted Data Space through the data import portal provided by the system. During the import process, the system automatically parses the data table structure, extracts field names, field types, field lengths, and data source identifiers, forming configurable field data, making the data manageable immediately after entering the system. Subsequently, the data provider sets field authorization configurations item by item in the field management interface, including selecting allowed fields, configuring authorization time limits, marking sensitive field attributes, and setting encryption identifiers and encryption algorithm types for fields that need protection, ensuring that the fields have field-level controlled characteristics before entering subsequent development steps. The system determines the fields that need encryption processing based on the encryption identifiers, obtains the encrypted fields, and generates a random symmetric key encryptKey based on the encryption identifiers and encryption algorithm types. At the same time, it calls the pre-set SM2 public key in the Trusted Data Space to encrypt encryptKey, generating the corresponding encryption policy, so that the field encryption process is completed internally by the system using a dual-algorithm approach. Subsequently, the system generates an authorization identifier authId based on the encryption policy and field authorization configuration, and combines the encryption policy with the authorization identifier authId. By associating fields, access control rules are formed, enabling subsequent sandbox instances to automatically match the corresponding access scope and encryption policy based on the authId when accessing fields. Finally, the system generates development configuration data based on allowed access fields, encrypted fields, encryption identifiers, encryption policies, and field access control rules, and writes the development configuration data into the data directory area of the trusted data space as the basic configuration for subsequent development sandboxes and sandbox instance loading, thereby ensuring that the development process always takes place within a controlled data scope.
[0038] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.
[0039] like Figure 2 As shown, based on the development configuration data, the initial sandbox is instantiated, and a sandbox model is constructed, including: Based on the allowed access fields, encrypted fields, encrypted identifiers, encryption policies, and field access control rules in the development configuration data, an initial configuration environment is constructed. An isolated runtime container is allocated to the initial sandbox, allowed access fields are loaded, unauthorized fields are masked, and encrypted fields are stored in ciphertext form to obtain a sandbox instance. Based on the sandbox instance, allowed access fields, encrypted fields, and field access control rules, coding, compilation, and testing operations are performed in the isolated runtime container to obtain development and runtime results. Based on the development and runtime results, the program files, model files, runtime dependencies, and runtime parameters of the sandbox instance are encapsulated and bound to the authorization identifier authId to obtain a sandbox model associated with the authorization identifier authId.
[0040] Specifically, after developers create an initial sandbox in the trusted data space, they first load the aforementioned development configuration data. The system automatically generates an initial configuration environment based on the allowed access fields, encrypted fields, encryption identifiers, encryption policies, and field access control rules in the development configuration data. This ensures that the initial sandbox has constraints on field-level access scope and ciphertext processing scope from the creation stage. Subsequently, the system allocates an isolated running container for the initial sandbox and starts the container. During container startup, allowed access fields are loaded into the container's data access layer, unauthorized fields are configured as inaccessible, and encrypted fields are written into the container's internal data structure in ciphertext form. Based on the region, the initial sandbox maintains an encrypted state when processing data in development mode, preventing the exposure of plaintext fields. After the container runs stably, developers perform coding, compilation, and testing operations in the isolated runtime container. The system constrains the coding and debugging process according to allowed access fields, encrypted fields, and field access control rules, recording code execution results, test data, and model files to form development and runtime results, ensuring the entire development process is controlled within the isolated environment. After the development and runtime results are generated, the system encapsulates the program files, model files, runtime dependencies, and runtime parameters in the sandbox instance and binds them to the authorization identifier authId to obtain a sandbox model associated with the authorization identifier authId. This sandbox model is then written to the model management area of the trusted data space, enabling subsequent application sandboxes to load and run based on this model in the isolated environment.
[0041] In one embodiment of the present invention, based on step S3, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.
[0042] like Figure 3 As shown, based on the sandbox model, a runtime environment is loaded in a trusted data space to construct a physically isolated application sandbox, including: An application sandbox is created based on the sandbox model associated with the authorization identifier authId. This application sandbox is deployed in a physically isolated manner within a trusted data space, resulting in the application sandbox deployment environment. The sandbox model is loaded based on this deployment environment. The loading process includes importing the sandbox model's program files, model files, runtime dependencies, and runtime parameters, while maintaining the binding relationship between the sandbox model and the authorization identifier authId, resulting in the runtime loading configuration. The application sandbox's runtime environment is constructed based on this configuration. This runtime environment includes a program execution environment, network isolation policies, and resource allocation parameters. A unique call entry point for the sandbox model is set within the runtime environment, resulting in the runtime environment configuration. Based on this runtime environment configuration, the application sandbox is physically isolated from the development sandbox, sandbox instances, and development configuration data, allowing the runtime environment configuration to run independently within the trusted data space, resulting in a physically isolated application sandbox.
[0043] Specifically, the operator first selects a sandbox model associated with the authorization identifier authId in the trusted data space, and creates an application sandbox through the system's application management interface. During the creation process, the system deploys the application sandbox to an independent running area in the trusted data space in a physically isolated manner, forming an application sandbox deployment environment. This keeps the application sandbox separate from the development process, thus preventing development-state files from directly entering the runtime state. Subsequently, the system loads the sandbox model according to the application sandbox deployment environment. During the loading process, the program files, model files, runtime dependencies, and runtime parameters of the sandbox model are imported sequentially, while maintaining the binding relationship between the sandbox model and the authorization identifier authId during the import process, forming a runtime loading configuration, enabling the application sandbox to operate based on the authorization identifier authId. The system executes subsequent tasks within the corresponding authorized scope. It continues to build the application sandbox's runtime environment based on the runtime configuration. This environment includes the program execution environment, network isolation policies, and resource allocation parameters. Within this environment, a unique entry point for calling the sandbox model is set, ensuring the application sandbox's runtime scope and external access paths remain controllable. After the runtime environment is built, the system physically isolates the application sandbox from the development sandbox, sandbox instances, and development configuration data based on the runtime environment configuration. This allows the application sandbox to run independently in a trusted data space, ensuring that the runtime environment can use the sandbox model while preventing the runtime environment from accessing any content in the development environment. This forms a physically isolated application sandbox and keeps the runtime process within a controlled scope.
[0044] In one embodiment of the present invention, based on step S4, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.
[0045] like Figure 4 As shown, controlled data access is performed based on the application sandbox, and key decryption and field decryption are configured within the application sandbox, including: The application sandbox, based on physical isolation, receives data access requests. It queries the field access control rules based on the authorization identifier `authId` within the sandbox to obtain the access control configuration. Based on the access control configuration, it determines whether the target field is an encrypted field. For encrypted fields, it reads the encryption policy associated with the authorization identifier `authId`. This encryption policy includes an encryption identifier, an encryption algorithm type, and an `encryptKey` encrypted with an SM2 public key, obtaining decryption initialization information. Based on this decryption initialization information, it decrypts the `encryptKey` using a pre-set SM2 private key within the application sandbox to obtain the `decryptKey`. The key decryption result exists only in the application sandbox memory. Based on the key decryption result, the encrypted field is decrypted at the field level according to the encryption algorithm type inside the application sandbox. The field-level decryption process does not write the decrypted data to the disk or transmit it outside the application sandbox, thus obtaining the field decryption result. Based on the field decryption result, the field decryption result is merged with the access result of the unencrypted field to form a controlled data access result. This allows the controlled data access result to be used in the isolated environment of the application sandbox and prevents the controlled data access result from flowing back to the development sandbox or sandbox instance.
[0046] Specifically, the application sandbox receives data access requests initiated by users or applications in an independent operating area. Upon receiving the request, the system first queries the field access control rules based on the authorization identifier authId in the application sandbox to obtain the access control configuration, ensuring that subsequent data processing remains within the authorized scope. The system then determines whether the target field is an encrypted field based on the access control configuration. For encrypted fields, the system reads the encryption identifier, encryption algorithm type, and encryptKey encrypted with the SM2 public key from the encryption policy associated with the authorization identifier authId, forming decryption initialization information. Subsequently, the system calls the pre-set SM2 private key within the application sandbox to decrypt the encryptKey, obtaining the decryptKey, and writes the decryptKey into the application sandbox's session memory, ensuring that the decryptKey does not appear outside the runtime environment, thus maintaining the isolation between the key and field data during processing. The system then uses the decryptKey... According to the encryption algorithm type, the encrypted field is decrypted at the field level. The field-level decryption is performed inside the application sandbox and the decrypted data is not written to disk, logged, or cached in persistent space, so that the plaintext of the field is only used in the memory of the current session. The system merges the field decryption result with the access result of the unencrypted field inside the application sandbox to form a controlled data access result. The access result is used in the physically isolated application sandbox. By not returning the decrypted content to the development sandbox or sandbox instance, the data processing process is kept within a controlled range and no backflow occurs, thereby ensuring that the data access link is stable within the application sandbox isolation environment.
[0047] In one possible implementation, it further includes: The steps to perform encryption include: Based on field access control rules, the original data corresponding to the encrypted field is encrypted at the field level using a symmetric encryption algorithm, including SM4 or AES, to obtain the field ciphertext. Based on the field ciphertext, the encryptKey used for symmetric encryption is asymmetrically encrypted using an SM2 public key to obtain the key encryption result. Based on the key encryption result, the field ciphertext and the key encryption / decryption result are written into the development configuration data and the sandbox instance to obtain the development-state ciphertext storage structure. Based on the development-state ciphertext storage structure, only the field ciphertext and encryption policy are allowed to be accessed in the development state, while access to the decryptKey or the field plaintext is not allowed, thus obtaining the development-state field access restriction configuration.
[0048] Specifically, after receiving the raw data uploaded by the data provider in the trusted data space, the system automatically identifies the encrypted fields that need to be encrypted according to the field access control rules, and calls the system's built-in symmetric encryption module to perform field-level encryption on the raw data corresponding to the encrypted fields according to the encryption algorithm type, including SM4 or AES. After encryption, the field ciphertext is obtained, so that the field content exists in ciphertext form before entering the development process. The system further calls the encryptKey used for symmetric encryption to perform asymmetric encryption operation on the SM2 public key preset in the trusted data space to generate a key encryption result, and writes the field ciphertext and the key encryption result together into the development configuration data and sandbox instance, so that the development state always processes encrypted fields in ciphertext form in subsequent operations. Subsequently, based on the above-mentioned development state ciphertext storage structure, the system only opens the read permission of the field ciphertext and encryption policy in the development state, and blocks decryptKey. The access paths to plaintext fields are configured to restrict field access in development mode. This ensures that the development environment can only access encrypted data during loading, debugging, and code execution, thus keeping data isolated and controlled during development and preventing the exposure of plaintext fields.
[0049] In one possible implementation, it further includes: The steps to perform decryption include: Based on the development-state encrypted storage structure, within the application sandbox, the key encryption result and field ciphertext are obtained according to the authorization identifier authId, thus obtaining runtime decryption preparation information. Based on the runtime decryption preparation information, within the application sandbox, the encryptKey is decrypted using a pre-set SM2 private key to obtain the decryptKey. The decryptKey is written to the application sandbox's session memory, thus obtaining runtime key information. Based on the runtime key information, the field ciphertext is decrypted at the field level according to the corresponding symmetric encryption algorithm, thus obtaining the field decryption result. Based on the field decryption result, within the application sandbox, the plaintext field is used for model inference, algorithm execution, and business processing, without being written to disk, logged, or cached in persistent space, thus obtaining controlled field usage results. Based on the controlled field usage results, at the end of the session, the decryptKey and field decryption results are cleared from memory, thus obtaining the session cleanup result.
[0050] Specifically, upon receiving a data access command, the application sandbox first reads the key encryption result and field ciphertext associated with the authorization identifier authId within the application sandbox according to the development-state ciphertext storage structure, generating runtime decryption preparation information to ensure that subsequent processing is performed only in the isolated environment of the application sandbox. The system then uses the runtime decryption preparation information to call the pre-set SM2 private key within the application sandbox to decrypt the encryptKey, obtaining the decryptKey, and then sets the decryptKey... The key is written to the application sandbox's session memory, ensuring it remains in memory throughout the entire process. Subsequently, the system uses the runtime key information to call the corresponding symmetric encryption algorithm to perform field-level decryption of the ciphertext, generating a field decryption result. This decryption operation is not written to disk, logged, or cached in persistent space, ensuring the plaintext exists only in the current session's memory. The system continues to use the field decryption result within the application sandbox for model inference, algorithm execution, and business processing, combining it with the access results of unencrypted fields to form controlled field usage results. This keeps the plaintext data processing within the application sandbox's isolated environment. At the end of the session, the system triggers a memory cleanup process based on the controlled field usage results, overwriting and clearing both `decryptKey` and the field decryption result. This ensures the decrypted data is not retained in the application sandbox's memory after the session ends, keeping data processing activities under control and preventing any backflow to the development sandbox or sandbox instance.
[0051] In some embodiments, the layered isolation-based sandbox development system may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the layered isolation-based sandbox development system may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) Features developed based on a layered, isolated sandbox.
[0052] In this embodiment, the sandbox development system based on hierarchical isolation can be divided into multiple functional modules according to the functions it performs, such as... Figure 5 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.
[0053] The configuration data building module is used to obtain raw data and build development configuration data based on the raw data; The sandbox model building module is used to instantiate the initial sandbox and build the sandbox model based on the development configuration data. The application sandbox building module is used to load the runtime environment in the trusted data space based on the sandbox model and build a physically isolated application sandbox. The decryption configuration module is used to perform controlled data access based on the application sandbox and to configure key decryption and field decryption within the application sandbox.
[0054] Figure 6 The layered isolation-based sandbox development method provided in this application embodiment can be applied to devices. Those skilled in the art will understand that the device structures involved in the embodiments of this invention do not constitute a limitation on the device; a device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workbenches, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.
[0055] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.
[0056] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.
[0057] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.
[0058] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.
[0059] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.
[0060] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.
[0061] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.
[0062] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.
[0063] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.
[0064] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.
[0065] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.
Claims
1. A sandbox development method based on hierarchical isolation, characterized in that, include: Obtain the raw data and construct the development configuration data based on the raw data; Based on the development configuration data, the initial sandbox is instantiated to build the sandbox model; Based on the sandbox model, a runtime environment is loaded in a trusted data space to build a physically isolated application sandbox; Controlled data access is performed based on the application sandbox, and key decryption and field decryption are configured within the application sandbox.
2. The method according to claim 1, characterized in that, Obtain the raw data and construct the development configuration data based on the raw data, including: Import the raw data from the business database into the trusted data space, and extract the field names, field types, field lengths and data source identifiers from the raw data to obtain the field data; In the trusted data space, field authorization configuration is performed on field data. The field authorization configuration includes allowed fields, authorization time limits, field sensitive attributes, encryption identifiers, and encryption algorithm types. The fields that need to be encrypted are determined based on the encryption identifier, and the encrypted fields are obtained. Based on the encryption identifier and encryption algorithm type, a random symmetric key encryptKey is generated, and the encryptKey is encrypted using a preset SM2 public key to obtain the encryption strategy; Based on the encryption policy and field authorization configuration, an authorization identifier authId is generated, and the encryption policy is associated with the authorization identifier authId to obtain the field access control rules; Development configuration data is obtained based on allowed access fields, encrypted fields, encrypted identifiers, encryption policies, and field access control rules.
3. The method according to claim 2, characterized in that, Based on the development configuration data, the initial sandbox is instantiated, and a sandbox model is built, including: Based on the allowed access fields, encrypted fields, encrypted identifiers, encryption policies, and field access control rules in the development configuration data, build the initialization configuration environment; To create a sandbox instance, allocate an isolated running container to the initial sandbox, load allowed access fields, mask unauthorized fields, and ensure that encrypted fields exist in ciphertext form. Based on sandbox instances, allowed access fields, encrypted fields, and field access control rules, coding, compilation, and testing operations are performed in an isolated runtime container to obtain development and runtime results; Based on the development and operation results, the program files, model files, runtime dependencies, and runtime parameters of the sandbox instance are encapsulated and bound to the authorization identifier authId to obtain the sandbox model associated with the authorization identifier authId.
4. The method according to claim 3, characterized in that, Based on the sandbox model, a runtime environment is loaded in a trusted data space to build a physically isolated application sandbox, including: Based on the sandbox model associated with the authorization identifier authId, an application sandbox is created. The application sandbox is deployed in a physically isolated manner in the trusted data space, resulting in the application sandbox deployment environment. Based on the application sandbox deployment environment, the sandbox model is loaded. The loading process includes importing the program file, model file, runtime dependencies and runtime parameters of the sandbox model. During the loading process, the binding relationship between the sandbox model and the authorization identifier authId is maintained to obtain the runtime loading configuration. The runtime environment of the application sandbox is built based on the runtime loading configuration. The runtime environment includes the program execution environment, network isolation policy and resource allocation parameters. A unique call entry point for the sandbox model is set in the runtime environment to obtain the runtime environment configuration. Based on the runtime environment configuration, the application sandbox is physically isolated from the development sandbox, sandbox instances, and development configuration data, so that the runtime environment configuration runs independently in a trusted data space, resulting in a physically isolated application sandbox.
5. The method according to claim 4, characterized in that, Controlled data access is performed based on the application sandbox, and key decryption and field decryption are configured within the application sandbox, including: The application sandbox, which is based on physical isolation, receives data access requests and queries the access control rules in the field according to the authorization identifier authId in the application sandbox to obtain the access control configuration. Based on the access control configuration, determine whether the target field is an encrypted field. For encrypted fields, read the encryption policy associated with the authorization identifier authId. The encryption policy includes an encryption identifier, an encryption algorithm type, and an encryptKey encrypted with an SM2 public key to obtain decryption initialization information. Based on the decryption initialization information, the encryptKey is decrypted using a pre-set SM2 private key inside the application sandbox to obtain the decryptKey. The decryptKey exists only in the application sandbox memory, thus obtaining the key decryption result. Based on the key decryption result, the encrypted field is decrypted at the field level according to the encryption algorithm type inside the application sandbox. The field-level decryption process does not write the decrypted data to the disk or transmit it outside the application sandbox, thus obtaining the field decryption result. Based on the field decryption result, the field decryption result is merged with the access result of the unencrypted field to form a controlled data access result. This controlled data access result is used in the isolated environment of the application sandbox and prevents the controlled data access result from flowing back to the development sandbox or sandbox instance.
6. The method according to claim 5, characterized in that, Also includes: The steps to perform encryption include: Based on the field access control rules, the original data corresponding to the encrypted field is encrypted at the field level using a symmetric encryption algorithm, including SM4 or AES, to obtain the field ciphertext. Based on the field ciphertext, the encryptKey used for symmetric encryption is asymmetrically encrypted using the SM2 public key to obtain the key encryption result; Based on the key encryption result, the field ciphertext and the key encryption / decryption result are written into the development configuration data and sandbox instance to obtain the development-state ciphertext storage structure; Based on the development-mode ciphertext storage structure, only the ciphertext and encryption policy of the fields are allowed to be accessed in the development mode, while the decryptKey or plaintext of the fields are not allowed to be accessed, thus obtaining the development-mode field access restriction configuration.
7. The method according to claim 5, characterized in that, Also includes: The steps to perform decryption include: Based on the development-state ciphertext storage structure, the key encryption result and field ciphertext are obtained within the application sandbox according to the authorization identifier authId, thus obtaining the runtime decryption preparation information; Based on the runtime decryption preparation information, the encryptKey is decrypted using a pre-set SM2 private key inside the application sandbox to obtain the decryptKey. The decryptKey is then written into the session memory of the application sandbox to obtain the runtime key information. Based on the runtime key information, the field ciphertext is decrypted at the field level according to the corresponding symmetric encryption algorithm to obtain the field decryption result; Based on the field decryption results, the plaintext of the fields is used for model inference, algorithm execution, and business processing within the application sandbox without being written to disk, logged, or cached in persistent space, thus obtaining controlled field usage results; Based on the controlled field usage results, the memory of decryptKey and field decryption results is cleared at the end of the session to obtain the session cleanup result.
8. A sandbox development system based on hierarchical isolation, characterized in that, include: The configuration data building module is used to obtain raw data and build development configuration data based on the raw data; The sandbox model building module is used to instantiate the initial sandbox and build the sandbox model based on the development configuration data. The application sandbox building module is used to load the runtime environment in the trusted data space based on the sandbox model and build a physically isolated application sandbox. The decryption configuration module is used to perform controlled data access based on the application sandbox and to configure key decryption and field decryption within the application sandbox.
9. A device, characterized in that, include: Memory is used to store sandbox development programs based on hierarchical isolation; A processor, configured to implement the steps of the layered isolation-based sandbox development method as described in any one of claims 1-7 when executing the layered isolation-based sandbox development program.
10. A computer-readable storage medium storing a computer program, characterized in that, The readable storage medium stores a sandbox development program based on hierarchical isolation, which, when executed by a processor, implements the steps of the sandbox development method based on hierarchical isolation as described in any one of claims 1-7.