WO2023071819A1 - 零信任安全容器的数据管控 - Google Patents

零信任安全容器的数据管控 Download PDF

Info

Publication number
WO2023071819A1
WO2023071819A1 PCT/CN2022/125182 CN2022125182W WO2023071819A1 WO 2023071819 A1 WO2023071819 A1 WO 2023071819A1 CN 2022125182 W CN2022125182 W CN 2022125182W WO 2023071819 A1 WO2023071819 A1 WO 2023071819A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
zero
pool
trust
role
Prior art date
Application number
PCT/CN2022/125182
Other languages
English (en)
French (fr)
Inventor
李文杰
Original Assignee
支付宝(杭州)信息技术有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 支付宝(杭州)信息技术有限公司 filed Critical 支付宝(杭州)信息技术有限公司
Priority to EP22885698.5A priority Critical patent/EP4345661A4/en
Publication of WO2023071819A1 publication Critical patent/WO2023071819A1/zh
Priority to US18/543,709 priority patent/US20240119127A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/12—Protecting executable software
    • G06F21/121—Restricting unauthorised execution of programs
    • G06F21/128—Restricting unauthorised execution of programs involving web programs, i.e. using technology especially used in internet, generally interacting with a web browser, e.g. hypertext markup language [HTML], applets, java
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/445—Program loading or initiating
    • G06F9/44568—Immediately runnable code
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H04L63/205—Network architectures or network communication protocols for network security for managing network security; network security policies in general involving negotiation or determination of the one or more network security mechanisms to be used, e.g. by negotiation between the client and the server or between peers or by selection according to the capabilities of the entities involved
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45587—Isolation or security of virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/034—Test or assess a computer or a system

Definitions

  • the present disclosure mainly relates to applet security, and in particular to applet container security.
  • this disclosure provides a data management and control scheme for zero-trust security containers, which can build a data pool for zero-trust security containers, and not only verify the data entering and leaving the data pool based on zero-trust security policies, but also based on The zero-trust security policy isolates the data in the data pool, so as to achieve strict control over the data of the applet container.
  • a data management and control method of a zero-trust security container including: generating a zero-trust security policy according to a scenario; building a data pool of a zero-trust security container; Trust security policy, wherein the data to be entered into and out of the data pool is only allowed in and out after being verified according to the zero trust security policy; and the data in the data pool is hierarchically isolated based on the zero trust security policy, so that the data in the data pool able to be read directionally.
  • the zero-trust security policy includes distrusting any data reader or writer.
  • the zero-trust security policy includes: verifying the source of the data to be written into the data pool; and admitting the data whose source is verified, wherein the admitted data is labeled with a source label.
  • the zero-trust security policy includes: for the data to be written into the data pool, verifying the role of the source and data writer; , where the admitted data is labeled with the source label and the role label of the data writer.
  • the zero-trust security policy includes: for the data to be read from the data pool, verifying the source provided by the data reader, the role of the data writer, and the role of the data reader; and Data whose source, role of the data writer, and role of the data reader are verified.
  • hierarchically isolating the data in the data pool according to the zero-trust security policy includes isolating the data pool into multiple data domains.
  • isolating the data pool into multiple data domains includes isolating data into multiple data domains according to sensitive data and runtime data.
  • isolating the data pool into multiple data domains includes isolating data into multiple data domains according to source and role.
  • corresponding protection levels are set for the plurality of data domains.
  • a data management and control system for a zero-trust security container including: a zero-trust policy module that generates a zero-trust security policy according to a scenario; a data pool construction module that builds a data pool for a zero-trust security container; The zero-trust verification module adopts a zero-trust security policy for the data that needs to enter and exit the data pool, and the data that needs to enter and exit the data pool is only allowed in and out after being verified according to the zero-trust security policy; and the data isolation module, based on zero-trust
  • the security policy hierarchically isolates the data in the data pool, so that the data in the data pool can be read directionally.
  • the zero-trust security policy includes distrusting any data reader or writer.
  • the zero-trust security policy includes: verifying the source of the data to be written into the data pool; and admitting the data whose source is verified, wherein the admitted data is labeled with a source label.
  • the zero-trust security policy includes: for the data to be written into the data pool, verifying the role of the source and data writer; , where the admitted data is labeled with the source label and the role label of the data writer.
  • the zero-trust security policy includes: for the data to be read from the data pool, verifying the source provided by the data reader, the role of the data writer, and the role of the data reader; and Data whose source, role of the data writer, and role of the data reader are verified.
  • the data isolation module hierarchically isolating the data in the data pool based on the zero-trust security policy includes the data isolation module isolating the data pool into multiple data domains.
  • the data isolation module isolating the data pool into multiple data domains includes the data isolation module isolating data into multiple data domains according to sensitive data and runtime data.
  • the data isolation module isolating the data pool into multiple data domains includes the data isolation module isolating data into multiple data domains according to sources and roles.
  • multiple data domains are set with corresponding protection levels.
  • a computer-readable storage medium storing instructions, and when executed, the instructions cause a machine to perform the aforementioned method.
  • FIG. 1 is a flow chart showing a data management and control method for a zero-trust secure container according to an embodiment of the present disclosure
  • FIG. 2 is a schematic diagram illustrating a process of data management and control of a zero-trust secure container according to an embodiment of the present disclosure
  • FIG. 3 is a schematic diagram showing the risk isolation that can be achieved in data management and control of a zero-trust security container according to an embodiment of the present disclosure
  • FIG. 4 is a schematic diagram illustrating a data pool architecture of a zero-trust security container according to an embodiment of the present disclosure
  • Fig. 5 is a block diagram illustrating a data management and control system of a zero-trust secure container according to an embodiment of the present disclosure.
  • Data has three states in the entire life cycle: static (At-Rest), in-transit (In-Transit) and in-use (In-Use).
  • St-Rest in-transit
  • In-Use in-use
  • data is generally stored in hard disks, flash memory, or other storage devices.
  • the status in transmission refers to the transmission of data from one place to another through the public network or private network. Users can encrypt files before transmission or use secure transmission protocols to ensure data security during transmission, such as HTTPS, SSL, TLS, FTPS, etc.
  • HTTPS HyperText Transfer Protocol Secure
  • the current form of container technology is mainly reflected in application containerization (such as Docker) and system containerization (such as LXC). Both forms of containers allow IT to abstract program code from the underlying architecture, enabling portability across various deployment environments. Container security prevents damage to other applications by isolating malicious applications.
  • the main application scenarios are: untrusted load isolation, multi-tenant application isolation, performance and fault isolation, etc.
  • a container is a special process that divides resources, files, devices, states, and configurations into independent spaces through namespaces, control groups, and chroot technologies.
  • application containerization i.e. applet container
  • applets are fully isolated from platform-side applications on the framework, there is almost no control over data input and output, resulting in a large number of unauthorized, Information leakage, privacy, data security, ecological issues, etc.
  • the current design mode of the container for data is "wide in and wide out", that is, all sources of input are put into a shared input pool, and there is no security operation such as authentication for reading and writing, and you can read and write at will according to the key. There is no verification of the returned data, and any caller can receive the same return. Failure to verify the input will allow attackers to use the parameters of the input container as an attack payload, interfering with the normal operation of the container mechanism. The output without verification will lead to various privacy leakage risks.
  • the disclosure incorporates a zero-trust secure container to implement strict data control over the secure container.
  • FIG. 1 is a flow chart showing a data management method 100 for a zero-trust secure container according to an embodiment of the present disclosure.
  • a zero-trust security policy is generated according to the scenario.
  • Zero trust security means that no one, device or system inside or outside the network should be trusted by default, and the trust basis of access control needs to be reconstructed based on authentication and authorization. Things such as IP addresses, hosts, geographical locations, and networks cannot be used as credible credentials. Zero trust is essentially identity-centric access control, thus guiding the security architecture from “network centralization” to “identity centralization”.
  • the zero-trust security container of the present disclosure does not trust all input data, no matter it comes from an application platform, a small program or other bundles.
  • the bundle is mainly used to transfer data, and the data it saves exists in the form of key-value (key-value pairs). The data needs to go through multiple verifications before being admitted.
  • the zero-trust security container of the present disclosure does not trust all readers who request data output, no matter whether the readers are application platforms, applets or other bundles. The data needs to go through multiple verifications before being approved.
  • the multi-factor verification before data is admitted is based on the zero trust security policy.
  • the assertions of the Zero Trust security strategy include: Threats should always be assumed; outside containers, applets, and even inside containers are full of threats at all times; trust cannot be established solely by labels or parameters.
  • the zero trust security policy can be used as the underlying design of the access control policy.
  • the access control policy can be dynamically evaluated and judged based on the assertion of the zero trust security policy, depending on as many data sources as possible.
  • zero trust security policies can be adjusted based on the above principles.
  • corresponding zero-trust security policies can be generated according to scenarios.
  • a data pool of zero-trust secure containers is constructed.
  • To implement data management and control for a zero-trust security container first build the data pool of the zero-trust security container. The input, output and interior of the data pool will be based on zero-trust security for data management and control. All sensitive and runtime data required by containers is brought into the data lake and validated against zero-trust security policies on input, output, and internal operations.
  • a zero-trust security policy is adopted for the data to be entered and exited in the data pool, wherein the data is admitted and exited only after being verified according to the zero-trust security policy.
  • a zero-trust security strategy is required.
  • the assertions of the adopted zero-trust security strategy include: Threats should always be assumed to be rife; threats are rife outside containers, applets, and even inside containers at all times; trust relationships cannot be established solely by labels or parameters.
  • the above-mentioned zero-trust security strategy essentially includes distrusting any data reader or writer. Based on the above assertions, any data to be used by the zero trust security container is verified according to the zero trust security policy.
  • data verification involves verifying the initiator and verifying the operator. Verification initiators include other bundles/SDKs, internal containers, applets, network traffic, etc.; verification operators include platform triggers, external network triggers, applet autonomous triggers, user autonomous triggers, etc.
  • the above-mentioned zero trust security policy will be embodied as an access control policy for the data to be used.
  • the access control strategy adopts role-based access control (Role-based Access Control, RBAC), that is, roles determine permissions, permissions are layered based on roles, and the principle of least privilege is adopted.
  • RBAC simply decouples users and permissions, and associates users with roles and roles with permissions.
  • Roles are classified management for many users with similar permissions. Roles have a subordinate relationship and can form a tree structure.
  • the permissions of the parent role are the sum of the permissions of itself and the child roles.
  • the access control policy for the zero-trust security container further includes, for the data to be written into the data pool, verifying the source of the data; and admitting the data whose source is verified, wherein the admitted data is labeled with a source label .
  • the source of data may include network, bundle, container itself, jsapi, etc. Those skilled in the art can understand that the sources of data may include non-exhaustive other sources, which will not be repeated here.
  • the access control policy for the zero-trust security container further includes, for the data to be written into the data pool, verifying the source of the data and the role of the data writer; and the access source and the role of the data writer The role of the data is verified, where the admitted data is labeled with the source label and the role label of the data writer.
  • the access control policy for the zero-trust security container further includes verifying the source provided by the data reader, the role of the data writer, and the data reader for the data to be read from the data pool. ; and data whose source, role of the data writer, and role of the data reader are verified.
  • the access control policy for zero-trust security containers is adaptive, that is, machine learning is used to set context-sensitive access policies, and the policies are automatically adjusted and adapted.
  • the directionality of data use is clear, that is, the data in the data pool can be read directionally.
  • Specified data can be accessed when the authentication initiator and authentication operator are clearly identified.
  • the above-mentioned zero-trust security strategy can also be embodied as other access control strategies, such as discretionary access control (Discretionary Access Control, DAC), mandatory access control (Mandatory Access Control, MAC), Bell-Lapadula security model, and Biba security model, etc.
  • these access control policies can be combined and configured for different levels of data according to different application scenarios. The setting of the access control policy will not be repeated here.
  • the data in the data pool is hierarchically isolated based on the zero-trust security policy, so that the data in the data pool can be directional read.
  • Namespace modifies the "view” of the application process on the entire computer, that is, the application process can only "see” certain specified content. For the host, these "isolated" processes are no different from other processes.
  • Linux Cgroups are used to limit the upper limit of resources that a process group can use, including CPU, memory, disk, network bandwidth, and so on.
  • Cgroups can also set the priority of the process, audit, and suspend and resume the process.
  • the above isolation of the container only isolates the applet from the platform application on the framework, and does not isolate the data in the data pool.
  • the data in the data pool will be isolated hierarchically in other dimensions. That is, at a coarse-grained level, access control is implemented on the data flow between servers, such as isolating data from different sources. On a fine-grained level, data access is restricted based on roles (or identities, collectively referred to as “roles” in this disclosure) and sources. Add role and source labels to each data in the data pool, and the data with different role labels and source labels are isolated from each other.
  • roles or identities, collectively referred to as “roles” in this disclosure
  • the zero-trust security policy that does not trust any data reader or writer promotes continuous dynamic verification of the roles that use data, thereby improving data security.
  • only data with clear role and source tags can be written into the data pool; and the data reader needs to carry its own role and the target role to accurately read the data.
  • the data in the data pool can be read in a targeted manner.
  • the data management and control method for the zero-trust security container disclosed in this disclosure verifies the data entering and leaving the data pool, and isolates the data in the data pool, thereby ensuring the data security of the zero-trust security container. That is, strict data control over secure containers is achieved through finer-grained control over all data used by the container.
  • Fig. 2 is a schematic diagram illustrating a process of data management and control of a zero-trust secure container according to an embodiment of the present disclosure.
  • the data pool of the zero-trust security container of the present disclosure performs entry and exit verification, isolated storage, and directional reading and use for all data.
  • the source and role of the data writer will be verified before the data enters the data pool.
  • the data whose source and role of the data writer have been verified is admitted; on the contrary, the data whose source or role of the data writer is unclear or cannot be verified is not admitted.
  • the admitted data is tagged with the source tag and the role tag of the data writer.
  • the source verification will be carried out before the data enters the data pool. Data with verified sources was admitted; conversely, data with unclear or unverified sources was excluded. Accessed data are tagged with source.
  • the role of the data writer before the data enters the data pool, the role of the data writer will be verified.
  • the data whose role of the data writer has been verified is admitted; on the contrary, the data whose role of the data writer is unclear or cannot be verified is not admitted.
  • the admitted data is tagged with the role of the data writer.
  • control is carried out from the dimensions of the source of data, the role of the data writer, and the role of the data reader.
  • data can be managed and controlled at a coarse grained level. For example, classify or classify data according to data sources to form different data domains. Data will be source-tagged. Another example is to classify or classify data according to the roles of data readers and writers to form different data domains. The data will be labeled with roles.
  • data can be isolated according to different web servers, application servers, databases, etc., so that data originating from different servers can be stored in different regions. And, further, the web server can only access the data of the corresponding application server, and the application server can only access the data of the corresponding database.
  • fine-grained control of data can be performed. For example, data is classified and graded according to the data source and the role of the data reader to form different data domains. Specifically, each data in the data pool is tagged with a role and a source, and data with different role tags and source tags are isolated from each other, thereby realizing data isolation by role and source tags.
  • each data domain can be set with a corresponding protection level, which means that after the data is generated, the entire life cycle of its storage, use and transmission is provided with different strengths according to the corresponding security policy. Security.
  • the reader can read only when specifying double tags (namely role tag and source tag).
  • the reader needs to carry the role of the reader (self identity) and the role of the data writer (target identity) to read.
  • function developers need to know the upstream label of the parameters they use in order to get the parameters accurately.
  • data it needs to be verified by role and source before it can be released.
  • the data can be read directionally, that is, the reader who can specify the double tag can read the data.
  • the reader can read only when the source tag is indicated. For data, it needs to be verified by the source before it can be released. Thus, the data can be read directionally, that is, the reader who can indicate the source tag can read the data.
  • the reader can read only when the role of the data writer is specified.
  • the data that needs to be verified by the role of the data writer can be approved.
  • the data can be read directionally, that is, the reader who can specify the role tag of the data writer can read the data.
  • FIG. 3 is a schematic diagram illustrating the risk isolation that can be achieved for data management and control of a zero-trust secure container according to an embodiment of the present disclosure.
  • the verification at the time of data admission will prevent the data from being used as an attack load
  • the verification at the time of data export will prevent internal data from being Stealing and preventing various privacy leakage risks to ensure data security
  • directional reading of data can prevent external data from interfering with the operation of internal mechanisms, thereby preventing security breaches.
  • FIG. 4 is a schematic diagram illustrating a data pool architecture of a zero-trust security container according to an embodiment of the present disclosure.
  • Namespace is used to implement "process isolation”
  • Cgroups is used to implement "authority isolation”.
  • the operating parameters and startup parameters of the core components of the container enter the container data center as runtime data.
  • the data pool in the container data center is shared by zero-trust secure containers. External input parameters that need to be used in any container can only be obtained from this data pool, such as whitelist, startup parameters, jsapi parameters, switch configuration, etc.
  • the data pool of the container data center is configured with entry customs and export customs to verify the data entering and exiting the data pool respectively.
  • the data in the data pool comes from container core components, call sources, container dependent components, and so on.
  • the operating parameters and startup parameters of the core components of the container, the data from the calling source, and the file data and user privacy data of the container's dependent components enter the data pool through the entry customs.
  • Data admission is the process of verifying data before writing data, and only data that has passed identity verification is allowed to be written into the pool.
  • the identity verification of data may be double verification of source and role. Every piece of data that enters the data pool has two tags, a role tag and a source tag.
  • the identity verification of data may be verification of one of source or role.
  • Data verification is the process of verifying the data reader before outputting data.
  • the reader needs to carry his own identity and the target identity to accurately read the data, and the reading behavior will be recorded and controlled.
  • the 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 The second data domain, the third data domain, the fourth data domain, etc.
  • data domains such as the first data domain, the second The second data domain, the third data domain, the fourth data domain, etc.
  • file data, memory data, network data, etc. can be stored separately.
  • the data in these data fields can only be read and written when double tags are specified, that is, the function developer needs to know the upstream tag of the parameter he uses in order to obtain the parameter accurately.
  • the generation of these two types of tags is generated by the container's own code, not by the initiator of reading and writing.
  • the container independently judges the source label and role source of the access data according to the source of the data (ie, network/other bundles/container itself/jsapi).
  • data pool architecture of the zero-trust security container shown in FIG. 4 is only an example and not a limitation.
  • Data isolation can be performed at different levels according to different dimensions and scenarios as shown in FIG. 2 .
  • Data labels can also be applied differently according to different scenarios, and correspondingly different admission, admission, and isolation are performed.
  • FIG. 5 is a block diagram illustrating a container data management and control system 500 for a zero-trust secure container according to an embodiment of the present disclosure.
  • the container data control 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 .
  • the zero trust policy module 502 generates a zero trust security policy according to scenarios.
  • the zero-trust security container of the present disclosure does not trust all input data, no matter it comes from an application platform, a small program or other bundles.
  • the bundle is mainly used to transfer data, and the data it saves exists in the form of key-value (key-value pairs).
  • the data needs to go through multiple verifications before being admitted.
  • the zero-trust security container of the present disclosure does not trust all readers who request data output, no matter whether the readers are application platforms, applets or other bundles. The data needs to go through multiple verifications before being approved.
  • the multi-factor verification before data is admitted is based on the zero trust security policy.
  • the assertions of the Zero Trust security strategy include: Threats should always be assumed; outside containers, applets, and even inside containers are full of threats at all times; trust cannot be established solely by labels or parameters.
  • the zero trust security policy can actually be used as the underlying design of the access control policy.
  • zero trust security policies can be adjusted based on the above principles.
  • the zero trust policy module 502 can generate a corresponding zero trust security policy according to the scenario.
  • the zero trust security policy generated by the zero trust policy module 502 according to the scenario is delivered to the zero trust verification module 506 and the data isolation module 508 .
  • the data pool construction module 504 constructs the data pool of the zero-trust security container.
  • the data pool construction module 504 first constructs the data pool of the zero-trust security container.
  • the input, output and interior of the data pool will be based on zero-trust security for data management and control. All sensitive and runtime data required by containers is brought into the data lake and validated against zero-trust security policies on input, output, and internal operations.
  • the zero-trust verification module 506 adopts a zero-trust security policy for the data to be entered and exited from the data pool, wherein the data to be entered and exited from the data pool is not admitted until verified according to the zero-trust security policy.
  • Sensitive data and runtime data will enter the shared data pool of the container built by the data pool construction module 504 .
  • the zero-trust verification module 506 needs to adopt a zero-trust security strategy.
  • the assertions of the adopted zero-trust security strategy include: Threats should always be assumed to be rife; threats are rife outside containers, applets, and even inside containers at all times; trust relationships cannot be established solely by labels or parameters.
  • the above-mentioned zero-trust security strategy essentially includes distrusting any data reader or writer.
  • the above-mentioned zero trust security policy will be embodied as an access control policy for the data to be used.
  • the zero-trust verification module 506's access control policy for the zero-trust security container further includes, for the data to be written into the data pool, verifying the source of the data; and admitting the data whose source is verified, wherein the access Data are labeled with provenance.
  • the zero-trust verification module 506's access control policy for the zero-trust security container further includes, for the data to be written into the data pool, verifying the source of the data and the role of the data writer; and the access source and the role of the data writer is verified data, where the admitted data is labeled with the source label and the role label of the data writer.
  • the zero-trust verification module 506's access control policy for the zero-trust security container also includes verifying the source provided by the data reader and the role of the data writer for the data to be read from the data pool and the role of the data reader; and data whose origin, data writer's role, and data reader's role are verified.
  • the data isolation module 508 hierarchically isolates the data in the data pool based on the zero-trust security policy, so that the data in the data pool can be read directionally.
  • the data isolation module 508 can perform different levels of management and control to isolate the data safely. Coarse-grained and fine-grained control of data can be performed from different dimensions. In the data control of secure containers, only sensitive data is controlled as coarse-grained control. Instead of not only controlling sensitive data, but also controlling runtime data, it is fine-grained control.
  • the data isolation module 508 will isolate the data in the data pool hierarchically in other dimensions. That is, at a coarse-grained level, access control is implemented on the data flow between servers, such as isolating data from different sources. On a fine-grained level, data access is restricted based on roles (or identities, collectively referred to as “roles” in this disclosure) and sources. Add role and source labels to each data in the data pool, and the data with different role labels and source labels are isolated from each other.
  • roles or identities, collectively referred to as “roles” in this disclosure
  • the data isolation module 508 hierarchically isolates the data in the data pool based on the zero-trust security policy, it will enable the data in the data pool to be called directionally. That is, when data is used, the directionality of data use is clear, that is, the data in the data pool can be read directionally.
  • the data management and control system of the zero-trust security container disclosed in this disclosure verifies the data entering and leaving the data pool, and isolates the data in the data pool, thereby ensuring the data security of the zero-trust security container. That is, strict data control over secure containers is achieved through finer-grained control over all data used by the container.
  • Each step and module of the data management and control method and system of the zero-trust secure container described above can be implemented by hardware, software, or a combination thereof.
  • the various illustrative steps, modules, and circuits described in connection with the present invention may be implemented with 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.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general-purpose processor may be a processor, microprocessor, controller, microcontroller, or state machine, among others.
  • the various illustrative steps, modules described in connection with the invention may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
  • the software modules implementing the various operations of the present invention may reside in storage media such as RAM, flash memory, ROM, EPROM, EEPROM, registers, hard disk, removable disk, CD-ROM, cloud storage, and the like.
  • the storage medium can be coupled to the processor so that the processor can read and write information from/to the storage medium, and execute corresponding program modules to realize various steps of the present invention.
  • software-based embodiments may be uploaded, downloaded or accessed remotely through appropriate communication means.
  • suitable means of communication include, for example, the Internet, the World Wide Web, an Intranet, software applications, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such means of communication.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Technology Law (AREA)
  • Multimedia (AREA)
  • Computing Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Databases & Information Systems (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Storage Device Security (AREA)

Abstract

本公开提供了一种零信任安全容器的数据管控方法。其中，所述方法包括：依据场景生成零信任安全策略；构建零信任安全容器的数据池；针对要出入该数据池的数据采取零信任安全策略，其中要出入所述数据池的数据在根据零信任安全策略验证后才被准入准出；以及基于零信任安全策略分层级隔离数据池内的数据，以使得该数据池内的数据能够被定向读取。

Description

零信任安全容器的数据管控 技术领域
本公开主要涉及小程序安全，尤其涉及小程序容器安全。
背景技术
当前网络用户已大量地使用小程序。但随着小程序数量的爆发式增长，其安全风险也逐步显现。小程序API使用不规范、与第三方服务器业务逻辑交互有漏洞、服务器数据校验不严谨等情况都可能导致数据泄露。
安全性成为了用户使用容器技术和业务上云面临的最大挑战，其中数据安全问题最为突出，近年来数据泄露事件发生的数量和泄露的数据量快速增长。
因此，本领域需要能够一种对小程序容器的数据进行高效的严格管控的方案。
发明内容
为解决上述技术问题，本公开提供了一种零信任安全容器的数据管控方案，该方案能够构建零信任安全容器的数据池，不仅基于零信任安全策略对进出数据池的数据进行验证，而且依据零信任安全策略对数据池内的数据进行隔离，从而实现对小程序容器的数据的严格管控。
在本公开一实施例中，提供了一种零信任安全容器的数据管控方法，包括：依据场景生成零信任安全策略；构建零信任安全容器的数据池；针对要出入该数据池的数据采取零信任安全策略，其中要出入该数据池的数据在根据零信任安全策略验证后才被准入准出；以及基于零信任安全策略分层级隔离该数据池内的数据，以使得该数据池内的数据能够被定向读取。
在本公开另一实施例中，零信任安全策略包括不信任任何数据读写方。
在本公开另一实施例中，零信任安全策略包括：针对要写入该数据池的数据，验证来源；以及准入来源得到验证的数据，其中准入数据贴有来源标签。
在本公开又一实施例中，零信任安全策略包括：针对要写入该数据池的数据，验证来源和数据写入方的角色；以及准入来源和数据写入方的角色得到验证的数据，其中准入数据贴有来源标签和数据写入方的角色标签。
在本公开另一实施例中，零信任安全策略包括：针对要从该数据池读取的数据，验证数据读取方提供的来源、数据写入方的角色和数据读取方的角色；以及准出来源、数据写入方的角色和数据读取方的角色得到验证的数据。
在本公开又一实施例中，依据零信任安全策略分层级隔离该数据池内的数据包括将该数据池隔离成多个数据域。
在本公开另一实施例中，将该数据池隔离成多个数据域包括按照敏感数据和运行时数据将数据隔离到多个数据域中。
在本公开另一实施例中，将该数据池隔离成多个数据域包括按照来源和角色将数据隔离到多个数据域中。
在本公开又一实施例中，该多个数据域被设置相应的保护等级。
在本公开一实施例中，提供了一种零信任安全容器的数据管控系统，包括：零信任策略模块，依据场景生成零信任安全策略；数据池构建模块，构建零信任安全容器的数据池；零信任验证模块，针对要出入该数据池的数据采取零信任安全策略，其中要出入该数据池的数据在根据零信任安全策略验证后才被准入准出；以及数据隔离模块，基于零信任安全策略分层级隔离该数据池内的数据，以使得该数据池内的数据能够被定向读取。
在本公开另一实施例中，零信任安全策略包括不信任任何数据读写方。
在本公开另一实施例中，零信任安全策略包括：针对要写入该数据池的数据，验证来源；以及准入来源得到验证的数据，其中准入数据贴有来源标签。
在本公开又一实施例中，零信任安全策略包括：针对要写入该数据池的数据，验证来源和数据写入方的角色；以及准入来源和数据写入方的角色得到验证的数据，其中准入数据贴有来源标签和数据写入方的角色标签。
在本公开另一实施例中，零信任安全策略包括：针对要从该数据池读取的数据，验证数据读取方提供的来源、数据写入方的角色和数据读取方的角色；以及准出来源、数据写入方的角色和数据读取方的角色得到验证的数据。
在本公开又一实施例中，数据隔离模块基于零信任安全策略分层级隔离该数据池内的数据包括数据隔离模块将该数据池隔离成多个数据域。
在本公开另一实施例中，数据隔离模块将该数据池隔离成多个数据域包括数据隔离模块按照敏感数据和运行时数据将数据隔离到多个数据域中。
在本公开另一实施例中，数据隔离模块将该数据池隔离成多个数据域包括数据隔离模块按照来源和角色将数据隔离到多个数据域中。
在本公开又一实施例中，多个数据域被设置相应的保护等级。
在本公开一实施例中，提供了一种存储有指令的计算机可读存储介质，当这些指令被执行时使得机器执行如前所述的方法。
提供本概述以便以简化的形式介绍以下在详细描述中进一步描述的一些概念。本概述并不旨在标识所要求保护主题的关键特征或必要特征，也不旨在用于限制所要求保护主题的范围。
附图说明
本公开的以上发明内容以及下面的具体实施方式在结合附图阅读时会得到更好的理解。需要说明的是，附图仅作为所请求保护的发明的示例。在附图中，相同的附图标记代表相同或类似的元素。
图1是示出根据本公开一实施例的零信任安全容器的数据管控方法的流程图；
图2是示出根据本公开一实施例的对零信任安全容器进行数据管控的过程的示意图；
图3是示出根据本公开一实施例的对零信任安全容器的数据管控能够达成的风险隔离的示意图；
图4是示出根据本公开一实施例的零信任安全容器的数据池架构的示意图；
图5是示出根据本公开一实施例的零信任安全容器的数据管控系统的框图。
具体实施方式
使得本公开的上述目的、特征和优点能更加明显易懂，以下结合附图对本公开的具体实施方式作详细说明。
在下面的描述中阐述了很多具体细节以便于充分理解本公开，但是本公开还可以采用其它不同于在此描述的其它方式来实施，因此本公开不受下文公开的具体实施例的限制。
数据在整个生命周期有三种状态：静态(At-Rest)、传输中(In-Transit)和使用中(In-Use)。在静态状态下，一般会把数据存放在硬盘、闪存或其他的存储设备中。传输中状态是指通过公网或私网将数据从一个地方传输到其他地方，用户可以在传输之前对文件加密或者采用安全的传输协议保证数据在传输中的安全，比如HTTPS,SSL,TLS,FTPS等。而使用中状态的数据在现有技术中的良好保护相对偏少。
容器技术目前的形式主要体现在应用程序容器化(例如Docker)和系统容器化(例如LXC)中。这两种形式的容器均能让IT人员从底层架构中抽象出程序代码，从而实现跨各种部署环境的可移植性。容器的安全性通过恶意应用的隔离，来防止其对其他应用的破坏。主要的应用场景有：不可信负载隔离、多租户应用隔离、以及性能和故障隔离等。
实际上，容器是一个特殊的进程，其通过名称空间(Namespace)、控制组(Control  groups)、切根(chroot)技术将资源、文件、设备、状态和配置划分到独立的空间。就应用程序容器化(即小程序容器)而言，虽然在框架上将小程序与平台方应用进行了充分的隔离，但是在数据的输入输出上几乎没有做任何管控，因此导致了大量越权、信息泄漏、隐私、数据安全、生态问题等等。
容器当前对数据的设计模式是“宽进宽出”，即所有来源输入放入一个共享输入池，读写均没有身份验证等安全操作，根据key可以随意读写。返回数据也无校验，任意调起方都可以收到相同的返回。输入不做验证会导致攻击者可以利用输入容器的参数作为攻击载荷，干扰容器机制的正常运行。而输出不做验证会导致各种隐私泄漏风险。
因此，要确保容器的安全性，还需要对数据(尤其是使用中数据)进行有效管控。本公开纳入零信任安全容器来实现对安全容器的严格数据管控。
本公开将主要以Android系统的小程序容器为例进行安全容器的数据管控方案的具体描述，但本领域技术人员可以理解，本公开的技术方案同样适用于iOS系统的小程序容器，还适用于系统容器化的数据管控，在下文中将不再赘述。
图1是示出根据本公开一实施例的零信任安全容器的数据管控方法100的流程图。
在102，依据场景生成零信任安全策略。
零信任安全是指在默认情况下不应该信任网络内部和外部的任何人、设备或系统，需要基于认证和授权重构访问控制的信任基础。诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任本质上是以身份为中心进行访问控制，从而引导安全体系架构从“网络中心化”走向“身份中心化”。
本公开的零信任安全容器对于所有的输入数据都不信任，不管其来自应用平台、小程序还是其他bundle。在Android系统中，bundle主要用于传递数据，它保存的数据是以key-value(键值对)的形式存在的。数据需要经过多重验证后才被准入。
同样，本公开的零信任安全容器对于所有索要数据输出的读取方都不信任，不论该读取方是应用平台、小程序还是其他bundle。数据需要经过多重验证后才被准出。
数据被准入准出之前的多重验证是基于零信任安全策略进行的。零信任安全策略的断言包括：应该始终假设充满威胁；容器外部、小程序、甚至容器内部每时每刻都充斥着威胁；不能仅仅凭借标签或参数来建立信任关系。零信任安全策略实际上可作为访问控制策略的底层设计，在不同的应用场景下访问控制策略可在零信任安全策略的断言的基础上因变于尽量多的数据源进行动态的评估和判定。
在不同场景中，零信任安全策略可依据以上的原则进行调整。由此，可依据场景生成相应的零信任安全策略。
在104，构建零信任安全容器的数据池。
要针对零信任安全容器进行数据管控，首先构建该零信任安全容器的数据池。该数据池的输入端、输出端和内部都将基于零信任安全进行数据管控。所有容器需要的敏感数据和运行时数据都被纳入数据池，并且在输入、输出和内部运作时基于零信任安全策略进行验证。
该零信任安全容器的数据池的架构将参照图4在下文中具体描述。
在106，针对要出入数据池的数据采取零信任安全策略，其中该数据在根据零信任安全策略验证后才被准入准出。
要对出入数据池的数据进行管控，需要采取零信任安全策略。所采取的零信任安全策略的断言包括：应该始终假设充满威胁；容器外部、小程序、甚至容器内部每时每刻都充斥着威胁；不能仅仅凭借标签或参数来建立信任关系。
上述的零信任安全策略实质上包括不信任任何数据读写方。基于以上断言，对零信任安全容器所要使用的任何数据进行根据零信任安全策略的验证。针对零信任安全容器，数据的验证涉及验证发起方和验证操作方。验证发起方包括其他bundle/SDK、容器内部、小程序、网络流量等；而验证操作方包括平台触发、外部网路触发、小程序自主触发、用户自主触发等。
上述的零信任安全策略针对要使用的数据，将具体化为访问控制策略。针对零信任安全容器，在使用数据时，访问控制策略采用基于角色的访问控制(Role-based Access Control，RBAC)，即角色决定权限，基于角色进行权限分层并采取最小权限原则。RBAC单纯地将使用者和权限进行解耦，将使用者与角色、角色与权限关联。角色是为许多拥有相似权限的使用者进行的分类管理，角色具有上下级关系，可形成树状结构，父级角色的权限是自身以及子角色权限的总和。
在本公开一实施例中，针对零信任安全容器的访问控制策略进一步包括针对要写入数据池的数据，验证数据的来源；以及准入来源得到验证的数据，其中准入数据贴有来源标签。在本公开一实施例中，数据的来源可包括网络、bundle、容器自身、jsapi等。本领域技术人员可以理解，数据的来源可包括非穷尽的其他来源，在此不做赘述。
在本公开另一实施例中，针对零信任安全容器的访问控制策略进一步包括针对要写入数据池的数据，验证数据的来源和数据写入方的角色；以及准入来源和数据写入方的角色得到验证的数据，其中准入数据贴有来源标签和数据写入方的角色标签。
在本公开又一实施例中，针对零信任安全容器的访问控制策略还包括针对要从数据池读取的数据，验证数据读取方提供的来源、数据写入方的角色和数据读取方的角色； 以及准出来源、数据写入方的角色和数据读取方的角色得到验证的数据。
该针对零信任安全容器的访问控制策略是自适应的，即利用机器学习来设置上下文相关访问策略，自动调整并适应该策略。
在数据使用时，数据使用的方向性是明确的，即数据池内的数据能够被定向读取。在验证发起方和验证操作方被明确确定时，指定数据能够被访问。
本领域技术人员可以理解，上述的零信任安全策略还可具体化为其他访问控制策略，例如自主访问控制(Discretionary Access Control，DAC)、强制访问控制(Mandatory Access Control，MAC)、Bell-Lapadula安全模型、以及Biba安全模型等等。进一步地，这些访问控制策略可依据不同的应用场景针对不同层级的数据进行组合配置。在此对访问控制策略的设置不作赘述。
在108，基于零信任安全策略分层级隔离数据池内的数据，以使得该数据池内的数据能够被定向读取。
Linux容器采用Namespace来实现“隔离”。Namespace修改了应用进程看待整个计算机的“视图”，即应用进程只能“看到”某些指定的内容。而对于宿主机来说这些被“隔离”了的进程跟其他进程并没有区别。
由于使用Namespace作为隔离手段的容器并不需要单独的Guest OS，这使得容器额外的资源占用几乎可以忽略不计；然而，这也造成了隔离并不彻底的问题，因为多个容器之间使用的还是同一宿主机的操作系统内核。进一步地，Linux内核中的很多资源和对象是不能被Namespace化的，例如时间。
因此采用Linux Cgroups来限制一个进程组能够使用的资源上限，包括CPU、内存、磁盘、网络带宽等等。另外，Cgroups还能够对进程进行优先级设置、审计，以及将进程挂起和恢复等操作。
容器的以上隔离仅仅是在框架上将小程序与平台方应用隔离开，对于数据池内的数据并未进行隔离。
针对数据池内的数据，可进行不同层级的管控以将数据安全隔离。从不同维度可对数据进行粗粒度和细粒度的管控。在安全容器的数据管控中，仅对敏感数据进行管控为粗粒度的管控。而不仅管控敏感数据、而且管控运行时数据，则为细粒度的管控。
如图2所示，将在其他维度分层级对数据池内的数据进行隔离。即，在粗粒度层面上，对服务器之间的数据流做了访问控制，例如将不同来源的数据作隔离。而在细粒度层面上，基于角色(或身份，在本公开中概称为“角色”)和来源等来限制数据访问。对数据池内的每一个数据加上角色和来源标签，具有不同角色标签和来源标签的数据都 相互隔离。
为了可以进一步提升数据访问的确定性，需要对角色在访问生命周期进行持续的动态验证，尤其是当上下文有变化的情况下，例如环境上下文、时空上下文、操作上下文、路径依赖等等。在零信任安全容器中，不信任任何数据读写方的零信任安全策略促使对使用数据的角色进行持续的动态验证，由此提高数据的安全性。
在本公开一实施例中，只有角色和来源标签明确的数据才能够被写入数据池；而数据读取方需要携带自身角色以及目标角色才能准确读取数据。由此，该数据池内的数据能够被定向读取。
因此，本公开所揭示的零信任安全容器的数据管控方法对进出数据池的数据进行验证，并对数据池内的数据进行隔离，由此确保零信任安全容器的数据安全。亦即，通过对容器所要使用的所有数据进行更细粒度的管控来实现对安全容器的严格数据管控。
图2是示出根据本公开一实施例的对零信任安全容器进行数据管控的过程的示意图。本公开的零信任安全容器的数据池对于所有数据，都进行准入准出验证、隔离存储以及定向读取和使用。
如图2所示，在本公开一实施例中，数据在进入数据池之前，将进行来源和数据写入方角色的验证。来源和数据写入方角色得到验证的数据被准入；相反来源或数据写入方角色不明确或得不到验证的数据不被准入。被准入的数据都被加上来源标签和数据写入方角色标签。
而在本公开另一实施例中，数据在进入数据池之前，将进行来源的验证。来源得到验证的数据被准入；相反来源不明确或得不到验证的数据不被准入。被准入的数据都被加上来源标签。
在本公开又一实施例中，数据在进入数据池之前，将进行数据写入方角色的验证。数据写入方角色得到验证的数据被准入；相反数据写入方角色不明确或得不到验证的数据不被准入。被准入的数据都被加上数据写入方角色标签。
针对数据池内的数据，可进行不同层级的管控以将数据安全隔离。从不同维度可对数据进行粗粒度和细粒度的管控。在安全容器的数据管控中，仅对敏感数据进行管控为粗粒度的管控。而不仅管控敏感数据、而且管控运行时数据，则为细粒度的管控。
如图2所示，则从数据的来源、数据写入方角色、数据读取方角色的维度来进行管控。在本公开一实施例中，数据可进行粗粒度的管控。例如，根据数据来源对数据进行分类或分级，形成不同数据域。数据将加上来源标签。又例如，根据数据读写方角色对数据进行分类或分级，形成不同数据域。数据将加上角色标签。在根据数据来源形成不 同数据域的情形中，可按来自不同的web服务器、应用服务器、数据库等来隔离数据，以使得源自不同服务器的数据能够分区域存储。并且，进一步地，web服务器只能访问对应的应用服务器的数据，而应用服务器只能访问对应的数据库的数据。
在本公开另一实施例中，数据可进行细粒度的管控。举例而言，根据数据来源和数据读写方角色来对数据进行分类分级，形成不同的数据域。具体地，对数据池内的每一个数据都加上角色和来源标签，具有不同角色标签和来源标签的数据都相互隔离，从而实现按角色和来源标签的数据隔离。
在数据池内的数据分不同数据域隔离后，各个数据域可设置相应的保护等级这意味着数据在生成之后，在其存储、使用和传输的整个生命周期都根据对应的安全策略提供不同强度的安全防护。
要获取数据池内的数据，在本公开一实施例中，同样读取方在指明双标签(即角色标签和来源标签)的情况下才可读取。读取方需要携带读取方角色(自身身份)以及数据写入方角色(目标身份)进行读取。举例而言，功能开发者需要知道自己使用的参数的上游标签才能准确获取参数。对于数据而言，需要经过角色和来源的验证才可被准出。由此，数据可以实现定向读取，即能够指明双标签的读取方可以读取数据。
而在本公开另一实施例中，读取方在指明来源标签的情况下才可读取。对于数据而言，需要经过来源的验证才可被准出。由此，数据可以实现定向读取，即能够指明来源标签的读取方可以读取数据。
在本公开又一实施例中，读取方在指明数据写入方角色情况下才可读取。对于数据而言，需要经过数据写入方角色的验证的数据才可被准出。由此，数据可以实现定向读取，即能够指明数据写入方角色标签的读取方可以读取数据。
图3是示出根据本公开一实施例的对零信任安全容器的数据管控能够达成的风险隔离的示意图。
根据本公开一实施例，由于如上所述的对零信任安全容器的数据管控，数据准入时的验证将使得该数据无法被利用作为攻击载荷，数据准出时的验证将阻止内部数据被外部窃取、并防止各种隐私泄露风险以保证数据安全，而数据的定向读取则可防止外部数据对内部机制运行的干扰，从而防止安全漏洞。
在本公开中，由于采用细粒度的数据管控，将敏感数据和运行时数据都纳入了管控，因此才使得数据与风险相隔离、安全得到保障。
图4是示出根据本公开一实施例的零信任安全容器的数据池架构的示意图。
如图4所示，根据本公开一实施例，在Android系统的容器核心组件中，采用 Namespace实现“进程隔离”，而采用Cgroups实现“权限隔离”。容器核心组件的运行参数和启动参数作为运行时数据进入容器数据中心。
容器数据中心的数据池为零信任安全容器共享。任意容器中需要使用的外部输入参数，都只能从该数据池中获取，比如白名单、启动参数、jsapi参数、开关配置等。
容器数据中心的数据池配置有入口海关和出口海关，以对进出数据池的数据分别进行验证。数据池的数据来自容器核心组件、调用来源、容器依赖组件等等。容器核心组件的运行参数和启动参数、来自调用来源的数据、以及容器依赖组件的文件数据和用户隐私数据等等通过入口海关进入数据池。
数据准入是写入数据前验证数据的过程，只有经过身份校验的数据才允许被写入池中。在本公开一实施例中，如图4所示，数据的身份校验可以是来源和角色双校验。进入数据池中的每一个数据都带有两个标签，即角色标签和来源标签。在本公开另一实施例中，数据的身份校验可以是来源或角色之一的校验。
数据准出是输出数据前验证数据读取方的过程。在本公开一实施例中，读取方需要携带自身身份以及目标身份才能准确读取数据，且读取行为会被记录和管控。
在本公开一实施例中，如图4所示，在容器数据中心的数据池中，不同角色标签和来源标签的参数相互隔离，并存储在不同的数据域中，例如第一数据域、第二数据域、第三数据域、第四数据域等。在这些数据域中，文件数据、内存数据、网络数据等等可分开存储。
在该实施例中，这些数据域中的数据只有指明双标签的情况下才可读写，亦即功能开发者需要知道自己使用的参数的上游标签才能准确获取参数。该两类标签的生成由容器自身代码产生，不由读写的发起方生成。容器根据数据的来源(即，网络/其他bundle/容器自身/jsapi)自主判断准入数据的来源标签和角色来源。
对生成的角色标签和来源标签需要建立对应的资产库以及基于角色标签和来源标签的管控能力，在此不做赘述。
本领域技术人员可以理解，如图4所示的零信任安全容器的数据池架构仅作为示例而非限制，数据的隔离可按图2所示依据不同维度根据场景来不同层级地进行。数据的标签也可根据场景的不同来不同地施加，并进行相应不同的准入、准出和隔离。
图5是示出根据本公开一实施例的零信任安全容器的容器数据管控系统500的框图。
容器数据管控系统500包括零信任策略模块502、数据池构建模块504、零信任验证模块506以及数据隔离模块508。
零信任策略模块502依据场景生成零信任安全策略。
本公开的零信任安全容器对于所有的输入数据都不信任，不管其来自应用平台、小程序还是其他bundle。在Android系统中，bundle主要用于传递数据，它保存的数据是以key-value(键值对)的形式存在的。数据需要经过多重验证后才被准入。同样，本公开的零信任安全容器对于所有索要数据输出的读取方都不信任，不论该读取方是应用平台、小程序还是其他bundle。数据需要经过多重验证后才被准出。
数据被准入准出之前的多重验证是基于零信任安全策略进行的。零信任安全策略的断言包括：应该始终假设充满威胁；容器外部、小程序、甚至容器内部每时每刻都充斥着威胁；不能仅仅凭借标签或参数来建立信任关系。零信任安全策略实际上可作为访问控制策略的底层设计。
在不同场景中，零信任安全策略可依据以上的原则进行调整。由此，零信任策略模块502可依据场景生成相应的零信任安全策略。零信任策略模块502依据场景所生成的零信任安全策略被传递给零信任验证模块506和数据隔离模块508。
数据池构建模块504构建零信任安全容器的数据池。
基于图4所示的架构，要针对零信任安全容器进行数据管控，数据池构建模块504首先构建该零信任安全容器的数据池。该数据池的输入端、输出端和内部都将基于零信任安全进行数据管控。所有容器需要的敏感数据和运行时数据都被纳入数据池，并且在输入、输出和内部运作时基于零信任安全策略进行验证。
零信任验证模块506针对要出入数据池的数据采取零信任安全策略，其中要出入数据池的数据在根据零信任安全策略验证后才被准入准出。
敏感数据和运行时数据将进入数据池构建模块504所构建的容器的共享数据池。要对出入数据池的数据进行管控，零信任验证模块506需要采取零信任安全策略。所采取的零信任安全策略的断言包括：应该始终假设充满威胁；容器外部、小程序、甚至容器内部每时每刻都充斥着威胁；不能仅仅凭借标签或参数来建立信任关系。上述的零信任安全策略实质上包括不信任任何数据读写方。
上述的零信任安全策略针对要使用的数据，将具体化为访问控制策略。在本公开一实施例中，零信任验证模块506针对零信任安全容器的访问控制策略进一步包括针对要写入数据池的数据，验证数据的来源；以及准入来源得到验证的数据，其中准入数据贴有来源标签。
在本公开另一实施例中，零信任验证模块506针对零信任安全容器的访问控制策略进一步包括针对要写入数据池的数据，验证数据的来源和数据写入方的角色；以及准入来源和数据写入方的角色得到验证的数据，其中准入数据贴有来源标签和数据写入方的 角色标签。
在本公开又一实施例中，零信任验证模块506针对零信任安全容器的访问控制策略还包括针对要从数据池读取的数据，验证数据读取方提供的来源、数据写入方的角色和数据读取方的角色；以及准出来源、数据写入方的角色和数据读取方的角色得到验证的数据。
数据隔离模块508基于零信任安全策略分层级隔离数据池内的数据，以使得数据池内的数据能够被定向读取。
针对数据池内的数据，数据隔离模块508可进行不同层级的管控以将数据安全隔离。从不同维度可对数据进行粗粒度和细粒度的管控。在安全容器的数据管控中，仅对敏感数据进行管控为粗粒度的管控。而不仅管控敏感数据、而且管控运行时数据，则为细粒度的管控。
如图2所示，数据隔离模块508将在其他维度分层级对数据池内的数据进行隔离。即，在粗粒度层面上，对服务器之间的数据流做了访问控制，例如将不同来源的数据作隔离。而在细粒度层面上，基于角色(或身份，在本公开中概称为“角色”)和来源等来限制数据访问。对数据池内的每一个数据加上角色和来源标签，具有不同角色标签和来源标签的数据都相互隔离。
由此，数据隔离模块508基于零信任安全策略分层级隔离数据池内的数据之后，将使得数据池内的数据能够被定向调用。即，在数据使用时，数据使用的方向性是明确的，即数据池内的数据能够被定向读取。
因此，本公开所揭示的零信任安全容器的数据管控系统对进出数据池的数据进行验证，并对数据池内的数据进行隔离，由此确保零信任安全容器的数据安全。亦即，通过对容器所要使用的所有数据进行更细粒度的管控来实现对安全容器的严格数据管控。
以上描述的零信任安全容器的数据管控方法和系统的各个步骤和模块可以用硬件、软件、或其组合来实现。如果在硬件中实现，结合本发明描述的各种说明性步骤、模块、以及电路可用通用处理器、数字信号处理器(DSP)、专用集成电路(ASIC)、现场可编程门阵列(FPGA)、或其他可编程逻辑组件、硬件组件、或其任何组合来实现或执行。通用处理器可以是处理器、微处理器、控制器、微控制器、或状态机等。如果在软件中实现，则结合本发明描述的各种说明性步骤、模块可以作为一条或多条指令或代码存储在计算机可读介质上或进行传送。实现本发明的各种操作的软件模块可驻留在存储介质中，如RAM、闪存、ROM、EPROM、EEPROM、寄存器、硬盘、可移动盘、CD-ROM、云存储等。存储介质可耦合到处理器以使得该处理器能从/向该存储介质读写信息，并执 行相应的程序模块以实现本发明的各个步骤。而且，基于软件的实施例可以通过适当的通信手段被上载、下载或远程地访问。这种适当的通信手段包括例如互联网、万维网、内联网、软件应用、电缆(包括光纤电缆)、磁通信、电磁通信(包括RF、微波和红外通信)、电子通信或者其他这样的通信手段。
还应注意，这些实施例可能是作为被描绘为流程图、流图、结构图、或框图的过程来描述的。尽管流程图可能会把诸操作描述为顺序过程，但是这些操作中有许多操作能够并行或并发地执行。另外，这些操作的次序可被重新安排。
所公开的方法、装置和系统不应以任何方式被限制。相反，本发明涵盖各种所公开的实施例(单独和彼此的各种组合和子组合)的所有新颖和非显而易见的特征和方面。所公开的方法、装置和系统不限于任何具体方面或特征或它们的组合，所公开的任何实施例也不要求存在任一个或多个具体优点或者解决特定或所有技术问题。
上面结合附图对本发明的实施例进行了描述，但是本发明并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本发明的启示下，在不脱离本发明宗旨和权利要求所保护的范围情况下，还可做出很多更改，这些均落在本发明的保护范围之内。

Claims (19)

  1. 一种零信任安全容器的数据管控方法，包括：
    依据场景生成零信任安全策略；
    构建零信任安全容器的数据池；
    针对要出入所述数据池的数据采取所述零信任安全策略，其中要出入所述数据池的数据在根据所述零信任安全策略验证后才被准入准出；以及
    基于所述零信任安全策略分层级隔离所述数据池内的数据，以使得所述数据池内的数据能够被定向读取。
  2. 如权利要求1所述的方法，所述零信任安全策略包括不信任任何数据读写方。
  3. 如权利要求2所述的方法，所述零信任安全策略包括：
    针对要写入所述数据池的数据，验证来源；以及
    准入所述来源得到验证的数据，其中所述准入数据贴有来源标签。
  4. 如权利要求2所述的方法，所述零信任安全策略包括：
    针对要写入所述数据池的数据，验证来源和数据写入方的角色；以及
    准入所述来源和所述数据写入方的角色得到验证的数据，其中所述准入数据贴有来源标签和所述数据写入方的角色标签。
  5. 如权利要求3所述的方法，所述零信任安全策略包括：
    针对要从所述数据池读取的数据，验证数据读取方提供的来源、所述数据写入方的角色和所述数据读取方的角色；以及
    准出所述来源、所述数据写入方的角色和所述数据读取方的角色得到验证的数据。
  6. 如权利要求1所述的方法，所述依据所述零信任安全策略分层级隔离所述数据池内的数据包括将所述数据池隔离成多个数据域。
  7. 如权利要求6所述的方法，所述将所述数据池隔离成多个数据域包括按照敏感数据和运行时数据将所述数据隔离到所述多个数据域中。
  8. 如权利要求6所述的方法，所述将所述数据池隔离成多个数据域包括按照来源和/或角色将所述数据隔离到所述多个数据域中。
  9. 如权利要求6所述的方法，所述多个数据域被设置相应的保护等级。
  10. 一种零信任安全容器的数据管控系统，包括：
    零信任策略模块，依据场景生成零信任安全策略；
    数据池构建模块，构建零信任安全容器的数据池；
    零信任验证模块，针对要出入所述数据池的数据采取所述零信任安全策略，其中要 出入所述数据池的数据在根据所述零信任安全策略验证后才被准入准出；以及
    数据隔离模块，基于所述零信任安全策略分层级隔离所述数据池内的数据，以使得所述数据池内的数据能够被定向读取。
  11. 如权利要求10所述的系统，所述零信任安全策略包括不信任任何数据读写方。
  12. 如权利要求11所述的系统，所述零信任安全策略包括：
    针对要写入所述数据池的数据，验证来源；以及
    准入所述来源得到验证的数据，其中所述准入数据贴有来源标签。
  13. 如权利要求11所述的系统，所述零信任安全策略包括：
    针对要写入所述数据池的数据，验证来源和数据写入方的角色；以及
    准入所述来源和所述数据写入方的角色得到验证的数据，其中所述准入数据贴有来源标签和所述数据写入方的角色标签。
  14. 如权利要求11所述的系统，所述零信任安全策略包括：
    针对要从所述数据池读取的数据，验证数据读取方提供的来源、所述数据写入方的角色和所述数据读取方的角色；以及
    准出所述来源、所述数据写入方的角色和所述数据读取方的角色得到验证的数据。
  15. 如权利要求10所述的系统，所述数据隔离模块基于所述零信任安全策略分层级隔离所述数据池内的数据包括所述数据隔离模块将所述数据池隔离成多个数据域。
  16. 如权利要求15所述的系统，所述数据隔离模块将所述数据池隔离成多个数据域包括所述数据隔离模块按照敏感数据和运行时数据将所述数据隔离到所述多个数据域中。
  17. 如权利要求15所述的系统，所述数据隔离模块将所述数据池隔离成多个数据域包括所述数据隔离模块按照来源和角色将所述数据隔离到所述多个数据域中。
  18. 如权利要求15所述的系统，所述多个数据域被设置相应的保护等级。
  19. 一种存储有指令的计算机可读存储介质，当所述指令被执行时使得机器执行如权利要求1-9中任一项所述的方法。
PCT/CN2022/125182 2021-10-29 2022-10-13 零信任安全容器的数据管控 WO2023071819A1 (zh)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP22885698.5A EP4345661A4 (en) 2021-10-29 2022-10-13 DATA MANAGEMENT AND CONTROL METHOD FOR SYSTEMATICALLY VERIFIED SECURITY CONTAINER
US18/543,709 US20240119127A1 (en) 2021-10-29 2023-12-18 Data control for zero-trust security container

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202111269968.0 2021-10-29
CN202111269968.0A CN114003865A (zh) 2021-10-29 2021-10-29 零信任安全容器的数据管控方法和系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/543,709 Continuation US20240119127A1 (en) 2021-10-29 2023-12-18 Data control for zero-trust security container

Publications (1)

Publication Number Publication Date
WO2023071819A1 true WO2023071819A1 (zh) 2023-05-04

Family

ID=79925035

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2022/125182 WO2023071819A1 (zh) 2021-10-29 2022-10-13 零信任安全容器的数据管控

Country Status (4)

Country Link
US (1) US20240119127A1 (zh)
EP (1) EP4345661A4 (zh)
CN (1) CN114003865A (zh)
WO (1) WO2023071819A1 (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN114003865A (zh) * 2021-10-29 2022-02-01 支付宝(杭州)信息技术有限公司 零信任安全容器的数据管控方法和系统

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170163652A1 (en) * 2015-09-25 2017-06-08 T-Mobile, U.S.A. Inc. Secure data corridors
US20190213346A1 (en) * 2018-01-09 2019-07-11 Randy Friedman System and method of decentralized services to make federated raw data sets self-governing for secure sharing and commingling
CN111131160A (zh) * 2019-11-25 2020-05-08 中科边缘智慧信息科技（苏州）有限公司 一种用户、服务及数据认证系统
CN112149105A (zh) * 2020-10-21 2020-12-29 腾讯科技（深圳）有限公司 数据处理系统、方法、相关设备及存储介质
CN114003865A (zh) * 2021-10-29 2022-02-01 支付宝(杭州)信息技术有限公司 零信任安全容器的数据管控方法和系统

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112100675B (zh) * 2020-11-05 2021-02-12 南京云信达科技有限公司 一种零信任的数据存储访问方法及系统
CN113507462B (zh) * 2021-07-05 2023-02-17 中国联合网络通信集团有限公司 零信任的数据监测预警方法、装置、系统和存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170163652A1 (en) * 2015-09-25 2017-06-08 T-Mobile, U.S.A. Inc. Secure data corridors
US20190213346A1 (en) * 2018-01-09 2019-07-11 Randy Friedman System and method of decentralized services to make federated raw data sets self-governing for secure sharing and commingling
CN111131160A (zh) * 2019-11-25 2020-05-08 中科边缘智慧信息科技（苏州）有限公司 一种用户、服务及数据认证系统
CN112149105A (zh) * 2020-10-21 2020-12-29 腾讯科技（深圳）有限公司 数据处理系统、方法、相关设备及存储介质
CN114003865A (zh) * 2021-10-29 2022-02-01 支付宝(杭州)信息技术有限公司 零信任安全容器的数据管控方法和系统

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP4345661A4 *

Also Published As

Publication number Publication date
EP4345661A4 (en) 2024-06-12
EP4345661A1 (en) 2024-04-03
US20240119127A1 (en) 2024-04-11
CN114003865A (zh) 2022-02-01

Similar Documents

Publication Publication Date Title
Subramanian et al. Recent security challenges in cloud computing
US10747875B1 (en) Customizing operating system kernels with secure kernel modules
Jia et al. Run-time enforcement of information-flow properties on Android
EP3140770B1 (en) Attestation of a host containing a trusted execution environment
Yasrab Mitigating docker security issues
Albaroodi et al. Critical Review of OpenStack Security: Issues and Weaknesses.
Kumar et al. Exploring security issues and solutions in cloud computing services–a survey
Bojanova et al. Trusting the internet of things
US20240119127A1 (en) Data control for zero-trust security container
Mustyala et al. Advanced Security Mechanisms in Kubernetes: Isolation and Access Control Strategies
Dahiya Cloud Security Essentials for Java Developers Protecting Data and Applications in a Connected World
Saha Machine learning-based efficient and generalizable cybersecurity frameworks
Zhang et al. Hybrid isolation model for device application sandboxing deployment in Zero Trust architecture
Varadharajan et al. Techniques for Enhancing Security in Industrial Control Systems
Sethi et al. Cloud security issues and challenges
Duncan et al. Cloud cyber security: finding an effective approach with unikernels
Lerner Trustworthy embedded computing for cyber-physical control
Dunkerley et al. Mastering Windows Security and Hardening: Secure and protect your Windows environment from intruders, malware attacks, and other cyber threats
Ansari et al. Smart Homes App Vulnerabilities, Threats, and Solutions: A Systematic Literature Review
Wu et al. An active data leakage prevention model for insider threat
Podjarny et al. Serverless security
Arakelyan Vulnerable Security Problems in Learning Management System (LMS) Moodle
Reti et al. Escape the fake: Introducing simulated container-escapes for honeypots
Al Khateeb et al. Securing Data in a Cloud Environment: Access Control, Encryption, and Immutability
Kern et al. Using RBAC to enforce the principle of least privilege in industrial remote maintenance sessions

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22885698

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 22885698.5

Country of ref document: EP

Ref document number: 2022885698

Country of ref document: EP

ENP Entry into the national phase

Ref document number: 2022885698

Country of ref document: EP

Effective date: 20231228

WWE Wipo information: entry into national phase

Ref document number: 11202309952X

Country of ref document: SG

NENP Non-entry into the national phase

Ref country code: DE