A data center security management method and system

Abstract

A data center security management method and system, in the process of executing a target script, judging whether there is a dangerous instruction in the target script; when there is, obtaining the safe execution time window of the device required to execute the target script for the dangerous instruction, judging whether the current time is in the safe execution time window, if so, judging whether the dangerous instruction is contained in the dangerous instruction whitelist of the device, when not contained in the dangerous instruction whitelist, blocking the job submission of the target script, and outputting the first prompt information to remind that there is a dangerous instruction in the target script, when contained in the dangerous instruction whitelist, submitting the target script to the scheduling layer to schedule the target script. Through the dangerous instruction identification, the dangerous instruction of the target script can be automatically identified, the safety and correct operation of the system is ensured. When the instruction script execution occurs a problem, it is automatically judged whether it can be repeatedly executed or manual intervention is required, the execution efficiency and robustness of the job are ensured.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and more specifically to a data center security management method and system. Background Technology

[0002] As the number of data center devices increases and system architecture becomes more complex, the requirements for operation and maintenance security and efficiency are also increasing. Operation and maintenance has gone through stages such as manual operation and maintenance, script-based operation and maintenance, tool-based operation and maintenance, and automated operation and maintenance services.

[0003] Because the promotion of SRE can bring significant improvements in service availability, cost-effectiveness, operational efficiency, and user experience, automation has become one of the main technological development trends in the field of operations and maintenance management.

[0004] The current demand for automation in data center operations primarily stems from service deployment and delivery, system changes, automated alarm handling, system inspection, disaster recovery switching, and data querying. Service deployment and delivery refers to tasks such as standard software installation, configuration modification, and network policy distribution. System changes include modifying host files, backup policies, modifying operating system parameters, system expansion, and port policy distribution. Automated job scheduling requires the following: support for atomic script encapsulation and script management; the automation process involves massive amounts of data commands, some of which may be malicious and could impact the normal operation of the system. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a data center security management method and system to ensure the secure operation of the system.

[0006] To achieve the above objectives, the embodiments of the present invention provide the following technical solutions:

[0007] A data center security management method includes:

[0008] Obtain the target scripts to be executed in the pending job;

[0009] Determine whether there are dangerous instructions in the target script;

[0010] When a dangerous instruction is present, obtain the safe execution time window for the dangerous instruction for the device that needs to execute the target script;

[0011] Determine whether the current time is within the safe execution time window. If so, determine whether the dangerous instruction is included in the device's dangerous instruction whitelist. If it is not included in the dangerous instruction whitelist, block the submission of the target script and output a first prompt message to remind the target script that there is a dangerous instruction. If it is included in the dangerous instruction whitelist, submit the target script to the scheduling layer for scheduling.

[0012] Optionally, the above data center security management method further includes, before obtaining the target script to be executed:

[0013] Retrieve the target scripts that need to be added to the database;

[0014] Determine whether there are dangerous instructions in the target script;

[0015] When a dangerous command is contained, a first warning message is displayed to the user.

[0016] When the user outputs the first command, a second prompt message is output to prompt the user to re-edit the target script, and the second prompt message contains the identified dangerous command;

[0017] When the user outputs a second command, the target script is stored in the MySQL database.

[0018] Optionally, in the above data center security management method, determining whether there are dangerous instructions in the target script includes:

[0019] Obtain aliases for all instructions in the target script;

[0020] The presence of dangerous instructions in the target script is determined based on whether the alias is an alias for a dangerous instruction.

[0021] Optionally, the above data center security management method further includes the following when a dangerous instruction exists:

[0022] Obtain the danger level of the danger command;

[0023] The first warning message includes at least the level of danger.

[0024] Optionally, after obtaining the target script to be executed, the above data center security management method further includes:

[0025] Determine whether the target script is currently in an editing state; if so, terminate the process. Optionally, in the above data center security management method, scheduling the target script includes:

[0026] The target script is scheduled using a distributed scheduling method.

[0027] Optionally, in the above data center security management method, after scheduling the target script, the method further includes:

[0028] Obtain the execution result of the target script;

[0029] Based on the execution result, determine whether the target script was successfully executed;

[0030] If execution fails, determine whether the target script is a script that can be rolled back and executed repeatedly. If it is, roll back and execute the target script repeatedly. If it is not, generate and output a prompt message to the user asking whether they need to roll back and execute the target script repeatedly.

[0031] Optionally, in the above data center security management method, determining whether the target script is a script that is allowed to be rolled back and executed repeatedly includes:

[0032] The instructions in the target script are searched and identified. If there are instructions that cannot be executed repeatedly, then the target script is a script that cannot be rolled back and executed repeatedly.

[0033] If there are no instructions that cannot be executed repeatedly, determine whether the target script will call other scripts;

[0034] If other scripts need to be called, the instructions in those other scripts are searched and identified. If the other scripts contain instructions that cannot be executed repeatedly, then the target script is a script that cannot be rolled back and executed repeatedly; if the other scripts do not contain instructions that cannot be executed repeatedly, then the target script is a script that can be rolled back and executed repeatedly.

[0035] A data center security management system, comprising:

[0036] The module includes a resource management module, a script management module, a job scheduling management module, and a job execution module.

[0037] The resource management module is used to manage data resources;

[0038] The script management module is used to implement any of the above-described data center security management methods;

[0039] The job scheduling management module is used to schedule and manage the jobs to be executed;

[0040] The job execution module is used to execute scheduled jobs.

[0041] Optionally, the data center security management system is integrated into a visual operation platform.

[0042] Based on the above technical solution, the solution provided in this embodiment of the invention determines whether dangerous instructions exist in the target script during execution. When dangerous instructions exist, a safe execution time window for the dangerous instructions is obtained. It is determined whether the current time falls within the safe execution time window. If so, it is determined whether the dangerous instructions are included in the device's dangerous instructions whitelist. If not included in the whitelist, the submission of the target script is blocked, and a first prompt message is output to remind the user that dangerous instructions exist in the target script. If included in the whitelist, the target script is submitted to the scheduling layer for scheduling. Through dangerous instructions identification, dangerous instructions in the target script can be automatically identified, ensuring the safe and correct operation of the system. Attached Figure Description

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

[0044] Figure 1 and Figure 2 This is a flowchart illustrating the script creation process in the data center security management method disclosed in this application.

[0045] Figure 3 and Figure 4 This is a flowchart illustrating the script execution process in the data center security management method disclosed in this application.

[0046] Figure 5 This is a schematic diagram of the detection process during the execution of the target script disclosed in the embodiments of this application;

[0047] Figure 6 This is a schematic diagram of the data center security management system disclosed in the embodiments of this application. Detailed Implementation

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

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

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

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

[0052] The technical solution disclosed in this application mainly comprises three parts in the automated operation and maintenance system's job scheduling: script management, job scheduling management, and job execution. Script management manages the content and version of the execution scripts. It can identify and mark dangerous instructions in the scripts, and also supports automatic identification of whether a script can be executed repeatedly: when a script is uploaded, the instructions involved are identified; if modified instructions are found, the script is automatically determined to be unretrievable, requiring final confirmation from the user. Job scheduling allocates jobs to execution machines. During job scheduling, it automatically identifies safe execution windows based on dangerous instructions contained in the script, the execution machine, and related services. Job execution modules will refuse to execute jobs outside the safe execution window. Job execution management executes jobs and controls the safe execution window for dangerous instructions and automatic retries, supporting high-concurrency script execution.

[0053] Regarding script management:

[0054] The data center security management method disclosed in this application mainly includes script management: script creation, script version management, script review, identification and blocking of dangerous script instructions, and determination of whether a script can be retried. Among these, newly created scripts must be reviewed and granted execution permissions before execution, and detection of dangerous script instructions is performed during both script creation and script execution.

[0055] In this solution, script management begins with script creation; see [link to relevant documentation]. Figure 1 and Figure 2 The process may include:

[0056] Step S101: Obtain the target script;

[0057] The scripts used in this step are scripts that the user created, edited, and uploaded.

[0058] Step S102: Determine whether the target script contains dangerous instructions.

[0059] To determine whether a target script contains dangerous instructions, one can first obtain the aliases of all instructions in the target script. Then, based on whether the aliases belong to dangerous instructions, it can be determined whether the target script contains dangerous instructions. Specifically, this process involves the Master obtaining the alias settings of all instructions in the target script using the `cat.bashrc` command, then querying all dangerous instructions entered in MySQL, and checking whether the instructions in the target script are included among the dangerous instructions.

[0060] In this solution, system administrators can add, modify, and delete dangerous commands on the dangerous command management page, add specified dangerous commands to device whitelists, or configure dangerous command whitelists for devices, and adjust the level and status of dangerous commands as needed. Dangerous commands are divided into five levels: 1, 2, 3, 4, and 5. The higher the level, the greater the harm to the system. Administrators can also specify whether a command can be executed repeatedly.

[0061] Step S103: When a dangerous instruction is included, output the first prompt message to the user.

[0062] If the target script contains dangerous instructions, the system using this method prompts the user to confirm by outputting a first prompt message, and prompts the user to view the dangerous instructions and re-edit them. If the user refuses to add the target script to the database, step S104 is executed. If the user confirms that the target script is added to the database, step S105 is executed.

[0063] Of course, when the dangerous instructions are not included, the storage operation of the target script can be performed directly. The storage operation refers to storing the target script and its script name, version number, script language, script status, upload time and other related information in the MySQL database, and storing the target script file in the SVN database.

[0064] Step S104: When the user outputs the first instruction (reject the database instruction), a second prompt message is output to prompt the user to re-edit the target script, and the second prompt message contains the identified dangerous instruction.

[0065] Step S105: When the user outputs the second instruction (confirm entry instruction), the target script is stored in the MySQL database.

[0066] Once the script is created, it can be executed. See [link / reference]. Figure 3 and Figure 4 The process may include:

[0067] Step S201: Obtain the target script to be executed in the job to be executed.

[0068] In this step, the user selects the target script and the device (IT device) to execute the target script, and submits the job to be executed. The target script and the corresponding device can be determined from the job to be executed.

[0069] Step S202: Determine whether there are dangerous instructions in the target script.

[0070] Step S203: When a dangerous instruction exists, obtain the safe execution time window for the dangerous instruction for the device that needs to execute the target script;

[0071] The safe execution time window refers to the time window during which the device executing the target script can safely execute the dangerous instruction. This safe execution time window can be adaptively calculated based on the operating indicators of each device.

[0072] Step S204: Determine whether the current time is within the safe execution time window. If so, determine whether the dangerous instruction is included in the device's dangerous instruction whitelist. If not, directly block the submission of the target script and prompt the user to re-edit the script.

[0073] The whitelist refers to the list of dangerous instructions that the device can execute.

[0074] Step S205: When the target script is not included in the dangerous instruction whitelist, block the job submission of the target script and output the first prompt message to remind the target script that there are dangerous instructions.

[0075] If a device is not included in the dangerous instruction whitelist, it indicates that the device corresponding to this operation cannot execute the target script.

[0076] Step S206: When the target script is included in the dangerous instruction whitelist, send an MQ message to submit the target script to the scheduling layer for scheduling.

[0077] During the execution of steps S202-206 above, the script is checked for approval, execution permissions, execution within a safe time window, and dangerous instructions. Once all checks are passed, a Kafka message is sent to the executor to submit the target script to the scheduling layer for scheduling. When scheduling the execution of the target script, the corresponding target script can be downloaded from the SVN database from the MQ message. Then, the file distribution function is used to distribute the target script file to the corresponding devices in this job. Finally, the target script is executed in batches on each device.

[0078] In this step, if the current time is within the safe execution time window and the dangerous instruction is in the dangerous instruction whitelist, it indicates that this operation can be executed.

[0079] When submitting the target script to the scheduling layer, the target script and execution request need to be sent to the message queue. If it involves controlling devices to execute the target script, the system using this method will split the execution request into multiple execution requests (i.e., multiple sub-request information) according to device granularity. Each execution request includes the number and information of the corresponding devices. The executor listens to the split sub-request messages and controls the executor program to schedule the jobs to be executed. According to the settings and scheduling algorithm, a Master can be selected for job scheduling and execution. When the user selects to execute the target script on multiple devices simultaneously, multiple execution requests will be involved in the distribution and execution of the target script. The system using this method needs to ensure that all requests are executed, and the final execution results can be summarized after execution.

[0080] When using the Master for job scheduling and execution, after the process on the Master receives the device and target script for this job, it can choose to send the target script to the corresponding device and start the script to obtain its execution status, or execute the script on the Master to obtain its execution status, depending on the target script's status and the management protocol. Once the execution status of the target script is obtained, it determines whether the job execution was successful. If it failed, it determines whether the target script can be rolled back and executed repeatedly. If so, it rolls back and executes the target script again, generating a rollback / failure history. If rollback is possible, it stores the execution history and rolls back the target script. Simultaneously, it summarizes the execution results of all devices corresponding to the target script in this job, generating execution results and logs.

[0081] The process of determining whether the target script can be rolled back for repeated execution can be as follows: Query the MySQL database and check the `idempotent` field of the target script. If the field is false, it means the target script cannot be executed repeatedly; if the `idempotent` field is true, it means the target script can be rolled back for execution.

[0082] In the technical solution disclosed in this embodiment, when the device performs adaptive calculation based on operating indicators to obtain the safe execution time window, the safety window of each script and each device can be identified first based on multiple factors such as target script level, business access indicators, device performance curve, and dangerous instruction level. The intersection of the two is recorded as the safe execution time window.

[0083] For example, services on a server can be divided into two categories. One category is triggered by service requests, and the service access volume can reflect the busyness of this type of service. Once a dangerous instruction is identified, the corresponding safety window can be determined based on the busyness of the service corresponding to the dangerous instruction. The other category is background processing jobs, and the busyness of these jobs can be reflected by the server's CPU utilization and memory utilization. The corresponding safety window of the device can be calculated based on the CPU utilization and memory utilization.

[0084] Specifically: Based on the business metrics data from the past year, the daily average value ū and variance σ are calculated by statistically analyzing business access volume every minute. The average value is then calculated at half-hour intervals to obtain the time period where the half-hour average value is less than ū - 3σ, thus forming the first time set. This first time set is the safety window for the target script. Similarly, based on the device's CPU and memory usage data from the past year, the daily average value ū and variance σ are calculated by statistically analyzing CPU and memory usage every minute. The average value is then calculated at half-hour intervals to obtain the time period where the half-hour average value is less than ū - 3σ, thus forming the second time set. This second set is the device's safety window.

[0085] The intersection of the first and second time sets constitutes the safe execution time window for dangerous instructions. If the intersection of the first and second time sets is empty, the CPU utilization and memory utilization data are adjusted to <ū-2σ, and the second time set is recalculated.

[0086] In the embodiments disclosed in this example, considering that some script instructions in the target script may not be allowed to be rolled back, the process for determining whether the target script is allowed to be rolled back includes: searching and identifying the instructions in the target script; if there are instructions that cannot be executed repeatedly, then the target script is marked as not being able to be executed automatically. If the target script calls other scripts in the script library, it is also necessary to determine whether the called script can be executed repeatedly; if the called script cannot be executed automatically, then the target script needs to be marked as not being able to be executed automatically.

[0087] In this scheme, the target script can be scheduled using a distributed scheduling method. During distributed scheduling, job scheduling execution supports horizontal scaling. The executor retrieves information such as the devices and target scripts involved in the current job from the message queue and distributes them to different Masters according to the scheduling allocation algorithm. When there are many job tasks, executors can be automatically added. During the scheduling process, the executor listens for Kafka messages and executes sub-request jobs (i.e., the multiple execution requests obtained from the split mentioned above). If an executor remains busy for 5 minutes or other set time intervals, a new executor is automatically added. If all executors have an idle time interval greater than 60% for 5 minutes or other set time intervals, one executor is automatically removed. However, it is important to note that the total number of executors should be maintained at ≥2. After receiving a Kafka message, the executor dynamically selects the Master to execute the target script, starts the target script, and obtains the return result according to the configured dynamic scheduling algorithm. The dynamic scheduling algorithm can be a round-robin scheduling algorithm, a weighted round-robin algorithm, a minimum LoadFactor (machineNumber / capacity) scheduling algorithm, or a Master IP address hash scheduling algorithm.

[0088] (1) Round-robin scheduling algorithm: This algorithm schedules equipment jobs to different Masters in a sequential and cyclical manner. The biggest feature of this algorithm is its simplicity. The round-robin algorithm assumes that all Masters have the same ability to process requests, and the executor will distribute all requests equally to each Master server.

[0089] (2) The weighted round-robin algorithm is mainly an optimization and supplement to the round-robin algorithm. The executor obtains real-time information of all Masters, gets the CPU consumption of the Masters, and adds a weight to each Master based on the CPU idle status. If the weight value of Master A is 1 and the weight value of Master B is 2, then the executor will schedule twice as many requests to Master B as to Master A. The Master server with the higher weight value can handle more jobs.

[0090] (3) Minimum LoadFactor (machineNumber / capacity) scheduling algorithm, where capacity is pre-set according to the Master configuration, and machineNumber represents the managed machines. New job assignments are distributed to the Master server with the lowest current LoadFactor. Minimum LoadFactor scheduling is a dynamic scheduling algorithm that estimates the server's status based on the number of managed devices. The Executor needs to query the number of managed devices on each Master server; when a server manages a device, its machineNumber is incremented by 1.

[0091] (4) Master IP address hash scheduling algorithm: First, the corresponding Master is found from the statically allocated hash table based on the Master IP address as the hash key. If the status of the Master server is available and the LoadFactor is not overloaded, the device job is sent to the Master; otherwise, it is returned for rescheduling.

[0092] In this embodiment, see Figure 5 After obtaining the target script (parent job) to be executed on the required n devices, multi-device concurrent security control can also be performed. Specifically: after obtaining the target script to be executed on the required n devices, n MQ messages are sent, and the n execution requests (sub-jobs) obtained from the previous split are executed. The parent request ID and LOCK:TASK+taskId are used as the lockKey to spin and acquire the lock. The spin attempts to lock each sub-job. If the lock is successfully acquired, the parent job status is updated. If an exception is thrown or the lock times out, the lock is released. It is determined whether the executed sub-job is the last sub-job. If so, the job execution is completed and the parent job status is updated. If it is not the last sub-job, the next unexecuted sub-job among the n sub-jobs is executed again.

[0093] To further ensure data security, this solution can also employ cross-network segment security mechanisms to manage data in the data center, for example:

[0094] Using a secure channel: Communication between Salt Master and Minion is conducted using the SSH encryption protocol to protect the security of the communication.

[0095] Configure firewall rules: Configure firewall rules on network devices to restrict access to the communication port between Salt Master and Minion to only specific IP addresses or IP ranges, in order to prevent unauthorized access.

[0096] Use authentication and authorization mechanisms: Configure authentication and authorization mechanisms in SaltStack, using Salt SSH key authentication to ensure that only authenticated and authorized users can perform file distribution operations.

[0097] Use encrypted file transfer: In SaltStack, configuration files are transferred using encryption to ensure that the files are not tampered with or stolen during the transfer process.

[0098] Monitoring and logging: Set up monitoring and logging mechanisms to detect and record abnormal behavior in real time, and to audit and track file distribution operations in order to promptly discover and respond to security incidents.

[0099] Although the operations are described in a specific order, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order. In certain environments, multitasking and parallel processing may be advantageous.

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

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

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

[0103] For the methods described above, see [link to relevant documentation]. Figure 6 This application also discloses a data center security management system, including:

[0104] Resource management module 10, script management module 20, job scheduling management module 30, and job execution module 40;

[0105] The resource management module is used to manage data resources;

[0106] The script management module is used to implement any of the above-described data center security management methods;

[0107] The job scheduling management module is used to schedule and manage the jobs to be executed;

[0108] The job execution module is used to execute scheduled jobs.

[0109] In addition, the data center security management system also has some basic functional modules, for example, it may also include:

[0110] SVN service module: Used to store script files and manage script history versions.

[0111] Minio service module: It is used as a media server to implement file storage middleware, and distributes files from the minio storage to the device.

[0112] ES service module: Used to store job execution history.

[0113] Redis service module: Used to implement distributed locks to ensure the final state of job execution.

[0114] MySQL database: Used to store platform configuration data, basic script information, and user information.

[0115] Master controller: Used to control remote devices and perform various operation and maintenance tasks.

[0116] Executor service module: Used to listen to automated job MQ, dynamically schedule the interaction between the Master and the controlled device, and execute the job logic layer.

[0117] Kafka service module: As a communication bridge between the visualization platform and the Executor, the platform is responsible for sending operation and maintenance jobs (MQ) to the Executor consumers.

[0118] Web UI module: An automated operation and maintenance visualization platform for the creation and management of automated jobs.

[0119] The units described in the embodiments of this disclosure can be implemented in software or in hardware. The name of a unit does not necessarily limit the unit itself; for example, the first acquisition unit can also be described as "a unit that acquires at least two Internet Protocol addresses".

[0120] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0121] 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 communication device 609, or installed from storage device 606, or installed from ROM 602. When the computer program is executed by processing device 601, it performs the functions defined in the methods of embodiments of this disclosure.

[0122] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0123] While several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments.

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

Claims

1. A data center security management method, characterized in that, include: Obtain the target scripts to be executed in the pending job; Determine whether there are dangerous instructions in the target script; When a dangerous instruction exists, the safe execution time window for the dangerous instruction is obtained for the device that needs to execute the target script. The safe execution time window refers to the time window during which the device that executes the target script can safely execute the dangerous instruction. The safe execution time window is determined based on the intersection of a first time set and a second time set. The first time set is the safe window for the target script determined based on business access volume, and the second time set is the safe window for the device determined based on the device's CPU utilization and memory utilization. Determine whether the current time is within the safe execution time window. If so, determine whether the dangerous instruction is included in the device's dangerous instruction whitelist. If it is not included in the dangerous instruction whitelist, block the submission of the target script and output a first prompt message to remind the target script that there is a dangerous instruction. If it is included in the dangerous instruction whitelist, submit the target script to the scheduling layer for scheduling.

2. The data center security management method according to claim 1, characterized in that, Before obtaining the target script to be executed, the following is also included: Retrieve the target scripts that need to be added to the database; Determine whether there are dangerous instructions in the target script; When a dangerous command is contained, a first warning message is displayed to the user. When the user outputs the first command, a second prompt message is output to prompt the user to re-edit the target script, and the second prompt message contains the identified dangerous command; When the user outputs a second command, the target script is stored in the MySQL database.

3. The data center security management method according to any one of claims 1-2, characterized in that, Determining whether the target script contains dangerous instructions includes: Obtain aliases for all instructions in the target script; The presence of dangerous instructions in the target script is determined based on whether the alias is an alias for a dangerous instruction.

4. The data center security management method according to claim 1, characterized in that, When dangerous instructions are present, this also includes: Obtain the danger level of the danger command; The first warning message includes at least the level of danger.

5. The data center security management method according to claim 1, characterized in that, After obtaining the target script to be executed, the following is also included: Determine if the target script is currently in edit mode; if so, end the process.

6. The data center security management method according to claim 1, characterized in that, Scheduling the target script includes: The target script is scheduled using a distributed scheduling method.

7. The data center security management method according to claim 1, characterized in that, After scheduling the target script, the process also includes: Obtain the execution result of the target script; Based on the execution result, determine whether the target script was successfully executed; If execution fails, determine whether the target script is a script that can be rolled back and executed repeatedly. If it is, roll back and execute the target script repeatedly. If it is not, generate and output a prompt message to the user asking whether they need to roll back and execute the target script repeatedly.

8. The data center security management method according to claim 7, characterized in that, Determining whether the target script is a script that is allowed to be rolled back and executed repeatedly includes: The instructions in the target script are searched and identified. If there are instructions that cannot be executed repeatedly, then the target script is a script that cannot be rolled back and executed repeatedly. If there are no instructions that cannot be executed repeatedly, determine whether the target script will call other scripts; If other scripts need to be called, the instructions in those other scripts are searched and identified. If the other scripts contain instructions that cannot be executed repeatedly, then the target script is a script that cannot be rolled back and executed repeatedly; if the other scripts do not contain instructions that cannot be executed repeatedly, then the target script is a script that can be rolled back and executed repeatedly.

9. A data center security management system, characterized in that, include: The module includes a resource management module, a script management module, a job scheduling management module, and a job execution module. The resource management module is used to manage data resources; The script management module is used to implement the data center security management method according to any one of claims 1-8 of this application; The job scheduling management module is used to schedule and manage the jobs to be executed; The job execution module is used to execute scheduled jobs.

10. The data center security management system according to claim 9, characterized in that, The data center security management system is integrated into the visual operation platform.

Images