Object access method and apparatus

Abstract

The embodiment of the present disclosure provides a kind of guest access method and device, the method comprises: receiving the access request to target guest;Access request includes the subject information, object information and operation type of multiple access control layers;Each access control layer is arranged according to first order;According to the access control strategy configured for each access control layer and the subject information, object information and operation type of each access control layer, the access result of access request in each access control layer is sequentially obtained according to first order, until access flow end condition is satisfied;Access flow end condition includes: the latest access result obtained indicates that access is denied;Or, the access result of last access control layer in first order has been obtained, and the access result of last access control layer indicates that access is allowed;According to access result, the response information of access request is generated.Through the embodiment, the access control accuracy for guest can be improved.

Description

Technical Field

[0001] This document relates to the field of information security technology, and in particular to an object access method and apparatus. Background Technology

[0002] In related technologies, access control is a security mechanism to prevent unauthorized access to objects by abnormal subjects. In practical applications, an access control list can be pre-configured for each object. Specifically, the identifiers of each subject allowed to access the object can be centrally stored in the object's access control list. Then, when the system receives an access request from a specific subject to access the object, it can determine whether the specific subject is allowed to access the object based on the subject identifier carried in the access request and the identifiers of each subject in the access control list.

[0003] With the rapid development of internet technology, access restrictions on objects have become increasingly complex, leading to a growing demand from users for more precise access control. Therefore, the question of how to improve the precision of access control for objects has attracted increasing attention. Summary of the Invention

[0004] This disclosure provides an object access method and apparatus to improve the accuracy of access control for objects.

[0005] In a first aspect, embodiments of this disclosure provide an object access method, including: Receive an access request for a target object; the access request includes subject information, object information, and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer; Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are sequentially obtained in the first order until the access process termination condition is met; the access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed. Based on the access result, generate response information for the access request.

[0006] Secondly, embodiments of this disclosure provide an object access device, comprising: A request receiving unit is used to receive an access request for a target object; the access request includes subject information, object information, and operation type of multiple access control layers; each access control layer is arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer. The result acquisition unit is configured to, according to the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, sequentially acquire the access results of the access request at each access control layer in the first order, until the access process termination condition is met; the access process termination condition includes: the latest acquired access result indicates that access is denied; or, the access result of the last access control layer in the first order has been acquired, and the access result of the last access control layer indicates that access is allowed; The information generation unit is used to generate response information for the access request based on the access result.

[0007] Thirdly, embodiments of this disclosure provide an electronic device, including: a memory, a processor, and computer-executable instructions stored in the memory and executable on the processor, wherein the computer-executable instructions, when executed by the processor, implement the method described in the first aspect above.

[0008] Fourthly, embodiments of this disclosure provide a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the method described in the first aspect above.

[0009] Fifthly, embodiments of this disclosure provide a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the method described in the first aspect above.

[0010] In one or more embodiments of this disclosure, firstly, an access request for a target object is received; the access request includes subject information, object information, and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer; then, according to the access control policy configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained sequentially in the first order until the access process termination condition is met; the access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed; finally, response information for the access request is generated based on the access results. As can be seen, by mapping the initiator of the access request to different operation entities in each access control layer and mapping the target object to different object resources in each access control layer, an access request for the target object can be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, allowing each access control layer to determine whether the access request is allowed from different dimensions, and to access the access results of the request in each access control layer in a first order. The standardized access process avoids errors in access result judgment caused by information omissions, thus improving the accuracy of access control for objects. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in one or more embodiments of this disclosure, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments recorded in this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 A flowchart illustrating an object access method provided in an embodiment of this disclosure; Figure 2 This is a schematic diagram of the structure of an object access device provided in an embodiment of the present disclosure; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present disclosure. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this disclosure, the technical solutions in one or more embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of the embodiments. Based on one or more embodiments of this disclosure, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0014] This disclosure provides an object access method and apparatus that enables precise access control over objects. The object access method can be applied to a server-side device, which can be a single server, a server cluster consisting of several servers, or one or more cloud servers within a cloud computing platform.

[0015] Figure 1 This is a flowchart illustrating an object access method according to an embodiment of this disclosure. Figure 1 As shown, the process includes: Step S102: Receive an access request for the target object; the access request includes subject information, object information and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer.

[0016] Step S104: Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained in the first order until the access process termination condition is met. The access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed.

[0017] Step S106: Generate response information for the access request based on the access result.

[0018] In this embodiment, firstly, an access request for a target object is received. The access request includes subject information, object information, and operation type of multiple access control layers. The access control layers are arranged in a first order. For each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer. Then, according to the access control policy configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained sequentially in the first order until the access process termination condition is met. The access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed. Finally, response information for the access request is generated based on the access results. As can be seen, by mapping the initiator of the access request to different operation entities in each access control layer and mapping the target object to different object resources in each access control layer, an access request for the target object can be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, allowing each access control layer to determine whether the access request is allowed from different dimensions, and to access the access results of the request in each access control layer in a first order. The standardized access process avoids errors in access result judgment caused by information omissions, thus improving the accuracy of access control for objects.

[0019] The following is a brief explanation of the relevant concepts of access control: A computer operating system is a program that manages and controls computer hardware and software resources; it is the kernel and foundation of a computer system. Access control is a core function of the operating system, used to restrict access and manipulation of objects by subjects to ensure system security. The subject initiates the access control operation, and the object is the subject being manipulated by the access control.

[0020] In step S102 above, an access request for a target object is received. In this embodiment, the target object refers to the recipient of the access request. In one example, the target object can be a virtual machine, a file, a hardware device, etc.

[0021] Access requests can be used to request the performance of a specific operation on a target object. In one example, the target object is a virtual machine, and an access request for the target object is used to request the creation of the virtual machine. Alternatively, the target object is file B within virtual machine A, and an access request for the target object is used to request the querying of contents within file B. Or, the target object is a hardware device, a "disk controller," and an access request for the target object is used to request the reading of physical disk data from the disk controller.

[0022] In step S102 above, the access request includes subject information, object information and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer.

[0023] In one example, the access control layers, arranged in the first order from top to bottom, are: tenant layer, virtual machine layer, user / process layer, and physical resource layer. Each access control layer is internally divided into multiple security domains. Subjects within a domain share access permissions, while domains are strictly isolated from each other. The access control layers follow a top-down access control path; upper-level subjects can only access lower-level resources through a directly adjacent lower-level subject.

[0024] For each access control layer, the subject information represents one or more operational entities mapped to the access control layer by the initiator of the access request. In this embodiment, the operational entities mapped to the initiator of the access request in each access control layer can be preset, and the operational entities mapped to the initiator in each access control layer may be different. In one example, the initiator of the access request can be represented by the user identifier "01". The multiple access control layers arranged in the first order are, from front to back: access control layer 1, access control layer 2, and access control layer 3, and the access control layers follow an access control path from front to back. The operational entity mapped to the user identifier "01" in access control layer 1 is tenant administrator X1; the operational entities mapped to the user identifier "01" in access control layer 2 include virtual machine Y1 and virtual machine Y2; the operational entity mapped to the user identifier "01" in access control layer 3 is physical network card Z1.

[0025] For each access control layer, the object information indicates that the target object maps to one or more types of object resources at the access control layer. In this embodiment, the object resources mapped to the target object at each access control layer can be preset, and the object resources mapped to the target object at each access control layer may be different. In one example, the target object can be represented by virtual machine Y1. The multiple access control layers arranged in the first order are, from front to back: access control layer 1, access control layer 2, access control layer 3, and access control layer 4, and the access control layers follow an access control path from front to back. The object resources mapped to virtual machine Y1 at access control layer 1 are the virtual machine cluster under tenant A; the object resources mapped to virtual machine Y1 at access control layer 2 are the virtual configuration resources of virtual machine Y1; the object resources mapped to virtual machine Y1 at access control layer 3 include the configuration management process and configuration files within virtual machine Y1; and the object resources mapped to virtual machine Y1 at access control layer 4 are the physical resource pool.

[0026] The following is a brief explanation of the relationship between target object and object resource: Target object refers to the abstract accessed object that is initially pointed to in the access request and is the target of the access request at the business level, while object resource refers to the concrete accessed resource that is mapped to the target object at a certain access control layer and conforms to the management attributes of that access control layer.

[0027] For each access control layer, the operation type refers to the type of specific operation performed by the operation entity mapped by the initiator of the access request on the object resource mapped by the target object in each access control layer.

[0028] In one example, the access request includes: a triple of access control layer 1: (subject information 1, object information 1, operation type x1), a triple of access control layer 2: (subject information 2, object information 2, operation type x2), a triple of access control layer 3: (subject information 3, object information 3, operation type x3), and so on.

[0029] In addition, access requests may also include environmental information from various access control layers. Environmental information refers to the background information related to the internal management of the access control layer, such as its real-time running status, inherent configuration rules, and resource association context, during the processing of the access request. This background information can serve as the contextual basis for obtaining the access result of the access request at the access control layer. In one example, the environmental information of access control layer 1 may include its static inherent environment, such as preset access rules and hardware configuration, etc. The environmental information of access control layer 1 may also include its dynamic real-time environment, such as resource utilization and process running status, etc.

[0030] In one example, the access request includes: a quadruple for access control layer 1: (subject information 1, object information 1, context information 1, operation type x1), a quadruple for access control layer 2: (subject information 2, object information 2, context information 2, operation type x2), a quadruple for access control layer 3: (subject information 3, object information 3, context information 3, operation type x3), and so on.

[0031] In one example, the target object is virtual machine Y1, and the access request is used to request the creation of the virtual machine. The object resources mapped by the target object in the access control layer refer to the concrete resources that each access control layer needs to manage to complete the goal of "virtual machine creation" and that are consistent with the attributes of that access control layer. For example, the object resources mapped by virtual machine Y1 in access control layer 1 include the virtual machine image, the object resources mapped by virtual machine Y1 in access control layer 2 include virtual memory, the object resources mapped by virtual machine Y1 in access control layer 3 include the virtual file system, and so on.

[0032] In one example, this embodiment can be implemented using an access control framework. The architecture of this framework can adopt a microkernel approach, centralizing access control functions into a single, independent access control module. This module, as part of the trusted computing base, runs in kernel mode and has the highest privileges. This access control module can include access control components for each access control layer. It is responsible for defining the access control policies for each access control layer and providing access control decision services to each layer. The operating system kernel corresponding to each access control layer interacts with this access control module through system calls, requesting access permissions at access control points. This centralized architecture facilitates unified management and global optimization of access control policies.

[0033] The access control module described above can also adopt the concept of SPM (Security Policy Model) to decouple the definition and execution of access control policies. The access control module only provides a general policy interpretation and execution engine, while specific access control rules are placed in a separate policy library. This policy library is written in a formal language and undergoes rigorous security and consistency verification. This decoupled design improves the flexibility of policy definition, allowing administrators to dynamically adjust policy rules according to actual needs without modifying the access control module's code.

[0034] In step S104 above, based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained sequentially in a first order until the access process termination condition is met. The access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed.

[0035] In one example, the multiple access control layers arranged in the first order are: Access Control Layer 1, Access Control Layer 2, and Access Control Layer 3. The access control layers follow a sequential access control path. Access control policy 1 is configured for Access Control Layer 1, Access Control Policy 2 is configured for Access Control Layer 2, and Access Control Policy 3 is configured for Access Control Layer 3. Based on Access Control Policy 1 and the subject, object, and operation types of Access Control Layer 1, the access result 1 of the access request at Access Control Layer 1 is obtained. If Access Result 1 indicates that access is allowed, then based on Access Control Policy 2 and the subject, object, and operation types of Access Control Layer 2, the access result 2 of the access request at Access Control Layer 2 is obtained. If Access Result 2 indicates that access is denied, the access process termination condition "the latest obtained access result indicates access denied" is met, and the access process ends.

[0036] In one example, the multiple access control layers arranged in the first order are: Access Control Layer 1, Access Control Layer 2, and Access Control Layer 3. The access control layers follow a sequential access control path. Access control policy 1 is configured for Access Control Layer 1, Access Control Policy 2 is configured for Access Control Layer 2, and Access Control Policy 3 is configured for Access Control Layer 3. Based on Access Control Policy 1 and the subject information, object information, and operation type of Access Control Layer 1, the access result 1 of the access request at Access Control Layer 1 is obtained. If access result 1 indicates that access is allowed, then based on Access Control Policy 2 and the subject information, object information, and operation type of Access Control Layer 2, the access result 2 of the access request at Access Control Layer 2 is obtained. If access result 2 indicates that access is allowed, then based on Access Control Policy 3 and the subject information, object information, and operation type of Access Control Layer 3, the access result 3 of the access request at Access Control Layer 3 is obtained. If access result 3 indicates that access is allowed, the access process termination condition "the access result of the last access control layer in the first sequence has been obtained, and the access result of the last access control layer indicates that access is allowed" is satisfied, and the access process ends.

[0037] In one example, access request 1 includes subject information 1, object information 1, background information 1, and operation type x1 of access control layer 1. Access control policy 1 is: allow the administrator of tenant A to remotely log in to virtual machine 1 of tenant B within the time period [08:00, 18:00]. Here, "administrator of tenant A" corresponds to subject information 1, "virtual machine 1 of tenant B" corresponds to object information 1, "time period [08:00, 18:00]" corresponds to background information 1, and "remote login" corresponds to operation type x1. In the process of obtaining the access result of access control layer 1 based on access control policy 1, subject information 1, object information 1, background information 1, and operation type x1, the following operations can be performed: determine whether subject information 1 matches "Tenant A's administrator"; determine whether object information 1 matches "Tenant B's virtual machine 1"; determine whether background information 1 matches "within the time period [08:00, 18:00]"; determine whether operation type x1 matches "remote login"; and determine the access result of access control layer 1 based on the obtained matching results.

[0038] In one embodiment, multiple access control layers include: a tenant layer, a virtual machine layer, a user process layer, and a physical resource layer. Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained sequentially in a first order, including: obtaining a first access result of the access request at the tenant layer based on a first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer; if the first access result indicates that access is allowed, obtaining a second access result of the access request at the virtual machine layer based on a second access control policy configured for the virtual machine layer and the subject information, object information, and operation type of the virtual machine layer; if the second access result indicates that access is allowed, obtaining a third access result of the access request at the user process layer based on a third access control policy configured for the user process layer and the subject information, object information, and operation type of the user process layer; and if the third access result indicates that access is allowed, obtaining a fourth access result of the access request at the physical resource layer based on a fourth access control policy configured for the physical resource layer and the subject information, object information, and operation type of the physical resource layer.

[0039] In this embodiment, the access control framework includes multiple access control layers, which are arranged in a first order as follows: tenant layer, virtual machine layer, user process layer, and physical resource layer. The access request includes: subject information, object information, and operation type of the tenant layer; subject information, object information, and operation type of the virtual machine layer; subject information, object information, and operation type of the user process layer; and subject information, object information, and operation type of the physical resource layer. That is, the access request involves a first number of access control layers, and the access control framework includes a second number of access control layers, where the first number equals the second number.

[0040] In this embodiment, the access control component of the tenant layer in the access control module can obtain the first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information and operation type of the tenant layer.

[0041] In one example, the tenant layer can be the top layer in the access control framework, achieving strong isolation between different tenants. Each tenant is treated as an independent security domain, i.e., a tenant domain, and each tenant domain has its own dedicated pool of physical resources, such as a dedicated physical machine cluster. There is no sharing of physical resources between different tenant domains, preventing malicious resource usage across tenants.

[0042] The entity that initiates the access request and maps to the operation at the tenant layer can be considered the subject of that tenant layer. The object resource that the target object of the access request maps to at the tenant layer can be considered the object of that tenant layer. The subject of the tenant layer can include the tenant administrator, and the object can include managed objects within the tenant, such as virtual machine images. Access control operations that are strongly associated with the tenant layer can include: creating / deleting virtual machines, migrating virtual machines, configuring virtual machine resources, etc.

[0043] Tenant administrators are assigned the "Tenant Domain Manager" role, which grants administrative privileges to all virtual machines within the domain. Cross-domain virtual machine access is prohibited to prevent the leakage of tenant private data. To address specific needs, such as cross-domain virtual machine collaboration, the tenant hierarchy can also support limited cross-tenant authorization. For example, the platform administrator can centrally define cross-domain resource access policies, allowing tenant administrators to grant cross-domain access permissions to designated virtual machines within their own domain. The platform administrator, together with the tenant administrator, uses a dual-signature mechanism to jointly complete cross-domain authorization and records audit logs to prevent abuse.

[0044] The key to implementing access control at the tenant layer lies in network isolation and authentication between tenant domains. All network traffic between tenant domains is reviewed by the access control module, prohibiting unauthorized cross-domain communication. The access control module also acts as a certificate distribution center for inter-tenant domain authentication, responsible for issuing, verifying, and revoking cross-domain communication certificates. By comprehensively utilizing network isolation and authentication, strict cross-tenant access control is achieved at both the communication and authentication levels.

[0045] The construction of the access control component in the tenant layer of the access control module involves the following steps: (a1) Divide tenant security domains and resource pools First, at the physical level, the hardware resources of the entire system need to be divided into multiple resource pools. Each resource pool is assigned to a tenant, serving as that tenant's security domain, or tenant domain. The granularity of resource pool division can be rack-level, physical machine-level, or CPU (Central Processing Unit) core-level, taking into account factors such as physical isolation, resource utilization, and scalability. The division results need to be persistently stored as the system's static configuration.

[0046] In practice, based on the cloud infrastructure management platform, its compute and storage services can be used to assign physical machines and storage devices to different tenants. The cloud infrastructure management platform supports organizing physical machines into independent availability zones, mapping each availability zone to a tenant. Using its filter scheduler mechanism, it can be specified that each tenant's virtual machines can only be scheduled to their own availability zone, prohibiting cross-zone scheduling.

[0047] (a2) Define the cross-domain resource access strategy model To unify the cross-tenant authorization mechanism, platform administrators need to predefine a general cross-domain resource access policy model. Utilizing the principles of XACML (eXtensible Access Control Markup Language), the authorization semantics are characterized using a four-tuple of "subject-object-context-operation". For example, access control policy 1 is: Allow the administrator of tenant A to remotely log in to virtual machine 1 of tenant B during the time period [08:00, 18:00].

[0048] The cross-domain resource access strategy model also needs to introduce a Role-Based Access Control (RBAC) mechanism, defining roles such as administrators and cloud server users within each tenant domain. The platform administrator uniformly plans the permission limits for each cross-tenant role. Within these limits, tenant administrators automatically assign permissions to roles within their own domain, thereby achieving hierarchical and layered management of cross-tenant permissions.

[0049] In practice, a standard policy description language can be defined, and a policy editing and conflict detection tool can be developed based on this language. Platform administrators use this tool to define the top-level cross-domain resource access policy library, and after the conflict detection is successful, it is stored in the global policy library of the access control framework.

[0050] (a3) Construct a cross-tenant identity authentication system Cross-tenant authentication is the foundation of inter-tenant domain access control. First, each tenant implements unified authentication, assigning a unique ID (identifier) ​​to each legitimate user. For cross-tenant authentication, a federated authentication model can be used, with the platform administrator acting as the federated authentication service provider.

[0051] For example, when a user of tenant A needs to access resources of tenant B, they initiate a federated authentication request to the platform's authentication server. The authentication service obtains the user's identity assertion from tenant A, verifies it, and issues a federated identity authentication token by combining the user ID and the tenant's domain ID, which is then issued to the user. When the user uses this token to request resources from tenant B, tenant B verifies the token's signature and validity period, thus confirming the user's identity.

[0052] In practical implementation, a federated identity authentication service can be built based on an open-source identity authentication framework. Resource providers can subscribe to events on the server side to receive user federated identity tokens, or the client can present the token when accessing resources; both methods support cross-tenant authentication. The authentication process should use a secure channel throughout to prevent the possibility of token eavesdropping or tampering.

[0053] (a4) Synchronize metadata between tenant domains To support cross-tenant authorization, necessary resource metadata, such as virtual machine inventories and file share inventories, needs to be synchronized among tenants. This metadata forms the basis for formulating cross-tenant authorization policies.

[0054] The specific synchronization mechanism is as follows: Each tenant designates a metadata synchronization agent, responsible for periodically publishing the resource metadata of its domain to the platform's registry center. The registry center performs global aggregation of the metadata, generating a global view. Other tenants can access the registry center and subscribe to the resource metadata they are interested in. When metadata changes, the synchronization agent incrementally synchronizes the changes to the registry center, which then notifies the subscribers.

[0055] In practice, publish-subscribe mechanisms such as message queues can be used to synchronize metadata. It is important to note that, for security reasons, resource metadata must be anonymized, hiding sensitive information such as IP (Internet Protocol) addresses. Simultaneously, subscriber permissions should be strictly limited, allowing subscriptions only to resources that are authorized for access.

[0056] (a5) Implement access control based on software-defined networking Traditional networks can only achieve Layer 2 isolation between tenants, while SDN (Software-Defined Networking) can achieve finer-grained access control. In this embodiment, SDN can be used to build an access control sub-framework between tenant domains.

[0057] In practice, each tenant configures an SDN controller within its domain, known as a tenant controller. The tenant controller manages the virtual switches within the domain and issues flow table rules. Tenant administrators register the tenant controllers within their domain with the platform for unified management.

[0058] The platform establishes a global SDN controller, responsible for configuring cross-domain communication access control policies on border switches between different tenant domains. Policy rules can limit communication based on the five-tuple (source IP, destination IP, source port, destination port, and protocol type). The global controller automatically generates flow table rules based on the cross-domain resource access policy library, allowing only policy-permitted cross-domain traffic and marking packets for identification by switches on the link.

[0059] The tenant controller and the global controller work together via the east-westbound API (east-westbound Application Programming Interface). When a virtual machine within a tenant initiates a cross-domain request, the local domain controller intercepts the request and sends an authorization decision request to the global controller. The global controller checks whether the request complies with the cross-domain policy and feeds back the decision to the local domain controller. Based on this, the local domain controller configures the flow tables of its domain border switch. After the request passes through the local domain border switch, the destination tenant's border switch identifies the inter-domain label of the data packet, executes the flow table rules configured by the global controller, and allows / denies the request to enter its domain.

[0060] By utilizing the aforementioned access control sub-framework for tenant domains built with SDN, the granularity of access control within and outside the domain can be flexibly customized, and the centralized control plane facilitates the unified distribution of access control policies.

[0061] By performing the above steps (a1)-(a5), the access control component of the tenant layer in the access control module can be constructed.

[0062] If the first access result indicates that access is denied, it can be determined that the access process termination condition "the latest access result indicates that access is denied" has been met, and the access process ends.

[0063] If the first access result indicates that access is permitted, the second access result of the access request at the virtual machine layer can be obtained based on the second access control policy configured for the virtual machine layer and the subject information, object information, and operation type of the virtual machine layer.

[0064] In this embodiment, the access control component in the virtual machine layer of the access control framework can obtain the first access result of the access request in the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information and operation type of the tenant layer.

[0065] In one example, the virtual machine layer sits below the tenant layer and is responsible for access control between different virtual machines within the same tenant. Within this virtual machine layer, each virtual machine is treated as a security domain, and virtual machines cannot communicate directly with each other by default, thus preventing unauthorized access between virtual machines.

[0066] The operation entity mapped to the initiator of the access request at the virtual machine layer can be considered the subject of that virtual machine layer. The object resource mapped to the target object of the access request at the tenant layer can be considered the object of that virtual machine layer. The subjects of the virtual machine layer include virtual machines, and the objects include other virtual machines and various virtual resources required by the virtual machines, such as virtual CPUs, virtual memory, and virtual hard disks. Cross-virtual machine access scenarios that are strongly related to the virtual machine layer can include: network communication between virtual machines, file sharing, and inter-process communication. For example, if a user of virtual machine A issues an access request to virtual machine B, and this access request is used to request file sharing between virtual machines A and B, then this access request is strongly related to the virtual machine layer.

[0067] Tenant administrators can explicitly define the set of virtual machines allowed to communicate and their permissions in the "Virtual Machine Trust" policy configured at the virtual machine level. The access control module intercepts all cross-virtual machine access requests, extracts attributes such as source and destination IPs, ports, and process IDs of the packets, matches them with the trust policy, and makes authorization decisions.

[0068] Access control within the virtual machine is handled by the lower-level user process layer. It is crucial to emphasize that the virtual machine layer must strictly restrict privileged operations performed by the virtual machine on the host machine, such as accessing host machine files or modifying virtual machine configurations. For example, sensitive operations via the virtual machine monitor can only be executed after authorization from the access control module.

[0069] Virtual machines, through dual isolation at the tenant and virtual machine levels, effectively resist virtual machine escape attacks. Even if an attacker compromises a virtual machine, it is difficult to breach the virtual machine boundary and affect other virtual machines. Furthermore, this embodiment can employ formal verification techniques to prove the security of the virtual machine monitor's access control mechanism, thereby minimizing potential threats.

[0070] The construction of the access control component at the virtual machine layer in the access control module involves the following steps: (b1) Define the virtual machine mutual trust strategy model First, a formal virtual machine mutual trust policy model needs to be defined to describe the set of virtual machines allowed to access each other and their permissions. Referring to the ABAC (Attribute-Based Access Control) model, this embodiment proposes a simplified mutual trust policy model, formally defined as follows: Policy = {<Sub, Obj, Env, Op, Dec>} In this context, Sub represents the attributes of the primary virtual machine, including the virtual machine ID, the owner user, and the security label; Obj represents the attributes of the object virtual machine or virtual resource, including the virtual machine ID, the resource type, and the security label; Env represents the environment attributes, such as the current time and the virtual machine's geographical location; Op represents the operation type, such as network communication and file read / write; and Dec represents the authorization decision, indicating whether to allow or deny access.

[0071] This model can characterize common cross-virtual machine trust scenarios, such as allowing all virtual machines belonging to user A to read a specific file from user B during working hours. Tenant administrators use this model to define trust policies within their tenants, and after conflict detection confirms no errors, synchronize the policy rules to the local policy library of each virtual machine monitoring program.

[0072] In practice, the definition, storage, and distribution of mutual trust policies can be achieved using MAC (Mandatory Access Control) frameworks. These frameworks provide policy languages ​​and compilation tools that translate high-level policies into low-level access control rules. They also utilize policy servers to implement distributed policy management.

[0073] (b2) Build a lightweight virtual machine monitoring program To implement fine-grained access control at the virtual machine level, a lightweight monitoring program needs to be deployed inside the virtual machine to intercept sensitive operations and initiate authorization requests to the virtual machine monitor on its behalf. This requires solving two problems: first, how to obtain sufficient semantic information inside the virtual machine for access control decisions; and second, how to prevent the monitoring program from being maliciously tampered with or bypassed by the virtual machine.

[0074] To address the first issue, this embodiment employs a library instrumentation-based solution. The monitoring program, in the form of a dynamic link library, is first loaded by the init (initialization) process when the virtual machine operating system starts. During loading, the monitoring program scans the operating system's import symbol table and instrumentes calls to sensitive API functions. When the virtual machine subsequently calls these functions, it will first jump to the corresponding stub function of the monitoring program. At runtime, the stub function extracts the call parameters (process PID, file path, network 5-tuple, etc.), along with the virtual machine's own metadata (such as the virtual machine ID), encapsulates them into an authorization request, and sends it to the virtual machine monitor.

[0075] Regarding the second issue, it is necessary to ensure that the monitoring program is not uninstalled prematurely or tampered with during runtime. This embodiment treats the monitoring program as a privileged module within a virtual machine, leveraging hardware virtualization features to achieve protection: On one hand, the monitoring program is loaded into the virtual machine's privileged memory. Using hardware features such as Intel EPT (Extended Page Tables), this memory region is set to read-only, and the virtual machine is not allowed to modify the EPT page tables. On the other hand, a monitor trap flag is set in the Intel VMCS (Virtual Machine Control Structure). When the virtual machine executes a sensitive instruction, it will trigger a VM Exit, forcibly trapping the virtual machine monitor. The virtual machine monitor checks the trap context; if it detects an attempt to modify the monitoring program's code or data, it rejects the operation, thus preventing the monitoring program from being bypassed or tampered with.

[0076] (b3) Integrate the access control subframework into the virtual machine monitor As the global manager of virtual machines, the virtual machine monitor is an ideal platform for implementing the virtual machine layer. For example, in a bare-metal virtual machine monitor, an access control subframe corresponding to the virtual machine layer can be integrated to receive authorization requests from the monitoring program and configure the underlying isolation mechanism accordingly.

[0077] The access control process of the access control subframework is as follows: When the monitoring program sends an authorization request, the access control subframework parses the subject and object attributes from the request and queries the mutual trust policy library for matching policy rules. If a match is found and the decision is "allow," the access control subframework calls the corresponding management API of the bare metal virtual machine monitor to configure the corresponding isolation rules. For virtual machine network communication, the access control subframework places the two virtual machines in the same virtual Layer 2 network; for virtual machine file sharing, the access control subframework grants the target virtual machine access permissions to the source virtual machine files by modifying file permissions and user mappings.

[0078] It's important to note that the access control subframework needs to avoid the overhead of duplicate authorizations. It persists the isolation rules in the virtual machine configuration during the initial authorization; subsequent virtual machines making the same request can directly query the authorization result without repeated configuration. However, if the mutual trust policy changes, the access control subframework needs to track the affected virtual machines and adjust the isolation rules accordingly.

[0079] (b4) Perform formal verification on the virtual machine monitor. To ensure the correctness of virtual machine monitor access control, this embodiment uses an interactive theorem prover based on high-order logic to formally verify its mutual trust strategy model and authorization mechanism.

[0080] Specifically, the syntax and semantics of the mutual trust strategy model are first formally defined, and it is proven that the model satisfies properties such as "completeness" and "consistency". Then, the implementation logic of the authorization mechanism is abstracted into a predicate, and it is proven that for any valid access request, this predicate is "equivalent" to the authorization decision given by the mutual trust strategy model. This requires manually introducing some preconditions and proof-aiding definitions, and finally completing the proof using various strategies of an interactive theorem prover based on higher-order logic.

[0081] By performing the above steps (b1)-(b4), the access control component of the virtual machine layer in the access control module can be constructed.

[0082] If the second access result indicates that access is denied, it can be determined that the access process termination condition "the latest access result indicates that access is denied" has been met, and the access process ends.

[0083] If the second access result indicates that access is permitted, the third access result of the access request at the user process layer can be obtained based on the third access control policy configured for the user process layer and the subject information, object information, and operation type of the user process layer.

[0084] In this embodiment, the access control component in the user process layer of the access control framework can obtain the third access result of the access request at the user process layer based on the third access control policy configured for the user process layer and the subject information, object information and operation type of the user process layer.

[0085] In one example, the user process layer manages permissions between user accounts and processes within the virtual machine. The operation entity mapped to the initiator of the access request at the user process layer can be considered the subject of this virtual machine layer. The object resource mapped to the target object of the access request at the tenant layer can be considered the object of this user process layer. This user process layer treats each user as a security subject, assigning different roles; then, based on the principle of least privilege, it customizes specific access permissions for each role. For example, roles could be administrators, regular users, visitors, etc. The objects of this user process layer cover all resources within the virtual machine, including the virtual file system, processes, network sockets, etc.

[0086] The access control module needs to delve deep into the virtual machine kernel, instrumenting critical paths for resource access to intercept each subject's (user / process) access to sensitive resources. When a process accesses a file, the module extracts the process's valid user ID, the file's security attributes, etc., queries the preset "subject-object-permission" triplet policy, and makes a real-time decision to allow or deny access.

[0087] For access control involving IPC (Inter-Process Communication), the user process layer follows the basic principles of "same origin" and "least privilege." By default, only inter-process communication within the same user is allowed, mitigating the infiltration of malicious processes. For necessary cross-user IPC, a capability list mechanism is used to explicitly grant processes the minimum communication permissions. Processes set access tags on IPC mechanisms such as message queues and shared memory, allowing only processes with legitimate capabilities to communicate with them, thus achieving fine-grained isolation between processes.

[0088] To prevent privilege escalation attacks within the virtual machine, the user process layer introduces the concept of Integrity Level (IL). Subjects and objects are divided into different integrity levels, and based on the Biba integrity model, control rules between ILs are defined: low-IL subjects are prohibited from writing to high-IL objects to prevent malicious modification of low-IL subjects; high-IL subjects are prohibited from reading low-IL objects to prevent contamination of high-IL subjects. Through top-down mandatory integrity control, a second line of defense against privilege escalation attacks is constructed.

[0089] Furthermore, considering the high dynamism of virtual machines, this user process layer supports dynamic adjustment of access control policies. Administrators can modify policy rules and adjust the permission allocation of subjects and objects in real time without system downtime. When policies are dynamically updated, the access control module notifies the kernel of the incremental portion, triggering the kernel to reload the policy. Cached access decisions must be invalidated and re-evaluated to ensure consistency between the decisions and the latest policy.

[0090] The construction of the access control component at the user process layer in the access control module involves the following steps: (c1) Define the RBAC model First, an RBAC model needs to be defined inside the virtual machine, mapping each user to one or more roles, and defining access permissions between roles and resources. Formally, the RBAC model can be represented as the following tuple: RBAC = (U, R, P, UA, PA) Where U is the user set, R is the role set, P is the permission set, UA is the many-to-many mapping between users and roles, and PA is the many-to-many mapping between roles and permissions. This model supports constraints such as role inheritance and mutual exclusion, and can flexibly express access control requirements in real-world scenarios.

[0091] In practical implementation, a set of virtual machine security roles can be defined based on the RBAC module of SELinux (Security-Enhanced Linux). Using SELinux's policy language, allowed operation types are defined between roles and resource types; for example, operation types include read and write. Then, pre-defined tools are used to associate each virtual machine user with a pre-defined security role.

[0092] (c2) Instrument the kernel and intercept resource access requests User / process access requests to resources will ultimately manifest as kernel-mode system calls. In this embodiment, system calls can be instrumented and intercepted in the kernel. For example, LSM (Linux Security Module) is selected as the instrumentation framework, and a new security module, VirtAC (Virtual Access Control), is developed based on this framework.

[0093] VirtAC implements all the hook functions defined in the LSM framework, which are called by resource access paths in the kernel source code. Taking a process opening a file as an example, the call path is: sys_open->do_sys_open->do_filp_open->security_file_open.

[0094] Among them, sys_open is the system call entry function, do_sys_open is the system call core processing function, do_filp_open is the core function for file path resolution and file object creation, and security_file_open is the file open hook function.

[0095] VirtAC implements the security_file_open hook, which is automatically called back by the kernel when a process invokes the open system call.

[0096] Within the hook function, VirtAC extracts the valid user ID from the current process's security context and calls relevant helper functions of the VFS (Virtual File System) to obtain the security attributes of the target file. It then assembles these two into an authorization request and sends it to the user-space policy server. The policy server queries the RBAC policy library and returns an authorization decision: allow access / deny access. VirtAC then allows or denies the system call accordingly, returning an error code if necessary.

[0097] (c3) Achieve fine-grained IPC isolation Taking shared memory as an example, VirtAC instrumentes the `shmget` (get shared memory identifier) ​​system call to intercept shared memory creation requests. If it's a newly created shared memory segment, VirtAC marks it with the valid user ID of the requesting process; if it's a reference to existing shared memory, VirtAC checks if the valid user ID of the requesting process matches the shared memory's marking, allowing only processes of the same user to reference the shared memory segment. Similarly, VirtAC instrumentes the `shmat` system call to intercept shared memory mapping requests and checks if the requesting process is qualified to map the memory segment.

[0098] For necessary cross-user IPC, VirtAC introduces a capability mechanism. Privileged processes create purpose-specific IPC objects, such as message queues for cross-user task collaboration. The privileged process explicitly grants appropriate capabilities to each process participating in the IPC, such as send / receive message permissions. When a process invokes IPC-related system calls, VirtAC checks whether it possesses the corresponding capabilities; processes lacking the necessary capabilities are denied access. VirtAC also supports the ability to dynamically modify and delete processes, enabling fine-grained permission minimization.

[0099] (c4) Implement mandatory integrity control in the kernel The basic idea of ​​mandatory integrity control is to assign integrity levels to subjects and objects and define information flow rules between subjects and objects at different levels. VirtAC is based on the Biba integrity model and implements top-down mandatory integrity control in the kernel.

[0100] In its implementation, VirtAC adds Integrity Level (IL) attributes to the file inode and process PCB data structure. Using a tagged file system, the IL for each file can be persistently stored. The process IL is determined at process creation and inherited from the parent process. VirtAC has a built-in IL policy library that defines the types of operations allowed between different ILs. For example, a high-IL process may only have read (r) permissions on a low-IL file, while a low-IL process may have no access permissions to a high-IL file.

[0101] VirtAC hooks the kernel's file read / write and inter-process communication paths, performing real-time comparisons of the inter-process intelligence (IL) of the subjects and objects. For information flows that violate the policy (such as a low-IL process writing to a high-IL file), VirtAC rejects the request and reports an error. By restricting low-IL subjects from writing to high-IL objects from multiple dimensions, VirtAC can effectively suppress privilege escalation attacks within the virtual machine.

[0102] (c5) Supports dynamic policy management and synchronization To adapt to the dynamic changes in the cloud environment, VirtAC needs to support real-time updates of security policies. This includes runtime modifications to the RBAC model and dynamic adjustments to process permissions. In practice, VirtAC can start a policy management service in user space to edit and store security policies. When administrators modify policies through this service, the service pushes incremental policy updates to the kernel module.

[0103] VirtAC provides a set of static control files, and the policy management service writes incremental policies to the corresponding control files. VirtAC listens to these control files, and upon detecting an update, triggers an LSM hook to reload the policy. Because multiple userspace services may be using the security policy, VirtAC employs reference counting and read-write locks to ensure the atomicity of policy updates and queries.

[0104] By performing the above steps (c1)-(c5), the access control component of the user process layer in the access control module can be constructed.

[0105] If the third access result indicates that access is denied, it can be determined that the access process termination condition "the latest access result indicates that access is denied" has been met, and the access process ends.

[0106] If the third access result indicates that access is permitted, the fourth access result of the access request at the physical resource layer can be obtained based on the fourth access control policy configured for the physical resource layer and the subject information, object information, and operation type of the physical resource layer.

[0107] In this embodiment, the access control component of the physical resource layer in the access control framework can obtain the fourth access result of the access request at the physical resource layer based on the fourth access control policy configured for the physical resource layer and the subject information, object information and operation type of the physical resource layer.

[0108] In one example, the physical resource layer can be the lowest layer in the access control framework, directly interacting with bare metal hardware resources and implementing fine-grained permission control over physical CPUs, physical memory, and I / O (Input / Output) devices. Specifically, the access control component of this physical resource layer can utilize a virtual machine monitor to intercept virtual machine access requests to physical resources, map virtual machine attributes to physical resource attributes, and notify the hardware layer's access control mechanism to configure specific resource access permissions.

[0109] Taking VT-d (Virtualization Technology for Directed I / O) as an example, the physical resource layer can support fine-grained access control to physical memory. VT-d introduces an I / O MMU (Input / Output Memory Management Unit), which can restrict DMA (Direct Memory Access) requests issued by the device to the range of pre-allocated physical memory. The access control module works in conjunction with the system's DMAR (DMA Remapping) unit to statically partition the DMA memory regions of different virtual machines and write the partitioning results into the DMAR page table. When the device issues a DMA request, the DMAR is responsible for looking up the table and only allowing DMA to authorized physical pages, thereby preventing malicious DMA access.

[0110] Similarly, the access control module can utilize IOMMU (Input / Output Memory Management Unit) technology to isolate the I / O devices of different virtual machines. It submits the device-virtual machine affiliation to the IOMMU and instructs the IOMMU to create an independent I / O address space for each virtual machine. When a virtual machine accesses a device, the IOMMU intercepts its I / O request, translates the virtual device address into a physical device address, checks whether the virtual machine has the right to access the destination device, and allows / denies the request based on the authorization result. Even if a malicious virtual machine knows the device addresses of other virtual machines, it cannot directly access unauthorized devices.

[0111] At the processor level, this layer utilizes the CPU's privilege level mechanism to implement access control over the execution of code from different virtual machines. The Virtual Machine Monitor (VM Monitor) runs at the highest privilege level and is responsible for classifying the privilege levels of different virtual machines. Sensitive instructions are restricted to execution only at higher privilege levels, thereby preventing unauthorized intrusions by virtual machines into the host machine. Modern processors also introduce the concept of VMCS (Virtual Machine Control System), which allows defining resource access permissions for each virtual machine at the hardware level. The access control module writes virtual machine permissions into the VMCS, and the CPU strictly checks the legality of instructions according to the VMCS rules, prohibiting unauthorized behavior.

[0112] The construction of the access control component in the physical resource layer of the access control module involves the following steps: (d1) Allocate DMA memory regions and configure DMAR page tables VT-d technology introduces a DMAR mechanism to limit a device's DMA requests to a pre-allocated range of physical memory, thereby preventing malicious devices from using DMA addresses to access unauthorized physical memory.

[0113] In practical implementation, the access control component of the physical resource layer in the access control module can be VirtAC. This VirtAC needs to statically partition the DMA memory region for each virtual machine within the VMM (Virtual Machine Monitor). The allocation must adhere to the following principles: first, allocate independent, non-overlapping contiguous physical pages for different virtual machines; second, the number of allocated physical pages must meet the maximum DMA cache requirements of the virtual machine configuration; and third, physical pages must be 4K (kilobyte) aligned to reduce address translation overhead.

[0114] VirtAC informs the hardware of the DMA memory partitioning results by writing them into the DMAR page table (called the VT-d page table). The VT-d page table uses a multi-level page table structure, indexing page table entries at 1GB (Gigabyte), 2MB (Megabyte), and 4KB (Kilobyte) granularities based on the high-order bits of the physical device address, ultimately locating the authorized physical page frame number. VirtAC fills the physical page frame number of each virtual machine into the leaf nodes of the VT-d page table, and simultaneously sets the read / write permissions of the page table entries to allowed. After the page table is configured, the VMM triggers the DMAR unit to load the page table.

[0115] When a device initiates a DMA request, the DMAR unit intercepts the target physical address in the request and uses that address as the key to query the VT-d page table. If the query fails, it means that the address is not within the permitted range, and the DMAR unit will reject the DMA request; if the query succeeds and the permissions of the matched entry are correct, the DMA request is allowed, and the physical address on the I / O bus is replaced with the actual physical address recorded in the VT-d table entry.

[0116] (d2) Implement I / O device isolation based on IOMMU To prevent malicious virtual machines from accessing unauthorized I / O devices, VirtAC uses IOMMU technology to isolate device access from different virtual machines. IOMMU is a memory management unit located between the CPU and the device, which translates each virtual machine's GVA (Guest Virtual Address) into the HPA (Host Physical Address) seen by the host machine.

[0117] The first step in isolation is to define the affiliation between virtual machines and devices. This requires the VMM to declare a list of devices owned by each virtual machine to VirtAC, which then constructs a virtual machine-device mapping table. For front-end virtualization mode, the VMM directly allocates physical devices to virtual machines through the paravirtualization bus driver; for back-end devices such as network cards / hard drives, it provides device emulation for virtual machines by creating corresponding back-end drivers in privileged domains.

[0118] The second step in isolation is to create an independent I / O address space for the virtual machine. VirtAC instructs the IOMMU to create an I / O page table for each virtual machine, mapping the virtual machine's GVA to the HPA. Compared to the memory page table of a regular MMU, the I / O page table also needs to record the DAV (Device Admission Vector), which identifies the virtual machine's access permissions to the target device. This way, even if a virtual machine knows the device addresses of other virtual machines, it cannot directly access unauthorized devices.

[0119] The final step in isolation is runtime address translation and permission checks. When a virtual machine initiates an I / O request, the request is intercepted by the VMM and handed over to VirtAC for processing. VirtAC extracts the GVA from the request and calls the IOMMU API to convert it to HPA. The IOMMU first indexes the I / O page table based on the high-order bits of the GVA, finds the page table entry corresponding to the GVA, and checks whether the DAV of that page table entry allows the virtual machine to access the target device; if so, it retrieves the HPA corresponding to the GVA from the page table entry and writes the HPA back to the request frame. The request frame is then dispatched to the I / O bus to access the real physical device.

[0120] (d3) Utilize CPU virtualization features to control code execution permissions x86 CPUs offer the VT-x (Intel Virtualization Technology for x86) virtualization feature set, which restricts virtual machine code execution to a specific privilege level while allowing the VMM to run at the highest privilege level. VirtAC can utilize this feature to restrict the execution of sensitive instructions by the virtual machine, including system register access and I / O port operations.

[0121] In its implementation, VirtAC creates a VMCS structure within the VMM for each vCPU (virtual CPU), defining the runtime rules for that vCPU. For example, the VMCS structure specifies rules related to allowed exceptions, exit events, and so on. VirtAC sets up a paging mode within the VMCS based on CR0.PE (Control Register 0.Protection Enable), dividing the 0-4G (gigabyte) linear address space into four 1G regions, each mapped to a corresponding region in physical memory. Pages containing code and data are mapped to lower-privilege regions. This paging mode isolates unauthorized access to higher-privilege pages by lower-privilege code.

[0122] When creating a virtual machine, VirtAC sets up the processor's Guest mode runtime environment in the VMCS, including vCPU register status, segment selectors and segment descriptors, GDTR (Global Descriptor Table Register) / IDTR (Interrupt Descriptor Table Register), etc. These fields are initialized according to the principle of least privilege, setting the Guest privilege level to the lowest level by default and disabling unnecessary functions. VirtAC then switches the processor to Guest mode and begins running the virtual machine.

[0123] During operation, if the virtual machine attempts to modify sensitive registers of the processor or execute privileged instructions, a "VM Exit" event will be triggered. The processor automatically enters the VMM, and VirtAC's VM Exit Handler takes over. VirtAC checks the cause of the trap; if the virtual machine attempts to modify critical registers, it rejects the operation; if it is a privileged instruction, the VMM simulates its execution. After completion, VirtAC reloads the Guest's runtime environment and resumes the virtual machine's operation.

[0124] (d4) Controlling virtual machine access to host machine memory By properly configuring the EPT, the number of host physical pages that a virtual machine can access can be strictly limited.

[0125] In practice, when VirtAC creates a VMCS, it sets the physical base address of the virtual machine's EPT page table by specifying a field. The EPT adopts a four-level page table structure, consisting of PML4E (Page-Map Level 4 Entry), PDPTE (Page-Directory Pointer Table Entry), PDE (Page-Directory Entry), and PTE (Page-Table Entry), which convert the virtual machine's GPA to HPA level by level.

[0126] VirtAC follows the principles of least privilege and data isolation, building independent EPT page table trees for different virtual machines. When filling in the EPT table entry for virtual machine A, only A's own physical page frame number is written to the HPA field of the leaf node, and the corresponding read and write permissions are set. This ensures that A can only access the portion of the host memory allocated to it. Even if A knows the physical addresses of other virtual machines, its access requests will trigger an exception due to missing EPT table entries.

[0127] When a virtual machine accesses memory, the MMU (Memory Management Unit) first queries the guest machine's own page table based on the GVA (Generative Virtualization Attribute) to convert the GVA to the GPA (Generative Page Attribute). Then, the MMU queries the EPT (Executable Page Table) based on the GPA to translate the GPA to the HPA (Hypertext Parity). During the query process, if an EPT entry is missing or the permissions do not match, a specified event will be triggered, causing the processor to exit Guest mode and enter VMM mode.

[0128] When an EPT (Extended Page Fault) exception occurs, VirtAC checks the virtual machine ID that initiated the memory access, the GPA (Guided Page Appearance) of the violation, and the access type. VirtAC determines whether the GPA is within the authorized scope of the requesting virtual machine, and if necessary, queries the security policy of the upper-layer VirtAC module. If it is an illegal access, an exception notification is injected to the virtual machine; if the access is legal, indicating a page fault, VirtAC fills in the corresponding EPT entry to complete the mapping from GPA to HPA (Hyper Page Appearance).

[0129] In addition to data pages, VirtAC also needs to protect the code and page tables themselves. Code pages can be mapped to "execute-only" permissions to prevent tampering by the virtual machine; leaf PTEs can be mapped to "read-only" permissions to prevent the virtual machine from escalating page table entry privileges; and for high-level page tables, VirtAC simply makes them non-existent, completely blocking the virtual machine from observing the page table structure. In this way, even if the virtual machine gains root privileges, it will be difficult to break through the hardware sandbox built by EPT.

[0130] Additionally, VirtAC allows multiple virtual machine EPT entries to be mapped to the same HPA for a specific GPA range. This range is marked as "Device DMA Secure" by setting I / O permission attribute bits in the PTE. These pages can only be accessed by the device, not the virtual machine CPU, and are restricted to the physical range allowed by DMAR, thus moderately relaxing DMA isolation restrictions while ensuring security.

[0131] (d5) Virtualized hardware encryption unit to prevent memory data leakage Plaintext data in memory can be stolen by privileged domains. To prevent virtual machine memory data leakage, VirtAC can virtualize the MEE (Memory Encryption Engine) hardware unit to encrypt the physical memory of the virtual machine in real time.

[0132] MEE introduces a memory encryption engine and key management unit, enabling real-time encryption / decryption of data passing through the system bus and supporting the allocation of independent memory encryption keys to different virtual machines. When DMA writes to memory, MEE encrypts the plaintext using AES (Advanced Encryption Standard) with the HPA of that page and the virtual machine key; when the CPU accesses memory, MEE automatically decrypts the ciphertext and finally presents the plaintext in the cache. By integrating the encryption and decryption process into hardware, MEE significantly improves the performance of memory encryption.

[0133] VirtAC maintains an MKTME (Memory Key Table Management Engine) for each vCPU, responsible for key allocation and updates for that vCPU. When creating a new virtual machine, VirtAC calls the KDG (Key Derivation Gateway) interface to generate a 128-bit virtual machine key and registers the key with the MKTME via a specified interface. When destroying a virtual machine, VirtAC removes the corresponding key from the MKTME, severing the key's connection to the physical pages.

[0134] To bind the key to the virtual machine memory page, VirtAC uses the reserved bit "KeyID" in the PTE to fill in the key slot number of the virtual machine when constructing the EPT page table. When the MMU queries the EPT page table, it not only obtains the HPA but also extracts the KeyID from the leaf PTE and passes it to the MEE unit. The MEE retrieves the corresponding key in the MKTME based on the KeyID to complete the encryption and decryption of the memory data.

[0135] Using the aforementioned data encryption / decryption methods, even if a privileged domain can read any virtual machine's memory page, it will only see ciphertext. The privileged domain cannot decrypt sensitive data in memory without the key. Even if an administrator can access the host machine's physical memory, it is difficult to locate and extract sensitive information from a large amount of ciphertext. Therefore, MEE's hardware encryption capabilities significantly reduce the risk of virtual machine memory data leakage.

[0136] By performing the above steps (d1)-(d5), the access control component of the physical resource layer in the access control module can be constructed.

[0137] If the fourth access result indicates that access is denied, it can be determined that the access process termination condition "the latest access result indicates that access is denied" has been met, and the access process ends.

[0138] If the fourth access result indicates that access is allowed, it can be determined that the access process termination condition "the access result of the last access control layer in the first sequence has been obtained, and the access result of the last access control layer indicates that access is allowed" has been met, and the access process ends.

[0139] As can be seen, by sequentially traversing each access control layer through this embodiment, the standardized access process can avoid errors in judging access results caused by missing information.

[0140] Based on a similar technical concept, in another embodiment, the access control framework includes multiple access control layers, arranged in a first order as follows: tenant layer, virtual machine layer, user process layer, and physical resource layer. The access request includes: subject information, object information, and operation type of the tenant layer; subject information, object information, and operation type of the virtual machine layer; and subject information, object information, and operation type of the user process layer. That is, the access request involves a first number of access control layers, and the access control framework includes a total of a second number of access control layers, where the first number is less than the second number.

[0141] It should be noted that when the first number is less than the second number, the access control layer involved in the access request is one access control layer in the access control framework, or the access control layer involved in the access request is multiple access control layers arranged consecutively in the access control framework.

[0142] In this embodiment, based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are obtained sequentially in a first order. This includes: obtaining a first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer; if the first access result indicates that access is allowed, obtaining a second access result of the access request at the virtual machine layer based on the second access control policy configured for the virtual machine layer and the subject information, object information, and operation type of the virtual machine layer; and if the second access result indicates that access is allowed, obtaining a third access result of the access request at the user process layer based on the third access control policy configured for the user process layer and the subject information, object information, and operation type of the user process layer. This embodiment can be referred to the corresponding description section of the above embodiments.

[0143] As can be seen, this embodiment eliminates the need to sequentially traverse all access control layers in the access control framework, reducing unnecessary access control operations. Furthermore, the standardized access process avoids errors in access result judgment caused by missing information.

[0144] In one embodiment, before obtaining the first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer, the method further includes: intercepting the access request through the access control component of the tenant layer, and extracting the subject information, object information, and operation type of the tenant layer from the access request.

[0145] Access requests are intercepted through a tenant-level access control component. For example, the access control component can pre-register the following: basic tenant identity information and a unique tenant identifier, tenant-specific resource quotas and resource ranges, and a tenant-level first access permission policy, which can be represented by a triple (subject-object-operation), etc. The access control component intercepts requests passing through the tenant layer and filters these requests based on the pre-registered basic tenant identity information, unique tenant identifier, and tenant-specific resource quotas and resource ranges to obtain the final access request.

[0146] The tenant-level access control component extracts the tenant-level subject information, object information, and operation type from the access request. For example, the tenant-level access control component extracts the following triple from the access request: (subject information 1, object information 1, operation type x1).

[0147] As can be seen, by utilizing the access control components of each access control layer in this embodiment to intercept access requests and extract the subject information, object information, and operation type of the corresponding access control layer, it is possible to achieve policy coordination and step-by-step verification of multi-layer access control, thereby avoiding single-layer protection vulnerabilities.

[0148] Similarly, based on the second access control policy configured for the virtual machine layer and the subject information, object information, and operation type of the virtual machine layer, before obtaining the second access result of the access request at the virtual machine layer, the process also includes: intercepting the access request through the access control component of the virtual machine layer, and extracting the subject information, object information, and operation type of the virtual machine layer from the access request.

[0149] Based on the third access control policy configured for the user process layer and the subject information, object information, and operation type of the user process layer, before obtaining the third access result of the access request at the user process layer, the process further includes: intercepting the access request through the access control component of the user process layer, and extracting the subject information, object information, and operation type of the user process layer from the access request.

[0150] Based on the fourth access control policy configured for the physical resource layer and the subject information, object information, and operation type of the physical resource layer, before obtaining the fourth access result of the access request at the physical resource layer, the process also includes: intercepting the access request through the access control component of the physical resource layer, and extracting the subject information, object information, and operation type of the physical resource layer from the access request.

[0151] In one embodiment, obtaining the first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer includes: determining a target sub-policy matching the access request in the first access control policy based on the subject information, object information, and operation type of the tenant layer; obtaining the corresponding dynamic feature value based on the subject information of the tenant layer; determining the decision result of the target sub-policy based on the dynamic feature value; and determining the first access result of the access request at the tenant layer based on the decision result of the target sub-policy.

[0152] The first access control policy can include multiple sub-policies with different dimensions. The decision results of the sub-policies with different dimensions may be consistent or conflicting.

[0153] The dynamic feature value corresponding to the subject information can be the feature value of the operation entity represented by the subject information, and this feature value changes dynamically over time. For example, feature value 1 indicates that the administrator of tenant A is currently on the blacklist, feature value 2 indicates the amount of idle CPU resources of tenant A at the current time, and so on.

[0154] In one example, the subject information, object information, and operation type of the tenant layer can be represented by a triple (subject information 1, object information 1, operation type x1). The first access control policy includes: Sub-policy 1 of dimension 1: Allow the administrator of tenant A to remotely log in to virtual machine 1 of tenant B during the time period [08:00, 18:00].

[0155] Sub-policy 2 of dimension 1: Allow the administrator of tenant C to remotely log in to virtual machine 1 of tenant B during the time period [08:00, 18:00].

[0156] Sub-policy 3 of dimension 2: Do not allow any tenant administrator who has been blacklisted within the past three months to access the virtual machine 1 of tenant B remotely.

[0157] Based on the triple (subject information 1, object information 1, operation type x1), the target sub-policies that match the access request can be determined in the first access control policy, including: sub-policy 1 and sub-policy 3.

[0158] Based on the tenant layer's main information 1, obtain the corresponding dynamic feature value: Feature value 1, which indicates that the administrator of tenant A has not been blacklisted within the past three months.

[0159] Based on the dynamic feature values, the decision result of the target sub-strategy is determined. For example, the decision result of sub-strategy 1 indicates that access is allowed, and the decision result of sub-strategy 3 indicates that access is allowed.

[0160] Based on the decision results of the target sub-policies, the first access result of the access request at the tenant layer is determined. For example, if the decision results of all target sub-policies are consistent and all allow access, it can be determined that the first access result of the access request at the tenant layer indicates that access is allowed.

[0161] As can be seen, this embodiment can utilize subject information to obtain dynamic change values ​​in real time, and use these dynamic change values ​​to provide a reference for decision-making, thereby improving the real-time performance and accuracy of access control policy decisions.

[0162] In one embodiment, the target sub-policy includes a first sub-policy and a second sub-policy; determining the first access result of the access request at the tenant layer based on the decision result of the target sub-policy includes: if the decision results of the first sub-policy and the second sub-policy conflict, then determining the first access result of the access request at the tenant layer based on the sub-policy priority information configured for the tenant layer, the decision result of the first sub-policy, and the decision result of the second sub-policy.

[0163] In one example, the subject information, object information, and operation type of the tenant layer can be represented by a triple (subject information 1, object information 1, operation type x1). The first access control policy includes: Sub-policy 1 of dimension 1: Allow the administrator of tenant A to remotely log in to virtual machine 1 of tenant B during the time period [08:00, 18:00].

[0164] Sub-policy 2 of dimension 1: Allow the administrator of tenant C to remotely log in to virtual machine 1 of tenant B during the time period [08:00, 18:00].

[0165] Sub-policy 3 of dimension 2: Do not allow any tenant administrator who has been blacklisted within the past three months to access the virtual machine 1 of tenant B remotely.

[0166] Based on the triple (subject information 1, object information 1, operation type x1), the target sub-policies that match the access request can be determined in the first access control policy, including: sub-policy 1 and sub-policy 3.

[0167] Based on the tenant layer's main information 1, obtain the corresponding dynamic feature value: Feature value 1, which indicates that the administrator of tenant A is currently in the blacklist.

[0168] Based on the dynamic feature values, the decision result of the target sub-strategy is determined. For example, the decision result of sub-strategy 1 indicates that access is allowed, and the decision result of sub-strategy 3 indicates that access is denied.

[0169] In the process of determining the first access result of an access request at the tenant layer based on the decision results of the target sub-policy, if the decision results of sub-policy 1 and sub-policy 3 conflict, then the first access result of the access request at the tenant layer is determined based on the sub-policy priority information configured for the tenant layer, the decision result of sub-policy 1, and the decision result of sub-policy 3. For example, if the priority of sub-policy 3 is higher than that of sub-policy 1, then the first access result of the access request at the tenant layer can be determined to be access denied.

[0170] As can be seen, by configuring sub-policy priority information in advance for the tenant layer through this embodiment, a unified judgment standard can be used to determine the access result when sub-policies of different dimensions conflict with each other.

[0171] In step S106 above, response information for the access request is generated based on the access result.

[0172] If the latest access result indicates that access is denied, a first response message for the access denial request is generated; if the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed, a second response message for the access acceptance request is generated.

[0173] In one embodiment, the access request includes a data write request submitted to the target virtual machine, the access request carrying the target data to be written; the access result of the last access control layer indicates that access is allowed; based on the access result, response information for the access request is generated, including: according to the access request, sending the target data to the memory encryption engine, performing data encryption processing through the memory encryption engine to obtain ciphertext data; writing the ciphertext data into the physical memory area mapped by the target virtual machine; determining the write status of the ciphertext data, and generating response information for the access request based on the write status.

[0174] In this embodiment, the target object is the target virtual machine, and the access request is used to request that the target data be written into the physical memory region mapped by the target virtual machine.

[0175] Based on the access request, the target data is sent to the memory encryption engine, which encrypts the data to obtain ciphertext data. This ciphertext data is then written to the physical memory region mapped to the target virtual machine. In one example, VirtAC can virtualize MEE hardware units to perform real-time encryption on the virtual machine's physical memory. The MEE then forwards the encrypted ciphertext data to the physical memory region mapped to the virtual machine.

[0176] If the write status of the encrypted data indicates that the encrypted data has been written successfully, then a response message indicating that the access request has been successfully responded to is generated based on the write status.

[0177] If the write status of the encrypted data indicates that the write of the encrypted data has failed, then a response message indicating that the access request has failed will be generated based on the write status.

[0178] As can be seen, by using a memory encryption engine to encrypt the target data and write the ciphertext into the physical memory area through this embodiment, the hardware encryption features can be fully utilized to improve the security of data storage.

[0179] In one embodiment, the object access method further includes: recording the access time of the access request and the access results of the access request at each access control layer when the access process termination condition is met, to obtain access record information corresponding to the access request; performing feature extraction based on the access record information to obtain access behavior features; and performing abnormal access detection based on the access behavior features to obtain detection results.

[0180] In one example, an access record may include: the access time of the access request: time point T1; the access results of the access request at each access control layer when the access process termination condition is met: access result 1 at the tenant layer indicates successful access, and access result 2 at the virtual machine layer indicates failed access.

[0181] Feature extraction is performed based on access log information to obtain access behavior characteristics. This can be achieved by analyzing user behavior using multiple access logs. For example, if the number of user access requests within 3 seconds is S1, and the access result 2 for each request at the virtual machine layer indicates access failure.

[0182] Anomaly detection is performed based on access behavior characteristics to obtain detection results. For example, anomaly access characteristic set can be pre-configured: anomaly access characteristic 1 indicates that the number of access requests from the same user within 3 seconds exceeds a first threshold; anomaly access characteristic 2 indicates that the number of consecutive failed access attempts by a user at the same access control layer exceeds a second threshold, and so on. The access behavior characteristics are then matched with the anomaly access characteristic set to obtain the anomaly detection results.

[0183] As can be seen, through this embodiment, by recording the access time and access results of each access control layer, and using the above information for anomaly detection, users with abnormal access behavior can be identified in a timely manner, thereby enabling targeted control measures to be taken.

[0184] In summary, through the embodiments of this disclosure, the initiator of the access request is mapped to different operation entities in each access control layer, and the target object is mapped to different object resources in each access control layer. This allows an access request for a target object to be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, enabling each access control layer to determine whether the access request is allowed from different dimensions. Furthermore, the access results of the request are accessed sequentially in a first order at each access control layer. Standardized access procedures can avoid errors in access result judgment caused by information omissions, thereby improving the accuracy of access control for objects.

[0185] Figure 2 This is a schematic diagram of the structure of an object access device provided in an embodiment of the present disclosure, as shown below. Figure 2 As shown, the device includes: The request receiving unit 201 is used to receive an access request for a target object; the access request includes subject information, object information and operation type of multiple access control layers; each access control layer is arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer. The result acquisition unit 202 is configured to, according to the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, sequentially acquire the access results of the access request at each access control layer in the first order, until the access process termination condition is met; the access process termination condition includes: the latest acquired access result indicates that access is denied; or, the access result of the last access control layer in the first order has been acquired, and the access result of the last access control layer indicates that access is allowed; The information generation unit 203 is used to generate response information for the access request based on the access result.

[0186] Optionally, the plurality of access control layers include: a tenant layer, a virtual machine layer, a user process layer, and a physical resource layer; when the result acquisition unit 202 acquires the access results of the access request at each of the access control layers in the first order according to the access control policies configured for each of the access control layers and the subject information, object information, and operation type of each of the access control layers, the result acquisition unit 202 performs the following steps: Based on the first access control policy configured for the tenant layer and the subject information, object information and operation type of the tenant layer, the first access result of the access request in the tenant layer is obtained; If the first access result indicates that access is allowed, the second access result of the access request at the virtual machine layer is obtained according to the second access control policy configured for the virtual machine layer and the subject information, object information and operation type of the virtual machine layer; If the second access result indicates that access is allowed, the third access result of the access request at the user process layer is obtained according to the third access control policy configured for the user process layer and the subject information, object information and operation type of the user process layer; If the third access result indicates that access is permitted, the fourth access result of the access request at the physical resource layer is obtained according to the fourth access control policy configured for the physical resource layer and the subject information, object information and operation type of the physical resource layer.

[0187] Optionally, when the result acquisition unit 202 acquires the first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer, it performs the following steps: Based on the subject information, object information, and operation type of the tenant layer, a target sub-policy matching the access request is determined in the first access control policy; Based on the main information of the tenant layer, obtain the corresponding dynamic feature value; Based on the dynamic feature values, the decision result of the target sub-strategy is determined; Based on the decision result of the target sub-policy, the first access result of the access request at the tenant layer is determined.

[0188] Optionally, the target sub-policy includes a first sub-policy and a second sub-policy; when the result acquisition unit 202 determines the first access result of the access request at the tenant layer based on the decision result of the target sub-policy, it performs the following steps: If the decision results of the first sub-policy and the second sub-policy conflict, then based on the sub-policy priority information configured for the tenant layer, the decision result of the first sub-policy, and the decision result of the second sub-policy, the first access result of the access request at the tenant layer is determined.

[0189] Optionally, the access request includes a data write request submitted to the target virtual machine, the access request carrying the target data to be written; the access result of the last access control layer indicates that access is permitted; when the information generation unit 203 generates the response information of the access request based on the access result, it performs the following steps: According to the access request, the target data is sent to the memory encryption engine, and the data is encrypted by the memory encryption engine to obtain ciphertext data; Write the encrypted data into the physical memory region mapped by the target virtual machine; Determine the write status of the encrypted data, and generate response information for the access request based on the write status.

[0190] Optionally, the device further includes: An information recording unit is used to record the access time of the access request and the access results of the access request at each of the access control layers when the access process termination condition is met, so as to obtain the access record information corresponding to the access request. The feature extraction unit is used to extract features based on the access record information to obtain access behavior features; An access detection unit is used to perform abnormal access detection based on the access behavior characteristics and obtain detection results.

[0191] Optionally, the device further includes: The information extraction unit is used to intercept the access request through the access control component of the tenant layer, and to extract the subject information, object information and operation type of the tenant layer from the access request.

[0192] In this embodiment, the initiator of the access request is mapped to different operation entities in each access control layer, and the target object is mapped to different object resources in each access control layer. This allows an access request for a target object to be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, enabling each access control layer to determine whether the access request is allowed from different dimensions. Furthermore, the access results of the request are accessed sequentially in the first order at each access control layer. The standardized access process avoids errors in access result judgment caused by information omissions, thereby improving the accuracy of access control for objects.

[0193] The object access device provided in one embodiment of this disclosure can implement the various processes in the foregoing method embodiments and achieve the same functions and effects, which will not be repeated here.

[0194] Furthermore, one embodiment of this disclosure also provides an electronic device, Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure, such as... Figure 3 As shown, the device includes: a memory 301, a processor 302, a bus 303, and a communication interface 304. The memory 301, the processor 302, and the communication interface 304 communicate via the bus 303. The communication interface 304 may include input / output interfaces, including but not limited to a keyboard, mouse, monitor, microphone, and loudspeaker.

[0195] Figure 3 In the memory 301, computer-executable instructions that can run on the processor 302 are stored. When the processor 302 executes the computer-executable instructions, the following process is implemented: Receive an access request for a target object; the access request includes subject information, object information, and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer; Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are sequentially obtained in the first order until the access process termination condition is met; the access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed. Based on the access result, generate response information for the access request.

[0196] In this embodiment, the initiator of the access request is mapped to different operation entities in each access control layer, and the target object is mapped to different object resources in each access control layer. This allows an access request for a target object to be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, enabling each access control layer to determine whether the access request is allowed from different dimensions. Furthermore, the access results of the request are accessed sequentially in the first order at each access control layer. The standardized access process avoids errors in access result judgment caused by information omissions, thereby improving the accuracy of access control for objects.

[0197] An electronic device provided in one embodiment of this disclosure can implement the various processes in the foregoing method embodiments and achieve the same functions and effects, which will not be repeated here.

[0198] Another embodiment of this disclosure also provides a computer-readable storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: Receive an access request for a target object; the access request includes subject information, object information, and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer; Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are sequentially obtained in the first order until the access process termination condition is met; the access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed. Based on the access result, generate response information for the access request.

[0199] In this embodiment, the initiator of the access request is mapped to different operation entities in each access control layer, and the target object is mapped to different object resources in each access control layer. This allows an access request for a target object to be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, enabling each access control layer to determine whether the access request is allowed from different dimensions. Furthermore, the access results of the request are accessed sequentially in the first order at each access control layer. The standardized access process avoids errors in access result judgment caused by information omissions, thereby improving the accuracy of access control for objects.

[0200] The computer-readable storage medium includes read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk, etc.

[0201] The computer-readable storage medium provided in one embodiment of this disclosure can implement the various processes in the foregoing method embodiments and achieve the same functions and effects, which will not be repeated here.

[0202] Another embodiment of this disclosure also provides a computer program product, the computer program product including a computer program, which, when executed by a processor, implements the following process: Receive an access request for a target object; the access request includes subject information, object information, and operation type of multiple access control layers; the access control layers are arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer; Based on the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, the access results of the access request at each access control layer are sequentially obtained in the first order until the access process termination condition is met; the access process termination condition includes: the latest obtained access result indicates that access is denied; or, the access result of the last access control layer in the first order has been obtained, and the access result of the last access control layer indicates that access is allowed. Based on the access result, generate response information for the access request.

[0203] In this embodiment, the initiator of the access request is mapped to different operation entities in each access control layer, and the target object is mapped to different object resources in each access control layer. This allows an access request for a target object to be split into hierarchical access sub-requests corresponding to each access control layer. This facilitates flexible configuration of access control policies for each access control layer, enabling each access control layer to determine whether the access request is allowed from different dimensions. Furthermore, the access results of the request are accessed sequentially in the first order at each access control layer. The standardized access process avoids errors in access result judgment caused by information omissions, thereby improving the accuracy of access control for objects.

[0204] The computer program product in this disclosure embodiment can implement the various processes of the above-described object access method embodiment and achieve the same effects and functions, which will not be repeated here.

[0205] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-readable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0206] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0207] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0208] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0209] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0210] Memory may include non-persistent storage in computer-readable storage media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable storage media.

[0211] Computer-readable storage media include both permanent and non-permanent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer-readable storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media does not include transient media, such as modulated data signals and carrier waves.

[0212] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0213] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0214] The above description is merely an embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of this application should be included within the scope of the claims of this application.

Claims

1. A method for accessing objects, characterized in that, include: Receive an access request for a target object; the access request includes subject information, object information, and operation type from multiple access control layers; Each of the access control layers is arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer. Based on the access control policies configured for each access control layer and the subject information, object information and operation type of each access control layer, the access results of the access request at each access control layer are obtained in the first order until the access process termination condition is met. The conditions for ending the access process include: the latest access result indicates that access is denied; or, the access result of the last access control layer in the first sequence has been obtained, and the access result of the last access control layer indicates that access is allowed. Based on the access result, generate response information for the access request.

2. The method according to claim 1, characterized in that, The multiple access control layers include: a tenant layer, a virtual machine layer, a user process layer, and a physical resource layer; the step of sequentially obtaining the access results of the access request at each access control layer according to the access control policies configured for each access control layer and the subject information, object information, and operation type of each access control layer, in the first order, includes: Based on the first access control policy configured for the tenant layer and the subject information, object information and operation type of the tenant layer, the first access result of the access request in the tenant layer is obtained; If the first access result indicates that access is allowed, the second access result of the access request at the virtual machine layer is obtained according to the second access control policy configured for the virtual machine layer and the subject information, object information and operation type of the virtual machine layer; If the second access result indicates that access is allowed, the third access result of the access request at the user process layer is obtained according to the third access control policy configured for the user process layer and the subject information, object information and operation type of the user process layer; If the third access result indicates that access is permitted, the fourth access result of the access request at the physical resource layer is obtained according to the fourth access control policy configured for the physical resource layer and the subject information, object information and operation type of the physical resource layer.

3. The method according to claim 2, characterized in that, The step of obtaining the first access result of the access request at the tenant layer based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer includes: Based on the subject information, object information, and operation type of the tenant layer, a target sub-policy matching the access request is determined in the first access control policy; Based on the main information of the tenant layer, obtain the corresponding dynamic feature value; Based on the dynamic feature values, the decision result of the target sub-strategy is determined; Based on the decision result of the target sub-policy, the first access result of the access request at the tenant layer is determined.

4. The method according to claim 3, characterized in that, The target sub-policy includes a first sub-policy and a second sub-policy; determining the first access result of the access request at the tenant layer based on the decision result of the target sub-policy includes: If the decision results of the first sub-policy and the second sub-policy conflict, then based on the sub-policy priority information configured for the tenant layer, the decision result of the first sub-policy, and the decision result of the second sub-policy, the first access result of the access request at the tenant layer is determined.

5. The method according to claim 1, characterized in that, The access request includes a data write request submitted to the target virtual machine, and the access request carries the target data to be written; The access result of the last access control layer indicates that access is permitted. The step of generating response information for the access request based on the access result includes: According to the access request, the target data is sent to the memory encryption engine, and the data is encrypted by the memory encryption engine to obtain ciphertext data; Write the encrypted data into the physical memory region mapped by the target virtual machine; Determine the write status of the encrypted data, and generate response information for the access request based on the write status.

6. The method according to claim 1, characterized in that, The method further includes: Record the access time of the access request and the access results of the access request at each access control layer when the access process termination condition is met, and obtain the access record information corresponding to the access request; Based on the access record information, feature extraction is performed to obtain access behavior features; Anomaly detection is performed based on the access behavior characteristics to obtain the detection results.

7. The method according to claim 2, characterized in that, Before obtaining the access request based on the first access control policy configured for the tenant layer and the subject information, object information, and operation type of the tenant layer, the process further includes: The access control component at the tenant layer intercepts the access request and extracts the subject information, object information, and operation type of the tenant layer from the access request.

8. An object access device, characterized in that, include: The request receiving unit is used to receive access requests for the target object. The access request includes subject information, object information, and operation type from multiple access control layers; Each of the access control layers is arranged in a first order; for each access control layer, the subject information represents the operation entity mapped by the initiator of the access request in the access control layer, and the object information represents the object resource mapped by the target object in the access control layer. The result acquisition unit is used to sequentially acquire the access results of the access request at each of the access control layers according to the access control policies configured for each of the access control layers and the subject information, object information and operation type of each of the access control layers, in the first order, until the access process termination condition is met. The conditions for ending the access process include: the latest access result indicates that access is denied; or, the access result of the last access control layer in the first sequence has been obtained, and the access result of the last access control layer indicates that access is allowed. The information generation unit is used to generate response information for the access request based on the access result.

9. An electronic device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-executable instructions that, when executed on the processor, enable the implementation of the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions that, when executed by a processor, enable the implementation of the method described in any one of claims 1-7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images