Bastion host operation instruction border crossing behavior identification and control method

Abstract

The invention provides a bastion host operation instruction border crossing behavior identification and control method, which comprises the following steps of: extracting an input value of a current operation instruction and a security boundary value preset by a system through a bastion host operation log, and synchronously acquiring a CPU occupancy rate, a memory usage amount and a running task number of a target host; analyzing the incidence relation among the CPU occupancy rate, the memory usage amount and the number of running tasks according to the host resource state data and the task load data, and identifying whether the host is in a light-load running state or a heavy-load running state currently to obtain a host load level; and according to the operation instruction input value, the security boundary value and the host load level, calculating the deviation degree of the operation instruction input value and the security boundary by adopting a dynamic risk quantification algorithm, and adjusting a risk weight coefficient in combination with the host load level to obtain a boundary crossing risk level.

Description

Technical Field

[0001] This invention relates to the field of information technology, and in particular to a method for identifying and controlling the boundary-crossing behavior of bastion host operation commands. Background Technology

[0002] As a core device for operation and maintenance security management, the bastion host plays a crucial role in identifying and controlling out-of-bounds operations, directly impacting the stable operation and security protection capabilities of critical information systems. Failure to detect or handle out-of-bounds operations in a timely manner can lead to system resource exhaustion, service interruption, or even the expansion of security vulnerabilities. Existing methods primarily determine risk levels based on a fixed difference between the operation input value and a preset benchmark value; the larger the difference, the higher the alarm level and the more likely immediate blocking will occur. This approach is prone to judgment bias when host load conditions vary, as the actual impact of the same difference on the system differs significantly under different operating environments, yet it is treated uniformly, resulting in a lack of specificity in alarm and blocking strategies. The core technical challenge lies in the direct influence of the target host's real-time resource load status on the correlation between numerical deviation and risk level determination. When the host is running under low load, CPU utilization and memory usage are low, the number of running tasks is small, and there is ample available processing power; in this case, a large input value difference often does not cause substantial harm. Conversely, under high load, even a small difference can rapidly exacerbate resource strain. This change in resource capacity makes it difficult to accurately reflect the true risk simply by relying on deviation, and fixed thresholds cannot adapt to dynamic environments, thus creating irreconcilable contradictions in risk assessment. For example, maintenance personnel need to upload large files to the server in batches for data updates. If the server's current load is low, the upload operation may cause the file size to far exceed the daily baseline, but the remaining resources can handle it, which is a normal operational requirement. If a high-priority alarm is triggered and blocked in real time based on a large deviation, necessary operations will be interrupted, affecting maintenance efficiency. Therefore, how to incorporate the real-time load level of the target host into the deviation calculation and dynamically adjust the alarm level classification threshold and blocking response strategy becomes a key issue in accurately identifying true out-of-bounds behavior and reducing false alarms. Summary of the Invention

[0003] This invention provides a method for identifying and controlling out-of-bounds behavior of bastion host operation commands, including: Extract the input values ​​of the current job command and the system's preset security boundary values ​​from the bastion host operation log, and simultaneously collect the CPU utilization, memory usage, and number of running tasks of the target host; The correlation between host resource status and task load is analyzed based on the CPU utilization, memory usage, and number of running tasks to identify the current host load status and obtain the host load level. Based on the input value of the current work instruction, the safety boundary value, and the host load level, the deviation between the input value of the current work instruction and the safety boundary is calculated, and the risk weight coefficient is adjusted in conjunction with the host load level to obtain the boundary risk level. Based on the out-of-bounds risk level and the host load level, extract the baseline alarm threshold and load adjustment coefficient, adjust the baseline alarm threshold, and compare the out-of-bounds risk level with the adjusted alarm trigger threshold to obtain the alarm level. Based on the alarm level and the host load level, identify the remaining processing capacity of the host from the CPU utilization rate and generate a security response command. Based on the security response command and the delayed execution time window, a blocking operation is issued to the target host or a monitoring process is started. The delay duration is extracted from the delayed execution time window, and a secondary status detection is triggered after the duration is reached. The operation execution status and historical decision records are recorded.

[0004] Preferably, the step of extracting the input value of the current job instruction and the system-preset security boundary value from the bastion host operation log, and simultaneously collecting the CPU utilization, memory usage, and number of running tasks of the target host, includes: The operation records are read from the bastion host log file, the timestamp, user ID and command string are parsed, and the file size, concurrent connection count and query record count in the command parameters are extracted. The file size threshold, concurrent connection threshold and query record threshold corresponding to the command string are obtained from the security configuration file to obtain the job input dataset. By connecting to the target host via the SSH protocol, the CPU utilization, memory usage, and number of running tasks of the target host are collected to obtain host resource status data.

[0005] Preferably, the step of analyzing the correlation between host resource status and task load based on the CPU utilization, memory usage, and number of running tasks to identify the current host load status and obtain the host load level includes: Collect time-series data on host CPU utilization, memory usage, and number of running tasks, and calculate average resource consumption and task resource density metrics. A two-dimensional scatter plot is constructed based on the average resource consumption of the task and the resource density index of the task. The K-means clustering algorithm is used to cluster the scatter points into multiple classes, and the center point of each class is calculated. By comparing the Euclidean distance between the current resource status point and the center point of the category, it is determined whether the host is currently in a light-load, heavy-load, or medium-load operating state, and the corresponding load level is assigned to obtain the host load level.

[0006] Preferably, the step of calculating the deviation between the job instruction input value and the safety boundary based on the job instruction input value, the safety boundary value, and the host load level, and adjusting the risk weight coefficient in conjunction with the host load level to obtain the boundary crossing risk level, includes: Calculate the difference between the input value of the current work instruction and the safety boundary value, and calculate the percentage of the difference to the safety boundary value as the basic deviation. Based on the host load level, query the load weight mapping table to determine the weight factor, and multiply the base deviation by the weight factor to obtain the weighted deviation value. A risk assessment matrix is ​​constructed based on the weighted deviation values. Historical execution records of each operation type in different deviation ranges are extracted from the bastion host log database. The ratio of the number of system anomalies to the total number of operations is calculated and used to fill the risk assessment matrix. The initial risk probability value corresponding to the current job instruction is found by using the risk assessment matrix. The initial risk probability value is adjusted according to the host CPU remaining rate and memory remaining amount. A non-linear mapping function is used to transform it into a risk scoring range to determine the risk score. The risk level of going out of bounds is determined by the risk score and associated with the work instruction identifier.

[0007] Preferably, the method further includes obtaining the command type and operation permission level of the job instruction from the bastion host log, extracting the allowed permission range and resource access restrictions of the command type of the job instruction from the security boundary, analyzing the degree to which operation permissions exceed the allowed range and the range of resource access exceeding the restrictions, determining the risk weight adjustment direction by combining host CPU utilization and memory usage, and identifying the threat level of the job instruction, including: Parse the job instruction string from the bastion host log, extract the command header identifier to determine the command type, read the role identifier of the executing user to obtain the operation permission level, query the standard permission level and accessible resource list corresponding to the command type from the security configuration library, calculate the difference between the actual operation permission level and the standard permission level to obtain the permission overreach value; Extract the target file path, database table name, and network target address actually accessed from the job instruction parameters, compare them item by item with the list of accessible resources, count the number of resource items not in the list, calculate the ratio of the number of resource items not in the list to the total number of resources actually accessed, and obtain the resource breakthrough rate. The initial risk product is obtained by multiplying the resource breach rate by the privilege overreach value. A high load weight coefficient or a low load weight coefficient is determined based on the current host CPU utilization and memory usage. The initial risk product is then adjusted to obtain the load adjustment risk value. The threat level of the work instruction is determined by querying the threat level mapping table based on the load adjustment risk value.

[0008] Preferably, the step of extracting a baseline alarm threshold and a load adjustment coefficient based on the boundary violation risk level and the host load level, adjusting the baseline alarm threshold, and comparing the boundary violation risk level with the adjusted alarm trigger threshold to obtain the alarm level includes: The corresponding initial threshold is obtained by querying the benchmark alarm threshold table based on the boundary risk level; The load adjustment coefficient table is queried according to the host load level to determine the upward or downward adjustment coefficient. The initial threshold is multiplied by the corresponding coefficient to obtain the dynamic alarm threshold. The risk level of exceeding the boundary is converted into a numerical value, the numerical value is compared with the dynamic alarm threshold, the difference is calculated, and the alarm intensity value is obtained. The alarm level is determined by querying the alarm level mapping table based on the alarm intensity value.

[0009] Preferably, the step of identifying the remaining processing capacity of the host from the CPU utilization rate based on the alarm level and the host load level, and generating a security response command, includes: A response decision table is constructed based on the alarm level and the host load level, and the remaining processing capacity is calculated from the current CPU utilization to determine the resource status identifier; The response judgment is made based on the resource status identifier, the alarm level, and the host load level to determine the response command type; Based on the response instruction type, query the instruction generation rule table, set the corresponding parameters, and combine them to obtain the security response instruction.

[0010] Preferably, the method further includes obtaining the instruction type from the security response instruction, identifying the task queue saturation level from the number of running tasks, adjusting the execution of the blocking instruction according to the task queue saturation level, and obtaining the final execution instruction, including: Extract the instruction type identifier and execution parameters from the security response instruction, obtain the number of currently running tasks, calculate the task queue saturation level, and determine the queue status identifier; Based on the queue status identifier and the instruction type identifier, an execution adjustment judgment is made to determine whether to add a delayed execution flag and a delay duration value; The final execution instructions are constructed based on the adjusted execution control parameters.

[0011] Preferably, the step of issuing a blocking operation or starting a monitoring process to the target host according to the security response command and the delayed execution time window, extracting the delay duration from the delayed execution time window and triggering a secondary status detection after the duration is reached, and recording the operation execution status and historical decision records includes: The execution method is determined based on the type identifier and time window field of the security response instruction, and an operation command is sent to the target host or a timer is set. When the timer is triggered or executed immediately, a blocking signal or a command to start the monitoring process is sent through the remote interface, and the execution confirmation information returned by the target host is received. Based on the execution confirmation information, determine whether to initiate secondary detection. After the delay period ends, collect the target host status again, compare the status differences, and record the instruction type, execution timestamp, target host identifier, execution result, and status change value into the historical record database to obtain the operation execution status and historical decision records.

[0012] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects: This invention discloses a method for identifying and controlling out-of-bounds behavior of bastion host operation commands. It extracts the current operation command input value from the bastion host and its deviation from the system's preset security boundary. Simultaneously, it collects the target host's CPU utilization, memory usage, and number of running tasks. By comprehensively analyzing the correlation between the host's load level and the risk of command out-of-bounds behavior, it dynamically adjusts the risk weight and adaptively adjusts the alarm trigger threshold according to the load. Finally, it generates a security response command that precisely matches the host's current actual processing capacity and task queue saturation state, including immediate blocking, delayed blocking, or downgraded monitoring. A secondary status verification and execution result recording are performed after a delay window. This invention effectively solves the problems of false positives and false negatives coexisting, and improper blocking timing leading to business interruption or security failure in traditional static threshold strategies under host resource fluctuation scenarios. It significantly improves the accuracy of protection and business continuity assurance of high-risk operations in complex load environments. Attached Figure Description

[0013] Figure 1 This is a flowchart of a method for identifying and controlling out-of-bounds behavior of bastion host operation commands according to the present invention.

[0014] Figure 2 This is a schematic diagram of a method for identifying and controlling out-of-bounds behavior of bastion host operation commands according to the present invention.

[0015] Figure 3 This is another schematic diagram of a method for identifying and controlling out-of-bounds behavior of bastion host operation commands according to the present invention. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0017] like Figures 1-3 This embodiment of a method for identifying and controlling boundary-crossing behavior of bastion host operation commands may specifically include: S101. Extract the input values ​​of the current job command and the system's preset security boundary values ​​from the bastion host operation log, and synchronously collect the CPU utilization, memory usage, and number of running tasks of the target host.

[0018] Operation records are read from the bastion host log file. The timestamps, user identifiers, and command strings in the logs are parsed, and the file size, concurrent connections, and query record count are extracted from the command parameters. The file size threshold, concurrent connection threshold, and query record threshold corresponding to the command string are obtained from the security configuration file to obtain the job input dataset. The target host is connected via SSH. If the CPU usage percentage in the job input dataset exceeds a preset load threshold, the difference between each value in the job input dataset and the corresponding threshold is multiplied by a load adjustment factor to obtain host load correlation data.

[0019] In one implementation, the bastion host log file stores each operation record in JSON format, including a timestamp field to record the operation timestamp, a user_id field to identify the operation user, and a command field to store the complete command string. After the parser reads the log file, it uses regular expressions to extract key parameters from the command field, such as the file size parameter of the scp command, the number of concurrent connections of the ssh command, and the number of query records of the mysql command.

[0020] Specifically, the security configuration file predefines the security boundaries for various commands. Different command types correspond to different threshold parameters, such as a file transfer command corresponding to a file size threshold, a remote connection command corresponding to a concurrent connection threshold, and a database query command corresponding to a query record count threshold. The system matches the corresponding threshold configuration item based on the command type field of the command string.

[0021] It should be noted that the load adjustment coefficient is determined based on the ratio between the host's current resource usage and the preset load threshold. When the CPU utilization percentage exceeds the preset load threshold, the system calculates the excess ratio r = (ct) / t, where c is the current CPU utilization percentage and t is the preset load threshold. Then, the coefficient = 1 + r is applied, multiplying the difference between each value in the job input dataset and the corresponding threshold by this coefficient. This dynamically amplifies the difference, allowing for a more rigorous evaluation of deviations under high load conditions.

[0022] For example, when an operations and maintenance personnel performs a file transfer operation and the file size exceeds a threshold, if the host CPU utilization rate exceeds a preset load threshold, the excess difference will be multiplied by a load adjustment coefficient for dynamic amplification, so that the deviation behavior under high load conditions is more strictly evaluated.

[0023] S102. Analyze the correlation between CPU utilization, memory usage and the number of running tasks based on host resource status data and task load data, identify whether the host is currently in a light-load or heavy-load running state, and obtain the host load level.

[0024] Time-series data on host CPU utilization, memory usage, and the number of running tasks are collected. The ratio of resource utilization to the number of tasks at each time point is calculated as the average resource consumption per task. The memory usage per task is obtained by dividing the memory usage by the number of running tasks. The difference between the single-task memory usage and a preset memory baseline is divided by the baseline value to obtain the task resource density index. A two-dimensional scatter plot is constructed based on the task resource density index and the average resource consumption per task. The horizontal axis represents the average resource consumption per task, and the vertical axis represents the task resource density index. Each scatter point represents the resource status at a sampling time. The K-means clustering algorithm is used to cluster the scatter points into three categories. The mean of the average resource consumption per task and the mean of the task resource density index at the center of each category are calculated to determine the resource usage cluster center. By comparing the Euclidean distance between the current resource status point and the resource usage cluster center, if the average resource consumption of the task in the cluster center with the smallest distance exceeds the preset heavy load threshold and the task resource density index exceeds the preset heavy load threshold, it is determined to be a heavy load operation state and assigned a load level of three. If the average resource consumption of the task is lower than the preset light load threshold and the task resource density index is lower than the preset light load threshold, it is determined to be a light load operation state and assigned a load level of one. The others are determined to be medium load operation states and assigned a load level of two, thus obtaining the host load level.

[0025] In one implementation, the bastion host system collects resource status data of the target host every 5 seconds, forming a continuous time-series data stream. The task resource density index reflects the intensity of a single task's occupation of system resources, and is obtained by normalizing the deviation between the actual occupation value and the baseline value.

[0026] Specifically, the calculation of average resource consumption per task needs to consider the instantaneous fluctuations in CPU utilization. Within a 10-minute sliding time window, the system collects the CPU utilization percentage every second, accumulating 600 sampling points. After removing the highest and lowest 5% outliers, the arithmetic mean of the remaining 540 sampling points is calculated. Simultaneously, the average number of processes counted by the `ps` command within this time window is obtained; dividing the two yields the CPU consumption per unit task. For memory usage, the number of bytes of memory used is obtained using the `free` command, divided by the number of currently running tasks to obtain the memory usage per task. If the memory usage per task is 50MB, and the preset memory baseline is 30MB, then the task resource density index is calculated as (AB) / B, where A is the memory usage per task and B is the preset memory baseline, with a calculated value of 0.67. This index, used as the vertical axis of a scatter plot, together with the average resource consumption per task, constitutes a two-dimensional feature space.

[0027] It should be noted that in the process of constructing the two-dimensional scatter plot, each scatter point represents a snapshot of system resources at a certain moment. The horizontal axis is the average resource consumption of the task, which represents the CPU consumption rate of a unit task. The vertical axis is the task resource density index, which represents the relative deviation of the memory usage value of a single task from the baseline value.

[0028] In one possible implementation, the K-means clustering algorithm involves: randomly selecting three initial cluster centers, corresponding to typical resource usage patterns under light, medium, and heavy loads, respectively. For each data point in the scatter plot, the distance to the three cluster centers is calculated, and the point is assigned to the nearest cluster. After assigning all points, the average CPU utilization and average memory usage of all points within each cluster are recalculated as the new cluster center coordinates. This iterative process is repeated until the change in the cluster center position is less than a preset convergence threshold of 0.01 or the number of iterations reaches 100. The three final cluster centers represent the typical resource usage characteristics of the system under different load levels.

[0029] Preferably, the Euclidean distance is calculated using standardized values ​​to avoid the influence of different units. For the current resource state point P(x,y), where x is CPU utilization and y is memory usage, the Euclidean distance to the cluster center C(a,b) is calculated as follows: .

[0030] For example, the preset overload threshold and light load threshold are set according to the business scenario. The overload threshold is usually set in the range of 70%-80% CPU utilization and 75%-85% memory usage, while the light load threshold is usually set in the range of 20%-30% CPU utilization and 25%-35% memory usage. When a system resource status point is closest to the overload cluster center at a certain moment, and the CPU utilization of that cluster center is 82% and the memory usage is 85% of the total memory, both exceeding the corresponding overload threshold, the system determines that it is currently in a overload running state.

[0031] Understandably, identifying load levels through dynamic clustering methods is more adaptable to changes in system resource usage patterns than using fixed thresholds, thus enabling more accurate assessment of the host's operating status.

[0032] S103. Based on the work instruction input value, safety boundary value, and host load level, a dynamic risk quantification algorithm is used to calculate the degree of deviation between the work instruction input value and the safety boundary. The risk weight coefficient is then adjusted in conjunction with the host load level to obtain the out-of-bounds risk level.

[0033] The difference between the job instruction input value and the safety boundary value is obtained. The percentage of the difference to the safety boundary value is calculated as the basic deviation. A preset load weight mapping table is consulted based on the host load level. If the load level is Level 1, the weight factor is a preset light load weight value; if the load level is Level 2, the weight factor is a preset medium load weight value; and if the load level is Level 3, the weight factor is a preset heavy load weight value. The basic deviation is multiplied by the weight factor to obtain the weighted deviation value. A risk assessment matrix is ​​constructed based on the weighted deviation value. The matrix rows represent operation type categories, and the matrix columns represent deviation value intervals. Historical execution records of each operation type in different deviation intervals are extracted from the bastion host log database. The ratio of the number of system anomalies to the total number of operations is calculated as the risk probability. The risk probability is filled into the corresponding positions in the matrix to obtain the risk probability matrix. The initial risk probability value corresponding to the current job instruction is found through the risk probability matrix. The current CPU remaining rate and memory remaining amount of the host are obtained. If the CPU remaining rate or memory remaining amount is lower than a preset resource safety threshold, the initial risk probability value is multiplied by a preset resource stress adjustment coefficient to obtain an adjusted risk probability value. A non-linear mapping function is used to convert the adjusted risk probability value to a preset risk score range to determine the risk score. Based on the risk score, an out-of-bounds risk level is determined. If the risk score exceeds a preset high-risk threshold, it is determined to be a high-risk level; if the risk score is within a preset medium-risk threshold range, it is determined to be a medium-risk level; and if the risk score is lower than a preset low-risk threshold, it is determined to be a low-risk level. The out-of-bounds risk level is associated with the job instruction identifier and stored to obtain the out-of-bounds risk level.

[0034] In one implementation, the basic deviation is calculated using the relative deviation method, which eliminates dimensional differences between different instruction types by standardizing the absolute deviation value. The difference between the work instruction input value and the safety boundary value reflects the degree of operational deviation; dividing this difference by the safety boundary value yields the dimensionless percentage deviation.

[0035] Specifically, the load weight mapping table is constructed based on statistical analysis of a large amount of historical operational data. The system collected records of out-of-bounds operations under different load levels over the past six months, analyzing the actual impact of the same deviation at each load level. Preset weight values ​​are set according to system load levels. Under light load conditions, the weight values ​​are set relatively low, indicating a higher tolerance for deviations when system resources are abundant; under medium load conditions, the weight values ​​remain at a baseline level; and under heavy load conditions, the weight values ​​are set relatively high, reflecting strict control requirements. The weight factor is positively correlated with the host load level; the higher the load, the larger the weight factor, and the same deviation will be amplified in evaluation.

[0036] It should be noted that the risk assessment matrix uses a two-dimensional table structure to store historical risk statistics, providing data support for subsequent risk probability queries. The matrix's row dimensions are categorized according to operation type, including four main categories: file transfer, database query, system configuration, and process management, with each category further subdivided into 10 subtypes.

[0037] In one possible implementation, the risk probability value stored in each cell of the matrix is ​​obtained through historical data statistics. The system extracts operation records from the bastion host log database for the past three months, totaling approximately 500,000 records, and filters out approximately 20,000 records that caused system anomalies. For each combination of operation type and deviation range, the proportion of anomaly occurrences to the total number of operations in that combination is calculated.

[0038] For example, if a file transfer operation is performed 1000 times in the severely deviated range, and 80 of these operations result in insufficient disk space or transfer timeouts, then the risk probability value for that cell is 0.08. Through this statistical method based on actual operational data, the constructed risk probability matrix can accurately reflect the actual risk level of different operations under different degrees of deviation.

[0039] Preferably, the dynamic adjustment mechanism for the initial risk probability value takes into account the impact of the host's real-time resource status on the risk. The CPU remaining rate is obtained by subtracting the current CPU utilization rate from 100%, and the remaining memory is obtained by subtracting the used memory from the total system memory.

[0040] For example, the preset resource security threshold is set according to the host configuration, including two dimensions: CPU remaining rate and memory remaining amount. When any resource falls below the security threshold, the system determines that it is in a resource stress state. The preset resource stress adjustment coefficient is set according to the level of resource stress, with a larger adjustment coefficient for higher stress levels.

[0041] In one embodiment, the risk score is mapped using a logarithmic transformation method, mapping the adjusted risk probability value P to a score range of 0-100. The mapping function is: Risk S = -50 × log10(1-P), where log10 represents the logarithm to base 10. When the risk probability P approaches 1, the risk score S approaches 100. This logarithmic mapping method provides higher resolution for low-risk areas, which is beneficial for refined management.

[0042] Specifically, the risk level classification adopts a three-tier system. A high-risk threshold of 70 points is preset, indicating that the operation is highly likely to cause system anomalies; a medium-risk threshold range of 40-70 points indicates that the operation carries some risk but is controllable; and a low-risk threshold below 40 points indicates that the operation carries relatively low risk. Each risk level corresponds to a different response strategy: high-risk levels trigger real-time alarms and may block operations; medium-risk levels record audit logs and implement rate-limited execution; and low-risk levels only record and monitor.

[0043] Understandably, by dynamically adjusting risk weights in conjunction with host load status, contextualized assessment of out-of-bounds behavior is achieved. Compared to fixed threshold judgment, this approach more accurately identifies real security threats and reduces false alarms under low load and false negatives under high load.

[0044] Obtain the command type and operation permission level of the job instruction from the bastion host log, extract the allowed permission range and resource access restrictions of the command from the security boundary, analyze the extent to which the operation permission exceeds the allowed range, assess the extent to which resource access exceeds the restrictions, determine the direction of risk weight adjustment by combining host CPU utilization and memory usage, and identify the threat level of the job instruction.

[0045] Parse the job command string from the bastion host logs, extract the command header identifier to determine the command type, read the role identifier of the executing user to obtain the operation permission level, query the standard permission level and accessible resource list corresponding to the command type from the security configuration database, subtract the standard permission level value from the actual operation permission level value, if the difference is greater than zero, it is recorded as an unauthorized access value, otherwise it is recorded as zero, thus obtaining the unauthorized access value. Construct a resource access detection table based on the unauthorized access value and the accessible resource list, extract the actual accessed target file path, database table name, and network target address from the job command parameters, compare each item with the accessible resource list, count the number of resource items not in the list as the breach count, calculate the ratio of the breach count to the total number of actually accessed resources, thus obtaining the resource breach rate. The initial risk product is obtained by multiplying the resource breach rate by the privilege overreach value. The current host CPU utilization and memory usage are then obtained. If the CPU utilization exceeds a preset high load threshold or the memory usage exceeds a preset high load threshold, the initial risk product is multiplied by a preset high load weighting coefficient. If both resources are below a preset low load threshold, the initial risk product is multiplied by a preset low load weighting coefficient to obtain the load adjustment risk value. Based on the load adjustment risk value, a preset threat level mapping table is queried. If the risk value falls within a preset severe threat range, the threat level is assigned a severe level; if it falls within a preset alert threat range, the threat level is assigned an alert level; and if it falls within a preset warning threat range, the threat level is assigned a warning level, thus obtaining the job instruction threat level.

[0046] In one implementation, the bastion host log records each job command in a structured format. Command header identifiers are extracted using regular expression matching, such as "sudo" for privileged commands, "ssh" for remote connection commands, and "scp" for file transfer commands. Each command type has a predefined standard permission level value in the system.

[0047] Specifically, the numerical representation of permission levels adopts a hierarchical assignment method. The system divides permissions into four levels from low to high: ordinary user, operator, administrator, and super administrator, assigned values ​​of 1, 2, 3, and 4 respectively. The role identifier of the executing user is read from the LDAP directory service or local user configuration file, and each user account is associated with a unique role identifier code. The security configuration library uses XML format to store the permission configuration for each command type, including three core fields: command name, standard permission level, and list of accessible resources. The calculation of the privilege violation value is implemented through simple arithmetic operations. When the actual operation permission level is 3 and the standard permission level is 2, the privilege violation value is 1, indicating a violation of one level. If the actual permission level is less than or equal to the standard permission level, the privilege violation value is recorded as 0, indicating that no privilege violation has occurred.

[0048] It should be noted that the construction process of the resource access detection table involves multi-dimensional resource comparison. The list of accessible resources adopts a whitelist mechanism, explicitly listing the allowed file paths, database tables, and network addresses.

[0049] In one possible implementation, the resource access detection process involves three dimensions of detection. At the file system level, the complete path of the target file, such as " / etc / passwd" or " / var / log / messages", is extracted from the job instruction parameters using a path resolver and matched against path prefixes in the whitelist. At the database level, table names in SQL statements are parsed, such as extracting the "users" table name from "SELECT * FROM users", and checking if it's in the list of allowed tables. At the network level, the target IP address or domain name, such as "192.168.1.100" or "server.example.com", is extracted and verified to be within the allowed network range. For each access request, the system checks and records each resource item not in the whitelist. The resource breach rate is calculated by dividing the number of unauthorized resources by the total number of accessed resources. For example, if 10 resources are accessed, and 3 of them are not in the whitelist, the breach rate is 30%. This multi-dimensional detection mechanism can comprehensively evaluate the resource access behavior of job instructions.

[0050] Preferably, the initial risk product is calculated using a multiplicative model, which multiplies the resource breach rate by the privilege overreach value.

[0051] For example, if the resource breach rate is 0.3 and the privilege overreach value is 2, then the initial risk product is 0.6.

[0052] For example, the load adjustment mechanism dynamically adjusts the risk assessment results based on the real-time resource status of the host. Preset high load thresholds include CPU utilization of 70% and memory usage of 75% of total memory, while preset low load thresholds include CPU utilization of 30% and memory usage of 40% of total memory. The preset high load weight coefficient ranges from 1.5 to 2.0, indicating that the risk assessment is amplified when resources are scarce; the preset low load weight coefficient ranges from 0.5 to 0.8, indicating that the risk assessment is appropriately reduced when resources are abundant. When CPU utilization reaches 80% or memory usage reaches 85%, the system determines it to be in a high load state and multiplies the initial risk product by the high load weight coefficient of 1.8. This dynamic adjustment mechanism makes the risk assessment more closely reflect the actual operating environment.

[0053] In one embodiment, the threat level mapping table defines different threat levels using a range-based approach. A preset critical threat range is defined as a risk value greater than 0.7, with corresponding system responses including immediate blocking, sending real-time alerts, and recording detailed audit logs. A preset alert threat range is defined as a risk value between 0.3 and 0.7, triggering delayed execution, rate limiting, and enhanced monitoring. A preset warning threat range is defined as a risk value less than 0.3, recording only operation logs for post-event auditing. Furthermore, the threat level mapping table supports dynamic configuration, allowing operations administrators to adjust the thresholds for each range based on business characteristics.

[0054] For example, for core database servers, the lower limit of the severe threat range can be adjusted to 0.5 to improve the security protection level; for test environment servers, the lower limit of the severe threat range can be adjusted to 0.9 to reduce false alarm interference.

[0055] Understandably, by combining privilege escalation detection, resource breach rate calculation, and dynamic load adjustment, a multi-dimensional threat level identification is achieved, which more accurately assesses the actual risk level of work instructions compared to a single-dimensional judgment.

[0056] S104. Based on the boundary risk level and host load level, extract the baseline alarm threshold and load adjustment coefficient. When the host load level is light, increase the alarm trigger threshold; when the host load level is heavy, decrease the alarm trigger threshold. Compare the boundary risk level with the adjusted alarm trigger threshold to obtain the alarm level.

[0057] The system queries a preset baseline alarm threshold table based on the risk level of the out-of-bounds event to obtain the initial threshold for the corresponding risk level. It then queries a load adjustment coefficient table based on the host load level; if the load level is light, an upward adjustment coefficient is obtained; if the load level is heavy, a downward adjustment coefficient is obtained. The initial threshold is multiplied by the corresponding adjustment coefficient to obtain the dynamic alarm threshold. The out-of-bounds risk level is converted into a numerical representation: high risk level corresponds to value 3, medium risk level to value 2, and low risk level to value 1. The risk level value is compared with the dynamic alarm threshold; if the risk level value is greater than the dynamic alarm threshold, an alarm is triggered. The difference between the risk level value and the dynamic alarm threshold is calculated to obtain the alarm intensity value. The alarm intensity value is then queried from an alarm level mapping table. If the alarm intensity value is greater than a preset high intensity threshold, it is assigned an emergency alarm level; if the alarm intensity value is in a preset medium intensity range, it is assigned a normal alarm level; and if the alarm intensity value is less than a preset low intensity threshold, it is assigned a warning alarm level, thus obtaining the alarm level.

[0058] In one implementation, the baseline alarm threshold table adopts a hierarchical design, setting different initial thresholds for three risk levels: high, medium, and low. The higher the risk level, the higher the corresponding initial threshold. These thresholds are determined based on statistical analysis of historical alarm data.

[0059] Specifically, the load adjustment coefficient table is designed to consider the impact of system resource status on alarm sensitivity. Under light load conditions, system resources are abundant and have a high tolerance for abnormal operations; therefore, an upward adjustment coefficient greater than 1 is used to raise the alarm trigger threshold and reduce false alarms. Under heavy load conditions, system resources are scarce, and any abnormality may cause service interruption; therefore, a downward adjustment coefficient less than 1 is used to lower the alarm trigger threshold and improve alarm sensitivity. Under medium load conditions, the coefficient is maintained at 1.0 to maintain the standard alarm level. The dynamic alarm threshold is obtained by multiplying the initial threshold by the adjustment coefficient, realizing the adaptive adjustment of the alarm threshold according to the system load.

[0060] It should be noted that the conversion from risk level to numerical value adopts a linear mapping method to ensure that there are clear numerical differences between different levels, which facilitates subsequent quantitative comparison.

[0061] In one possible implementation, the alarm intensity value reflects the degree to which the actual risk exceeds the threshold. When the risk level is 3 and the dynamic alarm threshold is 2.0, the alarm intensity value is 3 - 2.0 = 1.0. This difference directly reflects the severity of the breach; the larger the difference, the higher the risk and the more urgent the response.

[0062] Preferably, the alarm level mapping table divides alarm intensity values ​​into three ranges. A high-intensity threshold of 1.5 is preset. When the alarm intensity value exceeds 1.5, an emergency alarm is triggered, the system immediately sends an SMS and email notification to the administrator, and displays a red warning on the monitoring screen. A medium-intensity range of 0.5 to 1.5 is preset, triggering a normal alarm, logging the alarm, and displaying a yellow warning on the monitoring interface. A low-intensity threshold of 0.5 is preset; alarm intensity values ​​below 0.5 are considered a warning alarm and are only logged.

[0063] For example, a database query operation is determined to be of medium risk level, with a value of 2. The current host is in a heavily loaded state. The initial threshold of 1.8 is multiplied by the adjustment factor of 0.7 to obtain a dynamic alarm threshold of 1.26. The risk level value of 2 is greater than the threshold of 1.26, triggering an alarm. The alarm intensity value is 0.74, which falls in the medium intensity range, and is finally determined to be a normal alarm level.

[0064] Understandably, by dynamically adjusting alarm thresholds and implementing a tiered alarm mechanism, the alarm strategy is linked to the system load status, ensuring security protection under high load while avoiding excessive alarms under low load.

[0065] S105. Based on the alarm level and host load level, identify the remaining processing capacity of the host from the CPU utilization rate. When the alarm level is high priority and the host load level is heavy load, generate an immediate blocking command. When the alarm level is high priority and the host load level is light load, generate a degradation monitoring command. When the alarm level is low priority, generate a continuous monitoring command and obtain a security response command.

[0066] A response decision table is constructed based on the alarm level and host load level. Remaining processing capacity is calculated from the current CPU utilization rate by subtracting the current CPU utilization rate from the preset total CPU processing capacity. If the remaining processing capacity is lower than a preset resource pressure threshold, it is marked as resource-constrained; otherwise, it is marked as resource-sufficient, resulting in a resource status identifier. The resource status identifier is combined with the alarm level and host load level for response judgment. If the alarm level is high priority, the host load level is heavy, and the resource status identifier is resource-constrained, an immediate blocking type is selected. If the alarm level is high priority and the host load level is light, a degraded monitoring type is selected. If the alarm level is low priority, a continuous monitoring type is selected, determining the response command type. A preset command generation rule table is queried based on the response command type. If it is an immediate blocking type, the target process identifier and termination timestamp are set; if it is a degraded monitoring type, the monitoring frequency reduction parameter and resource limit value are set; if it is a continuous monitoring type, the log recording level and sampling interval are set. The command type identifier is combined with the corresponding parameters to obtain the security response command.

[0067] In one implementation, the response decision table adopts a three-dimensional mapping structure, combining alarm level, host load level, and resource status, and pre-defining the response strategy corresponding to each combination. The preset total CPU processing capacity is obtained through benchmark testing during system initialization, with the number of instructions processed per second as the metric.

[0068] Specifically, the calculation of remaining processing capacity needs to consider the multi-core characteristics of the CPU and the task scheduling mechanism. The system obtains the usage time of each CPU core by reading the / proc / stat file and calculates the average utilization rate of all cores as the current CPU utilization rate P (in percentage form). The total CPU processing capacity C is dynamically calculated using the formula C=N×F, where N is the number of cores and F is the performance benchmark value per core (instructions per second). The remaining processing capacity R_capacity=C×(1-P), with the same unit as C. The remaining processing capacity ratio R_ratio=R_capacity / C=(1-P), with the preset resource stress threshold set at R_ratio<0.2, meaning that when the remaining processing capacity ratio is below 20%, it is marked as a resource-constrained state. This quantification method ensures consistency of measurement, allowing for uniform evaluation of hosts with different configurations.

[0069] It should be noted that the response judgment uses a decision tree structure to implement multi-condition combination judgments. The first layer judges whether the alarm level is high priority, the second layer judges the host load level, and the third layer judges the resource status identifier. The output of each judgment node points to a specific response instruction type, avoiding complex nested condition judgments.

[0070] In one possible implementation, the instruction generation rule table stores parameter templates for each response type. For immediate blocking, parameters include the target process's PID, the network connection's socket descriptor, and the timestamp for blocking execution. The system terminates the process using the `kill` command or blocks the network connection using iptables rules. For monitoring operations, the system starts a background monitoring process using the `nohup` command, setting a data collection frequency of 10 times per second. Continuous monitoring maintains the normal monitoring frequency, only increasing the detail of log entries.

[0071] Preferably, the security response instruction is encapsulated in JSON format, including a type field to identify the instruction type, a parameter field to store specific parameters, a timestamp field to record the generation time, a priority field to indicate the execution priority, a delay flag field to control delayed execution, and a window field to define the execution time window.

[0072] For example, a database query operation triggers a high-priority alarm. The current host load level is heavy, and the CPU has only 15 processing units remaining, which is below the resource stress threshold. The system determines that the resource is constrained. According to the decision rules, the immediate blocking type is selected, the target process PID is set to 12345, the termination timestamp is the current time plus 100 milliseconds, and it is encapsulated into a security response command and executed immediately.

[0073] Understandably, by combining multi-dimensional judgments of alarm level, load status, and resource availability, fine-grained control of response strategies is achieved, ensuring rapid blocking in high-risk situations while avoiding over-response when resources are plentiful.

[0074] The instruction type is obtained from the security response instruction, the saturation level of the task queue is identified from the number of running tasks, and the execution of the blocking instruction is confirmed when the saturation level of the task queue exceeds the threshold. When the saturation level of the task queue does not exceed the threshold, the blocking instruction is converted into a delayed blocking instruction and a delayed execution time window is set to obtain the final execution instruction.

[0075] The system extracts instruction type identifiers and execution parameters from security response instructions, obtains the number of currently running tasks, reads the maximum capacity value of the task queue from the system configuration file, calculates the task queue saturation level by dividing the number of running tasks by the maximum capacity value, and marks the queue as congested if the saturation level exceeds a preset threshold; otherwise, it is marked as idle, thus obtaining the queue status identifier. Execution adjustment is determined based on the queue status identifier and instruction type identifier. If the instruction type identifier is a blocking type and the queue status identifier is idle, the instruction parameters remain unchanged and execution proceeds immediately. If the instruction type identifier is a blocking type and the queue status identifier is congested, a delayed execution flag and a preset delay duration value are added to the instruction parameters. Other instruction types retain their original parameters, thus determining the execution control parameters. The final execution instruction is constructed using these execution control parameters. If a delayed execution flag exists, the preset delay duration value is extracted, and the delayed execution time point is calculated. This execution time point is written into the instruction time window field. The instruction type identifier, execution parameters, and time window field are encapsulated into a complete instruction structure to obtain the final execution instruction.

[0076] In one implementation, the maximum capacity of the task queue is automatically set during system initialization based on hardware configuration, taking into account factors such as the number of CPU cores, memory size, I / O throughput, and context switching overhead. The system employs a weighted calculation method, with the capacity value Q determined by the formula Q = w1 × N + w2 × M + w3 × I - w4 × C, where N is the number of CPU cores, M is the memory size (GB), I is the I / O throughput (MB / s), C is the context switching overhead coefficient, and w1 to w4 are the corresponding weight coefficients. The weight coefficients are preset according to the system type; w1 is larger for compute-intensive systems, and w3 is larger for I / O-intensive systems. The system configuration file stores these parameters in XML format, facilitating adjustments by operations and maintenance personnel based on actual load conditions.

[0077] Specifically, calculating task queue saturation requires considering both the actual execution and waiting states of tasks. The system obtains the number of currently running tasks through the process manager, including tasks in execution and those in the waiting queue. The saturation calculation formula is the total number of current tasks divided by the maximum capacity value, then multiplied by 100%. A preset threshold is set based on system load characteristics, typically between 70% and 80%. When the saturation exceeds the threshold, it indicates a high system load, and additional blocking operations may exacerbate system congestion; below the threshold, the system has sufficient processing capacity to delay non-urgent blocking operations, giving administrators time to assess and intervene.

[0078] It should be noted that the adjustment judgment adopts a hierarchical decision-making mechanism, and different types of instructions have different processing strategies.

[0079] In one possible implementation, for blocking type commands, the system adopts differentiated processing based on the queue status. When the queue is congested, blocking is executed immediately to prevent the risk from spreading; when the queue is idle, a delayed execution flag is added, with a preset delay duration between 5 and 30 seconds, the specific value being dynamically adjusted based on historical execution results. For monitoring and alarm type commands, the original parameters remain unchanged regardless of the queue status to ensure the real-time nature of monitoring and alarms.

[0080] Preferably, the final execution instructions are encapsulated in a structured format, including a `type` field indicating the instruction type, a `params` field storing execution parameters, a `delay_flag` field indicating whether there is a delay, and a `window` field recording the execution time window. The time window uses a Unix timestamp, accurate to the millisecond level, to ensure the accuracy of the execution sequence.

[0081] For example, if a file deletion operation is determined to be blocked, and the current number of running tasks is 50, the maximum capacity is 100, and the saturation level is 50%, which is below the 75% threshold, the system determines that the queue is idle. The system adds a delayed execution flag to the execution parameters, sets a delay duration of 10 seconds, calculates the execution time as the current timestamp plus 10,000 milliseconds, and encapsulates this information into the final execution instruction.

[0082] Understandably, by dynamically adjusting the timing of blocking commands, both rapid response under high load and a buffer mechanism are provided when the system is idle, reducing the impact of erroneous operations.

[0083] S106. Based on the final execution instruction and the delayed execution time window, issue a blocking operation or start a monitoring process to the target host, extract the delay duration from the delayed execution time window, trigger a secondary status detection after the duration is reached, and record the operation execution status and historical decision records.

[0084] The execution method is determined based on the type identifier and time window field of the final executed instruction. If the time window field is empty, the operation command is immediately sent to the target host. If the time window field includes a delay duration, a timer is set to wait for triggering. When the timer triggers or execution occurs immediately, a blocking signal or a command to start the monitoring process is sent to the target host via a remote interface. The execution confirmation information returned by the target host is received to obtain the initial execution result. The initial execution result is used to determine whether to initiate secondary detection. If the initial execution result shows that the operation has been executed and there is a delay duration, the CPU utilization and memory usage status of the target host are obtained again after the delay duration ends. The difference between the baseline status saved before the operation execution and the current status is compared. The instruction type, execution timestamp, target host identifier, execution result, and status change value are written to the historical record database to obtain the operation execution status and historical decision record.

[0085] In one implementation, the time window field stores the execution time in Unix timestamp format with millisecond precision. The system determines whether execution needs to be delayed by comparing the current system time with the time window field value.

[0086] Specifically, the remote interface uses the SSH protocol to communicate with the target host. For blocking operations, the system sends a kill command to terminate the specified process; for monitoring operations, the system starts a background monitoring process using the nohup command. The data collection frequency is set according to the monitoring type. Continuous monitoring maintains the standard collection frequency, while degraded monitoring uses a reduced collection frequency.

[0087] It should be noted that the baseline state is automatically saved before the operation is performed, including key indicators such as CPU utilization, memory usage, and the list of running processes. This data is stored in a temporary cache for comparison during secondary testing.

[0088] In one possible implementation, the secondary detection is completed within 30 seconds after the delay period ends. The system re-collects the resource status of the target host, subtracts the current CPU utilization from the baseline value to obtain the change, and determines whether the operation has achieved the expected effect.

[0089] Preferably, the historical record database is stored in a time-series database. Each record contains five fields: timestamp, host IP, instruction type, execution status, and resource change value. It supports fast querying by time range and host identifier, providing data support for operation and maintenance auditing.

[0090] If the technical solution of this application involves the acquisition of personal information, the product using this solution has clearly informed the user of the processing rules and obtained the user's consent before processing. If sensitive personal information is involved, the user's individual consent has been obtained and the "express consent" requirement has been met. For example, a clear sign is placed at the collection device to indicate the collection scope, and the user's voluntary entry is considered as consent; or authorization is obtained through pop-up windows, user uploads, etc. The processing rules include the processor, purpose, method, and type of information.

[0091] Based on the embodiments of the present invention described above, and through the above description, those skilled in the art can make various changes and modifications without departing from the technical concept of the present invention. The technical scope of the present invention is not limited to the contents of the specification, but must be determined according to the scope of the claims.

Claims

1. A method for identifying and controlling boundary-crossing behavior of bastion host operation commands, characterized in that, include: Extract the input values ​​of the current job command and the system's preset security boundary values ​​from the bastion host operation log, and simultaneously collect the CPU utilization, memory usage, and number of running tasks of the target host; The correlation between host resource status and task load is analyzed based on the CPU utilization, memory usage, and number of running tasks to identify the current host load status and obtain the host load level. Based on the input value of the current work instruction, the safety boundary value, and the host load level, the deviation between the input value of the current work instruction and the safety boundary is calculated, and the risk weight coefficient is adjusted in conjunction with the host load level to obtain the boundary risk level. Based on the out-of-bounds risk level and the host load level, extract the baseline alarm threshold and load adjustment coefficient, adjust the baseline alarm threshold, and compare the out-of-bounds risk level with the adjusted alarm trigger threshold to obtain the alarm level. Based on the alarm level and the host load level, identify the remaining processing capacity of the host from the CPU utilization rate and generate a security response command. Based on the security response command and the delayed execution time window, a blocking operation is issued to the target host or a monitoring process is started. The delay duration is extracted from the delayed execution time window, and a secondary status detection is triggered after the duration is reached. The operation execution status and historical decision records are recorded.

2. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The process involves extracting the input values ​​of the current job command from the bastion host operation log and comparing them with the system's preset security boundary values, while simultaneously collecting the target host's CPU utilization, memory usage, and number of running tasks, including: The operation records are read from the bastion host log file, the timestamp, user ID and command string are parsed, and the file size, concurrent connection count and query record count in the command parameters are extracted. The file size threshold, concurrent connection threshold and query record threshold corresponding to the command string are obtained from the security configuration file to obtain the job input dataset. By connecting to the target host via the SSH protocol, the CPU utilization, memory usage, and number of running tasks of the target host are collected to obtain host resource status data.

3. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The step of analyzing the correlation between host resource status and task load based on the CPU utilization, memory usage, and number of running tasks to identify the current host load status and obtain the host load level includes: Collect time-series data on host CPU utilization, memory usage, and number of running tasks, and calculate average resource consumption and task resource density metrics. A two-dimensional scatter plot is constructed based on the average resource consumption of the task and the resource density index of the task. The K-means clustering algorithm is used to cluster the scatter points into multiple classes, and the center point of each class is calculated. By comparing the Euclidean distance between the current resource status point and the center point of the category, it is determined whether the host is currently in a light-load, heavy-load, or medium-load operating state, and the corresponding load level is assigned to obtain the host load level.

4. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The step of calculating the deviation between the job instruction input value and the safety boundary based on the job instruction input value, the safety boundary value, and the host load level, and adjusting the risk weight coefficient in conjunction with the host load level to obtain the boundary violation risk level, includes: Calculate the difference between the input value of the current work instruction and the safety boundary value, and calculate the percentage of the difference to the safety boundary value as the basic deviation. Based on the host load level, query the load weight mapping table to determine the weight factor, and multiply the base deviation by the weight factor to obtain the weighted deviation value. A risk assessment matrix is ​​constructed based on the weighted deviation values. Historical execution records of each operation type in different deviation ranges are extracted from the bastion host log database. The ratio of the number of system anomalies to the total number of operations is calculated and used to fill the risk assessment matrix. The initial risk probability value corresponding to the current job instruction is found by using the risk assessment matrix. The initial risk probability value is adjusted according to the host CPU remaining rate and memory remaining amount. A non-linear mapping function is used to transform it into a risk scoring range to determine the risk score. The risk level of going out of bounds is determined by the risk score and associated with the work instruction identifier.

5. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 4, characterized in that, This also includes retrieving command types and operation permission levels from bastion host logs, extracting the allowed permission range and resource access restrictions for command types of job instructions from security boundaries, analyzing the extent to which operation permissions exceed the allowed range and the extent to which resource access exceeds restrictions, determining the direction of risk weight adjustment in conjunction with host CPU utilization and memory usage, and identifying the threat level of job instructions, including: Parse the job instruction string from the bastion host log, extract the command header identifier to determine the command type, read the role identifier of the executing user to obtain the operation permission level, query the standard permission level and accessible resource list corresponding to the command type from the security configuration library, calculate the difference between the actual operation permission level and the standard permission level to obtain the permission overreach value; Extract the target file path, database table name, and network target address actually accessed from the job instruction parameters, compare them item by item with the list of accessible resources, count the number of resource items not in the list, calculate the ratio of the number of resource items not in the list to the total number of resources actually accessed, and obtain the resource breakthrough rate. The initial risk product is obtained by multiplying the resource breach rate by the privilege overreach value. A high load weight coefficient or a low load weight coefficient is determined based on the current host CPU utilization and memory usage. The initial risk product is then adjusted to obtain the load adjustment risk value. The threat level of the work instruction is determined by querying the threat level mapping table based on the load adjustment risk value.

6. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The step involves extracting a baseline alarm threshold and a load adjustment coefficient based on the boundary violation risk level and the host load level, adjusting the baseline alarm threshold, and comparing the boundary violation risk level with the adjusted alarm trigger threshold to obtain the alarm level, including: The corresponding initial threshold is obtained by querying the benchmark alarm threshold table based on the boundary risk level; The load adjustment coefficient table is queried according to the host load level to determine the upward or downward adjustment coefficient. The initial threshold is multiplied by the corresponding coefficient to obtain the dynamic alarm threshold. The risk level of exceeding the boundary is converted into a numerical value, the numerical value is compared with the dynamic alarm threshold, the difference is calculated, and the alarm intensity value is obtained. The alarm level is determined by querying the alarm level mapping table based on the alarm intensity value.

7. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The step of identifying the remaining processing capacity of the host from the CPU utilization rate based on the alarm level and the host load level, and generating a security response command, includes: A response decision table is constructed based on the alarm level and the host load level, and the remaining processing capacity is calculated from the current CPU utilization to determine the resource status identifier; The response judgment is made based on the resource status identifier, the alarm level, and the host load level to determine the response command type; Based on the response instruction type, query the instruction generation rule table, set the corresponding parameters, and combine them to obtain the security response instruction.

8. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 7, characterized in that, This also includes obtaining the instruction type from the security response instruction, identifying the task queue saturation level from the number of running tasks, adjusting the execution of the blocking instruction based on the task queue saturation level, and obtaining the final execution instruction, including: Extract the instruction type identifier and execution parameters from the security response instruction, obtain the number of currently running tasks, calculate the task queue saturation level, and determine the queue status identifier; Based on the queue status identifier and the instruction type identifier, an execution adjustment judgment is made to determine whether to add a delayed execution flag and a delay duration value; The final execution instructions are constructed based on the adjusted execution control parameters.

9. The method for identifying and controlling boundary crossing behavior of bastion host operation commands according to claim 1, characterized in that, The process involves issuing a blocking operation or initiating a monitoring process to the target host based on the security response command and the delayed execution time window. The delay duration is extracted from the delayed execution time window, and a secondary status check is triggered after the duration expires. The operation execution status and historical decision records are recorded, including: The execution method is determined based on the type identifier and time window field of the security response instruction, and an operation command is sent to the target host or a timer is set. When the timer is triggered or executed immediately, a blocking signal or a command to start the monitoring process is sent through the remote interface, and the execution confirmation information returned by the target host is received. Based on the execution confirmation information, determine whether to initiate secondary detection. After the delay period ends, collect the target host status again, compare the status differences, and record the instruction type, execution timestamp, target host identifier, execution result, and status change value into the historical record database to obtain the operation execution status and historical decision records.

Images