Computing power resource security calling method and device, storage medium and program product

Abstract

Embodiments of the present disclosure disclose a computing power resource safe calling method and device, a storage medium and a program product. The method comprises: obtaining real calling information of a computing power resource node, generating virtual calling information of the computing power resource node based on the real calling information; receiving a computing power calling request of a user end, authenticating the computing power calling request, and determining a target computing power resource node requested by the user; if the authentication is successful, sending the real calling information of the target computing power resource node to the user end, so that the user end calls the target computing power resource node; if the authentication fails, sending the virtual calling information of the target computing power resource node to the user end. The method can determine whether to send real or virtual calling information to the user end through authentication, which can ensure the safety of computing power resources and prevent hackers from illegally logging in and misusing.

Description

Technical Field

[0001] This disclosure relates to the field of network technology, and in particular to a method, apparatus, storage medium, and program product for securely accessing computing resources. Background Technology

[0002] With the rapid development of artificial intelligence and cloud computing technologies, cloud-native platforms such as Kubernetes (K8s) have been widely used in data centers, scientific research, government and enterprise sectors, and finance. These platforms, through standard scheduling and scaling mechanisms, in conjunction with DevicePlugins, can automatically discover, elastically allocate, and containerize heterogeneous hardware resources such as GPUs, NPUs, and FPGAs, thereby significantly improving resource utilization and system flexibility. However, with the widespread application of computing resources, security issues have become increasingly prominent.

[0003] In intelligent computing cloud platforms, the computing power scheduling platform is used to efficiently distribute and manage AI training and inference tasks. However, hackers may illegally log in to computing power servers by cracking SSH passwords, abusing computing resources, leading to resource waste and potential security risks. To prevent such attacks, a common practice is to completely disable SSH password login, restricting users' direct access to computing power devices to improve resource isolation. While this method improves security to some extent, it also leads to a decline in user experience, increases management complexity, and may affect rapid response capabilities in emergency situations. Summary of the Invention

[0004] In view of this, the present disclosure provides a method, apparatus, storage medium, and program product for securely invoking computing resources. It can determine whether to send real or virtual invoking information to the user terminal through authentication, which can ensure the security of computing resources, prevent hackers from illegally logging in and abusing them, and does not require completely disabling SSH password login, thus balancing security and user experience.

[0005] In a first aspect, the present disclosure provides a method for securely invoking computing resources, employing the following technical solution:

[0006] Obtain the actual call information of the computing resource nodes, and generate virtual call information of the computing resource nodes based on the actual call information;

[0007] Receive computing power request from user terminal, authenticate the computing power request, and determine the target computing power resource node requested by user;

[0008] If authentication is successful, the actual call information of the target computing power resource node will be sent to the user terminal so that the user terminal can call the target computing power resource node.

[0009] If authentication fails, the virtual access information of the target computing resource node will be sent to the user terminal.

[0010] Optionally, the actual access information includes the actual access path of the computing resource node;

[0011] Virtual access information includes the virtual access path of the computing resource node;

[0012] Analyze the naming rules of the actual access path, and determine the generation rules of the virtual access path based on the naming rules;

[0013] Based on the generation rules, an initial virtual access path is generated;

[0014] Triggering conditions for acquiring computing power resource nodes;

[0015] When the computing resource node meets the triggering conditions, the virtual access path is updated based on the generation rules.

[0016] Optionally, updating the virtual access path based on the generation rule when the computing resource node meets the triggering condition includes:

[0017] Obtain the monitoring duration and access frequency of computing resource nodes;

[0018] When the monitoring duration reaches the update cycle, or when the monitoring duration does not reach the update cycle but the access frequency reaches the preset access frequency threshold, the virtual access path is updated based on the generation rule.

[0019] Optionally, the secure allocation method for computing resources further includes:

[0020] Receive SSH requests from the office area access terminal and identify the SSH requests;

[0021] If the identification is successful, the office area access terminal is allowed to access general resources;

[0022] If identification fails, access to general resources will not be permitted for the office area access terminal.

[0023] Optionally, sending the virtual invocation information of the target computing power resource node to the user terminal includes:

[0024] The risk level of the computing power request is determined by authenticating the computing power request.

[0025] Determine whether the risk level exceeds a preset level threshold;

[0026] If the limit is exceeded, check whether the target computing resource node is configured with a honeypot proxy module;

[0027] If a honeypot proxy module is configured, the computing power call request will be forcibly redirected to the honeypot proxy module;

[0028] If the honeypot proxy module is not configured, then configure the honeypot proxy module for the target computing power resource node. After the configuration is complete, forcibly redirect the computing power call request to the honeypot proxy module.

[0029] The honeypot proxy module sends virtual call information for the target computing resource node to the user terminal step by step based on the risk level.

[0030] The user terminal is targeted and captured based on the sent virtual call information.

[0031] Optionally, sending the virtual invocation information of the target computing power resource node to the user terminal further includes:

[0032] When the risk level does not exceed the level threshold, detect whether the target computing power resource node is configured with a honeypot proxy module;

[0033] If a honeypot proxy module is configured, the honeypot proxy module will send virtual call information of the target computing power resource node to the user terminal step by step based on the risk level.

[0034] Based on the sent virtual call information, the user terminal is lured and captured;

[0035] If no honeypot proxy module is configured, the virtual call information of the target computing power resource node will be sent to the user terminal.

[0036] Optionally, the honeypot proxy module sends virtual invocation information of the target computing resource node to the user terminal step by step based on the risk level, including:

[0037] Based on the risk level of the computing power call request, the honeypot proxy module determines the target trapping topology from a preset set of trapping topology maps;

[0038] The honeypot proxy module sends virtual call information of the target computing resource nodes to the user terminal step by step according to the target trapping topology map;

[0039] The trapping topology set includes trapping topologies of different risk levels. Each node in the trapping topology represents a virtual call information sending prompt. The directed edges between nodes indicate the sending order of the virtual call information, and the attributes of the directed edges include the triggering conditions for sending the next virtual call information.

[0040] Optionally, the secure allocation method for computing resources further includes:

[0041] The system's computing resources are divided into multiple regions, and the attack level of each region is assessed at different time periods;

[0042] Assess the importance level of computing resource nodes in each region;

[0043] Based on the attack level of each region and the importance level of the computing resource nodes in the region, risky computing resource nodes are identified from the computing resource nodes in all regions.

[0044] Configure a honeypot agent module for each risky computing resource node.

[0045] Secondly, this disclosure also provides a secure computing resource mobilization system, which adopts the following technical solution:

[0046] The generation module is used to obtain the actual call information of the computing resource nodes and generate virtual call information of the computing resource nodes based on the actual call information.

[0047] The determination module is used to receive computing power call requests from users, authenticate the computing power call requests, and determine the target computing power resource node requested by the user; if the authentication is successful, the call module is executed; if the authentication fails, the sending module is executed.

[0048] The invocation module is used to send the actual invocation information of the target computing power resource node to the user terminal, so that the user terminal can invoke the target computing power resource node;

[0049] The sending module is used to send the virtual call information of the target computing power resource node to the user terminal.

[0050] Thirdly, this disclosure also provides a computer device, which adopts the following technical solution:

[0051] The computer device includes:

[0052] At least one processor; and,

[0053] A memory communicatively connected to the at least one processor; wherein,

[0054] The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform any of the above-described methods for securely invoking computing resources.

[0055] Fourthly, embodiments of this disclosure also provide a computer-readable storage medium storing computer instructions for causing a computer to execute any of the above-described methods for securely invoking computing resources.

[0056] Fifthly, embodiments of this disclosure also provide a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of any of the methods described above.

[0057] The secure computing resource invocation method provided in this disclosure provides an accurate data foundation for the entire computing resource invocation system by obtaining real invocation information. This allows the system to clearly understand the actual usage of each computing resource node, and the generation of virtual invocation information by simulating real invocation information protects the real data. A strict authentication mechanism ensures that only legitimate users can invoke computing resources, and accurately matching resources is achieved by identifying the target computing resource node requested by the user. Upon successful authentication, the real invocation information is sent to the user, allowing the user to accurately understand the actual situation of the target computing resource node and thus make efficient invocations. Users can rationally arrange computing tasks based on the real information, fully utilize the performance of computing resources, and improve computing efficiency and business processing capabilities. For unauthorized users who fail authentication, sending virtual invocation information can mislead attackers and prevent the leakage of real information. In this case, the virtual invocation information serves as a defense against external malicious probing. Attackers cannot obtain real resource information, making targeted attacks difficult and costly, and reducing the likelihood of system attacks. Even if unauthorized users obtain virtual information, they cannot pose a substantial threat to the system, ensuring the stability and security of the entire computing resource invocation system. Furthermore, the virtual call information can mislead attackers, increasing the difficulty for them to obtain real information and reducing the risk of system attacks. In addition, by generating virtual call information and implementing strict authentication, this method prevents hackers from illegally logging in and abusing computing power, without needing to completely disable SSH password login, thus reducing the negative impact on user experience, management complexity, and emergency response capabilities.

[0058] The above description is merely an overview of the technical solution disclosed herein. In order to better understand the technical means of this disclosure and to implement it in accordance with the contents of the specification, and to make the above and other objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0060] Figure 1 A flowchart illustrating the secure invocation method for computing resources provided in this embodiment of the disclosure;

[0061] Figure 2 A flowchart illustrating the virtual access path generation method provided in this embodiment of the disclosure;

[0062] Figure 3 This is a schematic diagram of accessing the intelligent computing cloud platform provided in an embodiment of this disclosure;

[0063] Figure 4 A flowchart illustrating a method for trapping a user terminal based on virtual call information, provided in an embodiment of this disclosure;

[0064] Figure 5 A flowchart illustrating the virtual call information sending method provided in this embodiment of the disclosure;

[0065] Figure 6 A flowchart illustrating the honeypot agent module allocation method provided in this embodiment of the disclosure;

[0066] Figure 7 A schematic diagram of the computing resource secure access system provided in this embodiment of the disclosure;

[0067] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present disclosure. Detailed Implementation

[0068] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0069] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0070] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using structures and / or functionalities other than one or more of the aspects set forth herein.

[0071] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0072] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0073] Reference Figure 1 This disclosure provides a method for securely accessing computing resources, comprising the following steps:

[0074] S1: Obtain the actual call information of the computing resource nodes, and generate virtual call information of the computing resource nodes based on the actual call information;

[0075] S2: Receive computing power call requests from users, authenticate the computing power call requests, and determine the target computing power resource node requested by the user;

[0076] S3: If authentication is successful, the actual call information of the target computing power resource node will be sent to the user terminal so that the user terminal can call the target computing power resource node;

[0077] S4: If authentication fails, the virtual call information of the target computing power resource node will be sent to the user terminal.

[0078] The secure method for accessing computing resources disclosed herein provides an accurate data foundation for the entire computing resource access system by obtaining real access information. This allows the system to clearly understand the actual usage of each computing resource node, such as the utilization rate of computing power and its operating status, thus providing a basis for subsequent resource allocation and scheduling. Generating virtual access information protects the real data. Virtual access information can disguise or distort real information to a certain extent, preventing the leakage of real access information in certain situations and enhancing the security and privacy of computing resource node information.

[0079] Through rigorous authentication mechanisms, such as identity verification and permission checks, it is ensured that only legitimate users can access computing resources, preventing malicious access and abuse by unauthorized users and effectively protecting the security and availability of computing resources. Determining the target computing resource node requested by the user enables precise resource matching. The system can select suitable computing resources for the user based on their needs and the actual situation of each computing resource node, improving resource utilization efficiency and avoiding waste and conflicts. Upon successful authentication, the system sends accurate access information to the user, allowing them to accurately understand the actual situation of the target computing resource node and thus make efficient access. Users can rationally arrange computing tasks based on accurate information, fully utilizing the performance of computing resources and improving computing efficiency and business processing capabilities. By providing accurate resource information to legitimate users, systemic issues such as access failures or resource waste due to inaccurate information are avoided, enhancing user trust and satisfaction.

[0080] For unauthorized users whose authentication fails, sending virtual call information can mislead attackers and prevent the leakage of real information. In this case, the virtual call information serves as a defensive measure against malicious external probing. Attackers cannot obtain real resource information, making it difficult to launch targeted attacks, increasing the difficulty and cost of attacks, and reducing the likelihood of system attacks. Even if unauthorized users obtain virtual information, they cannot pose a substantial threat to the system, ensuring the stability and security of the entire computing resource call system. Furthermore, the virtual call information can mislead attackers, increasing the difficulty for them to obtain real information and reducing the risk of system attacks.

[0081] In addition, this method avoids hackers from illegally logging in and abusing computing power by generating virtual call information and implementing strict authentication. It does not require completely disabling SSH password login, thus reducing the negative impact on user experience, management complexity, and emergency response capabilities.

[0082] In S1, all computing resource nodes on the intelligent computing cloud platform are statistically analyzed to obtain their actual usage information. This information includes the actual access paths, actual memory size, computation frequency, and model support of the computing resource nodes. Virtual usage information for the computing resource nodes is generated by simulating this actual usage information. This virtual usage information includes the virtual access paths and other relevant virtual information of the computing resource nodes. (Refer to...) Figure 2 The flowchart illustrating the virtual access path generation method shows the steps involved in "generating virtual access information for computing resource nodes based on real access information":

[0083] S11: Analyze the naming rules of the real access path, and determine the generation rules of the virtual access path based on the naming rules;

[0084] S12: Generate the initial virtual access path based on the generation rules;

[0085] S13: Triggering conditions for acquiring computing power resource nodes;

[0086] S14: When the computing resource node meets the triggering conditions, update the virtual access path based on the generation rules.

[0087] In the steps described above, a certain number of real access path samples are collected. These samples should cover real access paths of different types and business scenarios as much as possible to ensure the comprehensiveness of the analysis. The collected samples are then analyzed in detail to observe the patterns in the composition of each part of the path, such as whether there are fixed prefixes or suffixes, whether there are parts arranged according to specific numbers or time sequences, and whether specific characters or symbols are used for separation. After analyzing the naming rules of real access paths, the generation rules for virtual access paths are determined based on this. The generation rules should mimic the characteristics of real paths to a certain extent to increase the deceptiveness of the virtual paths. For example, if real paths frequently use dates as part of their numbering, then virtual paths can also use a similar date numbering method. At the same time, some random elements, such as random strings or numbers, can be introduced to prevent the virtual paths from being too predictable and easily identified by attackers.

[0088] Based on the established virtual access path generation rules, a corresponding code program is written. This program generates virtual access paths according to a certain logical combination of various elements in the rules, such as fixed prefixes, random elements, and numbering methods. During the generation process, a random number generator is used to generate random strings or numbers that meet the rule requirements and insert them into appropriate positions. After generating the initial virtual access paths, their validity is checked, including whether the paths conform to the generation rules, whether they contain illegal characters, and whether they conflict with existing real or virtual paths. If any paths are found to be invalid, they are regenerated until the conditions are met, ultimately resulting in a set of initial, deceptive virtual access paths.

[0089] To accurately determine the triggering conditions of computing resource nodes, comprehensive monitoring of these nodes is necessary. A dedicated monitoring system should be established to monitor various metrics of the computing resource nodes in real time, with a focus on two key indicators: the monitoring duration and the access frequency. The monitoring duration can be obtained by recording the time from the start of monitoring to the current moment, while the access frequency is calculated by counting the number of access requests to the node within a certain time interval. This data should be stored in a database in real time for subsequent analysis and judgment.

[0090] The monitoring duration and access frequency are continuously evaluated. When the monitoring duration reaches a pre-set update cycle, it indicates that it's time to update the virtual access paths. Alternatively, even if the monitoring duration hasn't reached the update cycle, but the access frequency reaches a preset access frequency threshold, this suggests potential abnormal access behavior, necessitating a timely update of the virtual access paths. When these triggering conditions are met, the previously written code program that generates virtual access paths based on the generation rules is invoked again. A new set of virtual access paths is generated according to the rules, replacing the original ones. Simultaneously, the updated virtual access path information is synchronized to the relevant system modules to ensure that subsequent access requests correctly use the new virtual paths.

[0091] In S2, the super administrator performs basic security configurations in the data center, configuring SSH and operating system security policies for all computing power servers. Entry control is strengthened through sshd_config's Match Address, Permit Root Login, and firewall IP whitelists, ensuring that only IPs in specific management network segments (such as bastion hosts and dedicated maintenance areas) can remotely log in with root privileges. These root-privileged IPs can perform permission modification, authorization, and maintenance operations on computing power resource nodes (such as / dev / gpu*, / dev / npu*, and other computing power card device nodes). Other IP areas (such as ordinary business areas and office areas) only allow login to the computing power servers with ordinary accounts. These ordinary accounts do not have the right to directly access, allocate, or operate computing power card-related device nodes; they can only perform routine maintenance operations such as log viewing and file management. Simultaneously, through udev rules and Linux ACLs / group permissions, access permissions to computing power resource nodes are strictly limited to root or specific security groups, supplemented by regular permission audits, ensuring that unauthorized accounts or non-management area IPs cannot bypass the platform to directly operate computing power resources.

[0092] When a user initiates a computing power call request—that is, every time a container or process requests the allocation or use of a device—the computing power card proxy module "GPU-Proxy" (implemented by rewriting the Device Plugin) in the computing power server begins to receive the request. Upon receiving the computing power call request, the Proxy first performs a whitelist authentication operation, checking whether the user or related identity information initiating the computing power call request exists in a pre-defined whitelist. If not, the request is directly rejected; if it is in the whitelist, the Proxy verifies the national cryptographic signature, token, certificate, or other identity credentials in the computing power call request using national cryptographic algorithms such as SM2, SM3, and SM4, thus completing further authentication of the computing power call request. During the processing of the computing power call request, the Proxy determines the target computing power resource node requested by the user based on relevant request information, such as the type and quantity of computing power requested. To ensure secure access to computing resources, the system employs a device node "soft proxy" mechanism. Before user authentication is successful, the actual call information of computing resource nodes (such as real physical device nodes, like / dev / nvidia0 and / dev / davinci0) is not visible to or cannot be directly accessed by ordinary users / processes. The proxy creates "virtual device nodes" (such as / dev / gpu-proxy0) for containers or tasks that need to access computing power, and all operations are directed to the proxy layer.

[0093] Reference Figure 3The diagram illustrating access to the intelligent computing cloud platform shows that super administrators in the data center can directly access the CPU, configure virtual call information for computing resource nodes, and set up whitelists. For users on the public network, they log in to the intelligent computing cloud platform via a webpage on their client side to issue computing power call requests. Because the authentication mechanism for computing power call requests and the use of virtual call information enhance the security of user-side computing power calls, SSH login permissions for maintenance personnel in the office area can be relaxed. Maintenance personnel can log in using SSH. Upon receiving an SSH request from an office access point, the system identifies the request. If successful, it confirms that the request originates from a legitimate office maintenance personnel and meets all security requirements, allowing the office access point to access general resources. If identification fails, access to general resources is denied. This method, which restricts computing resource access without blocking SSH, avoids restricting the operations of maintenance personnel, facilitating daily maintenance and troubleshooting, improving operational efficiency, and reducing management costs and complexity. By employing authentication mechanisms and virtual computing card technology, the system enhances the security of computing resources while dynamically adjusting access policies based on different user roles and network environments. This provides flexibility in accessing computing resources, particularly addressing the differences in access needs between field personnel and office staff. Furthermore, through IP-layered and permission-based access control methods, the system ensures the security of underlying computing server scheduling information while allowing users with reasonable needs to access relevant information on demand. This reduces the adverse effects of "only knowing the scheduling status when using the system" on user experience and improves the orderliness and controllability of system management.

[0094] In S3, if GPU-Proxy successfully authenticates the computing power request, it uses a dynamic soft link switching mechanism to soft link or bind the virtual computing power resource node to the target computing power resource node through cloud platform authorization (such as Device Plugin or Proxy). During container mounting, only the virtual computing power resource node is mounted into the target container; the target computing power resource node is hidden on the host side, and the Proxy maintains global management and dynamic switching capabilities for the soft links. Subsequently, the actual call information of the target computing power resource node, such as the device's specific identifier, access path, available computing power parameters, memory size, and computing frequency, is sent to the user client. After receiving this actual call information, the user client can use this information to invoke the target computing power resource node and utilize the computing power resources.

[0095] In S4, when GPU-Proxy authenticates a computing power access request, authentication fails if the client is not on the whitelist, or if the verification of the national cryptographic signature, token, certificate, or other identity credentials fails. In this case, a dynamic soft link switching mechanism is used to point the virtual device node to / dev / null or directly remove the soft link to prevent unauthorized access. Simultaneously, virtual access information for the target computing power resource node is sent to the client. This virtual information includes seemingly legitimate but actually unusable device identifiers and access paths, misleading potential unauthorized requesters and preventing the leakage of real computing power resources.

[0096] During the computing task scheduling process, the Proxy meticulously logs all behaviors related to computing resources, including resource allocation, access, and reclamation, as well as details of abnormal attempts and the command parameters used. To meet security and compliance requirements, these logs are encrypted and signed. The Proxy then stores the processed log information in an audit database, allowing backend personnel to audit this information at any time, ensuring the security and compliance of the computing task scheduling process.

[0097] Furthermore, when authentication fails, in addition to directly sending virtual call information to the user terminal, the virtual call information can also be used to lure and capture the user terminal in order to monitor and analyze potential malicious behavior, thereby enhancing the system's security and defense capabilities. (See reference...) Figure 4 The flowchart illustrating a method for trapping user terminals based on virtual call information demonstrates that "sending the virtual call information of the target computing resource node to the user terminal" includes:

[0098] S41: Determine the risk level of a computing power request by authenticating the computing power request;

[0099] S42: When the risk level exceeds the preset level threshold, check whether the target computing power resource node is configured with a honeypot proxy module; if yes, execute S43; if no, execute S44.

[0100] S43: Force redirection of computing power call requests to honeypot proxy module;

[0101] S44: Configure the honeypot proxy module for the target computing power resource node. After the configuration is complete, the computing power call request will be forcibly redirected to the honeypot proxy module.

[0102] S45: The honeypot proxy module sends virtual call information of the target computing power resource node to the user terminal step by step based on the risk level;

[0103] S46: Based on the sent virtual call information, the user terminal is lured into a trap.

[0104] In S41, during the authentication process for computing power call requests, in addition to routine authentication operations, dynamic monitoring of the behavior patterns of these requests is required. Specific monitoring includes request frequency and rhythm, request path and sequence, and the characteristics of the request data. Regarding request frequency and rhythm, attention should be paid to whether the number of requests per unit time exceeds the normal range, and whether there are high-frequency requests within a short period, such as brute-force attacks where attackers attempt to gain system privileges through numerous attempts. Simultaneously, the temporal distribution of requests should be analyzed to determine if there are any abnormal request intervals. For request paths and sequences, it is necessary to check whether the requests follow normal business processes and whether there are any abnormal jumps or bypasses of necessary steps. For example, in a simulated token replay attack, an attacker might use a stolen token to repeatedly initiate requests to bypass authentication. Regarding request data characteristics, it is necessary to analyze whether the data carried in the request conforms to normal business logic and whether the data format, size, and content are reasonable. Furthermore, for access characteristics such as certain source IP ranges, anonymous access gateways, and VPNs, a rule base needs to be established for matching. If the source IP of the request is in a known high-risk IP range, or if it accesses through an anonymous access gateway or VPN and its behavior characteristics match the preset risk rules, then the risk assessment of the request needs to be enhanced. Combining the dynamic monitoring results of the computing power call request behavior patterns and the matching of access characteristics, the risk level of the computing power call request is finally determined. A risk assessment model can be established, taking factors such as request initiation time, request source, and operation mode as input, and training the model through machine learning algorithms to automatically output an accurate risk level.

[0105] In S42-S44, to avoid the honeypot proxy module consuming excessive memory resources, it is only pre-configured on a subset of computing power resource nodes. Therefore, when the risk level of a computing power call request exceeds a preset threshold, it is necessary to first check whether the target computing power resource node is configured with a honeypot proxy module. If not, the honeypot proxy module must be configured on the target computing power resource node. After configuration, the computing power call request is forcibly redirected using methods such as network routing control or application-layer interception. Network routing control can be implemented by modifying static routes or adjusting dynamic routing protocol parameters; application-layer interception can be achieved by setting up a proxy server or deploying middleware to redirect the request to the honeypot proxy module.

[0106] In S45, refer to Figure 5 The flowchart illustrating the virtual call information sending method shows that "the honeypot proxy module gradually sends virtual call information of the target computing resource node to the user terminal based on the risk level," which includes:

[0107] S451: Based on the risk level of the computing power call request, the honeypot agent module determines the target trapping topology from the preset trapping topology set;

[0108] S452: The honeypot agent module sends virtual call information of the target computing power resource nodes to the user terminal step by step according to the target trapping topology map.

[0109] The trapping topology set contains trapping topologies of different risk levels. Each node in the trapping topology represents a virtual call message sending prompt. The directed edges between nodes indicate the sending order of the virtual call messages. The attributes of the directed edges include the triggering conditions for sending the next virtual call message.

[0110] In S45 and S46, after receiving the risk level of a computing power call request, the honeypot agent module accesses a preset set of trapping topologies. Since this set is categorized and stored according to different risk levels, the honeypot agent module can accurately select the target trapping topology matching the determined risk level. Once the honeypot agent module obtains the target trapping topology, it begins working according to the instructions of the nodes and directed edges in the graph. Specifically, the honeypot agent module invokes and sends the corresponding virtual call information based on the sending prompts in the nodes. The directed edges specify the sending order of the virtual call information, and the honeypot agent module sends the information to the user terminal sequentially in this order. Simultaneously, the attributes of the directed edges define the triggering conditions for sending the next virtual call information. The honeypot agent module will only send the next message when these conditions are met. For example, if the triggering condition is a specific response from the user terminal to a certain message, the honeypot agent module will wait for that response before sending subsequent messages, gradually completing the sending of virtual call information for the target computing power resource node, thereby guiding the user terminal to perform corresponding operations.

[0111] Suppose a company receives a high-risk computing power request. The honeypot proxy module quickly and accurately locates the target trapping topology corresponding to the high-risk level from a pre-set set of trapping topologies. In this target trapping topology, the first node prompts the sending of attribute information such as virtual access paths, memory size, and driver versions. Directed edges stipulate that the honeypot proxy module only enters the "layered trapping mode" according to the topology diagram when the user client makes further requests for this information (e.g., the user client attempts to access the resource using the virtual access path). Upon entering the first level of trapping, the honeypot proxy module sends information exhibiting slight anomalies, such as simulating performance bottlenecks, informing the user client that the current virtual target computing power resource node has certain performance issues and may have a slow response time. The trigger condition is that the user client continues to attempt resource operations or data acquisition after receiving the slight anomaly feedback. When this trigger condition is met, the second level of trapping begins. The honeypot proxy module guides the attacker to upload a model or perform training. Specifically, this can be done by sending seemingly encouraging prompts, such as indicating that the current resource is suitable for model training and offering promotional activities. The trigger condition is that the attacker responds to the guidance and begins uploading a model or initiating a training request. Once the attacker begins uploading the model or executing training, the third level of deception begins. The honeypot proxy module provides forged results to prevent the attacker from obtaining valid feedback. It also forces a delay in processing; for example, it informs the attacker that model training is complete, but the results may have some deviation, and sets a long delay when sending the forged results to further enhance deception. This process gathers information about the attacker's toolchain, command combinations, and uploaded data structures, gradually guiding the user into the deception process, thereby exposing more attack operations and tools. Furthermore, by enticing the user to operate, it buys the system time to defend against attacks.

[0112] The pre-defined set of trapping topologies should not be static, but dynamically updated based on actual conditions. Past attack cases can be collected and analyzed, and newly emerging attack patterns and characteristics can be incorporated into the trapping topologies. For example, if a new attack method is discovered that probes computing resources through a specific request sequence, corresponding nodes and directed edges can be added to the trapping topologies of the appropriate risk level to improve the effectiveness of the trapping.

[0113] To enhance the decoy effect, the virtual call information should be more diverse. A random number generator can be used to generate some virtual parameters, such as memory size and computation frequency, allowing them to vary randomly within a certain range. For error codes and status responses, in addition to the preset types, new error codes and response information can be dynamically generated based on different scenarios and attack types, making it difficult for attackers to distinguish between real and fake.

[0114] Furthermore, when the risk level does not exceed the threshold, the system checks whether the target computing power resource node is configured with a honeypot proxy module. If a honeypot proxy module is configured, it gradually sends virtual call information of the target computing power resource node to the user terminal based on the risk level. Based on the sent virtual call information, the user terminal is then targeted for capture. If no honeypot proxy module is configured, the virtual call information of the target computing power resource node is sent directly to the user terminal. This method reduces the need for complex capture strategies on user terminals with lower potential threats. Since the target computing power resource node lacks additional capture capabilities when no honeypot proxy module is configured, directly sending virtual call information allows for a quick response to requests, meeting basic user needs. This operation ensures the system's efficiency in processing requests, reducing unnecessary processing steps and time consumption. Although it lacks deep capture, it can simulate real computing power calls to a certain extent, maintaining normal system interaction and allowing for preliminary observation of subsequent user behavior. Moreover, configuring honeypot proxy modules for all computing power resource nodes would consume a large amount of system memory and computing power resources; this method saves system resources while ensuring system security.

[0115] Assuming the computing power request is low-risk and the target computing resource node is configured with a honeypot proxy module, the honeypot proxy module, based on the target trapping topology corresponding to the low-risk level, initially responds in low-simulation mode, returning a fixed error code and simplified attribute values, such as "device not available". If the requester continues to attempt, it can switch to medium-simulation mode, issuing a virtual access path, simulating complete attribute fields such as memory size and driver version, supporting partial I / O, and using latency simulation to add random response time, simulating slow loading or system congestion. During this process, the parameters returned by the virtual device, such as memory size and computing frequency, can be switched periodically or according to the requester's behavior, and the returned error codes will also change between "device busy", "permission denied", and "driver failure", thereby inducing the requester to perform more operations and exposing its operating procedures and tools.

[0116] During attacker tracing, detailed logs are recorded for all access behaviors via virtual paths, covering the original request IP, port, user identity information, operation commands and their parameters, uploaded model or data files, access behavior chains, and time-series behavior trajectories to reconstruct attack patterns. The system uniquely identifies and binds access sessions, combining browser fingerprints, user agent identifiers, naming patterns, and tag types in uploaded datasets for comprehensive tracing, thereby inferring the attacker's domain or business scenario. All behavior logs can be integrated with SIEM and security forensics systems, and both local encryption and remote synchronous transmission are supported.

[0117] Furthermore, in the process of allocating honeypot proxy modules to computing resource nodes, it is necessary to consider the system resource occupancy and the actual needs for attack prevention. Based on this, the method also provides a honeypot proxy module allocation method, referring to... Figure 6 The flowchart illustrates the honeypot proxy module allocation method, which includes the following steps:

[0118] S51: Divide the system's computing resources into multiple regions and assess the attack level of each region at different time periods;

[0119] S52: Assess the importance level of computing resource nodes in each region;

[0120] S53: Based on the attack level of each region and the importance level of the computing power resource nodes in the region, identify the risky computing power resource nodes from all computing power resource nodes in all regions;

[0121] S54: Configure a honeypot agent module for each risky computing resource node.

[0122] The above steps support dynamic adjustment of honeypot resource deployment density based on time, behavior patterns, or attack risk levels. Regarding density allocation, more honeypot proxy modules can be configured during specific time periods or in high-incidence attack areas. Specific adjustment methods include: time-driven adjustment: during peak attack periods such as nighttime and weekends, the attack level in most areas increases, while the importance level of computing power resource nodes typically doesn't change easily. Therefore, with more risky computing power resource nodes, the proportion of honeypot proxy modules increases accordingly, allowing them to occupy 70%-100% of all virtual path resources in the system; behavior-driven adjustment: when a large number of computing power path scans, repeated model uploads, or abnormal scheduling frequencies are detected in a certain area within a short period, it can be determined that the attack level in that area is high, and more risky computing power resource nodes will be identified, thus automatically increasing the density of honeypot proxy modules; tenant / user-driven adjustment: for unidentified users or risky tenants, a high honeypot coverage strategy is configured, ensuring that the paths they encounter by default are fake nodes. Furthermore, the deployment of honeypot proxy modules in the path space supports both sparse and dense modes. In sparse mode, a small number of honeypot proxy modules are evenly distributed throughout the path namespace, while in dense mode, a large number of honeypots are deployed in a concentrated area, forming a "path trap." Additionally, based on the importance level of risky computing power resource nodes, the priority of the honeypot proxy modules assigned to them is set; the system load is assessed in real time, and when the system load exceeds a preset load threshold, honeypot proxy modules are shut down in ascending order of priority until the system load no longer exceeds the load threshold.

[0123] In summary, this method, by introducing dynamic deformation and adaptive honeypot resource control mechanisms, combined with layered trapping and behavior tracking auditing design, can greatly enhance the platform's ability to perceive and trace unauthorized computing power access. When the system detects that an attacker repeatedly accesses the same path, or attempts to perform read, write, or persistent mounting operations on the path, it triggers a "honeypot path deformation" operation, creating the illusion of "unstable environment" and "unreliable hardware," misleading the attacker's judgment of the attack behavior, and forcing them to actively expose more operational processes and tools. This mechanism effectively improves the system's "unidentifiableness," reduces the probability of the honeypot being detected, and makes the computing power environment faced by attackers constantly changing and unpredictable, allowing the system to proactively obtain attack intentions, toolchains, and model data.

[0124] Reference Figure 7 This disclosure provides a secure computing resource mobilization system, including:

[0125] The generation module 101 is used to obtain the actual call information of the computing resource nodes and generate virtual call information of the computing resource nodes based on the actual call information;

[0126] The determination module 102 is used to receive computing power call requests from users, authenticate the computing power call requests, and determine the target computing power resource node requested by the user; if the authentication is successful, the call module is executed; if the authentication fails, the sending module is executed.

[0127] The calling module 103 is used to send the actual calling information of the target computing power resource node to the user terminal so that the user terminal can call the target computing power resource node;

[0128] The sending module 104 is used to send the virtual call information of the target computing power resource node to the user terminal.

[0129] The various variations and specific examples of the secure computing resource invocation method provided above are also applicable to the secure computing resource invocation system provided in this disclosure. Through the foregoing detailed description of the secure computing resource invocation method, those skilled in the art can clearly understand the implementation method of the secure computing resource invocation system. For the sake of brevity, they will not be described in detail here.

[0130] A computer device according to embodiments of the present disclosure includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0131] The processor may be a central processing unit (CPU) or other form of processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the computer device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the computer device to perform all or part of the steps of the computing resource secure invocation methods described in the foregoing embodiments of this disclosure.

[0132] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0133] like Figure 8 This is a schematic diagram of a computer device provided for an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the computer device in the embodiments of the present disclosure. Figure 8 The computer device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0134] like Figure 8 As shown, a computer device may include a processor (such as a central processing unit, graphics processing unit, etc.), which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) or programs loaded from storage devices into random access memory (RAM). The RAM also stores various programs and data required for the operation of the computer device. The processor, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0135] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow the computer device to communicate wirelessly or wiredly with other devices (such as edge computing devices) to exchange data. Although Figure 8 A computer apparatus with various devices is shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or included alternatively.

[0136] 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, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processor, all or part of the steps of the secure invocation method for computing resources according to embodiments of this disclosure are performed.

[0137] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0138] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When the non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the secure invocation methods for computing resources described in the foregoing embodiments of the present disclosure are performed.

[0139] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0140] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0141] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0142] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0143] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0144] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0145] Various changes, substitutions, and modifications can be made to the technology described herein without departing from the teachings defined by the appended claims. Furthermore, the scope of the claims of this disclosure is not limited to the specific aspects of the processes, machines, manufactures, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufactures, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, the appended claims include such processes, machines, manufactures, events, means, methods, or actions within their scope.

[0146] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0147] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A method for securely utilizing computing resources, characterized in that, include: Obtain the actual call information of the computing resource nodes, and generate virtual call information of the computing resource nodes based on the actual call information; Receive computing power request from user terminal, authenticate the computing power request, and determine the target computing power resource node requested by user; If authentication is successful, the actual call information of the target computing power resource node will be sent to the user terminal so that the user terminal can call the target computing power resource node. If authentication fails, the virtual call information of the target computing power resource node will be sent to the user terminal. The step of sending the virtual call information of the target computing power resource node to the user terminal includes: The risk level of the computing power request is determined by authenticating the computing power request. Determine whether the risk level exceeds a preset level threshold; If the limit is exceeded, check whether the target computing resource node is configured with a honeypot proxy module; If a honeypot proxy module is configured, the computing power call request will be forcibly redirected to the honeypot proxy module; If the honeypot proxy module is not configured, then configure the honeypot proxy module for the target computing power resource node. After the configuration is complete, forcibly redirect the computing power call request to the honeypot proxy module. The honeypot proxy module sends virtual call information for the target computing resource node to the user terminal step by step based on the risk level. Based on the sent virtual call information, the user terminal is lured and captured; The honeypot proxy module, based on the risk level, progressively sends virtual invocation information of the target computing resource node to the user terminal, including: Based on the risk level of the computing power call request, the honeypot proxy module determines the target trapping topology from a preset set of trapping topology maps; The honeypot proxy module sends virtual call information of the target computing resource nodes to the user terminal step by step according to the target trapping topology map; The trapping topology set includes trapping topologies of different risk levels. Each node in the trapping topology represents a virtual call information sending prompt. The directed edges between nodes indicate the sending order of the virtual call information, and the attributes of the directed edges include the triggering conditions for sending the next virtual call information.

2. The method for securely requisitioning computing resources according to claim 1, characterized in that, The actual access information includes the actual access path of the computing resource nodes; Virtual access information includes the virtual access path of the computing resource node; Analyze the naming rules of the actual access path, and determine the generation rules of the virtual access path based on the naming rules; Based on the generation rules, an initial virtual access path is generated; Triggering conditions for acquiring computing power resource nodes; When the computing resource node meets the triggering conditions, the virtual access path is updated based on the generation rules.

3. The method for securely requisitioning computing resources according to claim 2, characterized in that, When the computing resource node meets the triggering condition, updating the virtual access path based on the generation rule includes: Obtain the monitoring duration and access frequency of computing resource nodes; When the monitoring duration reaches the update cycle, or when the monitoring duration does not reach the update cycle but the access frequency reaches the preset access frequency threshold, the virtual access path is updated based on the generation rule.

4. The method for securely requisitioning computing resources according to claim 2, characterized in that, Also includes: Receive SSH requests from the office area access terminal and identify the SSH requests; If the identification is successful, the office area access terminal is allowed to access general resources; If identification fails, access to general resources will not be permitted for the office area access terminal.

5. The method for securely requisitioning computing resources according to claim 1, characterized in that, Sending the virtual call information of the target computing power resource node to the user terminal also includes: When the risk level does not exceed the level threshold, detect whether the target computing power resource node is configured with a honeypot proxy module; If a honeypot proxy module is configured, the honeypot proxy module will send virtual call information of the target computing power resource node to the user terminal step by step based on the risk level. Based on the sent virtual call information, the user terminal is lured and captured; If no honeypot proxy module is configured, the virtual call information of the target computing power resource node will be sent to the user terminal.

6. The method for securely invoking computing resources according to claim 5, characterized in that, Also includes: The system's computing resources are divided into multiple regions, and the attack level of each region is assessed at different time periods; Assess the importance level of computing resource nodes in each region; Based on the attack level of each region and the importance level of the computing resource nodes in the region, risky computing resource nodes are identified from the computing resource nodes in all regions. Configure a honeypot agent module for each risky computing resource node.

7. A computer device, characterized in that, The computer device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, which, when executed by the at least one processor, enables the at least one processor to perform the secure invocation method for computing resources as described in any one of claims 1-6.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to execute the secure access method for computing resources as described in any one of claims 1-6.

9. A computer program product comprising computer instructions, characterized in that, When executed by a processor, the computer instructions implement the steps of the secure invocation method for computing resources as described in any one of claims 1-6.

Images