Data management method and system of zero trust security container

Abstract

The present disclosure provides a data management method of a zero-trust security container, comprising: generating a zero-trust security policy according to a scene; constructing a data pool of the zero-trust security container; adopting the zero-trust security policy for data to be accessed in or out of the data pool, wherein the data to be accessed in or out of the data pool is admitted only after being verified according to the zero-trust security policy; and hierarchically isolating data in the data pool based on the zero-trust security policy, so that the data in the data pool can be read directionally.

Description

Technical Field

[0001] This disclosure primarily concerns the security of mini-programs, particularly the security of mini-program containers. Background Technology

[0002] Currently, a large number of internet users are using mini-programs. However, with the explosive growth in the number of mini-programs, their security risks are gradually emerging. Improper use of mini-program APIs, vulnerabilities in business logic interactions with third-party servers, and lax server data verification can all lead to data leaks.

[0003] Security has become the biggest challenge for users of container technology and business migration to the cloud, with data security being the most prominent issue. In recent years, the number of data breaches and the amount of data leaked have increased rapidly.

[0004] Therefore, there is a need in this field for a solution that can efficiently and strictly control the data of mini-program containers. Summary of the Invention

[0005] To address the aforementioned technical issues, this disclosure provides a data management solution for zero-trust secure containers. This solution can construct a data pool for zero-trust secure containers, not only verifying data entering and leaving the data pool based on zero-trust security policies, but also isolating data within the data pool according to zero-trust security policies, thereby achieving strict control over the data of the mini-program container.

[0006] In one embodiment of this disclosure, a data management method for a zero-trust secure container is provided, comprising: generating a zero-trust security policy based on a scenario; constructing a data pool for the zero-trust secure container; applying a zero-trust security policy to data entering or leaving the data pool, wherein data entering or leaving the data pool is only allowed entry or exit after verification according to the zero-trust security policy; and isolating data within the data pool in a hierarchical manner based on the zero-trust security policy, so that data within the data pool can be read in a targeted manner.

[0007] In another embodiment of this disclosure, the zero-trust security strategy includes not trusting any data reader or writer.

[0008] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source of data to be written to the data pool; and admitting data whose source has been verified, wherein the admitted data is labeled with a source tag.

[0009] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source and the role of the data writer for data to be written to the data pool; and admitting data whose roles of the source and the data writer are verified, wherein the admitted data is labeled with a source tag and a role tag of the data writer.

[0010] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source provided by the data reader, the role of the data writer, and the role of the data reader for data to be read from the data pool; and allowing data whose source, role of the data writer, and role of the data reader have been verified.

[0011] In yet another embodiment of this disclosure, the hierarchical isolation of data within the data pool according to a zero-trust security policy includes isolating the data pool into multiple data domains.

[0012] In another embodiment of this disclosure, isolating the data pool into multiple data domains includes isolating data into multiple data domains according to sensitive data and runtime data.

[0013] In another embodiment of this disclosure, isolating the data pool into multiple data domains includes isolating data into multiple data domains according to source and role.

[0014] In yet another embodiment of this disclosure, the plurality of data fields are configured with corresponding protection levels.

[0015] In one embodiment of this disclosure, a data management system for a zero-trust secure container is provided, comprising: a zero-trust policy module for generating a zero-trust security policy based on a scenario; a data pool construction module for constructing a data pool for the zero-trust secure container; a zero-trust verification module for applying a zero-trust security policy to data entering or leaving the data pool, wherein data entering or leaving the data pool is only allowed entry or exit after verification according to the zero-trust security policy; and a data isolation module for hierarchically isolating data within the data pool based on the zero-trust security policy, so that data within the data pool can be read in a targeted manner.

[0016] In another embodiment of this disclosure, the zero-trust security strategy includes not trusting any data reader or writer.

[0017] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source of data to be written to the data pool; and admitting data whose source has been verified, wherein the admitted data is labeled with a source tag.

[0018] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source and the role of the data writer for data to be written to the data pool; and admitting data whose roles of the source and the data writer are verified, wherein the admitted data is labeled with a source tag and a role tag of the data writer.

[0019] In another embodiment of this disclosure, the zero-trust security policy includes: verifying the source provided by the data reader, the role of the data writer, and the role of the data reader for data to be read from the data pool; and allowing data whose source, role of the data writer, and role of the data reader have been verified.

[0020] In another embodiment of this disclosure, the data isolation module isolates the data in the data pool in a hierarchical manner based on a zero-trust security policy, including the data isolation module isolating the data pool into multiple data domains.

[0021] In another embodiment of this disclosure, the data isolation module isolates the data pool into multiple data domains, including isolating data into multiple data domains according to sensitive data and runtime data.

[0022] In another embodiment of this disclosure, the data isolation module isolates the data pool into multiple data domains, including isolating data into multiple data domains according to source and role.

[0023] In yet another embodiment of this disclosure, multiple data fields are configured with corresponding protection levels.

[0024] In one embodiment of this disclosure, a computer-readable storage medium storing instructions that, when executed, cause a machine to perform the methods described above.

[0025] This overview is provided to introduce, in a simplified form, some of the concepts further described in the detailed description below. This overview is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Attached Figure Description

[0026] The above-described invention and the following detailed description will be better understood when read in conjunction with the accompanying drawings. It should be noted that the drawings are merely examples of the claimed invention. In the drawings, the same reference numerals represent the same or similar elements.

[0027] Figure 1 This is a flowchart illustrating a data management method for a zero-trust secure container according to an embodiment of the present disclosure;

[0028] Figure 2 This is a schematic diagram illustrating the process of data control for a zero-trust secure container according to an embodiment of the present disclosure;

[0029] Figure 3 This is a schematic diagram illustrating the risk isolation that can be achieved by data control of a zero-trust secure container according to an embodiment of the present disclosure;

[0030] Figure 4 This is a schematic diagram illustrating a data pool architecture for a zero-trust secure container according to an embodiment of the present disclosure;

[0031] Figure 5 This is a block diagram illustrating a data management system for a zero-trust secure container according to an embodiment of the present disclosure. Detailed Implementation

[0032] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, the specific embodiments of this disclosure will be described in detail below with reference to the accompanying drawings.

[0033] Numerous specific details are set forth in the following description in order to provide a full understanding of this disclosure. However, this disclosure may be practiced in other ways different from those described herein, and therefore is not limited to the specific embodiments disclosed below.

[0034] Data has three states throughout its lifecycle: At-Rest, In-Transit, and In-Use. In the At-Rest state, data is typically stored on hard drives, flash memory, or other storage devices. In the In-Transit state, data is transferred from one location to another via a public or private network. Users can encrypt files before transmission or use secure transmission protocols such as HTTPS, SSL, TLS, and FTPS to ensure data security during transmission. However, data in the In-Use state is subject to relatively less robust protection under current technologies.

[0035] Container technology currently manifests primarily in application containerization (e.g., Docker) and system containerization (e.g., LXC). Both forms of containers allow IT personnel to abstract program code from the underlying architecture, thereby achieving portability across various deployment environments. Container security prevents malicious applications from damaging other applications by isolating them. Key application scenarios include: untrusted load balancing, multi-tenant application isolation, and performance and fault isolation.

[0036] In reality, a container is a special process that uses namespaces, control groups, and chroot technology to divide resources, files, devices, states, and configurations into independent spaces. Regarding application containerization (i.e., mini-program containers), although the framework sufficiently isolates mini-programs from platform applications, it implements almost no control over data input and output, leading to numerous issues such as unauthorized access, information leaks, privacy concerns, data security problems, and ecosystem issues.

[0037] The container's current data design pattern is "wide-in, wide-out," meaning all input sources are placed in a shared input pool, and there are no authentication or other security operations for reading and writing; data can be read and written freely based on the key. Return data is also unvalidated, and any initiator can receive the same response. This lack of input validation allows attackers to use the container's parameters as attack payloads, disrupting the container's normal operation. Furthermore, the lack of output validation leads to various privacy leakage risks.

[0038] Therefore, to ensure container security, effective control over data (especially data in use) is also required. This disclosure incorporates zero-trust secure containers to achieve strict data control over secure containers.

[0039] This disclosure will primarily use the Android system's mini-program container as an example to describe the specific data management solution for secure containers. However, those skilled in the art will understand that the technical solution of this disclosure is also applicable to the iOS system's mini-program container and to system-wide containerized data management, which will not be elaborated upon further below.

[0040] Figure 1 This is a flowchart illustrating a data management method 100 for a zero-trust secure container according to an embodiment of the present disclosure.

[0041] In step 102, a zero-trust security policy is generated based on the scenario.

[0042] Zero trust security means that by default, no person, device, or system, whether inside or outside the network, should be trusted. It requires reconstructing the trust foundation of access control based on authentication and authorization. Information such as IP addresses, hosts, geographical locations, and network locations cannot be used as trusted credentials. Essentially, zero trust uses identity-centric access control, thus guiding the security architecture from "network-centric" to "identity-centric."

[0043] This disclosed zero-trust secure container does not trust any input data, regardless of whether it comes from an application platform, a mini-program, or another bundle. In the Android system, bundles are primarily used for data transfer, and the data they store is in key-value pairs. Data requires multiple verification steps before being allowed access.

[0044] Similarly, the zero-trust secure container disclosed herein does not trust any reader requesting data output, regardless of whether the reader is an application platform, a mini-program, or another bundle. Data is only allowed to exit after undergoing multiple verifications.

[0045] The multi-factor authentication before data access is granted is based on a zero-trust security policy. The assertions of a zero-trust security policy include: it should always be assumed that threats are present; threats exist outside the container, within the app, and even inside the container at all times; trust relationships cannot be established solely based on labels or parameters. In fact, a zero-trust security policy can serve as the underlying design for access control policies. In different application scenarios, access control policies can be dynamically evaluated and determined based on as many data sources as possible, adapting to the assertions of the zero-trust security policy.

[0046] In different scenarios, the zero-trust security policy can be adjusted according to the above principles. Therefore, a corresponding zero-trust security policy can be generated based on the specific scenario.

[0047] In section 104, a data pool for zero-trust secure containers is built.

[0048] To implement data governance for zero-trust secure containers, the first step is to build a data pool for those containers. The input, output, and internal processes of this data pool will all be governed by zero-trust security. All sensitive and runtime data required by the containers are included in the data pool and verified based on zero-trust security policies during input, output, and internal operations.

[0049] The architecture of the data pool for this zero-trust secure container will refer to Figure 4 This will be described in detail below.

[0050] In 106, a zero-trust security policy is adopted for data entering and leaving the data pool, where the data is only allowed entry and exit after being verified according to the zero-trust security policy.

[0051] To effectively manage data entering and leaving the data pool, a zero-trust security strategy is required. The assertions of this strategy include: always assuming a pervasive threat environment; threats exist constantly outside the container, within the app, and even inside the container; and trust relationships cannot be established solely based on labels or parameters.

[0052] The aforementioned zero-trust security policy essentially includes distrusting any data reader or writer. Based on these assertions, any data used by the zero-trust secure container is verified according to the zero-trust security policy. For zero-trust secure containers, data verification involves both the verification initiator and the verification operator. Verification initiators include other bundles / SDKs, the container's internal systems, mini-programs, network traffic, etc.; while verification operators include platform-triggered, external network-triggered, mini-program-triggered, and user-triggered verification.

[0053] The zero-trust security strategy described above specifies access control policies for the data to be used. For zero-trust secure containers, when using data, the access control policy adopts Role-based Access Control (RBAC), where roles determine permissions, permissions are hierarchically layered based on roles, and the principle of least privilege is applied. RBAC simply decouples users and permissions, associating users with roles, and roles with permissions. Roles are a classification and management system for many users with similar permissions. Roles have hierarchical relationships, forming a tree structure, where the permissions of a parent role are the sum of its own and its child roles' permissions.

[0054] In one embodiment of this disclosure, the access control policy for zero-trust secure containers further includes verifying the source of data to be written to the data pool; and verifying the source of the data, wherein the admitted data is labeled with a source tag. In one embodiment of this disclosure, the source of the data may include the network, bundle, the container itself, JSAPI, etc. Those skilled in the art will understand that the source of the data may include other sources beyond the exhaustive list, which will not be elaborated here.

[0055] In another embodiment of this disclosure, the access control policy for the zero-trust secure container further includes verifying the source of the data and the role of the data writer for the data to be written to the data pool; and the data for which the source and the role of the data writer are verified, wherein the admitted data is labeled with a source label and a role label of the data writer.

[0056] In yet another embodiment of this disclosure, the access control policy for zero-trust secure containers further includes verifying the source provided by the data reader, the role of the data writer, and the role of the data reader for data to be read from the data pool; and allowing data from which the source, the role of the data writer, and the role of the data reader are verified.

[0057] The access control policy for zero-trust secure containers is adaptive, meaning it uses machine learning to set context-sensitive access policies and automatically adjusts and adapts to them.

[0058] When using data, the direction of data use is clear; that is, data within the data pool can be read in a targeted manner. Specific data can be accessed only when the verification initiator and the verification operator are clearly identified.

[0059] Those skilled in the art will understand that the aforementioned zero-trust security policy can be further specified as other access control policies, such as Discretionary Access Control (DAC), Mandatory Access Control (MAC), the Bell-Lapadula security model, and the Biba security model, etc. Furthermore, these access control policies can be combined and configured for different levels of data according to different application scenarios. The details of setting access control policies will not be elaborated here.

[0060] In 108, data within the data pool is isolated in a hierarchical manner based on a zero-trust security policy, so that the data within the data pool can be read in a targeted manner.

[0061] Linux containers use namespaces to achieve "isolation." Namespaces modify the "view" that application processes have of the entire computer; that is, application processes can only "see" certain specified content. From the host machine's perspective, these "isolated" processes are no different from other processes.

[0062] Because containers using namespaces as an isolation mechanism do not require a separate guest OS, their additional resource consumption is negligible. However, this also results in incomplete isolation, as multiple containers still use the same host operating system kernel. Furthermore, many resources and objects in the Linux kernel cannot be namespaced, such as time.

[0063] Therefore, Linux Cgroups are used to limit the maximum resources a process group can use, including CPU, memory, disk, network bandwidth, etc. In addition, Cgroups can also set process priorities, audit processes, and suspend and resume processes.

[0064] The above isolation of the container only separates the mini-program from the platform application at the framework level, but does not isolate the data within the data pool.

[0065] Data within a data pool can be managed at different levels to ensure data security isolation. Data can be managed at both coarse-grained and fine-grained levels from different dimensions. In secure container data management, managing only sensitive data represents coarse-grained management. Managing not only sensitive data but also runtime data represents fine-grained management.

[0066] like Figure 2 As shown, data within the data pool is isolated in layers across other dimensions. That is, at a coarse-grained level, access control is implemented for data flows between servers, such as isolating data from different sources. At a fine-grained level, data access is restricted based on roles (or identities, referred to as "roles" in this disclosure) and sources. Each piece of data within the data pool is labeled with a role and a source, and data with different role and source labels are isolated from each other.

[0067] To further enhance the determinism of data access, continuous dynamic verification of roles is required throughout the access lifecycle, especially when the context changes, such as environmental context, spatiotemporal context, operational context, path dependencies, etc. In a zero-trust secure container, the zero-trust security policy, which distrusts no data reader or writer, prompts continuous dynamic verification of the roles using the data, thereby improving data security.

[0068] In one embodiment of this disclosure, only data with clearly defined roles and source tags can be written to the data pool; and the data reader needs to include both its own role and the target role to accurately read the data. Therefore, the data within the data pool can be read in a targeted manner.

[0069] Therefore, the data control method for zero-trust secure containers disclosed in this disclosure verifies data entering and leaving the data pool and isolates data within the data pool, thereby ensuring the data security of zero-trust secure containers. In other words, it achieves strict data control over secure containers by exercising more granular control over all data used by the container.

[0070] Figure 2 This is a schematic diagram illustrating the process of data management in a zero-trust secure container according to an embodiment of the present disclosure. The data pool of the zero-trust secure container of the present disclosure performs access and exit verification, isolated storage, and targeted reading and use on all data.

[0071] like Figure 2 As shown in one embodiment of this disclosure, data undergoes source and writer role verification before entering the data pool. Data whose source and writer roles are verified is admitted; conversely, data whose source or writer role is unclear or unverified is not admitted. Admitted data is tagged with a source label and a writer role label.

[0072] In another embodiment of this disclosure, the source of data is verified before it enters the data pool. Data with verified sources is admitted; conversely, data with unclear or unverified sources is not admitted. All admitted data is tagged with a source label.

[0073] In yet another embodiment of this disclosure, the data writer's role is verified before entering the data pool. Data whose writer role is verified is admitted; conversely, data whose writer role is ambiguous or unverified is not admitted. All admitted data is tagged with a writer role label.

[0074] Data within a data pool can be managed at different levels to ensure data security isolation. Data can be managed at both coarse-grained and fine-grained levels from different dimensions. In secure container data management, managing only sensitive data represents coarse-grained management. Managing not only sensitive data but also runtime data represents fine-grained management.

[0075] like Figure 2As shown, data control is implemented from the dimensions of data source, data writer role, and data reader role. In one embodiment of this disclosure, data can be controlled at a coarse-grained level. For example, data can be classified or graded according to its source to form different data domains. The data will be tagged with a source label. Another example is that data can be classified or graded according to the data reader / writer role to form different data domains. The data will be tagged with a role label. In the case where different data domains are formed according to the data source, data can be isolated according to whether it comes from different web servers, application servers, databases, etc., so that data originating from different servers can be stored in separate regions. Furthermore, the web server can only access data from the corresponding application server, and the application server can only access data from the corresponding database.

[0076] In another embodiment of this disclosure, data can be managed with fine granularity. For example, data can be classified and graded according to its source and the roles of the data reader and writer, forming different data domains. Specifically, each piece of data in the data pool is labeled with a role and a source tag, and data with different role tags and source tags are isolated from each other, thereby achieving data isolation by role and source tag.

[0077] After data within the data pool is isolated into different data domains, each data domain can be configured with a corresponding protection level. This means that after the data is generated, it is provided with different levels of security protection throughout its entire lifecycle of storage, use, and transmission, based on the corresponding security policies.

[0078] To access data within the data pool, in one embodiment of this disclosure, the reader can only read data if it specifies two tags (i.e., a role tag and a source tag). The reader needs to carry both its own role (the reader's identity) and the target's role (the data writer's identity) when reading. For example, a function developer needs to know the upstream tag of the parameter they are using to accurately obtain the parameter. Data requires verification of both role and source before it can be accessed. Therefore, targeted data reading is possible, meaning that only readers specifying the two tags can read the data.

[0079] In another embodiment of this disclosure, the reader can only read data if a source label is specified. Data requires source verification before it can be accessed. Therefore, targeted data reading is possible; that is, only readers who specify a source label can read the data.

[0080] In yet another embodiment of this disclosure, the reader can only read data if the data writer role is specified. For data, only data that has been verified by the data writer role can be allowed to be accessed. Thus, targeted data reading is possible, meaning that only readers who can specify the data writer role tag can read the data.

[0081] Figure 3 This is a schematic diagram illustrating the risk isolation that can be achieved by data control of a zero-trust secure container according to an embodiment of the present disclosure.

[0082] According to one embodiment of this disclosure, due to the data control of the zero-trust security container as described above, the verification during data admission will prevent the data from being used as an attack payload, the verification during data exit will prevent internal data from being stolen from the outside and prevent various privacy leakage risks to ensure data security, and the targeted reading of data can prevent external data from interfering with the operation of internal mechanisms, thereby preventing security vulnerabilities.

[0083] In this disclosure, by adopting fine-grained data control, sensitive data and runtime data are included in the control, thus isolating data from risks and ensuring security.

[0084] Figure 4 This is a schematic diagram illustrating a data pool architecture for a zero-trust secure container according to an embodiment of the present disclosure.

[0085] like Figure 4 As shown, according to one embodiment of this disclosure, in the container core component of the Android system, namespaces are used to implement "process isolation," while cgroups are used to implement "permission isolation." The running parameters and startup parameters of the container core component are entered into the container data center as runtime data.

[0086] The container data center's data pool is shared by containers with zero-trust security. Any external input parameters needed by any container can only be obtained from this data pool, such as whitelists, startup parameters, JSAPI parameters, and switch configurations.

[0087] The container data center's data pool is configured with inbound and outbound customs to verify data entering and leaving the pool separately. Data in the pool originates from container core components, call sources, container dependencies, and so on. The runtime and startup parameters of container core components, data from call sources, and file data and user privacy data from container dependencies enter the data pool through the inbound customs.

[0088] Data access control is the process of verifying data before it is written; only data that has passed identity verification is allowed to be written into the pool. In one embodiment of this disclosure, such as... Figure 4 As shown, data identity verification can be a dual verification of source and role. Each piece of data entering the data pool carries two tags: a role tag and a source tag. In another embodiment of this disclosure, data identity verification can be verification of either the source or the role.

[0089] Data verification is the process of verifying the data reader before outputting data. In one embodiment of this disclosure, the reader needs to carry both their own identity and the target identity to accurately read the data, and the reading behavior is recorded and controlled.

[0090] In one embodiment of this disclosure, such as Figure 4 As shown, in the data pool of the container data center, parameters of different role tags and source tags are isolated from each other and stored in different data domains, such as the first data domain, the second data domain, the third data domain, the fourth data domain, etc. Within these data domains, file data, memory data, network data, etc., can be stored separately.

[0091] In this embodiment, data in these data fields is readable and writable only when both tags are specified. That is, the function developer needs to know the upstream tag of the parameter they are using to accurately obtain the parameter. These two types of tags are generated by the container's own code, not by the initiator of the read / write operation. The container autonomously determines the source tag and role source of the admission data based on the data's origin (i.e., network / other bundles / container itself / JSAPI).

[0092] The generated role tags and source tags require the establishment of corresponding asset libraries and control capabilities based on role tags and source tags, which will not be elaborated here.

[0093] Those skilled in the art will understand that, Figure 4 The data pool architecture of the zero-trust secure container shown is for illustrative purposes only and not a limitation. Data isolation can be adjusted accordingly. Figure 2 The data is processed at different levels based on different dimensions and scenarios. Data labels can also be applied differently depending on the scenario, and corresponding entry, exit, and isolation measures can be implemented.

[0094] Figure 5 This is a block diagram illustrating a container data management system 500 for zero-trust secure containers according to an embodiment of the present disclosure.

[0095] The container data management system 500 includes a zero-trust policy module 502, a data pool construction module 504, a zero-trust verification module 506, and a data isolation module 508.

[0096] The Zero Trust Policy Module 502 generates a zero trust security policy based on the scenario.

[0097] This disclosed zero-trust secure container distrusts all input data, regardless of whether it originates from an application platform, a mini-program, or another bundle. In the Android system, bundles are primarily used for data transfer, storing data in key-value pairs. Data requires multiple verification steps before being allowed entry. Similarly, this disclosed zero-trust secure container distrusts all readers requesting data output, regardless of whether the reader is an application platform, a mini-program, or another bundle. Data requires multiple verification steps before being allowed exit.

[0098] The multi-factor authentication of data before it is admitted or denied access is based on a zero-trust security policy. The assertions of a zero-trust security policy include: it should always be assumed that threats are present; threats exist outside the container, within the app, and even inside the container at all times; trust relationships cannot be established solely based on labels or parameters. A zero-trust security policy can actually serve as the underlying design for access control policies.

[0099] In different scenarios, the zero-trust security policy can be adjusted according to the above principles. Therefore, the zero-trust policy module 502 can generate a corresponding zero-trust security policy based on the scenario. The zero-trust security policy generated by the zero-trust policy module 502 based on the scenario is then passed to the zero-trust verification module 506 and the data isolation module 508.

[0100] The data pool building module 504 builds a data pool for zero-trust secure containers.

[0101] based on Figure 4 The architecture shown is designed for data management of zero-trust secure containers. The data pool construction module 504 first constructs the data pool for this zero-trust secure container. The input, output, and internal operations of this data pool will all be managed based on zero-trust security. All sensitive and runtime data required by the container are included in the data pool and verified based on the zero-trust security policy during input, output, and internal operations.

[0102] The zero-trust verification module 506 adopts a zero-trust security policy for data entering and leaving the data pool. Data entering and leaving the data pool is only allowed entry and exit after being verified according to the zero-trust security policy.

[0103] Sensitive data and runtime data will enter the shared data pool of the container built by the data pool construction module 504. To manage data entering and leaving the data pool, the zero-trust verification module 506 needs to adopt a zero-trust security policy. The assertions of the adopted zero-trust security policy include: it should always be assumed that threats are present; threats exist outside the container, within the app, and even inside the container at all times; trust relationships cannot be established solely based on tags or parameters. The aforementioned zero-trust security policy essentially includes not trusting any data reader or writer.

[0104] The aforementioned zero-trust security policy is specified as an access control policy for the data to be used. In one embodiment of this disclosure, the access control policy of the zero-trust verification module 506 for the zero-trust security container further includes verifying the source of the data to be written to the data pool; and verifying the source of the data, wherein the access data is labeled with a source tag.

[0105] In another embodiment of this disclosure, the access control policy of the zero-trust verification module 506 for the zero-trust secure container further includes verifying the source of the data and the role of the data writer for the data to be written to the data pool; and verifying the access source and the role of the data writer for the data, wherein the access data is labeled with a source label and a role label of the data writer.

[0106] In yet another embodiment of this disclosure, the access control policy of the zero-trust verification module 506 for the zero-trust security container further includes verifying the source provided by the data reader, the role of the data writer, and the role of the data reader for the data to be read from the data pool; and allowing data whose source, role of the data writer, and role of the data reader have been verified.

[0107] The data isolation module 508 uses a zero-trust security policy to isolate data within the data pool in a hierarchical manner, so that the data within the data pool can be read in a targeted manner.

[0108] For data within the data pool, the data isolation module 508 can perform different levels of control to securely isolate the data. Data can be controlled at both coarse and fine granular levels from different dimensions. In the data control of the secure container, controlling only sensitive data represents coarse-grained control. Controlling not only sensitive data but also runtime data represents fine-grained control.

[0109] like Figure 2 As shown, the data isolation module 508 isolates data within the data pool in hierarchical layers across other dimensions. That is, at a coarse-grained level, access control is implemented for data flows between servers, such as isolating data from different sources. At a fine-grained level, data access is restricted based on roles (or identities, referred to herein as "roles") and sources. Each piece of data within the data pool is labeled with a role and a source tag, and data with different role and source tags are isolated from each other.

[0110] Therefore, after the data isolation module 508 isolates the data in the data pool in a hierarchical manner based on the zero-trust security policy, the data in the data pool can be accessed in a targeted manner. That is, when the data is used, the direction of data use is clear, meaning that the data in the data pool can be read in a targeted manner.

[0111] Therefore, the data management system for zero-trust secure containers disclosed in this disclosure verifies data entering and leaving the data pool and isolates data within the data pool, thereby ensuring the data security of zero-trust secure containers. In other words, it achieves strict data management of secure containers by exercising more granular control over all data used by the container.

[0112] The various steps and modules of the data management method and system for zero-trust secure containers described above can be implemented in hardware, software, or a combination thereof. If implemented in hardware, the various illustrative steps, modules, and circuits described in connection with this invention can be implemented or executed using a general-purpose processor, digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic components, hardware components, or any combination thereof. A general-purpose processor can be a processor, microprocessor, controller, microcontroller, or state machine, etc. If implemented in software, the various illustrative steps and modules described in connection with this invention can be stored as one or more instructions or codes on a computer-readable medium or transmitted. Software modules implementing the various operations of this invention can reside in storage media such as RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disks, removable disks, CD-ROMs, cloud storage, etc. The storage medium can be coupled to a processor so that the processor can read and write information from / to the storage medium and execute corresponding program modules to implement the various steps of this invention. Moreover, software-based embodiments can be uploaded, downloaded, or remotely accessed through appropriate communication means. Such appropriate means of communication include, for example, the Internet, the World Wide Web, intranets, software applications, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave and infrared communication), electronic communication, or other such means of communication.

[0113] It should also be noted that these embodiments may be described as processes depicted as flowcharts, flow diagrams, structure diagrams, or block diagrams. Although a flowchart may describe the operations as a sequential process, many of these operations can be executed in parallel or concurrently. Furthermore, the order of these operations can be rearranged.

[0114] The disclosed methods, apparatuses, and systems should not be limited in any way. Rather, the invention encompasses all novel and non-obvious features and aspects of the various disclosed embodiments (individually and in various combinations and sub-combinations of each other). The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor are any disclosed embodiments required to have any one or more specific advantages or to solve any particular or all technical problems.

[0115] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many modifications under the guidance of the present invention without departing from the spirit and scope of the claims. All of these modifications fall within the scope of protection of the present invention.

Claims

1. A data management method for a zero-trust secure container, comprising: Generate zero-trust security policies based on the scenario; Build a data pool with zero-trust secure containers; The zero-trust security policy is applied to data that needs to enter or leave the data pool, wherein data that needs to enter or leave the data pool is only allowed to enter or leave after being verified according to the zero-trust security policy. as well as The zero-trust security policy provides hierarchical isolation of the data in the data pool, enabling targeted reading of the data. Only readers capable of specifying the source label and the role label of the data writer can read the data, where the source label and the role label indicate that the source of the data and the role of the data writer are verified.

2. The method as described in claim 1, wherein the zero-trust security policy includes not trusting any data reader or writer.

3. The method as described in claim 2, wherein the zero-trust security strategy includes: Verify the source of the data to be written to the data pool; as well as Access is granted to data from verified sources, wherein the accessed data is labeled with a source label.

4. The method as described in claim 2, wherein the zero-trust security strategy comprises: For the data to be written to the data pool, verify the source and the role of the data writer; as well as The data that grants access to the source and the role of the data writer is verified, wherein the access data is labeled with a source tag and a role tag of the data writer.

5. The method as described in claim 3, wherein the zero-trust security strategy comprises: For the data to be read from the data pool, verify the source provided by the data reader, the role of the data writer, and the role of the data reader; as well as The data from the source, the role of the data writer, and the role of the data reader are verified.

6. The method as described in claim 1, wherein the hierarchical isolation of data within the data pool according to the zero-trust security policy includes isolating the data pool into multiple data domains.

7. The method of claim 6, wherein isolating the data pool into multiple data domains comprises isolating the data into the multiple data domains according to sensitive data and runtime data.

8. The method of claim 6, wherein isolating the data pool into multiple data domains comprises isolating the data into the multiple data domains according to source and / or role.

9. The method of claim 6, wherein the plurality of data fields are configured with corresponding protection levels.

10. A data management system for zero-trust secure containers, comprising: The zero-trust policy module generates zero-trust security policies based on the scenario. The data pool building module constructs a data pool for zero-trust secure containers. The zero-trust verification module adopts the zero-trust security policy for data that needs to enter or leave the data pool, wherein data that needs to enter or leave the data pool is only allowed to enter or leave after being verified according to the zero-trust security policy. as well as The data isolation module isolates the data in the data pool in a hierarchical manner based on the zero-trust security policy, so that the data in the data pool can be read in a targeted manner. Only the reader can read the data if it can specify the source label and the role label of the data writer. The source label and the role label indicate that the source of the data and the role of the data writer are verified.

11. The system of claim 10, wherein the zero-trust security policy includes not trusting any data reader or writer.

12. The system of claim 11, wherein the zero-trust security policy includes: Verify the source of the data to be written to the data pool; as well as Access is granted to data from verified sources, wherein the accessed data is labeled with a source label.

13. The system of claim 11, wherein the zero-trust security policy includes: For the data to be written to the data pool, verify the source and the role of the data writer; as well as The data that grants access to the source and the role of the data writer is verified, wherein the access data is labeled with a source tag and a role tag of the data writer.

14. The system of claim 11, wherein the zero-trust security policy includes: For the data to be read from the data pool, verify the source provided by the data reader, the role of the data writer, and the role of the data reader; as well as The data from the source, the role of the data writer, and the role of the data reader are verified.

15. The system of claim 10, wherein the data isolation module isolates the data in the data pool in a hierarchical manner based on the zero-trust security policy, including the data isolation module isolating the data pool into multiple data domains.

16. The system of claim 15, wherein the data isolation module isolates the data pool into multiple data domains by means of the data isolation module isolating the data into the multiple data domains according to sensitive data and runtime data.

17. The system of claim 15, wherein the data isolation module isolates the data pool into multiple data domains, including the data isolation module isolating the data into the multiple data domains according to the source and role.

18. The system of claim 15, wherein the plurality of data fields are configured with corresponding protection levels.

19. A computer-readable storage medium storing instructions that, when executed, cause a machine to perform the method as claimed in any one of claims 1-9.

Images