Device permission management method and apparatus, medium, electronic device, and program product

Abstract

This disclosure relates to a device access control method, apparatus, medium, electronic device, and program product, belonging to the field of device access control. It can meet the device access control needs in various device usage environments, possessing universality and strong flexibility. A device access control method includes: obtaining a target access control policy for a target device from a pre-configured access control policy on a server, wherein the target device is a device whose access is managed by the server, and the pre-configured access control policy is a permission management policy pre-configured by the server for each device whose access is managed; managing administrator permissions on the target device according to the target access control policy; and creating a custom token with administrator permissions to escalate the access of the target device.

Description

Technical Field

[0001] This disclosure relates to the field of device access control, specifically to a device access control method, apparatus, medium, electronic device, and program product. Background Technology

[0002] In today's digital age, device management has become crucial for achieving efficient operations and ensuring security. Larger enterprises, with tens or even hundreds of thousands of office devices, typically use Microsoft's local domain (Active Directory, AD) or cloud domain (Azure Active Directory, Azure AD) to manage these devices. This means adding office devices to the local / cloud domain, unifying the device operating environment through local / cloud domain group policies, and implementing access control through local / cloud domain account permission management.

[0003] However, the above-mentioned device permission management methods lack universality. That is, local domain group policies are only applicable to permission management in local domain scenarios, and cloud domain group policies are only applicable to permission management in cloud domain scenarios. Neither of them can be universally applied to device permission management in local account scenarios, local domain scenarios, or cloud domain scenarios. Summary of the Invention

[0004] This summary section is provided to briefly introduce the concepts, which will be described in detail in the detailed description section below. This summary section is not intended to identify key or essential features of the claimed technical solution, nor is it intended to limit the scope of the claimed technical solution.

[0005] In a first aspect, this disclosure provides a device permission management method, comprising: obtaining a target permission management policy for a target device from a pre-configured permission management policy of a server, wherein the target device is a device whose permissions are managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permissions are managed; managing the administrator permissions on the target device according to the target permission management policy; and creating a custom token with administrator permissions to escalate the permissions of the target device.

[0006] Secondly, this disclosure provides a device permission management apparatus, comprising: an acquisition module, configured to acquire a target permission management policy for a target device from a pre-configured permission management policy of a server, wherein the target device is a device whose permissions are managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permissions are managed; and a management module, configured to manage the administrator permissions on the target device according to the target permission management policy, and to create a customized token with administrator permissions to escalate the permissions of the target device.

[0007] Thirdly, this disclosure provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of the method described in any of the first aspects.

[0008] Fourthly, this disclosure provides an electronic device, comprising:

[0009] A storage device on which computer programs are stored;

[0010] A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of the first aspects.

[0011] Fifthly, this disclosure provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0012] By adopting the above technical solution, the target permission management policy for the target device is obtained from the pre-configured permission management policy on the server. Then, according to the target permission management policy, the administrator privileges on the target device are managed, and a customized token with administrator privileges is created to escalate the target device's permissions. This permission management method is limited by the target permission management policy on the server, but not by the device account system. Therefore, it can widely support possible device account systems, including local accounts, local domain accounts, and cloud domain accounts, thereby meeting the device permission management needs of various device usage environments. It has universality and strong flexibility, and can meet users' personalized device permission management needs. In addition, by managing the target device's permissions in the cloud, the privileges of the local administrator on the target device can be revoked, and the target device's permissions can be managed locally on the target device according to the target permission management policy. This reduces the risk of the target device's operating environment being compromised, significantly narrows the attack surface, and defends against attacks. It can also flexibly meet the permission requirements in specific scenarios. Moreover, from an enterprise operation perspective, it can unify the device operating environment and improve enterprise operational efficiency.

[0013] Other features and advantages of this disclosure will be described in detail in the following detailed description section. Attached Figure Description

[0014] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale. In the drawings:

[0015] Figure 1 This is a flowchart of a device access control method according to an embodiment of the present disclosure.

[0016] Figure 2 This is a schematic diagram of a self-service privilege escalation request window according to an embodiment of the present disclosure.

[0017] Figure 3 This is a schematic diagram of a self-service privilege escalation rejection window according to an embodiment of the present disclosure.

[0018] Figure 4 This is a schematic block diagram of a device access control apparatus according to an embodiment of the present disclosure.

[0019] Figure 5 This is a schematic diagram of a device permission management architecture according to an embodiment of the present disclosure.

[0020] Figure 6 A schematic diagram of the structure of an electronic device suitable for implementing embodiments of the present disclosure is shown. Detailed Implementation

[0021] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0022] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0023] The term "comprising" and its variations as used herein are open-ended inclusions, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below.

[0024] It should be noted that the concepts of "first" and "second" mentioned in this disclosure are used only to distinguish different devices, modules or units, and are not used to limit the order of functions performed by these devices, modules or units or their interdependencies.

[0025] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0026] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0027] It is understood that before using the technical solutions disclosed in the various embodiments of this disclosure, users should be informed of the types, scope of use, and usage scenarios of the personal information involved in this disclosure in an appropriate manner in accordance with relevant laws and regulations, and user authorization should be obtained.

[0028] For example, upon receiving a user's active request, a prompt message is sent to the user to explicitly inform them that the requested operation will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the software or hardware, such as the electronic device, application, server, or storage medium performing the operations of this disclosed technical solution, based on the prompt message.

[0029] As an optional but non-limiting implementation, in response to a user's active request, sending a prompt message to the user can be done via a pop-up window, where the prompt message can be presented in text format. Furthermore, the pop-up window can also include a selection control allowing the user to choose "agree" or "disagree" to provide personal information to the electronic device.

[0030] It is understood that the above notification and user authorization process are merely illustrative and do not constitute a limitation on the implementation of this disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of this disclosure.

[0031] Meanwhile, it is understood that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) shall comply with the requirements of relevant laws, regulations and related provisions.

[0032] Figure 1 This is a flowchart illustrating a device permission management method according to an embodiment of the present disclosure. This device permission management method is universally applicable to device permission management in various scenarios, including local account scenarios, local domain scenarios, and cloud domain scenarios. Figure 1 As shown, the device access control method may include the following steps S11 and S12.

[0033] In step S11, the target permission management policy for the target device is obtained from the pre-configured permission management policy of the server. The target device is a device whose permissions are managed by the server. The pre-configured permission management policy is the permission management policy pre-configured by the server for each device whose permissions are managed.

[0034] The server can reside in the cloud. It can centrally manage all or some of an enterprise's devices, for example, by centrally managing various permissions on those devices. For each device's permissions, the server can pre-configure corresponding permission management policies, enabling the use of these policies to manage permissions on that device.

[0035] Target access control policies may include at least one of the following: administrator privilege revoke rules, default privilege escalation rules, self-service privilege escalation rules, etc. In this disclosure, "privilege escalation" refers to privilege elevation, that is, elevation to administrator privileges.

[0036] Administrator privilege revocation rules can be used to indicate whether administrator privilege revocation is enabled and the administrator whitelist when administrator privilege revocation is enabled. The administrator whitelist can be used to indicate which accounts have administrator privileges; that is, accounts on the target device that are on the administrator whitelist can have administrator privileges, while accounts that are not on the administrator whitelist cannot have administrator privileges.

[0037] A default privilege escalation rule can be used to instruct that when a program specified in the default privilege escalation rule is launched, the process running that program will be elevated to administrator privileges by default. Default privilege escalation rules can manage permissions from any device-related dimension, such as program file attributes, time windows, device account dimensions, etc. Program file attributes can include at least one of the following: program name, program path, program directory, program process, program signature, etc. Time windows can include, for example, the time period during which default privilege management is implemented. Device account dimensions can include, for example, which device accounts are subject to default privilege management. For example, a default privilege escalation rule can instruct which time periods, which programs, and which accounts on the target device will have their processes running the specified programs elevated to administrator privileges by default. For instance, during time period 1, the process running program 1 under path 1 will have its privileges elevated to administrator privileges by default; during time period 2, the process running program 2 under publisher 2 will have its privileges elevated to administrator privileges by default; during time period 3, the process running program 3 with hash value 3 will have its privileges elevated to administrator privileges by default, and so on.

[0038] Self-service privilege escalation rules indicate whether self-service privilege escalation is enabled and, when enabled, rules that automatically escalate the privileges of running processes to administrator privileges. The difference between self-service privilege escalation rules and default privilege escalation rules is that self-service privilege escalation rules allow requests to be made when running any program and require interaction, such as entering a reason for the escalation. Default privilege escalation rules, on the other hand, do not require any interaction but require the program specified in the default rule to be escalated. Self-service privilege escalation rules can manage permissions from any device-related dimension, such as the time window dimension or the device account dimension. The time window dimension can include, for example, the time period during which self-service permission management is performed. The device account dimension can include, for example, which device accounts are subject to self-service permission management. For example, a self-service privilege escalation rule can indicate the time period during which a request can be made to escalate the privileges of a running process to administrator privileges.

[0039] In this disclosure, the device account may include a local account, a local domain account, a cloud domain account, etc.

[0040] In step S12, according to the target permission management policy, permission management is performed on the administrator permissions on the target device, and a custom token with administrator permissions is created to escalate permissions on the target device. For example, based on various rules included in the target permission management policy, it can be determined whether it is necessary to escalate the permissions of the processes running applications on the target device to administrator permissions. If so, the corresponding processes are escalated.

[0041] By adopting the above technical solution, the target permission management policy for the target device is obtained from the pre-configured permission management policy on the server. Then, according to the target permission management policy, the administrator permissions on the target device are managed, and a customized token with administrator privileges is created to escalate the device's permissions. This permission management method is limited by the target permission management policy on the server, but not by the device account system. Therefore, it can widely support possible device account systems, including local accounts, local domain accounts, and cloud domain accounts, thus meeting the device permission management needs of various device usage environments and possessing universality. In addition, because the permission rules in the target permission management policy can achieve more granular permission management, such as specific time periods, specific programs, specific directories, specific processes, and specific signatures, it has strong flexibility and can meet users' personalized device permission management needs. In addition, by managing access permissions for target devices in the cloud, the privileges of local administrators on the target devices can be revoked, and access permissions for the target devices can be managed locally on the target devices according to the target access management policy. This can reduce the risk of the target device's operating environment being compromised, significantly reduce the attack surface, and defend against attacks. It can also flexibly meet the access requirements in specific scenarios. Moreover, from the perspective of enterprise operations, it can also unify the device operating environment and improve enterprise operational efficiency.

[0042] In some embodiments, the permission management of administrator privileges on the target device in step S12 may include: matching the administrator whitelist in the target permission management policy with the permissions of each account on the target device, wherein the administrator whitelist is used to indicate the accounts on the target device that have administrator privileges; based on the matching results, revoking the administrator privileges of accounts that are not in the administrator whitelist but currently have administrator privileges, and granting administrator privileges to accounts that are in the administrator whitelist but whose administrator privileges were previously revoked.

[0043] For example, it is possible to periodically check whether the permissions of all accounts on the target device (e.g., local accounts, local domain accounts, cloud domain accounts, etc.) match the administrator whitelist in the target permission management policy.

[0044] For example, based on the administrator whitelist, accounts in user groups within local accounts, local domain accounts, and cloud domain accounts can be periodically checked. If an account in a user group is listed in the administrator whitelist but is currently recorded in the revoked list, it means that the account originally had administrator privileges but these privileges were previously revoked. The administrator privileges of this account can then be restored, for example, by adding or transferring the account to the administrator group. The revoked list is used to record accounts whose administrator privileges have been revoked.

[0045] For example, based on the administrator whitelist, accounts in the Administrators group of local accounts, local domain accounts, and cloud domain accounts can be periodically checked. If an account in the Administrators group is on the administrator whitelist and currently has administrator privileges, its administrator privileges will be maintained. If an account in the Administrators group is not on the administrator whitelist but currently has administrator privileges, its administrator privileges will be revoked; for example, the account can be transferred to a user group and recorded in the revoked list.

[0046] By adopting the above technical solution, a wide range of possible device account systems can be supported, including local accounts, local domain accounts, cloud domain accounts, etc. It can flexibly manage the local administrator permissions of the target device, thus meeting the device permission management needs of various device usage environments. It is not only universal but also meets the personalized needs of users.

[0047] In some embodiments, step S12, creating a custom token with administrator privileges to escalate privileges on the target device, may include: intercepting the startup process of the target program on the target device; matching the program information of the target program with the default privilege escalation rule in the target permission management policy, wherein the default privilege escalation rule is used to instruct that when a program specified in the default privilege escalation rule is started, the privileges of the process running the program specified in the default privilege escalation rule will be escalated to administrator privileges by default; if the program information of the target program matches the default privilege escalation rule in the target permission management policy, then a custom token with administrator privileges is created based on the token of the current account on the target device, and the target program is started using the custom token.

[0048] The target program can be any program on the target device; for example, it can be any program that the user wants to run.

[0049] For example, the startup process of a target program on a target device can be intercepted by injecting a target permission management policy into the host process responsible for launching the target program and hooking the application programming interface (API) used to create an instance of the target program. Injecting the target permission management policy into the host process can be achieved through dynamic link library (DLL) injection. Hooking the API used to create an instance of the target program can be achieved through an application programming interface (API) hook.

[0050] For example, the step of matching the target program's program information with the default privilege escalation rules in the target's permission management policy can be performed before the target program's startup process enters the User Account Control (UAC) pop-up. This ensures that default privilege escalation is completed before the UAC pop-up, guaranteeing the smooth operation of target programs that require administrator privileges. The main function of the UAC pop-up is to display a prompt when a user or program attempts to perform a task requiring administrator privileges, requesting confirmation from the currently logged-in user with administrator privileges or requiring administrator credentials from the currently logged-in user without administrator privileges.

[0051] For example, intercepting the startup process of a target program on a target device and matching the target program's information with the default privilege escalation rules in the target's permission management policy can be performed through Endpoint Privilege Management (EPM). Creating a custom token with administrator privileges based on the target device's current account token and using that custom token to launch the target program can be performed through a dedicated privilege escalation process. EPM can send privilege escalation requests for the target program to the privilege escalation process via a local remote procedure call (RPC), and the privilege escalation request can include the target program's information.

[0052] In addition, the default privilege escalation rules have been described in detail above and will not be repeated here.

[0053] By adopting the above technical solution, default privilege escalation can be achieved under any device account system on the target device, thus meeting the device permission management needs of various device usage environments and possessing universality. For example, it is applicable to local account systems, local domain account systems, cloud domain account systems, etc. Furthermore, because the default privilege escalation rules can achieve more granular permission management, such as specific time periods, specific programs, specific directories, specific processes, and specific signatures, it has strong flexibility and can meet users' personalized permission management needs. In addition, by managing permissions on the target device in the cloud, the privileges of the local administrator on the target device can be revoked, and permission management on the target device can be performed locally on the target device according to the default privilege escalation rules. This reduces the risk of the target device's operating environment being compromised, significantly narrows the attack surface, and defends against attacks. It also flexibly meets permission requirements in specific scenarios, and from an enterprise operation perspective, it can unify the device operating environment and improve enterprise operational efficiency.

[0054] In some embodiments, step S12, creating a custom token with administrator privileges to escalate privileges on the target device, may include: generating a self-service privilege escalation entry on the target device according to a self-service privilege escalation enable instruction in the target permission management policy, wherein the self-service privilege escalation enable instruction is used to instruct the generation of a self-service privilege escalation entry on the target device; in response to a privilege escalation request for the target program through the self-service privilege escalation entry, matching the privilege escalation request with a self-service privilege escalation rule in the target permission management policy, wherein the self-service privilege escalation rule is used to instruct the privileges of the process running the target program to be automatically escalated to administrator privileges based on the privilege escalation request; if the privilege escalation request matches the self-service privilege escalation rule, creating a custom token with administrator privileges based on the token of the current account on the target device, and launching the target program using the custom token.

[0055] For example, one can control the generation of a self-service privilege escalation entry in the right-click menu on the target device by modifying the registry, or by modifying the registry and using desktop right-click menu extension technology based on the modern user interface (UI) style implemented by Microsoft Universal Windows Platform (UWP) technology. This way, users can easily find the self-service privilege escalation entry through the right-click menu.

[0056] Matching privilege escalation requests with self-service privilege escalation rules in the target access control policy can be performed via a pop-up application. Creating a custom token with administrator privileges based on the target device's current account token and then using this custom token to launch the target application can be performed via the privilege escalation process described earlier. The pop-up application and the privilege escalation process can communicate via local RPC.

[0057] When a user runs a target program that requires administrator privileges, to achieve self-service privilege escalation, they can right-click the target program's icon on the target device. A pop-up right-click menu will appear. Clicking the self-service privilege escalation entry in the right-click menu will then allow the user to apply for self-service privilege escalation if the current time falls within the permitted time period specified by the rules. For example, if the rules specify the allowed time periods for self-service privilege escalation and whether a reason for the application is required, a self-service privilege escalation application window will then appear (e.g., ...). Figure 2As shown, the self-service privilege escalation request window displays program information for programs requiring administrator privileges to run. Users can verify if this program information matches the program information of the target program they wish to run. If they match, the user can confirm the request, and the self-service privilege escalation request will be sent to the privilege escalation process. The request can include the target program's program information. Additionally, the self-service privilege escalation request window can display a reason for escalation, requiring the user to fill in the reason. If the current self-service privilege escalation rules are not met—for example, if the rules specify a time period during which self-service privilege escalation is allowed, and the current time is outside that period—a self-service privilege escalation rejection window will pop up (e.g., ...). Figure 3 As shown in the image, the user's self-service privilege escalation request was rejected.

[0058] In addition, the self-service privilege escalation rules have been described in detail above and will not be repeated here.

[0059] By adopting the above technical solution, self-service privilege escalation can be achieved under any device account system on the target device, thus meeting the device permission management needs of various device usage environments and possessing universality. For example, it is applicable to local account systems, local domain account systems, cloud domain account systems, etc. Furthermore, because the self-service privilege escalation rules can achieve more granular permission management, such as specific time periods, specific programs, specific directories, specific processes, and specific signatures, it has strong flexibility and can meet users' personalized permission management needs. In addition, by managing permissions on the target device in the cloud, the privileges of the local administrator on the target device can be revoked, and permission management on the target device can be performed locally on the target device according to the self-service privilege escalation rules. This reduces the risk of the target device's operating environment being compromised, significantly narrows the attack surface, and defends against attacks. It also flexibly meets permission requirements in specific scenarios, and from an enterprise operation perspective, it can unify the device operating environment and improve enterprise operational efficiency.

[0060] In some embodiments, the device permission management method according to this disclosure may further include: sending permission management logs to a server. For example, sending permission management logs to the server after default privilege escalation, after self-service privilege escalation, etc. The permission management logs can be used for auditing by cloud administrators.

[0061] Access control logs can include various access control-related information that cloud administrators want to know, such as information about privilege escalation methods, the programs targeted by privilege escalation, and the devices requesting privilege escalation. For example, access control logs can include the device identifier of the device being controlled, the platform used by the device (e.g., Windows platform), the login account of the device when the access control log was generated, the privilege escalation method of the device (e.g., default privilege escalation method, self-service privilege escalation method, etc.), information about the objects being controlled on the device (e.g., the program targeted by privilege escalation and related information, such as the program's path, publisher, hash value, etc.), and the time the device was controlled, etc.

[0062] By adopting the above technical solutions, the access control log can establish a correlation between the access escalation method, the program targeted by the access escalation, and the device requesting the access escalation, which facilitates risk identification and content auditing by cloud administrators.

[0063] Figure 4 This is a schematic block diagram of a device permission management apparatus according to an embodiment of the present disclosure. This device permission management apparatus is universally applicable to device permission management in various scenarios, such as local account scenarios, local domain scenarios, and cloud domain scenarios. Figure 4 As shown, the device permission management device 40 may include: an acquisition module 41, used to acquire a target permission management policy for a target device from a pre-configured permission management policy on the server, wherein the target device is a device whose permissions are managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permissions are managed; and a management module 42, used to manage the administrator permissions on the target device according to the target permission management policy, and to create a custom token with administrator permissions to escalate the permissions of the target device.

[0064] By adopting the above technical solution, the target permission management policy for the target device is obtained from the pre-configured permission management policy on the server. Then, according to the target permission management policy, the administrator permissions on the target device are managed, and a customized token with administrator privileges is created to escalate the device's permissions. This permission management method is limited by the target permission management policy on the server, but not by the device account system. Therefore, it can widely support possible device account systems, including local accounts, local domain accounts, and cloud domain accounts, thus meeting the device permission management needs of various device usage environments and possessing universality. In addition, because the permission rules in the target permission management policy can achieve more granular permission management, such as specific time periods, specific programs, specific directories, specific processes, and specific signatures, it has strong flexibility and can meet users' personalized permission management needs. In addition, by managing access permissions for target devices in the cloud, the privileges of local administrators on the target devices can be revoked, and access permissions for the target devices can be managed locally on the target devices according to the target access management policy. This can reduce the risk of the target device's operating environment being compromised, significantly reduce the attack surface, and defend against attacks. It can also flexibly meet the access requirements in specific scenarios. Moreover, from the perspective of enterprise operations, it can also unify the device operating environment and improve enterprise operational efficiency.

[0065] Optionally, the management module 42 manages the administrator privileges on the target device, including:

[0066] Match the administrator whitelist in the target permission management policy with the permissions of each account on the target device. The administrator whitelist is used to indicate the accounts on the target device that have administrator privileges.

[0067] Based on the matching results, the administrator privileges of accounts that are not in the administrator whitelist but currently have administrator privileges will be revoked, and the administrator privileges of accounts that are in the administrator whitelist but whose administrator privileges were previously revoked will be granted administrator privileges.

[0068] Optionally, management module 42 creates a custom token with administrator privileges to escalate permissions on the target device, including:

[0069] Intercept the startup process of the target program on the target device;

[0070] The program information of the target program is matched with the default privilege escalation rule in the target permission management policy. The default privilege escalation rule is used to instruct that when the program specified in the default privilege escalation rule is launched, the privileges of the process running the program specified in the default privilege escalation rule will be elevated to administrator privileges by default.

[0071] If the program information of the target program matches the default privilege escalation rule in the target permission management policy, a custom token with administrator privileges is created based on the token of the current account on the target device, and the target program is launched using the custom token.

[0072] Optionally, the management module 42 intercepts the startup process of the target program on the target device, including:

[0073] By injecting the target permission management policy into the host process responsible for launching the target program and hooking the application interface used to create instances of the target program, the startup process of the target program on the target device is intercepted.

[0074] Optionally, management module 42 creates a custom token with administrator privileges to escalate permissions on the target device, including:

[0075] According to the self-service privilege escalation enable instruction in the target permission management policy, a self-service privilege escalation entry is generated on the target device. The self-service privilege escalation enable instruction is used to instruct the generation of a self-service privilege escalation entry on the target device.

[0076] In response to a privilege escalation request for the target program via the self-service privilege escalation portal, the privilege escalation request is matched with the self-service privilege escalation rules in the target permission management policy. The self-service privilege escalation rules are used to instruct the process running the target program to automatically escalate its permissions to administrator privileges based on the privilege escalation request.

[0077] If the privilege escalation request matches the self-service privilege escalation rules, a custom token with administrator privileges is created based on the current account's token on the target device, and the target program is launched using the custom token.

[0078] Optionally, the management module 42 generates a self-service privilege escalation entry on the target device, including:

[0079] By modifying the registry, a self-service privilege escalation entry can be generated in the right-click menu on the target device.

[0080] Optionally, the device access control device 40 further includes a sending module (not shown) for:

[0081] Send permission management logs to the server. The permission management logs include at least one of the following: information about the permission escalation method, information about the program targeted by the permission escalation, and information about the device requesting the permission escalation.

[0082] The specific implementation methods of the operations performed by each module in the device permission management device according to the embodiments of this disclosure have been described in detail in the relevant methods, and will not be repeated here.

[0083] This disclosure also provides a computer-readable medium having a computer program stored thereon, which, when executed by a processing device, implements the steps of any of the methods in this disclosure.

[0084] This disclosure also provides an electronic device, including:

[0085] A storage device on which computer programs are stored;

[0086] A processing apparatus for executing a computer program stored in a storage device to implement the steps of any method of the present disclosure.

[0087] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the methods in this disclosure.

[0088] Figure 5 This is a schematic diagram of a device permission management architecture according to an embodiment of the present disclosure.

[0089] like Figure 5 As shown, server 50 is located in the cloud and is used for unified management of all or some devices of an enterprise, such as unified access control for devices. For each device, server 50 can be pre-configured with a corresponding access control policy so that the access control policy can be used to manage the access of that device.

[0090] Target device 51 is one of the devices under the unified management of server 50. Server 50 sends the target permission management policy for target device 51 to EPM 511 of target device 51, realizing the distribution and updating of the pre-configured permission management policy.

[0091] EPM 511 injects the target permission management policy into the host process responsible for launching the target program in the resource manager 512 and application information service process 513 of the target device 51. It hooks the launch of the target program, for example, by hooking the application programming interface used to create an instance of the target program, thus intercepting the launch process. Before the UAC pop-up, EPM 511 matches the target program's program information with the default privilege escalation rules in the target permission management policy. If they match, EPM 511 sends the target program's program information to the privilege escalation process 516 on the target device 51 via local RPC. Privilege escalation process 516 can then create a custom token with administrator privileges based on the current account's token on the target device 51 and launch the target program using this custom token, achieving privilege escalation of the host process running the target program. Privilege escalation process 516 can also generate permission management logs and send them to server 50 for auditing by the cloud administrator. This implements the default privilege escalation operation on the target device 51.

[0092] EPM 511 can also control the generation of a self-service privilege escalation entry in the right-click menu 514 on the target device 51, based on the self-service privilege escalation enable instruction in the target permission management policy, either by modifying the registry or by modifying the registry and using a modern UI-style desktop right-click menu extension technology based on Microsoft UWP technology. When a user requests self-service privilege escalation for the target program, the pop-up program in the self-service privilege escalation pop-up module 515 matches the user's privilege escalation request with the self-service privilege escalation rules in the target permission management policy. If they match, the pop-up program sends the target program's program information to the privilege escalation process 516 via local RPC. The privilege escalation process 516 can then create a custom token with administrator privileges based on the token of the current account on the target device 51 and use the custom token to start the target program, thus achieving privilege escalation of the host process running the target program on the target device. The privilege escalation process 516 can also generate permission management logs and send them to the server 50 for auditing by the cloud administrator. This achieves the self-service privilege escalation operation on the target device 51.

[0093] Additionally, privilege escalation process 516 can inherit token creation capabilities from the local security authority on target device 51, thus enabling privilege escalation process 516 to create custom tokens with administrator privileges based on the tokens of the current account on target device 51.

[0094] By adopting the above technical solution, the target permission management policy for the target device is obtained from the pre-configured permission management policy on the server side. Then, permission management is applied to the target device according to the target permission management policy. This permission management method is limited by the server-side target permission management policy, but not by the device account system. Therefore, it can widely support possible device account systems, including local accounts, local domain accounts, and cloud domain accounts, thus meeting the device permission management needs of various device usage environments and possessing universality. Furthermore, because the permission rules in the target permission management policy can achieve more granular permission management, such as specific time periods, specific programs, specific directories, specific processes, and specific signatures, it has strong flexibility and can meet users' personalized permission management needs. In addition, by managing the target device's permissions in the cloud, the privileges of the local administrator on the target device can be revoked, and permission management can be applied to the target device locally according to the target permission management policy. This reduces the risk of the target device's operating environment being compromised, significantly narrows the attack surface, and defends against attacks. It also flexibly meets permission requirements in specific scenarios. Moreover, from an enterprise operation perspective, it can unify the device operating environment and improve enterprise operational efficiency.

[0095] The following is for reference. Figure 6The diagram illustrates a structural schematic of an electronic device 600 suitable for implementing embodiments of the present disclosure. Terminal devices in embodiments of the present disclosure may include, but are not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (personal digital assistants), PADs (tablet computers), PMPs (portable multimedia players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 6 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0096] like Figure 6 As shown, electronic device 600 may include a processing device (e.g., a central processing unit, a graphics processor, etc.) 601, which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 602 or a program loaded from storage device 608 into random access memory (RAM) 603. RAM 603 also stores various programs and data required for the operation of electronic device 600. Processing device 601, ROM 602, and RAM 603 are interconnected via bus 604. Input / output (I / O) interface 605 is also connected to bus 604.

[0097] Typically, the following devices can be connected to I / O interface 605: input devices 606 including, for example, touchscreens, touchpads, keyboards, mice, cameras, microphones, accelerometers, gyroscopes, etc.; output devices 607 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 608 including, for example, magnetic tapes, hard disks, etc.; and communication devices 609. Communication device 609 allows electronic device 600 to communicate wirelessly or wiredly with other devices to exchange data. Although Figure 6 An electronic device 600 with various devices is shown; however, it should be understood that it is not required to implement or possess all of the devices shown. More or fewer devices may be implemented or possessed alternatively.

[0098] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device 609, or installed from a storage device 608, or installed from a ROM 602. When the computer program is executed by the processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0099] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0100] In some implementations, clients and servers can communicate using any currently known or future-developed network protocol such as HTTP (Hypertext Transfer Protocol) and can interconnect with digital data communication (e.g., communication networks) of any form or medium. Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet (e.g., the Internet of Things), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks), as well as any currently known or future-developed networks.

[0101] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0102] The aforementioned computer-readable medium carries one or more programs. When the electronic device executes the aforementioned one or more programs, the electronic device causes the following to occur: It obtains a target permission management policy for a target device from a pre-configured permission management policy on the server, wherein the target device is a device whose permissions are managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permissions are managed; it manages the administrator permissions on the target device according to the target permission management policy, and creates a custom token with administrator permissions to escalate the permissions of the target device.

[0103] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including but not limited to object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0104] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0105] The modules described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules do not necessarily limit the module itself; for example, an acquisition module can also be described as "a module that acquires the target permission management policy for the target device from the pre-configured permission management policy on the server."

[0106] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0107] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0108] According to one or more embodiments of this disclosure, Example 1 provides a device access control method, including:

[0109] Obtain the target permission management policy for the target device from the pre-configured permission management policy on the server, wherein the target device is a device whose permission is managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permission is managed.

[0110] According to the target permission management policy, permission management is performed on the administrator permissions on the target device, and a custom token with administrator permissions is created to escalate the permissions of the target device.

[0111] According to one or more embodiments of this disclosure, Example 2 provides the method of Example 1, wherein the permission management of administrator privileges on the target device includes:

[0112] The administrator whitelist in the target permission management policy is matched with the permissions of each account on the target device, wherein the administrator whitelist is used to indicate the accounts on the target device that have administrator privileges;

[0113] Based on the matching results, the administrator privileges of accounts that are not in the administrator whitelist but currently have administrator privileges will be revoked, and the administrator privileges of accounts that are in the administrator whitelist but whose administrator privileges were previously revoked will be granted administrator privileges.

[0114] According to one or more embodiments of this disclosure, Example 3 provides the method of Example 1, wherein creating a custom token with administrator privileges to escalate privileges on the target device includes:

[0115] Intercept the startup process of the target program on the target device;

[0116] The program information of the target program is matched with the default privilege escalation rule in the target permission management policy, wherein the default privilege escalation rule is used to instruct that when the program specified in the default privilege escalation rule is started, the privileges of the process running the program specified in the default privilege escalation rule will be escalated to administrator privileges by default;

[0117] If the program information of the target program matches the default privilege escalation rule in the target permission management policy, a custom token with administrator privileges is created based on the token of the current account on the target device, and the target program is launched using the custom token.

[0118] According to one or more embodiments of this disclosure, Example 4 provides the method of Example 3, wherein intercepting the startup process of a target program on a target device includes:

[0119] The startup process of the target program on the target device is intercepted by injecting the target permission management policy into the host process responsible for launching the target program and hooking the application interface used to create an instance of the target program.

[0120] According to one or more embodiments of this disclosure, Example 5 provides the method of Example 1, wherein creating a custom token with administrator privileges to escalate privileges on the target device includes:

[0121] According to the self-service privilege escalation activation instruction in the target permission management policy, a self-service privilege escalation entry is generated on the target device, wherein the self-service privilege escalation activation instruction is used to instruct the generation of the self-service privilege escalation entry on the target device;

[0122] In response to a privilege escalation request for a target program via the self-service privilege escalation portal, the privilege escalation request is matched with a self-service privilege escalation rule in the target permission management policy, wherein the self-service privilege escalation rule is used to instruct the privileges of the process running the target program to be automatically escalated to administrator privileges based on the privilege escalation request.

[0123] If the privilege escalation request matches the self-service privilege escalation rules, a custom token with administrator privileges is created based on the current account's token on the target device, and the target program is launched using the custom token.

[0124] According to one or more embodiments of this disclosure, Example 6 provides the method of Example 5, wherein generating a self-service privilege escalation entry on the target device includes:

[0125] By modifying the registry, a self-service privilege escalation entry can be generated in the right-click menu on the target device.

[0126] According to one or more embodiments of this disclosure, Example 7 provides a method of any one of Examples 1 to 6, wherein the method further includes:

[0127] Send a permission management log to the server, wherein the permission management log includes at least one of the following: information about the permission escalation method, information about the program targeted by the permission escalation, and information about the device requesting the permission escalation.

[0128] According to one or more embodiments of this disclosure, Example 8 provides a device access control apparatus, including:

[0129] The acquisition module is used to acquire the target permission management policy for the target device from the permission management policy pre-configured by the server, wherein the target device is a device whose permission is managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permission is managed.

[0130] The management module is used to manage the administrator privileges on the target device according to the target permission management policy, and to create a custom token with administrator privileges to escalate the permissions of the target device.

[0131] According to one or more embodiments of the present disclosure, Example 9 provides a computer-readable medium having a computer program stored thereon that, when executed by a processing device, implements the steps of any one of the methods in Examples 1-7.

[0132] According to one or more embodiments of this disclosure, Example 10 provides an electronic device, including:

[0133] A storage device on which computer programs are stored;

[0134] A processing device for executing a computer program stored in a storage device to implement the steps of any of the methods in Examples 1-7.

[0135] According to one or more embodiments of the present disclosure, Example 11 provides a computer program product including a computer program that, when executed by a processor, implements the steps of the method of any one of Examples 1 to 7.

[0136] The above description is merely a preferred embodiment of this disclosure and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0137] Furthermore, while the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

[0138] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative forms of implementing the claims. Regarding the apparatus in the above embodiments, the specific manner in which the various modules perform their operations has been described in detail in the embodiments relating to the method, and will not be elaborated upon here.

Claims

1. A device access control method, characterized in that, include: Obtain the target permission management policy for the target device from the pre-configured permission management policy on the server, wherein the target device is a device whose permission is managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permission is managed. According to the target permission management policy, permission management is performed on the administrator permissions on the target device, and a custom token with administrator permissions is created to escalate the permissions of the target device. The process of creating a custom token with administrator privileges to escalate permissions on the target device includes: The startup process of the target program on the target device is intercepted; the program information of the target program is matched with the default privilege escalation rule in the target permission management policy, wherein the default privilege escalation rule is used to instruct that when a program specified in the default privilege escalation rule is launched, the privileges of the process running the program specified in the default privilege escalation rule will be escalated to administrator privileges by default; if the program information of the target program matches the default privilege escalation rule in the target permission management policy, a custom token with administrator privileges is created based on the token of the current account of the target device, and the target program is launched through the custom token; or; According to the self-service privilege escalation activation instruction in the target permission management policy, a self-service privilege escalation entry is generated on the target device, wherein the self-service privilege escalation activation instruction is used to instruct the generation of the self-service privilege escalation entry on the target device; in response to a privilege escalation request for the target program through the self-service privilege escalation entry, the privilege escalation request is matched with the self-service privilege escalation rule in the target permission management policy, wherein the self-service privilege escalation rule is used to instruct the privilege of the process running the target program to be automatically escalated to administrator privilege based on the privilege escalation request; if the privilege escalation request matches the self-service privilege escalation rule, a custom token with administrator privileges is created based on the token of the current account on the target device, and the target program is launched through the custom token.

2. The method according to claim 1, characterized in that, The permission management for administrator privileges on the target device includes: The administrator whitelist in the target permission management policy is matched with the permissions of each account on the target device, wherein the administrator whitelist is used to indicate the accounts on the target device that have administrator privileges; Based on the matching results, the administrator privileges of accounts that are not in the administrator whitelist but currently have administrator privileges will be revoked, and the administrator privileges of accounts that are in the administrator whitelist but whose administrator privileges were previously revoked will be granted administrator privileges.

3. The method according to claim 1, characterized in that, The process of intercepting the startup of the target program on the target device includes: The startup process of the target program on the target device is intercepted by injecting the target permission management policy into the host process responsible for launching the target program and hooking the application interface used to create an instance of the target program.

4. The method according to claim 1, characterized in that, The process of generating a self-service privilege escalation entry on the target device includes: By modifying the registry, the self-service privilege escalation entry can be generated in the right-click menu on the target device.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: Send a permission management log to the server, wherein the permission management log includes at least one of the following: information about the permission escalation method, information about the program targeted by the permission escalation, and information about the device requesting the permission escalation.

6. A device access control system, characterized in that, include: The acquisition module is used to acquire the target permission management policy for the target device from the permission management policy pre-configured by the server, wherein the target device is a device whose permission is managed by the server, and the pre-configured permission management policy is a permission management policy pre-configured by the server for each device whose permission is managed. The management module is used to manage the administrator privileges on the target device according to the target permission management policy, and to create a custom token with administrator privileges to escalate the permissions of the target device. The management module creates a custom token with administrator privileges to escalate permissions on the target device, including: The startup process of the target program on the target device is intercepted; the program information of the target program is matched with the default privilege escalation rule in the target permission management policy, wherein the default privilege escalation rule is used to instruct that when a program specified in the default privilege escalation rule is launched, the privileges of the process running the program specified in the default privilege escalation rule will be escalated to administrator privileges by default; if the program information of the target program matches the default privilege escalation rule in the target permission management policy, a custom token with administrator privileges is created based on the token of the current account of the target device, and the target program is launched through the custom token; or; According to the self-service privilege escalation activation instruction in the target permission management policy, a self-service privilege escalation entry is generated on the target device, wherein the self-service privilege escalation activation instruction is used to instruct the generation of the self-service privilege escalation entry on the target device; in response to a privilege escalation request for the target program through the self-service privilege escalation entry, the privilege escalation request is matched with the self-service privilege escalation rule in the target permission management policy, wherein the self-service privilege escalation rule is used to instruct the privilege of the process running the target program to be automatically escalated to administrator privilege based on the privilege escalation request; if the privilege escalation request matches the self-service privilege escalation rule, a custom token with administrator privileges is created based on the token of the current account on the target device, and the target program is launched through the custom token.

7. A computer-readable medium having a computer program stored thereon, characterized in that, When executed by a processing device, the computer program performs the steps of the method described in any one of claims 1-5.

8. An electronic device, characterized in that, include: A storage device on which computer programs are stored; A processing device for executing the computer program in the storage device to implement the steps of the method according to any one of claims 1-5.

9. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images