An emergency treatment method, device, medium and product for centralized authentication and authorization of equipment

Abstract

The application discloses an emergency processing method and device for centralized authentication and authorization of equipment, a medium and a product, relates to the technical field of electric communication, and comprises the following steps: establishing a heartbeat detection mechanism between a main server and equipment; monitoring the communication state between the main server and the equipment in real time by using the heartbeat detection mechanism; when the communication state between the main server and the equipment is abnormal, starting an emergency mode, and enabling a local authentication and authorization mechanism in the emergency mode until the communication state between the main server and the equipment returns to normal. The heartbeat detection technology and the local emergency authentication mechanism are introduced, so that the problem that the service continuity cannot be ensured when a system is abnormal in the prior art is solved.

Description

Technical Field

[0001] This application relates to the field of telecommunications technology, and in particular to an emergency handling method, device, medium, and product for centralized authentication and authorization of equipment. Background Technology

[0002] Current network device management systems typically employ centralized authentication and authorization mechanisms. When the main server fails, maintenance personnel are unable to log in to manage and maintain the devices. Existing technologies lack effective emergency response mechanisms, failing to guarantee business continuity during system anomalies. Summary of the Invention

[0003] To address the aforementioned problems, this application provides a method, equipment, medium, and product for centralized equipment certification and authorization emergency response.

[0004] To achieve the above objectives, this application provides the following solution:

[0005] Firstly, this application provides an emergency handling method for centralized certification and authorization of equipment, including:

[0006] Establish a heartbeat detection mechanism between the main server and the device;

[0007] The heartbeat detection mechanism described above is used to monitor the communication status between the main server and the device in real time.

[0008] When the communication status between the master server and the device is abnormal, the emergency mode is activated, and the local authentication and authorization mechanism is enabled in the emergency mode until the communication status between the master server and the device returns to normal.

[0009] This includes establishing a heartbeat detection mechanism between the main server and the devices, including:

[0010] The master server sends the public key to the device, and the device verifies the certificate chain and then stores the public key.

[0011] Set the heartbeat interval and heartbeat timeout threshold between the master server and the device, and obtain the maximum or minimum interval allowed by the device hardware;

[0012] An encrypted channel is established based on the secure transport layer protocol, and a device identifier is set. The device is then bound to the main server based on the device identifier.

[0013] The master server adds the device to the heartbeat management list; the parameters of the heartbeat management list include: device unique identifier, heartbeat interval, heartbeat timeout threshold, maximum and minimum allowed interval, timestamp of received response, consecutive failure count and network quality score;

[0014] Read parameters from the heartbeat management list and establish a heartbeat channel based on the parameters;

[0015] The heartbeat intervals in the heartbeat management list are updated in real time based on the network quality score to generate heartbeat packets for the heartbeat detection mechanism.

[0016] Optionally, the heartbeat detection mechanism is used to monitor the communication status between the master server and the device in real time, including:

[0017] The master server periodically broadcasts heartbeat packets to all devices. The devices verify the heartbeat packets and return response packets indicating their device status. The master server listens to the response packets from these devices and obtains the listening response results.

[0018] The communication status between the master server and the device is obtained based on the monitoring response results.

[0019] Optionally, the process of the device verifying the signature of the heartbeat packet includes:

[0020] A hash algorithm is used to decrypt the signature of the heartbeat packet based on the public key to obtain the first hash value;

[0021] The hash algorithm described above is used to perform a hash calculation on the original data in the heartbeat packet to obtain a second hash value;

[0022] Determine whether the first hash value is equal to the second hash value;

[0023] The verification is successful when the first hash value equals the second hash value.

[0024] Verification fails when the first hash value is not equal to the second hash value;

[0025] If verification fails, the heartbeat packet is discarded and a security event is recorded; the security event includes the received heartbeat packet information and the reason for the verification failure.

[0026] When multiple consecutive verification failures occur, the device's security protection mechanism is triggered.

[0027] Optionally, the process by which the master server listens for response packets from the device includes:

[0028] Determine whether a response packet from the device is received within the heartbeat timeout threshold;

[0029] If no response packet is received from the device within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered, and the failure count is incremented.

[0030] Real-time acquisition of device performance metrics and proactive alarms are used to comprehensively assess fault information and update device activity status;

[0031] If a response packet from the device is received within the heartbeat timeout threshold, no action is taken.

[0032] Optionally, the process for determining the abnormal communication status between the master server and the device includes:

[0033] The heartbeat timeout is determined based on the relationship between the failure count and the set value;

[0034] When a heartbeat times out, check if the master server broadcasted the message.

[0035] When the master server broadcasts, it checks the local status of the device and determines whether there are any abnormalities in the local status of the device.

[0036] When the local state of the device is abnormal, the communication state between the master server and the device is abnormal.

[0037] The communication between the master server and the device is normal when the heartbeat does not time out, the local status of the device is normal, or the master server does not broadcast.

[0038] Optionally, the processing steps of the local authentication and authorization mechanism include:

[0039] The authentication service stops triggering the heartbeat detection mechanism and loads local credentials;

[0040] Obtain the credential information entered by the user, and perform local authentication and authorization based on the credential information entered by the user and the local credentials.

[0041] Secondly, this application provides a computer device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the device centralized authentication and authorization emergency handling method provided above.

[0042] Thirdly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the above-described device centralized authentication and authorization emergency handling method.

[0043] Fourthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described device centralized authentication and authorization emergency handling method.

[0044] According to the specific embodiments provided in this application, this application has the following technical effects:

[0045] This application provides a method, device, medium, and product for centralized authentication and authorization emergency handling. By introducing heartbeat detection technology and a local emergency authentication mechanism, it achieves coordinated status control between the master server and the device, solving the problem that traditional centralized authentication systems cannot guarantee business continuity under abnormal circumstances. It automatically switches to emergency mode when a fault is detected, ensuring that maintenance personnel can still manage the device. After the communication between the master server and the device returns to normal, it can smoothly transition back to centralized authentication mode, achieving high availability, security, and data consistency. Attached Figure Description

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

[0047] Figure 1 A flowchart illustrating an emergency handling method for centralized device authentication and authorization, provided as an embodiment of this application;

[0048] Figure 2 The system architecture diagram provided in this application for the centralized certification and authorization emergency response method for implementing equipment;

[0049] Figure 3 A schematic diagram of the system monitoring process provided in one embodiment of this application;

[0050] Figure 4 This is a schematic diagram of an anomaly determination process provided in an embodiment of this application;

[0051] Figure 5 This is a schematic diagram of a heartbeat monitoring process provided in an embodiment of this application;

[0052] Figure 6 This is a schematic diagram of an emergency switching process provided in an embodiment of this application;

[0053] Figure 7 This is a schematic diagram of a system recovery process provided in an embodiment of this application;

[0054] Figure 8 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0055] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0056] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0057] In one exemplary embodiment, as such Figure 2 Taking the system architecture shown as an example, the implementation process of the centralized device authentication and authorization emergency handling method provided in this application will be explained, such as... Figure 1 As shown, the method includes:

[0058] Step 100: Establish a heartbeat detection mechanism between the master server and the device. In practical applications, the heartbeat detection mechanism can adopt a two-way authentication method. The goal of this step is to establish a secure and reliable heartbeat channel between the master server and the device. This is mainly achieved by establishing a secure and reliable heartbeat channel between the master server and the device, thereby establishing a heartbeat mechanism for subsequent real-time monitoring systems. Based on this, the implementation process of step 100 may include:

[0059] Step 100-1, Key Exchange: The master server sends the public key (RSA public key) to the device (KeyExchange::sendPublicKey()), and the device stores the public key after verifying the certificate chain (CertificateVerifier::verify()).

[0060] Step 100-2: Set the heartbeat interval and heartbeat timeout threshold between the master server and the device, and obtain the maximum or minimum interval allowed by the device hardware. In practical applications, this step is completed through parameter negotiation between the master server and the device. Specifically, the master server and the device negotiate the heartbeat interval (e.g., 30 seconds) and the heartbeat timeout threshold (e.g., 90 seconds). The device returns the maximum / minimum interval supported by its hardware capabilities (negotiateConfig()).

[0061] Step 100-3: Establish an encrypted channel based on Transport Layer Security (TLS) and set the device identifier. Bind the device to the master server based on the device identifier to complete two-way authentication. For example, establish an encrypted channel based on TLS 1.3 (TLSSession::create()). This step is mainly for implementing channel encryption.

[0062] Step 100-4: The master server adds the device to the heartbeat management list (HeartbeatManager::registerDevice()). The parameters of the heartbeat management list include: unique device identifier (MAC / IP combination), heartbeat interval (default 30 seconds, dynamically adjustable from 30-60 seconds), heartbeat timeout threshold (default 90 seconds, usually 3 times the heartbeat interval), maximum allowed interval (system preset upper limit, e.g., 60 seconds), minimum allowed interval (system preset lower limit, e.g., 15 seconds), timestamp of received response, consecutive failure count (3 failures trigger an alarm), and network quality score (used to dynamically adjust the heartbeat interval). This step is primarily for registration and startup.

[0063] Step 100-5: Read parameters from the heartbeat management list and establish a heartbeat channel based on the parameters. For example, during the heartbeat channel establishment phase, when a new heartbeat channel is established through HeartbeatInitializer (heartbeat initializer), parameters are read from the heartbeat management list.

[0064] Step 100-6: Update the heartbeat interval in the heartbeat management list in real time based on the network quality score to generate heartbeat packets for the heartbeat detection mechanism.

[0065] Based on the above description, during the anomaly detection phase, timeout detection can be performed by comparing the current time with the time interval of the last heartbeat. The device starts a heartbeat response thread (deviceSideListener()). Based on this, anomaly handling includes: ① If key exchange fails (check the error message: during the connection process, the client will return specific error messages. Common error messages include "key exchange failed" or "No compatible key exchange method found"), trigger a fallback protocol (such as a pre-shared key). ② If channel establishment times out, for example, after 3 retries, mark the device as unreachable.

[0066] Step 101: Employ a heartbeat detection mechanism to monitor the communication status between the main server and the device in real time. With a robust heartbeat mechanism, monitoring can obtain information such as heartbeat timeouts, resource load, and proactive alarms for comprehensive fault assessment. Therefore, the goal of this step is to continuously monitor the system status and maintain the heartbeat mechanism. In practical applications, the implementation of step 101 may include:

[0067] Step 101-1: The master server periodically (every 30 seconds) broadcasts a heartbeat packet (HeartbeatPacket structure) to all devices. Each device verifies the heartbeat packet and returns a response packet indicating its device status. The master server listens for these responses and receives the results. Devices listen for heartbeat requests via a UDP port. Upon receiving a heartbeat request, the device verifies the signature and collects its status (CPU / memory usage, etc.).

[0068] The verification data includes: ① The device decrypts the signature of the heartbeat packet using the master server's public key to obtain the hash value of the signature (denoted as H1). ② The device uses the same hash algorithm (such as SHA-256) to hash the original data in the heartbeat packet (excluding the signature itself) to obtain H2. ③ Compare H1 and H2: If they are the same, the verification passes. Otherwise, the verification fails. Handling of verification failure:

[0069] 1) Discard the heartbeat packet and do not perform any subsequent processing (such as collecting status and returning response).

[0070] 2) Record security events, including received data packet information, reasons for verification failure, etc., for subsequent auditing and analysis.

[0071] 3) Multiple consecutive verification failures may trigger the device's security protection mechanism (such as temporarily blocking the IP address of the main server to prevent possible attacks).

[0072] Based on the above description, the process of the device verifying the signature of the heartbeat packet includes:

[0073] Step (1): Use a hash algorithm to decrypt the signature of the heartbeat packet based on the public key to obtain the first hash value.

[0074] Step (2): Use a hash algorithm to perform a hash calculation on the original data in the heartbeat packet to obtain the second hash value.

[0075] Step (3): Determine whether the first hash value is equal to the second hash value.

[0076] Step (4): Verification passes when the first hash value equals the second hash value. Verification fails when the first hash value does not equal the second hash value.

[0077] When verification fails, the heartbeat packet is discarded and a security event is logged. The security event includes the received heartbeat packet information and the reason for the verification failure. When multiple consecutive verification failures occur, the device's security protection mechanism is triggered.

[0078] Furthermore, the master server listens for device responses: ① Upon receiving a response (i.e., receiving a response packet): it obtains information such as heartbeat timeout (the master server periodically sends probe packets (i.e., heartbeat packets) to the device; if no response is received within a set threshold (e.g., continuous packet loss or ACK timeout), triggering a heartbeat timeout alarm), resource load (real-time collection of device performance indicators such as CPU, memory, and network bandwidth), and proactive alarm comprehensive fault judgment (receiving hardware errors, service crash logs, and heartbeat port anomalies proactively reported by the device), and updates the device's active status (lastSeen field). ② Without receiving a response: it increments the failure count (failureCount++). Based on this, the process of the master server listening for device response packets includes:

[0079] Step (1): Determine whether a response packet from the device has been received within the heartbeat timeout threshold.

[0080] Step (2): When no response packet is received from the device within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered and the failure count is incremented.

[0081] Step (3): Real-time acquisition of device performance indicators and active alarms to comprehensively judge fault information and update device activity status.

[0082] Step (4): When a response packet from the device is received within the heartbeat timeout threshold, no action is taken.

[0083] Step 101-2: Obtain the communication status between the master server and the device based on the monitoring response results. Based on the above description, the process of repeating the above steps after a new interval is as follows: Figure 3 As shown.

[0084] Step 102: When the communication between the master server and the device is abnormal, activate the emergency mode and enable the local authentication and authorization mechanism in emergency mode until the communication between the master server and the device returns to normal, then return to centralized authentication mode. Centralized authentication mode refers to an architecture in a network system where all authentication requests from all devices are uniformly managed and verified by the master server. In practical applications, the switching of emergency mode can adopt a tiered switching strategy. The local authentication and authorization mechanism uses pre-set encrypted credentials.

[0085] In practical applications, after an anomaly is detected during the anomaly detection phase, atomic state switching is performed to avoid intermediate state risks. Specifically, atomic state switching manifests in the following ways: ① Hardware-level atomic operations (atomic state switching refers to completing a system mode change within a single, indivisible operation); ② State switching transactions (acquiring a mutex lock (std::lock_guard), verifying system health (e.g., whether the log cache is full), atomically updating mode flags, releasing resources, and notifying observers); ③ State machine integrity (preventing illegal jumps: preventing direct jumps from CENTRAL to intermediate states such as RECOVERY). Therefore, the purpose of the anomaly detection phase is to comprehensively determine whether emergency conditions have been triggered. These conditions include:

[0086] 1) Heartbeat timeout: No response was received for 3 consecutive times (failureCount>= 3).

[0087] 2) Main server broadcast: Receives emergency command (EmergencyBroadcast::isReceived()) actively issued by the server.

[0088] 3) Local anomalies: ① CPU usage exceeds 95% for 5 minutes. ② Low memory warning (SystemHealthChecker::checkMemory()).

[0089] Based on the above description, such as Figure 4 As shown, the process for determining abnormal communication status between the master server and the device includes:

[0090] Step (1): Determine whether the heartbeat timeout has occurred based on the relationship between the failure count and the set value;

[0091] Step (2): When the heartbeat times out, check if the master server has broadcast;

[0092] Step (3): When the master server broadcasts, check the local status of the device and determine whether there is any abnormality in the local status of the device.

[0093] Step (4): When the local status of the device is abnormal, the communication status between the master server and the device is abnormal.

[0094] Step (5): When the heartbeat does not time out, the local status of the device is normal, or the master server does not broadcast, the communication status between the master server and the device is normal.

[0095] Furthermore, step 102 corresponds to the emergency switchover phase. When an abnormal situation is detected based on the above, the system enters emergency mode to achieve a safe switchover to the local emergency mode. Therefore, the specific switchover process includes:

[0096] Step 1: Stop the centralized service. At this point, close the primary authentication connection (CentralAuthService::shutdown()). The primary server shutdown triggers a heartbeat anomaly detection mechanism: The primary server is typically responsible for managing the core authentication process. When shutdown() is called to forcibly close its connection, the primary server's service will stop responding to heartbeat requests. The heartbeat channel, as an independent link for monitoring the status between nodes, will immediately detect the primary server's unresponsive state and trigger the failover process.

[0097] Step 2: Load local credentials. The emergency account can be decrypted from the TPM (Trusted Platform Module) security chip (LocalAuth::loadCredentials()).

[0098] Step 3: Restrict permissions. When the system restarts, logs are viewed, configuration is backed up / restored, services are controlled, network diagnostics are performed, and system status is viewed, only predefined commands are allowed, such as reboot, log_view, config_backup, service_restart, ping, show_system_status, etc.

[0099] Step 4: Enable log caching. All operations are recorded to an encrypted local log (OperationLogger::startCaching()).

[0100] Step 5: Notify the maintenance end. Send a system status change alert (Notifier::broadcast()).

[0101] As an optional implementation of this application, after entering emergency mode, the following safe maintenance operations are performed. The purpose of the emergency operation phase is to safely perform maintenance operations in emergency mode.

[0102] 1. Certification:

[0103] ① Maintenance personnel enter local credentials (EmergencyOperator::handleLogin()) for authentication.

[0104] ② Verify the password hash (BCrypt::validate()). If authentication is successful, proceed to the next step.

[0105] 2. Command execution:

[0106] ① Check the command whitelist (PermissionManager::isAllowed()). When predefined commands are allowed, the check results are shown in Table 1.

[0107] ② Record commands and results (OperationLogger::logCommand()).

[0108] Table 1 Inspection Results

[0109]

[0110] 3. Audit: Generate security incident reports (SecurityLogger::generateReport()).

[0111] Based on the above description, the processing steps of the local authentication and authorization mechanism include:

[0112] Step 1) The authentication service stops triggering the heartbeat detection mechanism and loads local credentials.

[0113] Step 2) Obtain the credential information entered by the user, and perform local authentication and authorization based on the credential information entered by the user and the local credential.

[0114] As an optional implementation of this application, after the emergency operation, while the security incident report is being generated during the security maintenance operation, a system recovery phase is performed to achieve a smooth recovery to the centralized authentication mode. Based on this, the recovery process for the centralized authentication mode is as follows:

[0115] (1) After receiving the device online notification, the main server verifies the device identity (verifies the device certificate + MAC address binding).

[0116] (2) The master server sends a digitally signed recovery command (RecoveryCommand structure) to the device.

[0117] (3) Verify the recovery command signature on the device side (verifyCommand()).

[0118] (4) Upload cached logs on the device side (resumable interruption + compressed transmission).

[0119] (5) The master server receives and merges the device logs (the conflict detection adopts the timestamp priority strategy).

[0120] (6) Switch back to centralized authentication mode on the device side (AuthModeSwitcher::switchToCentral()).

[0121] (7) Clean up the local emergency status on the equipment side (delete temporary certificates).

[0122] Based on the above description, the centralized authentication and authorization emergency handling method for devices provided in this application continuously executes step 101 to monitor the heartbeat; if any abnormality occurs again, step 102 is executed repeatedly. Among these steps, based on... Figure 2 The system architecture shown in this application, and the emergency response method for centralized device authentication and authorization provided in this application, include a heartbeat monitoring process as follows: Figure 5 As shown, the emergency switchover process is as follows: Figure 6 As shown, the system recovery process is as follows: Figure 7 As shown.

[0123] As an optional implementation of this application, a long-connection scheme is provided, which replaces the heartbeat mechanism with real-time monitoring based on long connections, and the following steps are performed:

[0124] ① Use WebSocket or gRPC long connections instead of UDP heartbeat packets.

[0125] ② Continuous state synchronization is achieved through bidirectional flow.

[0126] The comparison results between the long connection scheme in this embodiment and the method provided in this application are shown in Table 2.

[0127] Table 2 Comparison Results

[0128]

[0129] Based on the comparison results shown in Table 2, it can be concluded that the advantages of this application are: it can be combined with TPM hardware binding; and it supports dynamic load adjustment (by adjusting the data push frequency).

[0130] In summary, the core of the method provided in this application lies in achieving state coordination control between the master server and the device through a multi-phase handshake protocol, aiming to solve the problem that traditional centralized authentication systems cannot guarantee business continuity under abnormal circumstances. Furthermore, through its multi-phase coordination control mechanism, this application can automatically switch to emergency mode when a fault is detected, ensuring that maintenance personnel can still manage the device, and smoothly transition back to centralized authentication mode after system recovery, achieving high availability, security, and data consistency. Compared with existing technologies, this application not only defines the functions of each module but also ensures the reliability of the entire process of fault detection, switching, and recovery through a complete request-response-confirmation (RRC) interaction chain.

[0131] Furthermore, existing centralized authentication systems (such as RADIUS / TACACS+ servers) suffer from single-point failures, preventing maintenance personnel from logging into devices and causing business interruptions. Traditional backup authentication solutions (such as local accounts) suffer from chaotic access control, high security risks, lack of real-time monitoring and automatic switching mechanisms, reliance on manual intervention, and slow response times. In contrast, the centralized device authentication and authorization emergency handling method provided in this application enables rapid detection and response to system anomalies, ensuring maintenance personnel can still manage devices during system failures, providing a smooth system recovery mechanism, and guaranteeing business continuity. Moreover, the availability of maintenance operations can be increased from 80% to 99.99%.

[0132] Based on the same inventive concept, this application also provides an emergency processing device for implementing the aforementioned emergency processing method for centralized device authentication and authorization. The solution provided by this device is similar to the solution described in the above method; therefore, the specific limitations in one or more embodiments of the emergency processing device for centralized device authentication and authorization provided below can be found in the limitations of the emergency processing method for centralized device authentication and authorization described above, and will not be repeated here.

[0133] In this embodiment, a centralized device authentication and authorization emergency response device is provided, comprising: a heartbeat monitoring module, a status determination module, and an emergency switching module.

[0134] The heartbeat monitoring module is used to establish a heartbeat detection mechanism between the main server and the device.

[0135] The status determination module is used to monitor the communication status between the master server and the device in real time using a heartbeat detection mechanism.

[0136] The emergency switching module is used to activate emergency mode when the communication status between the master server and the device is abnormal, and to enable the local authentication and authorization mechanism in emergency mode until the communication status between the master server and the device returns to normal, and then returns to centralized authentication mode.

[0137] In one exemplary embodiment, a computer device is provided, which may be a server or a terminal, and its internal structure diagram may be as follows. Figure 8As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores emergency processing data for centralized device authentication and authorization. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a centralized device authentication and authorization emergency processing method.

[0138] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0139] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0140] In one exemplary embodiment, a computer-readable storage medium is provided storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0141] In one exemplary embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0142] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0143] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (RRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM).

[0144] The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchain. The processors involved in the embodiments provided in this application may be, but are not limited to, general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc.

[0145] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0146] This document uses specific examples to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for handling emergency situations related to centralized device authentication and authorization, characterized in that, include: Establish a heartbeat detection mechanism between the main server and the device; The heartbeat detection mechanism described above is used to monitor the communication status between the main server and the device in real time. When the communication status between the master server and the device is abnormal, the emergency mode is activated, and the local authentication and authorization mechanism is enabled in the emergency mode until the communication status between the master server and the device returns to normal. This step corresponds to the emergency switchover phase. Based on the abnormal situation, the emergency mode is entered to achieve the purpose of safely switching to the local emergency mode. The specific switching process includes: Step 1: Stop the centralized service; at this time, close the main authentication connection; the main server closes the heartbeat anomaly detection mechanism; when shutdown() is called to forcibly close its connection, the main server's service will stop responding to heartbeat probe requests; the heartbeat channel, as an independent link for monitoring the status between nodes, will immediately detect the main server's unresponsive state and trigger the failover process. Step 2: Load local credentials; decrypt the emergency account from the TPM security chip; Step 3: Restrict permissions; only predefined commands are allowed when the system restarts, logs are viewed, configuration backup / restore is performed, services are controlled, network diagnostics are performed, and system status is viewed. Step 4: Enable log caching; all operations are recorded to encrypted local logs. Step 5: Notify the maintenance end; send a system status change alarm; This includes establishing a heartbeat detection mechanism between the main server and the devices, including: The master server sends the public key to the device, and the device verifies the certificate chain and then stores the public key. Set the heartbeat interval and heartbeat timeout threshold between the master server and the device, and obtain the maximum or minimum interval allowed by the device hardware; An encrypted channel is established based on the secure transport layer protocol, and a device identifier is set. The device is then bound to the main server based on the device identifier. The master server adds the device to the heartbeat management list; the parameters of the heartbeat management list include: device unique identifier, heartbeat interval, heartbeat timeout threshold, maximum and minimum allowed interval, timestamp of received response, consecutive failure count and network quality score; Read parameters from the heartbeat management list and establish a heartbeat channel based on the parameters; The heartbeat intervals in the heartbeat management list are updated in real time based on the network quality score to generate heartbeat packets for the heartbeat detection mechanism; The processing steps of the local authentication and authorization mechanism include: the authentication service stops triggering the heartbeat detection mechanism and loads local credentials; the credential information input by the user is obtained, and local authentication and authorization are performed based on the credential information input by the user and the local credentials.

2. The emergency handling method for centralized equipment authentication and authorization according to claim 1, characterized in that, The heartbeat detection mechanism described above is used to monitor the communication status between the master server and the device in real time, including: The master server periodically broadcasts heartbeat packets to all devices. The devices verify the heartbeat packets and return response packets indicating their device status. The master server listens to the response packets from these devices and obtains the listening response results. The communication status between the master server and the device is obtained based on the monitoring response results.

3. The emergency handling method for centralized equipment authentication and authorization according to claim 2, characterized in that, The process by which the device verifies the signature of the heartbeat packet includes: A hash algorithm is used to decrypt the signature of the heartbeat packet based on the public key to obtain the first hash value; The hash algorithm described above is used to perform a hash calculation on the original data in the heartbeat packet to obtain a second hash value; Determine whether the first hash value is equal to the second hash value; The verification is successful when the first hash value equals the second hash value. Verification fails when the first hash value is not equal to the second hash value; If verification fails, the heartbeat packet is discarded and a security event is recorded; the security event includes the received heartbeat packet information and the reason for the verification failure. When multiple consecutive verification failures occur, the device's security protection mechanism is triggered.

4. The emergency handling method for centralized equipment authentication and authorization according to claim 2, characterized in that, The process by which the master server listens for response packets from the device includes: Determine whether a response packet from the device is received within the heartbeat timeout threshold; If no response packet is received from the device within the heartbeat timeout threshold, a heartbeat timeout alarm is triggered, and the failure count is incremented. Real-time acquisition of device performance metrics and proactive alarms are used to comprehensively assess fault information and update device activity status; If a response packet from the device is received within the heartbeat timeout threshold, no action is taken.

5. The emergency handling method for centralized equipment authentication and authorization according to claim 4, characterized in that, The process for determining abnormal communication status between the master server and the device includes: The heartbeat timeout is determined based on the relationship between the failure count and the set value; When a heartbeat times out, check if the master server broadcasted the message. When the master server broadcasts, it checks the local status of the device and determines whether there are any abnormalities in the local status of the device. When the local state of the device is abnormal, the communication state between the master server and the device is abnormal. The communication between the master server and the device is normal when the heartbeat does not time out, the local status of the device is normal, or the master server does not broadcast.

6. A computer device, comprising: A memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the processor executes the computer program to implement the device centralized authentication and authorization emergency handling method according to any one of claims 1-5.

7. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the device centralized authentication and authorization emergency handling method as described in any one of claims 1-5.

8. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the device centralized authentication and authorization emergency handling method as described in any one of claims 1-5.

Images